LTE: Downlink Resource Allocation Type 1


Resource Allocation Type 1 uses the same number of RA bits as in Resource Allocation Type 0 but allows Resource Allocation on an individual RB level even for larger bandwidths.

The Resource Allocation Information consists of NRBG bits which will indicate the UE about a set of VRBs (Localized Type) from one of the P RBG subsets. The number of RBG subsets (P) is same as RBG size (P) in RA Type 0 which is as given below:


In an RBG subset number p, where 0 ≤ p < P, it is possible to allocate every Pth RB starting from pth RB and this allocation can be done using a bitmap.

A total of NRBDL­­/Pbits are required for resource allocation as in RA Type 0. Resource Block assignment consists of 3 fields.

The First field with log2 (P) bits used to indicate the selected RBG subset number among P RBG subsets.

The second field with one bit is used to indicate a shift of the resource allocation span within a subset. A bit value of 1 indicates shift is triggered. Shift is not triggered otherwise

The third field indicates a bitmap, where each bit of the bitmap addresses a single VRB in the selected RBG subset. The VRB is allocated to the UE if the corresponding bit value in the bit field is 1, the VRB is not allocated to the UE otherwise. The portion of the bitmap used to address VRBs in a selected RBG subset has size NRBTYPE1 and is defined as:
NRBTYPE1 = NRBDL­­/P⏋— ⎾log2 (P)⏋ — 1


The addressable VRB numbers of a selected RBG subset start from an offset, shift(p)   to the smallest VRB number within the selected RBG subset, which is mapped to the MSB of the bitmap. The offset is in terms of the number of VRBs and is done within the selected RBG subset. If the value of the bit in the second field for shift of the resource allocation span is set to 0, the offset for RBG subset p is given by shift(p) = 0. Otherwise, the offset for RBG subset p is given by shift(p) = NRBRBGsubset(p) — NRBType1, where the LSB of the bitmap is justified with the highest VRB number within the selected RBG subset. NRBRBGsubset(p) is the number of VRBs in RBG subset p and can be calculated by the following equation,



Consequently, when RBG subset p is indicated, bit i for i = 0, 1, …, NRBType1 — 1 in the bitmap field indicates VRB number


Example:
Let us consider NRBDL = 15. From the above table, number of RBG subsets (P) is 2. In this case, 1-bit (log2 (2)) is required to indicate the RBG subset number. One more bit is used to indicate whether a shift is used or not.  NRBTYPE1 = 8-1-1 = 6 bits are used for actual resource allocation bitmap. The resource allocation is illustrated below: 


Let the resource allocation bits are 00110011. MSB indicates RBG subset number, second bit indicates if shift is enabled or not. Remaining 6 bits indicate the bitmap of resource allocation of PRBs. In this case, RBG subset 0 is chosen without a shift. Using the remaining 6 bits 110011, RB numbers 0, 1, 8, and 9 are allocated to the UE. Similarly, if resource allocation bits are 11110011 RB numbers 3, 6, 11, and 14 are allocated to the UE.

Reference: 3GPP TS 36.213

LTE: Downlink Resource Allocation Type 2 and Uplink Resource Allocation Type 0


This type of resource allocation is mainly used for contiguous RB allocations for uplink (RA Type0) and for compact scheduling of downlink assignments (RA Type 2).

In this type, the resource block assignment information indicates to a scheduled UE a set of contiguously allocated localized VRBs or distributed VRBs.

In case of resource allocation signaled with PDCCH DCI format 1A, 1B or 1D, one bit flag indicates whether localized VRBs or distributed VRBs are assigned (value 0 indicates Localized and value 1 indicates Distributed VRB assignment) . In the case of resource allocation signaled with PDCCH DCI format 1C, only distributed VRBs are assigned.

Localized VRB allocations for a UE vary from a single VRB up to a maximum number of VRBs spanning the system bandwidth.

