One of the most common mistake we make and spend a lot of time for troubleshooting would be 'Network send some message but does not get any response from UE'. One of the most common reason in this situation (especially when you see the message has gone through L1) would be mismatchs between Signalling message and SRB.

3GPP 36.331 4.2.2 Signalling radio bearers says :

• SRB0 is for RRC messages using the CCCH logical channel;
• SRB1bis is for RRC messages (which may include a piggybacked NAS message) as well as for NAS messages prior to the activation of security, all using DCCH logical channel;
• SRB2 is NOT defined for LTE-NB.

The quote above leaves out one bearer. In 36.331 v19.3.0 clause 4.2.2, NB-IoT also uses SRB1, which carries RRC messages once AS security is active. The same clause marks both SRB2 and SRB4 as not applicable for NB-IoT. So an LTE-NB UE has at most three SRBs: SRB0, SRB1bis and SRB1.

Followings are the topics to be covered in this page.

• Which SRB does each LTE-NB RRC message use ?
• When does an LTE-NB UE move from SRB1bis to SRB1 ?
• Reference

Which SRB does each LTE-NB RRC message use ?

In the troubleshooting case described above, the first thing to check is the bearer each message went on. Each message definition in 36.331 clause 6.7 states its signalling radio bearer, and the table below collects them for the NB-IoT messages that use one.

From the message definitions in 36.331 v19.3.0 clause 6.7. MIB-NB, SIB1-NB, SystemInformation-NB, Paging-NB and SCPTMConfiguration-NB use BCCH, PCCH or SC-MCCH and no SRB.

The table shows three groups. Every CCCH message uses SRB0, because the UE has no dedicated bearer yet. RRCConnectionSetupComplete-NB always uses SRB1bis, because security is never active when it is sent. Messages that only make sense with security, such as RRCConnectionReconfiguration-NB and RRCConnectionResume-NB, always use SRB1. The rest can use either bearer, depending on whether security has been activated.

• SRB0 carries every CCCH message : connection request, setup, reject, re-establishment, resume request and early data.
• SRB1bis carries RRCConnectionSetupComplete-NB : it is the first DCCH message, and security is never active yet.
• SRB1 carries reconfiguration and resume : those messages need AS security.
• Most DCCH messages allow either : the bearer depends on whether security has been activated.

When does an LTE-NB UE move from SRB1bis to SRB1 ?

The either-bearer messages raise a practical question. The UE and the eNB must agree on which bearer is in use at every moment, or a message ends up on a bearer the other side does not expect. 36.331 v19.3.0 clause 5.3.1 gives the rules.

During RRC connection establishment, an NB-IoT UE establishes SRB1bis implicitly together with SRB1. SRB1bis has the same configuration as SRB1 but no PDCP entity, and it uses logical channel identity 3. SRB1bis is used until security is activated. The messages that activate security, the command and its successful response, are sent over SRB1, and ciphering starts after that procedure completes. After security is activated, new RRC messages are sent on SRB1.

Two cases keep the UE on SRB1bis. If security activation fails, the failure message is sent over SRB1, and the messages after it go back to SRB1bis. A UE that supports only the Control Plane CIoT EPS optimisation, or only the Control Plane CIoT 5GS optimisation, establishes SRB1bis alone. That UE carries its data inside NAS messages, never activates AS security, and so never uses SRB1.

This gives two things to check when a message gets no response. First, check whether AS security is active, because that decides SRB1bis or SRB1 for most DCCH messages. Second, check which CIoT optimisation the UE supports. A control-plane-only UE cannot receive a message that the table allows only on SRB1.

• SRB1bis has no PDCP : RRC messages on it are neither ciphered nor integrity protected by AS.
• SRB1bis uses logical channel identity 3 : 36.331 clause 9.1.2.1a gives its default configuration.
• Security activation moves the UE to SRB1 : the security mode messages themselves already use SRB1.
• Control Plane CIoT only means SRB1bis only : such a UE never activates AS security.

Reference

[1] 3GPP TS 36.331 v19.3.0 - clause 4.2.2 for signalling radio bearers, clause 5.3.1 for SRB1bis, clause 6.7 for NB-IoT RRC messages, clause 9.1.2.1a for the SRB1bis configuration