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;
• SRB1 is for RRC messages (which may include a piggybacked NAS message) as well as for NAS messages prior to the establishment of SRB2, all using DCCH logical channel;
• SRB2 is for RRC messages which include logged measurement information as well as for NAS messages, all using DCCH logical channel. SRB2 has a lower-priority than SRB1 and is always configured by E-UTRAN after security activation.

The quote above is the Release 8 text, and the list has grown since then. In 36.331 v19.3.0 clause 4.2.2, SRB2 also carries messages which include IAB-DU specific F1-C related information. Two more SRBs are defined. SRB1bis is for NB-IoT, and it carries RRC and NAS messages prior to the activation of security. SRB4 is for RRC messages which include application layer measurement reporting information, and E-UTRAN can configure it only after security activation. Neither SRB2 nor SRB4 is applicable for NB-IoT.

One more bearer appears in dual connectivity. In EN-DC and NGEN-DC, SRB3 may be configured to carry some NR RRC messages between the UE and the SgNB over the NR radio interface. SRB3 is defined in 38.331, not in 36.331. Once security is activated, all RRC messages on SRB1, SRB2 and SRB4 are integrity protected and ciphered by PDCP. For the NB-IoT details of SRB1bis, see SRB mapping for NB-IoT.

Followings are the topics to be covered in this page.

• Default SRB Configuration
• SRB Mapping to Signalling Message
• Which SRB do the other LTE RRC messages use ?
• Reference

Default SRB Configuration

In many cases (especially with testing environment), default setting is used for SRBs.  In most cases, you wouldn't need to check on the detailed parameter of these default settings but you would need to check on the details in case that you need to do some troubleshooting.  The detailed parameter setting for the default SRB are specified in 36.331 - 9 Specified and default radio configurations as shown below.

36.331 clause 9 splits the default into two parts. Clause 9.1.2 gives the specified configuration, which is fixed and only sets the logical channel identity. Clause 9.2.1 gives the default configuration of RLC and the logical channel, which E-UTRAN can later replace with an explicit value.

SRB1

SRB1 is the first dedicated bearer, so its defaults matter most. When RRCConnectionSetup selects the default configuration for SRB1, these are the values the UE applies.

< 36.331-9.1.2.1 SRB1 >

< 36.331-9.2.1.1 SRB1 >

The tables above give SRB1 logical channel identity 1 and RLC AM. On the UL side, t-PollRetransmit is ms45, pollPDU and pollByte are infinity, and maxRetxThreshold is t4. On the DL side, t-Reordering is ms35 and t-StatusProhibit is ms0. The logical channel has priority 1, the highest priority, with prioritisedBitRate infinity and logicalChannelGroup 0. The NB-IoT column uses t-PollRetransmit ms25000 and logicalChannelSR-Prohibit TRUE. In v19.3.0 the NB-IoT column lists t-Reordering as released, while the table image above shows N/A.

SRB1bis

SRB1bis exists only for NB-IoT. It has the same configuration as SRB1, so the specified configuration below only needs to give its logical channel identity.

< 36.331-9.1.2.1a SRB1bis >

The table gives logical channel identity 3. This is how the receiver tells SRB1bis from SRB1 on the same DCCH, because the RRC message itself does not name the bearer.

SRB2

SRB2 uses the same RLC timers as SRB1, so the difference to look for in the tables below is the logical channel. That difference decides which bearer is served first.

< 36.331-9.1.2.2 SRB2>

< 36.331-9.2.1.2 SRB2 >

The tables give SRB2 logical channel identity 2 and RLC AM with the same values as SRB1. The logical channel priority is 3, lower than the priority 1 of SRB1. This is how SRB2 gets its lower priority in clause 4.2.2. In v19.3.0, clause 9.1.2.3 also gives SRB4 its specified configuration, logical channel identity 4.

• The logical channel identity names the SRB : SRB1 is 1, SRB2 is 2, SRB1bis is 3 and SRB4 is 4.
• SRB1 and SRB2 share the RLC defaults : both use RLC AM with t-PollRetransmit ms45 and maxRetxThreshold t4.
• Priority separates SRB1 and SRB2 : SRB1 has logical channel priority 1 and SRB2 has priority 3.

SRB Mapping to Signalling Message

Also 36.331 defines the SRB mapping for each message as shown below. I recommend you to pay attention to these mapping examples. If SRB number does not match between the sender and the reciever, the message would not reach the destination even though the message is properly sent and reach the lower layer of the destination.

MasterInformationBlock

• Signalling radio bearer: N/A
• RLC-SAP: TM
• Logical channel: BCCH
• Direction: E-UTRAN to UE

 

SystemInformationBlockType1

