5G(NR): Scheduling Request

 

5G(NR): Scheduling Request:

This Blog will explain about the NR scheduling request mechanism which is applicable between UE and gNodeB. 

The Scheduling Request is triggered when UE is in uplink sync with gNodeB and It is not having and up-link (PUSCH/PUCCH) resource allocated for transmission of  new user plane or control plane data. 

 

The Scheduling Request (SR) is used for requesting UL-SCH resources( up-link grant ) for new transmission on PUCCH channel. 

 

Network (gNodeB) replies the UE with uplink grant in DCI 0_0 or DCI 0_1 messages on PDCCH channel.  

 

 

Configuration:

 

RRC connection setup or RRC reconfiguration request are used to configure the scheduling request related parameters. 

 

 

-MAC is controling the SR and the IE MAC-CellGroupConfig is used to configure MAC parameters for a cell group.

 

MAC-CellGroupConfig ::= SEQUENCE {  

      drx-Config SetupRelease { DRX-Config } OPTIONAL, -- Need M 

      schedulingRequestConfig

       bsr-Config

       tag-Config     

       phr-Config

       skipUplinkTxDynamic BOOLEAN,  

... }

-The IE SchedulingRequestConfig is used to configure the parameters, for the dedicated scheduling request (SR) resources. 

 

SchedulingRequestConfig ::= SEQUENCE {

    schedulingRequestToAddModList       SEQUENCE

                                               SchedulingRequestToAddMod  OPTIONA,

    schedulingRequestToReleaseList      SEQUENCE

                                               SchedulingRequestId  OPTIONAL -- Need N

}

 

SchedulingRequestToAddMod ::= SEQUENCE {

    schedulingRequestId                 SchedulingRequestId,

    sr-ProhibitTimer                    ENUMERATED {ms1, ms2, ms4, ms8, ms16,

                                                    ms32, ms64, ms128}

    sr-TransMax                         ENUMERATED {n4, n8, n16, n32, n64,

                                                    spare3, spare2, spare1}

}

 

- The IE "SchedulingRequestId" is used to identify a Scheduling Request instance in the MAC layer.

 

 SchedulingRequestId ::= INTEGER (0..7)

 

 

Each SR configuration corresponds to one or more logical channels. Each logical channel may be mapped to zero or one SR configuration, which is configured by RRC. 

 RRC configures the following parameters for the scheduling request procedure:  

- sr-ProhibitTimer (per SR configuration);  

- sr-TransMax (per SR configuration).

 

 SR will NOT be transmitted if:

1. SR opportunity falls in measurement gap interval or
2. another SR-Prohibit timer is running or
3. DL PDCCH with UL resources is received.
   

5G(NR): MAC Control Elements

 MAC Control Elements:

- As we know that RRC and NAS messages functions are used to exchange the signalings between UE and gNodeB, But there are several communication path at MAC layer. so there are special MAC structures that carries special control information. These special MAC structure carrying the control information is called 'MAC CE', which means 'MAC Control Element'.

-

 -MAC CE works between UE(MAC) and gNodeB(MAC) for FAST Signaling Communication Exchange without  involving upper layers. 

- It is sent as a part of MAC PDU. It  always placed before any MAC SDUs.  LCID field denotes MAC CE Types.

There are several Type of MAC-CE, MAC CE List specified in 38.321 v15.3:

 

 

LCID VALUES FOR DL-SCH 

 LCID values for UL-SCH channel.

 

 

MAC-CE and reference:

 

