10 - Layer 2 (Mac, Rlc, Pdcp)

Embed Size (px)

Citation preview

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    1/34

    1 2006 Nokia Layer 2 (MAC, RLC, PDCP)/ Kittipong Thamapa

    Layer 2Layer 2(MAC, RLC and PDCP)(MAC, RLC and PDCP)

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    2/34

    2 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    Interactions between RRC and lower layers

    in the C plane

    R R C R R C

    R L C R L C

    Radio Resource

    Assignment[Code, Frequency,

    TS, TF Set, Mapping,

    etc.]

    Measurement Report

    RLC retransmissioncontrol

    L 1 L 1

    U T R A N U E

    Control

    Measurements

    Control

    Measurements

    Control

    Measurements

    Control

    Measurements

    M A C M A C

    Co

    ntrol

    C

    ontrol

    3G TS 25.301

    Interactions between RRC and lower layers

    The RRC protocol controls and signals the allocation of radio resources to the UE. RRC allows MAC toarbitrate between users and radio bearers within the radio resource allocation. The RRC uses themeasurements done by the lower layers to determine which radio resources are available. Therefore it is aneed for a measurement report from the UE RRC to the UTRAN RRC. The figure above illustrates theprinciple. The local control and local measurements reporting is handled through the control SAPs betweenRRC and the lower layers.

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    3/34

    3 2006 Nokia Layer 2 (MAC, RLC, PDCP)/ Kittipong Thamapa

    Medium Access Control

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    4/34

    4 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    MAC Medium Access Control Protocol

    MAC Services to upper layer

    Data transfer service on logical channels classified in control and traffic channels

    Reallocation of radio resources and MAC parameters

    Reporting of measurements

    MAC functions:

    Mapping between logical channels and transport channels

    Selection of appropriate Transport Format for each Transport Channel depending on instantaneous source rate

    Priority handling between data flows of one UE

    Priority handling between UEs by means of dynamic scheduling

    Identification of UEs on common transport channels

    Multiplexing/demultiplexing of upper layer PDUs into/from transport blocks delivered to/from the physical layeron common transport channels

    Multiplexing/demultiplexing of upper layer PDUs into/from transport block sets delivered to/from the physicallayer on dedicated transport channels

    Traffic volume measurement

    Transport Channel type switching

    Ciphering Access Service Class selection for RACH and CPCH transmission

    3G TS 25.301

    A detailed description of all services and functions of layer 1 and 2 in the Uu interface is entered in the3GPP specification 25.301.

    MAC services to upper layers

    Data transfer. This service provides unacknowledged transfer of MAC SDUs between peer MAC entities.This service does not provide any data segmentation. Therefore, segmentation/reassembly function shouldbe achieved by upper layer. Reallocation of radio resources and MAC parameters. This service performs on request of RRCexecution of radio resource reallocation and change of MAC parameters, that is, reconfiguration of MACfunctions such as change of identity of UE, change of transport format (combination) sets, change oftransport channel type. Reporting of measurements. Local measurements such as traffic volume and quality indication arereported to RRC.

    MAC functions Mapping between logical channels and transport channels. The MAC is responsible for mapping of

    logical channel(s) onto the appropriate transport channel(s). Selection of appropriate Transport Format for each Transport Channel depending on instantaneoussource rate. Given the Transport Format Combination Set assigned by RRC, MAC selects the appropriatetransport format within an assigned transport format set for each active transport channel depending onsource rate. The control of transport formats ensures efficient use of transport channels. Priority handling between data flows of one UE. When selecting between the Transport FormatCombinations in the given Transport Format Combination Set, priorities of the data flows to be mappedonto the corresponding Transport Channels can be taken into account. Priorities are e.g. given by attributesof Radio Bearer services and RLC buffer status. The priority handling is achieved by selecting a TransportFormat Combination, for which high priority data is mapped onto L1 with a "high bit rate" TransportFormat, at the same time letting lower priority data be mapped with a "low bit rate" (could be zero bit

    rate) Transport Format. Transport format selection may also take into account transmit power indicationfrom Layer 1.

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    5/34

    5 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    UTRAN side MAC architecture

    FACH RACH

    DCCH DTCHDTCH

    DSCH

    MAC Control

    Iur or local

    MAC Control

    DCH DCH

    MAC-d

    [controls

    access to

    dedicated

    transport

    channels]

    MAC-c/sh

    [controls access to common

    transport channels]

    CPCH

    CCCH CTCHBCCHPCCH

    FACHPCH DSCH

    3G TS 25.321

    Logical Channels

    Transport Channels

    Traffic Related Architecture - UTRAN SideThe figure above illustrates the connectivity between the MAC entities from the UTRAN side.It is similar to the UE case with the exception that there will be one MAC-d for each UE and each UE(MAC-d) that is associated with a particular cell may be associated with that cell's MAC-c/sh.

    MAC-c/sh is located in the controlling RNC while MAC-d is located in the serving RNC.The MAC Control SAP is used to transfer Control information to each MAC entity belongs to one UE.

    Description of services provided to upper layers: Data transfer: This service provides unacknowledged transfer of MAC SDUs between peer MAC

    entities without data segmentation. Reallocation of radio resources and MAC parameters: This service performs on request of RRC

    execution of radio resource reallocation and change of MAC parameters. Reporting of measurements: Local measurements are reported to RRC.

    The functions of MAC include: Mapping between logical channels and transport channels

    Selection of appropriate Transport Format for each Transport Channel depending oninstantaneous source rate

    Priority handling between data flows of one UE Priority handling between UEs by means of dynamic scheduling Priority handling between data flows of several users on the DSCH and FACH Identification of UEs on common transport channels Multiplexing/demultiplexing of higher layer PDUs into/from transport blocks delivered to/from

    the physical layer on common transport channels Multiplexing/demultiplexing of higher layer PDUs into/from transport block sets delivered

    to/from the physical layer on dedicated transport channels Traffic volume monitoring

    Transport Channel type switching Ciphering for transparent RLC Access Service Class selection for RACH and CPCH transmission.

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    6/34

    6 2006 Nokia Layer 2 (MAC, RLC, PDCP)/ Kittipong Thamapa

    UE side and UTRAN side architecture

    MAC-b

    [controls

    access to

    Broadcast

    channel]

    BCCH

    BCH

    Mac Control

    3G TS 25.321

    The model of the MAC layer does not specify or restrict implementations. The MAC architecture includesfollowing entities:

    MAC-b is the MAC entity that handles the following transport channels:- broadcast channel (BCH)

    MAC-c/sh, is the MAC entity that handles the following transport channels:- paging channel (PCH)- forward access channel (FACH)- random access channel (RACH)- common packet channel (UL CPCH). The CPCH exists only in FDD mode.- downlink shared channel (DSCH)- uplink shared channel (USCH). The USCH exists only in TDD mode.

    MAC-d is the MAC entity that handles the following transport channels:- dedicated transport channels (DCH) MAC-b

    The diagram above illustrates the connectivity of the MAC-b entity in a UE and in each cell of the UTRAN.MAC-b represents the control entity for the broadcast channel (BCH). There is one MAC-b entity in each

    UE and one MAC-b in the UTRAN for each cell. The MAC Control SAP is used to transfer Controlinformation to MAC-b. The MAC-b entity is located in the Node B.

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    7/34

    7 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    MAC data PDU

    MAC SDUC/TUE-Id

    MAC header MAC SDU

    TCTF UE-Idtype

    Target Channel type field

    identifies the logical channelclasson FACH and RACH transportchannels

    Identifier of the UE on common transport channels

    Ensures correct decoding of the UE-Id f ielddepending on U-RNTI or C-RNTI

    Identifies the logical channel instancewhen multiple logical channels are carriedon the same transport channel

    Service Data Unit

    3G TS 25.321

    Elements of peer-to-peer communicationIn the UE for the uplink, all MAC PDUs delivered to the physical layer within one TTI are defined as Transport BlockSet (TBS). A TBS consists of one or several Transport Blocks, each containing one MAC PDU. The Transport Blocksshall be transmitted in the order as delivered from RLC. When multiplexing of RLC PDUs from different logicalchannels is performed on MAC, the order of all Transport Blocks originating from the same logical channel shall bethe same as the order of the sequence delivered from RLC. The order of the different logical channels in a TBS isset by the MAC protocol.

    MAC PDU consists of an optional (depends on the mapping of logical on transport channel) MAC header and aMAC Service Data Unit (MAC SDU). Both the MAC header and the MAC SDU are of variable size. The content andthe size of the MAC header depends on the type of the logical channel, and in some cases none of the parametersin the MAC header are needed. The size of the MAC-SDU depends on the size of the RLC-PDU, which is definedduring the set-up procedure.

    Header parameters: Target Channel Type Field: The TCTF field is a flag that provides identification of the logical channel class on

    FACH and RACH transport channels, that is, whether it carries BCCH, CCCH, CTCH, SHCCH or dedicated logicalchannel information. C/T field: The C/T field provides identification of the logical channel instance when multiple logical channels arecarried on the same transport channel. The C/T field is used also to provide identification of the logical channeltype on dedicated transport channels and on FACH and RACH when used for user data transmission. UE-Id: The UE-Id field provides an identifier of the UE on common transport channels. The following types of UE-Id used on MAC are defined:- UTRAN Radio Network Temporary Identity (U-RNTI) may be used in the MAC header of DCCH when

    mapped onto common transport channels- Cell Radio Network Temporary Identity (C-RNTI) is used on DTCH, DSCH in FDD mode, and may be used

    on DCCH, when mapped onto common transport channels

    - The UE id to be used by MAC is configured through the MAC control SAP. The lengths of the UE-id fieldof the MAC header are given in table 9.2.1.6.- UE-Id Type The UE-Id Type field is needed to ensure correct decoding of the UE-Id field in MAC Headers.

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    8/34

    8 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    Example elementary procedure: Traffic volume

    measurement/report in MAC

    Start

    Check traffic volume of transport channels

    TH L< Transport Channel

    Traffic Volume < TH U ?

    N

    Y

    Wait TTI

    Get the measurement information from RRC: Mode, Reporting

    Quantity identifiers, Time interval to take an average or avariance,

    Reporting Interval, THU, THL, etc.

    Mode = Periodical& end of Reporting

    Interval ?

    ReportMeasurementResult to RRC

    Mode = Event

    Trigger ?

    Y

    N

    Y

    N

    3G TS 25.321

    raffic volume measurement for dynamic radio bearer controlynamic radio bearer control is performed in RRC, based on the traffic volume measurement reported by MAC. Trafficolume information is gathered and measured in MAC layer and the result is reported from MAC layer to RRC layer.

    n the traffic volume measurement procedure in MAC, the MAC receives RLC PDUs together with BOs (Bufferccupancies) from RLC entities, and may multiplex these RLC PDUs. If the reporting mode is Event Trigger, MACompares for each TTI Transport Channel Traffic Volume (equivalent to total sum of BOs for logical channels mappednto a transport channel) with the thresholds set by RRC. If the value is out of range, MAC reports measurement resuthat is, BO, Average of BO, and Variance of BO) of each RB to RRC. If the reporting mode is Periodical, MAC reports

    measurement result of each RB to RRC at the end of each Reporting Interval. The Reporting Interval is set by RRC.hereby, RRC can be informed the traffic volume status of each logical and transport channel, and therefore can takeroper action for new radio bearer configuration accordingly.

    RC requests MAC measurement report with the primitive CMAC-Measure-REQ.MAC receives RLC PDUs with the primitive MAC-Data-REQ .MAC receives measurement information elements with the primitive CMAC-Measure-REQ that includes parameters

    uch as Mode, Reporting Quantity identifiers, Time interval to take an average or a variance, Reporting Interval, andHU and THL for each transport channel. Whenever MAC receives RLC PDUs from different RLC entities, it is notified bLC amount of data queued in RLC transmission and retransmission buffer. If the mode is Event Trigger, MAC compareransport Channel Traffic Volume with threshold values passed by RRC, THU and THL. In case the measured value is ouf range, MAC reports measurement result of each RB to RRC. On the other hand, if the mode is Periodical, MACeports the measurement result to RRC periodically. The measurement result can contain average and variance as wells amount of data for each RB as follows.

    When RRC receives the measurement result of each RB, the RRC shall convert the values BO, Average of BO, andariance of BO to the quantisised values RLC Buffer Payload, Average of RLC Buffer Payload, and Variance of RLCuffer Payload, respectively.

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    9/34

    9 2006 Nokia Layer 2 (MAC, RLC, PDCP)/ Kittipong Thamapa

    Radio Link Control

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    10/34

    10 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    RLC Radio Link Control Protocol

    RLC functions:

    Segmentation and reassembly

    Concatenation

    Padding

    Transfer of user data

    Error correction In-sequence delivery of upper layer PDUs

    Duplicate detection

    Flow control

    Sequence number check

    Protocol error detection and recovery

    Ciphering

    Polling

    Status transmission

    SDU discard

    Estimated PDU Counter (EPC) mechanism

    Suspend/resume function

    Stop/continue function

    Re-establishment function

    RLC Services to upper layer:

    Transparent data transfer Notification of unrecoverable errors

    Maintenance of QoS as defined by upper layers

    Unacknowledged data transfer

    QoS setting

    Acknowledged data transfer

    3G TS 25.301

    RLC ServicesServices provided to the upper layer

    Transparent data transfer. This service transmits upper layer PDUs without adding any protocol

    information, possibly including segmentation/reassembly functionality. Unacknowledged data transfer. This service transmits upper layer PDUs without guaranteeing deliveryto the peer entity. The unacknowledged data transfer mode has the following characteristics:- Detection of erroneous data: The RLC sublayer shall deliver only those SDUs to the receiving upper layerthat are free of transmission errors by using the sequence-number check function.- Immediate delivery: The receiving RLC sublayer entity shall deliver a SDU to the upper layer receivingentity as soon as it arrives at the receiver. Acknowledged data transfer. This service transmits upper layer PDUs and guarantees delivery to thepeer entity. In case RLC is unable to deliver the data correctly, the user of RLC at the transmitting side isnotified. For this service, both in-sequence and out-of-sequence delivery are supported. In many cases aupper layer protocol can restore the order of its PDUs. As long as the out-of-sequence properties of thelower layer are known and controlled (i.e. the upper layer protocol will not immediately request

    retransmission of a missing PDU) allowing out-of-sequence delivery can save memory space in thereceiving RLC. The acknowledged data transfer mode has the following characteristics:- Error-free delivery: Error-free delivery is ensured by means of retransmission. The receiving RLC entitydelivers only error-free SDUs to the upper layer.- Unique delivery: The RLC sublayer shall deliver each SDU only once to the receiving upper layer usingduplication detection function.- In-sequence delivery: RLC sublayer shall provide support for in-order delivery of SDUs, i.e., RLC sublayershould deliver SDUs to the receiving upper layer entity in the same order as the transmitting upper layerentity submits them to the RLC sublayer.- Out-of-sequence delivery: Alternatively to in-sequence delivery, it shall also be possible to allow that thereceiving RLC entity delivers SDUs to upper layer in different order than submitted to RLC sublayer at the

    transmitting side. Maintenance of QoS as defined by upper layers. The retransmission protocol shall be configurable bylayer 3 to provide different levels of QoS. This can be controlled.

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    11/34

    11 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    Data flow for non-transparent RLC and MAC

    Higher Layer

    L1

    Higher Layer PDU

    RLC SDU

    MAC SDU

    Transport block (MAC PDU)

    CRC

    RLCHeader

    RLCHeader

    MAC SDU

    Transport block (MAC PDU)

    CRC

    MACHeader

    MACHeader

    L2 MAC

    (non-transparent)

    L2 RLC

    (non-transparent)

    Segmentation &

    concatenation

    reassembly

    Higher Layer PDU

    RLC SDU

    3G TS 25.301

    Skipped in

    transparent mode

    For the data flow through the whole layer there are different options available depending on the serviceand the logical channel mapped on the transport channel for certain traffic or signalling. Both sublayers,MAC and RLC, can operate in the transparent mode where no header is required. This means that no

    functions are performed for a transparent PDU through a sublayer.Example: Data flow for CCCH mapped to FACH / RACH

    For CCCH, transparent transmission mode on RLC is employed on the uplink (when mapped to RACH).Unacknowledged transmission mode on RLC is employed on the downlink (when mapped to FACH). A MACheader is used for logical channel identification (CCCH, CTCH, SHCCH, DCCH, DTCH). If the transparent RLCtransfer mode is applied, no header is added in RLC. If the unacknowledged RLC transfer mode is applied aheader is added in the RLC sublayer, so-called non-transparent mode.

    The other examples are listed in the concerning specification.

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    12/34

    12 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    Overview model of RLC

    UTRAN

    Transmitting side Receiving side

    MSRadio Interface

    Receiving side

    3G TS 25.322

    Transm.Tr-

    Entity

    Transm.Um-

    Entity

    AM-EntityReceiv.Um-

    Entity

    Receiv.Tr-

    Entity

    Transm.Tr-

    Entity

    Transm.Um-

    Entity

    Receiv.Um-

    Entity

    Receiv.Tr-

    EntityAM-Entity

    Higher Layer

    RLC

    MAC

    Transmitting side

    Model of RLC

    The figure above gives an overview model of the RLC layer. It illustrates the different RLC peer entities.There is one transmitting and one receiving entity for the transparent mode service and the

    unacknowledged mode service and one combined transmitting and receiving entity for the acknowledgedmode service. In this specification the word transmitted is equivalent to "submitted to lower layer" unlessotherwise explicitly stated. The dashed lines between the AM-Entities illustrate the possibility to send theRLC PDUs on separate logical channels, e.g. control PDUs on one and data PDUs on the other.

    Services provided to upper layers

    The different services provided by RLC to higher layers are listed in the following; also mapping offunctions to different services is included.

    Transparent data transfer service:

    Segmentation and reassembly Transfer of user data.

    Unacknowledged data transfer service: Segmentation and reassembly Concatenation Padding Transfer of user data Ciphering Sequence number check.

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    13/34

    13 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    Model of two unacknowledged mode peer entities

    Transm.UM-Entity

    Transmissionbuffer

    UM-SAP

    ReceiverUM-Entity

    Receiverbuffer

    UM-SAP

    Radio Interface

    Segmentation &Concatenation

    Ciphering

    Add RLC header

    Reassembly

    Deciphering

    Remove RLCheader

    CCCH/DCCH/DTCH/SHCCHCTCH

    CCCH/DCCH/DTCH/ SHCCHCTCH 3G TS 25.322

    Acknowledged data transfer service: Segmentation and reassembly Concatenation Padding

    Transfer of user data Error correction In-sequence delivery of higher layer PDUs Duplicate detection Flow control Protocol error detection and recovery Ciphering.

    QoS settingNotification of unrecoverable errors

    The figure above shows the model of two unacknowledged mode peer entities. The transmitting

    UM-entity receives SDUs from the higher layers. RLC might segment the SDUs into RLC PDUs ofappropriate size. The SDU might also be concatenated with other SDUs. RLC delivers the RLCPDUs to a lower layer through either a CCCH, SHCCH, DCCH, CTCH or a DTCH. The CCCH andSHCCH uses unacknowledged mode only for the downlink. Which type of logical channeldepends on if the higher layer is located in the control plane (CCCH, DCCH, SHCCH) or user plane(CTCH, DTCH). The receiving UM-entity receives PDUs through one of the logical channels fromthe MAC sublayer. RLC removes header from the PDUs and reassembles the PDUs (ifsegmentation has been performed) into RLC SDUs. The RLC SDUs are delivered to the higherlayer.

    For the Acknowledged mode are functions added for buffering, re-transmission,re-assembly and multiplexing to support the required services for this mode. See the

    specification for detailed model.The applicability of services and functions depend on the transmission mode and the logicalchannel type.

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    14/34

    14 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    RLC protocol data units

    Data Transfer Mode PDU name Description

    Transparent TrD Transparent mode dataUnacknowledged UMD Sequenced unacknowledged mode dataAMD Sequenced acknowledged mode dataSTATUS Solicited or Unsolicited Status ReportPiggybackedSTATUS

    Piggybacked Solicited or Unsolicited StatusReport

    RESET Reset Command

    Acknowledged

    RESET ACK Reset Acknowledgement

    3G TS 25.322

    Data PDUsa) The TrD PDU (Transparent Mode Data PDU) is used to convey RLC SDU data without adding any

    RLC overhead. The TrD PDU is used by RLC when it is in transparent mode.b) The UMD PDU (Unacknowledged Mode Data PDU) is used to convey sequentially numbered

    PDUs containing RLC SDU data. It is used by RLC when using unacknowledged data transfer.c) The AMD PDU (Acknowledged Mode Data PDU) is used to convey sequentially numbered PDUscontaining RLC SDU data. The AMD PDU is used by RLC when it is in acknowledged mode.

    Control PDUsa) The STATUS PDU and Piggybacked STATUS PDU are used in acknowledged mode:

    by the receiving entity to inform the transmitting entity about missing PDUs at the receivingentity by the receiving entity to inform the transmitting entity about the size of the allowedtransmission window and by the transmitting entity to request the receiving entity to move the receiving window.

    b) The RESET PDU is used in acknowledged mode to reset all protocol states, protocol variables

    and protocol timers of the peer RLC entity in order to synchronise the two peer entities.c) RESET ACK PDU The RESET ACK PDU is an acknowledgement to the RESET PDU.

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    15/34

    15 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    PDU formats depending on transmission service for user data!

    Data

    TrD PDU

    Oct 1

    ELength Indicator

    Data

    PADOctN

    ELength Indicator (Optional)(1)

    .

    .

    .

    ESequence Number

    (Optional)

    (Optional)

    UMD PDU

    Sequence Number

    Sequence Number

    D/C

    ELength Indicator

    Data

    PAD or a piggybacked STATUS PDU

    Oct 1

    Oct 2

    OctN

    P HE

    ELength Indicator

    .

    .

    .

    (Optional)(1)Oct 3

    AMD PDU

    3G TS 25.322

    An RLC PDU is a bit string, with a length not necessarily a multiple of 8 bits. In the drawings in clause 9.2,bit strings are represented by tables in which the first bit is the leftmost one on the first line of the table,the last bit is the rightmost on the last line of the table, and more generally the bit string is to be readfrom left to right and then in the reading order of the lines.

    Depending on the provided service, RLC SDUs are bit strings, with any non-null length, or bit strings withan integer number of octets in length. An SDU is included into an RLC PDU from first bit onward. The TrD PDU transfers user data when RLC is operating in transparent mode. No overhead is added tothe SDU by RLC. The data length is not constrained to be an integer number of octets. The UMD PDU transfers user data when RLC is operating in unacknowledged mode. The length of thedata part shall be an integer number of octets. The UMD PDU header consists of the first octet, whichcontains the sequence number. The RLC header consists of the first octet and all the octets that containlength indicators. The AMD PDU transfers user data and piggybacked status information and requests status report bysetting Poll bit when RLC is operating in acknowledged mode. The length of the data part shall be aninteger number of octets. The AMD PDU header consists of the first two octets, which contain the

    sequence number. The RLC header consists of the first two octets and all the octets that contain lengthindicators.

    Parameters: The D/C field indicates the type of an acknowledged mode PDU. It can be either data or control PDU. Extension bit E indicates if the next octet will be a length indicator and E bit. Polling bit P is used to request a status report. Reserved 1 R1 is used to achieve octet alignment. Header Extension Type HE indicates if the next octet will be data or a length indicator and E bit.

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    16/34

    16 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    Status Information Control PDUs for AMD mode

    D/C PDU type SUFI1 Oct 1

    Oct2

    OctN

    SUFIK

    SUFI1

    PAD

    Oct1

    Oct2

    OctN

    SUFIK

    SUFI1

    PAD

    R2 PDU Type SUFI1

    Oct1

    OctN

    D/C R1PDU Type RSN

    PAD

    HFNIHFNI

    HFNI

    Status Information Control PDU

    Piggybacked Status PDU

    Reset, Reset ACK PDU

    PDU type field indicates the Control PDU type

    3G TS 25.322

    Control PDUs

    STATUS PDUThe STATUS PDU is used to report the status between two RLC AM entities. Both receiver and transmitter

    status information may be included in the same STATUS PDU. The figure shows an example and the lengthof each SUFI is dependent on the SUFI type. Up to K super-fields (SUFI1-SUFIK) can be included into oneSTATUS PDU, in which each super-field can be of different type. The size of a STATUS PDU is variable andupper bounded by the maximum RLC PDU size used by the logical channel on which the control PDUs aresent. Padding shall be included to exactly fit one of the PDU sizes used by the logical channel on which thecontrol PDUs are sent. The length of the STATUS PDU shall be an integer number of octets.

    Piggybacked STATUS PDUThe format of the piggybacked STATUS PDU is the same as the ordinary Control PDU except that the D/Cfield is replaced by a reserved bit (R2). This PDU can be used to piggyback STATUS PDU in an AMD PDU ifthe data does not fill the complete AMD PDU. The PDU Type field is set to zero and all other values areinvalid for this version of the protocol and the PDU is discarded.

    RESET, RESET ACK PDUThe RESET PDU and RESET ACK PDU have a one-bit sequence number field (RSN). With the aid of this fieldthe Receiver can define whether the received RESET PDU is transmitted by the Sender for the first time orwhether it is a retransmission of a previous RESET PDU.

    Parameters: Super field SUFI is implementation dependent, see specs. Padding PAD has a length such that the PDU has the required predefined total length. Reset Sequence Number RSN indicate the sequence number of the transmitted RESET PDU. HFNI indicates the hyper frame number to the peer entity.

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    17/34

    17 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    The state model for the acknowledged mode entities when reset is

    performed

    2.

    Ack.

    Data Transfer

    Ready

    1.

    Null

    CRLC-CONFIG-Req

    CRLC-CONFIG-Req3.

    Reset.

    Pending

    RESET

    RESET ACK

    RESET

    RESET ACK

    CRLC-CONFIG-Req

    Received signal

    Sent signal

    RESET ACK

    RESET

    RESET ACK

    3G TS 25.322

    This figure illustrates the state model for the acknowledged mode RLC entity. It includes following states:

    Null StateIn the Null state the RLC entity does not exist and therefore it is not possible to transfer any data throughit.

    Acknowledged Data Transfer Ready StateIn the Acknowledged Data Transfer Ready state, acknowledged mode data can be exchanged between theentities.

    Reset Pending StateIn the Reset Pending state the entity waits for a response from its peer entity and no data can beexchanged between the entities.

    Local Suspend StateThe RLC entity enters into Local Suspend state if Reset Pending state was entered from Local Suspendstate or if Reset Pending state was entered from Acknowledged Data Transfer Ready state and a CRLC-SUSPEND-Req was received in Reset Pending state.

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    18/34

    18 2006 Nokia Layer 2 (MAC, RLC, PDCP)/ Kittipong Thamapa

    Packet Data Convergence Protocol

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    19/34

    19 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    Packet Data Convergence Protocol (PDCP)

    Located in User Plane for Packet Switched services

    PDCP provides its services to the NAS at the UE or the relay at the RNC

    PDCP uses the services provided by the Radio Link Control (RLC) sublayer

    Main PDCP functions:

    Compression of redundant Network PDU control information (header compression)

    Transfer of packet data protocol user data using services provided by the RLC protocol

    Support for lossless SRNS relocation when PDCP is using acknowledged mode RLCwith in-sequence delivery

    Multiplexing of different radio bearers into one RLC entity (scheduled for Release 2000)

    3G TS 25.323

    Network layer protocols are intended to be capable of operating over services derived from a wide varietyof subnetworks and data links. UMTS supports several network layer protocols providing protocoltransparency for the users of the service. At that point of view supported protocols are IPv4 and IPv6.

    Introduction of new network layer protocols to be transferred over UTRAN shall be possible without anychanges to UTRAN protocols. Therefore, all functions related to transfer of packets from higher layers(PDCP SDUs) shall be carried out in a transparent way by the UTRAN network entities. This is one of therequirements for UTRAN PDCP.

    Another requirement for the PDCP is to provide functions that help to improve channel efficiency. Thisrequirement is fulfilled by the possibility to implement different kinds of optimisation methods. Thecurrently known methods are standardised IETF header compression protocols.Every RB is connected to one PDCP entity and one PDCP entity is connected to one RLC entity. The PDCPentities are located in the PDCP sublayer.

    Every PDCP entity uses zero, one or several header compression protocol types with certain parameters.

    Several PDCP entities may use the same protocol type. The protocol types and their parameters arenegotiated by higher layers and indicated to PDCP through the PDCP Control Service Access Point (PDCP-C-SAP).

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    20/34

    20 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    Structure of PDCP Protocol

    . . .

    . . .

    RLC

    PDCP-SDU

    PDCP-sublayer

    RLC-SDU

    RadioBearers

    UM-SAP AM-SAP

    Control-SAP

    Tr-SAP

    Protocolcomp. entityAlg. Type2

    Protocolcomp. entityAlg. Type1

    Protocolcomp. entityAlg. Type1

    Bearer-SAPs

    PDUnumbering

    Protocolcomp. entityAlg. Type1

    PDUnumbering

    Protocolcomp. entityAlg. Type2

    PDCP entityPDCP entityPDCP entity

    Possibility of Multiplexing->planned for Release 2000

    3G TS 25.323

    Packet Data Convergence Protocol performs the following functions:

    Header compression and decompression of IP data streams (e.g. TCP/IP and RTP/UDP/IP headers) at the

    transmitting and receiving entity, respectively. The header compression method is specific to the particularnetwork layer, transport layer or upper layer protocol combinations e.g. TCP/IP and RTP/UDP/IP.

    Transfer of user data. Transmission of user data means that PDCP receives PDCP SDU from the NAS andforwards it to the RLC layer and vice versa.

    Maintenance of PDCP sequence numbers for radio bearers that are configured to support lossless SRNSrelocation.

    The figure above shows the model of PDCP within UTRAN protocol architecture. Every PDCP-SAP usesexactly one PDCP entity. Each PDCP entity uses none, one or several header compression protocol types.

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    21/34

    21 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    PDCP data transfer over acknowledged mode RLC

    Originator

    PDCP RLC

    Acknowledgement

    RLC-AM-DATA.req

    RLC-AM-DATA.ind

    RLC-AM-DATA.cnf

    PDCP user

    Receiver

    PDCPRLC PDCP user

    PDCP-DATA.req

    PDCP-DATA.ind

    ...

    PDU type PID

    Sequence number

    Data

    Example for a PDCP PDU format:PDCP-SeqNum-PDU

    3G TS 25.323

    PDCP data transfer over acknowledged mode RLC

    If header compression is negotiated, the PDCP entity shall perform header compression upon reception of aPDCP-DATA.Req. The PDCP-PDU is then delivered in RLC-AM-DATA.Req to RLC.

    During operation, when the peer PDCP entity receives the PDCP-PDU in a RLC-AM-DATA.Ind primitive, thePDCP entity shall perform the header decompression (if negotiated) of PDCP-PDU to obtain the PDCP SDUand deliver the PDCP SDU to the PDCP user with the PDCP-DATA.Ind.The figure illustrates data transfer over acknowledged mode RLC.

    In case of unacknowledged data transfer the PDCP will not receive a confirmation message.

    The PDCP PDU can include the following parameters:

    PID - Used to distinguish different types of header compression packets to handle them with a correctheader compression protocol and to indicate the type of the packet within a certain protocol.

    PDU Type field indicates the PDCP-data PDU type which depend on Header compression used andsequence numbering:

    - PDCP-No-header PDU

    - PDCP Data PDU

    - PDCP SeqNum PDU

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    22/34

    22 2006 Nokia Layer 2 (MAC, RLC, PDCP)/ Kittipong Thamapa

    Broadcast/Multicast Control

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    23/34

    23 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    BMC protocol model

    3G TS 25.324

    L2/BMC sublayer

    RRC BMC-SAP

    user-plane

    L2/RLC sublayer

    BMC

    RLC

    UM-SAP

    CTCH-SAP

    Control BMC SAP

    The Broadcast/Multicast Control (BMC) protocol is another service-specific Layer 2 protocol whichexists only in the User Plane. This protocol is designed to adapt broadcast and multicast services,originating from the Broadcast domain, on the radio interface. The SMS Cell Broadcast service isdirectly taken from GSM and the only service utilising this protocol in Release 99 specification. It

    utilises UM RLC using the CTCH logical channel, which is mapped into the FACH transport channel.Each SMS Cell Broadcast message is targeted to a geographical area, the RNC maps this area intocells.

    The service requires one BMC protocol entity per cell and the concerning CTCH provided by the MAClayer. The BMC requests the Unacknowledged mode service of the RLC.

    The main functions in the BMC protocol are listed below. The functions depend on the interface sideUE or UTRAN [1]:

    Storage of Cell Broadcast messages. The BMC in RNC stores the Cell Broadcast (CB) messagereceived for scheduled transmission.

    Traffic volume monitoring and radio resource request for CBS. On UTRAN side the BMC

    calculates the required transmission rate for the CB service based on the messages received fromCBC-RNC interface and requests appropriate CTCH/FACH resources from RRC.

    Scheduling of BMC messages. The BMC receives scheduling information together with each CellBroadcast message over the CBC-RNC interface. Based on this scheduling information, on the UTRANside the BMC generates schedule messages and schedules BMC message sequence accordingly. Onthe UE side, BMC evaluates the schedule messages and indicates scheduling parameters to RRC,which are used by the RRC to configure the lower layers for CBS discontinuous reception.

    Transmission of BMC messages to UE. This function transmits the BMC messages according tothe schedule.

    Delivery of Cell Broadcast messages to upper layer (NAS). This UE function delivers the received

    non-corrupted Cell Broadcast messages to the upper layer.

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    24/34

    24 2006 Nokia Layer 2 (MAC, RLC, PDCP)/ Kittipong Thamapa

    RACH Transport Channel

    PHY PHY

    ATM

    RachFP

    ATM

    RachFP

    MAC-c/sh

    IubUE NodeB CRNC/SRNCUu

    MAC-d

    CCCH DCCH DTCH

    AAL2 AAL2

    MAC-c/sh

    MAC-d

    CCCHDTCH DCCH

    3G TS 25.401

    Logical Channels

    RACH Transport Channel

    The figure above shows the protocol stack model for the RACH transport channel when the Controlling andServing RNC are co-incident.

    For the RACH transport channel, Dedicated MAC (MAC-d) uses the services of Common MAC (MAC-c/sh).The Common MAC (MAC-c/sh) entity in the UE transfers MAC-c/sh PDU to the peer MAC-c/sh entity in theRNC using the services of the Physical Layer. An Interworking Function (IWF) in the Node B interworks theRACH frame received by the PHY entity into the RACH Frame Protocol (RACH FP) entity. The RACH FrameProtocol entity adds header information to form a RACH FP PDU that is transported to the RNC over anAAL2 (or AAL5) connection. At the RNC, the RACH FP entity delivers the MAC-c/sh PDU to the MAC-c/shentity.

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    25/34

    25 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    Overview of point-to-multipoint services and requirements

    Distribution Services

    (synonym: Point-to-multipoint Services)

    IP Multicast (IP-M)

    Cell BroadcastService (CBS)

    3G TS 25.925

    It is agreed to have service continuity for GSM/GPRS point-to-multipoint services in UMTS. This meansthat the user gets the same service behaviour as he/she knows it from GSM or GPRS. The services are Cell

    Broadcast Service and IP Multicast.

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    26/34

    26 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    CBS (GSM) impact on UMTS General Protocol architecture

    Node B

    UE CBC

    CBS Appl. 1 CBS Appl. 1

    BM-IWF

    SABP SABP

    TCP

    BMCBMC(note 3)

    (note 2)

    TCP

    RRC

    RLC

    MAC

    PHY

    RRC

    RLC

    MAC

    PHY

    Iu-BCUu

    (note6)

    IP IP

    (note6)

    RNC

    (note 1)

    (note 5)

    3G TS 25.925

    The impact of CBC (GSM) implementation on network and protocol architecture is shown above. Thefigure summarises the network and protocol architecture chosen for Release 1999 by S2, T2, R3 and R2.Note that the Cell Broadcast Centre is integrated into the Core Network. It is aimed to define a radiointerface protocol architecture that is independent of the chosen configuration of the CBC-RNC

    reference point.NOTE 1: S2 has chosen to integrate the CBC into the Core Network.NOTE 2: CBS Application protocol is to be defined by TSG T2.NOTE 3: R3 is responsible for specifying SABP (Service Area Broadcast Protocol, [19]).NOTE 4: This relay function provides IP routing to RNC.NOTE 5: The CBC sends a CB message together with its scheduling information once to an RNC

    (see [13] and [19]). The BM Interworking Function (BM-IWF) distributes CB messagesreceived over Appl. 3 to all BMC instances indicated in the delivered cell list. Forfuture releases of UMTS a new function would be necessary if a geographical area isdelivered instead of a cell list.

    NOTE 6: The lower layer on the Iu-BC interface uses AAL5 over ATM (packet transmission).In the following, the data unit delivered from/to the CBS Application 1 protocol is denoted as "CB

    message". It comprises the following CB message parameters:Number-of-Pages (1 octet),(CBS-Message-Information-Page 1 (82 octets), CBS-Message Information-Length 1(1 octet)) [,..,(CBS-Message-Information-Page 15 (82 octets), CBS-Message Information-Length 15)(1 octet)]

    This implies a maximum CB message length of 1 + 15 (82+1) = 1246 octets. (R3)

    The main objective of the BM-IWF in RNC is to distribute the received CB messages towards the BMCentities configured per cell for further processing. This is done in accordance with the associatedschedule information.

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    27/34

    27 2006 Nokia Layer 2 (MAC, RLC, PDCP)/ Kittipong Thamapa

    Protocol architecture for IP domain user plane

    RLC

    MAC

    L1

    GTP-U

    BSSGP

    ATM

    L2

    L1

    UDP/IP

    L2

    L1

    UDP/IP

    Uu Iu Gn GiUE RNS 3G-SGSN 3G-GGSN

    GTP-UGTP-U

    UDP/IP

    RLC

    L1

    AAL5

    ATM

    UDP/IP

    GTP-U

    MAC

    Note:Protocol layers above RLC and GTP-U are FFS

    AAL5

    3G TS 23.121

    The following principles apply to for the Iu interface. The UTRAN shall contain a "domaindistribution function" to route transparent application-level control signalling from the UE to thecorrect core network domain. The UE shall indicate the type of application being addressed (e.g. viaa protocol discriminator). The UTRAN shall map this on to the correct Iu instance to forward thesignalling. UTRAN-services (including radio access bearers) shall be independent from the core

    network domain used to access them. Either core network domain can access any appropriateUTRAN-service (e.g. it should be possible to access a "speech" radio access bearer from the PS-domain).

    Iu User PlaneThe standard shall support that the user data flows transported over the Iu reference point to/fromthe 'IP domain' shall be multiplexed on top of common layer 2 resources. If the Iu data transportbases on ATM PVCs then the Iu IP layer provides the Iu network layer services, e.g. routing,addressing, load sharing and redundancy. In this case an IP network may be configured to transferIu data units between RNSs and 3G-SGSNs. One or several AAL5/ATM Permanent VCs may be usedas the common layer 2 resources between the UTRAN and the 'IP domain' of the CN. The reason forusage of several permanent AAL5/ATM VCs may e.g. be for load sharing and redundancy. It is alsopossible to use one switched VC per user flow (PDP context or radio access bearer). A tunnellingprotocol is used on top of this common layer 2. This tunnelling protocol corresponds to an evolutionof the user plane part of the GTP protocol used in GPRS put on top of UDP/IP. The user data planein the UMTS network is made up of two tunnels:- first IP/UDP/GTP tunnel between RNC and 3G SGSN on Iu- second IP/UDP/GTP tunnel between GGSN and 3G SGSN on Gn.

    This architecture:- Provides hierarchical mobility- Allows having the RNC directly connected on the IP domain backbone

    - Ensures that all traffic is routed through 3G-SGSN that may perform functions such ascharging and Lawful Interception- Would allow to have different protocols (or protocol version) on Gn and Iu if needed in

    the future.

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    28/34

    28 2006 Nokia Layer 2 (MAC, RLC, PDCP)/ Kittipong Thamapa

    Exercises

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    29/34

    29 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    Answer the following questions

    What are the different information/data exchanged on the Control-,Transport- and User Plane depending on the UTRAN interface?

    What functions are located in the Transport Stratum?

    List the three different kind of Service Access Points used within UTRAN. What is a "Binding ID"?

    List the different protocols and their purpose located in Uu layer 2.

    Which UTRAN interface supports security functions?

    List the Transport Network Layer protocols of the Iu-CS Control Plane andthe dedicated services.

    Interface Control Plane Transport Plane User Plane

    Iu-PS

    Iu-CS

    Iur

    Iub

    Uu

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    30/34

    30 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    Connection-less, connectio-orientedservices, seperation of User Equipment

    Messaged routing, discrimination and

    distribution, Signalling Link management

    Mapping of requirements between

    SS7 and ATM

    Establish and release connections, provide

    reliable exchange of information

    Data segmentation, variable bit

    rates and error detection

    ATM cell with header

    Exercise: Describe briefly the sublayer services

    SCCP-SAP

    RANAP

    MTP3-B

    SSCOP

    SCCP

    SSCF-NNI

    AAL5

    ATM

    Physical Layer

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    31/34

    31 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    MAC layer distribution exercise: Enter the protocols for FACH separate

    controlling and serving RNC

    IubUE Node B CRNCUu Iur SRNC

    CCCH DCCH DTCHCCCHDTCH DCCH

    Iur FACH Frame Protocol is used to interwork the Common MAC at

    the controlling RNC with the dedicated MAC at the serving RNC3G TS 25.401

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    32/34

    32 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    MAC layer distribution exercise: Enter the protocols for FACH separate

    controlling and serving RNC

    Iur FACH Frame Protocol is used to interwork the Common MAC at

    the controlling RNC with the dedicated MAC at the serving RNC3G TS 25.401

    PHY PHY

    ATM

    FachFP

    IubUE NodeB CRNCUu Iur SRNC

    AAL2

    ATM

    FachFP

    MAC-c/sh

    ATM ATM

    MAC-d

    CCCH DCCH DTCH

    AAL2

    MAC-c/sh

    MAC-d

    CCCHDTCH DCCH

    AAL2

    FACHFP

    AAL2

    FACHFP

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    33/34

    33 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    Exercise: Enter the names for Uu protocol requirements for CB service

    Channels

    Channels

    con

    trol

    con

    trol

    control

    C-plane signalling

    U-plane information

    control

    Radio

    Bearers

    C-SAP

    C-SAP

    C-SAP

    3G TS 25.925

  • 7/28/2019 10 - Layer 2 (Mac, Rlc, Pdcp)

    34/34

    34 2006 Nokia Layer 2 (MAC, RLC, PDCP) / Kittipong Thamapa

    Exercise: Enter the names for Uu protocol requirements for CB service

    3G TS 25.925

    Transport

    Channels

    Logical

    Channels

    control

    control c

    ontrol

    C-plane signalling U-plane information

    L3

    L2/RLCRLC

    PHY

    L2/MAC

    L1

    BMC

    control

    L2/BMC

    MAC-c/sh

    PCH

    CCCH PCCH CTCH

    FACH 1...N

    Radio

    Bearers

    RLC

    BCCH

    RLCRLC

    C-SAP

    C-SAP

    C-SAP

    C-SAP

    UM

    RRC

    BMC-SAPTR

    MAC-d

    TR or

    UM