For indicating contiguous RB assignment, starting position of the RB (RBstart) and the number of RBs is required. Let us consider RBstart = 0th RB, the number of combinations possible = NRB. Similarly when RBstart = 1st RB, then the number of possible combinations are NRB – 1 and so on. There are NRB.(NRB + 1)/2 combinations possible in total.

For downlink, PDCCH DCI format 1A, 1B or 1D, a type 2 resource allocation field consists of a Resource Indication Value (RIV) corresponding to a starting resource block (RBstart) and a length in terms of virtually contiguously allocated resource blocks LCRBs.

For uplink, a resource allocation (type 0) field in the scheduling grant consists of a resource indication value (RIV) corresponding to an RBstart and a length in terms of contiguously allocated physical resource blocks (LCRBs ≥ 1). The RIV value for both uplink and downlink is defined by:

        RIV = NRB (LCRBs — 1) + RBstart                                            if (LCRBs — 1) ≤ NRB /2
                = NRB (NRB — LCRBs + 1) + (NRB — 1 — RBstart)         otherwise


Example:
Let us consider NRB = 6 NRB.(NRB + 1)/2 = 21  5-bits are required for indicating any RIV value ranging from 0 to 20. The RIV values for NRB = 6 are illustrated below. Let RBstart = 2 and LCRBs = 3, from the above equations RIV = 14



Reference: 3GPP TS 36.213

LTE: Downlink Resource Allocation Type 0


In Resource Allocation Type 0, Resource Block assignment information includes a bitmap indicating a set of Resource Block Groups (RBGs) to the scheduled UE. An RBG is a set of consecutive PRBs. 

In RA Type 0, the signaling overhead is reduced since the bitmap is defined on a group of RBs. The size of RBG (P) is a function of system bandwidth as shown in the table below:


The total number of RBGs (NRBG) for downlink system bandwidth NRBDL­­ is given by NRBG = NRBDL­­/Pwhere NRBDL­­/Pof the RBGs are of size P and if NRBDL­­ mod P  > 0 then 
one of the RBGs is of  size NRBDL­­ –  P.NRBDL­­/P.  

The bitmap is of size NRBG bits with one bitmap bit per RBG such that each RBG is addressable

An RBG is allocated to the UE if the corresponding bit value in the bitmap is 1, the RBG is not allocated to the UE otherwise

From the above table it could be noted that for smaller bandwidths (NRBDL ≤ 10) the value of P = 1 (RBG size = 1) which means that each RB can be addressed with a bit in the bitmap.

The RBG size (P) is increased with system bandwidth as smaller values of P would require more number of bits to address the entire bandwidth

Example:
Let us consider NRBDL = 15. From the above table, P = 2, so total number of RBGs NRBG = 8 out of which 7 RBGs are of size 2 RBs and one RBG is of size 1 RB. The total number of bits required for resource allocation is equal to NRBG which is 8 in this case. The bitmap is done as shown in the below:



In this example if the resource allocation information is 11000001, this means RBGs 1, 2 and 8 (5 RBs in total) are allocated and the remaining RBGs are not allocated to the UE.


Reference: 3PGP TS 36.213

LTE: Resource Allocation

The information on which Resource Blocks (RBs) are allocated (Resource Allocation) for both Uplink and Downlink needs to be signalled to the UE.

The Resource Allocation information is carried on Downlink Control Information (DCI) by Physical Downlink Control Channel (PDCCH). Resource Allocation field is one of the major field in the DCI.

In the case of Uplink, the allocated RBs have to be contiguous in order to guarantee single-carrier property (SC-FDMA is used in the Uplink). The contiguous nature of resource allocation requires less number of bits but the scheduler in the eNB will have less flexibility in allocating the resources.
  
In the case of Downlink, the allocated RBs doesn’t need to be contiguous which will require more bits to signal the Resource Allocation but the eNB’s scheduler will have more flexibility in allocating the resources.

In LTE, ResourceAllocation Type 0, Resource Allocation Type 1 and Resource Allocation Type 2 are defined.

