[srslte-users] Follow-up on "Tracking Area Update Reject" by Daly Dylanger in January 2018

[Johann T.]

Hi Patrik,

Did you receive any response on your question?

I am also interested in the TAU Reject function. Though I haven't yet tried
the code from Daly.

Regards,
Johann



On Mon, Nov 4, 2019 at 7:09 PM Patrik <pdjdev at gmail.com> wrote:

> Hello!
>
> This is my first post in this forum, and I hope that you could help me out
> here.
>
> I was looking into the older posts and found a question (from January
> 2018) where Daly Dylanger asked about Tracking Area Update Reject, and I am
> curious about knowing if there is an update on this issue (for example that
> this issue was resolved in any recent releases).
>
> My understanding is that the reject was (still is) not implemented in
> srsLTE and the coding efforts to include the reject handling by Daly
> resulted in a conclusion that his code does not work in srsLTE while
> working fine in OpenLTE, suggesting that there is a problem in srsenb?
>
> See also below. The original post is included below for your convenience.
>
> The reason for asking about this is that we would like to do some tests on
> TAU reject and attach rejects.
>
> Thanks in advance.
>
> BR, Patrik
>
>
> ____
>
> "Hey Guys,
>
> I'm trying to issue a TAU Reject directly after an incoming INITIAL
> Tracking Area Update Request.
>
> This is what I have so far
>
> bool
> s1ap_nas_transport::pack_tracking_area_update_reject(srslte::byte_buffer_t
> *reply_msg, uint32_t enb_ue_s1ap_id)
> {
>   srslte::byte_buffer_t *nas_buffer = m_pool->allocate();
>
>   uint8 sec_hdr_type;
>
>   m_s1ap_log->console("Packing TAU Reject...\n");
>
>   //Setup initiating message
>   LIBLTE_S1AP_S1AP_PDU_STRUCT tx_pdu;
>   bzero(&tx_pdu, sizeof(LIBLTE_S1AP_S1AP_PDU_STRUCT));
>
>   tx_pdu.ext          = false;
>   tx_pdu.choice_type  = LIBLTE_S1AP_S1AP_PDU_CHOICE_INITIATINGMESSAGE;
>
>   LIBLTE_S1AP_INITIATINGMESSAGE_STRUCT *init =
> &tx_pdu.choice.initiatingMessage;
>   init->procedureCode = LIBLTE_S1AP_PROC_ID_DOWNLINKNASTRANSPORT;
>   init->choice_type   =
> LIBLTE_S1AP_INITIATINGMESSAGE_CHOICE_DOWNLINKNASTRANSPORT;
>
>   //Setup Dw NAS structure
>   LIBLTE_S1AP_MESSAGE_DOWNLINKNASTRANSPORT_STRUCT *dw_nas =
> &init->choice.DownlinkNASTransport;
>   dw_nas->ext=false;
>   dw_nas->MME_UE_S1AP_ID.MME_UE_S1AP_ID = m_s1ap->get_next_mme_ue_s1ap_id();
>   dw_nas->eNB_UE_S1AP_ID.ENB_UE_S1AP_ID = enb_ue_s1ap_id;
>   dw_nas->HandoverRestrictionList_present=false;
>   dw_nas->SubscriberProfileIDforRFP_present=false;
>
>   // Set things here
>   LIBLTE_MME_TRACKING_AREA_UPDATE_REJECT_MSG_STRUCT track_rej;
>   track_rej.emm_cause = LIBLTE_MME_EMM_CAUSE_IMPLICITLY_DETACHED;
>   track_rej.t3446_present = false;
>   sec_hdr_type = LIBLTE_MME_MSG_TYPE_TRACKING_AREA_UPDATE_REJECT;
>
>   LIBLTE_ERROR_ENUM err =
> liblte_mme_pack_tracking_area_update_reject_msg(&track_rej, sec_hdr_type,
> NULL, (LIBLTE_BYTE_MSG_STRUCT *) nas_buffer);
>   if(err != LIBLTE_SUCCESS)
>   {
>     m_s1ap_log->error("Error packing TAU Reject\n");
>     m_s1ap_log->console("Error packing TAU Reject\n");
>     return false;
>   }
>
>   //Copy NAS PDU to Downlink NAS Trasport message buffer
>   memcpy(dw_nas->NAS_PDU.buffer, nas_buffer->msg, nas_buffer->N_bytes);
>   dw_nas->NAS_PDU.n_octets = nas_buffer->N_bytes;
>
>   //Pack Downlink NAS Transport Message
>   err = liblte_s1ap_pack_s1ap_pdu(&tx_pdu, (LIBLTE_BYTE_MSG_STRUCT *)
> reply_msg);
>   if(err != LIBLTE_SUCCESS)
>   {
>     m_s1ap_log->error("Error packing Dw NAS Transport: Authentication
> Reject\n");
>     m_s1ap_log->console("Error packing Downlink NAS Transport:
> Authentication Reject\n");
>     return false;
>   }
>
>   m_pool->deallocate(nas_buffer);
>   return true;
> }
>
> However, after receiving the TAU Request, my reject is never sent, I had to
> remove some TMSI Checks, for it to execute, there appears to be some
> confusion with Security Context, I need to provide nas_dl_count, however
> this is only possible with a Security Context, that doesen't exist yet,
> I've successfully done this on OpenLTE, it appears to be a srsENB specific
> issue.
>
> Setting it to NULL or 0 dosen't help.
>
> What am I missing?
>
> Any help would be greatly appreciated!"
>
> _______________________________________________
> srslte-users mailing list
> srslte-users at lists.softwareradiosystems.com
> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20191204/8c90c40d/attachment.htm>