MAC CE	Reference
Buffer Status Report	38.321 - 6.1.3.1
C-RNTI	38.321 - 6.1.3.2
UE Contention Resolution Identity	38.321 - 6.1.3.3
Timing Advance Command	38.321 - 6.1.3.4
DRX Command	38.321 - 6.1.3.5
Long DRX Command	38.321 - 6.1.3.6
Configured Grant Confirmation	38.321 - 6.1.3.7
Single Entry PHR	38.321 - 6.1.3.8
Multiple Entry PHR	38.321 - 6.1.3.9
SCell Activation/Deactivation	38.321 - 6.1.3.10
Duplication Activation/Deactivation	38.321 - 6.1.3.11
SP CSI-RS / CSI-IM Resource Set Activation/Deactivation MAC CE	38.321 - 6.1.3.12
Aperiodic CSI Trigger State Subselection MAC CE	38.321 - 6.1.3.13
TCI States Activation/Deactivation for UE-specific PDSCH MAC CE	38.321 - 6.1.3.14
TCI State Indication for UE-specific PDCCH MAC CE	38.321 - 6.1.3.15
SP CSI reporting on PUCCH Activation/Deactivation MAC CE	38.321 - 6.1.3.16
SP SRS Activation/Deactivation MAC CE	38.321 - 6.1.3.17
PUCCH spatial relation Activation/Deactivation MAC CE	38.321 - 6.1.3.18
SP ZP CSI-RS Resource Set Activation/Deactivation MAC CE	38.321 - 6.1.3.19
Recommended bit rate MAC CE	38.321 - 6.1.3.20

 

 

 

MAC CE Header:

- below are the MAC Control Elements of Buffer Status Report:

1- Short BSR and Truncated BSR format :

2- Long BSR format: 

Format of C-RNTI MAC Control Element: 

C-RNTI MAC control element fields

UE Contention Resolution Identity MAC Control Element :

UE Contention Resolution Identity MAC control element IEs

- it has fixed 48-bit size

- UE Contentions Resolution Identity: This field contains uplink CCCH SDU.

3C : MAC subheader - Contention Resolution:

R = 0

R = 0

E = 1

LCID = 11100 = Contention Resolution.

Timing Advanse Command MAC Control Element :

Timing Advance Command MAC control element

1- Timing Advance Command is of 6 bits in length. T_A (0, 1, 2… 63). 
Power Headroom MAC Control Element : 

Power Headroom MAC control element

Activation/De-activation MAC Control Element : 

- The C_i field is set to '0' to indicate that the SCell with SCellIndex i shall be de-activated.

Activation/De-activation MAC control elements

Padding MAC Sub-Header:

1F : MAC subheader - Padding

R = 0

R = 0

E = 0

LCID = 11111 = Padding

5G-NR: Bandwidth Part (BWP)

Introduction:

            A Bandwidth Part is a set of contiguous Common Resource Blocks. A Bandwidth Part may include all Common Resource Blocks within the channel bandwidth, or a subset of Common Resource Blocks

=>    Bandwidth Parts are an important aspect of 5G because they can be used to provide services to UE which do not support the full channel bandwidth, i.e. the Base Station and UE channel bandwidth capabilities do not need to match.

      ->For example, a Base Station could be configured with a 400 MHz channel bandwidth, while a UE may only support a 200 MHz channel bandwidth. In this case, the UE can be configured with a 200 MHz Bandwidth Part and can then receive services using a subset of the total channel bandwidth.

=> A UE can be configured with up to 4 downlink Bandwidth Parts per carrier and up to 4 uplink Bandwidth Parts per carrier. Only a single Bandwidth Part per carrier can be active in each direction. A UE receives the PDCCH and POSCH only within an active downlink Bandwidth Part. A UE transmits the PUCCH and PUSCH only within an active uplink Bandwidth Part. A UE can complete measurements outside the active bandwidth part but this can require the use of Measurement Gaps.

     Below Figure illustrates some example Bandwidth Part allocations for an operator using 2 x 400 MHz RF carriers. These examples illustrate the flexibility which Bandwidth Parts allow when configuring frequency domain resources.

=> the first UE is assumed to support the complete 400 MHz channel bandwidth and inter-band Carrier Aggregation

=> the second UE is assumed to support inter-band Carrier Aggregation but a maximum channel bandwidth of200 MHz

