Register 7 - Iu Interface User Plane Protocols PDF

VII.
Iu Interface User Plane Protocols
Iu Interface User Plane Protocols

Module Objectives: Iu User Plane Protocol Iu UP for CS Services, Iu Interface User Data Transfer for PS Services, GTP-U Protocol.
UTRAN and UMTS Radio Protocols
VII. Iu Interface User Plane Protocols
1 Iu User Plane Protocol
1.1 Iu User Plane Protocol Modes and Tasks

The Iu User Plane (Iu UP) protocol is located on Iu-PS and Iu-CS user plane as the highest layer that transports user data. This protocol is considered to be specific to UTRAN, hence it belongs to the so called radio network layer (RNL). Below the radio network layer is the transport network layer (TNL) which is independent of any UMTS related things. On Iu-CS the TNL is built out of AAL2/ATM and on Iu-PS the TNL is formed by GTP-U/UDP/IP/AAL5/ATM. The task of the Iu UP protocol is to decouple the service related user data transport characteristics from the underlying transport network protocols. This shall enable the easy exchange of the transport network protocols (e.g. all IP network without ATM) without any modification of the services. Only the Iu UP protocol has to be adapted to the new transport network. On Iu-PS there is currently no need for an adaptation of the transport services provided by GTP-U/UDP/IP to the session service (PDP context). Hence on Iu-PS the Iu UP protocol is more or less switched off, it does not provide frames or functionality. Of course this might change in future. On Iu-CS one of the main applications are speech calls with mobile specific speech codecs (AMR : Adaptive Multi-rate Codec). These codecs require a special media flow characteristics, which is not provided by AAL2/ATM. So on Iu-CS the Iu UP protocol has to enhance the transport network bearer service with additional functionality (sub-flows).
Menu
UE RNC
CN
RNL-SAP
RNL-SAP
Iu UP
TNL-SAP radio protocols radio protocols TNL-SAP
Iu UP
user plane transport bearer protocols
user plane transport bearer protocols
Iu user plane protocol.
TNL SAP = Transport Network Layer Service Access Point RNL SAP = Radio Network Layer Service Access Point
figure 1 Meaning and location of Iu UP protocol.
The functionality of the Iu UP protocol is divided into so called User Plane Modes. Currently there are two modes defined : Transparent Mode: The transparent mode is characterized by no functionality from the Iu UP protocol. This means there are no frames provided and no functionality can be expected from the protocol. This simply means the protocol is switched off. The Iu-PS user plane utilizes this mode in all current implementations. Support Mode for predefined SDU sizes: This is in the moment the only mode that enables specific Iu UP protocol functionality. The main functionality of this mode is the support of RAB sub-flows and sub-flow combinations. Associated with this the Iu UP protocol can perform a frame quality classification of user data, blocking of certain sub-flow combinations (rate control) and handling of the jitter of user data arrival.
The support mode for predefined SDU sizes works only, when the sizes of the user data frames are predefined, this means for each sub-flow combination all sizes of all subflows are exactly known. This is the case for speech codecs. The user plane modes can be further divided into versions. In UMTS Release 1999 only one version (version 1) exists for both modes. In UMTS Release 4 a version 2 is defined for the support mode.
Iu User Plane Protocol
Transparent Mode Version 1
Support Mode for predefined SDU sizes Version 1 Version 2

(only for UMTS Release 4 and higher)
Iu user plane protocol modes and mode versions.
-Transfer of user data
-Transfer of user data -UP Initialization -Rate Control -Time Alignment -Handling of error events -Frame quality classification
used on Iu-PS
used on Iu-CS
figure 2 Iu UP operation modes and currently available versions with their functionality.
Which of the two user plane modes and which version of this mode shall be used for a radio access bearer is configured by RANAP. In the RAB Assignment Request message the parameter user plane information that is provided for a RAB setup, contains the user plane mode version and user plane mode.
RNC
MSC|SGSN
RANAP: RAB Assignment Request

(Setup: RAB-ID, RAB parameters, User Plane Information = User Plane Mode + supported UP Mode Version)
Configuration of the Iu UP protocol with RANAP.
RANAP: RAB Assignment Response

(Setup Acknowledgement: RAB-ID)
figure 3 Parameters in RAB Assignment procedure affecting the Iu user plane protocol.
1.1.1
Transparent Mode
In transparent mode the Iu UP protocol is bypassed, thus the user data is transparently flowing through the Iu UP protocol layer without any processing.
10
Iu
RNC MSC|SGSN RNL SAP
Radio Interface Protocols Iu UP - TrM

