FANDOM


UM is one the modes supported by RLC. Characteristics of UM are given below

CharacteristicsEdit

Single Direction: The UM opeates in a single direction. i.e, it is connectionless protocol

PDU Length: The UM data PDUs have a set of defined length all of which are integer multiples of octets

Segmentation: The UM can provide segmentation functions, where higher layer SDUs are broken into a number of RLC PDUs

Concatenation: The UM can also provide concatenation functions, where a number of higher layer SDUs are collected together to form a RLC PDU.

Padding: The UM can pad RLC PDUs in the event that there are insufficient data from the higher layer SDUs

Ciphering: The UM can encrypt and decrypt data sent using the UM

Sequence numbers check: The UM entity can check sequence numbers and react according to the UM configuration

Buffering and discard: The UM can provide buffering and discard functions, depending upon its configuration from higher layers

UM EntitiesEdit

Figure showing UM entities is given below

UM Entities

Logical Channels UsedEdit

The RLC UM PDUs are used via a number of logical channels and its purpose are given below

Logical Channel Direction Typical usage
DCCH

UE to UTRAN

Used on the uplink for measurement reports and acknowleding the release of an RRC connection
DTCH UE to UTRAN Used for services where delay is more important than reliability
SHCCH UTRAN to UE Used to notify UEs in the CELL_FACH state that system information is about to change
CCCH UTRAN to UE Used to inform UEs of RRC connection setup information, successful URA/cell update, RRC connection release/ reject
DCCH UTRAN to UE Used for a range of purposes such as RB setup/reconfiguration, active set update, transport channel reconfiguration
DTCH UTRAN to UE Used for same reason as uplink
CTCH UTRAN to UE Common traffic channels on downlink, e.g, cell broadcast information













Segmentation ExplainedEdit

SegmentationExplained

One of the procedures for the UM entity is the segmenting of RLC SDUs and packing UMD PDUs. Above figure gives and example of the operation of the UM entity segmentation and concatenation procedure, in which we assume that the RLC UM entity has told the MAC that there are two RLC SDUs, each of length 40 octets, in the RLC UM entity buffer. For the next TTI, we assume that the MAC (based on priority and other factors) has requested the RLC UM entity to provide three PDUs each of length 27 octets. We also assume that the maximum PDU length at this time is such that a 7-bit lenght indicator can be used in place of the longer, 15-bit, length indicator

The first UMD PDU is completely filled with the first 26 octets of the first RLC SDU. In addition, a UMD header of lenght 1 octet is added. The header defines the sequence number of the UMD PDU (set to zero in this case) and the E bit (set to zero indicating that data follow)

In the second UMD PDU, the remaining data from the first RLC SDU are put into the UMD PDU along with the beginning of the second RLC SDU. In this case, the first RLC SDU is completed in this UMD PDU and so a length indicator is added to the header. The length indicator defines the number of octets between the end of the RLC header and the last octet of the RLC SDU it refers to, including the last octet. In this example, there are 14 octets in the last segment of the RLC SDU and so the length indicator is set to 14. The header for this second UMD PDU has two octets, one for the sequence number (set to 1, i.e. incremented by 1 from the previous UMD PDU sequence number) and an E bit (set to 1 indicating a length indicator follows), next there is a second octet for the 7-bit length indicator, which also includes an E bit (set to 0 indicating data field next).

In the third and final UMD PDU that the RLC has to supply to the MAC, 26 octets of data from the second RLC SDU are added to the UMD PDU along with a 1 octet RLC header. The RLC header has a sequence number (set to 2) and an E bit (set to 0 indicating data field next). The remaining RLC SDU segments (three octets in total) can remain in the RLC UM entities buffer to be transmitted in the next TTI, concatenated with additional RLC SDUs as they arrive in the buffer, or alternatively follow any discard procedures configured for this RLC entity

Although the use of padding is avoided where possible, the UMD PDU can be padded out to fill the available length in which case special length indicators are used to indicate the presence of padding. There are also a number of other special length indicators to cope with some less common situations where there is no room for a length indicator in the current UMD PDU and so these special length indicators are defines and included in subsequent UMD PDUs

Related Topics:Edit

RLC, TM

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.