Resource Allocation Type 0 and Resource Allocation Type 1 are used for non-contiguous resource allocation (only for Downlink) which uses bit-map based signaling. 

For allocating contiguous resource blocks in the Uplink, Resource Allocation Type 0 is used where as same for downlink it is called as Resource Allocation Type 2.

The UE shall interpret the Resource Allocation field depending on the PDCCH DCI Format detected. 

For Uplink, Resource Allocation information is conveyed on PDCCH DCI Format 0 using Resource Allocation Type 0.

In the Downlink, PDCCH DCI Formats 1, 2, 2A and 2B uses Resource Allocation Type 0 or Type 1  whereas PDCCH DCI Formats 1A, 1B, 1C and 1D uses Resource Allocation Type 2

Click here for Resource Allocation Type 0 in the Downlink. Check here for Downlink Resource Allocation Type 1. 

Uplink Type 0 and Downlink Type 2 are explained in post 'Downlink Resource Allocation Type2 and Uplink Resource Allocation Type0'.

Reference: 3GPP TS 36.213

LTE: ESM Information Request Procedure

·        The ESM information request procedure is used by the network to retrieve ESM information, i.e. protocol configuration options, APN, or both from the UE during the attach procedure if the UE has indicated (in the PDN CONNECTIVITY REQUEST) that it has ESM information that needs to be sent security protected.
·        The purpose of this procedure is to provide privacy for the ESM information if ciphering is enabled in the network.
·        The network initiates the ESM information request procedure by sending a ESM INFORMATION REQUEST message to the UE and starts the timer T3489.
·        This message shall be sent only after the security context has been setup, and if the ESM information transfer flag has been set in the PDN CONNECTIVITY REQUEST message.
·        The MME shall set the EPS bearer identity of the ESM INFORMATION REQUEST message to the value "no EPS bearer identity assigned" and include the PTI from the associated PDN CONNECTIVITY REQUEST message.
·        After receiving the ESM INFORMATION REQUEST message, the UE shall send an ESM INFORMATION RESPONSE message to the network.
·        The UE shall include all the protocol configuration options that need to be transferred security protected, and APN if required, to the network in the ESM INFORMATION RESPONSE (see the example below)message.
·        The UE shall set the EPS bearer identity of the ESM INFORMATION RESPONSE message to the value "no EPS bearer identity assigned" and include the PTI from the ESM INFORMATION REQUEST message

Reference 3GPP TS 24.301

Example:   ESM INFORMATION REQUEST message

Example:   ESM INFORMATION RESPONSE message  


LTE: Modify EPS Bearer Context Reject

·        If the MODIFY EPS BEARER CONTEXT REQUEST message cannot be accepted by the UE, then it sends a MODIFY EPS BEARER CONTEXT REJECT message to the MME.
·        This message shall include the EPS bearer identity and an ESM cause value indicating the reason for rejecting the EPS bearer context modification request
·        The MODIFY EPS BEARER CONTEXT REJECT message contains an ESM cause that typically indicates one of the following ESM cause values:
#26: insufficient resources
#41: semantic error in the TFT operation
#42: syntactical error in the TFT operation
#43: invalid EPS bearer identity
#44: semantic error(s) in packet filter(s)
#45: syntactical error(s) in packet filter(s)
#95 – 111: protocol errors
·        Upon receipt of the MODIFY EPS BEARER CONTEXT REJECT message with ESM cause value other than #43 "invalid EPS bearer identity", the MME shall stop the timer T3486 and abort the EPS bearer context modification procedure.
·        If the network receives the MODIFY EPS BEARER CONTEXT REJECT message with ESM cause #43 "invalid EPS bearer identity" the MME locally deactivates the EPS bearer context(s) without peer-to-peer ESM signalling

Reference 3GPP TS 24.301

Example:  MODIFY EPS BEARER CONTEXT REJECT message

LTE: Modify EPS Bearer Context Request