Transparent Iu UP mode.
Iu UP - TrM TNL SAP
TNL SAP
figure 4 Transparent operation mode of Iu UP protocol.
11
1.1.2
Support Mode for Predefined SDU Sizes
In the support mode for predefined SDU sizes the Iu UP protocol enables three categories of functionalities : Frame Handler Function: The frame handler function performs framing and deframing of user data and control messages. Together with that a cyclic redundancy check can be applied to user data. Procedure Control Function: The Iu UP protocol in support mode provides signaling procedures for initialization, rate control, time alignment and error event notification. NAS stream specific functions: These functions are special processing features of user data. In the support mode for predefined SDU sizes version 1 this covers : detection of frame loss, frame quality classification and decision to discard or deliver frames. Additionally frame loss notifications are sent to the data stream consumer (speech codec).
12
Iu
RNC RNL SAP MSC|SGSN
Radio Interface Protocols
NAS stream specific functions
NAS stream specific functions
Support mode for predefined SDU sizes of Iu UP.
Procedure Control Functions
Procedure Control Functions
Frame Handler Function
Frame Handler Function
TNL SAP
TNL SAP
figure 5 Functional architecture of Iu UP protocol for support mode.
13
1.2 Iu UP Support Mode Procedures

1.2.1 User Plane Initialization
When a new RAB is established, the RANAP message RAB Assignment Request contains in the user plane information parameter the configuration of the Iu UP protocol. If this parameter indicates the support mode for predefined SDU sizes, there will be an initialization procedure within the user channel (in-band signaling) after the user channel is set up. The initialization is a procedure of the Iu UP protocol in support mode and is triggered by the RNC with the message Initialization. This message contains the number subflows that have been defined. The RNC will give an identifier for each established RAB sub-flow combination, which is called RFCI (RAB sub-flow combination identifier). For each sub-flow combination the size (length) of each sub-flow inside must be indicated. The MSC has to check the transmitted configuration and shall acknowledge it with Initialization Acknowledgement.
14
RNC RANAP: RAB Assignment Request
MSC|SGSN
(Setup: RAB-ID, RAB parameters, User Plane Mode : Support Mode for predefined SDU sizes)

(Setup Acknowledgement: RAB-ID)
INITIALISATION
( number of defined sub-flows, RFCI for each sub-flow-combination, length of each sub-flow in each sub-flow-combination, Inter PDU Transmission Interval IPTI for each sub-flow-combination)
INITIALISATION ACK
Initialisation 1(3).
figure 6 Initialization procedure.
15
In general the parameter in the Initialization message can be presented in the following way. From the RAB Assignment Request message the Iu UP protocol gets all the information about sub-flows and sub-flow combinations that are applicable to this RAB (RAB parameters). As already mentioned, each sub-flow occurs in each sub-flow combination, but possibly with different sizes. So the Initialization message will contain for each sub-flow combination a RFCI that is used as unique identifier for this combination. The size of each sub-flow in a combination is indicated. Additionally the IPTI (Inter PDU Transmission Interval) which is the mean time between two consecutive user data frames of one sub-flow combination is indicated. This IPTI is typically the size of the SDU for one sub-flow combination divided by the bit rate of this combination.
16
N sub-flows
sub-flowcombination 1
sf 1
sf 2
sf 3
...
sf N
size of subflow N
RFCI=1
IPTI
sub-flowcombination 2 RFCI=2
size size size of of of subsubsubflow 1 flow 2 flow 3
...
IPTI
size size size of of of subsubsubflow 1 flow 2 flow 3 ...
...
size of subflow N
sub-flowcombination X
Initialisation 2(3).
RFCI=X
IPTI
size size size of of of subsubsubflow 1 flow 2 flow 3
...
size of subflow N
figure 7 Sub-flow combination configuration.
17
1.2.2
Transfer of User Data
When the Iu UP protocol for the RAB is configured, user data can be transported using the Iu UP protocol. Therefore the frame of type Transfer Of User Data is provided. This PDU transports the user data as payload and includes the RFCI that indicates according to which subflow combination the payload is built.
18
RNC
MSC|SGSN

(RFCI, payload)

(RFCI, payload)
19
Transfer of User Data.
figure 8 Transfer of user data frames in support mode.
1.2.3
Rate Control Procedure
The rate control procedure is used by the RNC to indicate to the MSC which sub-flow combinations are currently allowed and which are currently permitted. This is done using the Rate Control frame of Iu UP protocol, in which a bitmap can be found. This bitmap specifies for each defined sub-flow combination whether it is blocked (b1) or allowed (b0). With that the serving RNC is able to control the maximum and minimum data rates by enabling and inhibiting certain sub-flow combinations. Usually this functions works together with the control procedures of the AMR (Adaptive Multi-rate Codec). When and how the serving RNC uses this procedure is operator and manufacture specific. Note that in version 2 of the support mode (UMTS Release 4 and higher) also the MSC can send rate control messages.
20
RNC
MSC|SGSN
Rate Control
(RFCI indicator bitmap)
0 0 0 1 1 ...1
RFC X : barred
...
: : : : :
21
Rate Control.
RFC 5 RFC 4 RFC 3 RFC 2 RFC 1
barred barred allowed allowed allowed
figure 9 Rate control procedure.
1.2.4
Time Alignment Procedure
The RNC has to send the downlink data in radio frames that are periodical time slices of 10 ms. So the sending of data in dedicated channels is in fact synchronous. But the MSC sends the data via the Iu bearer based on ATM, so it is possible that the user data arrives at the RNC at irregular intervals (jitter). To compensate this jitter the RNC maintains a jitter buffer. If the jitter becomes too big, the jitter buffer may have a under-run or a over-run. Therefore the RNC can report to late and to early sending to the MSC. This is simply done by the Iu UP protocol message Time Alignment. This message carries a time alignment value which specifies the to late or to early sending in the range of 40 ms to +40 ms in 500 s steps.
22
RNC
MSC|SGSN

