Core Network Nb Interface User Plane Protocols

3GPP TS 29.415 V9.1.0 (2010-09)
Technical Specification
3rd Generation Partnership Project;
Technical Specification Group Core Network and Terminals;
Core Network Nb Interface User Plane Protocols
(Release 9)

 EMBED Word.Picture.6  	
	
The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.	 
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.	 
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.
Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.


Keywords
UMTS, network, protocol

3GPP
Postal address

3GPP support office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Internet
 HYPERLINK "http://www.3gpp.org" http://www.3gpp.org

Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© 2010, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA, TTC).
All rights reserved.

UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE™ is a Trade Mark of ETSI currently being registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM® and the GSM logo are registered and owned by the GSM Association


Contents
 TOC \o "1-9" Foreword	 PAGEREF _Toc200025872 \h 5
Introduction	 PAGEREF _Toc200025873 \h 5
1	Scope	 PAGEREF _Toc200025874 \h 6
2	References	 PAGEREF _Toc200025875 \h 6
3	Definitions, symbols and abbreviations	 PAGEREF _Toc200025876 \h 7
3.1	Definitions	 PAGEREF _Toc200025877 \h 7
3.2	Symbols	 PAGEREF _Toc200025878 \h 7
3.3	Abbreviations	 PAGEREF _Toc200025879 \h 7
4	User Plane	 PAGEREF _Toc200025880 \h 7
4.1	General aspects	 PAGEREF _Toc200025881 \h 7
4.2	Operational and Functional Aspects	 PAGEREF _Toc200025882 \h 8
5	Transparent Mode	 PAGEREF _Toc200025883 \h 8
6	Support mode for predefined SDU sizes	 PAGEREF _Toc200025884 \h 8
6.1	General	 PAGEREF _Toc200025885 \h 8
6.2	Nb UP protocol layer services in Support Mode	 PAGEREF _Toc200025886 \h 8
6.3	Services expected from the Transport Network Layer	 PAGEREF _Toc200025887 \h 8
6.4	Functions of the Nb UP protocol layer in Support Mode	 PAGEREF _Toc200025888 \h 9
6.4.1	Functional model of the Nb UP protocol layer in Support Mode	 PAGEREF _Toc200025889 \h 9
6.4.2	Frame handler function	 PAGEREF _Toc200025890 \h 9
6.4.3	Procedure control functions	 PAGEREF _Toc200025891 \h 9
6.4.4	Non Access Stratum data streams specific functions	 PAGEREF _Toc200025892 \h 9
6.4.4.1	Frame quality classification	 PAGEREF _Toc200025893 \h 9
6.4.4.1.1	General	 PAGEREF _Toc200025894 \h 9
6.4.4.1.2	Handling of FQC information	 PAGEREF _Toc200025895 \h 10
6.5	Elementary procedures	 PAGEREF _Toc200025896 \h 10
6.5.1	Transfer of User Data procedure	 PAGEREF _Toc200025897 \h 10
6.5.1.1	Successful operation	 PAGEREF _Toc200025898 \h 10
6.5.1.2	Unsuccessful operation	 PAGEREF _Toc200025899 \h 10
6.5.2	Initialisation procedure	 PAGEREF _Toc200025900 \h 10
6.5.2.1	Successful operation	 PAGEREF _Toc200025901 \h 10
6.5.2.2	Unsuccessful operation	 PAGEREF _Toc200025902 \h 11
6.5.3	Rate Control	 PAGEREF _Toc200025903 \h 11
6.5.3.1	Successful operation	 PAGEREF _Toc200025904 \h 11
6.5.3.2	Unsuccessful operation	 PAGEREF _Toc200025905 \h 11
6.5.4	Time Alignment	 PAGEREF _Toc200025906 \h 11
6.5.4.1	Successful operation	 PAGEREF _Toc200025907 \h 11
6.5.4.2	Unsuccessful operation	 PAGEREF _Toc200025908 \h 11
6.5.5	Handling of Error Event procedure	 PAGEREF _Toc200025909 \h 11
6.5.5.1	Successful operation	 PAGEREF _Toc200025910 \h 11
6.5.5.2	Unsuccessful operation	 PAGEREF _Toc200025911 \h 11
6.6	Elements for Nb UP communication in Support mode	 PAGEREF _Toc200025912 \h 11
6.7	Handling of unknown, unforeseen and erroneous protocol data	 PAGEREF _Toc200025913 \h 12
7	Communication Primitives for the Nb UP protocol layer	 PAGEREF _Toc200025914 \h 12
7.1	Modelling Principle	 PAGEREF _Toc200025915 \h 12
7.2	Primitives towards the upper layers at the CNL-SAP	 PAGEREF _Toc200025916 \h 12
7.3	Primitives towards the transport layers at TNL-SAP	 PAGEREF _Toc200025917 \h 12
7.3.1	General	 PAGEREF _Toc200025918 \h 12
7.3.2	ATM/AAL2 based Transport Layer	 PAGEREF _Toc200025919 \h 12
7.3.2.1	General	 PAGEREF _Toc200025920 \h 12
7.3.2.2	AAL2 Service Primitives used by the Nb UP protocol	 PAGEREF _Toc200025921 \h 12
7.3.3	GTP-U based Transport Layer	 PAGEREF _Toc200025922 \h 13
7.3.4	RTP/UDP/IP based Transport Layer	 PAGEREF _Toc200025923 \h 13
8	Evolution of Nb UP Protocol	 PAGEREF _Toc200025924 \h 13
Annex A (informative):	Change history	 PAGEREF _Toc200025925 \h 14

Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x	the first digit:
1	presented to TSG for information;
2	presented to TSG for approval;
3	or greater indicates TSG approved document under change control.
y	the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc.
z	the third digit is incremented when editorial only changes have been incorporated in the document.
Introduction
The present document specifies the user plane protocol used between two Media Gateways in the CS core network. Through out the present document this protocol shall be referred to as the Nb UP protocol. The Nb UP protocol is for a large part identical to the Iu UP protocol (see 3GPP TS 25.415 [2]), and only the differences between the two protocols are specified. This specification defines the applicability of the UP, as defined in 3GPP TS 25.415 [2], for the Nb interface only.
Given that the Nb UP uses the same PDU types as the Iu UP, the term IuFP is used to refer to the common framing.
For the purpose of the present document, any occurrence of the term "Iu UP" in the corresponding sections of 3GPP TS 25.415 [2], shall be interpreted as "Nb UP".
1	Scope
The present document specifies the user plane protocol of the bearer used between two MGWs within the BICC-based CS core network, called the Nb UP protocol. The present document assumes the implementation of the split between call control and the bearer transport and control, as specified in 3GPP TS 23.205 [1], see figure 1. Note that the present document does not preclude an implementation of a combined MSC Server and MGW.
EMBED Word.Picture.8
Figure 1: CS core network logical architecture
2	References
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
References are either specific (identified by date of publication, edition number, version number, etc.) or non‑specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies.  In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]	3GPP TS 23.205: "Bearer Independent CS Core Network; Stage 2"
[2]	3GPP TS 25.415: "UTRAN Iu Interface User Plane Protocols"
[3]	3GPP TS 29.232: "Media Gateway Controller; Media Gateway interface; Stage 3"
[4]	3GPP TS 29.414: "Core Network Nb Data Transport and Transport Signalling"
[5]	3GPP TR 41.001: "GSM Release specifications"
[6]	3GPP TR 21.905: "Vocabulary for 3GPP Specifications"
[7]	IETF RFC 1889: "RTP A Transport Protocol for Real Time Applications"
[8]	ITU-T I.366.1 (06/98): "Segmentation and Reassembly Service Specific Convergence Sublayer for the AAL type 2"
3	Definitions, symbols and abbreviations
3.1	Definitions
Definitions used in the present document are listed in 3GPP TR 21.905 [6].
3.2	Symbols
For the purposes of the present document, the following symbols apply:
Iu	Interface between the RNS and the core network. It is also considered as a reference point.
Nb	Interface between media gateways.
IuFP	Iu Framing protocol
3.3	Abbreviations
For the purposes of the present document, the following abbreviations apply:
AAL	ATM Adaptation Layer
AAL2	AAL Type 2
ATM	Asynchronous Transfer Mode
CN	Core Network
CNL	Core Network Layer
CS	Circuit Switched
FFS	For Further Study
IPTI	Inter PDU Transmission Interval
Iu UP	Iu interface User Plane
MGW	Media GateWay
PDU	Protocol Data Unit
RTP	Real-time Transmission Protocol
SAP	Service Access Point
SDU	Service Data Unit
SRNC	Serving Radio Network Controller