=> the third UE is assumed to support both inter and intra-band Carrier Aggregation with a maximum channel bandwidth of200 MHz. This combination allows the UE to use all 800 MHz of spcctrum simultaneously, i.e. a single active Bandwidth Part per Component Carrier.

=> the fourth VE is also assumed to support both inter and intra-band Carrier Aggregation. However, this UE is assumed to support a maximum channel bandwidth of 100 MHz and is configured with multiple Bandwidth Parts per Component Carrier

=> the fifth UE is assumed to support only one of the two operating bands and a maximum channel bandwidth of200 MHz. For the purposes of this example, the UE is allocated only a single Bandwidth Part to illustrate that the set of allocated Bandwidth Parts do not have to cover the complete channel bandwidth.

UE 1 configured with:

2 Camponent Carriers (inter-band Carrier Aggregation). 

Single Bandwidth Part per Carrier

 UE 2 configured with:

2 Component Carriers (inter-bond Carrier Aggregation)

2 Bandwidth Parts per Carrier

UE 3 configured with:

4 Campanent Carriers (intra & inter-band Carrier Aggregation)

Single Bandwidth Parts per Carrier

UE 4 configured with:

4 Camponent Carriers (intra & inter-band Carrier Aggregation)

Up to 4 Bandwidth Parts per Carrier

UE 5 configured with:

1 Component Carrier

1 Bandwidth Part

In above Figure, the second and third UE appear to have very similar configurations, i.e. both UE arc configured with 2 x 200 MHz Bandwidth Parts within each operating band. The second UE is configured with 2 Component Carriers and 2 Bandwidth Parts per carrier, whereas the third UE is configured with 4 Component Carriers and I Bandwidth Part per Carrier. This difference in configuration has implications upon some lower level procedures and also the RF performance requirements.

=> at the MAC layer there is a HARQ entity for each serving ce:11. The second UE which is configured with 2 Component Carriers would have 2 HARQ entities and HARQ re-transmissions can be switched between Bandwidth Parts by dynamically changing the active Bandwidth Part (field within the PDCCH DC] can be used to change the active Bandwidth Part). The third lJE which is configured with 4 Component Carriers would have 4 HARQ entities and HARQ re-transmissions cannot be switched between Component Carriers.

=> RF performance requirements such as out-of-band emissions are specified per carrier rather than per Bandwidth Part. This means that the second UE has to achieve its RF requirements at the edge of each 400 MHz carrier, while the third UE has to achieve its

RF requirements at the edge of each 200 MHz carrier.

BWP Types:

    A UE uses an 'Initial' Bandwidth Part when first accessing a cell. The Initial Downlink Bandwidth Part can be signalled within SIB-1 using the inilia/DownlinkBWP parameter structure presented in below table. This parameter structure uses the  locationAndBandwidth information element to specify the set of contiguous Common Resource Blocks belonging to the Initial Downlink Bandwidth Part. The value is coded using Resource Indication Value (RIV) rules with N size of BWP = 275 (these rules are described in section 3.6.4.2.2 within the context of allocating Resource Blocks for the POSCH). The RB start value which is derived from the locationAndBandwidth value is

added to the offsetToCarrier value  i.e. the starting position of the Bandwidth Part is relative to the first usable Resource Block. The initia/DownlinkBWP parameter structure also specifics the subcarrier spacing to be used for the Bandwidth Part and provides the UE with cell level information for receiving the PDCCH and PDSCH.

The initial Downlink BWP parameter structure can also be provided to the UE using dedicated signalling. If the parameter structure is not provided to a UE then the Initial Downlink Bandwidth Part is defined by the set of Rcsource Blocks belonging to the Control

Resource Set (CORESET) for the Type O PDCCH Common Search Space. These Resource Blocks can be deduced from information within the MIB.

Information regarding the Initial Uplink Bandwidth Part can also be signalled within SIB-1 or by using dedicated signalling.

