This commit rejects an UE that connects by sending RRCConnectionRequest with S-TMSI.

The observed behavior (samsung phone, lte dongle, sequans box) is that the UE
keeps connecting over and over again.

openair2/RRC/LITE/MESSAGES/asn1_msg.c

@@ -2110,6 +2110,67 @@ do_RRCConnectionReestablishmentReject(
   return((enc_rval.encoded+7)/8);
 }
 
+//------------------------------------------------------------------------------
+uint8_t
+do_RRCConnectionReject(
+  uint8_t                    Mod_id,
+  uint8_t*                   const buffer)
+//------------------------------------------------------------------------------
+{
+
+  asn_enc_rval_t enc_rval;
+
+  DL_CCCH_Message_t dl_ccch_msg;
+  RRCConnectionReject_t *rrcConnectionReject;
+
+  memset((void *)&dl_ccch_msg,0,sizeof(DL_CCCH_Message_t));
+  dl_ccch_msg.message.present           = DL_CCCH_MessageType_PR_c1;
+  dl_ccch_msg.message.choice.c1.present = DL_CCCH_MessageType__c1_PR_rrcConnectionReject;
+  rrcConnectionReject                   = &dl_ccch_msg.message.choice.c1.choice.rrcConnectionReject;
+
+  // RRCConnectionReject
+  rrcConnectionReject->criticalExtensions.present = RRCConnectionReject__criticalExtensions_PR_c1;
+  rrcConnectionReject->criticalExtensions.choice.c1.present = RRCConnectionReject__criticalExtensions__c1_PR_rrcConnectionReject_r8;
+  /* let's put a wait time of 1s for the moment */
+  rrcConnectionReject->criticalExtensions.choice.c1.choice.rrcConnectionReject_r8.waitTime = 1;
+
+#ifdef XER_PRINT
+  xer_fprint(stdout, &asn_DEF_DL_CCCH_Message, (void*)&dl_ccch_msg);
+#endif
+  enc_rval = uper_encode_to_buffer(&asn_DEF_DL_CCCH_Message,
+                                   (void*)&dl_ccch_msg,
+                                   buffer,
+                                   100);
+  AssertFatal (enc_rval.encoded > 0, "ASN1 message encoding failed (%s, %ld)!\n",
+               enc_rval.failed_type->name, enc_rval.encoded);
+
+#if defined(ENABLE_ITTI)
+# if !defined(DISABLE_XER_SPRINT)
+  {
+    char        message_string[20000];
+    size_t      message_string_size;
+
+    if ((message_string_size = xer_sprint(message_string, sizeof(message_string), &asn_DEF_DL_CCCH_Message, (void *) &dl_ccch_msg)) > 0) {
+      MessageDef *msg_p;
+
+      msg_p = itti_alloc_new_message_sized (TASK_RRC_ENB, RRC_DL_CCCH, message_string_size + sizeof (IttiMsgText));
+      msg_p->ittiMsg.rrc_dl_ccch.size = message_string_size;
+      memcpy(&msg_p->ittiMsg.rrc_dl_ccch.text, message_string, message_string_size);
+
+      itti_send_msg_to_task(TASK_UNKNOWN, Mod_id, msg_p);
+    }
+  }
+# endif
+#endif
+
+#ifdef USER_MODE
+  LOG_D(RRC,"RRCConnectionReject Encoded %d bits (%d bytes)\n",
+        enc_rval.encoded,(enc_rval.encoded+7)/8);
+#endif
+
+  return((enc_rval.encoded+7)/8);
+}
+
 uint8_t do_RRCConnectionRelease(
   uint8_t                             Mod_id,
   uint8_t                            *buffer,

openair2/RRC/LITE/MESSAGES/asn1_msg.h

@@ -218,6 +218,16 @@ do_RRCConnectionReestablishmentReject(
     uint8_t                    Mod_id,
     uint8_t*                   const buffer);
 
+/**
+\brief Generate an RRCConnectionReject DL-CCCH-Message (eNB).
+@param Mod_id Module ID of eNB
+@param buffer Pointer to PER-encoded ASN.1 description of DL-CCCH-Message PDU
+@returns Size of encoded bit stream in bytes*/
+uint8_t
+do_RRCConnectionReject(
+    uint8_t                    Mod_id,
+    uint8_t*                   const buffer);
+
 /**
 \brief Generate an RRCConnectionRequest UL-CCCH-Message (UE) based on random string or S-TMSI.  This
 routine only generates an mo-data establishment cause.

openair2/RRC/LITE/rrc_eNB.c

@@ -963,6 +963,49 @@ rrc_eNB_generate_UECapabilityEnquiry(
 
 }
 
+//-----------------------------------------------------------------------------
+void
+rrc_eNB_generate_RRCConnectionReject(
+  const protocol_ctxt_t* const ctxt_pP,
+  rrc_eNB_ue_context_t*          const ue_context_pP,
+  const int                    CC_id
+)
+//-----------------------------------------------------------------------------
+{
+#ifdef RRC_MSG_PRINT
+  int                                 cnt;
+#endif
+
+  eNB_rrc_inst[ctxt_pP->module_id].carrier[CC_id].Srb0.Tx_buffer.payload_size =
+    do_RRCConnectionReject(ctxt_pP->module_id,
+                          (uint8_t*) eNB_rrc_inst[ctxt_pP->module_id].carrier[CC_id].Srb0.Tx_buffer.Payload);
+
+#ifdef RRC_MSG_PRINT
+  LOG_F(RRC,"[MSG] RRCConnectionReject\n");
+
+  for (cnt = 0; cnt < eNB_rrc_inst[ctxt_pP->module_id].carrier[CC_id].Srb0.Tx_buffer.payload_size; cnt++) {
+    LOG_F(RRC,"%02x ", ((uint8_t*)eNB_rrc_inst[ctxt_pP->module_id].Srb0.Tx_buffer.Payload)[cnt]);
+  }
+
+  LOG_F(RRC,"\n");
+#endif
+
+  MSC_LOG_TX_MESSAGE(
+    MSC_RRC_ENB,
+    MSC_RRC_UE,
+    eNB_rrc_inst[ctxt_pP->module_id].carrier[CC_id].Srb0.Tx_buffer.Header,
+    eNB_rrc_inst[ctxt_pP->module_id].carrier[CC_id].Srb0.Tx_buffer.payload_size,
+    MSC_AS_TIME_FMT" RRCConnectionReject UE %x size %u",
+    MSC_AS_TIME_ARGS(ctxt_pP),
+    ue_context_pP == NULL ? -1 : ue_context_pP->ue_context.rnti,
+    eNB_rrc_inst[ctxt_pP->module_id].carrier[CC_id].Srb0.Tx_buffer.payload_size);
+
+  LOG_I(RRC,
+        PROTOCOL_RRC_CTXT_UE_FMT" [RAPROC] Logical Channel DL-CCCH, Generating RRCConnectionReject (bytes %d)\n",
+        PROTOCOL_RRC_CTXT_UE_ARGS(ctxt_pP),
+        eNB_rrc_inst[ctxt_pP->module_id].carrier[CC_id].Srb0.Tx_buffer.payload_size);
+}
+
 //-----------------------------------------------------------------------------
 void
 rrc_eNB_generate_RRCConnectionReestablishmentReject(
@@ -3627,8 +3670,15 @@ rrc_eNB_decode_ccch(
       } else {
         rrcConnectionRequest = &ul_ccch_msg->message.choice.c1.choice.rrcConnectionRequest.criticalExtensions.choice.rrcConnectionRequest_r8;
         {
-          AssertFatal(rrcConnectionRequest->ue_Identity.present == InitialUE_Identity_PR_randomValue,
-                      "unsupported InitialUE-Identity in RRCConnectionRequest");
+          if (rrcConnectionRequest->ue_Identity.present != InitialUE_Identity_PR_randomValue) {
+            LOG_E(RRC,
+                  PROTOCOL_RRC_CTXT_UE_FMT" RRCConnectionRequest with S-TMSI not supported yet, let's reject the UE\n",
+                  PROTOCOL_RRC_CTXT_UE_ARGS(ctxt_pP));
+            rrc_eNB_generate_RRCConnectionReject(ctxt_pP,
+                             rrc_eNB_get_ue_context(&eNB_rrc_inst[ctxt_pP->module_id], ctxt_pP->rnti),
+                             CC_id);
+            break;
+          }
           AssertFatal(rrcConnectionRequest->ue_Identity.choice.randomValue.size == 5,
                       "wrong InitialUE-Identity randomValue size, expected 5, provided %d",
                       rrcConnectionRequest->ue_Identity.choice.randomValue.size);

[Florian Kaltenberger]

when you say "keeps connecting over and over again" how does it connect? Again with S-TMSI or with the initial procedure?

[Csaba Sipos]

Hi Florian,

We've been talking about this for a day now.

The conclusion is this:

1. THere is no way to signal the UE anything in the RRC layer (RRCConnectionReject does not hold any cause information).
2. If we do the reject what this patch does, there is a chance that a UE will stuck in this state and keep retrying with S-TMSI, cause the specs. does not tell explicitly what to do, so there is a high chance that the behavior of the UE in a consecutive RRCReject event will be implementation (vendor) dependent.
3. Because of this what we can do is to send an explicit (MME originated) Detach with the "Re-Attach required" required flag set. This also not guarantees that the UE will not try with the S-TMSI again, it needs testing, but still it seems a better way.
4. But in the end there is a high chance that we will need to implement S-TMSI handling anyway, cause even if its optional, it seems there is no proper way to handle this through signalling.

Regards, Csaba

[Florian Kaltenberger]

Hi Csaba, thanks for this clarification.

[Cedric Roux]

Yes, "keeps connecting over and over again" means the UE does it over and over with S-TMSI, at least the ones I tried (with the sequans right now for example). This really was just a test. I still prefer it than the Assert because the eNB does not crash anymore here. But yes, as Csaba says, we need to handle this case properly.

[Csaba Sipos]

"I still prefer it than the Assert because the eNB does not crash anymore"

Totally aggree with that.