4	User Plane
4.1	General aspects
The Nb UP is located in the user plane of the CS core network over the Nb interface. It is used to convey data between MGWs.
The Nb UP protocol shall be initiated at one MGW and acknowledged by the adjoining MGW.
The Nb UP framing is identical to the Iu UP framing, i.e., the same PDU types are valid for both protocols.
Figure 2 shows the logical location of the Nb UP protocol layer in relation to the Nb interface.
 EMBED Word.Picture.8  
Figure 2: Nb UP protocol layer occurrence in overall architecture.
4.2	Operational and Functional Aspects
There are two modes of operation for the Nb UP:
-	Transparent mode;
-	Support mode for predefined SDU size.
The two modes of operation follow the definition of the corresponding Iu UP modes of operation, as described in 3GPP TS 25.415 [2].
Support mode version 2 is mandatory on the NbUP interface. Support mode version 1 is not required at the Nb but may be used if both MGWs support it, as a result of the version negotiation during the Initialisation procedure.
5	Transparent Mode
This mode of operation is identical to that of the Iu UP protocol, see the corresponding section in 3GPP TS 25.415 [2].
6	Support mode for predefined SDU sizes
6.1	General
See the corresponding section in 3GPP TS 25.415 [2].
6.2	Nb UP protocol layer services in Support Mode
See the corresponding section in 3GPP TS 25.415 [2].
6.3	Services expected from the Transport Network Layer
See the corresponding section in 3GPP TS 25.415 [2].
6.4	Functions of the Nb UP protocol layer in Support Mode
6.4.1	Functional model of the Nb UP protocol layer in Support Mode
See the corresponding section in 3GPP TS 25.415 [2].
6.4.2	Frame handler function
See the corresponding section in 3GPP TS 25.415 [2].
6.4.3	Procedure control functions
See the corresponding section in 3GPP TS 25.415 [2].
6.4.4	Non Access Stratum data streams specific functions
See the corresponding section in 3GPP TS 25.415 [2].
6.4.4.1	Frame quality classification
6.4.4.1.1	General
On the Nb UP in Support Mode the frames are classified with the Frame Quality Classifier (FQC). This classifying is based on frame classification on the preceding link and the setting of the attribute "Delivery of erroneous SDUs". The MSC server shall indicate the value of the attribute "Delivery of erroneous SDUs" see 3GPP TS 29.232 [3].
Figure 4 shows the main input and output information for the frame quality classification function on the Nb UP.
 EMBED Word.Picture.8  