The Base Station can use dedicated signalling to configure up to 4 Downlink Bandwidth Parts per cell and up to 4 Uplink Bandwidth Parts per cell. The parameter structure used to configure a Downlink Bandwidth Part. The Initial Bandwidth Part is referenced using an identity of 0, whereas other Bandwidth Parts are allocated an identity within the range 1 to 4

=> In the case of TDD, an Uplink and Downlink Bandwidth Part with the same bwp-ld share the same center frequency

=> The Base Station can dynamically switch the Active Bandwidth Part using the Bandwidth Part Indicator field within DCI Formats 0 and 1_1. The switching procedure is not instantaneous so the Base Station cannot allocate resources immediately after changing the Active Bandwidth Part. The switching delay is specified within 3GPP TS 38.133.

=> A UE can also be configured with a Default Downlink Bandwidth Part (identified using defaultDownlinkB WP-Id which points to one of the configured hwp-id values). If a UE is not explicitly provided with a Default Downlink Bandwidth Part then it is assumed to be

the Initial Downlink Bandwidth Part.

=> If a UE is configured with a bwp-lnactivityTimer then the UE switches back to the Default Downlink Bandwidth part after the inactivity timer has expired while using a non-Default Downlink Bandwidth Part.

5G-NR: UPLINK RESOURCE REQUEST

5G-NR: UPLINK RESOURCE REQUEST:

Introduction:

              The Base Station packet scheduler is responsible for allocating resources to transfer uplink data. In some cases, it is not necessary for the UE to request those resources:

   The Base Station may allocate resources in a proactive manner, i.e. provide the UE with capacity on the PUSCH before it is actually requested. This approach helps to reduce latency because the UE is able to transmit uplink data without having to request resources and subsequently wait for those resources to be allocated. Proactive scheduling is generally applicable to cells which are not heavily loaded. Cells transferring a lot of data may not have sufficient capacity to allocate resources which may not be required, i.e. proactive scheduling grants arc typically given low priority by the packet scheduler. 

   The Base Station may provide the UE with 'Configured Grants' lo allow uplink retansmission on the PUSCH without having to receive individual resource allocations on the PDCCH. A UE configured in this way is not free to transmit on any Resource Block

at any time, but is configured to allow periodic transmission on a specific set of Resource Blocks. This type of resource allocation is also known as 'Grant Free' resource allocation and is analogous to Sem-Persistent Scheduling (SPS) in the downlink.

UE can request uplink resources using the following mechanisms:

1- Scheduling Request 

2- Buffer Status Reporting

3- Random Access procedure 

1- Scheduling Request:

              A UE uses the Scheduling Request (SR) procedure as a mechanism to request air-interface resources for a new uplink transmission.

=> Below figure illustrates the sequence of events associated with the transmission of a Scheduling Request. Uplink data belonging to a specific Logical Channel is queued for transmission within the UE buffer. This uplink data triggers the UE to send a Scheduling

Request using PUCCH resources which have been configured specifically for the Logical Channel which has the uplink data ready for transmission. The Base Station receives the Scheduling Request and is able to deduce the Logical Channel (or group of Logical

Channels if multiple Logical Channels have been linked to the same set of PUCCH resources). Knowledge of the Logical Channel helps the Base Station to priorities the Scheduling Request.

=>The Base Station then proceeds to allocate uplink resources on the PUSCH using a PDCCH transmission. The UE uses those resources to send a Buffer Status Report (BSR) in combination with at least some of the buffered data. The Buffer Status Report provides the Base Station with information regarding the volume of data waiting to be transferred. Alternatively, if the UE buffer can be emptied using the initial uplink resource allocation, the UE can exclude the Buffer Status Report and send only the uplink data.

=> Once a Scheduling Request has been triggered, it is categorized as 'pending' until it is 'cancelled', i.e. a Scheduling Request remain categorized as 'pending' after it has been transmitted. A Scheduling Request is 'cancelled' after the UE has received an uplink resource allocation and has sent a Buffer Status Report, or after the UE has received an uplink resource allocation and has been able to empty its transmission buffers.

