[srsran-users] NAS Short MAC invalid issue

[Pedro Alvarez]

Hi Joe --

I think there is a bug in the UE that you might be triggering if you create
a 5min blackout in the DL.

Basically, in the Attach Request, Service Request (and I think the TAU
request too), you are not supposed to increment the NAS COUNT until the RRC
is in the RRC Connected state.
This is because if those messages are lost, the sync between the UE and MME
will be lost.

See the following from the standard TS 24.301 V14.10.0, section 4.4.3
"Handling of NAS COUNT and NAS sequence number":
> The NAS sequence number part of the NAS COUNT shall be exchanged between
the UE and the MME as part of the
> NAS signalling. After each new or retransmitted outbound security
protected NAS message, the sender shall increase
> the NAS COUNT number by one,
*except for the initial NAS messages if the lower layers indicated the
failure to*>* establish the RRC connection (see 3GPP TS 36.331 [22]).*

Could you check if the NAS COUNT matches when you do the blackout, please?
If that is not the case, we will have to do further debugging.

Regards, Pedro.






On Tue, Nov 15, 2022 at 10:28 AM J Giovatto <jgiovatto at adjacentlink.com>
wrote:

> On 11/13/22 04:23, Andre Puschmann wrote:
> > Hi Joe,
> >
> > On 11/11/22 19:52, J Giovatto wrote:
> >> I ran into this case where if after a successful attach (rinti 0x46)
> >> the ue looses the link with the enb for 5 minute with a constant
> >> uplink ping (1pps) to the epc.
> >>
> >> Upon re-establish link (rinti 0x47) the ue does attach but con no
> >> longer complete the ping. I believe that uplink traffic is required
> >> to cause this, w/o traffic
> >
> > I am assuming you run this with ZMQ radios. Could you please check
> > that you've configured both UE and eNB to use the same EARFCNs? Note
> > that it's possible to have different values configured and the ZMQ
> > radios will still connect.
> >
> > For reestablishment or anything else related to mobility we need to
> > make sure the that the EARFCN values are correct and match because
> > they are parameters in all security related functions.
> >
> > Please check and run again, if the issue is still present, please send
> > full logs for all three components.
>
> Yes running zmq, I have confirmed that earfcn = 2850 and only earfcn =
> 2850 is in play.
>
> I have attached a patch for zmq that will create a 5 min DL blackout
> that you can try.
>
> Seems like it ony happens with UL pending traffic (ping the epc).
>
> Thanks for looking.
>
>
> Joe
>
>
> >
> >
> >> Maybe this is related to issue #960 ?
> >
> > I don't think it is related to
> > https://github.com/srsran/srsRAN/issues/960
> >
> > But have a look at the above and we check further if needed.
> >
> > Thanks
> > Andre
>
>
> _______________________________________________
> srsran-users mailing list
> srsran-users at lists.srsran.com
> https://lists.srsran.com/mailman/listinfo/srsran-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20221115/2ffc069f/attachment.htm>