Figure 4: Frame quality classification in Nb UP
6.4.4.1.2	Handling of FQC information
The handling of FQC shall be as specified in Table 1.
Table 1. FQC handling in Nb UP protocol, receiving side
Input
Action
Delivery of erroneous SDUs 
FQC in received PDU
Payload CRC

'yes' or 'no'
'good'
OK
Leave FQC unchanged. Forward SDU and FQC to upper layer
‘yes’
‘bad radio’
OK
Leave FQC unchanged. Forward SDU and FQC to upper layer
'yes'
'good' or ‘bad radio’
Not OK
Set FQC to 'bad'. Forward SDU and FQC to upper layer
‘yes’
‘bad’
Any
Leave FQC unchanged. Forward SDU and FQC to upper layer
'no'
'good'
Not OK
Drop SDU
‘no’
‘bad’ or ‘bad radio’
Any
Not applicable. SDUs are dropped at a previous link.
'no-error-detection-consideration'
Any
Any
Leave FQC unchanged. Forward SDU and FQC to upper layer

The FQC handling in the Nb UP protocol entity on the sending side is as follows:
When the upper layer indicates an FQC value in the Nb-UP-DATA-Request message, an FQC shall be set in the PDU as indicated by the upper layer. If the upper layer does not indicate an FQC value, the FQC in the PDU shall be set to 'good'.
When the upper layer indicates an FQC with the value 'bad' to the Nb UP protocol layer, the Nb UP support functions may generate an erroneous payload CRC. 
An MGW may ignore the settings of the "delivery of erroneous SDUs" property of the 3GUP package if the MGW passes frames transparently through the UP entities as described in 3GPP TS 29.232 [3].
6.5	Elementary procedures
6.5.1	Transfer of User Data procedure
6.5.1.1	Successful operation
See the corresponding section in 3GPP TS 25.415 [2]. For the purpose of the present document, the MGW replaces the function of the SRNC and the CN, and the Nb replaces the function of the Iu.
When the MGW provides the Frame Number IE it shall be based on time according to the handling on Iu (see 3GPP TS 25.415 [2]) for conversational and streaming traffic class.
NOTE:	The IuUP Frame Number IE is based on time also and therefore no interworking of this IE is required.
6.5.1.2	Unsuccessful operation
See the corresponding section in 3GPP TS 25.415 [2]. For the purpose of the present document, the MGW replaces the function of the SRNC and the CN, and the Nb replaces the function of the Iu.
6.5.2	Initialisation procedure
6.5.2.1	Successful operation
See the corresponding section in 3GPP TS 25.415 [2].
When an Nb UP layer protocol entity receives an initialisation status request from the upper layer, it shall start the initialisation procedure. See 3GPP TS 29.232 [3], concerning the overall initialisation process. When an Nb UP layer protocol entity receives an initialisation message it shall acknowledge this message and indicate to the upper layer that an initialisation message has been received. When an Nb UP layer protocol entity receives a positive initialisation acknowledgement it shall indicate to the upper layer that a positive initialisation acknowledgement has been received.
6.5.2.2	Unsuccessful operation
See the corresponding section in 3GPP TS 25.415 [2]. A negative acknowledgement triggers a repetition of the initialisation message. After N INIT unsuccessful repetitions, the initialisation procedure is terminated. 
6.5.3	Rate Control
6.5.3.1	Successful operation
See the corresponding section in 3GPP TS 25.415 [2]. When an Nb UP protocol entity receives a rate control message over the Nb interface, it shall provided an indication of the rate control to the upper layer. The rate control indication is acknowledged on request from the upper layer. 
6.5.3.2	Unsuccessful operation
See the corresponding section in 3GPP TS 25.415 [2]. Depending on the error cause, a negative acknowledgement is either reported in a status indication to the upper layer, or it triggers a repetition of the control command. After N RC unsuccessful repetitions, the rate control procedure is terminated.
6.5.4	Time Alignment
6.5.4.1	Successful operation
See the corresponding section in 3GPP TS 25.415 [2]. When an Nb UP protocol entity receives a time alignment command over the Nb interface, it shall indicate the time alignment to the upper layer. The time alignment is acknowledged on request from the upper layer.
6.5.4.2	Unsuccessful operation
See the corresponding section in 3GPP TS 25.415 [2]. Depending on the error cause, a negative acknowledgement is either reported in a status indication to the upper layer, or it triggers a repetition of the control command. After N TA unsuccessful repetitions, the time alignment procedure is terminated.
6.5.5	Handling of Error Event procedure
6.5.5.1	Successful operation
See the corresponding section in 3GPP TS 25.415 [2].
6.5.5.2	Unsuccessful operation
See the corresponding section in 3GPP TS 25.415 [2].
6.6	Elements for Nb UP communication in Support mode
See the corresponding section in 3GPP TS 25.415 [2].
6.7	Handling of unknown, unforeseen and erroneous protocol data
See the corresponding section in 3GPP TS 25.415 [2].
7	Communication Primitives for the Nb UP protocol layer
7.1	Modelling Principle
See the corresponding section in 3GPP TS 25.415 [2].
7.2	Primitives towards the upper layers at the CNL-SAP
See the corresponding section in 3GPP TS 25.415 [2].
7.3	Primitives towards the transport layers at TNL-SAP
7.3.1	General
Access to the Transport network Layer is performed through a generic SAP: TNL-SAP.
When the Transport Network upper layer consists of AAL2, the TNL SAP maps to the AAL-SAP which allows communication to be performed using specific AAL primitives.
When the Transport Network upper layer consists of RTP/UDP/IP, the TNL-SAP maps to the services provided by IETF RFC 1889 [7].
The choice of communication, specific or generic, through the TNL-SAP is fixed by the Core Network Layer control plane logic. This choice of communication is based on the requirements placed by, e.g. the RAB characteristics, the core network domain requesting the RAB establishment or other operator's choice.
7.3.2	ATM/AAL2 based Transport Layer
7.3.2.1	General
When the Nb UP protocol layer uses the services of an ATM/AAL2 transport, it shall use an established AAL2 connection for transferring frames between the peer TNL-SAPs at both ends of the Nb User plane access points. The Transport Network Control Plane over the Nb interface handles the signalling to establish and release the AAL2 call connections.
7.3.2.2	AAL2 Service Primitives used by the Nb UP protocol
AAL2 services and primitives used at the Service Access Point from the AAL2 layer are shown in table 3.
Table 4: AAL2 primitives and parameters
Primitive
Type
Parameters
Comments
SSSAR-UNITDATA
Request
SSSAR-INFO