=> Scheduling Requests are sent using the PUCCH physical channel. All PUCCH Formats can accommodate a Scheduling Request, i.e. Formats 0, I, 2, 3 and 4.  Scheduling Request resources arc always configured using either PUCCH Format 0 or PUCCH Format 1.  Other PUCCH formats can be used when PUCCH transmissions coincide, e.g. a Scheduling request transmission using PUCCH Format 0 coincides with a CSI Reporting transmission using PUCCH Format 3. In that case, both the Scheduling Request and CSI Report can be transferred using PlJCCH Format 3.

=> A UE is not free to transmit a Scheduling Request at any instant in time. Instead, the Base Station provides the UE with timing information which defines the time instants that a UE is permitted to transmit a Scheduling Request. This timing information includes

the SR-periodicity and SR-offset.

=> The SchedulingRequestResourceConjig parameter structure which configures both the SR-periodicity and SR-offset using the periodicityAndOffset information clement.

RRC Parameters:

=> The schedulingRequestld represents a pointer towards an additional set of parameters associated with the Scheduling Request resources.

= > sr-ProhibitTimer defines the minimum time between consecutive scheduling

Requests, i.e. this timer is started after sending a Scheduling Request and the UE must wait for this timer to expire before sending another Scheduling Request

=>  sr-TransMax specifies the maximum number of Scheduling Requests which can be sent to the Base Station. If the number of Scheduling Requests reaches this upper limit before receiving an uplink resource allocation, the UE releases its PUCCH and SRS resources and initiates the random access procedure.

https://www.5gfundamental.com/2021/02/5gnr-scheduling-request.html

2- Buffer Status Reporting:

               AUE uses Buffer Status Reporting (BSR) to provide the Base Station within information regarding the volume of uplink data waiting to be transferred. Buffer Status Reports are sent on the PUSCH using a MAC Control Element. The provision of a Buffer Status Report helps the Base Station to allocate an appropriate quantity of air-interface resources .

=> Both the PDCP and RLC layers provide the MAC layer with data volume figures so the UE is able lo signal the total buffered data volume to the Base Station.

=>Buffer Status Reports are sent per 'Logical Channel Group' (LCG) rather than per 'Logical Channel' (although it is possible for an LCG to include only a single Logical Channel). In general, Logical Channels with similar priority are linked to the same LCG. This allows the Base Station to differentiate between the volume of high priority data and the volume of lower priority data.

There are three categories of triggering mechanism for Buffer Status Reports (BSR):

1- Regular BSR triggering is applicable if:

->  new uplink data becomes available for transmission, and that uplink data belongs to a Logical Channel which has higher priority than the Logical Channels associated with the previously available uplink data.

-> new uplink data becomes available for transmission after having no uplink data  

available for transmission the retxBSR-Timer expires when there is uplink data waiting to be transferred.

-> The retxBSR-Timer has been specified to help avoid the deadlock situation which occurs when the Base Station fails to receive a Buffer Status Report while the UE believes

that reception has been successful, i.e. the UE fails to receive the request for a re-transmission. In this situation the UE waits for an uplink resource allocation but the Base Station does not provide any resources because it failed to receive the Buffer Status Report. The retxBSR-Timer helps to resolve the situation by triggering a re-transmission of the report.

2-Periodic BSR triggering is applicable if:

    the periodicBSR-Timer expires. This timer can be set to 'infinity' so periodic Buffer Status Reports are optional. The periodic timer is re-started after each Buffer Status Report transmission unless the 'truncated' report format is used.

3-Padding BSR triggering is applicable if:

    uplink resources have been allocated such that the number of padding bits equals or exceeds the size ofa Buffer Status Report. In this case, a Buffer Status Report is included within the uplink packet to reduce the quantity of padding, i.e. taking advantage of the unused uplink capacity.