bad timing
(RFCI, payload)
Time Alignment
(time alignment)
Time Alignment Acknowledgement

(RFCI, payload)
Time Alignment.
adjusted timing
figure 10 Time alignment for user data with too high jitter.
23
1.2.5
Error Event Procedure
If UE or RNC detect an error in the transmitted downlink data, the error event indication procedure is triggered. The Iu UP protocol provides the Error Event message for this. This message contains an error cause (e.g. wrong SDU sizes, undefined RFCI, etc.) and an error distance. The error distance specifies who detected the error. The error distance 0 is a local error detected by the Iu UP protocol in the RNC. If the failure is detected by other protocols in the RNC (e.g. AMR codec) the error distance is set to 1, if the error indication comes from the UE the error distance is set to 2.
24
RNC
MSC|SGSN
Error Event
(error cause, error distance)
25
Error Event.
figure 11 Error event indication.
1.3 Frame Quality Classification Function

The frame quality classification function is available in the support mode for predefined SDU sizes only. The function consists of the following features : CRC check : The Iu UP protocol can perform a cyclic redundancy check for the user data payload on Iu. frame quality classification : The Iu UP protocol layer can divide the received frames in categories of frames without errors (good), frames with bit errors (bad) and frames with bit errors resulting from air interface problems (bad due to radio). On basis of the RAB configuration, frame quality classification and CRC check the Iu UP protocol can decide to discard or deliver the frame.
The exact behavior and applicability of these features is configured during RAB establishment. The parameter that is responsible for this is the Delivery Of Erroneous SDU element in the RAB parameters. This parameter can be set individually for each defined sub-flow. The Delivery Of Erroneous SDU parameter can have three different values: YES : The CRC check for payload will be performed by Iu UP protocol, and all three features are applicable. Frames with and without errors will be delivered to the higher layers (e.g. AMR codec). NO : The CRC for payload will be performed by Iu UP protocol, and all three features are applicable. But only frames without bit errors will be delivered, whenever bit errors are detected (by CRC or frame quality classification) the frame will be discarded. NO ERROR DETECTION CONSIDERATION : If this is the value of the parameter, the Iu UP protocol will not perform the CRC check for payload. Also the frame quality classification is not used, instead each user data frame will be delivered without any error detection consideration.
This parameter must be set for each sub-flow individually. But the Iu UP protocol will treat all sub-flows in a sub-flow combination in the same way. This is done in the UTRAN and UMTS Radio Protocols 26
following way. If the Delivery Of Erroneous SDU parameter of at least one sub-flow is NO, all sub-flows are handled in this way. If the Delivery Of Erroneous SDU parameter of at least one sub-flow is YES, but for no sub-flow the Delivery Of Erroneous SDU parameter is NO, all sub-flows are treated like Delivery Of Erroneous SDU parameter is YES. If for all sub-flows the Delivery Of Erroneous SDU parameter is NO ERROR DETECTION CONSIDERATION then all sub-flows are handled according to this.
Radio Access Bearer

Traffic Class
Delivery Order
Asymetry
Max. SDU-Size
Max. Bitrate
Transfer Delay
Guaranteed Bitrate
Priority
Frame Quality Classification function 1- CRC error protection activiation/deactivation..
Sub-Flow 1
SDU Error Ratio Bit Error Ratio
Delivery of erroneous SDUs
Sub-Flow x
SDU Error Ratio
...
Bit Error Ratio

Delivery of erroneous SDUs
Size of subflow SDU in each combination
Size of subflow SDU in each combination
Delivery Of Erroneous SDU::= ENUMERATED{ yes, no, no-error-detection-consideration }
Payload CRC applicable Payload CRC not applicable
figure 12 Parameter in RAB Assignment Request to control the frame quality classification.
27
1.3.1
Downlink User Data Handling
The handling of the downlink user data is simple. When the MSC wants to send a downlink user data SDU, it shall evaluate the Delivery Of Erroneous SDU parameter for this sub-flow. If at least for one sub-flow Delivery Of Erroneous SDU = YES or NO, the MSC shall calculate a CRC over the payload and transmit it in the user data frame (Transfer of User Data). The frame quality classification is always set to good, because user data from the MSC has no bit errors by definition. The RNC receives the user data frame and shall evaluate the CRC if it is included. In case bit errors (from Iu interface) are detected, the frame is always discarded, regardless of the value of the Delivery Of Erroneous SDU parameters.
28
FQC ( Frame Quality Classification ) [ 0= frame good, 1= frame bad, 2= frame bad due to radio ]
Menu
UE
RNC
CN