·        The purpose of the EPS bearer context modification procedure is to modify an EPS bearer context with a specific QoS and TFT.
·        This procedure is initiated by the network, but it may also be initiated as part of the UE requested bearer resource allocation/modification procedure.
·        The network may also initiate the EPS bearer context modification procedure to update the APN-AMBR of the UE, for instance after an inter-system handover
·        The MME initiates the EPS bearer context modification procedure by sending a MODIFY EPS BEARER CONTEXT REQUEST message to the UE and starts the timer T3486
·        The MME shall include an EPS bearer identity that identifies the EPS bearer context to be modified in the MODIFY EPS BEARER CONTEXT REQUEST message
·        If this procedure was initiated by a UE requested bearer resource allocation/modification procedure, then the MODIFY EPS BEARER CONTEXT REQUEST shall contain the PTI value received by the MME in the corresponding request message.
·        The IEs in this message include, EPS bearer identity, PTI, New EPS QoS, TFT, New QoS, Negotiated LLC SAPI, Radio priority, Packet flow ID, APN-AMBR, and Protocol configuration options etc…
·        After receiving the MODIFY EPS BEARER CONTEXT REQUEST message, the UE shall stop timer T3396 if it is running for the APN associated with the PDN connection, check the received TFT before taking it into use and then send a MODIFY EPS BEARER CONTEXT ACCEPT message to the MME

Reference 3GPP TS 24.301

Example:  Modify EPS Bearer Context Request message

LTE: Bearer Resource Modification Reject

·        If the network cannot accept the bearer resource modification requested by the UE, then the MME shall send a BEARER RESOURCE MODIFICATION REJECT message to the UE.
·        The BEARER RESOURCE MODIFICATION REJECT message shall contain the Procedure Transaction Identity (PTI) which should match the PTI value received in the BEARER RESOURCE MODIFICATION REQUEST.
·        Also, this message shall contain an ESM cause value which indicates the reason for rejecting the UE requested bearer resource modification.
·        If the bearer resource modification requested is for an established LIPA PDN connection, then the network shall reply with a BEARER RESOURCE MODIFICATION REJECT message with ESM cause #60 "bearer handling not supported".
·        If the ESM cause value is #26 "insufficient resources", the network may include a value for timer T3396 value IE in this message. In such a case, the UE should take different actions depending on the timer value as specified in section 6.5.4.4 in 3GPP TS 24.301.
·        After receiving the BEARER RESOURCE MODIFICATION REJECT message, the UE shall stop the timer T3481 and release the traffic flow aggregate description associated to the PTI value.
·        If the ESM cause included in the reject message is #43 "invalid EPS bearer identity", the UE locally deactivates the EPS bearer context(s) without peer-to-peer ESM signalling.

Reference 3GPP TS 24.301

Example:  BEARER RESOURCE MODIFICATION REJECT message

LTE: Bearer Resource Modification Request

·        The purpose of the UE requested bearer resource modification procedure is for a UE to request a modification or release of bearer resources for a traffic flow aggregate or modification of a traffic flow aggregate by replacing or adding packet filters.
·        When requesting a modification of bearer resources for a traffic flow aggregate or a modification of a traffic flow aggregate, the UE can modify the existing GBR.
·        If the network accepts this procedure, it invokes a dedicated EPS bearer context activation, an EPS bearer context modification, or an EPS bearer context deactivation procedure.
·        If there is a PDN connection for emergency bearer services established, the UE shall not request a modification of bearer resources for this PDN connection.
·        In order to request the modification of bearer resources for one traffic flow aggregate, the UE shall send a BEARER RESOURCE MODIFICATION REQUEST message to the MME
·        The UE shall include the EPS bearer identity of the EPS bearer associated with the traffic flow aggregate in the EPS bearer identity for packet filter IE.
·        To request a change of the GBR without changing the packet filter(s), the UE shall set the TFT operation code in the Traffic flow aggregate IE to "no TFT operation" and include the packet filter identifier(s) to which the change of the GBR applies in the Packet filter identifier parameter in the parameters list.
·        The UE shall indicate the new GBR requested for the EPS bearer context in the Required traffic flow QoS IE.
·        To request a modification of a traffic flow aggregate, the UE shall set the TFT operation code in the Traffic flow aggregate IE to "Replace packet filters in existing TFT" or "Add packet filters to existing TFT".
·        If the TFT operation code is set to "Add packet filters to existing TFT", the UE shall include the existing packet filter identifier(s) to which the newly added packet filter(s) is linked in the parameters list.
·        To request a release of bearer resources, the UE shall set the TFT operation code in the Traffic flow aggregate IE to "Delete packet filters from existing TFT".
·     If the UE includes the Required Traffic Flow QoS IE, the UE shall set the QCI to the current QCI value of the EPS bearer context.
·        If the bearer resource modification requested is accepted by the network, the MME shall send ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST, MODIFY EPS BEARER CONTEXT REQUEST or DEACTIVATE EPS BEARER CONTEXT REQUEST message with a PTI which matches the value used for the BEARER RESOURCE MODIFICATION REQUEST message.
·        If the bearer resource modification requested cannot be accepted by the network, the MME shall send a BEARER RESOURCE MODIFICATION REJECT message to the UE.