SSSAR-UUI
Not used (note)
SSSAR-UNITDATA
Indication
SSSAR-INFO

SSSAR-UUI
Not used (note)
NOTE:	The setting of this field is set to not used i.e. decimal value 26 according to ITU-T Q.366.1 [8].

These primitives are to be used in the Nb UP.
The Transport Network control plane is as specified in 3GPP TS 29.414 [4].
7.3.3	GTP-U based Transport Layer
Not applicable.
7.3.4	RTP/UDP/IP based Transport Layer
When the Nb UP protocol layer uses the services of an RTP-based transport, it shall use a dynamic payload type that was negotiated for the connection for transferring Nb UP frames between the two endpoints at both ends of the Nb User plane access points. This dynamic payload type is negotiated using the specified bearer control protocol, 3GPP TS 29.414 [4].
8	Evolution of Nb UP Protocol
See the corresponding section in 3GPP TS 25.415 [2].
Annex A (informative):
Change history
Change history
DateTSG #TSG Doc.CRRevSubject/CommentOldNew03-2001TSG#11NP-010037Approved as Version 4.0.0 to be placed under Change Control2.0.04.0.009-2001TSG#13NP-0104380011Clarification on FQC handling and alignment with TS 25.4154.0.04.1.012-2001TSG#14NP-0105730021Correction to Scope clause4.1.04.2.012-2001TSG#14NP-0105730041Reference to Iu UP4.1.04.2.003-2002TSG#15NP-020085005Add GERAN Iu mode to scope4.1.05.0.003-2003TSG#19NP-0300760071No backward compatibility to Nb UP FP support mode version 1 required5.0.05.1.012-2004CN#26Upgraded to v6.0.05.1.06.0.001-2005Correct typo in version number on cover6.0.06.0.112-2006TSG#34CP-0606190122Time based Nb frame number6.0.16.1.006-2007TSG#36Upgraded to v7.0.06.1.07.0.005-2008TSG#40CP-0803100132NbFP not used for SIP-I based CS CN7.0.08.0.012-2009TSG#46Automatic upgrade from previous Release8.0.09.0.009-2010TSG#49CP-100555016Correcting unspecific external reference9.0.09.1.0








 STYLEREF ZA 3GPP TS 29.415 V9.1.0 (2010-09)
 PAGE 2
 STYLEREF ZGSM Release 9


3GPP