No Slide Title

Download Report

Transcript No Slide Title

UTRA
Data Communication Protocols
Description
July 15
Raul Bruzzone
1
Contents
•
•
•
•
•
•
•
•
•
Introduction
Review of Data Communication Concepts
Protocol Architecture Overview
Layer 1: Services and Functions
Medium Access Control Sub-layer: Services and
Functions
Radio Link Control Sub-layer: Services and Functions
Radio Resource Control Layer: Services and Functions
Conclusions
References
July 15
Raul Bruzzone
2
Introduction
July 15
Raul Bruzzone
3
UTRA Data Communication Protocols
• The set of rules that different machines of a
Communication System must follow in order to transport
data is called a Protocol.
• This presentation introduces the Protocols that have been
designed for the radio-dependent part of UMTS, called
UMTS Radio Access Network (UTRA).
• These protocols cover the three lower layers of the
OSI/ISO model.
• Their functionality is distributed in the User Equipment
(UE) and Fixed Radio Network.
July 15
L2_1
4
Review of
DATA COMMUNICATION
Concepts
July 15
Raul Bruzzone
5
Data Communication Service
Concept
• A Service represents a set of functions offered to a User by
a Provider :
Service
User
Service
Access Points
Service
User
Service
Provider
July 15
L2_2
6
Layering Concept
• When the Data Communication process requires a relatively complex
processing, the total activity is split in several parts called Layers.
N-Service
User
N-Service
Entity
N- Service
Access Points
(N-1) - Service
Access Points
N-Service
User
Layer
N+1
N-Service
Entity
Layer
N
(N-1) - Service
Provider
July 15
L2_2
7
Data Communication Protocols
• Service Entities located in the same layer communicate
between them following a set of rules called Protocol.
N-Service
User
N-Service
Entity
N-Layer
Protocol
N-Service
User
Layer
N+1
N-Service
Entity
Layer
N
(N-1) - Service
Provider
July 15
L2_2
8
Confirmed Data Communication
Service
A Data Communication Service involves two
participants:
• The User asking for the service: The Requesting User
• The User that is informed about the service request: The
Accepting User
• A Confirmed Service is one that involves a Handshake
between the Requesting User and the Accepting User.
July 15
L2_2
9
Service Primitives
• A Confirmed Service requires the exchange of several
messages between the participating entities. Each message
is called a Service Primitive.
• The following slides will show how these Primitives are
exchanged.
July 15
L2_2
10
Confirmed Service Scenario
SAP
Requesting
User
Requesting
User
SAP
Accepting
User
Accepting
User
Service
Provider
July 15
L2_2
11
1. Service Request
SAP
Requesting
User
Requesting
User
Accepting
User
SAP
Accepting
User
service.REQUEST
Service
Provider
July 15
L2_2
12
2. Service Indication
SAP
SAP
Requesting
User
Requesting
User
Accepting
User
Accepting
User
service.REQUEST
service.INDICATION
Service
Provider
July 15
L2_2
13
3. Service Response
SAP
SAP
Requesting
User
Requesting
User
Accepting
User
Accepting
User
service.REQUEST
service.INDICATION
service.RESPONSE
Service
Provider
July 15
L2_2
14
4. Service Confirmation
SAP
SAP
Requesting
User
Requesting
User
Accepting
User
Accepting
User
service.REQUEST
service.INDICATION
service.RESPONSE
Service
Provider
July 15
service.CONFIRMATION
L2_2
15
Data Transfer by Encapsulation (I)
• Consider that a Service Provider is asked to transfer some data to the
Remote Service User.
• User-data are termed a Service Data Unit (SDU).
• The Service Provider adds a small header to the user-data. This header
is called Protocol Control Information (PCI). It identifies the data to
be transferred.
• The resulting object is called a Protocol Data Unit.
PCI
SDU
PDU
PDU
July 15
L2_2
16
Data Transfer by Encapsulation (II)
• Next, the (N-1) Service Provider must be invoked. To do this, the
Interface Control Information (ICI) is attached to the Protocol Data
Unit (PDU).
• The ICI identifies the Service Primitive to be invoked from the (N-1)Layer Service.
• The resulting object is called an Interface Data Unit (IDU).
PDU
PDU
ICI
IDU
July 15
IDU
L2_2
17
Data Transfer by Encapsulation (III)
• The (N-1) Service Provider receives the Interface Data Unit (IDU) and
breaks it apart into the ICI and the (N-1) SDU.
• It then invokes the desired primitive, based on the ICI.
IDU
IDU
PDU
ICI
PDU
ICI
July 15
L2_2
18
Data Transfer by Encapsulation (IV)
• At the other end, the process is performed in the
reverse order.
July 15
L2_2
19
Service Types
• Services are classified in two classes:
– Connection-oriented Services
– Connectionless Services
• Examples of these services are:
– Connection-oriented Services: Speech Communication
– Connectionless Services: Packet Data Communication
• UTRAN provides both types of services
July 15
L2_2
20
Connection-oriented Services
A service of this kind goes through three distinct
phases:
• Connection Establishment
• Data Transfer
• Connection Release
July 15
L2_2
21
Connection-oriented Services
Phase 1: Establishment
• In this phase, the users negotiate the conditions in which
the service will be provided.
• Typical conditions to negotiate include:
– Data rate
– Target Bit Error Rate
– Maximum Admissible Delay
• If the negotiation is succesful, a Connection is established.
• The Connection remains available until a Release is
requested (or a failure occurs).
• Typically, all Layers provide a connection establishment
service, using the verb Connect.
July 15
L2_2
22
Connection-oriented Services
Phase 2: Data Transfer
• During this stage, the users exchange data.
• Third Generation Mobile Systems allow, during this phase,
to change the conditions under which data are transferred.
• This is required in order to maintain a Multi-media
Communication, where the requirements in terms of data
type and speed may change during the Call.
July 15
L2_2
23
Connection-oriented Services
Phase 3: Connection Release (I)
• In this phase, the Data Transfer comes to an end.
• Layers provides 3 types of Connection Release
Services:
– RELEASE
– ABORT
– P-ABORT
July 15
L2_2
24
Connection-oriented Services
Phase 3: Connection Release (II)
• The RELEASE service provides a graceful degradation of
the connection. Any service primitives queued for delivery
are drained prior to the binding being destroyed. This is a
confirmed service.
• The ABORT service provides for a user-initiated
immediate release of the connection. Service primitives
queued for delivery may or may not be drained prior to the
binding being destroyed. This is an unconfirmed service.
• The P-ABORT (provider-service abort) is a providerinitiated service that also results in an immediate release of
the connection. This is usually triggered by an underlying
failure.
July 15
L2_2
25
Connectionless Services
• This service has only one phase: Data Transfer
• Resources (radio channels, etc.) are only allocated by the
network for a certain amount of data. If more data needs to
be transferred, a new connectionless service needs to take
place.
• Connectionless services are also known as Packet
Communication services.
• Some second generation mobile networks provide these
kinds of services:
– Global Packet Radio Service (GPRS) in GSM.
– CDPD in the US standard.
July 15
L2_2
26
Protocol Architecture
Overview
July 15
Raul Bruzzone
27
UTRA Architecture
Non-Access Stratum
GC
Nt
GC
DC
Nt
DC
Access Stratum
UE
July 15
Radio
(Uu)
UTRAN
L2_1
Iu
Core Network
28
Service Access Points
GC GC Nt
GC GC Nt Nt DC DC
Nt DC DC
• GC: General Control
• Nt: Notification
• DC: Dedicated Control
July 15
L2_1
29
Transport Channels
• The Services provided by Layer 1 to Layer 2 are called
Transport Channels.
• The part of layer 2 that directly interfaces with Layer 1 is
called Medium Access Control (MAC) sub-layer.
MAC
L2/MAC
Transport
Channels
PHY
July 15
L2_1
L1
30
Logical Channels
U-plane information
C-plane signalling
RLC
RLC
RLC
L2/RLC
RLC
RLC
RLC
RLC
RLC
Logical
Channels
MAC
L2/MAC
Transport
Channels
PHY
July 15
L2_1
L1
31
Logical Channels
• The upper part of layer 2, that directly interfaces with the
Medium Access Control (MAC) sub-layer, is called Radio
Link Control (RLC) sub-layer.
• The Services provided by the Medium Access Control
(MAC) sub-layer to the Radio Link Control sub-layers are
called Logic Channels.
July 15
L2_1
32
RLC Instances in UTRAN
UTRAN
UEs
U-plane
information
C-plane signalling
L2/RLC
Logical
Channels
MAC
L2/MAC
Transport
Channels
PHY
July 15
Raul Bruzzone
L1
33
Layer 3: Radio Resource Control (RRC)
U-plane information
C-plane signalling
GC
Nt
DC
L3
RRC
RLC
RLC
RLC
L2/RLC
RLC
RLC
RLC
RLC
RLC
Logical
Channels
MAC
L2/MAC
Transport
Channels
PHY
July 15
L2_1
L1
34
Configuration Control Connections
GC
Nt
DC
L3
control
control
control
RRC
RLC
RLC
RLC
L2/RLC
RLC
RLC
RLC
RLC
RLC
Logical
Channels
MAC
L2/MAC
Transport
Channels
PHY
July 15
L2_1
L1
35
UTRAN Radio Interface Protocol
Architecture
U-plane information
C-plane signalling
GC
Nt
DC
L3
control
control
control
RRC
RLC
RLC
RLC
L2/RLC
RLC
RLC
RLC
RLC
RLC
Logical
Channels
MAC
L2/MAC
Transport
Channels
PHY
July 15
L2_1
L1
36
Layer 1:
Functions and Services
July 15
Raul Bruzzone
37
A review of Physical Layer Functions (I)
• Macro-diversity distribution/combining and soft handover execution
• Error detection on transport channels and indication to higher layers
• FEC encoding/decoding and interleaving/de-interleaving of transport
channels
• Multiplexing of transport channels and demultiplexing of coded
composite transport channels
• Rate matching
• Mapping of coded composite transport channels on physical channels
July 15
L2_1
38
A review of Physical Layer Functions (II)
•Power weighting and combining of physical channels
•Modulation and spreading/demodulation and despreading of physical
channels
•Frequency and time (chip, bit, slot, frame) synchronization
•Measurements and indication to higher layers (e.g. FER, SIR,
interference power, transmit power, etc.)
•Closed-loop power control
•RF processing
July 15
L2_1
39
Transport Channels
• The Services provided by Layer 1 to Layer
2 are called Transport Channels.
MAC
L2/MAC
Transport
Channels
PHY
July 15
L2_1
L1
40
Transport Channel Types
Transport Channel identification may be based on:
• The Physical Channel used for data transport. In this
case, the Physical Channel properties are used for
identification:
– Carrier Frequency and Spreading Code (FDD)
– Carrier Frequency, Spreading Code and Time Slot (TDD)
This class of channels is called Dedicated Channels.
• In-band identification. This class of channels is called
Common Channels.
July 15
L2_1
41
Transport Channels
Common Transport Channels
Random Access Channel
(RACH)
Dedicated Transport Channels
Dedicated Channels
(DCH)
ODMA Random Access Channel
(ORACH)
Fast Uplink Signalling Channel
(FAUSCH)
Forward Access Channel
(FACH)
Downlink Shared Channels
(DSCH)
ODMA Dedicated Channel
(ODCH)
Downlink Shared Control Channel
(DSCCH)
Uplink Shared Channel
(USCH)
Broadcast Channel
(BCH)
Synchronisation Channel
(SCH)
Paging Channel
(PCH)
July 15
L2_1
42
Random Access Channel (RACH)
•
•
•
•
Used by the UE for initial access to the fixed network.
Used to upload small amounts of non-real-time data.
Only available in the Uplink.
Contention based.
July 15
L2_1
43
ODMA Random Access Channel (ORACH)
• Used by UEs for relaying data.
• Contention based
July 15
L2_1
44
Forward Access Channel (FACH)
• Used by the BS to transmit small amounts of data.
• Available only in the Downlink.
• No closed-loop power control.
July 15
L2_1
45
Downlink Shared Channel (DSCH)
• Shared by several UEs.
• It carries dedicated data or control information.
July 15
L2_1
46
Downlink Shared Control Channel
• It is always associated with a Downlink Shared Channel
(DSCH).
• It provides information on resources allocation for the
associated DSCH.
July 15
L2_1
47
Uplink Shared Channel (USCH)
• Uplink channel shared by several UEs.
• It carries dedicated user or signalling data.
• Only available in TDD mode.
July 15
L2_1
48
Broadcast Channel
• Used by the Base Station to distribute general information
to all the UEs camping in its cell.
July 15
L2_1
49
Synchronisation Channel
• Used by the Base Station to distribute synchronisation
information to all the UEs camping in its cell.
• Only available in TDD mode.
July 15
L2_1
50
Paging Channel (PCH)
• Used by the Base Station to inform a specific UE about a
network-originated call.
• Transmitted on an intermitent basis, in order to facilitate
Sleeping Mode at the UEs.
July 15
L2_1
51
Dedicated Channel
• Used to communicate data between UTRAN and a specific
UE.
• Available in both uplink and downlink.
July 15
L2_1
52
Fast Uplink Signalling Channel (FAUSCH)
• Uplink channel used to allocate dedicated channels.
• Operates in conjunction with the Forward Access Channel
(FACH).
July 15
L2_1
53
ODMA Dedicated Channel
• Assigned to a specific UE for relaying purpose.
July 15
L2_1
54
Medium Access Control
(MAC) Sub-layer:
Functions and Services
July 15
Raul Bruzzone
55
Inside MAC
• MAC is, in fact, a set of several independent entities.
• Six types of entities have been identified.
• The functions implemented by each entity are different in
the UE than from UTRAN.
• MAC configuration is performed by the Radio Resource
Control (RRC) layer (Layer 3).
MAC
MAC-b
July 15
MAC-p
MAC-c
MAC-d
L2_3
MAC-sh
MAC-sy
56
MAC Entities (I)
• MAC-b identifies the MAC entity that handles the Broadcast Channel
(BCH). There is one MAC-b entity in each UE and one MAC-b in the
UTRAN for each cell.
• MAC-p identifies the MAC entity that handles the Paging Channel
(PCH). There is one MAC-p entity in each UE and one MAC-p in the
UTRAN for each cell.
• MAC-c identifies the MAC entity that handles the Forward Access
Channel (FACH) and the Random Access Channel (RACH). There is
one MAC-c entity in each UE and one in the UTRAN for each cell.
MAC
MAC-b
July 15
MAC-p
MAC-c
MAC-d
L2_3
MAC-sh
MAC-sy
57
MAC Entities (II)
•
MAC-d denotes the MAC entity that is responsible for handling of Dedicated
Logical Channels and Dedicated Transport Channels (DCH) allocated to a UE.
There is one MAC-d entity in the UE and one MAC-d entity in the UTRAN
for each UE.
•
MAC-sh denotes the MAC entity that handles Downlink Shared Channels
(DSCH) for both FDD and TDD and Uplink Shared Channels (USCH) for
TDD . There is one MAC-sh entity in each UE that is using a DSCH and a
USCH for TDD operation and one MAC-sh entity in the UTRAN for each cell
that contains a DSCH and a USCH for TDD operation.
•
MAC-sy identifies the MAC entity used in TDD operation to handle the
information received on the Synchronisation Channel SCH.
MAC
MAC-b
July 15
MAC-p
MAC-c
MAC-d
L2_3
MAC-sh
MAC-sy
58
Connectivity of Broadcast, Paging and
Synchronisation Channels
BCCH
MAC-b
UTRAN
MAC
Control
PCCH
SCCH
MAC-p
MAC-sy
PCH
SCH
BCH
UE
Radio Link
Control
(RLC)
Medium
Access
Control
(MAC)
Layer 1
July 15
L2_3
59
Connectivity of FACH, RACH, USCH and
Dedicated Channels
DTCH
DTCH
DCCH
MAC
Control
CCCH
TDD only
MAC-d
MAC-c
MAC-sh
FACH RACH
USCH DSCH
( TDD only )
UE
Radio Link
Control
(RLC)
Medium
Access
Control
(MAC)
UTRAN
July 15
L2_3
DCH DCH
Layer 1
60
Inside MAC-c
MAC
Control
CCCH
UE
MAC-c
to MAC –d
to MAC –sh (2)
add/read
c-RNTI
C/D MUX
UL: TF
selection
ASC Selection (1)
UTRAN
RACH
July 15
L2_3
FACH
61
MAC Layer - UTRAN side
MAC Control
DCCH
DTCH
CCCH
MAC
Control
DTCH
Controlling
RNC
Serving
RNC
TDD only
MAC-d
MAC-c
FACH
RACH
MAC-sh
USCH
DCH
DSCH
DCH
TDD only
July 15
L2_3
62
MAC DATA
Protocol Data Unit (PDU)
MAC header
C/D
UE-Id
MAC SDU
MAC SDU
C/T
• The MAC Service Data Unit (SDU) contains the data
originated at the upper layer.
July 15
L2_3
63
MAC DATA
Protocol Data Unit (PDU): C/D Field
C/D
UE-Id
MAC SDU
C/T
• The C/D field is a single-bit flag that provides
identification of the logical channel class on FACH and
RACH transport channels, i.e. whether it carries CCCH or
dedicated logical channel information.
July 15
C/D field
Designation
1
CCCH
0
DCCH or DTCH
L2_3
64
MAC DATA
Protocol Data Unit (PDU): UE-Id Field
C/D
UE-Id
MAC SDU
C/T
• The UE-Id field provides an identifier of the UE .
July 15
L2_3
65
MAC DATA
Protocol Data Unit (PDU): UE-Id Field
C/D
UE-Id
MAC SDU
C/T
• The C/T field provides identification of the logical channel
instance when multiple logical channels are carried on the
same transport channel.
C/T field
(e.g. 4 bits )
0000
0001
...
1111
July 15
Designation
Logical
channel 1
Logical
channel 2
...
Logical
channel 16
L2_3
66
MAC Sub-layer Functions (I)
• 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
• Priority handling between data flows of several users on
the the DSCH and FACH
• Scheduling of broadcast, paging and notification messages
• Identification of UEs on common transport channels
July 15
L2_3
67
MAC Sub-layer Functions (II)
• 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
• Monitoring the links of the assigned resources
• Routing of higher layer signalling
• Maintenance of a MAC signalling connection between
peer MAC entities
• Dynamic Transport Channel type switching
July 15
L2_3
68
MAC Sub-layer Functions (III)
The following potential functions are regarded as further
study items:
• Constrained execution of open loop power control
algorithms
• Processing of messages received at common control
channels
• Successive Transmission on RACH
• Ciphering
• Access Service Class selection for RACH transmission.
July 15
L2_3
69
Logical Channels Structure
Logical Channels
Common Channels
Dedicated Channels
Synchronisation Control Channel
(SCCH)
Dedicated Traffic Channels
(DTCH)
Broadcast Control Channel
(BCCH)
ODMA Dedicated Traffic
Channels (ODTCH)
Paging Control Channel
(PCCH)
Dedicated Control Channels
(DCCH)
Common Traffic Channels
(CTCH)
Common Control Channel
(CCCH)
ODMA Dedicated Control Channel
(ODCCH)
ODMA Common Control Channel
(ODCCH)
July 15
L2_1
70
Logical channels mapped onto transport channels
(seen from the UE side)
SCCHSAP
BCCHSAP
PCCHSAP
SCH
BCH
PCH
DCCHSAP
FAUSCH RACH
CCCHSAP
FACH USCH
(TDD only)
(TDD only)
DTCHSAP
DSCH DCH
Logical
Channels
Transport
Channels
MAC SAPs
July 15
L2_1
71
Logical channels mapped onto transport channels
(seen from the UTRAN side)
SCCHSAP
BCCHSAP
PCCHSAP
SCH
BCH
PCH
DCCHSAP
FAUSCH RACH
CCCHSAP
FACH USCH
(TDD only)
(TDD only)
DTCHSAP
DSCH
DCH
Logical
Channels
Transport
Channels
MAC SAPs
July 15
L2_1
72
Logical channels mapped onto transport channels
(seen from the UE side, Relay only)
ODCCHSAP
OCCCHSAP
ODTCHSAP
Logical
Channels
Transport
Channels
ORACH
ODCH
MAC SAPs
July 15
L2_1
73
Radio Link Control (RLC)
Sub-layer:
Functions and Services
Base
Station
User
Equipment
July 15
Raul Bruzzone
74
General Concepts on Link Control
• Segmentation and Re-assembly
• Error Detection and Correction
• Flow Control
July 15
L2_1
75
Segmentation and Re-assembly
• The maximum length of frames is usually limited by:
– The Optimum transmission length required by Lower
Layers (e.g. MAC)
– The Size of available Buffers
• When the length of a message exceeds the maximum
allowable size of the frame, the message must be
segmented and sent over several frames. This process is
called Segmentation.
• Conversely, the message must be re-assembled at the other
end. This process is called Re-assembly.
July 15
L2_1
76
Segmentation
Upper Layer Message
1
Segmentation
1
1
0
More Bit
1 This Frame is not the last of the Message
Direction of Transmission
0 This Frame is the last of the Message
July 15
L2_1
77
Re-assembly
1
1
1
0
Re-assembly
Upper Layer Message
July 15
L2_1
78
Error Detection and Correction
• The Link Layer improves the transmission quality by
detecting frames with errors, and asking for repetition.
• Error Detection is implemented by means of a sequence of
redundancy bits. This sequence is called Frame Check
Sequence (FCS).
• Error Detection serves two purposes:
– To provide information on the likelihood of errors in a frame
– To monitor the quality of the link, triggering alarms when it
exceeds a specific threshold.
July 15
L2_1
79
Error Detection and Correction
• Error Detection and Correction is based on retransmission
of frames that are received with errors.
• Frames receive a cyclic number, which enables the
recipient to:
– To detect possible repetitions and/or losses of frames
– To acknowledge specific frames.
• The acknowledgement is done by the receiver by means of
transmitting to the sender, the number of the next expected
frame: N(R).
July 15
L2_1
80
Error Detection and Correction
Repetition Rules
Repetition is triggered by the sender in two cases:
• When it does not receive an ACK after a certain
amount of time.
• When it receives an ACK for a frame which is not
the last one sent.
July 15
L2_1
81
Error Detection and Correction
Timers
The repetition process is based on two timers located at the
Sender:
• Supervision Timer: measures the time between successive
checks of ACKs
• Expiry Timer: measures the maximum allowable time to
receive the ACK of a specific message
July 15
L2_1
82
Flow Control
• Flow Control procedures allow a Recipient Entity to send
back to the Transmitting Entity a message asking to
reduced (or even stop) data delivery:
Data Flow
Flow Control Feedback
• This control mechanism avoids that a local overload could
produce the colapse of the whole system.
July 15
L2_1
83
UTRAN Radio Interface Protocol
Architecture
U-plane information
C-plane signalling
GC
Nt
DC
L3
control
control
control
RRC
RLC
RLC
RLC
L2/RLC
RLC
RLC
RLC
RLC
RLC
Logical
Channels
MAC
L2/MAC
Transport
Channels
PHY
July 15
L2_1
L1
84
Data Transfer Modes provided by RLC
RLC is able to transmit higher layer Protocol Data Units (PDUs)
according to three kinds of data communication services:
• Transmission without adding any protocol information, although
including (if required) segmentation/re-assembly functionality. This
mode is called Transparent Data Transfer.
• Transmission without guaranteeing delivery to the peer entity (i.e. no
notification to the sender in case of bad reception). This mode is
called Un-acknowledged Data Transfer.
• Transmission ensuring delivery to the peer entity: In case RLC is
unable to deliver the data correctly, the user of RLC at the transmitting
side is notified. This mode is called Acknowledged Data Transfer.
July 15
L2_1
85
Un-acknowledged Data Transfer Mode
The unacknowledged data transfer mode has the following
characteristics:
• Detection of erroneous data: The RLC sub-layer delivers
only those SDUs to the receiving higher layer that are free
of transmission errors by using a sequence-number check
function.
• Unique delivery: The RLC sub-layer delivers each Service
Data Unit (SDU) only once to the receiving upper layer,
using duplication detection function.
• Immediate delivery: The receiving RLC sub-layer entity
delivers a Service Data Unit (SDU) to the higher layer
receiving entity as soon as it arrives at the receiver.
July 15
L2_1
86
Acknowledged Data Transfer Mode
The acknowledged data transfer mode has the following characteristics:
• Error-free delivery: it is ensured by means of retransmission. The
receiving RLC entity delivers only error-free Service Data Units
(SDUs) to the higher layer.
• Unique delivery: RLC delivers each SDU only once to the receiving
upper layer, using a duplication detection function.
• In-sequence delivery: RLC ensures in-order delivery of SDUs, i.e.,
RLC delivers SDUs to the receiving higher layer entity in the same
order as the transmitting higher layer entity submits them to its RLC
sub-layer.
• Out-of-sequence delivery: Alternatively to in-sequence delivery, it is
also possible to instruct the receiving RLC entity to deliver SDUs to
its higher layer in different order than submitted to RLC sub-layer at
the transmitting side.
July 15
L2_1
87
Other Services provided by RLC
to Upper Layers
• RLC connection establishment/release. This service
performs establishment/release of RLC connections.
• QoS setting. The retransmission protocol is configurable
by layer 3 to provide different levels of QoS. This can be
controlled.
• Notification of unrecoverable errors. RLC notifies the
upper layer of errors which cannot be resolved by RLC
itself by normal exception handling procedures. e.g. by
adjusting the maximum number of retransmissions
according to delay requirements
July 15
L2_1
88
RLC Sub-layer Architecture
The RLC sub-layer is implemented by means of several
independent entities:
• Transparent Mode (Tr) Entities
• Un-acknowledged Mode (UM) Entities
• Acknowledged Mode (AM) Entities
July 15
L2_1
89
RLC Sub-layer Architecture
• Transmitting and receiving entities for Transparent Modes
exist at both sides of the Radio Interface:
UE
UTRAN
Higher
Layer
Radio Interface
Receiv.
Tr-Entity
Transm.
Tr-Entity
Receiv.
Tr-Entity
RLC
Transm.
Tr-Entity
MAC
July 15
L2_4
90
RLC Sub-layer Architecture
• Transmitting and receiving entities for Un-acknowledged
Mode (UM) exist at both sides of the Radio Interface:
UE
UTRAN
Higher
Layer
Radio Interface
Receiv.
UM-Entity
Transm.
UM-Entity
Receiv.
UM-Entity
RLC
Transm.
UM-Entity
MAC
July 15
L2_4
91
RLC Sub-layer Architecture
• There is one combined transmitting and receiving entity
for the acknowledged mode service:
UE
UTRAN
Higher
Layer
Radio Interface
AM-Entity
RLC
AM-Entity
MAC
July 15
L2_4
92
RLC Sub-layer Architecture
The complete RLC architecture is:
AM-Entity
Receiv.
UM-Entity
Receiv.
Tr-Entity
Transm.
Tr-Entity
Transm.
UM-Entity
AM-Entity
Receiv.
UM-Entity
Receiv.
Tr-Entity
RLC
Transm.
UM-Entity
Higher
Layer
Transm.
Tr-Entity
UTRAN
Radio Interface
UE
MAC
July 15
L2_4
93
Transparent-Mode Entities
Radio Interface
Tr-SAP
Tr-SAP
Transm.
Entity
Receiving
Entity
Segmentation
Re-assembly
Transmission
buffer
Receiver
buffer
BCCH/PCCH/
CCCH/DTCH
July 15
BCCH/PCCH/
CCCH/DTCH
L2_4
94
Transparent-Mode Entity Operation
• The transmitting Tr-entity
receives SDUs from the higher
layers through the Tr-SAP.
Radio Interface
SDU
Tr-SAP
July 15
L2_4
95
Transparent-Mode Entity Operation
•
The transmitting Tr-entity receives SDUs from the
higher layers through the Tr-SAP.
•
RLC segments the SDUs into
appropriate RLC PDUs without
adding any overhead.
Radio Interface
SDU
Tr-SAP
Transm.
Entity
Segmentation
July 15
L2_4
96
Transparent-Mode Entity Operation
•
•
•
The transmitting Tr-entity receives SDUs from the
higher layers through the Tr-SAP.
RLC segments the SDUs into appropriate RLC
PDUs without adding any overhead.
Radio Interface
SDU
Tr-SAP
The PDU is stored in a Transmission
Buffer, waiting for available radio
transmission capacity.
Transm.
Entity
Segmentation
Transmission
buffer
July 15
L2_4
97
Transparent-Mode Entity Operation
•
•
•
•
The transmitting Tr-entity receives SDUs from the
higher layers through the Tr-SAP.
RLC segments the SDUs into appropriate RLC
PDUs without adding any overhead.
The PDU is stored in a Transmission Buffer,
waiting for available radio transmission capacity.
RLC delivers the RLC PDUs to
MAC through either a BCCH, PCCH
or a DTCH.
Radio Interface
SDU
Tr-SAP
Transm.
Entity
Segmentation
Transmission
buffer
July 15
L2_4
98
Transparent-Mode Entity Operation
•
•
•
•
•
The transmitting Tr-entity receives SDUs from the
higher layers through the Tr-SAP.
RLC segments the SDUs into appropriate RLC
PDUs without adding any overhead.
The PDU is stored in a Transmission Buffer,
waiting for available radio transmission capacity.
RLC delivers the RLC PDUs to MAC through
either a BCCH, PCCH or a DTCH.
MAC transmits the data to its peer
entity located at the other side of the
Radio Interface.
Radio Interface
SDU
Tr-SAP
Transm.
Entity
Segmentation
Transmission
buffer
BCCH/PCCH/
CCCH/DTCH
July 15
L2_4
BCCH/PCCH/
CCCH/DTCH
99
Transparent-Mode Entity Operation
•
•
•
•
•
•
The transmitting Tr-entity receives SDUs from the
higher layers through the Tr-SAP.
RLC segments the SDUs into appropriate RLC
PDUs without adding any overhead.
The PDU is stored in a Transmission Buffer,
waiting for available radio transmission capacity.
RLC delivers the RLC PDUs to MAC through
either a BCCH, PCCH or a DTCH.
MAC transmits the data to its peer entity located at
the other side of the Radio Interface.
The Receiving entity receives PDUs
through from one of the logical
channels from the MAC sub-layer.
The information is stored in a Buffer.
Radio Interface
SDU
Tr-SAP
Transm.
Entity
Receiving
Entity
Segmentation
Transmission
buffer
BCCH/PCCH/
CCCH/DTCH
July 15
L2_4
Receiver
buffer
BCCH/PCCH/
CCCH/DTCH
100
Transparent-Mode Entity Operation
•
•
•
•
•
•
•
The transmitting Tr-entity receives SDUs from the
higher layers through the Tr-SAP.
RLC segments the SDUs into appropriate RLC
PDUs without adding any overhead.
The PDU is stored in a Transmission Buffer,
waiting for available radio transmission capacity.
RLC delivers the RLC PDUs to MAC through
either a BCCH, PCCH or a DTCH.
MAC transmits the data to its peer entity located at
the other side of the Radio Interface.
The Receiving entity receives PDUs through from
one of the logical channels from the MAC sublayer. The information is stored in a Buffer.
Radio Interface
SDU
Tr-SAP
Transm.
Entity
Receiving
Entity
Segmentation
Re-assembly
Transmission
buffer
Receiver
buffer
RLC reassembles the PDUs into RLC
SDUs.
BCCH/PCCH/
CCCH/DTCH
July 15
L2_4
BCCH/PCCH/
CCCH/DTCH
101
Transparent-Mode Entity Operation
•
•
•
•
•
•
•
•
The transmitting Tr-entity receives SDUs from the
higher layers through the Tr-SAP.
RLC segments the SDUs into appropriate RLC
PDUs without adding any overhead.
The PDU is stored in a Transmission Buffer,
waiting for available radio transmission capacity.
RLC delivers the RLC PDUs to MAC through
either a BCCH, PCCH or a DTCH.
MAC transmits the data to its peer entity located at
the other side of the Radio Interface.
The Receiving entity receives PDUs through from
one of the logical channels from the MAC sublayer. The information is stored in a Buffer.
RLC reassembles the PDUs into RLC SDUs.
Radio Interface
SDU
SDU
Tr-SAP
Tr-SAP
Transm.
Entity
Receiving
Entity
Segmentation
Re-assembly
Transmission
buffer
Receiver
buffer
The receiving entity transfers the
SDUs to the higher layers through
the Tr-SAP.
BCCH/PCCH/
CCCH/DTCH
July 15
L2_4
BCCH/PCCH/
CCCH/DTCH
102
Un-acknowledged Mode Entity
Radio Interface
Tr-SAP
Tr-SAP
Transm.
Entity
Receiving
Segmentation
Concatenation
RLC Header Addition
Remove RLC Header
Re-assembly
Transmission
buffer
Receiver
buffer
BCCH/PCCH/
CCCH/DTCH
July 15
Entity
BCCH/PCCH/
CCCH/DTCH
L2_4
103
Acknowledged Mode Entity
Receiving Side
Transmitting Side
AM-SAP
AM-Entity
Segmentation
Concatenation
Add RLC Header
RLC Control Unit
Received acknowledgements
Retransmission
buffer &
management
MUX
Transmission
buffer
Remove RLC
Header &
Re-assembly
Acknowledgements
Receiver buffer &
Retransmission
management
Set fields in RLC Header (e.g. set
poll bits)
Demux/Routing
DCCH/
DTCH
July 15
DCCH/
DTCH
DCCH/
DTCH
L2_4
DCCH/
DTCH
DCCH/
DTCH
DCCH/
DTCH
104
Acknowledged Mode Entity
Acknowledgement Communication Path
Receiving Side
Transmitting Side
Transmitting Side
Receiving Side
AM-SAP
Segmentation
Concatenation
RLC Header
Retransm.
buffer
management
MUX
Remove RLC
Header &
Re-assembly
Transmission
buffer
Set fields in RLC Header
(e.g. set poll bits)
DCCH/
DTCH
Acknowledgement
Set fields in RLC Header
(e.g. set poll bits)
Demux/Routing
Demux/Routing
DCCH/
DTCH
DCCH/
DTCH
July 15
Receiver buffer
Retransmission
management
L2_4
105
Acknowledged Mode Entity
Acknowledgement Communication Path
Receiving Side
Transmitting Side
Transmitting Side
Receiving Side
AM-SAP
Segmentation
Concatenation
RLC Header
Retransm.
buffer
management
MUX
Remove RLC
Header &
Re-assembly
Transmission
buffer
Receiver buffer
Retransmission
management
Set fields in RLC Header
(e.g. set poll bits)
DCCH/
DTCH
Set fields in RLC Header
(e.g. set poll bits)
Demux/Routing
Demux/Routing
DCCH/
DTCH
DCCH/
DTCH
Retransmission
July 15
L2_4
106
RLC Services: Comparative Table
Transparent
Mode
• Segmentation / Re-assembly
• Transfer of User Data
Un-acknowledged
Mode
• Segmentation / Re-assembly
• Concatenation
•Transfer of User Data
Acknowledged
Mode
• Segmentation / Re-assembly
• Concatenation
•Transfer of User Data
• Error correction
• In-sequence delivery
• Duplicate detection
• Flow Control
• Error detection and recovery
• QoS setting
• Notific. of unrecov. errors
• Multicast delivery
July 15
L2_4
107
Radio Resource Control
(RRC) Layer:
Functions and Services
July 15
Raul Bruzzone
108
UTRAN Radio Interface Protocol
Architecture
U-plane information
C-plane signalling
GC
Nt
DC
L3
control
control
control
RRC
RLC
RLC
RLC
L2/RLC
RLC
RLC
RLC
RLC
RLC
Logical
Channels
MAC
L2/MAC
Transport
Channels
PHY
July 15
L2_1
L1
109
Radio Resource Control (RRC)
Services
RRC Services are classified in three classes:
• Information Broadcast (General Control Service)
• Paging and Notification Broadcast (Notification Service)
• Establishment/release of a connection and transfer of
messages using this connection (Dedicated Control
Service)
Each class of service has its specific Service Access Point.
July 15
L2_6
110
RRC Functions (I)
• Broadcast of information provided by the non-access
stratum (Core Network)
• Broadcast of information related to the access stratum
• Broadcast of ODMA relay node neighbour information
• Establishment, maintenance and release of an RRC
connection between the UE and UTRAN
• Collating ODMA neighbour list and gradient information
• Maintenance of number of ODMA relay node neighbours.
• Establishment, maintenance and release of a route between
ODMA relay nodes
July 15
L2_1
111
RRC Functions (II)
• Interworking between the Gateway ODMA relay node and
the UTRAN
• Establishment, reconfiguration and release of Radio
Access Bearers
• Assignment, reconfiguration and release of radio resources
for the RRC connection
• RRC connection mobility functions
• Paging/notification
• Routing of higher layer PDUs
July 15
L2_1
112
RRC Functions (III)
•
•
•
•
•
•
•
•
Control of requested QoS
UE measurement reporting and control of the reporting
Outer loop power control
Control of ciphering
Slow Dynamic Channel Allocation
Contention resolution
Arbitration of radio resources on uplink DCH
Initial cell selection and re-selection in idle mode
July 15
L2_1
113
Model of RRC (UE side)
Non Access Stratum
BCFE:
DCFE:
PNFE:
RFE:
TME:
Broadcast Control Functional Entity
Dedicated Control Functional Entity
Paging and Notification Control Functional Entity
Routing Functional Entity
Traffic Multiplexing Entity
GC-SAP
...
...
...
...
...
...
Nt-SAP
DC-SAPDC-SAP
Nt-SAP
RFE
RFE
RFE
BCFE
PNFE
DCFE
GC-SAP
GC-SAP Nt-SAP
DC-SAP
RRC
TME
Tr-SAP
UM SAP
AM SAP
RLC-ctrl
RLC
MAC
MAC
UTRAN
July 15
MAC-ctrl
L1-ctrl
L1
L2_6
114
Model of RRC (UE side)
Routing Function Entity (RFE)
Non Access Stratum
• Routing of higher layer
messages to different Man
Machine/Communication
Management (MM/CM)
entities is handled by the
Routing Function Entities
(RFE).
GC-SAP
...
...
...
...
...
...
Nt-SAP
DC-SAPDC-SAP
Nt-SAP
RFE
RFE
RFE
BCFE
PNFE
DCFE
GC-SAP
GC-SAP Nt-SAP
DC-SAP
RRC
TME
Tr-SAP
UM SAP
AM SAP
RLC-ctrl
RLC
MAC
MAC
MAC-ctrl
L1-ctrl
L1
July 15
L2_6
115
Model of RRC (UE side)
Broadcast Control Function Entity (BCFE)
Non Access Stratum
GC-SAP
• Broadcast functions are
handled in the Broadcast
Control Function Entity
(BCFE).
...
...
...
...
...
...
Nt-SAP
DC-SAPDC-SAP
Nt-SAP
RFE
RFE
RFE
BCFE
PNFE
DCFE
GC-SAP
GC-SAP Nt-SAP
DC-SAP
RRC
TME
Tr-SAP
UM SAP
AM SAP
RLC-ctrl
RLC
MAC
MAC
MAC-ctrl
L1-ctrl
L1
July 15
L2_6
116
Model of RRC (UE side)
Broadcast Control Function Entity (BCFE)
Non Access Stratum
• BCFE offers RRC services
by the GC-SAP
GC-SAP
• Broadcast functions are
handled in the Broadcast
Control Function Entity
(BCFE).
...
...
...
...
...
...
Nt-SAP
DC-SAPDC-SAP
Nt-SAP
RFE
RFE
RFE
BCFE
PNFE
DCFE
GC-SAP
GC-SAP Nt-SAP
DC-SAP
RRC
TME
Tr-SAP
UM SAP
AM SAP
RLC-ctrl
RLC
MAC
MAC
MAC-ctrl
L1-ctrl
L1
July 15
L2_6
117
Model of RRC (UE side)
Broadcast Control Function Entity (BCFE)
Non Access Stratum
• BCFE offers RRC services
by the GC-SAP
GC-SAP
• Broadcast functions are
handled in the Broadcast
Control Function Entity
(BCFE).
...
...
...
...
...
...
Nt-SAP
DC-SAPDC-SAP
Nt-SAP
RFE
RFE
RFE
BCFE
PNFE
DCFE
GC-SAP
GC-SAP Nt-SAP
DC-SAP
RRC
TME
• BCFE uses the lower layer
services provided by TrSAP.
Tr-SAP
UM SAP
AM SAP
RLC-ctrl
RLC
MAC
MAC
MAC-ctrl
L1-ctrl
L1
July 15
L2_6
118
Model of RRC (UE side)
Paging and Notification Control Function Entity (PNFE)
Non Access Stratum
GC-SAP
• Paging of idle mode UE(s)
is controlled by the paging
and notification control
function entity (PNFE)
...
...
...
...
...
...
Nt-SAP
DC-SAPDC-SAP
Nt-SAP
RFE
RFE
RFE
BCFE
PNFE
DCFE
GC-SAP
GC-SAP Nt-SAP
DC-SAP
RRC
TME
Tr-SAP
UM SAP
AM SAP
RLC-ctrl
RLC
MAC
MAC
MAC-ctrl
L1-ctrl
L1
July 15
L2_6
119
Model of RRC (UE side)
Paging and Notification Control Function Entity (PNFE)
Non Access Stratum
• PNFE offers RRC services
by the Nt-SAP
GC-SAP
• Paging of idle mode UE(s)
is controlled by the paging
and notification control
function entity (PNFE)
...
...
...
...
...
...
Nt-SAP
DC-SAPDC-SAP
Nt-SAP
RFE
RFE
RFE
BCFE
PNFE
DCFE
GC-SAP
GC-SAP Nt-SAP
DC-SAP
RRC
TME
Tr-SAP
UM SAP
AM SAP
RLC-ctrl
RLC
MAC
MAC
MAC-ctrl
L1-ctrl
L1
July 15
L2_6
120
Model of RRC (UE side)
Paging and Notification Control Function Entity (PNFE)
Non Access Stratum
• PNFE offers RRC services
by the Nt-SAP
GC-SAP
• Paging of idle mode UE(s)
is controlled by the paging
and notification control
function entity (PNFE)
...
...
...
...
...
...
Nt-SAP
DC-SAPDC-SAP
Nt-SAP
RFE
RFE
RFE
BCFE
PNFE
DCFE
GC-SAP
GC-SAP Nt-SAP
DC-SAP
RRC
TME
• BCFE uses the lower layer
services provided by TrSAP.
Tr-SAP
UM SAP
AM SAP
RLC-ctrl
RLC
MAC
MAC
MAC-ctrl
L1-ctrl
L1
July 15
L2_6
121
Model of RRC (UE side)
Dedicated Control Function Entity (DCFE)
Non Access Stratum
GC-SAP
• The Dedicated Control
Function Entity (DCFE)
handles all functions
specific to one UE
...
...
...
...
...
...
Nt-SAP
DC-SAPDC-SAP
Nt-SAP
RFE
RFE
RFE
BCFE
PNFE
DCFE
GC-SAP
GC-SAP Nt-SAP
DC-SAP
RRC
TME
Tr-SAP
UM SAP
AM SAP
RLC-ctrl
RLC
MAC
MAC
MAC-ctrl
L1-ctrl
L1
July 15
L2_6
122
Model of RRC (UE side)
Dedicated Control Function Entity (DCFE)
Non Access Stratum
• DCFE offers RRC services
by the DC-SAP
GC-SAP
• The Dedicated Control
Function Entity (DCFE)
handles all functions
specific to one UE
...
...
...
...
...
...
Nt-SAP
DC-SAPDC-SAP
Nt-SAP
RFE
RFE
RFE
BCFE
PNFE
DCFE
GC-SAP
GC-SAP Nt-SAP
DC-SAP
RRC
TME
Tr-SAP
UM SAP
AM SAP
RLC-ctrl
RLC
MAC
MAC
MAC-ctrl
L1-ctrl
L1
July 15
L2_6
123
Model of RRC (UE side)
Dedicated Control Function Entity (DCFE)
Non Access Stratum
• DCFE offers RRC services
by the DC-SAP.
GC-SAP
• The Dedicated Control
Function Entity (DCFE)
handles all functions
specific to one UE.
...
...
...
...
Nt-SAP
RFE
RFE
RFE
BCFE
PNFE
DCFE
GC-SAP Nt-SAP
DC-SAP
RRC
TME
• DCFE can use lower layer
services of UM, AM and
Tr-SAP depending on the
message to be sent and on
the current UE service
state.
July 15
...
...
DC-SAPDC-SAP
Nt-SAP
GC-SAP
Tr-SAP
UM SAP
AM SAP
RLC-ctrl
RLC
MAC
MAC
MAC-ctrl
L1-ctrl
L1
L2_6
124
Conclusions
July 15
Raul Bruzzone
125
UTRA Architecture
Non-Access Stratum
GC
Nt
GC
DC
Nt
DC
Access Stratum
UE
July 15
Radio
(Uu)
UTRAN
L2_1
Iu
Core Network
126
UTRAN Radio Interface Protocol
Architecture
U-plane information
C-plane signalling
GC
Nt
DC
L3
control
control
control
RRC
RLC
RLC
RLC
L2/RLC
RLC
RLC
RLC
RLC
RLC
Logical
Channels
MAC
L2/MAC
Transport
Channels
PHY
July 15
L2_1
L1
127
Layer 1
• The Services provided by Layer 1 to Layer
2 are called Transport Channels.
MAC
L2/MAC
Transport
Channels
PHY
July 15
L2_1
L1
128
Layer 2: Medium Access Control (MAC)
•
MAC-b (Broadcast Channel)
•
MAC-p (Paging Channel)
•
MAC-c (Forward Access, Random Access Channels)
•
MAC-d (Dedicated Channels)
•
MAC-sh (Shared Channels)
•
MAC-sy (Synchronization Channels)
MAC
MAC-b
July 15
MAC-p
MAC-c
MAC-d
L2_3
MAC-sh
MAC-sy
129
Connectivity of Broadcast, Paging and
Synchronisation Channels
BCCH
MAC-b
UTRAN
MAC
Control
PCCH
SCCH
MAC-p
MAC-sy
PCH
SCH
BCH
UE
Radio Link
Control
(RLC)
Medium
Access
Control
(MAC)
Layer 1
July 15
L2_3
130
Layer 2: RLC Segmentation
Upper Layer Message
1
Segmentation
1
1
0
More Bit
1 This Frame is not the last of the Message
Direction of Transmission
0 This Frame is the last of the Message
July 15
L2_1
131
Layer 2: Transparent-Mode Operation
Radio Interface
Tr-SAP
Tr-SAP
Transm.
Entity
Receiving
Entity
Segmentation
Re-assembly
Transmission
buffer
Receiver
buffer
BCCH/PCCH/
CCCH/DTCH
July 15
BCCH/PCCH/
CCCH/DTCH
L2_4
132
Layer 3: Model of RRC (UE side)
Non Access Stratum
BCFE:
DCFE:
PNFE:
RFE:
TME:
Broadcast Control Functional Entity
Dedicated Control Functional Entity
Paging and Notification Control Functional Entity
Routing Functional Entity
Traffic Multiplexing Entity
GC-SAP
...
...
...
...
...
...
Nt-SAP
DC-SAPDC-SAP
Nt-SAP
RFE
RFE
RFE
BCFE
PNFE
DCFE
GC-SAP
GC-SAP Nt-SAP
DC-SAP
RRC
TME
Tr-SAP
UM SAP
AM SAP
RLC-ctrl
RLC
MAC
MAC
UTRAN
July 15
MAC-ctrl
L1-ctrl
L1
L2_6
133
References
July 15
Raul Bruzzone
134
Mobile Radio Data Communication Protocols
References
L2_1
TS RAN S2.01, Radio Interface Protocol Architecture, V0.2.0
3GPP. April, 1999
L2_2
The Open Book. A Practical Perspective on OSI.
Marshall T. Rose
Prentice Hall
L2_3
TS RAN S2.21, MAC Protocol Specification, V0.1.0
3GPP. April, 1999
L2_4
TS RAN S2.22, RLC Protocol Specification V0.1.0
3GPP. April, 1999
L2_5
The GSM System for Mobile Communications
Michel Mouly, Marie-Bernadette Pautet
L2_6
TS RAN 2.31, RRC Protocol Specification, V0.1.0
3GPP. April, 1999
July 15
Raul Bruzzone
135
coming next …
ODMA
Opportunity Driven Multiple Access
Raul Bruzzone