= > Four formats have been specified for the Buffer Status Report:

 1- Short BSR,

 2- Short Truncated BSR,

 3- Long BSR and 

 4- Long Truncated BSR.

=>If the BSR is triggered using either the Regular or Periodic mechanisms then either a Long or Short BSR is generated. The Long BSR is designed to accommodate information regarding multiple LCG so this format is generated if more than a single LCG has uplink data to transfer. Otherwise, a Short BSR is generated to provide information regarding a single LCG.

=>Tfthe BSR is triggered using the Padding mechanism then the BSR format depends upon the quantity of padding which is available to accommodate the BSR. It is assumed that the quantity of padding is always at least as large as a Short BSR otherwise the Padding BSR

would not have been triggered. If there is sufficient padding to accommodate a Long BSR then a Long BSR is generated. Otherwise, if only a single LCG has data to transfer then a Short BSR is generated. Otherwise, if multiple LCG have data to transfer but the size of

the padding can only accommodate a Short BSR then Short Truncated BSR is generated for the LCG with the highest priority Logical Channel. Otherwise, a Long Truncated BSR is generated for the LCG with the highest priority Logical Channels.

=> The MAC Control Elements have the same format and have a fixed size. The actual payload of the MAC Control Element is I Byte. J\n additional I Byte subheader is included to identify the payload of the MAC Control Element. 

An LC ID value of 61 is used to identify a Short BSR, whereas an LCID value of 59 is used to identify a Short Truncated BSR (LCID stands for Logical Channel Identity but within this context it is used to identify a MAC CE rather than a Logical Channel)




=> The size and structure of a Short and Short Truncated BSR are the same. The only difference is that the Short BSR provides information when only a single LCG has data to transfer, whereas the Short Truncated LCG provides information regarding the LCG which includes the highest priority Logical Channel when multiple LCG have data to transfer.

=> The 5 bits used to quantify the Buffer Size. The values within this table have units of Bytes.

5G-NR: SIGNALLING RADIO BEARERS:

5G-NR: SIGNALLING RADIO BEARERS:

Indroduction:

          The eNodeB is the Master Node so the majority of RRC signalling procedures terminate at the eNodeB rather than the gNodeB. Signalling Radio Bearer-0 (SRB0), SRB 1 and SRB2 terminate at the eNodeB. This means that the 4G RRC signalling protocol

specified in 3GPP TS 36.331 is applicable. SRB-I and SRB2 ,can be configured as 'split' SRB. This allows RRC messages to be transmitted and received by both the eNodeB and gNodeB.

      SRB3 can be setup at the request of the 5G Secondary Node. SRB3 terminates al the Secondary Node (gNode B) and so the 5G RRCsignalling protocol specified in 3GPP TS 38.331 is applicable. SRB3 is used for signalling procedures which are time sensitive with

respect to the gNode B, e.g. mobility procedures. SRB3 supports a limited number of signalling messages, i.e. RRC Reconjiguration, RRC Reconfiguration Complete and Measurement Report messages. 

SIGNALLING RADIO BEARERS:

=> The RRC signalling protocol operates between the UE and Base Station.

=> The Non Access Stratum (NAS) signalling protocol operates between the UE and AMF/SMF 5G NR in BULLETS.

=> Signalling Radio Bearers (SRB) are used to transfer RRC messages between the UE and Base Station. RRC messages can encapsulate NAS messages so SRB are also responsible for transferring NAS messages between the UE and Base Station. The NG Application
Protocol (NGAP) is used to transfer NAS messages between the Hase Station and AMF. NAS messages associated with Session Management terminate at the SMF rather than the AMF. The AMF acts a relay between the Base Station and SMF for Session Management NAS messages

=> below figure illustrates the protocol stacks used for both RRC and NAS signalling. The set of SRB provide a logical connection between the RRC layers within the UE and Base Station.