• Signalling radio bearer: N/A
• RLC-SAP: TM
• Logical channel: BCCH
• Direction: E-UTRAN to UE

 

RRCConnectionRequest

• Signalling radio bearer: SRB0
• RLC-SAP: TM
• Logical channel: CCCH
• Direction: UE to E-UTRAN

 

RRCConnectionSetup

• Signalling radio bearer: SRB0
• RLC-SAP: TM
• Logical channel: CCCH
• Direction: E-UTRAN to UE

 

RRCConnectionSetupComplete

• Signalling radio bearer: SRB1
• RLC-SAP: AM
• Logical channel: DCCH
• Direction: UE to E-UTRAN

 

RRCConnectionReconfiguration

• Signalling radio bearer: SRB1
• RLC-SAP: AM
• Logical channel: DCCH
• Direction: E-UTRAN to UE

 

MeasurementReport

• Signalling radio bearer: SRB1
• RLC-SAP: AM
• Logical channel: DCCH
• Direction: UE to E-UTRAN

 

MobilityFromEUTRACommand

• Signalling radio bearer: SRB1
• RLC-SAP: AM
• Logical channel: DCCH
• Direction: E-UTRAN to UE

 

UECapabilityEnquiry

• Signalling radio bearer: SRB1
• RLC-SAP: AM
• Logical channel: DCCH
• Direction: E-UTRAN to UE

 

UEInformationRequest

• Signalling radio bearer: SRB1
• RLC-SAP: AM
• Logical channel: DCCH
• Direction: E-UTRAN to UE

 

DLInformationTransfer

• Signalling radio bearer: SRB2 or SRB1 (only if SRB2 not established yet. If SRB2 is suspended, E-UTRAN does not send this message until SRB2 is resumed.)
• RLC-SAP: AM
• Logical channel: DCCH
• Direction: E-UTRAN to UE

 

Paging

• Signalling radio bearer: N/A
• RLC-SAP: TM
• Logical channel: PCCH
• Direction: E-UTRAN to UE

 

Each message definition in 36.331 v19.3.0 clause 6.2.2 still lists the same four attributes, and the values above are still correct. Two entries have grown. SystemInformationBlockType1 now uses logical channels BCCH and BR-BCCH, where BR-BCCH serves BL UEs and UEs in CE. DLInformationTransfer now has three extra rules. If only timeReferenceInfo is included, SRB1 is used. Otherwise, SRB1 is used only if SRB2 is not established yet. If only dedicatedInfoF1c is included, SRB2 is used.

Let's apply this to the troubleshooting case at the top of the page. The first check is the logical channel identity in the MAC subheader of the message. It must match the SRB in the list above. The second check is timing. A NAS message sent in DLInformationTransfer goes on SRB2 once SRB2 exists, so SRB2 must already be configured and not suspended.

• Broadcast and paging have no SRB : MIB, SIB1 and Paging list the signalling radio bearer as N/A.
• SRB0 carries the CCCH messages : RRCConnectionRequest and RRCConnectionSetup travel before any dedicated bearer exists.
• SRB1 carries the DCCH control messages : reconfiguration, measurement report and capability messages all use SRB1.
• NAS transfer prefers SRB2 : DLInformationTransfer falls back to SRB1 only before SRB2 is established.

Which SRB do the other LTE RRC messages use ?

The list above covers the messages of a typical call setup. The table below adds the other common messages, taken from the message definitions in 36.331 v19.3.0 clause 6.2.2. It uses the same attributes, except RLC-SAP. The RLC-SAP is TM for CCCH and BCCH, and AM for DCCH.

From the message definitions in 36.331 v19.3.0 clause 6.2.2. Direction both means that the first message goes from E-UTRAN to UE and the second from UE to E-UTRAN, except for RRCEarlyDataRequest, which the UE sends.

The table follows the same pattern as the list above. CCCH messages use SRB0, because they are sent before or without a dedicated bearer. Almost every DCCH message uses SRB1. SRB2 appears only for messages that carry NAS information or logged measurement information, and SRB4 appears only for application layer measurement reports.

• Re-establishment starts on SRB0 : only RRCConnectionReestablishmentComplete uses SRB1.
• Resume starts on SRB0 : RRCConnectionResume and its complete message use SRB1.
• Logged measurements move to SRB2 : UEInformationResponse uses SRB2 when it includes logged measurement information.
• SRB4 has one message : MeasReportAppLayer carries the application layer measurement report.

Reference

[1] 3GPP TS 36.331 v19.3.0 - clause 4.2.2 Signalling radio bearers, clause 6.2.2 Message definitions, clause 9.1.2 and 9.2.1 SRB configurations