Definitions
- MIoT (Mobile Internet of Things) is a GSMA term that refers to the 3GPP LPWA (Low Power Wide Area) technologies using the licensed band.
- 3GPP LPWA Technology are LTE-M (LTE Machin Type Communication), NB-IoT (Narrow Band IoT) and EC-GSM-IoT (Extended Coverage GSM IoT).
- MTC (Machine Type Communication) is ability that is given to a device/machine or physical object that contain embedded technology to communicate with the Base Station (BS), specified by 3GPP in Release 12.
- eMTC (enhanced MTC) specified by 3GPP in Relrase13 (LTE Cat-M1) and then enhanced in Release 14 (LTE Cat-M2).
- LTE-M (LTE Machine Type Communication) is an industrial term of 3GPP eMTC. LTE-M allows access to network services via E-UTRA (Evolved Universal Terrestrial Radio Access) with 1.4 MHz and 5 MHz channel bandwidth with LTE Cat-M1 and LTE-Cat-M2 devices respectively.
- NB-IoT: NB-IoT allows access to network services via E-UTRA with a channel bandwidth limited to 200 kHz. NB-IoT, is a term specified by 3GPP in Release 13 (NB-IoT Category NB1) and then enhanced in Release 14 (NB-IoT Category NB1).
- NB-IoT UE: A UE that uses NB-IoT.
- NB-N1 mode, the capability that allows the NB-IoT UE to connect the 5GCN (5G Core Network) via E-UTRA.
- WB-N1 mode, the capability that allows the NR/LTE-M UE to connect the 5GCN via E-UTRA.
5G and mMTC
mMTC (Massive Machine Type Communications) or Massive IoT, is one of the three usage scenarios of 5G that allows the billions of the devices to send the data (especially small volumes of the data) across the 5G network. However, the 3GPP have developed several enhancements in Release 14, especially for NB-IoT technology to support mMTC. The mMTC devices are low cost and typically only communicate with the network infrequently. In the early phase of 5G deployment, NB-IoT and LTE-M technologies can be utilized to allow the billions of the devices to send small volumes of the data across the network infrequently. For this case, the mMTC devices utilize the 4G technologies of NB-IoT and LTE-M, to connect the 5G Core. In addition, the 4G Base Station (eNB) should be upgraded to an ng-eNB capable of working in the NG-RAN (Next Generation Radio Access Network) as well as connecting to the 5GCN (Figure 1). Therefore, by this way some of the enhanced services (e.g. network slicing, MICO Mode, etc.) supported by 5G which are applicable for mMTC type communication can be used.
NB-IoT Operation Mode
For NB-IoT operating in LTE, system scenarios have been divided into 3 following operations,
- Category NB1/NB2 stand-alone operation: category NB1/NB2 is operating standalone when it utilizes its own spectrum, for example the spectrum used by GERAN systems as a replacement of one or more GSM carriers, as well as scattered spectrum for potential IoT deployment.
- Category NB1/NB2 guard band operation: category NB1/NB2 is operating in guard band when it utilizes the unused resource block(s) within an E-UTRA carrier’s guard-band.
- Category NB1/NB2 in-band operation: category NB1/NB2 is operating in-band when it utilizes the resource block(s) within a normal E-UTRA carrier
The information about operation mode is sent via MIB-NB (Master Information Block-Narrow Band) over PBCH-NB (Physical Broadcast Channel-Narrow Band) to the NB-IoT devices.
In the figure below, the Operation mode and the MIB-NB IE (Information Element) related to the Operation mode is shown in Figure 2.
Multi carrier Configuration:
There two types of carriers in the NB-IoT as follows:
- Anchor carrier: a carrier where the UE assumes that NPSS/NSSS/NPBCH/SIB-NB are transmitted.
- NPSS: Narrow Band Primary Synchronization Signal
- NSSS: Narrow Band Secondary Synchronization Signal
- Non-anchor carrier: a carrier where the UE does not assume that NPSS/NSSS/NPBCH/SIB-NB are transmitted.
When NB-IoT is operating in inband-SamePCI (in-band with the same PCI (Physical Cell Identity)) mode, only a specific PRB (Physical Resource Block) within the legacy LTE System Band can be configured as Anchor carrier. The PRB index within LTE channel bandwidth are as follows (Figure 3):
The NB-IoT device can be scheduled using anchor carrier or non-anchor carrier for sending and receiving the user data using NPUSCH (Narrow Band Physical Uplink Shared Channel) or NPDSCH (Narrow Band Physical Downlink Shared Channel). In case of non-anchor carrier, the NB-IoT UE can be configured using RRCConnectionReconfiguration-NB message by the ng-eNB. The support of multi carrier and multi tone is sent by the NB-IoT during RRCConnectionRequest-NB to the ng-eNB.
NB-IoT UE Registration with the 5GS (5G System)
To use the 5G network services, the NB-IoT UEs need to register with the 5G system. There is possibility in the 5G system to register without a data connection. If NB-IoT devices need to send/receive the data to/from an IoT Application Server (AS), then they can request to establish a data connection/PDU Session, which can be based upon Unstructured, Ethernet and IP. In this article, I will try to explain the registration procedure of a NB-IoT UE within the 5G system. The key IEs (Information Elements) exchanged between the NB-IoT device and the 5G System during the network registration, will also be explained.
RRC Connection Establishing:
By decoding the MIB-NB (Master Information Block-Narrow Band), the NB-IoT UE can understand the scheduling information to receive the SIB1-NB (System Information Block Type 1-Narrow Band), which contains the scheduling information of other Narrow Band SIBs. Decoding the system information assists the NB-IoT UE how to behave in the cellular network, e.g. Cell Selection/Re-reselection in Intra-Frequency or Inter-Frequency, running the random access procedures and establishing the RRC Connection, Registration with the 5G network, listening to the paging message.
As NB-IoT users utilize the narrow band physical channels to establish the RRC Connection, the ng-eNB will be aware about the type of devices.
To establish the RRC Connection with ng-eNB within NG-RAN, the NB-IoT UE sends RRCConnectionRequest-NB (Figure 4) which includes the following information:
- EstablishmentCause, e.g. Provides the establishment cause for the RRC connection request as provided by the upper layers, the cause of establishment in Release 16: mt-Access, mo-Signalling, mo-Data, mo-ExceptionData
- UE identity, is included to facilitate contention resolution by lower layers and can be NG-5G-S-TMSI (added in Release 16) or random value (0..248-1). NG-5G-S-TMSI is a shortened version of the 5G-GUTI, This identity is included for NB-IOT UE if upper layers provide a 5G-S-TMSI , a temporary UE identity provided by the AMF, Added in Release 16.
- MultiToneSupport (Optional), if present, this field indicates that the UE supports multi-carrier operation in the mode, FDD or TDD, used for access, Added in Release 13.
- MultiCarrierSupport (Optional), if present, this field indicates that the UE supports UL multi-tone transmissions on NPUSCH in the mode, FDD or TDD, used for access, Added in Release 13.
After SRB1 configuration by the ng-eNB, the NB-IoT device changes its state from the RRC_IDLE to the RRC_Connected (shown in Figure 4) and then sends the RRCConnectionSetupComplete-NB message which contains the following information to ng-eNB:
- Dedicated NA message (NAS PDU), e.g. The “Registration Request”
- Selected PLMN Identity, Index of the PLMN selected by the NB-IoT UE from the plmn-IdentityList included in SystemInformationBlockType1-NB.
- NG-5G-S-TMSI (Optional), is a shortened version of the 5G-GUTI, This identity is included for NB-IOT UE if upper layers provide a 5G-S-TMSI , a temporary UE identity provided by the AMF, Added in Release 16.
- Registered AMF (Optional), is used to transfer the GUAMI of the AMF where the NB-IOT UE has been registered previously, Added in Release 16
- GUAMI Type (Optional), is used to indicate whether the GUAMI included is native (derived from native 5G-GUTI) or mapped (from EPS, derived from EPS GUTI), Added in Release 16.
- S-NSSAI List (Optional), contains a list of up to eight network slice ID, Added in Release 16
- NG-U Data Transfer (Optional), indicates whether the NB-IOT UE is capable of sending the user data on N3 interface, Added in Release 16
- UP-CIoT 5GS Optimization (Optional), is included when the NB-IOT UE is capable of User Plane 5G Optimization, the capability that utilizes the signaling optimizations to enable efficient transport of user data (IP, Ethernet or Unstructured) over the user plane, Added in Release 16.
AMF Selection for sending the NAS Registration Request
If the NB-IoT UE wishes to register with the 5GC (5G Core), it will include the “NAS Registration Request” message in the RRCConnectionSetupComplete-NB message. The “NAS Registration Request” message may contain the IEs (Information Element) shown in Figure 5:
The NAS registration Request is then sent via N2 interface by the ng-eNB using NGAP: Initial UE Message to the AMF. Upon receiving the NAS Registration Request message , the AMF first checks whether 5G-GUTI is included in the message to obtain the SUPI for the security procedure, if not then requests the NB-IoT UE to prepare the SUCI/SUPI by sending the NAS Identity Request message (Figure 6).
UE Capability Enquiry Procedure:
The ng-eNB will then request the NB-IoT UE to prepare radio access capabilities by sending the UE Capability Enquiry message (Figure 6). In response, the NB-IoT UE prepares the NB-IoT Radio Access capability information and then sends it by RRC: UE Capability Information message to the ng-eNB which in turn will send the prepared information to the AMF by NGAP: UE Radio Capability Information Indication message. At this point, both ng-eNB and AMF are aware of the UE’s RAT type, which is NB-IoT.
Some important radio access capability parameters applicable in NB-IoT are as follows:
- Ue-Category-NB, defines a combined uplink and downlink capability in NB-IoT. Based upon the downlink and, uplink physical layer parameter values there two categories of NB-IOT as NB-IOT Category NB1 and NB-IOT Category NB2.
- MultiTone-r13, defines whether the UE supports UL multi-tone transmissions on NPUSCH, and is only applicable for UEs of any ue-Category-NB. This field is mandatory for UEs of this release of the specification.
- MultiCarrier-r13, defines whether the UE supports multi-carrier operation and is only applicable for UEs of any ue-Category-NB. This field is mandatory for UEs this release of the specification.
- TwoHARQ-Processes-r14, defines whether the UE supports 2 HARQ processes in DL and UL. This field is only applicable for UEs that support category NB2.
- MultiCarrier-NPRACH-r14, defines whether the UE supports NPRACH on non-anchor carrier and is only applicable for UEs of any ue-Category-NB. It is mandatory for NB-IoT UEs of this release of the specification.
- MultiCarrierPaging-r14, defines whether the UE supports paging on non-anchor carriers for FDD and is only applicable for UEs of any ue-Category-NB. It is mandatory for NB-IoT UEs of this release of the specification.
- SupportedBandList-r13, defines which NB-IoT radio frequency bands are supported by the UE. This field is only applicable for UEs of any ue-Category-NB.
- powerClassNB-20dBm-r13
- powerClassNB-14dBm-r14
- MultipleDRB-r13, indicates whether the UE supports multiple DRBs. Within the 5G system, it is only applicable if the NB-IOT UE supports NG-U data transfer or User plane CIoT 5GS Optimization, and any ue-Category-NB.
- EarlyData-UP-5GC-r16, indicates whether the UE supports MO-EDT (Mobile Originated Early Data Transmission) for User Plane CIoT 5GS optimization.
- Pur-CP-5GC-r16, indicates whether the UE supports transmission in preconfigured UL resource (PUR) for NB-IoT FDD for Control Plane CIoT 5GS optimization. This feature is only applicable if the UE supports any ue-Category-NB.
- Pur-UP-5GC-r16, indicates whether the UE supports transmission in preconfigured UL resource (PUR) for NB-IoT FDD for User Plane CIoT 5GS optimization. This feature is only applicable if the UE supports any ue-Category-NB.
Authentication and NAS Security Procedure:
Once the AMF gets the NB-IOT UE’ SUPI/SUCI, it starts the authentication procedure (Figure 6). In this procedure the AMF, the AUSF, the UDM and the NB-IOT UE are involved and both 5G network and NB-IoT UE will authenticate each other. Once authentication has taken place, the AMF then initiates the NAS Security Procedure (Figure 6) by sending NAS Security Mode Command message to the NB-IoT UE. In this message, the AMF defines the algorithms which should be used for encryption and integrity and it also provides a KSI (Key Set Identifier) and NB-IoT UE Security Capability. The NAS Security Mode Command message is encrypted but not integrity protected. In response, the device will send the NAS Security Mode Complete message which both encrypted and integrity protected. This message may include the IMEISV (International Mobile Equipment Identity/ Software Version) if requested by the AMF.
Subscription Data Management and Policy Management:
Once the NAS Security is successful, the AMF should register with the UDM to inform that is taking the responsibility of the NB-IoT UE. The AMF will then conduct the registration with the UDM by sending a message calling the Nudm_UECM API (Figure 7). In this message the current RAT type of the UE is included which is NB-IoT. Once the AMF registration for the NB-IoT UE has taken place in the UDM, the AMF will retrieve the UE’s individual subscription data which is related to the access and mobility management by sending a message to the UDM which calls the Nudm_SDM API. In response, the UDM will return the requested information to the. Since the RAT type is NB-IoT, the following specific parameters can be included in the subscription data:
- NbIoTUePriority, Indicates NB IoT UE priority which is used by the NG-RAN to prioritize resource allocation between UEs accessing via NB-IoT.
- MicoAllowed, Indicates whether the UE subscription allows MICO mode.
- EcRestrictionDataNb, If present, this IE should indicate whether Enhanced Coverage for NB-N1 mode is restricted or not.
- True: Enhanced Coverage for NB-N1 mode is restricted.
- False or absent: Enhanced Coverage for NB-N1 mode is allowed.
- ActiveTime, subscribed active time based upon the seconds for PSM (Power Saving Mode) UEs, To enable UE power saving and to enhance MT (Mobile Terminating) reachability while using MICO mode, e.g. for CIoT , this timer can be sent by the device
Registration Accept and Registration Complete:
After completing the NB-IoT context in the AMF, the Registration Accept message containing the IEs (Information Elements) shown in Figure 8 is sent to the device by the AMF.
Some other important IEs related to the timers are sent to the NB-IoT device by Registration Accept message shown in the Figure 9.
Note: the Registration Accept message can include some other IEs which are not shown in the Figure H and Figure 8 and 9. For more information in this regard, you can refer to the 3GPP TS 24.501 specification.
Finally, if new 5G-GUTI is allocated by the AMF, the NAS Registration Complete message should be sent by the NB-IoT device to the AMF (Figure 10).
References
- 3GPP TS 23.501: “System Architecture for the 5G System; Stage 2”.
- 3GPP TS 23.502: “Procedures for the 5G System; Stage 2”.
- 3GPP TS 24.008: “Mobile Radio Interface Layer 3 specification; Core Network Protocols; Stage 3”.
- 3GPP TS 24.501: “5G Non-Access-Stratum (NAS) protocol for 5G System (5GS); stage3”
- 3GPP TS 29.503: “5G System; Unified Data Management Services; Stage 3”.
- 3GPP TS 36.300: “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); overall description; Stage 2”.3GPP TS 38.300: “NR; NR and NG-RAN Overall Description”.
- 3GPP TS 38.300: “NR; NR and NG-RAN Overall Description”.
- 3GPP TS 36.306: “Evolved Universal Terrestrial Radio Access -E-UTRA); User Equipment -UE) Radio access capabilities”.
- 3GPP TS 36.331: “Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification”.
- 3GPP TS 36.304: “Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) Procedures in idle mode”.