3GPP has specified 4 types ofSRB for New Radio (NR):

=> SRB-0 transfers RRC messages which use the Common Control Channel (CCCH) logical channel.

=>SRR-1, 2 and 3 transfer RRC messages which use the Dedicated Control Channel (DCCI-I) logical channel

=> SRB-1 supports RRC signalling between the UE and Base Station but can also encapsulate NAS messages prior to the setup of SRB2.

=> SRB-2 is always setup after security activation and is used to encapsulate NAS messages. SRB 2 messages arc handled with lower priority relative to SRB-1 messages.

=> SRB-3 is applicable when using the 'E-UTRAN New Radio Dual Connectivity' (EN-DC) configuration. In this case, SRIJ 0, 1 and 2 are managed by the E-UTRAN Master Node while SRB 3 is managed by the NR Secondary Node. SRB 3 allows RRC messages

to be transferred directly between the Secondary Node and the UE. SRB 3 is limited to transferring RRC Reconfiguration and Measurement Report messages. These messages arc a subset of those transferred by SRB-1

=> Below figure illustrates the concept of a 'Split SRB' which is applicalblc to SRB-1 and SRB 2 when using a Dual Connectivity configuration. A split SRB means that RRC messages can be transferred using the Master Node air-interface, the Secondary Node airinterface

or both air-interfaces. The use of both air-interfaces helps to improve reliability. The concept is applicable to both the uplink and downlink so the UE can be instructed to transmit uplink RRC messages on both air-interfaces

      Above  is based upon the Non-Standalone EN-DC configuration so SRB 3 is also shown within the Secondary Node. SRB O is only applicable to the Master Node. Splitting SRB I and SRB 2 creates SRB IS and SRB 2S which use the X2 Application Protocol (X2AP) to transfer RRC messages to and from the Secondary Node

The RRC messages associated with each SRB are presented in below Table

SRB-0 uses Transparent Mode (TM) RLC while SRB 1 and 2 use Acknowledged Mode (AM) RLC.

=>SRB-0 transfers messages associated with establishing, re-establishing and resuming a connection. The uplink messages are transmitted as MSG3 within the Random Access procedure, while the downllink messages can be transmitted as MSG4. The VE is allocated a DCCH logical channel once an RRC connection has been established so SR.B 1 and 2 are able to transfer subsequent messages.

=>The RRCResumeRequest message is an exception which has been specified to use the CCCH logical channel rather than the CCCH logical channel. The CCCHI logical channel is intended to transfer larger messages than the CCCH logical channel

=> After security activation, all messages transferred by SRB-I, 2 and 3 arc integrity protected and ciphered by the Packet Data Convergence Protocol (PDCP). In addition, NAS messages use integrity protection and ciphering between the UE and AMF.

=> The Uplink Information Transfer and Downlink Information Transfer messages are dedicated to sending NAS messages and do not include any RRC signalling content. These messages arc transfcned using SRB 2 unless SRB2 has not yet been configured

=> 3GPP References: TS 38.331, TS 37.340

5G Network Architecture

5G Network Architecture:

Introduction:

            In this blog, we will see 5G network architecture nodes, their functionality and interfaces between different nodes. it is vary important to know about all the nodes and their functionality to understand the whole concept of 5G architecture.

Below description is taken from 3gpp TS.

 

In Detailed:

Core network service based architecture:

 

AMF: Access and Mobility Management Function:- 
             Like in LTE MME, In NR AMF provide the similar services to the access network and core network component. general functions of AMF are to provide the mobility management, Authentication management, NAS related management to UE and SMF selection types of services.

=>Termination point for RAN Control Plane interfaces (NG2).

=>UE Authentication and Access Security procedures.

=>Mobility Management (handover Reach-ability, Idle/Active Mode mobility state. handling)

=>Registration Area management.

=>Access Authorization including check of roaming rights; 

=>Session Management Function (SMF) selection