Reference 3GPP TS 24.301

Example:  BEARER RESOURCE MODIFICATION REQUEST message

LTE: Bearer Resource Allocation Reject

·        If the bearer resource allocation request cannot be accepted by the network, then the MME sends a BEARER RESOURCE ALLOCATION REJECT message to the UE.
·        The BEARER RESOURCE ALLOCATION REJECT message shall contain the Procedure Transaction Identity (PTI) which is equal to the PTI value in the BEARER RESOURCE ALLOCATION REQUEST received from the UE
·        This message shall also contain an ESM Cause value indicating the reason for rejecting the UE requested bearer resource allocation.
·        The UE, after receiving the BEARER RESOURCE ALLOCATION REJECT message, shall stop the timer T3480 and release the traffic flow aggregate description associated to the received PTI value
·        If the ESM cause value is #26 "insufficient resources", the network may include a value for timer T3396 value IE in the BEARER RESOURCE ALLOCATION REJECT message. Depending on the timer value, the UE shall take different actions as explained in 6.5.3.4 in 3GPP TS 24.301

Reference 3GPP TS 24.301

Example:  BEARER RESOURCE ALLOCATION REJECT message

LTE: Bearer Resource Allocation Request

·       The purpose of the UE requested bearer resource allocation procedure is (for an UE) to request an allocation of bearer resources for a traffic flow aggregate.
·        The UE requests a specific QoS demand (QCI) and optionally sends a Guaranteed Bit Rate (GBR) requirement for a new traffic flow aggregate.
·        If accepted by the network, this procedure invokes a dedicated EPS bearer context activation procedure or an EPS bearer context modification procedure.
·        If there is a PDN connection for emergency bearer services established, the UE shall not request additional bearer resources for this PDN connection.
·        The UE initiates this procedure by sending a BEARER RESOURCE ALLOCATION REQUEST message to the MME and starts the timer T3480.
·        The UE shall include the IE Linked EPS bearer identity and set it as the EPS bearer identity of the default EPS bearer associated with the requested bearer resource.
·        The UE shall set the TFT operation code in the Traffic flow aggregate IE to "Create new TFT".
·        In the Required traffic flow QoS IE, the UE shall indicate a QCI (QoS Class Identifier) and, if the UE also includes a GBR, the additional GBR required for the traffic flow aggregate.
·        If the bearer resource allocation request is accepted by the network, the MME shall send either an ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST or MODIFY EPS BEARER CONTEXT REQUEST message with a PTI value received in the BEARER RESOURCE ALLOCATION REQUEST message.
·        If the UE doesn’t receive response to the BEARER RESOURCE ALLOCATION REQUEST message before the expiry of the timer T3480, the UE shall resend this message and reset/restart T3480. This retransmission is repeated four times, i.e. on the fifth expiry of T3480, the UE shall abort the procedure, release the PTI allocated for this activation.
·        The Protocol Configuration Options IE is included in the BEARER RESOURCE ALLOCATION REQUEST message if the UE wishes to transmit (protocol) data (e.g. configuration parameters, error codes or messages/events) to the network.
·        The UE shall include the IE Device Properties in this message if the UE is configured for NAS signalling low priority

