As in physical layers, in RRC there has been drastical changes for LTE-NB introducing a lot of new RRC messages and IE (Information Elements) dedicated for LTE-NB. Understandably some of the functions of normal LTE function are not supported in LTE-NB.
The changes follow from what an NB-IoT UE does. It stays in one cell, sends little data, and spends most of its life in idle mode. So the RRC functions for mobility and measurement drop out, while the ones for connection setup, suspension and resumption stay. The two sections below cover the functions that are missing and the messages that remain.
Followings are the topics to be covered in this page.
RRC Functions Not in LTE-NB
An NB-IoT UE does not move between cells while connected, and it does not report measurements. So several RRC functions of normal LTE have nothing to do in NB-IoT, and 36.331 marks them as not applicable.
Followings are the functionality that are supported in normal LTE but not supported in LTE-NB. These are based on 36.331 4.4 Functions.
- ETWS Notification, CMAS Notification
- InterRAT Mobility including e.g security activation transfer of RRC context information
- Measurement Configuration and Reporting
- Self-configuration and Self-optimization
- Measurement logging and reporting for network performance optimization
The list above reflects Release 13. 36.331 v19.3.0 clause 4.4 still marks inter-RAT mobility, measurement configuration and reporting, self-configuration and self-optimisation, and measurement logging as not applicable for NB-IoT. It also marks QoS control with SPS and prioritised bit rate as not applicable for NB-IoT.
ETWS and CMAS notification no longer carry that mark in v19.3.0. Clause 5.2.1.3 lets E-UTRAN notify NB-IoT UEs in RRC_IDLE about ETWS and CMAS notification through Direct Indication information. So the first bullet above no longer holds in the current release.
Mobility changes shape rather than disappearing. NB-IoT keeps only key change without re-keying at RRC Connection Resumption, and transfer of RRC context information, as NOTE 1 of clause 4.4 states. An NB-IoT UE that moves to a new cell therefore reselects it in idle mode, or re-establishes or resumes its connection there, instead of being handed over.
No measurement reporting : the eNB never configures measurements for an NB-IoT UE.No handover : cell change happens through reselection, re-establishment or resume.No SPS or PBR : QoS control by RRC is not applicable for NB-IoT.ETWS and CMAS are supported now : the Release 13 exclusion no longer appears in v19.3.0.
LTE-NB RRC Messages at High Level
Following is the high level RRC messages defined for NB-IoT. Just take a brief look at the overall message structure and refer to 36.331 6.7 NB-IoT RRC messages for the details.
Following is based on
BCCH-BCH-Message-NB ::= SEQUENCE {
message BCCH-BCH-MessageType-NB
}
BCCH-BCH-MessageType-NB::= MasterInformationBlock-NB
BCCH-DL-SCH-Message-NB ::= SEQUENCE {
message BCCH-DL-SCH-MessageType-NB
}
BCCH-DL-SCH-MessageType-NB ::= CHOICE {
c1 CHOICE {
systemInformation-r13 SystemInformation-NB,
systemInformationBlockType1-r13 SystemInformationBlockType1-NB
},
messageClassExtension SEQUENCE {}
}
PCCH-Message-NB ::= SEQUENCE {
message PCCH-MessageType-NB
}
PCCH-MessageType-NB ::= CHOICE {
c1 CHOICE {
paging-r13 Paging-NB
},
messageClassExtension SEQUENCE {}
}
DL-CCCH-Message-NB ::= SEQUENCE {
message DL-CCCH-MessageType-NB
}
DL-CCCH-MessageType-NB ::= CHOICE {
c1 CHOICE {
rrcConnectionReestablishment-r13 RRCConnectionReestablishment-NB,
rrcConnectionReestablishmentReject-r13 RRCConnectionReestablishmentReject,
rrcConnectionReject-r13 RRCConnectionReject-NB,
rrcConnectionSetup-r13 RRCConnectionSetup-NB,
rrcEarlyDataComplete-r15 RRCEarlyDataComplete-NB-r15,
spare3 NULL, spare2 NULL, spare1 NULL
},
messageClassExtension SEQUENCE {}
}
DL-DCCH-Message-NB ::= SEQUENCE {
message DL-DCCH-MessageType-NB
}
DL-DCCH-MessageType-NB ::= CHOICE {
c1 CHOICE {
dlInformationTransfer-r13 DLInformationTransfer-NB,
rrcConnectionReconfiguration-r13 RRCConnectionReconfiguration-NB,
rrcConnectionRelease-r13 RRCConnectionRelease-NB,
securityModeCommand-r13 SecurityModeCommand,
ueCapabilityEnquiry-r13 UECapabilityEnquiry-NB,
rrcConnectionResume-r13 RRCConnectionResume-NB,
ueInformationRequest-r16 UEInformationRequest-NB-r16,
spare1 NULL
},
messageClassExtension SEQUENCE {}
}
UL-CCCH-Message-NB ::= SEQUENCE {
message UL-CCCH-MessageType-NB
}
UL-CCCH-MessageType-NB ::= CHOICE {
c1 CHOICE {
rrcConnectionReestablishmentRequest-r13 RRCConnectionReestablishmentRequest-NB,
rrcConnectionRequest-r13 RRCConnectionRequest-NB,
rrcConnectionResumeRequest-r13 RRCConnectionResumeRequest-NB,
rrcEarlyDataRequest-r15 RRCEarlyDataRequest-NB-r15
},
messageClassExtension SEQUENCE {}
}
UL-DCCH-Message-NB ::= SEQUENCE {
message UL-DCCH-MessageType-NB
}
UL-DCCH-MessageType-NB ::= CHOICE {
c1 CHOICE {
rrcConnectionReconfigurationComplete-r13 RRCConnectionReconfigurationComplete-NB,
rrcConnectionReestablishmentComplete-r13 RRCConnectionReestablishmentComplete-NB,
rrcConnectionSetupComplete-r13 RRCConnectionSetupComplete-NB,
securityModeComplete-r13 SecurityModeComplete,
securityModeFailure-r13 SecurityModeFailure,
ueCapabilityInformation-r13 UECapabilityInformation-NB,
ulInformationTransfer-r13 ULInformationTransfer-NB,
rrcConnectionResumeComplete-r13 RRCConnectionResumeComplete-NB,
ueInformationResponse-r16 UEInformationResponse-NB-r16,
purConfigurationRequest-r16 PURConfigurationRequest-NB-r16,
spare6 NULL, spare5 NULL, spare4 NULL,
spare3 NULL, spare2 NULL, spare1 NULL
},
messageClassExtension SEQUENCE {}
}
SC-MCCH-Message-NB ::= SEQUENCE {
message SC-MCCH-MessageType-NB
}
SC-MCCH-MessageType-NB ::= CHOICE {
c1 CHOICE {
scptmConfiguration-r14 SCPTMConfiguration-NB-r14
},
messageClassExtension SEQUENCE {}
}
The listing above is the v19.3.0 text, and it differs from the Release 13 version in five places. The table below lists the messages that later releases added. Each one takes a spare value of the existing c1 CHOICE, so the size of the CHOICE stays the same.
Logical channel | Message added | Purpose |
UL-CCCH | RRCEarlyDataRequest-NB-r15 | Early data transmission in Msg3 |
DL-CCCH | RRCEarlyDataComplete-NB-r15 | Early data transmission in Msg4 |
DL-DCCH | UEInformationRequest-NB-r16 | Request for a RACH, RLF or ANR report |
UL-DCCH | UEInformationResponse-NB-r16 | Response to UEInformationRequest-NB |
UL-DCCH | PURConfigurationRequest-NB-r16 | Request for preconfigured uplink resources |
SC-MCCH | SCPTMConfiguration-NB-r14 | SC-PTM configuration, on a new logical channel |
From the message type definitions of 36.331 v19.3.0. The suffix in each name gives the release that introduced it.
Some messages keep their LTE names without the -NB suffix. SecurityModeCommand, SecurityModeComplete, SecurityModeFailure and RRCConnectionReestablishmentReject have the same content in NB-IoT as in LTE, so the NB-IoT message types point to the LTE definitions. Every other message has its own -NB definition.
Seven logical channels : BCCH-BCH, BCCH-DL-SCH, PCCH, DL-CCCH, DL-DCCH, UL-CCCH and UL-DCCH, plus SC-MCCH since Release 14.Early data transmission uses the CCCH : RRCEarlyDataRequest-NB and RRCEarlyDataComplete-NB carry user data in Msg3 and Msg4.New messages take spare values : each c1 CHOICE keeps the size it had in Release 13.Four messages are shared with LTE : the security mode messages and RRCConnectionReestablishmentReject.
Reference
[1] 3GPP TS 36.331 v19.3.0 - clause 4.4 for RRC functions, clause 5.2.1.3 for system information change and Direct Indication, clause 6.7 for NB-IoT RRC messages