(RFCI, payload, FQC = good, payload CRC)
Frame Quality Classification function 2 - downlink.
RNC discards the frame when payload CRC present and bit errors are detected with it.
figure 13 Downlink user data handling.
29
1.3.2
Handling of Uplink User Data
In case of uplink data the Iu UP protocol behavior is a little bit more complex. This is because now we can have errors from the radio interface and errors from the Iu interface. In the RNC the following can is done : frame quality classification according to the information received from the radio protocols, decision to discard or deliver the frame, calculation of a CRC for the payload if applicable.
In the MSC the following can happen : checking of frame quality classification, checking of CRC if there is one, decision to discard or deliver the frame.
30
Iu
RNC data with FQC MSC|SGSN RNL SAP
Radio frame quality classification
Radio Interface Protocols
Yes discard frame? No Add payload CRC if needed, set FQC check payload CRC if present, check FQC deliver frame?
Frame Quality Classification function 3 - uplink.
TNL SAP
TNL SAP
figure 14 Uplink user data frame quality handling.
31
1.4 Frame Formats

1.4.1 Transfer of User Data (PDU Type 0 and 1)
The Iu UP protocol provides two frames (PDU types) for the transport of user data payload. These two frames are PDU type 0 : PDU type 0 allows a CRC to be transmitted for the payload. PDU type 1 : In contrast to type 0 there can be no CRC for the payload in a PDU type 1.
Common elements of both frame types are : PDU type indication : Distinguishes between PDU type 0 (with payload CRC), PDU type 1 (without payload CRC) and PDU type 14 (control messages of Iu UP protocol). Frame Number : This field works as a sequence number for the user data frames. It is a strictly increasing number. FQC (frame quality classification) : The FQC classifies the frame quality according to good (b00), bad (b01) and bad due to radio (b10) frames. RFCI (RAB sub-flow combination identifier)
The payload that is transported by the frame is not required to have length that is an integral multiple of 8 bits. But always the Iu UP protocol pads the missing bits such that the payload is aligned to octet boundaries. For future compatibility the frames contain a so called spare extension. This extension is currently not used and not transmitted. In future versions it might happen that additional parameters are transmitted in this extension.
32
PDU Type (0000) Frame Number FQC

Iu User Plane protocol frames : Transfer Of User Date (PDU Type 0 and 1).
PDU Type (0001) Frame Number FQC RFCI Header CRC Payload spare
RFCI Header CRC Payload CRC Payload Payload CRC
Payload Payload Padding
Padding
Spare Extension (0..4 octets) Spare Extension (0..4 octets)
figure 15 PDU Type 0 and 1 for transfer of user data.
33
1.4.2
Control Frames (PDU Type 14)
For control messages that do not carry user data inside the PDU type 14 is used. This frame format consists of ACK/NACK : This field indicates whether the control message is a procedure request (b00), positive acknowledgement (b01), negative acknowledgement (b10). Sequence Number : The sequence number for PDU type 14 is used as a transaction identity. An acknowledgement shall use the sequence number of the corresponding request. The sequence numbers of requests shall be increasing numbers. Iu UP mode version : This four bit field indicates the version of the used Iu UP mode. Currently only the value b0000 (version 1) is used. Procedure Indicator : The procedure indicator differentiates between Initialization procedure (b0000), Rate control procedure (b0001), Time alignment procedure (b0010), Error event indication (b0011).
The rest of the frame is used for the parameters that are specific to the procedure.
34
PDU Type (1110)

Iu UP mode version
ACK/ NACK
Sequence Number
Procedure Indicator
Header CRC payload CRC