=>NAS(non access stratum) signaling including NAS Ciphering and Integrity protection, termination of MM NAS and forwarding of SM NAS (NG1).

=>AMF obtains information related to MM from UDM.

=>May include the Network Slice Selection Function (NSSF) 

=>Attach procedure without session management adopted in CIoT implemented in EPC is defined also in 5GCN (registration management procedure) 

=>User Plane (UP) selection and termination of NG4 interface (AMF has part of the MME and PGW functionality from EPC.

AUSF: services Authentication Server Function:  The main function of AUSF is to provide the services for Authentication procedure and communicate directly with UDM and AMF for accessing and providing the subscriber information.

=>Contains mainly the EAP authentication server functionality 

=>Storage for Keys (part of HSS from EPC) 

=>Obtains authentication vectors from UDM and achieves UE authentication. 72 NF Repository Function (NRF) 

=>Provides profiles of Network Function (NF) instances and their supported services within the network 

=>Service discovery function, maintains NF profile and available NF instances. (not present in EPC world) NRF offers to other NFs the following services: 

=>Nnrf_NFManagement 

=>Nnrf_NFDiscovery 

=>OAuth2 Authorization Core network functions 73 Core network functions Network Exposure Function (NEF) 

=>Provides security for services or AF accessing 5G Core nodes 

=>Seen as a proxy, or API aggregation point, or translator into the Core Network 

Policy Control Function (PCF) 

=>Expected to have similarities with the existing policy framework (4G PCRF) 

=>Updates to include the addition of 5G standardized mobility based policies (part of the PCRF functionality from EPC) 

Session Management Function (SMF) :

=>DHCP functions 

=>Termination of NAS signaling related to session management 

=>Sending QoS/policy N2 information to the Access Network (AN) via AMF
=>Session Management information obtained from UDM 

=>DL data notification 

=>Selection and control of UP function 

=>Control part of policy enforcement and QoS. 

=>UE IP address allocation & management 

=>Policy and Offline/Online charging interface termination 

=>Policy enforcement control part 

=>Lawful intercept (CP and interface to LI System) Core network functions.

Unified Data Management (UDM) :

=>Similar functionality as the HSS in Release 14 EPC User Data Convergence (UDC) concept: separates user information storage and management from the front end 

=>User Data Repository (UDR): storing and managing subscriber information processing and network policies 

=>The front-end section: Authentication Server Function (AUSF) for authentication processing and Policy Control Function (PCF). Core network functions 

User Plane Function (UPF) :

=>Allows for numerous configurations which essential for latency reduction
=>Anchor point for Intra-/Inter-RAT mobility 

=>Packet routing and forwarding 

=>QoS handling for User Plane 

=>Packet inspection and PCC rule enforcement 

=>Lawful intercept (UP Collection) 

 Roaming interface (UP)

=>May integrate the FW and Network Address Translation (NAT) functions 
=>Traffic counting and reporting (UPF includes SGW and PGW functionalities) 

Application Functions (AF) 

=>Services considered to be trusted by the operator

=>Can access Network Functions directly or via the NEF 

=>AF can use the PCF interface PCF for requesting a given QoS applied to an IP data flow (e.g., VoIP). 

=>Un-trusted or third-party AFs would access the Network Functions through the NEF (same as AF in EPC) Network Slice Selection Functions (NSSF) 

=>Selecting of the Network Slice instances to a UE.

=>Determining the AMF set to be used to serve the UE.

=>The Application Function (AF) can be a mutually authenticated third party. – Could be a specific 3rd party with a direct http2 interface or a inter-working gateway exposing alternative API’s to external applications. 

=>Enables applications to directly control Policy (reserve network resource, enforce SLAs), create network Slices, learn device capabilities and adapt service accordingly, invoke other VNF’s within the network… 

=>Can also subscribe to events and have direct understanding of how the network behaves in relation to the service delivered.

 Data Network (DN):

=> Services offered: Operator services, Internet access, 3rd party