10 - layer 2 (mac, rlc, pdcp)
TRANSCRIPT
-
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