Reference 3GPP TS 24.301

Example:  BEARER RESOURCE ALLOCATION REQUEST message

LTE: Deactivate EPS Bearer Context Accept

·       The UE after receiving the DEACTIVATE EPS BEARER CONTEXT REQUEST message, shall delete the EPS bearer context identified by the EPS bearer identity.
·       If the EPS bearer identity indicated in the DEACTIVATE EPS BEARER CONTEXT REQUEST is that of the default bearer to a PDN, the UE shall delete all EPS bearer contexts associated to the PDN.
·       After deactivating the identified EPS bearer context (s), the UE shall respond to the MME with the DEACTIVATE EPS BEARER CONTEXT ACCEPT message.
·        If due to the EPS bearer context deactivation, there is only one PDN connection active and that is for emergency bearer services, then the UE shall consider itself attached for emergency bearer services only
·        In the DEACTIVATE EPS BEARER CONTEXT ACCEPT message, the UE shall include Procedure Transaction Identity (PTI) as received in the DEACTIVATE EPS BEARER CONTEXT REQUEST message
·        Other IEs in the DEACTIVATE EPS BEARER CONTEXT ACCEPT message include, EPS bearer identity and Protocol configuration options

Reference 3GPP TS 24.301

Example:  DEACTIVATE EPS BEARER CONTEXT ACCEPT message

LTE: Deactivate EPS Bearer Context Request

·        The purpose of the EPS bearer context deactivation procedure is to deactivate an EPS bearer context or disconnect from a PDN by deactivating all EPS bearer contexts to that PDN.
·        This procedure is initiated by the network, and it may be triggered by the UE by means of the Bearer Resource Modification or PDN Disconnect procedure.
·        If a NAS signalling connection exists when the MME initiates this procedure, then the MME shall initiate the EPS bearer context deactivation procedure by sending a DEACTIVATE EPS BEARER CONTEXT REQUEST message to the UE and start the timer T3495.
·        If there no NAS signalling connection exists when the MME initiates this procedure, then the ESM entity in the MME shall locally deactivate the EPS bearer context towards the UE without any peer-to-peer ESM signalling between the MME and the UE.
·        The DEACTIVATE EPS BEARER CONTEXT REQUEST message contains an ESM cause typically indicating one of the following:
#8:  operator determined barring
#36: regular deactivation
#38: network failure
#39: reactivation requested or
#112: APN restriction value incompatible with active EPS bearer context
·        If the deactivation is triggered by a UE initiated bearer resource modification or PDN disconnect procedure, the DEACTIVATE EPS BEARER CONTEXT REQUEST message shall contain the PTI value received from the UE in the corresponding message.
·        When the MME wants to deactivate all EPS bearer contexts to a PDN and thus disconnect the UE from the PDN, the MME shall include the EPS Bearer Identity of the default bearer associated to the PDN in the DEACTIVATE EPS BEARER CONTEXT REQUEST message.
·        If the MME doesn’t receive a response for DEACTIVATE EPS BEARER CONTEXT REQUEST before the expiry of the timer T3495, the MME shall resend this message and shall reset and restart T3495. This retransmission is repeated four times, i.e. on the fifth expiry of T3495, the MME shall abort the procedure and deactivate the EPS bearer context locally without any peer-to-peer ESM signalling between the MME and the UE.
·        The IE Protocol Configuration Options is included in the message if the network wishes to transmit (protocol) data (e.g. configuration parameters, error codes or messages/events) to the UE.

Reference 3GPP TS 24.301

Example:  DEACTIVATE EPS BEARER CONTEXT REQUEST message