Iu User Plane protocol frames : Control Frame (PDU Type14).
payload CRC
Procedure Data
Spare Extension (0..32 octets)
figure 16 Control frame format of Iu UP protocol (PDU Type 14).
35
1.4.3
Example of Formatted Frame
The following contains an example of a formatted Iu UP protocol frame. The PDU type is formed by the highest four bits of the first octet. It has the value H`E = d14 which indicates a control frame. The next two bits form the ACK/NACK field and is b00 so this frame constitutes a procedure request. The last two bits of the first octet are the sequence number. In the second octet the higher four bits give the user plane mode version which is b000, so version 1 of the user plane mode is used here. The lower four bits are the procedure indicator. The value b0001 together with the ACK/NACK field mean a Rate Control message. In the Iu UP protocol specification TS 25.415 the Rate Control message is defined to have only one parameter a bitmap of allowed and barred sub-flow combinations. The first element of this parameter is an indicator how many sub-flow combinations are indicated. In the actual case this means 3 sub-flow combinations are defined. Then the last octet contains the bitmap beginning from the highest bit. Bit 8 and 7 of the last octet are 0, so RFCI 1 and RFCI 2 are allowed, whereas RFCI 3 is blocked, because bit 6 is 1.
36
7 1 0
6 1 0
5 1 0
4 0 0
3 0 0
2 0 0
1 1
0 0
PDU type 14=Control, Procedure request UP mode version 0, Procedure 1 = rate control
Header CRC payload CRC

Iu User Plane protocol frames : Rate Control example.
0 1 payload CRC 1 0 1 0
0 0
0 0
0 1
0 0
0 0
0 0
spare, 3 RFCIs defined RFCI 1and 2 allowed, RFCI 3 barred
figure 17 Example of a formatted rate control frame
37
38
2 Iu-PS User Plane GTP-U
39
2.1 Iu-PS Protocols for User Data Transfer

The Iu-PS user plane is responsible to transport packet data between RNC and SGSN for activated PDP contexts. Thus the data is running from UE to SGSN via RNC and then to the GGSN and vice versa. On the radio interface Uu the packet data is transported in the PDCP (Packet Data Convergence Protocol) which performs packet header information compression and decompression. The lower layers of Uu (RLC, MAC and PHY) form the radio bearer that is temporary used as transport resource for the PDP context. The radio bearer is of course part of the radio access bearer RAB that is currently allocated for the PDP context. Note that the PDP context can exist with and without an associated radio access bearer. It can be de-allocated when no user packet data has to be sent. On the Iu-PS interface the radio access bearer is implemented on the user plane by the protocols : Iu-UP (Iu user plane protocol) : This protocol is at the moment running in transparent mode only, so there is no functionality provided by this protocol on Iu-PS. GTP-U (GPRS Tunneling Protocol User plane) : The GTP-U layer forms data transport tunnels between RNC and SGSN for each radio access bearer of all PDP contexts. So this protocol tunnels the user packets between RNC and SGSN. UDP/IP : These two standard protocols are denoted as path protocols. UDP provides an unreliable data transport, but as the ATM network is reliable enough, there should be no problem. The IP layer enables the routing between SGSN and RNC as far as this is necessary. AAL5/ATM : The AAL 5 layer provides an unacknowledged transport service for variable bit rate service, especially for bursty traffic. The AAL 5 virtual channels have to be defined by the operator (semi-permanent virtual channels) and are usually end-to-end between RNC and SGSN.
40
Menu
Uu Packet Bearer = Radio Bearer
Iu Packet Bearer = GTP-Tunnel
UE
RNC
SGSN
RNL-SAP
Relay Iu UP PDCP RLC MAC PHY
RNL-SAP Iu UP GTP-U UDP IP AAL5 ATM
PDCP
GTP-U on the packet oriented Iu user plane
GTP-U UDP IP AAL5 ATM
RLC MAC PHY
RNL-SAP : Radio Network Layer Service Access Point
figure 18 Packet oriented data transfer over Iu and Uu.
41
The complete picture of the Iu-PS interface protocol stack shows, that it consists of control and user plane. No network control plane is defined, thus there is no ALCAP (Access Link Control Application Part) involved on Iu-PS. This is, because the AAL5 virtual channels are pre-configured (semi-permanent) and do not need a dynamical set up. Also there is no sub-channeling within an AAL5 virtual channel, this means, all IP packets are equally, statistically multiplexed onto the virtual channel. The differentiation between the data packets of different PDP contexts is done in the GTP-U protocol layer. Hence it is necessary to configure this protocol when a new radio access bearer is set up for a PDP context. But RAB management is a task of RANAP, so it is a task of RANAP (RANAP-RAB management process) to configure the GTP-U protocol after RAB establishment.
42
NAS signaling / PS user data

RNC radio network layer SGSN
RANAP
Iu User Plane Prot.
SCCP MTP 3 B
Relation between Iu-PS control and user plane
GTP-U UDP IP AAL 5 ATM (NNI) Physical Layer
SAAL AAL 5 transport network layer control plane
network control plane
user plane
figure 19 Protocol architecture on Iu-PS.
43
2.2 Tunnel End Points and Tunnel Configuration

The GPRS feature of UMTS is built according to the principle of tunneling. This means network protocol packets for an external data network (e.g. IP or PPP datagrams) must be transported through another network (in our case UMTS network). So the tunnel is nothing else than a transport bearer service. The UMTS packet switched bearer services consist of several transport tunnels. A first bearer service is between UE and RNC (radio bearer), the second between RNC and SGSN and a third is between SGSN and GGSN. In this section only the tunnel between RNC and SGSN is of interest, but most of the statements hold for the SGSN-GGSN tunnel too. Each tunnel is identified by its two endpoints. As the tunnels is a transport service specific to a certain PDP context, the protocols GTP-U, UDP and IP have to deal with the definition of the endpoints. Indeed an endpoint is defined as the pair : IP address of the endpoint node and TEID (Tunnel Endpoint Identifier) which is a local reference number for the PDP context chosen by this endpoint node, the address belongs to. So the TEID is unique only together with the IP address.
These two identifiers will be carried in each user data packet, the TEID is contained in the GTP-U part and the IP address will be contained in the IP header of the data frame that carries the tunneled data. With this it is possible to uniquely identify and process the packet. In this you may miss the UDP port number. In UMTS the UDP source port number of a tunnel can vary during time (ephemeral port numbers for source) and the UDP destination port numbers are pre-defined by the GTP-U protocol (port number 2152). When a tunnel is to be set up, it is necessary to indicate IP address and TEID for both tunnel endpoints. All TEID values except TEID = 0 can be used for tunnels. The TEID = 0 is reserved for control procedures of GTP-U (e.g. error indications, path test).
44
RNC
IP/ATM network
GTP-U UDP IP AAL 5 ATM
SGSN
TEIDRNC
UDP Port No. RNC-IP Addr.
Concept of Tunnel bearer services on Iu-PS.
TEIDSGSN
UDP Port No. SGSN-IP Addr.
Tunnel Endpoint
Tunnel Endpoint
(TEIDRNC, TEIDSGSN)
Iu Tunnel (Iu Packet Bearer)
figure 20 Tunnel end points and the relevant protocols.
45
When a PDP context is active a radio access bearer for this context can exist or not. In other words, when no packet user data must be transported the radio access bearer can be released and in the moment packet data must be sent a new radio access bearer will be set up. The radio access bearer for a packet data bearer is from the point of view of RANAP signaling procedure nothing special. The RANAP message RAB Assignment Request is used to trigger the set up of the radio access bearer and the RNC acknowledges with RAB Assignment Response. In the request and response message two parameters are special for packet data bearers set : Transport Layer Address : This element contains the IP address of SGSN (request) or RNC (response). Iu Transport Layer Association : This parameter transports the TEID of SGSN (request) or RNC (response) to the other side.
With this both sides (e.g. RNC and SGSN) have all information to establish the tunnel as a logical transport resource. Any further action is not necessary.
46
RNC
SGSN
RANAP: RAB Assignment Request

Allocation of TEIDs and IP addresses for the tunnel using RANAP.
(Setup: RAB-ID, RAB parameters, Transport Layer Address = SGSN-IP address, Iu Transport Association = SGSN-TEID, PDP type = protocol to be tunnelled )

(Setup Acknowledgement: RAB-ID, Transport Layer Address = RNC-IP address, Iu Transport Association = RNC-TEID)
figure 21 RAB Assignment parameters for configuration of tunnels.
47
The UDP port numbers for GTP-U messages are handled in the following way. GTP-U two three types of frames are defined : GTP-U data frames (G-PDU) : A G-PDU carries user data inside. The destination port number of a G-PDU is always set to d2152. The source port number is freely chosen by the originator of the G-PDU (ephemeral source port). GTP-U request control frames : A request control frame is used to trigger a signaling procedure. The destination port is again d2152, whereas the source port is freely chosen. GTP-U response control frames : A response control frames is the answers to a request control frame. The source port of a response control frame is always d2152 (e.g. this equals the destination port of the associated request control frame) and the destination frame is the source port number of the associated request control frame.
In other words the GTP-U protocol uses port number d2152, which must always be used for the destination port number in initial messages (G-PDU or request control frame),but the source port number can be chosen freely in initial messages. In response messages the values from the corresponding initial message are taken and interchanged.
48
RNC (SGSN) Source Port : X

Dest. Port : 2152
SGSN (RNC)
GTP-U request message

UDP port number utilization for GTP-U control and data messages.
Source Port : 2152
Dest. Port : X
GTP-U response message
GTP-U data frame
TEID
Source Port : X
Dest. Port : 2152
figure 22 GTP-U within UDP and the associated UDP port numbers.
49
2.3 GTP-U Procedures

2.3.1 Packet Data Transfer
The main task of the GTP-U protocol is to transport packet user data of a PDP context within the associated tunnel on Iu-PS. The G-PDU (GTP Protocol Data Unit) is responsible for this. This frame is transported within a UDP/IP datagram that contains the IP address of RNC (downlink) or SGSN (uplink) and the UDP destination port (d2152) and source port (ephemeral). In the header of the G-PDU the TEID of the receiver endpoint is included. Also a sequence numbering for the packet user data is contained in here. The user data itself will be transported as payload in the G-PDU which is also called TPDU (Transport PDU).
50
RNC
SGSN
G-PDU (RNC-IP-address, source port: X, destination port: 2152)
[TEIDRNC, sequence number, T-PDU=user data]
G-PDU (SGSN-IP-address, source port: Y, destination port: 2152)
[TEIDSGSN, sequence number, T-PDU=user data]

GTP-U user data transport.
figure 23 G-PDU for packet oriented user data transfer.
51
2.3.2
Error Indication
When SGSN or RNC receive a G-PDU for a TEID that is not active, a error notification shall be sent. Therefore the GTP-U protocol contains the Error Indication procedure. This frame is a request control frame which is sent in TEID=0, that has been reserved for control procedures. The error indication frame itself then contains a parameter TEID1, that contains the inactive TEID the G-PDU was received for. When the remote side receives such an error indication, it shall implicitly release the RAB that is associated with the inactive TEID. The PDP context itself is not affected by this.
52
RNC Error Indication release RAB [TEID=0, TEID1 = inactive PDP context]
SGSN
Error Indication
GTP-U error indication for inactive TEIDs.
[TEID=0, TEID1 = inactive PDP context] release RAB !PDP context not released
figure 24 GTP-U Error indication for inactive PDP contexts.
53
2.3.3
Path Test Procedure
RNC and SGSN periodically test whether their counterpart is still active. This procedure is the path test or echo procedure. The node that starts a path test, will send a GTP-U control frame of type Echo Request with TEID = 0. The remote side has to response with a frame Echo Response.
54
RNC
SGSN
Echo Request (RNC-IP-address, source port: X, destination port: 2152)
[TEID=0]
Echo Response (SGSN-IP-address, source port:2152, destination port:X)
[TEID=0]
Path availability test with GTP-U echo procedure.
Echo Request (SGSN-IP-address, source port: Y, destination port: 2152)
[TEID=0]
Echo Response (RNC-IP-address, source port:2152, destination port:Y)
[TEID=0]
figure 25 Echo request for path test procedure.
55
2.4 GTP-U Frame Format

The GTP-U frames are transported in UDP/IP datagrams. The IP protocol can be of version 4 or 6. In any case the IP header carries the source and the destination IP address used for IP routing between RNC and SGSN if it is necessary. The UDP header includes the UDP port numbers as they have been discussed before. The GTP frame follows as data part of the UDP frame. The GTP frame contains the TEID of the destination node.
56
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
IP version header length
type of service datagram identification time to live protocol (H11=UDP)
total length
flags
fragment offset
header checksum
source IP address destination IP address

options (e.g. time stamps, route records, security info)
IPv4 header
UDP source port number

UDP datagram length
UDP destination port number

UDP checksum
UDP header
version PT 0 E S PN GTP message type GTP message length Tunnel Endpoint Identifier (TEID) next extension header Sequence Number N-PDU number
extension header length extension header content
extension header content=0
GTP message
GTP message parameters/data

IP/UDP/GTP headers on Iu.
PT = Protocol Type (1=GTP; 0=GTP) version = 001 (TS 29.060 V3.x.y) E = extension header field indicator S = sequence number indicator PN = N-PDU number indicator
figure 26 IP/UDP/GTP frame layout.
57
The GTP-U frame contains the following elements : version (3): The version field indicates the differentiates between different GTP versions. UMTS must use GTP version 2 (b001) or higher. GTP version 2 is specified in TS 29.060 V3.x.y. GPRS/GSM can use GTP version 1 (b000) which has been specified in GSM TS 09.60. PT (Protocol Type) (1): The protocol type distinguishes between GTP (b1) and GTP' (b0) used between GSN and charging gateway function, and thus is a charging data protocol. E (Extension Header Flag) (1): This bit indicates whether the octet 12 of the header shall be evaluated (b1) or not (b0) S (Sequence Number Flag) (1): This bit indicates whether the octets 9 and 10 shall be evaluated (b1) or not (b0). PN (N-PDU Number Flag) (1): This bit indicates whether the octet 11 shall be evaluated (b1) or not (b0). Message Type (8): The message type differentiates between the following frame types: G-PDU (HFF), Echo Request (H01), Echo Response (H02), Error Indication (H1A), Supported Header Extension Indication (H1F). Length (16): These two octets indicate the length of the payload (without GTP header) in bytes. TEID (Tunnel Endpoint ID) (32): The tunnel endpoint identifier of the destination. Sequence Number (16): The sequence number is a strictly increasing label for each G-PDU. For control message frames the sequence number is used as a transaction identifier (in other words: request and response have the same number). The sequence number is must be present when one of the E, S or PN bits are set. The sequence number shall be used only when the S bit is set. N-PDU Number (8): The N-PDU number represents a sequence number for network protocol data units (e.g. IP datagrams for external network). It is used during interSGSN routing area updates and inter-system handovers to support loss-less data transmission. This field must be present when one of the bits E, S or PN is set, this field shall be evaluated only when the PN bit is set. Next Extension Header Type (8): This field is used to indicate which extension header follows after the standard header. The value H00 indicates that no extension header follows, H01 means the PDCP number extension header. This field must be present when one of the bits E, S or PN is set and shall be evaluated only when the E bit is set.
After the header follows then either the payload (no extension header indicated) or an extension header. UTRAN and UMTS Radio Protocols 58
8 7 6 5 4 3 2 1 1 2 3 4 5 6
GTP header and GTP-U relevant message type codes.
version
PT 0 E S PN Message Type Length
Version : 0 0 1 (GTP V2) PT (Protocol Type): 1=GTP, 0=GTP E (Extension Header) : octet 12 is valid S (Sequence Number): octets 9/10 valid PN (N-PDU Number): octet 11 valid
Message Type Code 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 1 0 1 0 0 1 1 1 1 1 1 1 1 1 1 Message Type Echo Request Echo Response Error Indication Supported Header Extension Indication G-PDU
7 8 9 10 11 12
Tunnel Endpoint ID (TEID)
0 0 0 0 1
1 0 0 1 1
Sequence Number N-PDU Number

Next Extension Header Type
Next Header Extension Type Type 0 0 0 0 0 0 0 0 No more extension headers 0 0 0 0 0 0 0 1 PDCP PDU Number extension header.
figure 27 GTP frame format.
59
The extension headers of GTP are built according to a model consisting of the following elements : Extension Header Length (8), Extension Header Content (N*8) : The extension header content represents the meaning of this header. It must be an integral multiple number of 8 bits. Next Extension Header Type (8): This field indicates, what comes after this extension header. When this field is H00 the payload will follow.
The only extension header that is currently defined is the extension header for PDCP PDU numbers. In case of relocations and associated handovers, this header can be used to support loss-less relocation.
60
General Extension Header Layout
PDCP PDU number extension header
8 7 6 5 4 3 2 1 Extension Header Length

Extension Header Content Next Extension Header Type
8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 1 PDCP PDU Number

Next Extension Header Type
61
GTP extension header..
figure 28 Extension header layout and PDCP Number extension header.
62

Register 7 - Iu Interface User Plane Protocols PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Register 7 - Iu Interface User Plane Protocols PDF

Uploaded by

Copyright:

Available Formats

VII.

Iu Interface User Plane Protocols

Iu Interface User Plane Protocols

UTRAN and UMTS Radio Protocols

VII. Iu Interface User Plane Protocols

UTRAN and UMTS Radio Protocols

VII. Iu Interface User Plane Protocols

1 Iu User Plane Protocol

UTRAN and UMTS Radio Protocols

VII. Iu Interface User Plane Protocols

1.1 Iu User Plane Protocol Modes and Tasks

UTRAN and UMTS Radio Protocols

VII. Iu Interface User Plane Protocols

user plane transport bearer protocols

user plane transport bearer protocols

Iu user plane protocol.

figure 1 Meaning and location of Iu UP protocol.

UTRAN and UMTS Radio Protocols

VII. Iu Interface User Plane Protocols

UTRAN and UMTS Radio Protocols

VII. Iu Interface User Plane Protocols

Iu User Plane Protocol

Transparent Mode Version 1

Support Mode for predefined SDU sizes Version 1 Version 2

Iu user plane protocol modes and mode versions.

-Transfer of user data

UTRAN and UMTS Radio Protocols

VII. Iu Interface User Plane Protocols

UTRAN and UMTS Radio Protocols

VII. Iu Interface User Plane Protocols

RANAP: RAB Assignment Request

RANAP: RAB Assignment Response

UTRAN and UMTS Radio Protocols

VII. Iu Interface User Plane Protocols

UTRAN and UMTS Radio Protocols

VII. Iu Interface User Plane Protocols

Radio Interface Protocols Iu UP - TrM

Iu UP - TrM TNL SAP

figure 4 Transparent operation mode of Iu UP protocol.

UTRAN and UMTS Radio Protocols

VII. Iu Interface User Plane Protocols

Support Mode for Predefined SDU Sizes

UTRAN and UMTS Radio Protocols

VII. Iu Interface User Plane Protocols

Radio Interface Protocols

NAS stream specific functions

NAS stream specific functions

Support mode for predefined SDU sizes of Iu UP.

Procedure Control Functions

Procedure Control Functions

Frame Handler Function

Frame Handler Function

figure 5 Functional architecture of Iu UP protocol for support mode.

UTRAN and UMTS Radio Protocols

VII. Iu Interface User Plane Protocols

1.2 Iu UP Support Mode Procedures

UTRAN and UMTS Radio Protocols

VII. Iu Interface User Plane Protocols

RNC RANAP: RAB Assignment Request

RANAP: RAB Assignment Response

figure 6 Initialization procedure.

UTRAN and UMTS Radio Protocols

VII. Iu Interface User Plane Protocols