EMM Service Reject After Disconnection

[anilgurses]

Hi,

I am currently having issues with reconnecting the UE to the eNB after disconnecting for more than ~2 mins. Here are the details,

Issue Description

First, UE successfully attached to eNB and started to receive data. After waiting 1-2 minutes, I took the UE outside of the eNB coverage area and UE was disconnected from the eNB. I waited 4 minutes and then took the UE back inside the coverage area. At this point, the problem showed itself. UE couldn't get authorized by EPC and always receives service reject with emm cause 0x09. Even if I wait for a long time for the reconnection, the UE eventually fails to attach for the maximum number of trials(5). If I wait less than 1 minute while disconnected and then I go back to the coverage area, there is no problem. The thing I can't understand is why previously authorized UE can not get authorized again after disconnecting after a certain amount of time. If I restart the UE, it starts to work again.

Setup Details

• eNB & EPC - USRP B205 mini SRS 21.10 UHD 4.1.0 50 PRB but also tried 100 PRB&25 PRB

• UE - USRP B205 mini SRS 21.10 UHD 4.1.0

Expected Behavior

Successful reconnection

Actual Behaviour

Service reject with cause 0x9.

Steps to reproduce the problem

After successful connection to eNB, take UE out of the coverage area for more than 3-4 minutes. Then, take UE back to the coverage area.

enbepcLogs.tar.gz ue.log

[anilgurses]

I found a workaround for my problem. Before going into details, I need to say that I am not an expert on LTE. Therefore, the things I did or wrote below could be wrong. First, let me explain how the problem arises on the UE side step by step,

[Current state: UE is connected and receiving data ] 1- RRC-Connected and EMM registered. EPC and UE have correct state information. 2- While the application(iperf or ping) is running in the background, UE goes outside the coverage area. (I observed that UE is able to receive PSS signals at this step. Therefore, it tries to send Random Access transmission but eNB never receives it. 3-eNB creates a UE context release after a certain time(roughly 2 min). Then, sends it to EPC for UE context release. When UE context release is completed, the EMM registration is removed for UE from the core network. This is why I am getting service reject with EMM cause #9. 4- After UE context release is completed by EPC, it notifies eNB and eNB tries to notify UE(it never happens because UE is not able receive signals from eNB) 5- Normally, after normal disconnection T301 timer should start. When T301 timer expires, UE should go EMM-DEREGISTERED state on NAS and it should look start searching for cells. More details can be read from TS 136 331(5.3.3.7, page 56) 7- Since T301 never starts, UE stays in EMM-REGISTERED and RRC-IDLE state. To clarify, T301 timer is working but it somehow never starts. (I couldn't identify the issue at this point) 8- When UE receives a request from the application, it starts to a service request(with cause mo-data) due to EMM-REGISTERED state. When the service request is initiated, it tries to reestablish the RRC connection. 9- RRC connection is established but then UE receives service reject with EMM cause #9. From the spec(TS 124 301(5.6.1.5, page 123)), UE should go EMM-DEREGISTERED state and initiate attach procedure. 10- When the UE receives cause #9, it was trying to reattach(EMM state is DEREGISTERED::ATTACH_NEEDED) but it can't attach. After max trials(5), it start t3402 timer(12 min). Then, there is no attachment at all.

To solve the problem, Instead of going to EMM-DEREGISTERED::ATTACH_NEEDED, I suggest that it should go EMM-DEREGISTERED::PLMN_SEARCH.
Also, when the connection_request_completed function receives false outcome, it goes emm_state_t::registered_substate_t::normal_service state. Isn't it wrong? I changed it to emm_state_t::deregistered_substate_t::plmn_search. Now, everything works. I am not sure that I broke something for other scenarios. Also, I am not sure that this is the correct way to solve this problem.

If you think I am wrong at some point, I am more than happy to learn the correct version. Also, if my approach is correct, I am more than happy to pr my changes.

Thank you for your understanding. Let me know if you need more logs or testings.

[copslock]

Beacuse of the famous IMSI 000000000000000 problem,the EPC context mangement is broken #588

[anilgurses]

I saw IMSI 000000000000000 problem as well. However, I can't see that error anymore after my little fix in srsue. If it was an epc problem, why I am able to reconnect successfully again after restarting again?

If you look at TS 124 301 (5.2.3.2.4), for plmn-search it says "The UE may also enter this substate as a ..... basically as a result of a service request rejected by the network". I wrote my solution to my second comment on this issue but I can also make a pull request. I am just waiting for a comment on my approach.

[anilgurses]

As a side note, I have very powerful hardware and I don't believe it's related to hardware as it is mentioned in the issue you sent.

[copslock]

@anilgurses Why UE reattach with Service Request faild?It shows in the EPC console log ---invalid S-MAC,this problem is even serious in early versions that can even happened in active state,I think they didn't actually fix this problem totally, it was covered by the fix of some other procedure.The key point of this problem is when enter invalid S-MAC routine,the nas->ctx was improperly reset or something else happened to the nas context pointer,I am trying to locate the root cause ,I guess its caused by the simple hack style nas* nas_ctx = s1ap->find_nas_ctx_from_imsi(imsi); function,the reset pointer just made the nas->ctx always returned NULL, and the NULL enb_ue_s1ap_id, value diddn't properly update the initial context message

`bool s1ap_ctx_mngmt_proc::send_initial_context_setup_request(nas* nas_ctx, uint16_t erab_to_setup)
{
  m_s1ap_log->info("Preparing to send Initial Context Setup request\n");

  // Get UE Context/E-RAB Context to setup
  emm_ctx_t* emm_ctx = &nas_ctx->m_emm_ctx;
  ecm_ctx_t* ecm_ctx = &nas_ctx->m_ecm_ctx;
  esm_ctx_t* esm_ctx = &nas_ctx->m_esm_ctx[erab_to_setup];
  sec_ctx_t* sec_ctx = &nas_ctx->m_sec_ctx;

  // Prepare reply PDU
  s1ap_pdu_t tx_pdu;
  tx_pdu.set_init_msg().load_info_obj(ASN1_S1AP_ID_INIT_CONTEXT_SETUP);

  asn1::s1ap::init_context_setup_request_ies_container& in_ctx_req =
      tx_pdu.init_msg().value.init_context_setup_request().protocol_ies;

  // Add MME and eNB S1AP Ids
  in_ctx_req.mme_ue_s1ap_id.value = ecm_ctx->mme_ue_s1ap_id;
  in_ctx_req.enb_ue_s1ap_id.value = ecm_ctx->enb_ue_s1ap_id;//NULL pointer now

which caused the eNodeB refuse to pass the message to the right UE,that's why when you restart the program it works again

[anilgurses]

@copslock I understood your point. tried this under different conditions. For instance, if you run the exact scenario on zmq, you will not encounter with imsi 0000.. error. At least, I haven't observed on my tests. You might also be right about EPC context manager. However, can you give me details about how the pointer issue in EPC can be solved by restarting ue? Is there something I am missing? I will try to debug the function(and other related) you gave on my setup. I'll update you.

I still believe that there is an issue in UE as I declared in my previous comments. I hope Andre or someone from srsRAN team will reply soon.

[anilgurses]

@andrepuschmann Sorry to tag you but your comment on this matter is well appreciated.