• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
25933 540 ip transport in the utran
 

25933 540 ip transport in the utran

on

  • 850 views

 

Statistics

Views

Total Views
850
Views on SlideShare
850
Embed Views
0

Actions

Likes
0
Downloads
42
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    25933 540 ip transport in the utran 25933 540 ip transport in the utran Document Transcript

    • 3GPP TR 25.933 V5.4.0 (2003-12) Technical Report 3rd Generation Partnership Project;Technical Specification Group Radio Access Network; IP transport in UTRAN (Release 5)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 thisSpecification.Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners Publications Offices.
    • Release 5 2 3GPP TR 25.933 V5.4.0 (2003-12) Keywords UMTS, radio, IP 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 http://www.3gpp.org Copyright NotificationNo part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media.© 2004, 3GPP Organizational Partners (ARIB, CCSA, ETSI, T1, TTA, TTC). All rights reserved. 3GPP
    • Release 5 3 3GPP TR 25.933 V5.4.0 (2003-12)ContentsForeword.................................................................................................................................................101 Scope....................................................................................................................................................112 References............................................................................................................................................113 Definitions, symbols and abbreviations................................................................................................143.1 Definitions............................................................................................................................................................143.2 Symbols................................................................................................................................................................143.3 Abbreviations.......................................................................................................................................................144 Introduction..........................................................................................................................................154.1 Task Description..................................................................................................................................................154.2 Rationale for IP Transport....................................................................................................................................155 Requirements.......................................................................................................................................165.1 General requirements...........................................................................................................................................165.2 Independence to Radio Network Layer................................................................................................................165.3 Services required by the upper layers of user planes of Iu..................................................................................165.4 Services required by the upper layers of user planes of Iur and Iub....................................................................175.5 Coexistence of the two transport options.............................................................................................................175.6 Quality of Service................................................................................................................................................175.7 Efficient utilization of transport resources...........................................................................................................185.8 Layer 2/Layer 1 independence.............................................................................................................................185.9 Transport Bearer Identification............................................................................................................................185.10 Transport Network Architecture and Routing....................................................................................................185.10.1 Network elements ...........................................................................................................................................185.11 Radio Network Signalling Bearer......................................................................................................................186 Study Areas..........................................................................................................................................196.1 External standardization.......................................................................................................................................196.2 User plane proposed solutions.............................................................................................................................196.2.1 CIP solution.......................................................................................................................................................196.2.1.1 CIP Container.................................................................................................................................................196.2.1.2 CIP Packets....................................................................................................................................................196.2.1.2.1 Segmentation and Re-assembly..................................................................................................................196.2.1.2.2 CIP Packet Header Format..........................................................................................................................206.2.1.2.3 The CIP Packet Header Fields in Detail. ...................................................................................................206.2.1.2.4 Discussion of the CIP Packet Header Field Sizes.......................................................................................216.2.2 LIPE solution....................................................................................................................................................216.2.2.1 Details of Multiplexed Header.......................................................................................................................226.2.2.2 Basic Header..................................................................................................................................................226.2.2.3 Extensions......................................................................................................................................................226.2.3 PPP-MUX based solution.................................................................................................................................236.2.3.1 PPP Multiplexed Frame Option Over HDLC................................................................................................236.2.3.2 PPP Multiplexed Frame Option Over ATM/AAL5.......................................................................................246.2.3.3 PPP Multiplexed Frame Option Over L2TP Tunnel (TCRTP)......................................................................256.2.4 MPLS solution..................................................................................................................................................266.2.4.1 MPLS General Description............................................................................................................................266.2.4.2 Routing with MPLS.......................................................................................................................................266.2.4.3 Support for QoS requirements.......................................................................................................................276.2.4.4 Efficient, QoS-enabled transmission over routed domains with MPLS........................................................276.2.4.5 Efficient transmission over narrowband (point-to-point) links with MPLS..................................................296.2.4.5.1 MPLS Header Compression "Session Negotiation"...................................................................................296.2.4.5.1.1 Using RSVP-TE to negotiate "MPLS Simple Header Compression"......................................................306.2.4.5.1.2 Using LDP signalling for "MPLS Simple Header Compression" session negotiation............................306.2.4.5.2 Handling of large packets over narrowband links.......................................................................................306.2.5 AAL2 based solution.........................................................................................................................................316.2.6 Usage of UDP Lite for IP UTRAN...................................................................................................................31 3GPP
    • Release 5 4 3GPP TR 25.933 V5.4.0 (2003-12)6.2.6.1 Background....................................................................................................................................................316.2.6.2 UDP Lite 316.3 QoS 326.3.1 Fragmentation...................................................................................................................................................326.3.1.1 General 326.3.1.2 IP fragmentation.............................................................................................................................................336.3.1.3 Fragmentation to facilitate delay sensitive traffic..........................................................................................336.3.1.4 Application level fragmentation.....................................................................................................................336.3.1.5 Layer 2 fragmentation solution......................................................................................................................346.3.2 Sequence information........................................................................................................................................346.3.3 Error detection...................................................................................................................................................346.3.4 Flow Classification in IP Networks..................................................................................................................346.3.4.1 Classification based on RNL information......................................................................................................346.3.4.2 Classification based on TNL information......................................................................................................356.3.5 Classification Configuration.............................................................................................................................356.3.5.1 Transport bearer based classification.............................................................................................................356.3.5.2 Packet per packet classification.....................................................................................................................356.3.6 UTRAN Hop-by-Hop QoS Approach...............................................................................................................366.3.7 UTRAN End-to-End QoS Approach................................................................................................................366.4 Transport network bandwidth utilization.............................................................................................................366.4.1 General issues....................................................................................................................................................376.4.1.1 Multiplexing...................................................................................................................................................376.4.1.1.1 Location of multiplexing in transport network...........................................................................................376.4.1.1.1.1 Scenario 1: 376.4.1.1.1.2 Scenario 2: 386.4.1.1.1.3 Scenario 3: 386.4.1.2 Resource Management...................................................................................................................................396.4.1.3 Header Compression Techniques...................................................................................................................396.4.1.3.1 Technical evaluation...................................................................................................................................396.4.1.3.1.1 Use of Differential Coding ......................................................................................................................406.4.1.3.1.2 Comparison 406.4.1.3.2 UTRAN Evaluation.....................................................................................................................................406.4.1.3.3 Use of Negotiation......................................................................................................................................406.4.2 Solution Comparison data.................................................................................................................................406.5 User plane transport signalling.............................................................................................................................416.5.1 Solution without ALCAP..................................................................................................................................416.5.1.1 Principle 416.5.1.2 Solution without using additional RNL Parameters.......................................................................................426.5.1.2.1 On Iub - Iur..................................................................................................................................................426.5.1.2.2 Inter-working on Iu.....................................................................................................................................436.5.1.3 Solution with higher flexibility and complexity using additional RNL parameters......................................446.5.1.4 Provisioning and Dynamic Selection of the Transport Option .....................................................................446.5.1.4.1 On Iub 446.5.1.4.2 Inter-working on Iu.....................................................................................................................................446.5.1.4.3 Interworking on Iur.....................................................................................................................................456.5.1.4.3.1 Provisioning of transport capabilities ......................................................................................................456.5.1.4.3.2 Indicate dynamically in a signaling message the IP Transport Option Availability or ATM Preference ............................................................................................................................................456.5.1.4.3.3 Benefits 456.5.1.4.3.4 Drawbacks 456.5.2 LIPE solution....................................................................................................................................................466.5.2.1 Alternative I Solution:....................................................................................................................................466.5.2.1.1 LIPE Signalling Channel.............................................................................................................................476.5.2.1.2 Tunnel Setup Procedure..............................................................................................................................476.5.2.1.3 Connection Set up Procedure......................................................................................................................476.5.2.1.4 Tunnel tear down.........................................................................................................................................476.5.2.1.5 Connection tear down.................................................................................................................................486.5.2.2 Alternative II Solution:..................................................................................................................................486.6 Layer 1 and layer 2 independence........................................................................................................................486.6.1 Options for L2 specification..............................................................................................................................486.6.1.1 General 48 3GPP
    • Release 5 5 3GPP TR 25.933 V5.4.0 (2003-12)6.6.1.2 L2 not standardized........................................................................................................................................486.6.1.3 L2 standardized..............................................................................................................................................496.7 Radio Network Signalling bearer.........................................................................................................................496.7.1 Iub RNL signalling bearer.................................................................................................................................496.7.1.1 SCTP characteristics .....................................................................................................................................496.7.1.2 Proposal 1.......................................................................................................................................................496.7.1.3 Proposal 2.......................................................................................................................................................506.7.1.4 Use of SCTP...................................................................................................................................................506.7.2 RNSAP Signalling............................................................................................................................................516.7.3 RANAP Signalling............................................................................................................................................516.7.4 PCAP signalling................................................................................................................................................526.7.5 SCCP/M3UA versus SUA ...............................................................................................................................526.7.6 Interworking of SCCP/M3UA and SUA...........................................................................................................536.7.6.1 Interworking in native SS7 networks.............................................................................................................546.7.6.2 Interworking in SS7 and SigTran Networks..................................................................................................546.7.6.3 Interworking in UTRAN................................................................................................................................586.7.6.4 SCCP and SUA interworking in detail ..........................................................................................................596.7.6.4.1 Establishment of SUA connectivity............................................................................................................596.7.6.4.2 SEP Failover................................................................................................................................................606.7.6.4.3 Successful ASP Failover scenario...............................................................................................................606.7.6.4.4 Message mapping between SCCP and SUA...............................................................................................616.7.6.5 Conclusions....................................................................................................................................................626.7.7 Iub Signalling Bearer Comparison Data...........................................................................................................626.7.7.1 Comparison TCP, UDP, SCTP......................................................................................................................626.7.7.1.1 User service.................................................................................................................................................626.7.7.1.2 Reliability 626.7.7.1.3 Availability..................................................................................................................................................626.7.7.1.4 Defence/Security.........................................................................................................................................636.7.7.1.5 Performance................................................................................................................................................636.7.7.1.6 RNL changes...............................................................................................................................................646.7.7.1.7 Implementation Difficulty...........................................................................................................................646.7.7.1.8 Maturity 646.7.7.1.9 Interoperability............................................................................................................................................646.7.7.1.10 Operational aspects...................................................................................................................................646.7.7.2 Summary 656.7.8 Reference Architecture for ENUM based Services..........................................................................................656.7.8.1 Key requirements/assumptions of the mobility services using ENUM.........................................................656.7.8.2 Some definitions.............................................................................................................................................666.7.8.3 System solution based on ENUM..................................................................................................................676.7.8.4 Service discovery/IP address retrieval of end service nodes.........................................................................676.8 Addressing............................................................................................................................................................696.8.1 General addressing requirements......................................................................................................................696.8.2 Bearer addressing solutions...............................................................................................................................706.8.2.1 Destination IP addresses and destination UDP ports as connection identifiers.............................................706.9 IP transport and routing architecture aspects.......................................................................................................716.9.1 Flexibility of IP architectures ...........................................................................................................................716.9.2 Hosts and routers...............................................................................................................................................716.9.3 IPv6 aspects.......................................................................................................................................................736.9.3.1 Improved Performance...................................................................................................................................736.9.3.2 Autoconfiguration .........................................................................................................................................736.9.3.3 IPv6 to IPv4 interworking..............................................................................................................................736.9.3.3.1 Network Address/Port Translators-Protocol Translators (NAPT-PT)........................................................746.9.3.3.2 Stateless IP/ICMP Translation Algorithm (SIIT).......................................................................................746.9.3.3.3 Dual stack 746.9.3.4 Tunneling ......................................................................................................................................................766.9.3.5 Summary 766.10 Backward compatibility with R99-R4/Coexistence with ATM nodes..............................................................776.10.1 General............................................................................................................................................................776.10.2 Interworking Options......................................................................................................................................786.10.2.1 Dual Stack operation within Rel.5 RNCs....................................................................................................786.10.2.1.1 Interworking with PWE3-capable ATM Switch.......................................................................................79 3GPP
    • Release 5 6 3GPP TR 25.933 V5.4.0 (2003-12)6.10.2.2 Transport Network Layer IWU....................................................................................................................806.10.2.2.1 Issue on TNL IWU control protocol.........................................................................................................816.10.3 Conclusion.......................................................................................................................................................836.10.4 UTRAN Architecture considerations..............................................................................................................836.10.5 ATM/IP Interworking solution proposals.......................................................................................................846.10.5.1 Bearer control proposal using IETF SIP/SDP..............................................................................................846.10.5.1.1 Description................................................................................................................................................856.10.5.1.2 Bearer control between IP and ATM nodes signalling examples.............................................................856.10.5.1.3 Use of SIP for Interworking between UTRAN ATM interfaces and UTRAN IP interfaces....................876.10.5.1.3.1 Description 876.10.5.1.3.1.1 Inter Working Problem Summary.......................................................................................................876.10.5.1.3.1.2 Approach/Aims...................................................................................................................................876.10.5.1.3.1.3 Using SIP as a Transport Bearer Signalling Protocol.........................................................................876.10.5.1.3.1.4 Implementation...................................................................................................................................876.10.5.1.3.1.4.1 ACK message...................................................................................................................................876.10.5.1.3.1.4.2 Communication of endpoint information and session identification...............................................896.10.5.1.3.1.4.2.1 SIP header fields...........................................................................................................................906.10.5.1.3.1.4.2.2 SDP parameters.............................................................................................................................906.10.5.1.3.1.4.2.3 Example message..........................................................................................................................916.10.5.2 Bearer Control proposal using a new protocol (“Q.IP-ALCAP”), optimised for concatenation with AAL Type 2 links....................................................................926.10.5.2.1 Overall Scenario for “Q.IP-ALCAP”........................................................................................................936.10.5.2.2 Protocol Stack for “Q.IP-ALCAP”...........................................................................................................956.10.5.2.3 Example: Connection Establishment on Iur..............................................................................................956.10.5.3 IP-ALCAP based on Q.2630........................................................................................................................966.10.5.3.1 Benefits 966.10.5.3.2 IP-specific information in Q.2630 in Served User Transport (SUT) parameter.......................................976.10.5.3.2.1 Served User Transport parameter in Q.2630..........................................................................................976.10.5.3.2.2 Structure of information.........................................................................................................................986.10.5.4 Use of IETF RSVP for ATM/IP interworking...........................................................................................1006.10.5.4.1 Working scenarios...................................................................................................................................1006.10.5.4.1.1 ATM UTRAN Node initiated RL Setup procedure.............................................................................1006.10.5.4.1.2 IP UTRAN Node initiated RL Setup procedure..................................................................................1026.10.5.4.1.3 RSVP considerations............................................................................................................................1036.10.5.5 Inter-working with a PWE3-Capable ATM Switch ..................................................................................103Example: Connection Establishment on Iur.............................................................................................................1046.10.6 Coexistence between Rel.5 and R99/R4 Iur Control Plane using SUA protocol.........................................1056.10.6.1 Connecting an Rel.5 RNC to a R99/R4 RNC............................................................................................1056.11 Synchronization................................................................................................................................................1076.12 Security............................................................................................................................................................1076.12.1 Security Threats............................................................................................................................................1076.12.2 Security Operation in IP networks................................................................................................................1076.12.2.1 IPSec architectures.....................................................................................................................................1076.12.2.2 SCTP Security features..............................................................................................................................1076.12.2.3 Firewalls and other systems.......................................................................................................................1086.13 Iu-cs/Iu-ps harmonization................................................................................................................................1086.13.1 GTP-U for Iu user plane................................................................................................................................1086.13.1.1 Iu PS 1086.13.1.2 Iu CS 1086.13.1.3 GTP header for the Iu-PS user plane..........................................................................................................1086.13.1.4 User plane header simplification considerations for the Iu-PS..................................................................1096.13.1.5 Proposed GTP-U-like header scenario "A" for real-time applications......................................................1106.13.1.6 GTP-U-like alternative header scenario "B" for real-time applications....................................................1106.13.1.7 Comparison of the GTP-U header and the possible new scenarios "A" and "B"......................................1116.13.1.8 Motivation for GTP-U................................................................................................................................1126.13.2 RTP for Iu-cs interface..................................................................................................................................1126.13.2.1 Reasons for selecting an RTP/UDP/IP based Iu-cs User Data Transport stack.........................................1126.13.2.2 Motivation for not choosing the RTP alternative.......................................................................................1136.13.2.2.1 General 1136.13.2.2.2 Commonality with Nb interface..............................................................................................................1136.13.2.2.3 Special RTP capability ...........................................................................................................................113 3GPP
    • Release 5 7 3GPP TR 25.933 V5.4.0 (2003-12)6.13.2.2.4 Bandwidth utilization..............................................................................................................................1147 Agreements and associated agreed contributions...............................................................................1147.1 External standardization.....................................................................................................................................1147.2 QoS differentiation.............................................................................................................................................1147.3 Transport network bandwidth utilization...........................................................................................................1157.3.1 Multiplexing....................................................................................................................................................1157.4 User plane transport signalling...........................................................................................................................1157.5 Layer 1 and layer 2 independence......................................................................................................................1157.6 Radio Network Signalling bearer.......................................................................................................................1157.7 Addressing..........................................................................................................................................................1167.8 Transport architecture and routing aspects........................................................................................................1177.9 Backward compatibility with R99-R4/Coexistence with ATM nodes..............................................................1177.10 Synchronization................................................................................................................................................1187.11 Security............................................................................................................................................................1187.12 Iu-cs/Iu-ps harmonization................................................................................................................................1187.13 Iur/Iub User plane protocol stacks...................................................................................................................1187.14 Iu-cs/Iu-ps user plane protocol stacks..............................................................................................................1197.14.1 Iu-cs 1197.14.2 Iu-ps 1197.15 IP version issues...............................................................................................................................................1198 Specification Impact and associated Change Requests.......................................................................1208.1 TS 25.401...........................................................................................................................................................1208.1.1 Impacts 1208.1.2 List of Change Requests..................................................................................................................................1208.2 TS 25.410...........................................................................................................................................................1208.2.1 Impacts 1208.2.2 List of Change Requests..................................................................................................................................1208.3 TS 25.411...........................................................................................................................................................1208.3.1 Impacts 1208.3.2 List of Change Requests..................................................................................................................................1208.4 TS 25.412...........................................................................................................................................................1218.4.1 Impacts 1218.4.2 List of Change Requests..................................................................................................................................1218.5 TS 25.413...........................................................................................................................................................1218.5.1 Impacts 1218.5.2 List of Change Requests..................................................................................................................................1218.6 TS 25.414...........................................................................................................................................................1218.6.1 Impacts 1218.6.2 List of Change Requests..................................................................................................................................1218.7 TS 25.415...........................................................................................................................................................1218.7.1 Impacts 1218.7.2 List of Change Requests..................................................................................................................................1218.8 TS 25.420...........................................................................................................................................................1218.8.1 Impacts 1218.8.2 List of Change Requests..................................................................................................................................1218.9 TS 25.422...........................................................................................................................................................1228.9.1 Impacts 1228.9.2 List of Change Requests..................................................................................................................................1228.10 TS 25.423.........................................................................................................................................................1228.10.1 Impacts..........................................................................................................................................................1228.10.2 List of Change Requests................................................................................................................................1228.11 TS 25.424.........................................................................................................................................................1228.11.1 Impacts..........................................................................................................................................................1228.11.2 List of Change Requests................................................................................................................................1228.12 TS 25.426.........................................................................................................................................................1228.12.1 Impacts..........................................................................................................................................................1228.12.2 List of Change Requests................................................................................................................................1228.13 TS 25.430.........................................................................................................................................................1228.13.1 Impacts..........................................................................................................................................................1228.13.2 List of Change Requests................................................................................................................................122 3GPP
    • Release 5 8 3GPP TR 25.933 V5.4.0 (2003-12)8.14 TS 25.432.........................................................................................................................................................1238.14.1 Impacts..........................................................................................................................................................1238.14.2 List of Change Requests................................................................................................................................1238.15 TS 25.433.........................................................................................................................................................1238.15.1 Impacts..........................................................................................................................................................1238.15.2 List of Change Requests................................................................................................................................1238.16 TS 25.434.........................................................................................................................................................1238.16.1 Impacts..........................................................................................................................................................1238.16.2 List of Change Requests................................................................................................................................1238.17 TS 25.442.........................................................................................................................................................1238.17.1 Impacts..........................................................................................................................................................1238.17.2 List of Change Requests................................................................................................................................1239 Project Plan........................................................................................................................................1239.1Schedule..............................................................................................................................................................1239.2 Work Task Status...............................................................................................................................................12410 Open Issues......................................................................................................................................124Annex A: Simulation Model...............................................................................................................126A.1 Introduction....................................................................................................................................126A.2 Simulation scenarios.......................................................................................................................126A.3 Simulation model framework.........................................................................................................126A.4 Source Traffic Models....................................................................................................................126A.4.1 Speech source model......................................................................................................................................126A.4.2 Data source model..........................................................................................................................................127A.4.2.1 Data Source Model 1...................................................................................................................................127A.4.2.2 Data source model 2....................................................................................................................................127A.5 RLC/FP model...............................................................................................................................128A.5.1 Voice Traffic..................................................................................................................................................128A.5.2 Packet data Traffic.........................................................................................................................................128A.6 Protocol Stack Models....................................................................................................................129A.6.1 Overview........................................................................................................................................................129A.6.2 Module Functions...........................................................................................................................................131A.6.2.1 Header Compression (FFS).........................................................................................................................131A.6.2.2 Packetizer....................................................................................................................................................131A.6.2.3 Queues.........................................................................................................................................................131A.6.2.4 Segment Function........................................................................................................................................132A.6.2.5 Scheduler.....................................................................................................................................................132A.6.3 Examples........................................................................................................................................................132A.7 Last Mile Link Models...................................................................................................................132A.8 Performance criteria.......................................................................................................................132Annex B: Appendix.............................................................................................................................134B.1 Additions table 7-6, clause 7.2.2 of [2]: Parameters of the AAL type 2 signalling protocol messages ....................................................................................................................................................134B.2 Additions to table 7-7, clause 7.2.2 of [2]: Parameters of the AAL type 2 signalling protocol messages.....................................................................................................................................135B.3 Additions to clause 7.3 of [2]: Parameter specification of the AAL type 2 signalling protocol messages.....................................................................................................................................135B.4 Additions to clause 7.4 of [2]: Field specification of the AAL type 2 signalling protocol parameters ....................................................................................................................................................135B.5 Additions to clause 8.2.2 of [2]: Nodal functions for AAL type 2 nodes without served user interaction...................................................................................................................................136 3GPP
    • Release 5 9 3GPP TR 25.933 V5.4.0 (2003-12)B.6 Additions to the annex of [2]: Nodal functions for AAL type 2 nodes without served user interaction ....................................................................................................................................................136Annex C: Coding of the compatibility information..........................................................................137C.1 Coding of the compatibility information.........................................................................................137C1.1 Parameter compatibility...................................................................................................................................137Annex D: Change History..........................................................................................................138 3GPP
    • Release 5 10 3GPP TR 25.933 V5.4.0 (2003-12)ForewordThis Technical Report 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 formalTSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with anidentifying 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. 3GPP
    • Release 5 11 3GPP TR 25.933 V5.4.0 (2003-12)1 ScopeThe purpose of the present document is to help the TSG RAN WG3 group to specify the changes to existingspecifications, needed for the introduction of "IP Transport" option in the UTRAN for Release 5. It is intended to gatherall information in order to trace the history and the status of the Work Task in RAN WG3. It is not intended to replacecontributions and Change Requests, but only to list conclusions and make reference to agreed contributions and CRs.When solutions are sufficiently stable, the CRs can be issued.It describes agreed requirements related to the Work Task, and split the Work Task into "Study Areas" in order to groupcontributions in a consistent way.It identifies the affected specifications with related Change Requests.It also describes the schedule of the Work Task.The present document is a "living" document, i.e. it is permanently updated and presented to all TSG-RAN meetings.2 ReferencesThe following documents contain provisions which, through reference in this text, constitute provisions of the presentdocument. • 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] IP-Transport in UTRAN Work Task Description, as agreed at TSG RAN#6 [2] 3GPP TS 25.401: "UTRAN Overall Description". [3] 3GPP TS 25.410: "UTRAN Iu Interface: General Aspects and Principles". [4] 3GPP TS 25.412: "UTRAN Iu interface signalling transport". [5] 3GPP TS 25.420: "UTRAN Iur Interface: General Aspects and Principles". [6] 3GPP TS 25.422: "UTRAN Iur interface signalling transport". [7] 3GPP TS 25.430: "UTRAN Iub Interface: General Aspects and Principles". [8] 3GPP TS 25.427: "UTRAN Iur and Iub interface user plane protocols for DCH data streams". [9] IETF RFC 1812: "Requirements for IP Version 4 Routers", June 1995. [10] R. Pazhyannur, I. Ali, Craig Fox, "PPP Multiplexed Frame Option", RFC3153, August 2001.. [11] IETF RFC 1661 (STD 51): "The Point-to-Point Protocol (PPP)", W. Simpson, Ed., July 1994. [12] IETF RFC 1662 (STD 51): "PPP in HDLC-like Framing", W. Simpson, Ed., July 1994. [13] IETF RFC 2508: "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", S. Casner, V. Jacobson, February 1999. [14] IETF RFC 2509: "IP Header Compression over PPP", M. Engan, S. Casner, C. Bromann, February 1999. 3GPP
    • Release 5 12 3GPP TR 25.933 V5.4.0 (2003-12) [15] IETF RFC 2364: "PPP Over AAL5", G. Gross, M. Kaycee, A. Lin, J. Stephens, July 1998. [16] IETF RFC 2661: "Layer Two Tunneling Protocol "L2TP"", W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter, August 1999. [17] Bruce Thompson, Tmima Koren, Dan Wing, "Tunneling multiplexed Compressed RTP (TCRTP)", <draft-ietf-avt-tcrtp.06.txt>, February 27, 2002. [18] Andrew J. Valencia, "L2TP Header Compression (L2TPHC), <draft-ietf-l2tpext-l2tphc-04.txt>, October 2001. [19] Tmima Koren, Stephen Casner, Patrick Ruddy, Bruce Thompson, Alex Tweedly, Dan Wing, John Geevarghese, ", “Compressing IP/UDP/RTP headers on links with high delay, packet loss and reordering”, <draft-ietf-avt-crtp-enhance-04.txt>, February 24, 2002. [20] IETF RFC 1990: "The PPP Multilink Protocol (MP)". [21] IETF RFC 2686: "The Multi-Class Extension to Multi-Link PPP". [22] "A Lightweight IP Encapsulation Scheme", draft-chuah-avt-lipe-02.txt, M. Chuah, E. J. Hernandez-Valencia, December 2000. NOTE 1: Expired. There is no new version. [23] IETF RFC 3031: "Multi-Protocol Label Switching Architecture" , January 2001. [24] IETF RFC 2719: "Framework Architecture for Signaling Transport", October 1999. [25] IETF RFC 2960: "Stream Control Transmission Protocol", October 2000. [26] J. Loughney,G. Sidebottom, Guy Mousseau, S.Lorusso, SS7 SCCP-User Adaptation Layer (SUA), <draft-ietf-sigtran-sua-12.txt>, 11 February 2002. [27] IETF RFC 2460: "Internet Protocol, Version 6 (Ipv6) Specification", December 1998. [28] IETF RFC 2462: "Ipv6 Stateless Address Autoconfiguration", December 1998. [29] "An overview of the introduction of IPV6 in the Internet", ”, IETF draft-ietf-ngtrans-introduction- to-ipv6-transition-08, February 2002. [30] IETF RFC 2893, "Transition Mechanisms for Ipv6 Hosts and Routers", August 2000. [31] IETF RFC 3270, "MPLS Support of Differentiated Services", May 2002. [32] "Tunneling Multiplexed Compressed RTP in MPLS", draft-theimer-tcrtp-mpls-00.txt, IETF work in progress, June 2000. NOTE 2: Expired. There is no new version. [33] "Frame Relay Fragmentation Implementation Agreement, FRF.12" http://www.frforum.com/5000/ Approved/FRF.12/frf12.doc. [34] "Simple Header Compression", draft-swallow-mpls-simple-hdr-compress-00.txt, March 2000, work in progress NOTE 3: Expired. There is no new version. [35] IETF RFC 2687: "PPP in a Real-time Oriented HDLC-like Framing". [36] "COPS Usage for MPLS/Traffic Engineering", draft-franr-mpls-cops-00.txt, July 2000, work in progress. NOTE 4: Expired. There is no new version. [37] "Constraint-Based LSP Setup using LDP", draft-ietf-mpls-cr-ldp-05.txt, February 2001, work in progress. 3GPP
    • Release 5 13 3GPP TR 25.933 V5.4.0 (2003-12) NOTE 13:Expired . There is no new version. [38] "RSVP-TE: Extensions to RSVP for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, February 2001, work in progress NOTE 5: Expired . There is no new version. [39] "MPLS/IP Header Compression", draft-ietf-mpls-hdr-comp-00.txt, July 2000, work in progress. NOTE 6: Expired. There is no new version. [40] R3-010181: "Comparison CIP/MPLS". [41] "MPLS/IP Header Compression over PPP", draft-ietf-mpls-hdr-comp-over-ppp-00.txt, July 2000, work in progress. NOTE 7: Expired. There is no new version. [42] IETF RFC 768: "User Datagram Protocol". [43] 3GPP TS 21.133: "3G security; Security threats and requirements". [44] IETF RFC 2401: "Security Architecture for the Internet Protocol", November 1998. [45] IETF RFC 2408: "Internet Security Association and Key Management Protocol (ISAKMP)", November 1998. [46] 3GPP TS 29.060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface". [47] draft-larzon-udplite-04.txt, "The UDP Lite protocol". NOTE 8: Expired. There is no new version. [48] 3GPP TR 23.910: "Circuit switched data bearer services". [49] IETF RFC 791 (9/1981): "Internet Protocol". [50] 3GPP TR 29.903: "Feasibility study on SS7 signalling transportation in the core network with SCCP-User Adaptation (SUA)". [51] IETF RFC 2507: "IP Header Compression", M. Degermark, B. Nordgren, S. Pink , February 1999. [52] ITU-T Recommendation Q.2630.1: "AAL Type 2 Signalling Protocol (Capability Set 1)". [53] ITU-T Recommendation Q.2150.3: "Signalling Transport Converter on SCTP". [54] IETF RFC 2205: "Resource ReSerVation Protocol (RSVP); Version 1 Functional Specification". [55] IETF RFC 2210: "The use of RSVP with IETF Integrated Services". [56] IETF RFC 2996: "Format of the RSVP DCLASS Object". [57] IETF RFC 2543: "SIP: Session Initiation Protocol". [58] IETF RFC 2327: "SDP: Session Description Protocol". [59] IETF RFC 1889: "RTP: A Transport Protocol for Real-Time Applications". [60] 3GPP TS 25.411: "UTRAN Iu interface Layer 1". [61] ISO/IEC 8348: "Information technology – Open Systems Interconnection – Network service definition". [62] ISO/IEC 8348/Amd.1: "Information technology – Open Systems Interconnection – Network service definition Amendment 1: Addition of the Internet protocol address format identifier", 3GPP
    • Release 5 14 3GPP TR 25.933 V5.4.0 (2003-12) [65] IETF RFC 2874: "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", July 2000. [67] ITU-T SG11: TD GEN/11-49r1 “Draft Signalling Requirements for AAL Type 2 to IP Interworking (TRQ.AAL2IP.iw)” February 2002 [68] ITU-T SG11: TD GEN/11-54r3 “Report of Q.6/11, Joint Qs.6 & 9/11 and Q.9/11 discussions” March 2002 [69] 3GPP TSG RAN WG3: R3-021366 “A2IP Signalling Protocol (Q.IPALCAP Spec draft)” May 2002 [70] draft-ietf-pwe3-framework-01.txt: "Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3)" [71] draft-ietf-pwe3-atm-encap-01.txt: "Encapsulation Methods for Transport of ATM Cells/Frame Over IP and MPLS Networks"3 Definitions, symbols and abbreviations3.1 DefinitionsFor the purposes of the present document, the following terms and definitions apply.3.2 SymbolsFor the purposes of the present document, the following symbols apply:3.3 AbbreviationsFor the purposes of the present document, the following abbreviations apply: AAL2 ATM Adaptation Layer type 2 ACK Acknowledgement ALCAP Access Link Control Application Protocol ATM Asynchronous Transfer Mode CDN Compressing/Decompressing Node CRC Cyclic Redundancy Check CRNC Controlling Radio Network Controller DRNC Drift Radio Network Controller FEC Forwarding Equivalence Class FP Frame Protocol FR Full Rate GPRS General Packet Radio Service GSM Global System for Mobile communications GTP GPRS Tunneling Protocol HDLC High Level Data Link Control ICMP Internet Control Message Protocol IP Internet Protocol Ipv4 Internet Protocol Version 4 Ipv6 Internet Protocol Version 6 L2TP Layer Two Tunneling Protocol LAN Local Area Network LCP Link Control Protocol LDP Label Distribution Protocol LEN LENgth LSB Least Significant Bit LSP Label-Switched Path 3GPP
    • Release 5 15 3GPP TR 25.933 V5.4.0 (2003-12) LSRs Label Switched Routers LXT Length ExTension MPLS Multi-Protocol Label Switching MSB Most Significant Bit MTU Maximum Transmission Unit NAPT-PT Network Address/Port Translators-Protocol Translators NBAP Node B Application Part NCP Network Control Protocol NSP Network Service Part O&M Operations & Maintenance PDCP Packet Data Convergence Protocol PDU Protocol Data Unit PFF Protocol Field Flag PPP Point-to-Point Protocol PPPmux PPP Multiplexing PVC Permanent Virtual Circuit PWE3 Pseudo Wire Emulation Edge to Edge QoS Quality of Service RAB Radio Access Bearer RANAP Radio Access Network Application Part RFC Request For Comments RNL Radio Network Layer RNSAP Radio Network Subsystem Application Part RSVP Resource ReserVation Protocol SAPC Service Application PLMN Code SCCP Signalling Connection Control Part SEP Signalling End Point SIIT Stateless IP/ICMP Translation algorithm SP Signalling Points SRNC Serving Radio Network Controller SS7 Signalling System No. 7 SSSAR Service Specific Segmentation and Re-assembly sublayer STP Signalling Transfer Point SUGR Served User Generated Reference parameter TLV Type-Length-Value TNL Transport Network Layer ToS Type of Service TTI Transmission Timing Interval UDP User Datagram Protocol UMTS Universal Mobile Telecommunications System UTRAN Universal Terrestrial Radio Access Network VPN Virtual Private Network4 Introduction4.1 Task DescriptionThe work task is described in the contribution [1], which has been agreed at TSG-RAN#6. The purpose of this newwork task is to enable the usage of IP technology for the transport of signalling and user data over Iu, Iur and Iub in theUTRAN.4.2 Rationale for IP TransportThis clause will describe some rationale for IP Transport option in the UTRAN.Some mobile operators require a UTRAN transport solution for IP as an alternative to ATM.This is partly due to the following reasons: 3GPP
    • Release 5 16 3GPP TR 25.933 V5.4.0 (2003-12) 1) IP is developing to allow the support of a mix of traffic types and to support low speed links. 2) The popularity of the Internet/World Wide Web and corporate LANs puts price pressure on IP networking equipment. 3) IP is the technology to the "desktop" (terminals) so most applications will be based on IP. 4) Operation and maintenance networks will be based on IP. To have networks with homogeneous technology can save management and operations costs. 5) IP, like ATM, is a packet-switched technology and provides the opportunity to use transport resources in an efficient manner. 6) IP is Layer 2 independent. 7) Autoconfiguration capabilities. 8) Dynamic update of routing tables.It is clear that there will be IP data traffic in the mobile networks. It should be a matter of an operators choice whetherIP or ATM is used in the transport network to carry the various types of traffic from the circuit and packet domains.5 RequirementsThis clauseclause details high level requirements for the IP UTRAN option.5.1 General requirementsWhenever possible, preference for already standardized protocols should be used, e.g. IETF protocols for the IP relatedparts, in order to have wide spread acceptance and avoid double work. Relevant UTRAN recommendations may also bestandardized in the IETF.By "IETF protocols", it is meant standards RFCs and working group internet drafts.The use of Ipv6 shall not be precluded.5.2 Independence to Radio Network LayerThe changes should only be made to the Transport Network Layer (TNL) since the Radio Network Layer should beindependent of the TNL. The impact on the RNL shall be minimized but there could be some minor changes to theRadio Network Layer, e.g. addressing.Not requiring the end point RNL user plane frame protocols to be aware of the underlying multiplexing, i.e.,transparency.5.3 Services required by the upper layers of user planes of IuFor the Iu_CS the requirement is transfer of user data (TS 25.415) and in-sequence delivery is not required.It is a requirement that the Radio Network Layer (RNL) functional split shall not be changed depending on the TNLtechnology. This is in line with the architectural principle of separation of the RNL and TNL stated in [2]. If the RNL isdifferent for different transport technologies, backward compatibility is lost or complicated and an implementation ispotentially complicated when changing transport. The RNL shall be independent from the transport type.In order to be compatible with the Release 99 / Release 4 IuCS, Iur, and Iub, the following requirements for setting uptransport bearers shall apply for IP transport:The SRNC (Iu/Iur)/CRNC (Iub) TNL receives a request from the RNL to establish a bidirectional transport bearer. Therequest includes the end system address and transport bearer association received from the peer. It also includes thequality of service and resources required from the transport network. 3GPP
    • Release 5 17 3GPP TR 25.933 V5.4.0 (2003-12)5.4 Services required by the upper layers of user planes of Iur and IubIn the current specifications the AAL2/ATM provides the services to radio network layer. The services required by theradio network layer are: - connection identification; - in-sequence delivery of PDUs to upper layers (TS 25.425, TS 25.427). If this means re-ordering of PDUs or simply not sending data that have been received out-of-sequence is not clearly stated.It is a requirement that the Radio Network Layer (RNL) functional split shall not be changed depending on the TNLtechnology. This is in line with the architectural principle of separation of the RNL and TNL stated in [2]. If the RNL isdifferent for different transport technologies, backward compatibility is lost or complicated and an implementation ispotentially complicated when changing transport.In order to be compatible with the Release 99 / Release 4 IuCS, Iur, and Iub, the following requirements for setting uptransport bearers shall apply for IP transport.The SRNC (Iu/Iur)/CRNC (Iub) TNL receives a request from the RNL to establish a bidirectional transport bearer. Therequest includes the end system address and transport bearer association received from the peer. It also includes thequality of service and resources required from the transport network.5.5 Coexistence of the two transport optionsIn Release 5, UTRAN(s) may have both ATM and IP transport networks. Following requirements with regards to ATMand IP transport network coexistence shall be met: - The specifications shall ensure the co-existence of ATM and IP Transport options within UTRAN, i.e. parts of UTRAN using ATM and parts of UTRAN using IP transport. - In Release 5, ATM and IP Transport Options shall rely on the same functional split between Network Elements.The transport technology choices of an UMTS operator will vary. Some will use AAL2/ATM. Others will use IP andothers will use both AAL2/ATM and IP. Interoperability between Release 99 / Release 4 and later UTRAN ATMinterfaces and UTRAN IP interfaces (for example, IP Iur to ATM Iur) is an important function for operators deployingboth types of transport networks. An interworking solution shall be included in the specification.The following are requirements for the interworking solution: 1) It shall be possible for a UTRAN to support Release 99 / Release 4 and later ATM interfaces and UTRAN IP interfaces. One means of assuring that UTRAN nodes can communicate with each other is for nodes to have both ATM and IP interfaces. 2) Where Node terminating Iu, Iur or Iub does not support ATM interfaces (Release 99 / Release 4 and later releases) and UTRAN IP interfaces, an TNL interworking function shall be required to enable the nodes to inter- operate between ATM and IP technologies.5.6 Quality of ServiceThe mechanisms to secure the quality of service parameters, timing aspects, and packet loss have to be considered.Quality of service parameters include service class definition and congestion control requirements. Timing aspectsinclude delay and delay-variation requirements.TNL shall provide the appropriate QoS requested by the RNL. However, the way the end-to-end transport networkactually implements the QoS shall not be specified below IP.Mechanisms that provide QoS or efficient bandwidth utilization must take into account UTRAN traffic (Control plane,user plane, O&M) and non-UTRAN traffic. 3GPP
    • Release 5 18 3GPP TR 25.933 V5.4.0 (2003-12)5.7 Efficient utilization of transport resourcesEfficient use of the bandwidth of the transport network shall be considered, e.g. by reducing the protocol overhead (viaHeader compression, multiplexing, …).Iub/Iur protocols shall operate efficiently on low speed point to point links which may be shared with other traffic (e.g.GSM/GPRS Abis, UMTS Release 99 / Release 4 compliant interfaces).The TNL shall provide the functionality of sufficiently de-coupling the bandwidth optimization techniques such thatthey can be used independently of each other.The TNL shall provide the means to enable or disable the schemes for efficient bandwidth usage (e.g. headercompression, multiplexing, etc…).In addition, for high-speed routed segments, it is important that specific bandwidth optimization is not required at everyhop.Mechanisms that provide efficient bandwidth utilization must take into account the QoS requirements of all UTRANtraffic (Control plane, user plane, O&M) also in case of non UTRAN traffic.5.8 Layer 2/Layer 1 independenceThe functionality of the higher layers shall be independent from the Layer 2 and Layer 1 technologies. The higherlayers refer both to the higher protocol layers of the Transport Network Layer and to all Radio Network Layer.The Layer 2 and Layer 1 shall be capable to fulfill the QoS requirements set by the higher layers. IP TransportFlexibility.By defining protocol stacks on Iur, Iub and Iu, one may not make any restrictive assumption on IP transport networktopology. They shall adapt to a wide range of networks (LAN to WAN) and no preference shall be expressed on routedvs. point to point networks.5.9 Transport Bearer IdentificationIn Release 99 / Release 4 UTRAN, ATM transport provides the ability to uniquely address individual flows. In an IPbased UTRAN, the transport network has to provide the means to uniquely address individual flows - both in the user aswell as signalling planes.5.10 Transport Network Architecture and Routing5.10.1 Network elementsNetwork elements e.g. RNC, Node B need to be identified by one or more IP addresses.5.11 Radio Network Signalling BearerThe following are requirements on the signalling transport protocol: 1) It shall be possible for a UTRAN node to support multiple signalling bearers of different transport technologies at the same time. 2) A signalling transport shall allow multiple RNL signalling protocol entities terminating on a node to use a common physical interface. 3) A signalling transport shall provide a means of uniquely identifying the originating and terminating signalling entities. 3GPP
    • Release 5 19 3GPP TR 25.933 V5.4.0 (2003-12)6 Study AreasThis clause gives a summary of areas that have been identified where work needs to be performed to complete the workitem.As work proceeds in Release 5 with regard to IP in the UTRAN, the Work Task is divided in the following StudyAreas.6.1 External standardizationThere is a need for identifying supporting work required by other Standards Bodies. Certain protocols and/or QoSmechanisms may be indicated which are not currently supported in the industry. Appropriate liaisons should beidentified. Procedure for LSs with IETF should be defined. RAN3 needs to start the IETF official communicationchannels.6.2 User plane proposed solutionsThis study area is intended to describe the various proposed solutions for Iur and Iub, Iu-cs and Iu-ps.6.2.1 CIP solution6.2.1.1 CIP ContainerThe aggregation functionality allows to multiplex CIP packets of variable size in one CIP container, also of variablesize. This is necessary for an efficient use of the bandwidth of the links. It is achieved by amortizing the IP/UDPoverhead over several CIP packets. The resulting packet structure is depicted below: IP UDP CIP CIP CIP CIP header header packet packet packet packet ... header payload header payload CIP container Figure 6-1: Generic CIP Container format6.2.1.2 CIP Packets6.2.1.2.1 Segmentation and Re-assemblyA segmentation/re-assembly mechanism allows to split large FP PDUs in smaller segments. There has to be a trade-offbetween efficiency (IP header/payload ratio) and transmission delay. Large data packets have to be segmented in orderto avoid IP fragmentation and to keep transmission delays low.The following figure shows the segmentation process from a FP PDU to several CIP packet payloads. 3GPP
    • Release 5 20 3GPP TR 25.933 V5.4.0 (2003-12) FP PDU FP PDU FP PDU segment FP PDU segment FP PDU segment CIP packet payload CIP packet payload CIP packet payload CIP packet payload FP PDU is not segmented FP PDU is segmented in 3 packets Figure 6-2: CIP segmentation6.2.1.2.2 CIP Packet Header FormatThe proposed CIP packet header format is shown in the following figure. CRC reserved segmentation CID payload length end sequence number flag flag flag 3 bits 1 bit 1 bit 11 bits 8 bits 1 bit 7 bits CID payload length sequence number section section section Figure 6-3: CIP packet header format6.2.1.2.3 The CIP Packet Header Fields in Detail.The CIP packet header is composed of three clauses: 1) The CID clause, also containing CRC and flags is used for multiplexing. This clause is mandatory. - The CRC protects the reserved flag, the segmentation flag and the CID. - The reserved flag is for further extensions. - The segmentation flag indicates that the sequence number field and the end flag are present. These fields are only needed for segmented packets. Because also the aggregation of non-segmented PDUs is a frequent case, e.g. voice, these fields can be suppressed by means of the segmentation flag to save bandwidth. - The CID is the Context ID. This is the identifier of the multiplex functionality, e.g. to distinguish the flows of different calls or users by the higher layers. 2) The payload length clause is used for aggregation. This clause is mandatory. - The payload length is the length of the CIP packet payload. So, CIP packets, containing e.g. FP-PDUs with voice or FP-PDU segments with data, can be between 1 and 256 octets in size. 3GPP
    • Release 5 21 3GPP TR 25.933 V5.4.0 (2003-12) 3) The sequence number clause, also containing the end-flag is used for segmentation. This clause is optional. It exists if the segmentation flag is set. - The end-flag marks the last segment of a packet in a sequence of segments. This field is only present if the segmentation flag is set. - The sequence number is to reassemble segmented packets. This field is only present if the segmentation flag is set. It is incremented for each segment (modulo) and is not reset if the segments of a new packet start. The sequence numbers are maintained for each CID individually.6.2.1.2.4 Discussion of the CIP Packet Header Field SizesOne aim is to have byte aligned boundaries where possible. So, adding a few bits to some fields would increase theheader size by at least 1 byte. The proposed CIP packet header has a length of 3 bytes for non-segmented packets and 4bytes for segmented packets. - The CID field size determines how many flows between a pair of network elements can be supported at the same time. The proposed size of 11 bits allows 2 048 CIDs. This is more than 8 times the amount that AAL2 offers. It can be extended by additional UDP ports, each having its own CID address space. - The size of the Payload Length field. This choice determines the maximum size of a CIP packet payload, containing either a whole FP-PDU or a segment of a FP-PDU. Typically, these packets are either small by nature or they are made small intentionally. So, to stay on byte boundaries, the length field for the CIP packet payload size is proposed to be 1 byte. - The size of the Sequence Number field determines in how many segments a FP PDU can be split before this modulo-incremented field wraps around and becomes ambiguous. The proposed size is 7 bits i.e. 128 segments. One bit has to be reserved for the end-flag. These two fields are combined together because they are both optional and are needed only in case of segmentation. The segment numbers also protect segments that arrive late, from being injected in the next packet with the same CID during the reassembly process. This is the reason why the segment numbers are counted modulo over the full range and do not start with 0 at every new FP PDU. A very worst case scenario with a 2 Mbit/s source would deliver 20 480 bytes within 80 ms. If this PDU is cut to pieces of 256 bytes, 80 segments would result. - The size of the CRC depends on how many bits need protection. A bit error in the length field would interpret the wrong bytes as the next header. But this can be detected, because the next header is again protected by its own CRC. So, the payload length needs no protection. An error in the sequence number would be detected by either placing a segment in a position where another segment with the same number already is, or would be regarded as too late because it belongs to the segment number range of a PDU already processed. Even if the segment is injected in the wrong place, it would be detected by a checksum error of the higher layer. So, the only fields that need protection are the flags and the CID. An error in the CID is critical, because it would inject a formally correct (non-segmented) PDU in the flow to another CID, i.e. to the wrong destination. This might be difficult to detect by the higher layer, because the CID is not a part of the PDU of the higher layer. And so, the CRC of the higher layer alone is not a sufficient protection mechanism against the erroneous injections of formally correct PDUs. For the 13 bits to be protected, a 3 bit CRC seems to be sufficient.6.2.2 LIPE solution [Editors note: This clause refers to deleted or expired ietf-drafts]The LIPE scheme uses either UDP/IP or IP as the transport layer. Each LIPE encapsulated payload consists of avariable number of multimedia data packet (MDP). For each MDP, there is a multiplexing header (MH) that conveysprotocol and media specific information.The format of an IP packet conveying multiple MDPs over UDP using a minimum size MH is below: 3GPP
    • Release 5 22 3GPP TR 25.933 V5.4.0 (2003-12) MH2 IP UDP MH1 MH3 MDP1 MDP2 MDP3 (8) (1-3) (1-3) (20) (1-3) MH: Multiplexed Header MDP: Multiplexed Data payload IP TID MH1 MH2 MH3 (1) MDP1 MDP2 MDP3 (20) (1-3) (1-3) (1-3) TID: Tunnel Identifier PPP/HDLC Framing Figure 6-4: LIPE UDP/IP or IP Encapsulation FormatFigure 6-4 shows the encapsulation format of a LIPE packet. Details of the multiplexed header is described in the nextclause.6.2.2.1 Details of Multiplexed Header 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 E Length Extended Headers (a) Basic Multiplexed Header 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 1 Length 0 Seq No FlowId (b) Extended Multiplexed Header with Seq No & Flow ID 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 1 Length 1 0 Seq No FlowId (c ) Extended Multiplexed Header with Seq No & Flow ID Figure 6-5: Formats of Multiplexed Header6.2.2.2 Basic HeaderThe Multiplexing Header (MH) comprises of two components: The extension bit (the E bit) and the MDP length field.Optional Extension Headers can be supported via the E bit. The MH format is shown in figure 6-5 (a). The E bit is theleast significant bit of the first byte of the MH header. It is set to one/zero to indicate the presence/absence of anextension header. If the E-bit is set to one, the first header extension MUST be a Extended Header Identifier field. TheLength filed is 7 bit. This field indicates the size of the entire MDP packet in bytes, including the E bit, the length fieldand optional extension headers (if they exist).6.2.2.3 ExtensionsExtension headers are used to convey user specific information. It also facilitates the customization of LIPE to provideadditional control information e.g. sequence number, voice/video quality estimator. 3GPP
    • Release 5 23 3GPP TR 25.933 V5.4.0 (2003-12)The 16-bit EHI is the first field in any Extension Header. It is used to identify MDPs belonging to specific user flows.The format of a LIPE encapsulated payload with a FlowID extension header is shown in Figure 6-5 (b). The leastsignificant bit of the 1st byte of EHI is the X-bit. When the X-bit is clear, it means there is a 3 bit header SEQUENCENO. and a 12 bit FlowId. When the X bit is set to one, it indicates that the EOF bit and the 3 bit Seq Number fields existand that the FlowID field is 11 bit. The second least significant bit is the End Of Fragment (EOF) indicator. When EOFis set to 0, it means this is the last fragment (for packets that are not fragmented, this bit is always 0). When EOF is setto 1, it means there are more fragments coming.6.2.3 PPP-MUX based solution [Editors note: This clause refers to deleted or expired ietf-drafts]6.2.3.1 PPP Multiplexed Frame Option Over HDLCPPP Multiplexing (PPPmux) [10], figure 6-6, provides a method to reduce the PPP framing [11] [12] overhead used totransport small packets, e.g. voice frames, over slow links. PPPmux sends multiple PPP encapsulated packets in a singlePPP frame. As a result, the PPP overhead per packet is reduced. When combined with a link layer protocol, such asHDLC, this offers an efficient transport for point-to-point links.At a minimum, PPP encapsulating a packet adds several bytes of overhead, including an HDLC flag character (at leastone to separate adjacent packets), the Address (0xFF) and Control (0x03) field bytes, a two byte PPP Protocol ID, andthe two byte CRC field. Even if the Address and Control Fields are negotiated off and the PPP Protocol ID iscompressed, each PPP encapsulated frame will include four bytes of overhead. This overhead can be reduced to one ortwo bytes.The key idea is to concatenate multiple PPP encapsulated frames into a single PPP multiplexed frame by inserting adelimiter before the beginning of each frame. Each PPP encapsulated frame is called a PPP subframe. Removing thePPP framing characters can save several bytes per packet, reducing overhead.During the NCP negotiation phase of PPP, a receiver can offer to receive multiplexed frames using a PPP Mux ControlProtocol (PPPMuxCP). Once PPPMuxCP has been negotiated, the transmitter may choose which PPP frames tomultiplex. Frames should not be re-ordered by either the transmitter or receiver regardless of whether they arrive as partof the PPP multiplexed frame or by themselves.The PPP Protocol ID field of a subframe can be removed if the PPP Protocol ID of that subframe is the same as that forthe preceding subframe. A Protocol Field Flag (PFF) bit and a Length Extension (LXT) field is defined as part of thelength field (thus reducing the length field from an 8-bit to a 6- bit field). The PFF bit is set if the PPP Protocol ID isincluded in the subframe. The PFF bit is cleared if the PPP Protocol ID has been removed from the subframe. The PFFbit may be set to zero for the first subframe in a PPP multiplexed Frame if the Protocol ID is the same as the defaultPID, as specified by the PPPMuxCP option. The transmitter is not obligated to remove the PPP Protocol ID for anysubframe.The format of the complete PPP frame along with multiple subframes is shown in figure 6-6. Note that regardless of theorder in which individual bits are transmitted, i.e. LSB first or MSB first, the PFF bit will be seen to be the MSB of abyte that contains both the PFF and the subframe length field. HDLC PPPmux P L Len1 PPP Prot. cUDP1 Payload1 Hdr ID F X Field1 (2) (1) (0x59) F T (0-2) Info1 PPP Hdr (2) (1-2) P L LenN PPP Prot. cUDPN PayloadN CRC F X FieldN (2) F T (0-2) (2) InfoN (1-2) Figure 6-6: PPPMux frame with multiple subframes 3GPP
    • Release 5 24 3GPP TR 25.933 V5.4.0 (2003-12)PPP Header: The PPP header contains the HDLC header and the PPP Protocol Field for a PPP Multiplexed Frame(0x59). The PPP header compression options (ACFC and PFC) may be negotiated during LCP and could thus affect theformat of this header.Protocol Field Flag (PFF): This one bit field indicates whether the PPP Protocol ID of the subframe follows thesubframe length field. PFF = 1 indicates that the protocol field is present for this subframe. PFF = 0 indicates that theprotocol field is absent for this subframe. If PFF = 0 then the PPP Protocol ID is the same as that of the precedingsubframe with PFF = 1, or it is equal to the default PID value of the PPPMuxCP Option for the first subframe.Length Field: The length field consists of three subfields: 1) Protocol Field Flag (PFF): The PFF refers to the most significant bit of the first byte of each subframe. This one bit field indicates whether the PPP Protocol ID of the subframe follows the subframe length field. For the first subframe, the PFF bit could be set to zero if the PPP protocol ID of the first subframe is equal to the default PID value negotiated in PPPMuxCP. PFF = 1 indicates that the protocol field is present (and follows the length field) for this subframe. PFF = 0 indicates that the protocol field is absent for this subframe. If PFF = 0 then the PPP Protocol ID is the same as that of the preceding subframe with PFF = 1, or it is equal to default PID value of the PPPMuxCP Option for the first subframe. The transmitter is not obligated to remove the PPP Protocol ID for any subframe. 2) Length Extension (LXT): This one bit field indicates whether the length field is one byte or two bytes long. If the LXT bit is set, then the length field is two bytes long (a PFF bit, a length extension bit, and 14 bits of sub-frame length). If the LXT bit is cleared, then the length field is one byte long (a PFF bit, a length extension bit, and 6 bits of sub-frame length). 3) Sub-frame Length (LEN): This is the length of the subframe in bytes not including the length field. However, it does include the PPP Protocol ID if present (i.e. if PFF = 1). If the length of the subframe is less than 64 bytes (less than or equal to 63 bytes), LXT is set to zero and the last six bits of the length field is the subframe length. If the length of the subframe is greater than 63 bytes, LXT is set to one and the last 14 bits of the length field is the length of the subframe. The maximum length of a subframe is 16,383 bytes. PPP packets larger than 16,383 bytes will need to be sent in their own PPP frame. A transmitter is not required to multiplex all frames smaller than 16,383 bytes. It may chose to only multiplex frames smaller than a configurable size into a PPP multiplexed frame.Protocol Field: This field contains the Protocol Field value for the subframe. This field is optional. If PFF = 1 for asubframe, the protocol field is present in the subframe, otherwise it is inferred at the receiver.The receiver MUST support Protocol-Field-Compression (PFC) for PPP Protocol Ids in this field. Thus the field may beone or two bytes long. The transmitter SHOULD compress PPP Protocol Ids in this field that have an upper byte of zero(i.e. Protocol Ids from 0x21 thru 0xFD). This Protocol Field Compression is not related to the negotiation of PFCduring LCP negotiation, which affects the length of the PPP Multiplexed Frame Protocol ID.Information Field: This field contains the actual packet being encapsulated. Any frame may be included here with theexception of LCP Configure Request, ACK, NAK and Reject frames and PPP multiplexed frames. If LCP isrenegotiated, then PPP Multiplexing MUST be disabled until PPP Mux Control Protocol is negotiated.In the proposed protocol stack the Information Field is comprised of a compressed IP/UDP (cUDP) [12] [13] header(with a minimum length of 2 bytes and maximum of 5 bytes) and the payload of the packet. The PPPMuxCP defaultPID is 0x67, corresponding to cUDP. (A 2-byte cUDP header assumes an 8-bit CID and no UDP checksum.)6.2.3.2 PPP Multiplexed Frame Option Over ATM/AAL5This protocol stack uses the same PPPmux option as described above, but carries PPP over an ATM/AAL5 link layer[14] [15], figure 6-7. Here the HDLC header and CRC trailer is replaced with an ATM header and AAL5 trailer. 3GPP
    • Release 5 25 3GPP TR 25.933 V5.4.0 (2003-12) ATM PPPmux P L Len1 PPP Prot. cUDP1 Payload1 Cell 1 Header ID F X Field1 (2) (5) (0x59) F T (0-2) (1-2) ATM P L Len1 PPP Prot. cUDPN PayloadN AAL5 Cell 2 Header F X FieldN (2) Trailer (5) F T (0-2) (8) (1-2) [Editors note: Payload position needs to be fixed] Figure 6-7: PPPMux over an ATM/AAL56.2.3.3 PPP Multiplexed Frame Option Over L2TP Tunnel (TCRTP) [Editors note: This clause refers to deleted or expired ietf-drafts]In cases where a routed WAN interface is required, one may still use PPPmux, but tunnel it via L2TP [16]. Thisprotocol is called Tunnelled Compressed RTP (TCRTP) -[17], figure 6-8.L2TP tunnels should be used to tunnel the cUDP payloads end to end. This is a natural choice since cUDP payloads arePPP payloads, and L2TP allows tunnelled transport of PPP payloads. L2TP includes methods for tunnelling messagesused in PPP session establishment such as NCP. This allows the procedures of RFC2509 to be used for negotiating theuse of cUDP within a tunnel and to negotiate compression/decompression parameters to be used for the cUDP flow.A companion draft [18] describes a method of compressing L2TP tunnel headers from 36 bytes (including the IP/UDP/L2TP headers) to 21 bytes. L2TPHC packets include an IP header, using the L2TPHC IP protocol id. The UDP headeris omitted, and the L2TPHC header is reduced to 1 byte. The added overhead is now 21 bytes of the IP header.Enhancements to CRTP [19] are not needed for cUDP header compression. IP HDLC PPP IP Hdr L2TP PPPMux P L Len1 PPP Prot. cUDP1 Payload1 Hdr Prot. (20) HC ID F X Field1 (2) (1) ID L2TPHC Header (0x59) F T (0-2) (1) Protocol (1) (1-2) P L LenN PPP Prot. cUDPN PayloadN CRC F X FieldN (2) F T (0-2) (2) (1-2) Figure 6-8: PPPmux tunnelled over Routed Network using L2TPHC (with PPP as Layer 2)A more bandwidth efficient way to send TCRTP over a PPP link is to compress the L2TP IP header with cUDP (this isreferred to as cTCRTP). 3GPP
    • Release 5 26 3GPP TR 25.933 V5.4.0 (2003-12) HDLC cUDP cUDP L2TP PPPMux P L Len1 PPP Prot. cUDP1 Payload1 Hdr Prot. (2) HC ID F X Field1 (2) (1) ID Header (0x59) F T (0-2) (1) (1) (1-2) P L LenN PPP Prot. cUDPN PayloadN CRC F X FieldN (2) F T (0-2) (2) (1-2) Figure 6-9: cTCRTP PPPMux packet tunnelled in L2TPHC over a PPP link6.2.4 MPLS solution [Editors note: This clause refers to deleted or expired ietf-drafts] [Editors note: Detailed reference to RFCs and other standards need to be provided, and overheads need to be calculated again according to the detailed references.]6.2.4.1 MPLS General DescriptionThe Multi-Protocol Label Switching (MPLS) protocol is an interstitial, layer 2.5 protocol which complements andenhances the IP protocol, in that it offers an alternative method of forwarding IP packets, while reusing the existing IProuting protocols (e.g., OSPF, BGP).MPLS can run on top of numerous L2 technologies (PPP/Sonet, Ethernet, ATM, FR, WDM Lambdas, etc.).MPLS forwards IP packets based on a 20-bit label. An ingress router at the edge of an MPLS domain, called a LabelEdge Router, decides which subset of incoming packets is to be mapped to which Label-Switched Path (LSP), and thenadds the corresponding label to each packet as it arrives. This subset of packets that is forwarded in the same mannerover the same LSP is called a Forwarding Equivalence Class (FEC). Packets are then forwarded through the MPLSdomain by the Label Switched Routers (LSRs) based on the label. At the egress edge of the MLS domain, the egressLSR removes the MPLS label from each IP packet, and subsequently the IP packets are forwarded by conventional IPforwarding.Each pair of LSRs on the Label-Switched Path (LSP) must agree on which label to use on that segment of the LSP. Thisagreement is achieved by using a set of procedures, called a label distribution protocol. The label distribution protocolassociates a Forwarding Equivalence Class (FEC) with each LSP it creates. The FEC associated with an LSP specifieswhich packets are "mapped" to that LSP.6.2.4.2 Routing with MPLSMPLS, as a complementary forwarding technique to IP forwarding, offers the following advantages: - coexistence with IP Hop-By-Hop Routing: an LSR is capable of forwarding both IP packets and MPLS frames; - traffic engineering capabilities: MPLS uses the label prefixed to an IP packet to determine the path that the packet will take through the network, regardless of the IP addresses contained in the packet. Routes through the network can be engineered to meet various network or operator requirements (such as QoS or trafic load). For example, the traffic at the edge of the MPLS domain can be segregated according to QoS class and the packets can be directed along the MPLS paths defined over the route that meets their QoS requirements (see QoS clause hereafter); - flexibility due to label semantics: the meaning of the labels can be tailored to what needs to be achieved in the network. For example, labels can be used to specify treatment for QoS, multiplexing, multicasting, header compression, etc; 3GPP
    • Release 5 27 3GPP TR 25.933 V5.4.0 (2003-12) - flexibility due to label stacking: MPLS supports the ability to stack more than one label in front of an IP packet. LSRs are capable of pushing, popping and swapping labels. This allows for: - different addressing in different subnets; - efficient inherent support for tunnels-in-tunnels. This can be used, for example, for IP VPN and mobility support; - transparent routing: the compressed packet passes transparently through the intermediate LSRs. This is in contrast to schemes based, for example, on PPP where either header (de-)compression must occur on a hop-by- hop basis or the compressed packets must be carried inside a second, uncompressed IP tunnel packet. MPLS thereby makes network nodes much simpler; - fast rerouting: MPLS protection switching mechanisms can be applied to achieve fast restoration from a node failure. Both local and end-end protection could be used to achieve fast tunnel restoration which is an essential requirement for a carrier grade network. Backup tunnels may also be combined with load sharing to allow a more even traffic distribution; - match any layer 2: MPLS can run on top of numerous L2 technologies. When MPLS is used over ATM or Frame Relay, the LSP can be mapped onto layer 2 connections such as VCCs or PVCs.6.2.4.3 Support for QoS requirementsFinally, the MPLS supports a number of QoS differentiation mechanisms for IP flows: - QoS engineered paths: the flows with different QoS characteristics can be separated on different LSPs. LSPs can be engineered to meet the QoS requirements for each class of traffic supported by the network. The traffic at the edge of the MPLS domain can be segregated according to QoS class and the packets can be directed along the MPLS paths defined over the route that meets their QoS requirements. Taking again our example over narrow-band links, QoS efficient LSPs could pave the way for real-time flows whereas user data with long payloads could be routed over separate LSP(s). By so doing, there is no risk to have big packets blocking the way of delay-sensitive small packets. Best efficiency can be achieved by combining the use of MPLS with the appropriate layer 2 mechanisms depending the technology used at layer 2. Taking again our example with ATM over such narrow-band links, the different LSPs (i.e. VCCs) are multiplexed onto the same physical link by the ATM VCC multiplexing function respecting the VCC QoS, thus the LSP Qos. Then QoS characteristics of real- time flows (such as IP Diffserv marking) can be used to select the LSP (i.e. the ATM VCC) the packet should be sent over. This is fairly easy to achieve through the VPI/VCI – label mapping defined above; - integration with Differentiated Services (DiffServ): DiffServ provides a mechanism for defining the treatment that a packet will receive as it is forwarded through an IP network. Although there are no performance guarantees with DiffServ, it can be used to improve end-to-end performance over large scale, wide area networks. MPLS can support DiffServ by using the DiffServ marking in each packet to determine: - which path the packet should be sent over. Paths can then be engineered, as mentionned above, to provide more deterministic performance guarantees than are available with pure DiffServ in a routed network; - the treatment that packets will receive over a specific path. In this model, closely resembling the basic DiffServ model, packets with different QoS requirements can be carried over the same MPLS path. Within that path, the DiffServ marking is used to prioritize and schedule packets to provide "better" treatment for some packets with respect to other packets carried over that same path. - In-Sequence Packet Delivery: because the route that a packet will travel through the network is precisely defined by the Label Switched Path, packets are guaranteed to be received in the same order that they were transmitted.6.2.4.4 Efficient, QoS-enabled transmission over routed domains with MPLSLet us consider a general network configuration, which includes a broadband routed cloud as well as a narrowband link,typically on the last-mile link to the Node B. This configuration is shown in figure 6-10. 3GPP
    • Release 5 28 3GPP TR 25.933 V5.4.0 (2003-12) Narrow-band IP Routed Link Node B RNC Broadband Network Bandwidth optimisation “session” Figure 6-10: General UTRAN network configurationFigure 6-10 also shows the most likely location of the pair of endpoints for a bandwidth optimization "session". In thismanner, bandwidth optimization is only performed where it is really required, on the narrow-band, point-to-point link.Figure 6-11 shows the protocol stacks at the relevant nodes in the network for an MPLS-based transport solution over arouted domain. On the downlink, UDP/IP packets are mapped onto MPLS paths at the RNC, and are sent uncompressedthrough the network to a compressing/decompressing node (CDN). The UDP/IP packets are then compressed using atechnique defined in clause 6.2.4.5.1, and sent compressed over the narrow-band point-to-point link. At the Node B theUDP/IP packets are restored/uncompressed. On the uplink, UDP/IP packets are compressed and sent over the narrow-band link. At the CDN, packets are uncompressed and mapped onto an MPLS path for transport to the RNC. Becausethe MPLS label attached to the compressed packet is used to route the frame through the network, the CDN can belocated at the RNC or at any point along the path to the Node B that has sufficient processing capacity for handling theCDN functions. Narrow-band Link IP/MPLS Compress Node B RNC Network /Decomp. Node Payload Payload Payload Payload Payload Payload Frame Frame Frame Frame Frame Frame UDP UDP UDP UDP cUDP/IP cUDP/IP IP IP IP MPLS* MPLS* IP MPLS MPLS Class of Service 1 LSP *:may also be compressed depending on uuteetechniquetechnique(see2.(see2.6) Class of Service 2 LSP the compression technique used. (see2.6) Class of Service 3 LSP Figure 6-11: Protocol stacks at key nodes in the network for a MPLS-based transport solutionAn MPLS-based transport solution for the UTRAN, integrated with DiffServ (or DiffServ-like) mechanisms, includesthe following: 3GPP
    • Release 5 29 3GPP TR 25.933 V5.4.0 (2003-12) - Label-Switched Paths (LSPs) are established between an RNC and a Node B, in both directions; each LSP carries one or more class of service supported by the UTRAN. This occurs during NodeB initialization, before user traffic is allowed to flow through the NodeB. LSPs can be pre-setup via provisioning (e.g., using COPS MPLS [40]), or set up dynamically using CR-LDP [37] or RSVP-TE [38]. As part of this process of setting up the LSPs, all the intermediate transit routers are provisioned to provide the desired per-hop behaviour (i.e., scheduling treatment and in some cases, drop precedence for each DS code point). By providing consistent behaviour to packets belonging to the same class of service in each transit node which is part of an LSP, the overall quality of service in that LSP is achieved. This is consistent with the approach described in [31]. - The operator decides how many classes of service there will be supported in the UTRAN, and also how classes of service map to an LSP (i.e., one or more). - An IP packet is mapped to the LSP with appropriate class of service based on two things: the DS code point marking in the IP header of the packet, and the FEC that the packet belongs to, (i.e. the destination IP address in the IP header). This is also consistent with [31]. - IP packets are mapped to the appropriate LSPs at the UTRAN edge nodes, i.e., the RNCs and Node Bs.6.2.4.5 Efficient transmission over narrowband (point-to-point) links with MPLSCompression of UDP/IP headers is compatible with the use of MPLS in order to provide optimized efficiency onnarrow-band links. As an example, two types of techniques are currently under investigation over PPP links andavailable as internet drafts: - "simple IP header compression" [34] where the emphasis is put on the flexibility on the point where the compression and decompression nodes are located: compression can be performed between any two LSRs on the LSP including compressing over the complete LSPs. In that case the compressed frame is routed through the LSP with the MPLS label. This technique is based on differential coding compared to a static template which presents the advantage of robust synchronization between compressor and decompressor even in case of lost frames. The bandwidth efficiency calculation leads to overheads (layer 2 + layer 3) of 9 bytes per user flow. - "MPLS+IP Header compression" [39] where the compression is only performed on a point-to-point link (such as UTRAN last mile) and the emphasis is further put on MPLS header compression. In that case, the MPLS label is compressed by sharing the UDP/IP compression context. Bandwidth efficiency is further improved by using the same differential coding as introduced in [40]. This differential coding scheme transmits the changes between successive packets in order to keep the size of the compressed fields small. The resulting overhead (layer 2 + layer 3) is 7 bytes per user flow.The detailed calculations and the comparison of bandwidth efficiency on the last mile for the different alternatives isaddressed in the document [40]. The optimization between the two techniques could be left to network engineering.Header compression also implies a previous negotiation between the compressor and decompressor. As an example, thefollowing clause describes how this negotiation is performed for one of the above defined compression techniques overPPP [34]. The equivalent for the second one can be found in [41].6.2.4.5.1 MPLS Header Compression "Session Negotiation"As with other header compression techniques, a header compression session negotiation is required. Here are twoexamples of how this can be done: - using RSVP-TE messages to negotiate the header compression [34], or - using the Label Distribution Protocol (LDP) to negotiate the header compression.A fundamental concept in MPLS is that two LSRs must agree on the meaning of the labels used to forward trafficbetween and through them. This common understanding is achieved by using a set of procedures, called a labeldistribution protocol, by which one LSR informs another of label bindings it has made.The Label Distribution Protocol, LDP [8] describes one of the label distribution protocols, by which LSRs distributelabels to support MPLS forwarding along normally routed paths. An extended version of RSVP [38] can also be used todefine and distribute labels. 3GPP
    • Release 5 30 3GPP TR 25.933 V5.4.0 (2003-12)6.2.4.5.1.1 Using RSVP-TE to negotiate "MPLS Simple Header Compression"The internet draft "Simple Header Compression" [34] describes a way of negotiating a MPLS Header Compressionsession using RSVP-TE signalling. The compressor endpoint sends an RSVP PATH message to request an MPLSheader compression session. The decompressor replies with an RSVP RESV message confirming that it will performthe decompression.The compressor includes a SIMPLE_HEADER_COMPRESSION (SHC) RSVP object in the PATH message tocommunicate the header template and the set of operands. To allow multiplexing across an LSP the SHC objects alsocarry a one byte sub-context ID (SCID).The decompressor includes a SIMPLE_HEADER_COMPRESSION_REPLY RSVP object in the RESV message toindicate which SCIDs it is agreeing to decompress.The template in the SHC object consists of the first n bytes of a packet. All of the fixed fields are set to their appropriatevalues. The variable fields are set to zero. Fields are always delimited on byte boundaries. Each operand is simply anoffset and a length. They serve to delimit the variable fields within the template.Instructions on what to do with the variable fields (e.g., IP TTL, IP checksum, and IP length) is also signalled in theSHC object, using the T, C, and L flags, respectively.The compressor removes the header from the packet. The term header is used loosely here. It refers to the first n bytesof the packet where n is the length of the header template. The compressor uses the operands to extract the variablefields from the header. These are concatenated together as a compressed header. The SCID is then prepended to thecompressed header and the packet is sent.The decompressor uses the incoming MPLS label and the SCID to locate the proper decompression context. Thedecompressor then uses the header template to reconstruct the original header. It uses the operands to populate thevariable fields of the header with the contents of the compressed header.Over the life of an RSVP session SCIDs may be added and deleted simply by refreshing the Path state with the updatedset of SHC objects The SHCR object provides synchronization between the sender and receiver as to which SCIDs maybe used.6.2.4.5.1.2 Using LDP signalling for "MPLS Simple Header Compression" session negotiationMPLS Header Compression session negotiation can be accomplished with the LDP protocol, by adding a new TLV(Type-Length-Value) that includes the header template, flags and set of operands as described in clause 6.2.4.5.1.1.The compressor requests a label for a new IP flow (i.e., 5-tuple combination source IP address, source port, destinationIP address, destination port, protocol id} via the downstream on-demand method from the decompressor, which is itsLDP peer in this case. The decompressor provides the MPLS label it wants to use for this FEC back to the compressor.The decompressor also stores the mapping of MPLS label to header template+flags+operands in a local table. Thecompressor also specifies how the IP TTL, IP checksum, and IP length fields are to be regenerated on the other end inthe FEC TLV.The compressor LSR can then compress the IP packets as per clause 6.2.4.5.1.1. When the decompressor LSR receivesthe MPLS frame, it looks up the MPLS label in the mapping table, and uses this information to restore the UDP/IPheader.6.2.4.5.2 Handling of large packets over narrowband linksIn general, sending a large packet over a narrowband link will cause delays to subsequent real time packet(s) that wouldimpact the QoS of the real time packet(s). Fragmenting large packets into smaller sub-packets, and then scheduling allthe packets to be sent over a link (including the sub-packets) according to their QoS requirements generally solves thisproblem.When MPLS is used in a UTRAN transport solution, the fragmentation can be localized over the narrowband link byrelegating it to the underlying layer 2: - ATM can provide this with AAL-5; - Multi_Link PPP can provide this [20]; 3GPP
    • Release 5 31 3GPP TR 25.933 V5.4.0 (2003-12) - Multi-class extension of Multi-Link PPP can provide this [21];- HDLC can provide this with PPP in a Real-time Oriented HDLC-like Framing [35]; - Frame Relay can also provide this [33].6.2.5 AAL2 based solutionIf it is determined by RAN3 that a protocol should be used for multiplexing and/or fragmentation between the IP layerand the RNL, the AAL2 (SSSAR and CPS) user plane protocol should be used over UDP.AAL2/UDP should be used for multiplexing and fragmentation between the IP layer and the RNL for the followingreasons: 1) Using AAL2 makes interoperability between IP and AAL2/ATM nodes easier. 2) Fragmentation and multiplexing standards already exist. 3) Fewer protocols need to be supported in a UTRAN node. 4) AAL2/UDP will be terminated in the UTRAN end node.Some changes could be made to the existing AAL2 protocol: 1) It is not necessary to limit the UDP packet size to 48 bytes as it is for ATM. 2) There is no reason to split an AAL2 SDU between two UDP packets as is done with ATM. As a result there should be no reason for the AAL2 Start field.6.2.6 Usage of UDP Lite for IP UTRAN [Editors note: This clause refers to deleted or expired ietf-drafts]6.2.6.1 BackgroundThere are a number of link technologies where data can be partially damaged. Microwave transport is one commonexample. For some applications, such as voice, better performance can be achieved if errored data is not discarded but isinstead delivered to the application.The current ATM UTRAN allows bit errors in the payload to be passed to the application. This is because: - ATM only protects the ATM header with a Header Error Control (HEC) field. - AAL2 only protects the AAL2 header with an HEC field. - AAL2 also provides support for error detection for the payload in I.366.1. This is not used in the UTRAN, however. - The UTRAN framing protocols include a checksum for the headers and an optional checksum for the payload.In Ipv4, the UDP checksum either covers the entire datagram or is not used at all. In Ipv6, the UDP checksum ismandatory and can not be disabled. The Ipv6 header does not have a header checksum so the UDP checksum was mademandatory in order to protect the IP addressing information. This means with classic UDP the entire packet must becovered for Ipv6.It would be beneficial if the error detection mechanism of the transport layer could protect vital information such asheaders and to optionally ignore errors best handled by the application.However, as it is recognized that the probability for a well-designed link to add errors is very low (<10-6) for most of thetime, it is not envisaged a real need for the use of the UDP-lite in IP UTRAN.6.2.6.2 UDP LiteUDP Lite is an IETF Working Group draft. It provides a partial checksum that improves the flexibility over classicUDP by making it possible to define the part of a packet to be protected by the checksum. 3GPP
    • Release 5 32 3GPP TR 25.933 V5.4.0 (2003-12)The UDP Lite header is shown in the figure below. 0 15 16 31 Source Destination Port Port Checksum Checksum Coverage Data bytes …Its format differs from classic UDP in that the UDP "Length" field has been replaced with a "Checksum Coverage"field. Information about the UDP Lite packet length can be found in the length field of the IP header so the packetlength information in UDP is not required.The fields ``Source Pt and ``Destination pt are the same as classic UDP (RFC-768) [42]."Checksum Coverage" is the number of bytes that are covered by the checksum beginning with the first byte of theUDP Lite header. A "Checksum Coverage" of zero indicates that the entire UDP Lite packet is included in thechecksum."Checksum" is a checksum over a pseudo-header of information from the IP header and the number of bytes specifiedby the "Checksum Coverage". The same pseudo-header from the IP layer used in classic UDP for inclusion in thechecksum calculation is also used for UDP Lite.UDP Lite has its own protocol number that is different than the classic UDP protocol.6.3 QoSThis study area is related to the QoS mechanisms that may be in the upper layers. For example, an IP stack may use theIETF diffserv mechanisms to effect QoS. However, Diffserv provides the tools but does not define the policies of theQOS architecture. For example, QoS must be provided for individual user services, and packets must be markedaccordingly.At IP layer, Diffserv, RSVP or over-provisioning may be used.In the UTRAN there are three planes involved, the User plane, the Control plane and the Management plane. Thoughthe characteristics of the users in these planes differ (PDU size, QoS requirements, etc.), they are all sharing the sametransmission and potentially interfering each other. Additionally non-UTRAN traffic will also share the transmissionnetwork. That non-UTRAN traffic can not be excluded from the IP transport network, as it could be one reason why aoperator chooses IP as transport technology.When evaluating any mechanism, one should consider its applicability for all three planes and the non-UTRAN traffic.This approach enables a unified basis for the QoS and for the efficient utilization of transport resources.In an IP network, the deployment of QoS features is not sufficient to ensure guarantee of service. The network shall becorrectly dimensioned, so that the expected service can be provided. The provisioning of resource must be done withsome over-dimensioning factor depending on the maximum packet size. The bigger the real-time packets, the moreresource will be necessary. NOTE: That reason is basically the same that justifies small cell size in ATM, to provide QoS.6.3.1 Fragmentation6.3.1.1 GeneralFragmentation is required to adjust packets to the Maximum Transmission Unit (MTU) size of the path, and, for slowlinks, to prevent short, time sensitive packets from being delayed by large packets in front of them on a link. Forexample, with a rate of 384 kbps and a TTI of 80 ms a data payload size of 3 840 bytes will result. The RLC mightsegment this data but all the segments (transport blocks) are multiplexed into the same packet (transport block set). 3GPP
    • Release 5 33 3GPP TR 25.933 V5.4.0 (2003-12)Fragmentation must be performed also on the non-UTRAN traffic, if any, or the network must be oversized. The typicalpacket size density derivation of www traffic has its peaks at 64 Byte and 1500 Byte. A 1 500 Byte packet introduces ona E1 link the jitter of 6,25ms.6.3.1.2 IP fragmentationIP fragmentation is the capability of the IP protocol to fragment a packet into multiple segments based on the MaximumTransmission Unit (MTU) size of the path the packet will traverse. The MTU of the path can be "discovered" usingMTU path discovery which involves sending an ICMP message over the path and receiving the smallest MTUdiscovered along the path. If the packet is larger than the path MTU, it will be fragmented. The MTU is set in a routerbased on the link characteristics.For PPP, the MTU size is flexible. For Ethernet links the maximum and default MTU is 1 500 bytes. For GigabitEthernet a 9 000 byte frame size possible (Jumbo Frames).Disadvantages of IPv4 fragmentation are: 1) Bandwidth efficiency with larger packets is not realized in the part of the path with larger bandwidths since once a packet is fragmented it can only be reassembled at the endpoint. 2) For IPv4, IP header compression cannot be used. This is not the case for IPv6. 3) For IPv4, the overhead is large when IP fragmentation is used. Also, fragmentation can be performed at any link along the path. This can result in heavy processing demands on the routers in the network. IPv6 fragmentation is only allowed end to end.End-to-end fragmentation, whether using IP fragmentation or fragmentation above the IP layer ("application level"fragmentation), can be used to adjust the packet size to the path MTU but is not suitable to solve issues around a slowlink. This is because IPv6 allows the MTU to be set to a minimum of 1 280 octets which is not small enough for slowlink issues.Since the disadvantages of IP fragmentation are not relevant when performed end-to-end, IP fragmentation would besupported in the UTRAN nodes to adjust the packets to the paths MTU. It should only be done end-to-end for bothIPv4 and IPv6. Also, the network should be designed such that MTU sizes are not so small that the IP headers consumetoo much bandwidth. This is the same approach taken for the GTP protocol and assumes that the operator has somecontrol over the network.IP fragmentation would not be used to facilitate delay-sensitive traffic on slow links. Layer 2 mechanisms would beused for this as indicated in the IPv6 RFC [27]:"IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a1 280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6".6.3.1.3 Fragmentation to facilitate delay sensitive trafficIn order to facilitate delay sensitive real time traffic, large packets can be segmented and the segments can be mixedwith the higher priority traffic. This is only relevant for slow speed links where any delays can effect the performance ofthe applications.IP fragmentation does not automatically address this problem since IP fragmentation only fragments based on the sizeof packet that a link can handle. This packet size may not be small enough to allow the efficient use of the link whendelay sensitive traffic is present. It could be possible for IPv4 networks to set the MTU of the link to a smaller size thannecessary to facilitate delay sensitive traffic. However, this can effect the efficiency of the higher speed links along thepath. IP fragmentation is always end to end for IPv6.6.3.1.4 Application level fragmentationApplication fragmentation can help with avoiding IP fragmentation but does not automatically solve the problem forefficiency over slow links. MTU discovery can be used to determine the size of packet required to avoid IPfragmentation but it does not provide the necessary information required to know what packet sizes should be used forefficiency over slow links. It is possible that this size could be configured based on knowledge of the slow links but thisaffects the processing and routing efficiency efficiency over higher speed parts of the transport network 3GPP
    • Release 5 34 3GPP TR 25.933 V5.4.0 (2003-12)6.3.1.5 Layer 2 fragmentation solutionIn general, it is best to take care of slow link problems only over the slow link and not over the entire path. Onealternative is to handle segmentation as a lower layer issue. As an example, for PPP, the fragmentation capabilities inmultilink PPP [20] can be used for this purpose. With multiclass extensions, multiple flows can be identified within aPPP stream. The IPv6 specification says that for links that cannot convey a 1 280 octet packet in one piece, link-specificfragmentation and reassembly must be provided at a layer below IPv6.Layer 2 fragmentation provides flexibility because it does not need to be end-to-end. It can be multi-hop using tunnelingin which case it is more flexible than application level and IP fragmentation.6.3.2 Sequence informationIf fragmentation is provided between IP and RNL, then a sequence number is required in order to reassemble thefragments.Many of the Radio Network frame protocol specifications say that the transport layer must deliver frames in order.However, it is part of the IP UTRAN investigation to determine if this is actually a valid requirement.If it is shown that a sequence number is required then this functionality could be provided between the frame protocolsand the IP transport layer (i.e. UDP).6.3.3 Error detectionAAL2/ATM has the following error detection capabilities: 1) ATM provides no error detection capability for the payload, but only for the ATM header. 2) AAL2 provides error protection for the header using the HEC.IP has the following error detection capabilities: 1) The link layer can protect the payload. Examples are the HDLC and the AAL5 checksums. 2) UDP has an optional checksum for IPv4 that is mandatory in IPv6.Therefore, for AAL2/ATM no error checking is performed on the payload. For IP, error detection capabilities areprovided at the link and transport layer. Whether additional error checking is required above the UDP layer is FFS.6.3.4 Flow Classification in IP NetworksOnce these QoS classes have be defined and the respective priorities or requirements set, it shall be possible forUTRAN traffic to be recognized as pertaining to each of the individual classes, so that transport nodes can deliverappropriate QoS. Therefore nodes implementing Transport function are not only responsible for differentiating serviceamong a set of IP packets but also to classify those IP packets to be able to deliver the respective QoS. NOTE: Differentiation has a larger meaning than DiffServ acceptation. Even in IntServ model, IP packets are differentiated according to flow filtering, i.e. they receive different services according to established reservations.Classification can basically be realized according to specific layer information, such as header field values or contextinformation. One can distinguish between Radio Network Layer and Transport Network Layer based classification.6.3.4.1 Classification based on RNL informationFor instance, SRNC knows about relative and absolute QoS requirements for RABs and can base its transportdifferentiation on RNL information based classification. It is an implementation issue only how this can be done, but itis very easy to realize thanks to additional information in layer to layer primitives.In DRNC and Node B, such a classification can be envisaged if relevant RNL information is available. However QoSrequirements as extensive as RAB parameters may not be available in those nodes. 3GPP
    • Release 5 35 3GPP TR 25.933 V5.4.0 (2003-12)RNL information is assumed to be unreachable in intermediate transport nodes that are UTRAN agnostic. In thosenodes, classification can only be done with standard or classical IP methods.6.3.4.2 Classification based on TNL informationVarious QoS models and solutions exist for IP networks, with specific advantages and best uses. However they havecommon features that they all need to realize, like flow classification. Instead of listing all QoS solutions, thisclauseclause limits to information commonly used to classify IP flows to provide QoS: - IP ToS (Type of Service) field can be used to classify among some traffic classes. This field is used in core Diffserv routers to deliver Per Hop Behaviour (so called Behaviour Aggregate Classifier). - L3/L4 fields: IP header and Transport Protocol (UDP, TCP, and SCTP…) contain additional fields that can be used to classify among IP packets. Most commonly used fields are IP addresses, Transport Protocol ports and Protocol Identifier of IP header. Those classifiers are called Multi-Field Classifiers. - MPLS label can also be used to distinguish among separate FEC (Forwarding Equivalence Class), even if they share a common destination. - MPLS EXP (Experimental) bits are also proposed to be used to provide flow classification on a granularity similar and compatible with Diffserv model.Input interface can also be used when classifying packets.6.3.5 Classification ConfigurationClassifications presented in 6.3.4.2 are relevant in the Transport Network Layer only. Nevertheless, they shall bedefined according to UTRAN QoS requirements and to RAB classes, since those requirements are known by RNL.Such a mapping can be done: - at Transport bearer selection, when deciding transport bearer end point addressing that can later be used to classify the flows (e.g. IP, UDP addresses directly or mapped on MPLS label); - at UTRAN flow source (Node B, RNC) on a packet per packet basis, by assigning the relevant TOS field, EXP field or by encapsulating in the relevant MPLS label.Both methods offer different characteristics that are detailed hereafter.6.3.5.1 Transport bearer based classificationTransport Bearer based classification can be very fine but impose intermediate node to be aware of part of or all endpoint addressing. This is needed to create filters based on this information in intermediate nodes.This knowledge of transport bearer addressing by intermediate transport nodes can be: - signalled for each individual transport bearer, but it would need non-scalable and complex signalling like RSVP; - pre-configured with semi static classification filters based on partial transport bearer addressing information, e.g. source UDP port, destination IP address etc. With such an alternative, intermediate transport nodes need not to be signalled at transport bearer establishment of particular filtering for the new bearer. Intermediate nodes can either be configured by O&M or by aggregate RSVP reservations.Moreover, if the classification is based on destination information only, the source node may be unaware ofclassification. It does implicit classification ruled by destination node at transport bearer termination selection.6.3.5.2 Packet per packet classificationIf QoS is marked in source node by relevant tagging in IP or MPLS headers, filtering in intermediate node is simpler.The classification in intermediate transport nodes does not depend on end node transport addresses and therefore issimpler to configure and manage. 3GPP
    • Release 5 36 3GPP TR 25.933 V5.4.0 (2003-12)On the other hand, the granularity may be coarser if only ToS or EXP bits are available to distinguish between trafficclasses.6.3.6 UTRAN Hop-by-Hop QoS ApproachThis approach relies on the QoS differentiation, which is provided by the IP backbone. This means the UTRAN internalflows (e.g. RAB traffic, NBAP signalling, …) have to be mapped to the IP network. This mapping is not obviousbecause of the specific properties of UTRAN traffic. Due to the fact that the RLC/MAC layer are on RNC side, even thebest effort RAB QoS class becomes time constraint traffic in UTRAN, but with more relaxed delay requirements thanthe conversational RAB QoS class. The delay requirements themselves are dependent from the MAC strategy in theRNC, which is manufacturer dependent.QoS differentiation in the IP backbone could be provided by Diffserv for example. Scheduler algorithms and strategiesfrom the installed routers are used and must be configured to meet the UTRAN requirements.The last mile between the edge router and a NodeB is assumed to be a bottleneck for all UTRAN traffic flows. Theadaptation to the low speed link has to be done by L2 techniques. Advanced functions like QoS differentiation,segmentation and multiplexing are needed in L2. For example, the PPP protocol is a meaningful candidate for thisadaptation. It provides with its extensions Multi-Class PPP and PPPmux the required QoS differentiation, segmentationand multiplexing functionality.However, still some issues need to be solved: - a mechanism shall be defined to inform the edge router about the needed quality classes towards the NodeB and the parameters used for the differentiation; - it shall be defined on which edge router functionality the standard design relies on, and what can remain implementation dependent; - the interworking of PPPmux with MC-PPP should be defined, for instance the availability of a separate PPPmux instance per QoS class shall be clarified.6.3.7 UTRAN End-to-End QoS ApproachThe end-to-end approach provides QoS differentiation for the UTRAN traffic flows inside the UTRAn NEs. User planeprotocol proposals like CIP and LIPE rely on this principle. But also the PPPmux based proposal can provide an e2eapproach by tunnelling the PPP protocol via L2TP (TCRTP). The queuing and scheduling is performed inside the NEsunder control of the UTRAN equipment manufacturer. In the IP backbone only one QoS class is needed for UTRANtraffic, which could be the expedited forwarding (EF) class of Diffserv.The QoS differentiation is simpler because the quality classes are well known inside the NEs and the complexmanagement function to distribute the QoS parameter in the IP network can be avoided.However, for the implementation dependent O&M traffic the head of line blocking problem still exists. In case the edgerouter provides on data link layer only one QoS class, IP fragmentation at the O&M center could be configured to areasonable IP packet size. If the edge router provides at least two QoS classes (ML-PPP) the best effort O&M trafficcould easily be distinguished from the tunnel carrying the other UTRAN traffic.6.4 Transport network bandwidth utilizationThis study area is related to bandwidth efficiency by e.g. multiplexing/header compression, resource management, andthe use of segmentation. Lower speed links, such as E1, or shared higher speed links may require different techniques(e.g. header compression and multiplexing) than dedicated higher speed links.When evaluating and comparing efficiency of different candidate schemes for efficient bandwidth utilization, theirimpacts on the other study areas of this chapter have to be identified and considered. 3GPP
    • Release 5 37 3GPP TR 25.933 V5.4.0 (2003-12)6.4.1 General issues6.4.1.1 MultiplexingMultiplexing provides a means for reducing the impact of the size of the UDP/IP headers in a packet. It is important forgaining better bandwidth efficiency with small packets. Multiplexing can be performed at the application layer or alower layer. An example of application level multiplexing would be if the length field in the GTP header would be usedto delimit GTP tunnels multiplexed within one UDP/IP packet. This is not currently supported in GTP. Applicationlevel multiplexing reduces the impact of the IP and UDP headers. However, when header compression is applied, theoverhead is already significantly reduced.Multiplexing within a PPP frame is being addressed currently in the IETF [10]. Advantages of PPP multiplexing are: 1) Layer 2 multiplexing provides the possibility for routing multiplexed packets using tunneling as does application level multiplexing. 2) Layer 2 multiplexing is not end-to-end so how multiplexing is applied at the source does not need to be based on the worst case link in the path. 3) Packets with different IP addresses can be multiplexed in same PPPmux frame. With application level multiplexing, only packets going to same IP address can be multiplexed.6.4.1.1.1 Location of multiplexing in transport networkThree architectures are proposed for multiplexing distribution in transport network, as depicted in figure 6-12. They arepresented and discussed hereafter.6.4.1.1.1.1 Scenario 1:Multiplexing is done end-to-end, i.e. transparently to intermediate transport nodes. This solution has the benefit ofsimplicity regarding intermediate transport nodes that may be multiplexing agnostic.Some limitations can be noted for this scenario: - All information multiplexed in one packet shall follow the same path and shall be serviced with the same QoS, since intermediate transport nodes are multiplexing agnostic. However it is still possible to handle differentiation in end nodes and to take benefits of several QoS in the transport network: there is only the restriction that all information in one packet cannot be serviced differently, once they have been multiplexed. As far as the routing/path is concerned and considering current RNL architecture, Node B has only one Iub interface towards one C-RNC and therefore it is not a requirement to allow multiplexing of information having different destinations. - Both aspects of multiplexing as introduced above in 0 cannot be distinguished. Therefore they cannot be optimized separately. Nevertheless, since low speed link multiplexing is the most important aspect, it can be the basis for optimization.As a conclusion, scenario 1 has some limitations but it can provide simple transport network solutions, since it needsonly basic functionality in transport network intermediate nodes. 3GPP
    • Release 5 38 3GPP TR 25.933 V5.4.0 (2003-12) Node B Edge RNC Router End-to-end multiplexing, transparent to intermediate transport nodes Scenario 1 Node B Edge RNC Router Last Mile multiplexing, terminated in Edge router Scenario 2 Node B Edge RNC Router Last Mile multiplexing, Routed network multiplexing, terminated in Edge router transparent to high speed routers Scenario 3 Figure 6-12: Scenarios for multiplexing location6.4.1.1.1.2 Scenario 2:Multiplexing is on last mile low speed links only, where bandwidth is a limiting factor and where high-speed interfaceresource optimization is not required. It provides functionality on the exact network portions that require efficiency.Hereafter are the characteristics of this solution: - This scenario induces some functionality in edge router to terminate the multiplexing. - Downlink packets arrive in the edge router and shall be multiplexed and differentiated according to some knowledge of QoS. Therefore the edge router shall participate in QoS differentiation and end-to-end differentiation is not sufficient. - Packets multiplexed together on the uplink/downlink can be forwarded to/from different paths with different QoS after the edge router. This brings flexibility, with some complexity in the transport network.Therefore scenario 2 is more flexible and optimal, with more complex QoS handling in transport network and higherprocessing power per packet in the edge router. It does not cover the multiplexing on high-speed interfaces for reductionof number of packets per second.6.4.1.1.1.3 Scenario 3:Scenario 3 can be considered as an extension of scenario 2 for high speed link multiplexing. 3GPP
    • Release 5 39 3GPP TR 25.933 V5.4.0 (2003-12)There are indeed two multiplexing "sessions", one between Node B and edge router and another between edge routerand RNC. The first one is very similar to the one described in scenario 2. The second one is presumably routed with lessstringent bandwidth requirement.It can be expected that sufficient concentration exist between edge router and RNC to allow several sessions towardsseveral RNC. Therefore the edge router is really doing routing of individual information payloads of both types ofmultiplexing sessions: it de-multiplexes on one side what it receives and re-multiplexes on the output interface.6.4.1.2 Resource ManagementThe solution for resource management should be scalable in complexity. It should also allow traffic other than UMTStraffic without seriously degrade the quality of service of the UMTS traffic. Some operators will require IP connectivityfor other applications using the same network as the UTRAN. The use of VPNs can be investigated in order to facilitatethe sharing of network resources. Resource management setup time should be minimized such that it meets therequirements but does not add too much delay for the application connection setup.For the low-speed links, delay needs to be well controlled for soft handover and other time critical operations. Also,since these interfaces are part of the network where resources are more expensive, its particularly important to utilizethe bandwidth in an efficient way. In addition, where node synchronization messages are used, they must have smalldelay in order to be effective. For these reasons the use of on-demand resource allocation should be given particularconsideration.Static routing or dynamic routing using a routing protocol could be used. Static routing allows easier control over delaysbut puts heavier requirements on configuring the network. Dynamic routing protocols add complexity but increase thepossibilities for automatic configuration.The following possible functions relating to resource management should be considered: - Admission control: Enforces a limited load within a traffic class in order to limit the delay caused by buffering in network routers. - Policing: Once traffic has been admitted in a network based on certain traffic characteristics, it may be policed to ensure that it does not violate the conditions of its admission. - Reservation of resources: How should resources be reserved in the transport network?Allocation of resources can be static or dynamic. It can also be performed by one or a combination of several methods,for example: - Over-provisioning: This method is static and there is no need for admission control. However, it does not take advantage of transport bandwidth efficiency gains that IP can provide. - Allocation of aggregates of flows (a trunk). This can be dynamic but changes of bandwidth allocation are made more slowly than per flow allocation. - Allocation per flow: Allocation of resources is made on a per call basis. - The admission control function can be centralized or distributed: - With server based admission control, resource requests are made to a server. A centralized or partly distributed server architecture can be used. - Distributed admission control uses signalling (e.g. RSVP). The admission control function is distributed in the routers and is performed hop-by-hop. RSVP could have scalability problems for large networks if it is used per flow.6.4.1.3 Header Compression Techniques6.4.1.3.1 Technical evaluationIn this technical evaluation, only UDP/IP flows are considered. 3GPP
    • Release 5 40 3GPP TR 25.933 V5.4.0 (2003-12)6.4.1.3.1.1 Use of Differential CodingThe standard compression techniques can be partitioned in two classes of techniques whether the differential coding isused or not: - The first one does not use differential coding: each compressed packet sent contains the randomly changing fields of the header in the compressed header so that the compression context is only updated by full header packets (a.k.a. templates). Here the decompressor gets out of sync only when a full header packet changing the context is lost. It does not get out of sync when simple compressed packets are lost or full header packets not changing the context. Moreover, it features quick recovery from out of sync. The full header packet is sent initially and can be resent periodically. Some parameters can be tuned to upper bound the period of disconnection.RFC 2507 [51] uses this class of techniques for compressing UDP/IP packets. This is named compressed_non_tcp. - The second one uses differential coding: each compressed packet does not send the fields that have constant first order differences. Thus each compressed packet is used to update the context information at the decompressor. Therefore, each lost compressed packet causes the compression context to become out of sync, so the decompressor must request a full header packet from the compressor in order to re-sync. This class of techniques is designed to work over a point-to-point link: the issue being that, if the compressor and decompressor are more than a link apart, the compressed packets must be tunnelled, and then the delay in re- syncing the two increases.RFC 2508 13] uses this class of techniques for UDP/IP flows. This is named compressed_udp.6.4.1.3.1.2 ComparisonRFC 2508 [13] differentiates from RFC 2507 [51] by being optimized when RTP is used on top of UDP/IP. It providesspecificities for RTP support and most of all the RTP header strongly benefit from differential coding since it has manyfields which are constant at the first order.When simply used over UDP/IP without RTP on top as for IP-based UTRAN transport, the differential coding producesmarginal bandwith gain on UDP/IP header. To that respect it can be said equivalent to RFC 2507 [51].To the opposite, RFC 2507 [51] is much more robust against the loss of packets. Because it does not use second orderdifferences, the loss of one compressed packet does not get the decompressor out of synchronization. This means thatsome real time packets will not be dropped waiting for a resync to be performed, to the detriment of voice quality.6.4.1.3.2 UTRAN EvaluationUMTS decided to support RFC 2507 [51] for PDCP (3GPP TS 25.323). TS 25.323 specifies RFC 2507 [51] as theprotocol being operated according to clause 3 of the IETF specification RFC 2507[51] and to use the mechanismsrelated to error recovery and packet reordering as described in clauses 10 and 11 of RFC 2507 [51].The clauseclause 5.1.2.2 clearly includes the compressed_non_TCP as part of the Protocol IDentifiers.So, for the benefice of reusability, since it is the one selected for PDCP, RFC 2507 [51] should be preferred.6.4.1.3.3 Use of NegotiationThe IPHC over PPP as defined in [14] describes an option for negotiating the use of IPHC on IP packets in PPP links.The Header Compression itself is based on the IPHC but [14] allows the negotiation of its use over PPP controlprotocol. To ensure multivendor operability of the interface, the use of negotiations is encouraged.6.4.2 Solution Comparison dataPreliminary simulation results for MPLS, LIPE and PPPMux indicate that in general, comparison of capacityperformance of the different multiplexing protocols alone is inconclusive. Other criteria must be used in order to selectone protocol over another. 3GPP
    • Release 5 41 3GPP TR 25.933 V5.4.0 (2003-12)6.5 User plane transport signallingThe use of IP based protocols for the user plane mandates compatible signalling in the control plane. The signallingmust accommodate the appropriate mechanisms to specify, establish, and manage IP streams as opposed to virtualcircuits/connections. Signalling for IP bearer exchanges transport bearer identifiers, (e.g. IP addresses and UDP portnumbers) for each end of the bearer stream. If there is a need for user plane connections, it should be investigated howconnections between UMTS nodes should be handled. It should be investigated whether an ALCAP protocol isrequired.6.5.1 Solution without ALCAP6.5.1.1 PrincipleUnlike Iu-cs, Iu-ps does not require an TNL signalling protocol to establish/maintain/release user plane TransportBearers.The transport bearer termination points, at CN and UTRAN sides, are identified by Information Elements carried byRANAP messages [3]: - Transport Layer Address IE: This information element is an IP address to be used for the user plane transport. It generally corresponds to the IP address of the board that processes GTP-u for the RAB to be established. - Iu Transport Association IE: This information element is the GTP Tunnel Endpoint Identifier.These fields are coded as bit strings or octet strings. They are transparent to RANAP i.e. to Radio Network Layer(RNL), and are only seen by the Transport Network Layer (TNL).The reason for not using ALCAP in the PS domain is linked to the connectionless aspect of IP layer.ALCAP protocol is needed for the case there is a TNL switch between two RNL nodes, since RNL protocol (RANAPon Iu, RNSAP on Iur, NBAP on Iub) does not terminate in the TNL switch (e.g. AAL2 switch). This is shown in figure6-13.In the case of IP networks, destination IP address is sufficient to route an IP packet to the TNL termination point. RN L RN L p ro to co l RN L te rm ination te rm ination TN L TN L p ro to co l TN L TN L p ro to co l TN L te rm ination (ALC AP) switch ing (ALC AP) te rm ination Figure 6-13: RNL and TNL terminationsWhen IP is used as transport in the UTRAN, it is therefore possible to avoid the use of a TNL protocol (i.e. ALCAP) onIur and Iub while keeping the independence between RNL and TNL. Avoiding the use of a TNL protocol results inbenefits with regards to e.g. connection set-up delays.Similarly to Iu-ps, it is proposed to exchange Transport Bearer termination point identifiers via the RNL signallingprotocols over Iur and Iub (i.e. via RNSAP and NBAP).Transport Bearer termination points can always be defined by: - The IP address of the termination point - The transport bearer identifier within this IP address - Transport Bearer Characteristics.The first two items correspond respectively to Transport Layer Address IE, Iu(x) Transport Association IE used inRANAP messages. The last item is added to carry information which is specific to the Transport Bearer and which isnot interpreted by the Radio Network layer. 3GPP
    • Release 5 42 3GPP TR 25.933 V5.4.0 (2003-12)The contents of those fields should be coded as bit strings or octet strings in order to comply with the RNL/TNLindependence: these fields are transferred to the TNL without being interpreted by the RNL.A simple solution consists of introducing two IEs in appropriate RNSAP and NBAP messages to identify the user planetransport bearer termination points: - Transport Layer Address IE: This information element is an IP address to be used for the user plane transport. - Iur/Iub Transport Association IE: This information element is the identifier of the Transport Bearer at the IP address termination point. - Transport Bearer Characteristics IE: This information element contains information specific to the Transport Bearer.These IEs shall be transferred transparently by the RNL to the TNL.Related RNSAP messages are e.g. RL Setup Request, RL Setup Response, RL Addition Setup, RL Addition Response.Related NBAP messages are e.g. RL Setup Request, RL Setup Response, RL Addition Setup, RL Addition Response,Common Transport Channel Setup Request, Common Transport Channel Setup Response. NOTE: Special attention shall be given to the fact that any unnecessary parameter dependence on the TNL type shall be avoided.6.5.1.2 Solution without using additional RNL Parameters6.5.1.2.1 On Iub - IurThe following table summarizes the possible exchanges of parameters over the Iur and indicates when an ALCAPwould be initiated.The simple behaviour is as follows:The very simple assumption is that a SRNC always indicates its IP capabilities if any.The very simple behaviour is that a DRNC returns IP addressing if both DRNC & SRNC have IP capabilities, ATMaddresses otherwise.It is also based on the assumption that whenever there are the two possibilities: direct connection or via a TNLinterworking, the straight connectivity is preferred. 3GPP
    • Release 5 43 3GPP TR 25.933 V5.4.0 (2003-12) SRNC- SRNC -> DRNC DRNC ->SRNC Comment DRNC1 ATM-ATM X E.164 TLA SRNC initiates ATM-ALCAP Binding Id IWF not required.2 ATM-IP X E.164 TLA DRNC returns its ATM addresses since SRNC is Binding Id ATM SRNC initiates ATM-ALCAP3 IP-ATM IP address E.164 TLA The IP SRNC receives an ATM address back UDP port Binding Id It initiates IP-ALCAP4 IP – IP IP address IP address No ALCAP required. UDP port UDP port5 ATM – X E.164 TLA SRNC initiates ATM-ALCAP ATM&IP Binding Id IWF not required.6 IP – IP address IP address No ALCAP required. ATM&IP UDP port UDP port7 IP&ATM IP address E.164 TLA The DRNC returns its address. ATM UDP port Binding Id SRNC has dual capabilities and knows IWF is not required using ATM. The SRNC initiates ATM-ALCAP (though IP- ALCAP could be used). IWF not required.8 IP&ATM-IP IP address IP address No ALCAP required. UDP port UDP port9 IP&ATM – IP address IP address No ALCAP required. IP&ATM UDP port UDP portThe behaviour for Iub is essentially the same as for Iur, with the Node B taking the DRNCs role.6.5.1.2.2 Inter-working on IuIt is assumed that the CN node knows about the SRNC transport capabilities as part of the configuration packagealready provided (SS7 addresses, etc.).The simple behaviour is as follows:If both CN and SRNC have IP capabilities, the CN sends IP address& UDP port.Otherwise, the CN sends E164 address in the Transport Network Layer Address IE and Binding ID in the TransportLayer Association IE.In the response direction, only IP information needs to be conveyed.The complete range of scenarios are described in the table below. 3GPP
    • Release 5 44 3GPP TR 25.933 V5.4.0 (2003-12) MSC-RNC MSC -> RNC MSC ->RNC Comment1 ATM-ATM E.164 TLA RNC initiates ATM-ALCAP - Binding Id IWF not required.2 ATM-IP E.164 TLA RNC initiates IP-ALCAP - Binding Id3 IP-ATM E.164 TLA RNC initiates ATM-ALCAP Binding Id4 IP – IP IP address IP address No ALCAP required. UDP port UDP port5 ATM – E.164 TLA RNC initiates ATM-ALCAP ATM&IP - Binding Id IWF not required6 IP – IP address IP address No ALCAP required. ATM&IP UDP port UDP port7 IP&ATM – E.164 TLA IWF not required. ATM Binding Id RNC initiates ATM-ALCAP.8 IP&ATM-IP IP address IP address No ALCAP required. UDP port UDP port9 IP&ATM – IP address IP address No ALCAP required. IP&ATM UDP port UDP portAll scenarios have been covered without the need to introduce new IEs in the RNL.6.5.1.3 Solution with higher flexibility and complexity using additional RNL parametersVoid.6.5.1.4 Provisioning and Dynamic Selection of the Transport OptionThis solution allows to perform load balancing and to indicate transport preferences for dual stack nodes while IPresources are progressively introduced.6.5.1.4.1 On IubOn the Iub, the use of an additional parameter could be seen as useful to ward off some unavailability of one of the twonetworks (ATM, IP). This could also be envisaged during a migration phase to smoothly move from one transporttechnology to another.However, since connection of NodeBs to RNCs is static and a node B has only one parent RNC this facilitates thefilling of an O&M package and it is indeed very easy to add one parameter to this O&M package to inform about thedual-stack capability of a peer side, if desired, for example.6.5.1.4.2 Inter-working on IuIt has been shown that the following behaviour described in the TR 25.933 fulfills the requirement and is very simple:If both CN and SRNC have IP capabilities, the CN sends IP address & UDP port.Otherwise, the CN sends Embedded E164 or AESA variant of NSAP or IP address in the Transport Network LayerAddress IE and Binding ID in the Transport Layer Association IE. 3GPP
    • Release 5 45 3GPP TR 25.933 V5.4.0 (2003-12)In the response direction, only IP information needs to be conveyed.This scenario without new RNL parameters only assumes that the CN node knows about the SRNC transportcapabilities as part of the configuration package already provided (SS7 addresses, etc.).Again on this interface, the O&M package already exists and therefore it is a realistic assumption here that anyadditional parameter can be included in the configuration package.6.5.1.4.3 Interworking on IurThis solution allows the DRNC to make the full decision. It is to be noted that since every RNC can take the role ofSRNC and DRNC on a call basis, the ability to perform load balancing is brought to every RNC. Automatic statisticalregulation of transport usage is thus ensured possible.6.5.1.4.3.1 Provisioning of transport capabilitiesIt is assumed that an RNC is in relation with a limited number of RNC(s). Thefore it is assumed capable to know thetransport capabilities by O&M. The amount of needed resources per transport technology is then provisionned for eachof these interfaces. The provisioning may be the result of dimensioning or operator driven network configuration.6.5.1.4.3.2 Indicate dynamically in a signaling message the IP Transport Option Availability or ATM PreferenceThe originating node sends a transport information to the terminating node, so that the terminating node has all possibleinformation for its decision for selection of the transport option.This means that the SRNC can send either its IP address whenever it is IP capable (i.e. dual stack or IP only node) or noaddress at all when it wants to indicate IP resource unavailability on its side or a preference for ATM.Sending an IP address allows the DRNC to make the full decision by indicating back its preferred transport. Thus whenan ATM address is returned, ATM bearer is established. When an IP address is returned, IP bearer is established.To the opposite, sending no address forces the DRNC to use ATM.6.5.1.4.3.3 BenefitsThis Iur solution is a compromise solution that presents a lot of benefits: - full flexibility for the receiving node (SRNC for Iu, DRNC for Iur, Node B for Iub) as it knows the capabilities of the originating node; - the two transport options are equal; - load sharing and operator preference (configured) could be supported; - migration scenario fulfilled: If an operator wants to migrate a UTRAN node from ATM to IP, the UTRAN node will during a shorter or longer period of time have both transport options available and the actual switchover might be difficult to plan in advance. As soon as the ATM node becomes also IP capable during a migration phase, it can send an IP address instead of no address; - no New IEs at all is added to the RNL.6.5.1.4.3.4 DrawbacksThis solution is based on the assumption that the usage of transport resources is symmetrical.Thus, only one node (the DRNC) has the possibility to decide for using the IP transport option, SRNC can only decidefor ATM transport.In case of ATM resource unavailability at the SRNC, there is no way to force the DRNC to establish an IP transportbearer. 3GPP
    • Release 5 46 3GPP TR 25.933 V5.4.0 (2003-12)6.5.2 LIPE solution [Editors note: This clause refers to deleted or expired ietf-drafts]When LIPE is being used for Iub/Iur User Plane traffic, there are two alternatives for user plane transport signalling.Alternative I requires no changes in the existing RNSAP and NBAP procedures but a lightweight ALCAP-likeprocedure is required. Alternative II introduces a new information element to Radio Link Setup Messages in RNSAPand NBAP but ALCAP is not required.6.5.2.1 Alternative I Solution:There are two steps involved in creating a communication channel between two LIPE peers. The first step is to set up aLIPE tunnel. Once a tunnel has been set up, connections for different streams may be multiplexed into this tunnel.Typical scenarios for a LIPE tunnel are illustrated in figure 6-14. In the case of point to point link, we assume that IPlayer connectivity has been established using mechanisms such as PPP, ATM-AAL5 etc. Point to Point Link RNC RNC/Node B LIPE Tunnel RNC IP Cloud RNC/Node B LIPE Tunnel Figure 6-14: Typical LIPE tunnels in a 3GPP network LIPE tunnel set up request LIPE tunnel set up reply LIPE connection set up request LIPE connection set up reply RNC RNC/Node B Figure 6-15: Tunnel/Connection set up procedure 3GPP
    • Release 5 47 3GPP TR 25.933 V5.4.0 (2003-12)6.5.2.1.1 LIPE Signalling ChannelA specified UDP destination port is used for the exchange of LIPE signalling messages The format of the LIPEsignalling message is given in figure 6-16. IP UDP TYPE LENGTH Control Message Payload (20) (8) (4) (4) (20) Figure 6-16: LIPE Signalling Channel Message format6.5.2.1.2 Tunnel Setup ProcedureThe actual format of the tunnel setup control message payload is shown in [22].The tunnel set up request message payload should consist of the following: 1) UDP destination port number for the LIPE tunnel for the reverse LIPE tunnel.Protocols such as RSVP may be used for reservation of bandwidth resources across the path between LIPE peers forQoS guarantees. This issue is not addressed in this contribution.A successful tunnel set up reply message should consist of: 1) UDP destination port number at the destination node for the forward LIPE tunnel.A tunnel setup failure condition is triggered by a tunnel set up reply message or time out. Retransmissions of LIPEtunnel set up messages for failed tunnel set up instances should be supported.6.5.2.1.3 Connection Set up ProcedureOnce the tunnel set up procedure has been completed, connections for several RABs can be set up on the tunnel. Acontrol message type is defined for connection setup request. The actual format of the connection setup request controlmessage payload is shown in [22]. Connection request for a LIPE connection for a RAB carries: 1) RABID; 2) Flow ID (FID).A control message type is defined for connection setup reply. The actual format of the connection setup reply controlmessage payload is as shown in [22]. A successful connection set up reply message carries: 1) Error Code; 2) RABID; 3) FID for the reverse path.A connection setup failure condition is triggered by a connection set up reply message or time out. Retransmission ofLIPE connection set up messages for failed connection set up instances should be supported.6.5.2.1.4 Tunnel tear downA control message type must be defined for tunnel tear down. The actual format of the tunnel tear down controlmessage payload is as shown in [22]. Tunnel tear down may be initiated by either peer. The tunnel tear down messageshould contain: 1) UDP destination port for the forward tunnel (w.r.t to the peer initiating tunnel tear down).A tunnel should not be torn down without tearing down all connections through the tunnel. 3GPP
    • Release 5 48 3GPP TR 25.933 V5.4.0 (2003-12)6.5.2.1.5 Connection tear downA control message type must be defined for connection tear down. Connection tear down request should carry. 1) FID;6.5.2.2 Alternative II Solution:For the Iur interface, the procedures setting up transport bearers should be modified to include an information elementfor conveying the flow identifier information in the Request message. Correspondingly, the DRNC should return a flowidentifier information for the reverse direction in the Response message.Similarly, for the Iub interface, the NBAP, the procedures setting up transport bearers should be modified to include aninformation element for conveying the flow identifier information in the Request message. Correspondingly, the NodeB should return a flow identifier information for the reverse direction in the Response message.When Alternative II solution is being used to establish flow identifiers, ALCAP is not required.6.6 Layer 1 and layer 2 independenceThis study area is related to the capability to allow multiple layer 1 and layer 2 technologies.The role of Layer 2 and Layer 1 in the QoS and/or in the transport resource efficiency needs to be considered whenspecifying the requirements towards L2/L1.Requirements on L2/L1 (e.g. in sequence delivery) should be documented in the UTRAN specifications to ensure thatappropriate technologies can be more easily selected.6.6.1 Options for L2 specification6.6.1.1 GeneralThe used L2 techniques may vary across the different interfaces and links. Especially, if slow links are used at Iubinterfaces, specific features from the L2 protocol are required. Besides the multiplexing functionality, ML/MC-PPP[20], [21] may be required for QoS differentiation. It provides several queues, segmentation and schedulingfunctionality. Header compression is an other important feature which may be required to improve the efficiency.A common case in the IP transport architecture is that the UTRAn NEs are connected to an IP router which is thenresponsible for the L2 termination. Supported L2 techniques have to be negotiated with the IP network provider to buildan efficient TNL. It is then up to the operator what layer 2 protocols are used in the transport network.However, also the use of point-to-point links between UTRAn NEs is a reasonable scenario. Here, no intermediaterouter will terminate the L2, both NEs have to implement the same L2 protocol. In a multi-vendor scenario this casemay cause problems.6.6.1.2 L2 not standardizedNot standardizing any L2 will provide the most freedom for the operators to build their transport network. A variant ofthis approach could be to standardize some requirements for the selection of L2 to ensure that the expected functions forUTRAN TNL are provided. However, because the usage of these functions in L2 is essential to provide an efficientTNL service, they will be implemented anyway even if not required in the standard. The only issue which remains hereis the multi-vendor scenario. 3GPP
    • Release 5 49 3GPP TR 25.933 V5.4.0 (2003-12)6.6.1.3 L2 standardizedFully standardizing one L2 to the exclusion of allowing others would solve the multi-vendor issue for point-to-pointlinks. But, standardizing one exclusive L2 protocol that must be used in the UTRAn NEs would restrict the flexibilityfor the operators. A solution which solves the multi-vendor issue, but still offers the full flexibility would be thepreferred approach for the L2 standardization for IP transport in UTRAN.Requiring the implementation of one or a limited set of L2 protocols, but still allow the use of any L2 protocol in theUTRAn NEs would be a good solution for the standard.The L2 protocol specified in the standard to be implemented in the UTRAn NEs should be the PPP protocol [11] withits extensions PPPmux [10] and ML/MC-PPP [20], [21] and header compression. During the work in RAN3 for IPtransport it has been shown that the PPPmux approach fulfils the requirements and provides good performance.The layer 2 framing protocol below PPP is FFS.6.7 Radio Network Signalling bearerThis study area is related to the transport of Radio Network Signalling over an IP network.6.7.1 Iub RNL signalling bearer6.7.1.1 SCTP characteristicsSCTP/IP [24], [25] can provide the following: - acknowledged error-free non-duplicated transfer of user data; - data fragmentation to conform to discovered path MTU size; - sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages; - optional bundling of multiple user messages into a single SCTP packet; - network-level fault tolerance through supporting of multi-homing at either or both ends of an association; - congestion avoidance behaviour; - resistance to flooding and masquerade attacks.6.7.1.2 Proposal 1In an IP network, transport protocols like TCP or UDP are used to transport messages. UDP is unreliable. TCP hasweaknesses regarding signalling transport e.g. it is a byte-oriented protocol instead of a message-oriented protocol (see[24], [25]). SCTP, the new protocol that is being developed in IETF for the purpose of signalling transport in an IPnetwork, is a suitable alternative. Furthermore, SCTP has already been introduced on Iur and Iu-PS interfaces inRelease 99 / Release 4 specifications. (See [4] and [6]) Therefore, it is proposed to adopt SCTP on Iub as well. 3GPP
    • Release 5 50 3GPP TR 25.933 V5.4.0 (2003-12)The proposed protocol stack in RNC and Node-B for the IP option is as follows: NBAP SCTP IP Layer 2 Layer 1 Figure 6-17: Iub Signalling bearer protocol stack without Adaptation Layer6.7.1.3 Proposal 2For an SCTP-based solution for the Iub signalling bearer, an SCTP adaptation module would be used between NBAPand the SCTP protocol. N BA P SSC F A da pt Mod TP SC SCTP IP Iub L1/L2 Figure 6-18: Iub Signalling bearer protocol stack with Adaptation Layer6.7.1.4 Use of SCTPA SCTP connection between two endpoints is called an association. One SCTP association can be considered as alogical aggregation of streams. A stream is a unidirectional logical channel between 2 endpoints. In order to achieve bi-directional communications, two streams are necessary, one in each direction. Each user message (i.e. a messageoriginated from the SCTP user application) handled by SCTP has to specify the stream it is attached to, a streamidentifier allows to identify each stream inside the association. Therefore, each SCTP stream can be considered as anindependent flow of user messages from one SCTP node to another. The stream independence has the advantage ofavoiding blocking between streams.Between CRNC and Node B, one or several SCTP associations might exist. Node-B selects a SCTP association atcreation of an UE context. It would not be very efficient to consider each association as a signalling bearer because allrequirements of NBAP signalling transport can be fulfilled by one SCTP stream. Since it can be considered one SCTPassociation is an aggregation of NBAP signalling bearers, it is proposed that each NBAP signalling bearer be mappedon a pair of SCTP streams (one in downlink and one in uplink). The choice of stream identifiers being done by the userapplication, the simplest solution is to choose the same stream identifier for the two streams. Although two streams perassociation (one in each direction) is enough for the transfer of NBAP messages, this proposition adds more flexibilityas it allows each association to support several flows of NBAP messages and it has the advantage to avoid blockingbetween signalling bearers. 3GPP
    • Release 5 51 3GPP TR 25.933 V5.4.0 (2003-12)[7] describes the Node-B logical model as it is seen from the CRNC. It defines one Node B Control Port andCommunication Control Ports within each Node-B. A communication control port corresponds to one signalling bearerand each signalling bearer between Node-B and CRNC can at most correspond to one communication control port. Atcreation of an UE context, Node-B selects a communication control port whose identity is communicated to CRNC.According to the previous discussion, each communication control port will correspond to one SCTP association andtwo SCTP streams in opposite directions of the same association. And similarly for the Node-B control port.It is expected NBAP specifications will not be impacted by this change. The IE "Communication Control Port Id" stillidentifies the signalling bearer i.e. one SCTP stream number inside one SCTP association between the Node-B and thecontrolling RNC.6.7.2 RNSAP SignallingThe SUA [26], [50] delivery mechanism provides the following functionality: - support for transfer of SS7 SCCP-User Part messages (e.g., RNSAP); - support for SCCP connectionless service; - support for SCCP connection oriented service; - support for the seamless operation of SCCP-User protocol peers; - support for the management of SCTP transport associations between a SG and one or more IP-based signalling nodes); - support for distributed IP-based signalling nodes; - support for the asynchronous reporting of status changes to management.Given these capabilities, SCCP (and the associated adaptation protocol, M3UA) may be unnecessary and it should beconsidered that they may be eliminated in order to provide a simpler and more efficient signalling transport that may becarried via SUA/SCTP/IP over ATM AAL5 or other Layer 2 protocols, such as HDLC-PPP, etc.6.7.3 RANAP SignallingIn order to minimize the changes on UTRAN Radio Network Layer and thus to reduce the number of different variantsof any application signalling protocol, the SCTP shall be used together with the suitable Adaptation Module. This isaccording to the signalling transport framework architecture of the SigTran Working Group of IETF, RFC 2719 [24].The following figure illustrates the application of Adaptation Module in the Transport Network Layer of Iu interface. Iu Rad io N e two rk Laye r RAN AP Ad ap tatio n Transp o rt M o d u le SC TP N etwo rk r Laye IP Link Laye r Ph ysical Laye r Figure 6-19: RNL Signalling bearers on Iu interface, the principle 3GPP
    • Release 5 52 3GPP TR 25.933 V5.4.0 (2003-12)6.7.4 PCAP signallingThe Iupc signalling transport protocol stack is structured the same as the Iur and Iu interfaces control plane, i.e. they areSCCP users. Therefore, the transport solution chosen for the Iur and Iu signalling interface shall also be applied to theIupc interface.6.7.5 SCCP/M3UA versus SUABased on contributions R3-012155 and R3-012163, this clause captures an analysis study effort done during the IPAdhoc #4 that attempted to do a comparison in the major areas between choices of SCCP/M3UA vs SUA as RNLSignalling Bearer options for RANAP and RNSAP.The analysis was captured using a spreadsheet table format with 3 columns identified of: - "Area" – technical aspect serving as basis for the comparison; - "Advantage (SUA, M3UA, neither)" – indication if either SUA or M3UA or neither had any advantage over the other technology; - "Weighting (0 – no advantage, 1 – low, 2 – medium, 3 – high most affecting)" – relative weighting of the indicated advantage.The areas in bold were items that were treated during the analysis effort which were also areas that were covered incontributions presented at the IP Adhoc #4 session. It was also argued that this list of areas was incomplete. Consensuswas not achieved.The areas in italics were items that were suggested and agreed as important areas to be considered but wereacknowledged not to be covered as they were not in the contributions presented at IP Adhoc #4 session. 3GPP
    • Release 5 53 3GPP TR 25.933 V5.4.0 (2003-12) Advantage (SUA, M3UA, Weighting (1 – low, 2 – medium, 3 – Area neither) high most affecting) SUA – one step mapping (as opposed to two step for Routing Efficiency M3UA,national boundary) 2 SUA - SUA does not mandate Addressing Flexibility use of point codes 3 Neither – M3UA has gone thru last call but requested to go thru last call again and SUA in Standardization Maturity last call to end 8/24/01 0 SUA – M3UA has other obligations in its support that Protocol Complexity SUA not needed 2 SUA – If M3UA is already there, management is more complex, in all other cases simpler (e.g. DNS, ENUM server address management & not needed management of SCCP and M3UA layer) with Management Complexity SUA. 1 Neither – Requirement of sigtran on M3UA and SUA is to Interworking interwork with SS7 cleanly. 0 M3UA – SUA alone not backward compatible with M3UA. It leads to additional SG and increased network complexity however SCCP/M3UA and SUA are peers thru use of SG, as Backward Compatibility defined in IETF SUA draft. 3 M3UA – Neither candidate is RFC (preventing any multi- vendor implementation from existing) M3UA has done interoperability testing and issues found in earlier version, SUA has not done inter- Testing Maturity operability testing. 1Weighted Total (SUA = 8, M3UA = 4) Areas not covered in either contribution on RNL Signalling Transport Operational Cost Iub Applicability Scalability6.7.6 Interworking of SCCP/M3UA and SUAIn this clause the interworking principles within SS7 and SigTran networks are first shortly explained and then the moredetailed description of the interworking between SUA and SCCP/M3UA is given. 3GPP
    • Release 5 54 3GPP TR 25.933 V5.4.0 (2003-12)6.7.6.1 Interworking in native SS7 networksIn SS7 both MTP-3 and SCCP have several national variants (ETSI, ANSI, China, etc.) that are incompatible with eachother. In addition to national variants there is the international version of both protocols (ITU-T) to enable worldwideconnectivity between national SS7 networks. As a conclusion, in SS7 networks whenever there is a need forconnectivity between different countries or between different operators networks, the application of a SignallingGateway is a necessity. This applies both for MTP-3 and for SCCP. Here the Signalling Gateway is a Signalling Pointthat has an interface to all SS7 networks that are to be connected through it. Global roam ing Country 1 International Country 2 SS7 SGW SS7 SGW SS7 Figure 6-20: Global SS7 networkingThe use of SCCP on top of M3UA makes the availability of a Signalling Gateway a must also in SCCP/M3UAnetworks. Only in SUA-only environment there is no need for interworking within the signalling network itself. This isfor the reason that neither MTP-3 nor SCCP are present there.6.7.6.2 Interworking in SS7 and SigTran NetworksIn SS7 networks the nodes involved in signalling/signalling transport are called Signalling Points (SP). A SignallingPoint can be either a Signalling End Point (SEP) or a Signalling Transfer Point (STP). The Transport Network Layer ofthe SS7 network is called Network Service Part (NSP). In the following figure there are the TNL of the traditional SS7,of UTRAN Rel99&Rel4 IP option and of the proposed SUA based Rel5 IP option. sam e services SCCP SCCP SUA M3UA NSP SCTP SCTP TNL MTP-3 IP IP MTP-2 Datalink Datalink MTP-1 Physical Physical Figure 6-21: Network Service Part/Transport Network Layer protocolsA couple of remarks related to the figure above: In SS7 networks it is the responsibility of a Signalling Transfer Point(STP) to act as a router while the routing is based on MTP-3 (link-by-link) and SCCP (end-to-end). In case of SigTranthe networking is provided by Internet Protocol. It is the role of an ordinary IP router to route the signalling messagefrom the originating Signalling End Point to the destination Signalling End Point. The following figures furtherillustrates the protocols used in the signalling network between the Signalling End Points. The peer applicationprotocols are only in the Signalling End Points. 3GPP
    • Release 5 55 3GPP TR 25.933 V5.4.0 (2003-12) SS7 MTP3 3 MTP3 MTP3 SS7 Signalling End Point Signalling End Point M3UA M3UA IP IP IP Signalling Signalling End Point End Point SUA SUA Signalling IP IP IP Signalling End Point End Point SS7 MTP3 MTP3 MTP3 SS7 Signalling 3 Signalling End Point End Point M3UA M3UA Signalling IP IP IP Signalling End Point End Point SUA SUA Signalling IP IP IP Signalling End Point End Point Figure 6-22: Signalling networking in case of SS7 (top), SCCP/M3UA (middle) and SUA in single operator environment (APPLICABLE TO UTRAN)In figure 6-22 above there is the single operator environment depicted. UTRAN in general is a single operatorenvironment. That is, it is assumed that each Signalling End Point knows the routable address to all other SignallingEnd Points. Furthermore, in case of SS7 and SCCP/M3UA it is also assumed that each Signalling End Point knows thenon-routable Signalling Point Codes of all other Signalling Points present in the network. For this reason there is noneed for Global Title Translation from a routable address to the Signalling Point Code. In any larger network (in termsof number of Signalling Points) this approach results in large Signalling Point Code tables in each and every SignallingEnd Point, with the resulting operation & management work. 3GPP
    • Release 5 56 3GPP TR 25.933 V5.4.0 (2003-12) For GTT SS7 SCCP SCCP SS7 Signalling Signalling end MTP3 MTP3 end point IP IP point SCCP SCCP M3UA M3UA M3UA M3UA Signalling Signalling SCTP SCTP end end point point IP IP SUA SUA Signalling Signalling end end point IP IP point SUA relay SUA SUA SUA SUA Signalling Signalling SCTP SCTP end end point IP IP pointFigure 6-23: Signalling networking in case of SS7 (top), SCCP/M3UA (middle) and SUA in multi-PLMN environment (NOT APPLICABLE TO UTRAN)In figure 6-23 above it has been assumed that the signalling networking extends over PLMN boundaries. In such ascenario it cannot be assumed that each Signalling End Point would know the Signalling Point Code of its peer. This isfor many reasons, like the following: Signalling Point Codes may not be unique in two different PLMNs, the size of theSignalling Point Code tables in the involved Signalling End Points would become too big in size, operators do not wantto allow direct visibility of their SPs over PLMN boundaries, etc. For this reason the Global Title Translation function isneeded in the networks. For SUA there are two cases included. In the first case each Signalling End Point knows theroutable address (logical name, IP address) of its peer. In the second case SUA relay is used. The SUA relay has beendefined in clause 1.4.6 of SUA [26]. SUA relay function allows the determination of the next hop SCTP associationtowards the destination Signalling End Point. This determination may be based e.g., on Global Title information (E.164number) in analogy with SCCP GTT in SS7 and M3UA networks above. However, the difference is that in SUA thereis no Signalling Point Codes but the relay function operates with routable addresses. The SUA relay was introduced inSUA protocol to allow greater scalability, flexibility and reliability in wide-scale deployment of SUA (note: In M3UAthere is no relay function specified).Figure 6-24 depicts the two ways that SCTP associations can be established among IP based signalling nodes, the topone shows the mash network with SCTP associations established between each other. The bottom one shows SCTPassociations between two signalling end nodes are bridged through SUA Relay nodes. 3GPP
    • Release 5 57 3GPP TR 25.933 V5.4.0 (2003-12) Signalling Po int 1 IPSP Signalling Po int 2 IPSP Ne twork 1 Signalling Po int n SC TP asso ciatio ns Ne twork IPSP n IPSP Ne twork Ne twork Signalling Po int 1 1 2 SU A Re lay SU A Relay IPSP Signalling Po int 2 SC TP associatio ns SC TP associations SC TP associatio ns IPSP SU A Re lay SU A Relay Signalling Po int n Figure 6-24: Interconnecting Operator Networks with SUAThe networking aspect described above is important also because of the following consideration. In the discussions inRAN WG3 the concern has been raised that as there is the Bearer Independent Call Control protocol (BICC) used in theUMTS Core Network and as it is an MTP-3 User, inherently incapable of using SCCP or SUA, its presence togetherwith SUA would create an interworking issue. However, the description above showed this concern to be invalid. Theinterworking is only needed for the peer SCCP User protocols. If there are two BICC peers communicating with eachother, then they share the signalling network (i.e., IP network) with SUA Users between their corresponding SignallingEnd Points. In the Signalling End Points the signalling stacks are e.g., as follows: No Interworking there No Interworking here In the depicted scenario No interworking is needed only RANAP interworking between the RANAP peers. SCCP BICC here RANAP BICC The presence of MTP-3 User M3UA SUA M3UAapplications does not create SCTP SCTP an interworking issue. IP IP SigTran network Figure 6-25: MTP-3 User (BICC) and SCCP User (RANAP) in the same networkAs it is shown in the figure, there are now two Signalling Users present, one is a genuine SCCP User (RANAP) whilethe other is an MTP-3 User (BICC). In the node on the right there are two SCTP Users, one is SUA and the other isM3UA. The same SCTP instance is used to serve both of its users there. In the node on the left the stack is different; 3GPP
    • Release 5 58 3GPP TR 25.933 V5.4.0 (2003-12)there we have two M3UA Users, one is the BICC while the other is the SCCP. The same M3UA instance can serve bothof its users. There is no interworking involved that would be caused by the presence of both MTP-3 Users (BICC) usingM3UA and SCCP Users (RANAP) using SUA.6.7.6.3 Interworking in UTRANRegardless of the used SigTran adaptation layer there is a need for interworking DOCUMENTTYPE network between the non-IP SS7interfaces and SigTran network interfaces. The Signalling Gateway needs to offer the protocols and their interworking TypeUnitOrDepartmentHereas shown in figure 6-26. TypeYourNameHere TypeDateHere Global roam ing IWF SigTran networks Non-IP SS7 (SUA, SCCP, M3UA, SCTP, IP, datalink) (MTP levels 1 -3, SCCP) Figure 6-26: Interworking between SigTran and non-IP SS7Interworking within the SigTran domain is necessary if one of the Application protocol peers (e.g., RANAP-RANAP) isusing SCCP/M3UA-based SigTran stack while the other is using SUA-based stack. As it was described earlier, there isstill no need for interworking in the signalling transport network as such, because of the fact that the signalling transportwithin the intermediate transport network is carried out by IP protocol and IP routers in both cases. The SCTP and itsadaptation layer are implemented only in the Signalling End Point where the Application protocol peers areimplemented. The only reason for any interworking in the network would result from the use of more than one SCCPvariant in the SCCP/M3UA side of the SigTran domain. In this case the interworking would be purely between the twovariants of SCCP.In the following figure some of the SUA-SCCP interworking options are illustrated. DUAL STACK RANAP RANAP SUA SCCP SCCP M3UA M3UA SCTP SCTP IP IP SigTran network SIGNALLING GATEWAY RANAP RANAP RANAP RANAP RANAP SUA SCCP SCCP SCCP SUA M3UA M3UA SUA M3UA SCTP SCTP SCTP SCTP SCTP IP IP IP IP IP SigTran SigTran SigTran network network network EVOLUTION RANAP RANAP SUA SUA SCTP SCTP IP IP SigTran network Figure 6-27: Interworking between the SCCP User peers in UTRANAs a conclusion for now it is said that the Signalling Interworking Function as such is needed in the 3GPP networksregardless of the application of SUA. This is the case in order to provide global roaming in SS7 environment in general, 3GPP
    • Release 5 59 3GPP TR 25.933 V5.4.0 (2003-12)due to national variants of both MTP-3 and SCCP, and in order to connect non-IP and IP (SigTran) network interfacestogether. SUA introduces a need for interworking between the peer SCCP User application protocols in case the otherend point is using SCCP/M3UA bearer. However, the intermediate signalling network does not need to be affected bythis interworking.6.7.6.4 SCCP and SUA interworking in detailSUA is designed to interwork with SCCP seamlessly at a Signalling Gateway. SUA has a class of messages forinforming the SS7 network of the availability of the nodes in the IP network, and a class of messages for informing theIP network of the availability of nodes within the SS7 network. For applications running over SCCP or SUA, there is noimpact on the interworking of SCCP and SUA at the Signalling Gateway.Below there are examples of interworking between applications running in the IP domain and applications running inthe SS7 domain. The Sigtran Working Group recommends that more than one Application Server Process (ASP) bemade available as a Signalling End Point (SEP) within the IP network. RANAP/RNSAP would be terminated at theASP in the IP network.As far as the mapping of the signalling messages is concerned, the following examples cover only SCCP and SUAprotocols. This for the following reasons: 1) Interface but the interworking is between SCCP and SUA. 2) The Signalling Gateway represents the availability of the Application Server Process in SUA domain to the Signalling End Point in SS7 domain (and vice versa). 3) In the SUA side it is the responsibility of the SUA to manage the availability of the Application Server (made up of one or several ASPs handling the SCCP User messages in question) while it is the responsibility of the SCTP to keep the association available between a particular ASP and the SG (e.g., keep-alive, multi-homing). For the case where an association or an ASP goes down, the SUA has the procedures available for the fail-over. On the other side of the SG, SCCP, M3UA and SCTP protocols perform similar functions. It is only the SCCP level actions that are visible on the other side of the SG, while the roles and relationship of the underlying MTP-3 level functions (link management, traffic management and route management) and the SCCP level functions are according to the SS7 specifications. 4) The key point is that the SEP and SG(s) as well as the SG(s) and ASP(s) are made concerned about each others availability and that they have been configured as redundant (link, route, association, ASP, etc.). As a result each entity is able to determine if the peer is still reachable and if a fail-over to a backup is needed and how to reach the backup.6.7.6.4.1 Establishment of SUA connectivityEach involved node is configured with the connections that need to be setup. ASP 1 ASP 2 SG SEP (Primary) (Backup) |------Establish SCTP Association------| |-Estab. SCTP Assoc-| |--Align SS7 link---|Each IP SEP declares to the SG that it is running. +----------------ASP Up----------------> <--------------ASP Up Ack--------------+ +------ASP Up-------> <---ASP Up Ack------+The Primary IP SEP declares to the SG that it is active. The SG notifies all IP SEPs. +-------------ASP Active---------------> <----------ASP Active Ack--------------+ <----------NTFY (ASP Active)-----------+ <-NTFY (ASP Active)-+The SG represents the availability of ASP 1 to the SEP. SubSystem Allowed +--------SSA--------> 3GPP
    • Release 5 60 3GPP TR 25.933 V5.4.0 (2003-12)The SEP declares its availability to the SG. Similarly, the SG informs the active ASP of the availability of the SEP asdictated by SGs concerned list. N.B. The SG maps the SS7 address of the SEP to an IP address, which the SG knowsASP 1 will understand. SubSystem Allowed <--------SSA--------+ Destination Available <-----------------DAVA-----------------+Traffic can now flow. A connectionless flow is shown for simplicity. Nevertheless, the SG is responsible for mappingIP to SS7 addresses and vice-versa. Only the Routing Context for ASP 1 persists from ASP 1 to SEP. +-----------------CLDT-----------------> +--------UDT--------> Connectionless data Unitdata6.7.6.4.2 SEP FailoverThe SEP knows that the SG is concerned about its availability. Similarly, the SG knows that ASP 1 is concerned aboutthe SEPs availability; therefore the incoming SSP is translated into DUNA. ASP 1 uses a DAUD to instruct the SG toinvoke the SS7 Sub-system Test procedure. ASP 1 ASP 2 SG SEP (Primary) (Backup) Destination <--------SSP--------+ SubSystem Prohibited <-----------------DUNA-----------------+ Unavailable +-----------------DAUD-----------------> Destination State Audit +--------SST--------> Subsystem Status Test6.7.6.4.3 Successful ASP Failover scenarioThe following is an example of a successful failover scenario, where there is a failover from ASP 1 to ASP 2, i.e.Primary to Backup. During the failover, the SG buffers any incoming data messages from the SEP, forwarding themwhen the Backup becomes available. Traffic can flow normally after the failure. ASP 1 ASP 2 SG SEP (Primary) (Backup) +------ signalling connection lost -----+ <-NTFY (ASP Inact.)-+ +----ASP Active-----> <--ASP Active Ack---+ 3GPP
    • Release 5 61 3GPP TR 25.933 V5.4.0 (2003-12) 6.7.6.4.4 Message mapping between SCCP and SUA For the seamless support of transfer of SCCP-User Part messages, SCCP messages are mapped into associated SUA messages according to the table below [50]. SUA SUA SCCP SCCP Classes Mgt. SUA Full Name NAME NAME Full Name 0 1 2 3 Msg. Usage Connectionless Messages ConnectionlessCLDT UDT Unitdata x x - - - - Data TransferCLDT XUDT Extended unitdata x x - - - -CLDT LUDT Long unitdata x x - - - - ConnectionlessCLDR UDTS Unitdata service x x - - - - Data ResponseCLDR XUDTS Extended unitdata service x x - - - -CLDR LUDTS Long unitdata service x x - - - - Connection-Oriented Messages ConnectionCODT Oriented Data DT1 Data form 1 - - x - - - TransferCODT DT2 Data form 2 - - - x - -CODT ED Expedited data - - - x - - ConnectionCODA Oriented Data AK Data acknowledgement - - - x - - AcknowledgeCODA EA Expedited data acknowledge - - - x - - ConnectionCORE CR Connection request - - x x - - Request ConnectionCOAK CC Connection confirm - - x x - - Acknowledge ConnectionCOREF CREF Connection refused - - x x - - Refused ReleaseRELRE RLSD Released - - x x - - Request ReleaseRELCO RLC Release complete - - x x - - CompleteRESRE Reset Request RSR Reset request - - - x - -RESCO Reset Confirm RSC Reset confirm - - - x - - ConnectionCOIT Oriented IT Integrity test - - x x - - Inactivity Test ConnectionCOERR ERR Protocol Data Unit Error - - x x - - Oriented Error SS7 MGT Messages NetworkSCON SSC Destination/subsystem-congested - - - - x - Congestion DestinationDAVA SSA Destination/subsystem-allowed - - - - x - Available DestinationDUNA SSP Destination subsystem-prohibited - - - - x - Unavailable DestinationDAUD SST Destination/subsystem-status-test - - - - x - State Auditn/a SOR Subsystem-oos-req - - - - x -n/a SOG Subsystem-oos-grant - - - - x - DestinationDRST n/a Destination Restricted - - - - x - Restricted SUA MGT MessagesASPUP ASP Up n/a n/a - - - - - xASPDN ASP Down n/a n/a - - - - - x ASPASPAC n/a n/a - - - - - x AcknowlwdgeASPIA ASP Inactive n/a n/a - - - - - xNTFY Notify n/a n/a - - - - - xERR Error n/a n/a - - - - - x 3GPP
    • Release 5 62 3GPP TR 25.933 V5.4.0 (2003-12) SUA messages (CLDT, CLDR) support all 6 SCCP connectionless messages.-2002 - = Message not applicable for this protocol class.X = Message applicable for this protocol class.N/a = not applicable6.7.6.5 ConclusionsBased on this contribution the following is concluded. 1) Signalling Interworking Function is needed in 3GPP networks in order to provide global roaming and in order to interconnect non-IP and IP-signalling (SigTran) networks. This is irrespective of the type of SigTran adaptation layer. 2) Co-Existence of MTP-3 User application protocols (e.g., BICC) and SUA does not generate need for interworking. 3) Interworking of SUA and SCCP is needed to connect two application protocol peers (e.g., RANAP-RANAP), one using SCCP/M3UA and the other using SUA. M3UA and SUA as SigTran protocols have common network layer in the intermediate signalling network. 4) Interworking of SUA and SCCP is an integral part of the SUA specification. The Signalling Gateway functionality is a key feature of SUA protocol. In interworking the Signalling Gateway represents the SUA endpoint to SCCP/M3UA endpoint and vice versa.6.7.7 Iub Signalling Bearer Comparison Data6.7.7.1 Comparison TCP, UDP, SCTP6.7.7.1.1 User serviceA first difference between these three protocols is the user friendliness of the format presented to the user application.TCP is a byte-oriented protocol whereas SCTP is message oriented. This allows easier parsing of messages at theapplication layer because there is no need of establishing boundaries.However, this advantage is quite negligible. Also in case this would be desired, a tiny adaptation layer can do the jobover TCP.6.7.7.1.2 ReliabilityUDP is well known to be an unreliable protocol due to its connectionless state.To the opposite, TCP features SACK messages that allow a quick detection of loss of packets. TCP also implements afast retransmit option that can be associated in order to send the SACK messages faster than normal packets whenlosses are detected.The result of these mechanisms is that call set-up times are expected to be more evenly distributed together with beingshorter whereas the simple detection of packet loss would take more than 500 ms with UDP.SCTP features the same advantages as TCP compared to UDP because it is similarly a connection-oriented transportprotocol.6.7.7.1.3 AvailabilityCongestion control performance is also less effective with UDP because congestion states are computed on atransaction per transaction basis, rather than across all transactions. To the opposite TCP and SCTP maintain congestioncontrol over the entire connection so that the aggregate rate of messages can be controlled. 3GPP
    • Release 5 63 3GPP TR 25.933 V5.4.0 (2003-12)In terms of availability, one of the key new features brought by SCTP is the multi-homing: this means that a singleSCTP endpoint can support multiple IP addresses. Multi-homing can be used for redundancy and allows a greatersurvivability in case of network failures. For example, it could be combined with the use of different prefixes to forcethe associated routing to go through different carriers.Multi-homing is a clear differentiator on SCTP side but can be considered minor since it is today associated with fallback modes and cannot be used for load sharing.6.7.7.1.4 Defence/SecurityOne of the key technical advantage of SCTP is the security aspect that is more developed. A "cookie" mechanism hasbeen incorporated to guard against some types of denial of service attacks. In particular, it is efficient against a blindattacker trying to get memory and resources down of an SCTP server by overflowing it. It uses signature authenticationwithout need of key exchanges with the client.6.7.7.1.5 PerformanceAnother differentiator for SCTP is the efficiency of the use of the connections it makes. SCTP features the "multi-streaming".According to the node-B logical model as defined in TS25.430, one signalling bearer per communication control port isset up which result in several TCP connections on one hand or one to several SCTP associations on the other handbetween the node B and the CRNC.In a likely NBAP scenario, one signalling bearer would be mapped either on one TCP connection on one hand or ontotwo SCTP streams of one SCTP association on the other hand. This is because one SCTP stream is unidirectional.Therefore, they could be from one to several SCTP associations depending on the signalling endpoints.The corresponding drawing shows the mapping of signalling bearers onto TCP streams: RNC Node B TCP connections Switch NBAP instancesThe corresponding drawing shows the mapping of signalling bearers onto SCTP streams: RNC Node B STCP connections Switch NBAP instances 3GPP
    • Release 5 64 3GPP TR 25.933 V5.4.0 (2003-12)The main advantage of SCTP compared to TCP results from the mapping of the signalling bearers onto differentstreams which can be considered as independent flows of user messages.The resulting benefit is to avoid the so-called head of line blocking between signalling bearers. To the opposite, whenusing TCP, several transactions can be multiplexed within a single TCP connection and the loss of one transaction canhamper concurrent ones.However, this benefit only occurs under loss conditions and the Iub is not considered a lossy link. For example, evenwhen microwave links are being used, it has already been shown (around UDP-lite discussions) that the loss rate isnegligible 99,99% of time and that losses only occur during fading which result anyway in deconnection. The SCTPresilience to head of line blocking is therefore minor when considered on Iub.Also, using one TCP connection per signalling bearer in the node B seems a reasonable possible implementation. Whenthere are too many, anyway, SCTP has the same troubles than TCP since it agrees at the beginning on the number ofstreams opened and when all streams have been mapped, there is again the head of line blocking possibility.Management of SCTP streams is not that easy.6.7.7.1.6 RNL changesIn terms of addressing, each user message originated from the user application handled by SCTP has to specify theStream Identifier within an SCTP association it is attached to. The choice of the stream identifiers is to be done by theuser application. However, to that respect, all protocols should be equally footed.6.7.7.1.7 Implementation DifficultyCompared to TCP, SCTP complexity is obviously greater as it can be compared as TCP plus additional features. Alsothe knowledge of the protocol is not the same. However, some of these features can be treated as options and need notbe present at first time and therefore both can be considered equal regarding this criteria.6.7.7.1.8 MaturityIt is clear that TCP choice is more mature than SCTP. TCP has been existing for a long time in the market whereasSCTP is a new RFC from October 2000. However, the development of SCTP has taken into account several years ofTCP existence. To this respect, the TCP experience has passed through SCTP and they can be equally ranked.6.7.7.1.9 InteroperabilityRegarding interoperability, SCTP interoperability testing should have also already been conducted for the Iur/Iu andeven if TCP is more mature regarding this interoperability, it features several variants that could thwart carelessinteroperability.Finally, this gives a small advantage for SCTP.6.7.7.1.10 Operational aspectsSCTP already selected on Iur&Iu: but these interfaces affect the RNC. Today the choice of SCTP on the Iub would onlyresult in the support of a new protocol in the node B. However, the choice of TCP would result in a new protocol inUTRAN. This gives an advantage for SCTP. 3GPP
    • Release 5 65 3GPP TR 25.933 V5.4.0 (2003-12)6.7.7.2 SummaryIn order to summarize all the points made above, and to assign to them a proper weighting, even if the task is not alwayseasy to be performed in an unbiased way, the following matrix tries to capture all these conclusions: UDP SCTP TCP User service 1 1 0 Reliability 0 2 2 Availability 0 3 2 Defence/Security 0 2 0 Performance 0 3 1 RNL changes 0 0 0Implementation difficulty 0 1 0 Maturity 0 0 0 Interoperability 0 1 0 Operational aspect 0 2 0As a summary, this table shows that: - UDP is too unreliable and too less performant compared to the others, - even if both can address the requirements of the NBAP Iub signalling transport, SCTP offers actually both technical and operational advantages over TCP.6.7.8 Reference Architecture for ENUM based ServicesTo transport SS7 applications (service/protocol) in an all IP environment, especially using peer-to-peer architecture,will require an infrastructure to translate the global titles and subscriber IDs (IMSI, IMEI, E.164) to an IP address of anSS7 service node.Currently in an IP environment, there is no scheme defined for retrieval of service applications node address (IPaddress, Host name or URI etc.) based on IMSI as an identifier. The same can be applied to IMEI-International MobileEquipment Identifier, which is used extensively as an identifier for mobile equipment to provide authentication/securityservices for the mobile subscribers.The translation of these identifiers or so called Global Title (term used for identifiers in SS7 environment) to an IPaddress can be performed deploying an infrastructure based on ENUM/DNS servers or some other means. However, forENUM/DNS to be used for mapping each identifier to IP address, we need to define a unique domain for eachnumbering plan (e.g. e164.arpa, e212.arpa and e214.arpa, IMEI.arpa, Point Code.arpa etc). Apart from creating newdomains by the IANA, there is tremendous work that needs to be done to come up with procedures to administer thesenumbers. Not to mention the large memory requirement to accommodate the entire range of identifiers at eachoperators domain to map the correct IP address to these numbers corresponding to the service application node(s).A DNS server can be populated with IMSIs if an operator wishes to use IMSI and wants to establish his own privatenation-wide data network. However, even though the present document does not preclude the use of IMSI/DNS, theproblem still remains of managing two different DNS domains and not to mention other domains that might need to beadded depending on the services associated with other global titles and subscriber Ids.6.7.8.1 Key requirements/assumptions of the mobility services using ENUMIMSI (E.212) is used as the subscriber ID for roaming and registration services in mobile environment. The followingare the key requirements to be supported by the ENUM based DNS infrastructure: - Using IMSI received from a subscriber, identify a physical or a virtual node providing a specific mobility related service such as: MAP-HLR etc. within a PLMN. - These service applications nodes and their IP addresses need to be under the control of the local domains. These should be defined by the service provider based on service providing capability, that is: a service application nodes IP address can be provided in the local DB/ENUM depending on the type of services it is handling or the GT types/protocols it is capable of handling. This is further illustrated in later clauses of the present document. 3GPP
    • Release 5 66 3GPP TR 25.933 V5.4.0 (2003-12) - Using a common standards based infrastructure such as ENUM, identify the IP address of a specific service application node to be used for sending the subsequent MAP applications messages and to negotiate the GT data type to be used within the messages. - To identify/discover the service handling capability of a PLMN. This can be further utilized for Service discovery prior to sending query associated with a specific service. - A common solution based on ENUM, using both IMSI, E.164 and other global titles based numbering schemes to provide service/protocol discovery and service node identification (retrieval of the destination IP address) will simplify network management for the operators. The same common infrastructure for address resolution should be applied all SS7/IP user adaptation protocols. Derived requirements associated with this are: - Provide service discovery and identification of the appropriate service applications node for other services not associated with IMSI or E.164 numbers. - To provide ability of sharing a service application node across geographically dispersed PLMNs (centralized service concept). - Provide an inter-working between the various SS7/IP adaptation protocols.6.7.8.2 Some definitionsHere, two new concepts are introduced: First: Service Application PLMN Code (SAPC) and, second: Addition of newservices in ENUM under the control of the operators who have reached a roaming agreement for a set of subscribers.Service Application PLMN Code (SAPC): Service Application PLMN Code (SAPC) is a unique E.164 numberassigned to a PLMN providing a set of services. Table 1 gives examples of SAPC codes for different PLMNs. It shouldbe noted that the use of wild card to denote an exchange code would work equally well and is covered by the SAPCconcept introduced in this draft paper. However, the wild card use in DNS can cause unpredictable results. It is alsorecommended that it should not be used in DNS/ENUM. SAPC code assignment will undoubtedly work to associate aset of services uniquely with a PLMN.SAPC concept applies to other services as well as potential future services such as Instant Messaging, Dispatch etc.which may not be based on or associated with E.164 numbering scheme. Refer to table 1 for SAPC codes and theassociated services provided by a PLMN. Services can be associated with a number of different subscriber ID scheme,such as: E.164 (CAP, MAP, SIP), E.212 (MAP), E.XXX (Dispatch/group calls), Point Codes (SS7 support service) etc. Table 1: SAPC Example using an unique code (assigned to PLMN) PLMN SAPC Available Service URIs SIP MAP CAP DISPATCH Protocol-URI 1 1-817-822-1999 X X X (SS7-SG) 2 1-817-707-2001 X X X (M2UA) 3 1-214-797-2001 X X X X (M3UA) 4 1-212-363-1988 X X X (IUA) 5 1-212-676-1111 X X X X (SUA) 6 1-516-676-0000 X X X X (SUA) 7 1-202-765-0000 X X X (SS7-SG) N 1-202-676-000 X X X (SUA)Services/Service application node: Services could be based on and associated with any numbering scheme. Servicescould be in support of Voice Dispatch, Instant Messaging etc, and can be based on any identifier (E.212, E.214, E.164,IMEI, point code as node address etc.) using any protocol type. An example of a service can be support of the SS7message routing functionality to legacy networks. Additionally, service can be associated with a particular protocolsuch as SUA @ IP add/host name, M3UA @ IP add/host name, XUA @ IP add/host name etc.Discovery/Retrieval of IP address for a service application node can be based on any service URI specified in ENUM.New services can be standardized and introduced via ENUM in conformance with governing regulations.SCCP User Adaptation protocol (SUA): SUA stands for SCCP User Adaptation protocol. SUA messages contain theglobal titles within the message body as part of the called party address field. 3GPP
    • Release 5 67 3GPP TR 25.933 V5.4.0 (2003-12)Here the use SUA is synonymous with XUA (any SS7/IP adaptation protocol such as SUA, M3UA, M2UA, M2PA,IUA etc.) to explain the reference architecture and operation for mobility services. SUA is used from here on as anexample only.6.7.8.3 System solution based on ENUMThe present document focuses on a solution that will work with just one domain (e164.arpa) in ENUM for all thenumberings schemes which includes, E.164, E.212, E.214 etc., thereby reducing the memory requirements,administrative overhead, operational and management costs etc. The present document describes an architectureillustrating how SUA can deliver SCCP-User messages to the destination node using the Global Title Information thatare based on IMSI as well as E.164 numbers. The architecture makes use of the RFC 2916 (ENUM/DNS) to achievethis by using the concept of Service Applications Code (SAPC) and the inclusion of mobility services URI (MAP URIetc.) in ENUM.It is expected that operators populate the ENUM with MAP URI associated with mobility services such asMSC/HLR/VLR etc. End point service node IP addresses, associated with a set of services, need to be stored in ENUMcorresponding to the SAPC belonging to the local operator for a given PLMN. These end node IP addresses are sent aspart of the ENUM/DNS response to the query based on this PLMN SAPC (E.164 number format).Received URI/IP address from the ENUM is based on the standard query information based on the preference andorder. Therefore, either the URI/IP address of the service node providing the mobility services can be retrieved uniquelyor all the services populated (provided by the service provider) can be known by using the ENUM query based onPLMN s E.164 number (SAPC).6.7.8.4 Service discovery/IP address retrieval of end service nodesAs stated earlier, service applications nodes can be defined by the service provider in ENUM, that is: a serviceapplication nodes IP address can be provided in the local DB/ENUM depending on the type of services it is handling ora specific protocol based services that it is capable of providing.Operational scenarios:Two scenarios are described. - First scenario (Figure 1) illustrates the service discovery with point code as the global title. An example of such a service is SS7 support service to provide inter-working function for the legacy SS7 networks using point codes based addressing scheme and SG as the service application node. To further illustrate this, a small satellite PLMN not capable of providing legacy SS7 network support via SG could utilize this service via its main PLMN 1 supporting such a service. Therefore, using the SAPC concept in ENUM domain, a satellite PLMN could identify the IP address of a specific service application node to be used for sending the subsequent SS7 applications messages to the legacy SS7 network via the main PLMN. - Second scenario (Figure 2) illustrates the discovery of a virtual IP address of a proxy node for load balancing in a distributed architecture using SS7/IP user Adaptation Proxy function (SAP) concept. Signalling Gateway (SG) is shown as two separate functions: SIF and SUA for clarity and to utilize the load sharing function of the SAP for the legacy SS7 network messages.Notes/assumptions: - Service Applications Node (example- SUA) can be based on any SS7/IP adaptation layer protocol. - Local ENUM can contain a virtual IP address or an IP address of a physical service application node providing mobility services (HLR in this case) - Discovery/Retrieval of IP address for a service application node can be based on any service URI specified in ENUM. - Service discovery can be based on standard DNS/ENUM query with order and preference. - PLMN 1 and PLMN N have roaming agreement and are aware of the SAPC codes for each others PLMN.Scenario 1: SS7 support services example using point code (see figure 1) - Operational steps: 3GPP
    • Release 5 68 3GPP TR 25.933 V5.4.0 (2003-12) - SUA node in PLMN N receives IMSI (registration request) from MS. - PLMN N determines that the subscriber belongs to a PLMN with legacy SS7 support only. - SUA node looks-up corresponding SAPC (E.164 number = 1-817-822-1999) in local DB/ENUM. - SUA node uses this as the unique E.164 (ISDN) number for the PLMN 1 in ENUM query message. - SUA node sends an ENUM query message (1). This is routed over other ENUMs to the local ENUM of PLMN 1. - Local ENUM/DB in PLMN 1 receives the message (1) and looks up the services/protocols (including SUA- SG nodes IP address) corresponding to SAPC received in the ENUM query. - Local ENUM responds with message (2) with all servfices/protocols associated with SAPC of PLMN 1. - Message (2) is routed over the IP network to PLMN N. - PLMN N sends the SUA message (3) to PLMN 1 using the retrieved IP address of the SUA-SG node. - SUA-SG sends message (4) to SS7 network with destination PC. - SS7 network routes the message (5) to the appropriate PLMN. (3) SUA message sent to the SUASG node based on the destination IP address received - (1) ENUM (1) ENUM MAP CAP R IP ENUM SUA SUA NETWORK (1) (1) ENUM query message (SAPC= PLMN 1’s E.164 code) DB/ SG ENUM (2) IP address of the SUA SG (providing SS7 - support in PLMN 1) is sent back PLMN 1 (4) SG sends msg. using PC within the msg. SUA SUA R SS7 NETWORK DB/ (PLMN without SG) ENUM (5) SS7 network routes msg. PLMN N Figure 1: SS7 support services exampl (Point Code)Scenario 2: SAP (virtual IP addree) operation for load balancing and distributed processing (see figure 2) - Operational steps: - SUA proxy (SAP) node in PLMN N receives IMSI (registration request) from MS. - SAP node looks-up corresponding SAPC (E.164 number = 1-817-822-1999) in local DB/ENUM. - SAP node uses this as the unique E.164 (ISDN) number for the PLMN 1 in ENUM query message. - SAP node sends an ENUM query message (1). This is routed over other ENUMs to the local ENUM of PLMN 1. - Local ENUM/DB in PLMN 1 receives the message (1) and looks up the services/protocol (including SAP nodes virtual IP address) corresponding to SAPC received in the ENUM query. 3GPP
    • Release 5 69 3GPP TR 25.933 V5.4.0 (2003-12) - Local ENUM responds with message (2) with all services/protocols associated with SAPC of PLMN 1. Message (2) is routed over the IP network to PLMN N. - PLMN N sends the SUA message (3) to PLMN 1 using the retrieved IP address of the SAp node. - SUA Message (3) is routed over the IP network and received and terminated on SAP in PLMN 1. - SAP examines the SUA message (3) content and discovers the routing criterion (SSN, GT data type, data translation type, etc.) and finds the service applications (SUA) node based on type of GT data (E.212, E.214, E.164, PC, IP address or a host name), service type and range by performing the query to the mocal DB (AMF function). - SAP in PLMN 1 performs load balancing for the incoming SUA messages between multiple SUA nodes based on pre-defined criterion (e.g. based on registered ASPs serving m nodes) and sends the SUA messages and responses are directly sent to the same SUA node (AS-SUA) usong the received IP address in the CLDT- SUA response message and the SCTP association. - Incoming messages from the SS7 network are treated in the similar manner by SAP. See messages (5), (6) and (7). SUA SUA m 1 3 4 ENUM DB SAP1 R 7 2 IP NETWORK 6 ENUM SUA SIF SIF SUA n SG SG PLMN 1 1 3 5 SUA SUA m SS7 NETWORK R DB SAP N DB Local DB, DNS or ENUM (AMF) SIF SIF SUA SUA SG n SG SAP SS7/IP user Adaptation Proxy (SAP) function PLMN N SIF SS7 Inter working Function (SIF) - SUA SCCP User Adaptation Protocol (SUA) SS7 NETWORK Figure 2: Distibuted SUA architecture with load balancing6.8 AddressingThis study area is related to all addressing issues with regards to the introduction of IP Transport. For example, theadvantages of using IPv6 should be investigated. Also, addressing issues relating to inter-working with AAL2/ATMnodes should be considered.IPv6 has a 16 byte address field compared to 4 byte address field for IPv4. It is well known that the IPv4 public addressspace is running out, especially outside the U.S.6.8.1 General addressing requirements - IP addressing in UTRAN shall be logical and should not have any dependency on network element or interface type. 3GPP
    • Release 5 70 3GPP TR 25.933 V5.4.0 (2003-12) - In case of Ipv4, to ensure efficient usage of IPv4 addresses and routing efficiency, IP based RAN shall adopt classless IP addressing scheme, using Variable Length Subnet Masks (VLSM). - IP addressing in UTRAN scheme must support hierarchical routing network design and work well with the chosen routing protocol to provide best route convergence time in order to avoid network instability. - Where applicable, IP addressing in UTRAN must budget for multi-homing of network elements. - IP addressing in UTRAN must be scalable and take network element/interface growth and network expansion into consideration. - RAN IP Addressing scheme must be flexible and be suitable for different RAN sizes and topologies. - IP addressing in UTRAN must allocate addresses efficiently.In an IP based UTRAN it is necessary that every UTRAN Node gets at least one IP address. Even in an UTRAN withATM transport UTRAN Nodes will require IP addresses, e.g. for O&M functions. In fact there will be the situation thatthe most UTRAN nodes will have several IP addresses. Because of this reasons it is necessary to ensure that sufficientIP addresses are available. Especially when an operator decides to use public IP addresses for some UTRAN nodes, theavailability of sufficient number of IP addresses must be studied with respect to the bearer addressing scheme.If there is a private, isolated UTRAN network, then its possible that the IPv4 address space would be sufficient.However, if the UTRAN traffic is routed through a public network or a broader private network, then the IPv4 addressspace may not be sufficient. Using private addresses may require the use of a Network Address Translation (NAT)function when the UTRAN traffic must traverse a network using public addresses in order to translate public addressesto private when entering the private network. Private IPv4 addressing is a commonly used solution for extending theIPv4 address space.However, the use of NATs causes problems in the network. Some of these are: - It breaks the End-to-End Paradigm for Security when using IPSec. - UTRAN protocols use external signalling to exchange transport address and connection identifier information. An Application Level Gateway might be needed to take care of ensuring that the correct addresses are used for a session. When intermediate Application Level Gateways are used the performance is hurt and the delay is increased. - It adds costly manipulation on all packets. - It is a single Point of Failure. - It increases management and system configuration complexity.6.8.2 Bearer addressing solutions6.8.2.1 Destination IP addresses and destination UDP ports as connection identifiersDestination IP addresses and destination UDP ports are used for connection identification based on the followingassumptions:- UDP ports provide approximately 65,000 connection identifiers. It is acceptable to require the addition of an IP address to support additional 65,000 connections. Adding IP addresses is not a concern, particularly if IPv6 is used in IP UTRAN networks.- Using dynamic UDP ports means that a large range of UDP ports must be allowed through a firewall for the radio network application IP host. This can compromise the internal network if the host also supports other applications that use dynamic UDP ports.- The use of VPNs can be used to isolate the UDP ports used as connection identifiers from a firewall and can remove the need for a firewall in some cases.- Network Address Translators (NATs) can also cause problems when dynamic UDP ports are used since they change the address and possibly the UDP ports of packets. Only IPv6 could be used in the IP UTRAN network so 3GPP
    • Release 5 71 3GPP TR 25.933 V5.4.0 (2003-12) that NATs can be avoided or VPNs should be used such that NATs will not effect the IP address and UDP port used for the application.6.9 IP transport and routing architecture aspects6.9.1 Flexibility of IP architecturesWide deployment and cost effectiveness of IP infrastructure are major reasons for introducing IP as a transport option inUTRAN. Therefore the chosen architecture must take best benefit of IP technologies and infrastructure.Infrastructure transporting IP packets encompass a large variety of equipment like routers and switches, implementing awide range of functions (routing, switching, route discovery, tunnelling, load sharing, QoS handling etc). The flexibilitythat can be used to combine those equipment and functions are a major advantage of IP.It implies that several different architectures can be built with IP, which can adapt to various topologies and link layertechnologies. This flexibility brings both adaptability and competitiveness.That flexibility has to be considered, when defining higher layers for IP transport. No optimization should be madeaccording to a limited set of topologies or link layer technologies that could later restrict the competitive advantage ofIP.6.9.2 Hosts and routersBasically, the IP Transport Network is a set of nodes and links connecting Network Elements implementing UTRANfunctions (Node B, RNC, and Management Platform). That network is responsible for transporting user, control plane,data and O&M data between the Network Elements implementing UTRAN functions with some requirements(addressing, security, Quality of Service…).Several networks can fulfil these requirements. It relies on vendors, operators and third party service providers todetermine best implementations for the transport network.In an IP Transport Network, one can distinguish between end nodes (hosts) and intermediate nodes responsible forforwarding IP packets.Since standardization of IP transport option is intended to be layer 2 independent, in this study area, IP Transportarchitecture is limited to nodes implementing an IP layer.Nodes implementing an IP layer are either hosts, or routers. According to [8], the forwarding capability is the onlyfeature distinguishing routers from hosts.IP Hosting is a necessary function for a network element supporting of the UTRAN functions (Node B, RNC) but thesenetwork elements may also include transport network functions. Like AAL2 switching for ATM transport, IPforwarding and routing is not part of UTRAN functions. Routers connect networks of IP hosts to build internets. Hostsare not allowed to route packets they did not originate. 3GPP
    • Release 5 72 3GPP TR 25.933 V5.4.0 (2003-12) Router Network 1 1 Network 2 Network 3 Router 2 Figure 6-28: Routers interconnecting IP networksRouters forwarding IP packets in the transport network may have the following characteristics: - They can process user plane and control plane data at any layer lower or equal to IP. - They may process higher layer information for Transport Network O&M or configuration purpose.Other IP features may encompass tunnelling mechanisms (e.g. GRE, MPLS, L2TP, IPSec) or mechanisms requiringstorage of state information for every flow (e.g. RSVP). Such features, if too much specific or complex, should not berequired to be standard function of the transport network.In IP architecture, a host sees only routers directly accessible (without intermediate router). In most cases (no multi-homing), there is only one such router, named First Router in the Architecture. A node acting as a router may be a FirstRouter for other Node Bs.If the First Router is part of the IP network of routers, it is typically named Edge Router.In the special case when two UTRAn NEs are directly connected with a point-to-point link, taking no benefit of IPinfrastructure, no intermediate router exists between both UTRAn NEs. However there are still benefits for IP (e.g. noQAAL2). This case constitutes one very specific topology solution. RNC Edge Router Edge Node Router B IP Network of routers RNC Edge Router Node B Edge Node Node Router B B Figure 6-29: Example Architecture for IP Transport NetworkThe physical medium between one Node B and the first router is expected to be often bandwidth limited. 3GPP
    • Release 5 73 3GPP TR 25.933 V5.4.0 (2003-12)6.9.3 IPv6 aspectsThe UTRAN can be a very large network, with potentially thousands of end system hosts connected to a large routednetwork. If public IPv4 addresses are used in this network to begin with, the work is substantial to later reconfigure thisnetwork to IPv6, when the IPv4 address space is running out, or when the operator desires to move to using the IPv6protocol in all of his networks.If the network is a newly built closed intranet in the first release, it is quite easy to use IPv6 from the start, sinceinterworking with IPv4 nodes will not be needed in that case.6.9.3.1 Improved PerformanceThere is potential for improved performance when IPv6 is used. This is due to the following: 1) There are fewer header fields and optional headers compared to IPv4 (from 12 to 8) and the checksum in the IP header has been removed. 2) IPv6 header fields are better aligned. This also facilitates implementation in hardware. 3) Header compression can reduce the header size better than IPv4 under certain conditions.Network performance is improved due to the hierarchical address architecture.6.9.3.2 AutoconfigurationAddress Management is provided using Auto-configuration. This provides the following benefits: 1) Lower administrative cost. 2) Easier renumbering. 3) Easier Address Management.There are two address management schemes defined: 1) Stateful autoconfiguration using DHCPv6. This is also used with IPv4. Hosts obtain interface addresses and/or configuration information and parameters from a server. 2) Stateless autoconfiguration: Stateless autoconfiguration requires no manual configuration of host and no configuration of servers.Stateless and stateful autoconfiguration can complement each other. The stateless approach is suitable in the case wherethe exact addresses a host use is not a great concern. The stateful approach is suitable when tighter control over exactaddress assignments is required.6.9.3.3 IPv6 to IPv4 interworkingA wide range of techniques have been identified and implemented for IPv6/IPv4 interworking. They basically fall intothree categories: tunneling techniques, translation techniques, and dual stack techniques. - Tunnels can be used for routing packets between two IPv6 hosts via an IPv4 network by adding an IPv4 header to the IPv6 packet. - Translators are used for IPv6 to IPv4 interworking by translating the headers. - Dual stack techniques mean that IPv4 and IPv6 co-exist in the same host.It is likely that if an operator starts with an IPv4 UTRAN they will not change to IPv6 all at once by upgrading all IPUTRAN nodes to IPv6 at the same time. New nodes that are IPv6 capable will be added as the network grows. TheseIPv6 nodes must then interwork with the existing IPv4 UTRAN nodes and utilize the IPv4/IPv6 interworkingtechniques developed by the IETF. Particularly on the Iur, where full connectivity is required, interworking betweenIPv4 nodes and IPv6 nodes could require many more IPv4 addresses than the operator has left available. 3GPP
    • Release 5 74 3GPP TR 25.933 V5.4.0 (2003-12)Interworking techniques have disadvantages such that it is best to avoid using them if it is possible. Summaries of themain interworking techniques are provided in the following clauses.6.9.3.3.1 Network Address/Port Translators-Protocol Translators (NAPT-PT)The use of NATs for interworking between IPv4 hosts and IPv6 hosts has similar problems as using NATs with privateIPv4 addresses for extending the IPv4 address space.In the UTRAN, bearer control (exchange of IP address/UDP port) will be performed using signalling such that IPaddresses are included in the payload of signalling messages. The bearer control messages tell a UTRAN host whatdestination address to use to send data to the peer UTRAN host. An IPv4 host will not be able to use an IPv6 addressreceived from an IPv6 peer host. There must be an Application Level Gateway (ALG) that intercepts the bearer controlmessage and changes the transport parameters to the appropriate IP version. This must be done in coordination with theNAT so that the addresses in the traffic packets are changed according to the address put in the bearer control message.ALGs and NATs are undesirable. They add complexity and degrade performance. This technique also requires thatthere be a pool of IPv4 addresses available that the NAT can use to translate IPv6 addresses. In addition, the NAPT-PTprovides a single point of failure since all inbound and outbound traffic pertaining to a session must traverse the sameNAPT-PT router. This increases costs since the reliability must be high.The advantage of NAPT-PTs over other interworking techniques is that it allows more efficient use of IPv4 addresses.This is because one IPv4 address can be used for multiple IPv6 hosts by mapping IPv6 hosts to different UDP ports forthe same IPv4 address. Other interworking techniques require an IPv4 address be mapped to an IPv6 host. One keydisadvantage of NAPT-PTs is the need for ALGs.6.9.3.3.2 Stateless IP/ICMP Translation Algorithm (SIIT)SIIT provides a method for interworking that doesnt require ALGs. However, it does require that an IPv6 host must bedynamically assigned a temporary IPv4 address that is used for the time of the session. The IPv6 host provides the IPv4peer with the temporary IPv4 address using UTRAN bearer control. The IPv4 host uses this address for traffic packets.When the packets reach the SIIT router, the temporary IPv4 address is mapped to the IPv6 host address. The packet isthen tunnelled from the SIIT router to the IPv6 host.The IPv4 host provides the IPv6 host with an IPv4 address using UTRAN bearer control. For traffic, the IPv6 host mapsthis IPv4 address to an IPv6 address, which causes the packet to be routed to a SIIT router. The SIIT router willtranslate the mapped address back to the IPv4 address and forward it to the IPv4 host.The SIIT technique allows multiple SIIT routers in a network so it does not cause a single point of failure like with theNAPT-PT technique.This technique requires that the operator have a pool of IPv4 addresses available. It also requires that the traffic isrouted through a SIIT router and the IP headers are translated which can have an impact on performance.When an IPv4 address is assigned to an IPv6 node, its necessary for the SIIT routers to be provided the addressmapping between the assigned IPv4 address and the IPv6 address. This requires a protocol from the AIIH serverassigning the IPv4 address to the SIIT router. AIIH stands for "Assignment of IPv4 Addresses to IPv6 Hosts" and is aDHCPv6 server with extensions.6.9.3.3.3 Dual stackIt is also possible for new nodes to deploy a dual stack when migrating to IPv6. The IPv4 stack can be used toward anexisting IPv4 node and the IPv6 stack can be used toward IPv6 nodes.The dual stack mechanism was designed as one part of a "transition toolbox" to support a gradual introduction of IPv6into the existing IPv4 networks.The dual stack mechanism is defined in [30] as "a technique for providing complete support for both Internet protocols– IPv4 and IPv6 – in hosts and routers". Also in [30], it is stated that the dual stack mechanism is "the moststraightforward way for IPv6 nodes to remain compatible with IPv4-only nodes".A dual stack mechanism consists basically of the support for both IPv6 and IPv4 in the UTRAN IP nodes. However, asstated in [64], it is possible that a dual stack node (i.e. IPv6/IPv4 node) may operate, in IPv6-only or IPv4-only mode; aconfiguration switch may implement the selection of protocol version. This is very useful in the case of introducing 3GPP
    • Release 5 75 3GPP TR 25.933 V5.4.0 (2003-12)UTRAN IPv6/IPv4 nodes in IPv4-only networks and in the IPv6-only network scenarios. Although the Dual Stacktechnique, as described in [30], is enough to handle the migration from IPv4 to IPv6 networks, it is still possible to usethe dual stack approach in conjunction with tunneling mechanisms, as an option. This provides extra-flexibility in theconfiguration of the networks by the operators.Address configurationDual stack hosts also require that the operator have a pool of IPv4 addresses still available in order to assign one to thehost when it must communicate with an IPv4 host.Since the dual stack nodes support both protocols, IPv6/IPv4 nodes may be configured with both IPv4 and IPv6addresses, depending on the operation mode, i.e. if the node is in IPv4-only operation it requires only an IPv4 address,if the node is in IPv6-only operation it requires only an IPv6 address, and if the node is in IPv6/IPv4 operation, itrequires both IPv4 and IPv6 addresses.The IPv6/IPv4 nodes use IPv4 mechanisms (e.g. DHCP, manual configuration, etc) to acquire their IPv4 address andthe IPv6 mechanisms (e.g. stateless address autoconfiguration, manual configuration, etc) to obtain their IPv6 address.There are other mechanisms described in [30] to acquire IPv4-compatible IPv6 addresses for the case where automatictunneling is used by the IPv6/IPv4 nodes.It is also necessary to keep track of which UTRAN hosts use IPv4 and which use IPv6 in order to know which type ofaddress information to provide in the bearer control signalling.The only possible limitation that [30] envisages for the dual stack mechanism is that in the near future scenario all of thenodes connected to both IPv6/IPv4 network would require IPv4 public addresses. This can be a problem if the operatoris running out of IPv4 public addresses. However, note that the UTRAN does not require many IP addresses, so thatshould not be the case. Dynamic IPv4 address assignment may also be implemented by the use of a DHCPv6 server.However, for the UTRAN case it is not an issue, since: 1) the UTRAN networks are private networks, not accessible to the UEs, so there is no need to use public addresses, 2) CIDR techniques may provide enough granularity to address several UTRAN nodes with a class C group of addresses (this can depend largely on a case by case basis), and 3) in case there is a need to access the UTRAN node from the Internet, NAT mechanisms may be used to translate a public address to several private addresses. The implications and potential disadvantages of NAT should be considered however.DNSIn the Internet, the Domain Name Server (DNS) is used in both IPv4 and IPv6 to map between hostnames and IPaddresses. A new resource record type "A6" has been defined for IPv6 addresses in [29] with support for an earlierrecord named "AAAA". Since IPv6/IPv4 nodes shall be able to interoperate directly with both IPv4 nodes and IPv6nodes, they must provide resolver libraries capable of dealing with IPv4 "A" records as well as IPv6 "A6" and "AAAA"records. However, when a query locates an "A6/AAAA" record holding an IPv6 address, and an "A" record holding anIPv4 address, the resolver library may filter or order the results returned to the application in order to influence theversion of IP packets used to communicate with that node, i.e. return only the IPv6 address to the application, returnonly the IPv4 address or return both addresses. This decision is implementation dependent, however, theimplementation shall allow the application to control whether or not the filtering takes place.The DNS capability in the UTRAN transport is not needed, since all the nodes and functionalities are static (i.e. it doesnot follow the same model as the Internet, where the content of the application can be located in several places).However, as implementation dependent, it can be used for both dual stack and IPv6 only nodes.Complexity of dual stack implementation in comparison with IPv6-onlyThe term "dual stack" is somehow misleading because it is possible to misunderstand that this implies two separate HWand SW implementations in the node, one for IPv4 and one for IPv6, but as 0 states, "most implementations of IPv6does not offer two completely distinct TCP/IP stacks, one for IPv4 and one for IPv6, but a hybrid stack in which mostof the code is shared between the two protocol suites". 3GPP
    • Release 5 76 3GPP TR 25.933 V5.4.0 (2003-12)From an operator point of view, it is more complicated to connect IPv6-only nodes in IPv4-only transport network,since it would require the configuration and use of tunnels and the deployment of dual stack edge routers from thebeginning of the IP UTRAN IPv6-only nodes introduction, making the planning quite complex in comparison with thedual stack approach in the UTRAN nodes.6.9.3.4 TunnelingWhere there is only an IPv4 network available, IPv6 UTRAN traffic can be transported over the network usingunnelling. As shown in the following figure, this requires that only the first-hop routers be IPv6 capable. Techniqueshave been developed in the IETF to determine the appropriate tunnel endpoints. IPv6 IPv6 RNC IPv6 IPv4 IPv4 IPv6 RNC R R IPv4 NW R R Dual stack IPv4/IPv6 routerThe use of tunnelling will be common in the IP UTRAN anyway for various reasons including: 1) Multiplexing of small packets into larger packets using PPPMUX and tunnelling with L2TP. 2) Virtual Private Networking for security and quality of service control.Therefore, requiring tunnelling for transporting IPv6 packets over an IPv4 network is not a drawback.6.9.3.5 SummaryThere is a good case for using only IPv6 for IP UTRAN hosts: 1) There are advantages to deploying IPv6. 2) The UTRAN is a closed IP network in that UTRAN applications only communicate with each other, not to applications in other networks such as the Internet and so could be a good place to deploy IPv6. 3) There is a strong advantage to avoid IPv4/IPv6 transition techniques for UTRAN hosts since they add complexity and impact performance. They also require that an operator have a pool of IPv4 addresses available. 4) The disadvantage of using IPv6 is that, where only an IPv4 network exists, the IPv6 traffic must be tunnelled over it. However, tunnelling will commonly be used for other purposes anyway in the UTRAN transport network.It is true that other applications in a UTRAN node besides the UTRAN applications may need transition mechanismsbetween IPv6 and IPv4. An example of this would be an OAM application. The following scenarios are possible: 1) A client could be upgraded to IPv6 and must interwork with an existing IPv4 server in the operators network. These applications are not as sensitive to performance considerations as the UTRAN applications so the interworking mechanisms are not a problem. 2) The servers could be upgraded to IPv6 along with the clients. 3) The clients could be run on hosts different than those of the UTRAN applications and continue to use IPv4 to avoid the need for interworking.Also, the Release 99 / Release 4 Iu interface already supports IPv4. For this interface, a dual stack should be requiredthough it should be recommended that the Iu interface be upgraded to IPv6 when the IP UTRAN is deployed.Inter-working between IPv4 and IPv6 is possible and will have to be mastered by operators, like ISPs, and vendors.However, when this inter-working can be avoided, it simplifies the overall IP network management and configuration. 3GPP
    • Release 5 77 3GPP TR 25.933 V5.4.0 (2003-12)One case avoiding any interworking is to deploy new IP networks with IPv6 only, when new equipment has to beinstalled to build it. Reasons why the standard shall allow using IPv4 equipments, when they are available are: - since IP technology is a good solution to mix several applications on the same common infrastructure, re-use of existing IP networks shall be possible; - no specific feature of IPv6 is required by the RNL. No addressing shortage is expected when a private network is used for UTRAN; - allowing IPv4 makes IP Transport in UTRAN deployment independent from any IPv6 deployment.6.10 Backward compatibility with R99-R4/Coexistence with ATM nodesIt should be investigated how to inter-work the user plane between IP and AAL2/ATM interfaces including inter-working with a node that supports only AAL2/ATM interfaces, and how to interwork the control plane between IP andATM interfaces.6.10.1 GeneralAn IP UTRAN node should not be required to support AAL2/ATM UTRAN interfaces in order to interoperate withAAL2/ATM UTRAN nodes. The solution for interoperating between a UTRAN node with only IP interfaces and aRelease 99 / Release 4 and later AAL2/ATM UTRAN node should be performed only in the transport network layer(TNL) in order to maintain transport independence for the Radio Network Layer. The separation of RNL and TNL is anarchitectural principle in [1]. This means that the UTRAN RNL applications must not be affected nor should anyinterworking be required in the UTRAN RNL control plane or user plane when interworking between differenttransport technologies.As shown in figure 6-30 there are principally 3 cases (3-5) where interworking between IP and ATM nodes on Iub andIur is necessary. RNC RNC 5. RNC RNC ATM 1. ATM IP 2. IP 3. 4. 1. 2. NB NB ATM IP Figure 6-30: Interworking casesThe cases of interconnecting can be summarized as follows: - Iub/I–r – All A2 - Iub/I–r – All I3 - I–b – ATM RNC with IP Node4 - I–b – IP RNC with ATM Node B - I–r – IP RNC with ATM RNC.When an operator is migrating from ATM to IP, for example, a newly deployed UTRAN node should be allowed tosupport only IP interfaces and still be able to interwork with ATM UTRAN nodes. It should not be required to supportAAL2/ATM UTRAN interfaces in order to interoperate with AAL2/ATM UTRAN nodes. This is the case for thefollowing reasons 3GPP
    • Release 5 78 3GPP TR 25.933 V5.4.0 (2003-12)1. Otherwise, all Release 5 RNCs having connectivity with both ATm NEs and Ip NEs terminating RNL protocols would need to support both types of interfaces2. There may be manufacturers that want to supply only UTRAN nodes with one transport technology (such as IP- only nodes) but interwork with existing ATM nodes terminating RNL protocols in the operators network3. When an operator is migrating from ATM to IP, the newly deployed nodes would need to also support ATM interfaces to interwork with the legacy ATM nodes terminating RNL protocols. This means that the ATM network is being extended, which defeats the original purpose.6.10.2 Interworking OptionsA design goal for the IP transport option within Rel.5 is to minimize the effects on the RNL ([1], clause 5.2). The factthat an Release 99 / Release 4 node can be connected without having been upgraded to Rel.5 must be taken intoaccount.In the following three potential interworking options (dual stack operation, and TNL IWU) should be considered:6.10.2.1 Dual Stack operation within Rel.5 RNCsWithin the dual stack option a Rel.5 RNC must provide both stacks. Generally, it is assumed that only RNCs shouldprovide both types of interfaces, so that Node Bs are either IP or ATM nodes. Nevertheless, for interworking case 3,where an IP based Node B is connected with a Release 99 / Release 4 RNC, also an interworking on Iub would benecessary. Within a pure IP or ATM environment the RNC must only provide one type of interface. ATM IP RNL RNL A TNL T M TNL Figure 6-31: Dual Stack operation within Rel.5 RNCsA Rel.5 IP node that needs to communicate with a pure ATM node (R99 or later) requires the complete ATM/AAL2protocol stack. Beneficial of such an dual stack solution is, that it does not require a TNL control protocol on IP side.On Iub this solution would be quit sufficient, but on Iur there may be certain cases where a simple IWF or dual stackoperation are not sufficient and an interworking unit (IWU) will be needed. (If interworking case 3 and 4 should besupported, also on Iub an IWU would be needed.) Iur Iur RNC ATM RNC IP RNC R99 R4 R4 Figure 6-32: Full Meshed IurIn the network, that is shown in figure 6-32, are some RNCs pure IP based, some RNCs are pure ATM based and someRNCs are dual stacked. Assuming a network configuration where a pure IP based RNS borders on a pure ATM basedRNS, the Iur interface between both RNSs must be supported.A dual stacked RNC with an IWF in the middle would be able to communicate on both networks but would not be ableto combine both parts of the network. In that case either an interworking unit is needed or a solution to transport ATM- 3GPP
    • Release 5 79 3GPP TR 25.933 V5.4.0 (2003-12)traffic through the IP-backbone. Such a solution, based on Pseudo-Wire Emulation Edge to Edge (PWE3) [70] [71], isprovided in the next paragraph.6.10.2.1.1 Interworking with PWE3-capable ATM SwitchA PE node as defined in [71], an ATM switch equipped with interfaces to both the ATM and the IP network, connectsthe ATM and the IP-backbone. The PE-node acts as a PWE-capable node towards the IP-backbone and establishes atunnel with the RNC-with PWE3 for interconnection with the RNC-R99.RNC-with PWE3 communicates with RNC-R99 via its AAL2/AAL5 protocol stack on top of PWE3 layer over thePWE3 tunnel through the IP-backbone. The PWE3 tunnel terminates in the PE-node, from where plain ATM-traffic isforwarded to RNC-R99 over the ATM-backbone w/o termination of the Adaptation Layer. All planes (Control planedesignated as xxAP in the figure Transport Network Control Plane (Q2630) and user plane (designated as Vc/Dt in thefigure) shall be carried over PWE3.The TNL Control Plane protocol used in this solution is thus the ALCAP Q2630 tunnelled over PWE3 used as layer 1.A PE-node relays the Q2630 messages encapsulated in SS7/AAL5 like any other ATM switch that is potentially placedin the transport network between the PWE-capable RNC and the next adjacent node terminating the Q2630 stack.Similarly, a PE-node relays the User Plane messages encapsulated in AAL2/ATM like any other ATM switch that ispotentially placed in the transport network between the PWE-capable RNC and the next adjacent node terminating theQ2630 stack. RNC P E- RNC R99 A TM-Back b o n e n o de IP-Back bo n e with P WE3 Vc/Dt Vc/Dt FP Q2 6 3 0 Q2 6 3 0 FP AAL2 AAL5 AAL5 AAL2 ATM ATM ATM ATM P WE3 P WE3 Lay er 1 Lay er 1 Tu n n el Tu n n el IP IP L2 /L1 L2 /L1 Figure 6-32a: Interworking with a PWE3-capable ATM SwitchA PE-node relays also the xxAP Control Plane messages encapsulated in AAL5/ATM like any other ATM switch thatis potentially placed in the transport network between the PWE-capable RNC and the ATM RNC. 3GPP
    • Release 5 80 3GPP TR 25.933 V5.4.0 (2003-12) P E- RN C R99 ATM -Backbone no e d IP-Backbone RN C w th i PWE 3 xx A x P xx A x P AAL5 AAL5 ATM ATM ATM ATM P WE 3 P WE3 Lay er1 Lay er1 Tu n el n Tu n el n IP IP L2 / 1 L L2 / 1 L Figure 6-32b: Interworking with a PWE3-capable ATM SwitchThe three options of PWE3 tunneling protocol [71] over IP networks can be done either directly over IP layer or overL2TP [38] or MPLS.The following figure shows the protocol stack at the RNC/CN-node, in the case the RNC/CN-node cannot be connectedto the ATM backbone and implements PWE3. ATM PWE3 ffs IPv6 (RFC 2460) L2TP MPLS IPv6 (RFC 2460) IPv4 optional (RFC 791) IPv4 optional (RFC 791) IPv6 (RFC 2460) IPv4 optional (RFC 791) Data Link Layer Physical Layer Figure 6-32c: Bearer for Control plane (RANAP), Transport Network control plane (ALCAP) and user plane with PWE3 tunneling protocol.The method(s) to be used for encapsulation of ATM cells, namely, One-to-one mode and N-to-one mode, is(are) FFS.The transport service to be used, namely the ATM VCC Cell Transport Service or the ATM VPC Cell TransportService, is FFS.The use of the ATM AAL5 CPCS-SDU and AAL5 PDU frame modes is not required.The signalling flows corresponding to this ATM-IP interworking method are presented in section 6.10.5.5.6.10.2.2 Transport Network Layer IWUAlso an TNL IWU can either be placed somewhere between the connecting nodes or can be integrated within one node. 3GPP
    • Release 5 81 3GPP TR 25.933 V5.4.0 (2003-12) ATM IP IWU RNL RNL A TNL T IP TNL M Figure 6-33: Transport Network Layer IWUOn transport network layer the IWU must support the translation between ATM and IP transport formats and QoSrequirements. It must hold all states of active connections.Although it is conceivable that a pure IP TNL could work without a TNL control protocol a simple TNL IWU wouldprobably require a TNL control protocol. At least this depends on the agreed addressing scheme for the IP transport.6.10.2.2.1 Issue on TNL IWU control protocolThe following two figures show an example of a radio link setup request on Iur between an Release 99 / Release 4 andRel.5 IP RNC. The first example, where the SRNC is a Release 99 / Release 4 and the DRNC is a Rel.5 IP RNC, avoidsthe usage of an TNL control protocol due to an appropriate choice of the binding ID and transport layer address withinthe RNSAP messages. In the second example, where the SRNC is a Rel.5 IP and the DRNC is a Release 99 / Release 4RNC, the usage of a TNL control protocol is unavoidable.Figures 6-34 and 6-35 show the relevant information exchange on RNSAP and the involved primitives and messages ofthe AAL2 signalling protocol regarding [2] for each example.In the first example the Release 99 / Release 4 SRNC requests a radio link setup. The Rel.5 DRNC RNL requests fromits TNL resources for the new connection and receives an appropriate transport layer address and a binding ID. Forexample, the BID would be the UDP port, where the TNL is waiting for the new connection, and the transport layeraddress (TLA) would be a the code point (CP) that terminates at the IWU and identifies the DRNC. Therefore the Rel.5TNL must have the knowledge that it is communicating with an ATM node. It provides an CP instead of an IP addressand encodes the necessary information in a way that allows the IWU to establish the IP path later on. Within the radiolink setup response message the UDP port number can be transported within the binding ID. Both informations, TLAand BID, are transmitted via ALCAP to the IWU. The IWU maps code points to IP addresses and extracts the portnumber out of served user generated reference (SUGR). The mapping between code points and IP addresses must beconfigured by O&M within the IWU and within the TNL of the IP node. The IWU is than able to establish a UDPconnection and to complete the ALCAP connection setup. Some ATM specific informations like the link characteristicsget either lost or translated into an IP equivalent IE.Failure behaviour is FFS. 3GPP
    • Release 5 82 3GPP TR 25.933 V5.4.0 (2003-12) 1. RL SETUP REQUEST RNL 2.3 RL SETUP RESPONSE(BID, TLA) RNL SRNC DRNC (BID=e.g.UDP-Port/ Flow Label, TLA=CP) (SUGR=BID) 6. CP -> IP- Adr. 2.1 REQ new connection SUGR -> Port/Label 3. ESTABLISH REQ 2.2 (TLA / BID) (SUGR) 5. EST. IND (SUGR) 9. EST. CONF. 7. EST. RESP 4. ERQ(SUGR) A TNL T IP TNL ATM 8. ECF M IP R99 R4 Figure 6-34: Example 1: RNSAP: DCH RL Setup, SRNC = R99/R4; DRNC = Rel.5 NOTE: In this case the IWU must always send data to the DRNC before the DRNC can transmit data towards the SRNC because the DRNC does not know to which IP address/UDP port to send data before receiving this first data.In the case where the Rel.5 IP RNC requests a radio link setup from the Release 99 / Release 4 RNC, the Release 99 /Release 4 RNC is not aware of the fact that it is communicating with an IP node. Beside, it must choose the binding IDcompletely free (e.g. without the knowledge what ports are free on the IWU or the IP RNC). The Rel.5 SRNC can mapthe TLA to an appropriate IP address but it can not map the binding ID to an appropriate UDP port number. Trying tomap the binding ID to the port numbers results either in assigning a large number of IP addresses to both, the IP RNCand the IWU, or restricting the binding ID space within the Release 99 / Release 4 RNCs. Even if a trade off betweennumbers of needed IP addresses and restrictions of the binding ID space could be found, information like the linkcharacteristics that cant be generated within the IWU itself must be transmitted somehow to the IWU. For that purposea TNL control protocol also on the IP side of the connection is necessary. 1 . RL SETU P REQ U EST RN L RN L 2.1 RL SETU P RESPO N SE(BID , TLA) D RN C SRN C M ap p ing: BID -> Po rt / Lab e l 5. EST. IN D 2.2 REQ So ck / Lab e l 3.a „ ESTABLISH 2 .3 (Po rt / Lab e l) REQ “ 3.b ESTABLISH REQ 8.b „ EST. C O N F“ 6. EST. RESP. TN L control 8.a EST. C O N F protocol 4. ERQ TN L A TN L T IP ATM 7. EC F IP M R99 R4 Figure 6-35: Example 2: RNSAP: DCH RL Setup, DRNC = R99/R4; SRNC = Rel.5 3GPP
    • Release 5 83 3GPP TR 25.933 V5.4.0 (2003-12)Candidates for this IP -based TNL control protocol (IP-ALCAP) are described in sections 6.10.5.1 to 6.10.5.4.6.10.3 Conclusion It must be clarified if an interworking on Iub (interworking case 3 and 4) should be supported or if an dual stack operation is sufficient for the Iub interface. For the Iur interface, when the IP RNC has no access to the ATM network, either: - an IWU is needed, -which is either integrated within the IP RNC or in an independent box- - or alternatively, a PWE3 tunnel protocol can be used between the IP RNC and an ATM switch used in the transport network to make a tunnel towards the ATM RNC. An IWU that works only on TNL requires a TNL control protocol that must be specified within the standard. The solutions using such an independent IWU and a dedicated IP-based TNL Control Protocol are presented in section 6.10.5.1 to 6.10.5.4. The solution using the ATM switch with the PWE3 tunnel protocol is presented in 6.10.5.5.6.10.4 UTRAN Architecture considerationsThe following figures show the Iur interface where an IP UTRAN node is introduced. They are shown as interworkingexamples for the purpose of this discussion. In figure 6-36, a Release 99 / Release 4 SRNC is shown with an Iurinterface to an IP DRNC. In figure 6-37, an IP SRNC is shown with an Iur interface to a Release 99 / Release 4 DRNC. R99 SRNC Iur IP DRNC Control plane (RNL) SRNC RNSAP CP CP User plane (RNL) Iur FP SRNS UP UP Control plane (TNL) q.aal2 q.aal2 ??? ??? AAL2/ATM IP ???/ ???/ AAL2/ AAL2/ UDP User plane (TNL) ATM ATM /IP UDP/ IP TL IW Figure 6-36: Transport network layer interworking with Release 99/ Release 4 SRNC 3GPP
    • Release 5 84 3GPP TR 25.933 V5.4.0 (2003-12) IP SRNC Iur R99 DRNC Control plane (RNL) SRNC RNSAP CP CP User plane (RNL) Iur FP SRNS UP UP Control plane (TNL) ??? ??? q.aal2 q.aal2 IP AAL2/ATM ???/ ???/ UDP/ AAL2/ AAL2/ User plane (TNL) UDP /IP ATM ATM IP TL IW Figure 6-37: Transport network layer interworking with IP SRNCThese figures show the separation between the RNL control plane, the RNL user plane, the TNL control plane, and theTNL user plane. The IP protocols and the need for a TNL control plane protocol in the IP domain are yet to bedetermined so they are shown with question marks.The following statements concerning interworking can be made based on the discussion and examples above: 1) IP and AAL2/ATM UTRAN nodes use different address and flow identification types. The appropriate types must be provided to the appropriate nodes when establishing a transport bearer. 2) A Release 99 / Release 4 SRNC will initiate q.aal2 connection signalling and expect a response when establishing a transport bearer. 3) A Release 99 / Release 4 DRNC will expect to receive q.aal2 connection signalling when a transport bearer is being established by the SRNC. 4) A transport network interworking function is required in the transport network. This function could be implemented in a third node with both IP and AAL2/ATM interfaces, for example.6.10.5 ATM/IP Interworking solution proposalsThis section describes the signalling flow for several candidate solutions enabling an IP node to interwork with a legacyATM node. It first describes in subsections 6.10.5.1 to 6.10.5.4 the signalling flow for the candidate solutions based on the thirdinterworking option i.e. solutions using a TNL IWU as presented in section 6.10.2.2.Then in section 6.10.5.5, it presents the signalling flow for the interworking solution based on a PWE3-capable ATMswitch that fulfils the same requirement.6.10.5.1 Bearer control proposal using IETF SIP/SDPFor exchanging transport layer information between IP UTRAN nodes, the RNL signalling should be used (RANAP,RNSAP, NBAP) without a Transport Network Control Protocol.For establishing transport connections between an IP UTRAN node and an ATM UTRAN node, a Transport NetworkLayer interworking function should be used in the transport network. This function would be implemented in a thirdnode (such as an RNC) that has both ATM and IP interfaces.In order to interwork with the q.aal2 signalling used by the AAL2/ATM node, an IP ALCAP will be used. 3GPP
    • Release 5 85 3GPP TR 25.933 V5.4.0 (2003-12)6.10.5.1.1 DescriptionIt is proposed to use Session Initiation Protocol (SIP) signalling with Session Description Protocol (SDP) parameters.SDP [58] supports both IP and ATM parameters. SIP [57] is proposed since it is an IETF signalling protocol and is usedto carry SDP.Since a node must know what type of interface to communicate with, a Network Type parameter should be added to theRNL signalling. The following table shows how the Network Type parameter is used. R99/R4 R5 IP R5 ATM Action SRNC DRNC R5 DRNC knows the SRNC is Release 99 / Release 4 because of missing transport parameters in RL setup req. R5 IP RNC does interworking steps. DRNC SRNC SRNC sends IP transport parameters that Release 99 / Release 4 DRNC will ignore. SRNC must know that it is receiving ATM parameters. Absence of network type in response will indicate that it is Release 99 / Release 4. R5 IP RNC does interworking steps. SRNC DRNC R5 DRNC knows SRNC is Release 99 / Release 4 because of missing transport parameters in RL setup req. DRNC SRNC SRNC sends ATM network type parameter that Release 99 / Release 4 DRNC will ignore. SRNC must know that it is receiving ATM parameters from DRNC. Absence of network type will indicate that it is Release 99 / Release 4. SRNC DRNC SRNC sends IP transport parameters. SRNC must know that it is receiving ATM parameters. It can know this from the network type parameter in DRNC response. SRNC then performs interworking steps. DRNC SRNC SRNC sends ATM network type. R5 DRNC knows its ATM from the network type and performs interworking steps.6.10.5.1.2 Bearer control between IP and ATM nodes signalling examplesThe following figures provide signalling diagrams that show how the interworking can be achieved with this proposal.The Iur is shown as an example. UDP ports are shown for connection identifiers as an example. Rel ‘ 99 Rel 4 IP SRNC GW DRNC Radio Link Setup Req () Radio Link Setup Resp [AAL2 address (Aal2D1), SUGR (BIDD1), NetType ] Aal2D1-> Est Req [VCC/CID1, Aal2D1, IPD1 Aal2D1/ ALC, BIDD1, SSCS] Invite Request [IPGW1, UdpGW1, BIDD1] IPD1 BIDD1 Est Conf [] Response [IPD2, UdpD1] IPD2 UdpD1 IPGW1 UdpGW1 Radio Link Release (...) Release Req [Cause] Bye Request [ ] Release Conf [] Response [ ] Figure 6-38: Interworking between an AA2/ATM SRNC and an IP DRNC NOTE 1: The Release 99 / Release 4 SRNC sends radio link setup. There is an SCTP Signalling Gateway for interworking the SCTP/IP signalling to ATM signalling. 3GPP
    • Release 5 86 3GPP TR 25.933 V5.4.0 (2003-12) NOTE 2: The IP DRNC node responds with ATM transport parameters. The IP DRNC must have both ATM and IP addresses assigned to it. NOTE 3: The SRNC uses q.aal2 signalling to establish a connection towards the DRNC based on the address received in the RL Setup Response. The TNL IW node is along the route to the DRNC. NOTE 4: When the TNL IW function receives the q.aal2 set up message it determines that the destination node is an IP node. NOTE 5: The TNL IW function translates the ATM address to the IP address for the DRNC and sends a SIP Invite message to the IP DRNC. The Invite message includes the IP address and UDP port for traffic toward the TNL IW node. Also included is the binding ID so that the DRNC can correlate the transport signalling with the RNL signalling. NOTE 6: The IP DRNC responds to the Invite message. Included in the response message is the IP address and UDP port for traffic towards the IP DRNC. NOTE 7: When the TNL IW node receives the Response message it sends the q.aal2 confirmation message to the ATM SRNC. NOTE 8: To release the connection, the SRNC sends a q.aal2 Release Request. NOTE 9: When the TNL IW function receives the request it sends a SIP Bye Request to the IP DRNC. NOTE 10:The IP DRNC responds to the Bye Request and when the TNL IW function receives it, it sends the q.aal2 Release Confirm. Rel 4 IP TNL IW Rel ‘99 SRNC DRNC Radio Link Setup Req (IPS1, UdpS1, NetType) Radio Link Setup Resp [AAL2 address (Aal2D1), SUGR (BIDD1)] Invite Request [IPS1, UdpS1, Est Req [VCC/CID1, Aal2D1, Aal2D1, ALC , BIDD1, SSCS] ALC, BIDD1, SSCS] Aal2D1 Est Conf () BIDD1 Response [IPGW1, UdpGW1] IPGW1 UdpGW1 IPS1 UdpS1 Radio Link Release (...) Bye Request [ ] Release Req [Cause,] Response [ ] Release Conf () Figure 6-39: Interworking between an AA2/ATM SRNC and an IP DRNC NOTE 11:The rel 4 SRNC sends radio link setup. An SCTP Signalling Gateway is used for interworking the SCTP/IP signalling and ATM signalling. The Setup message includes IP address, UDP port, and network type that will be ignored by the Release 99 / Release 4 DRNC. NOTE 12:The ATM DRNC node responds with the ATM transport parameters. NOTE 13:The SRNC sends a SIP Invite message to the TNL IW node. It includes the IP address and UDP port to be used for traffic towards itself. It also includes the ATM parameters received from the ATM DRNC so that the TNL IW function can establish an AAL2 connection with the ATM DRNC. 3GPP
    • Release 5 87 3GPP TR 25.933 V5.4.0 (2003-12) NOTE 14:The TNL IW function initiates a q.aal2 establish request based on the parameters received from the SRNC. NOTE 15:The ATM DRNC responds to the q.aal2 establish message. NOTE 16:When the TNL IW node receives the establish confirm message is sends a SIP response message to the IP SRNC. The response includes the IP address and UDP port used for traffic towards itself. NOTE 17:To release the connection, the SRNC sends a SIP Bye Request. NOTE 18:When the TNL IW function receives the request it sends a q.aal2 Release Request to the ATM DRNC. NOTE 19:The ATM DRNC responds to the Release Request. NOTE 20:When the TNL IW function receives it, it sends SIP response.6.10.5.1.3 Use of SIP for Interworking between UTRAN ATM interfaces and UTRAN IP interfaces6.10.5.1.3.1 Description6.10.5.1.3.1.1 Inter Working Problem Summary It is required that interworking be possible between an IP UTRAN node (or MSC) that does not have any ATM interfaces and an ATM UTRAN node (or MSC). The motivations for this requirement are described in clause 5 of the present document.6.10.5.1.3.1.2 Approach/AimsThe solution to the Interworking requirement should be such that there is a minimum set of requirements placed on theIP node. The IP node should as much as possible be able to act as if it is talking to another IP node. A SignallingGateway is assumed for interworking the SCTP/IP signalling to ATM signalling.The TNL-IWF should receive either an Q.AAL2 establish request or an SIP Invite request message and be able togenerate the other message based on the information that is in the message and a table of associations. The IP nodeshould not need to make any ATM configuration decisions. Any ATM (AAL2) configuration should be done by theTNL-IWF.6.10.5.1.3.1.3 Using SIP as a Transport Bearer Signalling ProtocolSIP 0 is a protocol that is specifically designed for the establishment of IP sessions for many different types ofapplications. It is an IETF protocol developed by the MMUSIC working group for creating, modifying and terminatingsessions. SIP invitations contain session descriptions that allow participants to agree on a set of compatible sessionparameters. The session descriptions are described using SDP 0.SIP has scope for much more functionality than isrequired here, and is aimed for use as a multimedia session control protocol. However, a basic implementation of SIP,carefully defined so as to unambiguously describe the usage of the protocol for this application would meet therequirements for an IP ALCAP.6.10.5.1.3.1.4 ImplementationCompliance with SIP places some requirements on the TNL-IWF and the communication between the TNL-IWF andthe IP UTRAN (or MSC) Node.6.10.5.1.3.1.4.1 ACK messageIn addition to the Invite request and Response messages, an ACK message is required by SIP to confirm the session. Inclause 6.5 of [1] there should be an ACK message after receipt of the SIP response message for figures 30 and 31. TheACK message should always be in the same direction as the original Invite Request message.The corrected diagrams and associated description are shown below: 3GPP
    • Release 5 88 3GPP TR 25.933 V5.4.0 (2003-12) Rel ‘99 Rel 5 IP SRNC IWF DRNC Radio Link Setup () Radio Link Setup [AAL2 address (Aal2D1), SUGR (BIDD1)] Aal2D1-> IPD1 Aal2D1/ Est Req [VCC/CID1, Aal2D1, ALC, BIDD1, IPD1 SSCS] Invite Request [IPIWF1, UdpIWF1, BIDD1] BIDD1 Est Conf [] Response [StatusCode,IPD2, UdpD1] ACK IPD2 UdpD1 IPIWF1 Radio Link Release (...) UdpIWF1 Release Req [Cause] Bye Request [ ] Release Indication [ ] Response [ ] Figure 6-40: Interworking between an AAL2/ATM SRNC and an IP DRNC NOTE 1: The Release 99 / Release 4 SRNC sends radio link setup. There is an SCTP Signalling Gateway for interworking the SCTP/IP signalling to ATM signalling. NOTE 2: The IP DRNC node responds with ATM transport parameters. The IP DRNC must have both ATM and IP addresses assigned to it. NOTE 3: The SRNC uses q.aal2 signalling to establish a connection towards the DRNC based on the address received in the RL Setup Response. The TNL IWF is along the route to the DRNC. NOTE 4: When the TNL IWF receives the q.aal2 set up message it determines that the destination node is an IP node. NOTE 5: The TNL IWF translates the ATM address to the IP address for the DRNC and sends a SIP Invite message to the IP DRNC. The Invite message includes the IP address and UDP port for traffic toward the TNL IWF. Also included is the binding ID so that the DRNC can correlate the transport signalling with the RNL signalling. NOTE 6: The IP DRNC responds to the Invite message. Included in the response message is the IP address and UDP port for traffic towards the IP DRNC. NOTE 7: When the TNL IWF receives the Response message it sends the q.aal2 confirmation message to the ATM SRNC. It also sends an SIP ACK message to confirm the IP bearer connection. NOTE 8: To release the connection, the SRNC sends a q.aal2 Release Request. NOTE 9: When the TNL IWFreceives the request it sends a SIP Bye Request to the IP DRNC. NOTE 10:The IP DRNC responds to the Bye Request and when the TNL IWF receives it, it sends the q.aal2 Release Confirm. 3GPP
    • Release 5 89 3GPP TR 25.933 V5.4.0 (2003-12) Rel 5 IP Rel ‘99 SRNC IWF DRNC Radio Link Setup (IP) Radio Link Setup [AAL2 address (Aal2D1), SUGR (BIDD1)] Invite Request [IPS1, UdpS1, Aal2D1, BIDD1] Est Req [VCC/CID1, Aal2D1, ALC, Aal2D1 BIDD1, SSCS] BIDD1 Est Conf () Response [StatusCode, IPIWF1, UdpIWF1] ACK IPIWF1 UdpIWF1 IPS1 UdpS1 Radio Link Release (...) Bye Request [ ] Release Req [Cause] Release Indication (Cause) Response [ ] Figure 6-41: Interworking between an AAL2/ATM SRNC and an IP DRNC NOTE 11:The rel 5 IP SRNC sends radio link setup. An SCTP Signalling Gateway is used for interworking the SCTP/IP signalling and ATM signalling. The Setup message includes IP address, UDP port, and network type that will be ignored by the Release 99 / Release 4 DRNC. NOTE 12:The ATM DRNC node responds with the ATM transport parameters. NOTE 13:The SRNC sends a SIP Invite message to the TNL IWF. It includes the IP address and UDP port to be used for traffic towards itself. It also includes the ATM parameters received from the ATM DRNC so that the TNL IWF can establish an AAL2 connection with the ATM DRNC. NOTE 14:The TNL IWF initiates a q.aal2 establish request based on the parameters received from the SRNC. NOTE 15:The ATM DRNC responds to the q.aal2 establish message. NOTE 16:When the TNL IWF receives the establish confirm message is sends a SIP response message to the IP SRNC. The response includes the IP address and UDP port used for traffic towards itself. The IP SRNC then confirms with an SIP ACK message. NOTE 17:To release the connection, the SRNC sends a SIP Bye Request. NOTE 18:When the TNL IWF receives the request it sends a q.aal2 Release Request to the ATM DRNC. NOTE 19:The ATM DRNC responds to the Release Request. NOTE 20:When the TNL IWF receives it, it sends the SIP response.6.10.5.1.3.1.4.2 Communication of endpoint information and session identificationThe signalling shown in clause 6.10.5.1.3.1.4.1 shows the SIP Invite Request message being used to pass certainparameters. These parameters are required to indicate the endpoints of the session being established. The followingclauses define the use of the SIP fields and SDP parameters to be used in these SIP messages. 3GPP
    • Release 5 90 3GPP TR 25.933 V5.4.0 (2003-12)6.10.5.1.3.1.4.2.1 SIP header fieldsSIP messages are structured in a HTTP like way as defined in the SIP RFC [57] with a number of mandatory andoptional fields. The mandatory fields (ie; they must be present in a SIP message) are: SIP header Contains Use in UTRAN Allow: 1#Method only required in a 405 response message Call-ID: <session identifier> The binding id is communicated here Contact: "sip:" <username>@<host> [ ":" Username=source E164 address <port> ] Host = src IP address or domain name Port = source SCTP port Content length: <length in octets> Length in octets of the message Content Type: <media-type> "application/sdp" Cseq: <sequence number> <method> Sequence number < 2**31 Eg: Cseq: 4711 INVITE From: "sip:" <username>@<host> [ ":" Username=source E164 address <port> ] Host = src IP address or domain name Port = source SCTP port To: "sip:" <username>@<host> [ ":" Username= destination E164 <port> ] address Host = destination IP address or domain name Port = destination SCTP port Via: <protocol-sent> <source ip> ":" Protocol-sent="SIP2.0/SCTP" <port> Source ip = src IP address Port = src port addressThe Call-Id along with the From and To fields constitutes a Call leg.Other fields are optional and should not be mandated for the UTRAN application.6.10.5.1.3.1.4.2.2 SDP parametersThe following SDP parameters are mandatory (must be present) as according to RFC 2327. - V – version of SDP. This should be set to zero. - O – this information represents the identity of the sender of the message. Username is left as "-" when the concept of users is not supported by the application. The session id needs to be a globally unique identifier that can be generated by any mechanism(ie random number, network time protocol, etc). For the UTRAN, this value will be set to the Binding ID received via the RN protocol(ie RNSAP/NBAP/RANAP). Version here refers to the version of the message and must be incremented each time(recommendation is to use an NTP timestamp). The network type is IN for internet and the address type is IP6 or IP4. The Address is the origins address. - S – this is an arbitrary string to associate with the session. - T – this is the time of the session. With the stop time set to zero indicates that the session is not bounded. The start time must be specified however (otherwise the session is regarded as permanent). - E – email address. The email address of the source (Inviter). Either this field or the p field (phone number) MUST be sent to comply with the SDP protocol. This field may be used to send the same information as the "contact" field in the SIP header.All other SDP parameters are optional according to [58]. The following parameters however are required and defined asfollows for the UTRAN application of the SIP protocol as an IP ALCAP. 1) C=IN IP6 <src IP6address> or, for Ipv4 option: c= IN IP4 <srcIP4address> 2) this is information associated with the connection. Essentially it is a description of the network layer address that must be used to send data to. 3GPP
    • Release 5 91 3GPP TR 25.933 V5.4.0 (2003-12)M= application <udpport> udp/<IuxFP> <value> 3) describes the media used for the session and provides the transport address. For this application, the media is an "application", will use a udp port assigned by the sender of the message, a transport protocol field (either IuFP, IurFP or IubFP) and a fmt type must be chosen. Values 96 – 127 are user definable for fmt type.A=fmtp: <value> <parameters> 4) zero or more media attribute lines. This attribute is the main mechanism available in SDP to allow the extension of SDP and the tailoring of its use for particular applications. <value> should match with <value> in the m= line. <parameters> can be used to convey information describing the format of the media. In the case of the UTRAN application, this is proposed to convey some of the service requirements of the payload. This will consist of nine parameters as follows: - maximum FP-DU size(Framing Protocol Data Unit packet size including FP headers); - average FP-DU size; - maximum bit rate; - average bit rate; - path TYpe.These parameters are calculated based on the requirements of the RNL on the TNL as specified in the 3GPPspecifications for the RNL and must be given for both uplink and downlink. The actual format of this message for theUTRAN application is:a=fmtp: <value> MaxSizeUp AvSizeUp MaxRateUp AvRateUp MaxSizeDn AvSizeDn MaxRateDn AvRateDn,PathTypewhere <value> is as previously defined and: MaxSizeUp Maximum FP-DU size for the uplink. AvSizeUp Average FP- DU size for the uplink MaxRateUp Maximum Bitrate for the uplink AvRateUp Average Bitrate for the uplink MaxSizeDn Maximum FP-DU size for the downlink AvSizeDn Average FP- DU size for the downlink MaxRateDn Maximum Bitrate for the downlink AvRateDn Average Bitrate for the downlink Path Type Path Type6.10.5.1.3.1.4.2.3 Example messageAn example SIP Invite request could be represented as the following:INVITE sip: A2EA2@Iputrannode2.operator.netVia: SIP/2.0/SCTP 194.237.226.242:5062From: sip: A2EA1@iwf1.operator.netTo: sip: A2EA2@Iputrannode2.operator.netCall-ID: <BIDD1>CSeq: 1 INVITEContact: sip: A2EA1@iwf1.operator.net:5062Content-type: application/sdpContent-length: 141 3GPP
    • Release 5 92 3GPP TR 25.933 V5.4.0 (2003-12)v=0o= - <bidd1> 924526776692 IN IP4 194.237.226.242s= -e= A2EA1@iwf1.operator.netc=IN IP4 194.237.226.242t=76554467889 0m=app 7094 UDP/IubFP 96 a= fmtp: 96 41 38 16400 8550 41 38 16400 8550 where: A2EA1 = E164 address of the ATM node A2EA2 = E164 address of the IP node BIDD1 = Session Identifier communicated in RANAP(Binding ID) 194.237.226.242 = IP address of the IWF iwf1.operator.net = domain name of the IWF Iputrannode2.operator.net = domain name of the IP R5 node6.10.5.2 Bearer Control proposal using a new protocol (“Q.IP-ALCAP”), optimised for concatenation with AAL Type 2 linksThe discussion of the TNL interworking functionality in clauses 6.10.2.2 and 6.10.4 shows that a transport networklayer interworking functionality (TNL IWU) is needed as well as a signalling protocol for bearer control (IP-ALCAP).A standardized transport network control protocol is beneficial to operators that have multi-vendor environments andone interworking function may be used by several RNCs, although they are from different vendors.Also from the discussion in 6.10.2.2 and 6.10.4, it becomes clear that the interworking functionality is part of the TNL.According to the principles of 3GPP and in particular RAN WG3, specification of new TNL protocols shouldpreferably be done within other groups, e.g. IETF or ITU-T.As depicted in figures 6-36 and 6-37, the TNL IWU uses Q.2630.2 for communication with the R99/Rel-4 UTRANnodes. In order to ease implementation of such TNL IWU, the bearer control protocol for the IP-part of the connectionwill be as close to Q.2630.2 as possible. Related activities where started in ITU-T/SG11 as ITU-T was found to be thesuited organisation to specify this new bearer control protocol.Currently (March 2002), ITU-T has started to investigate the requirements for such protocol. As no name for the newprotocol has been defined in ITU-T yet, we will use the term “Q.IP-ALCAP” in this section to refer to this approach.From perspective mentioned above, it is desirable that “Q.IP-ALCAP” fulfils the following requirements:• Highly consistent with Q.2630.2 due to implementation related reasons described above• Support of embedded E.164 addresses or AESA variant of NSAP also for IP nodes (To allow IP nodes to address R99/Rel-4 ATM nodes)• Support of the generic IP-QoS parameters as agreed in section 7.9 for solution (3), i.e. Bit rate, SDU size, TNL QoS ClassThe following subsections of 6.10.5.2 will give details on the “Q.IP-ALCAP” proposal. As ITU-T is working in parallelto 3GPP TSG RAN WG3, additional information can be found in their documentation (the topic is handled in ITU-TSG11, Question 15). 3GPP
    • Release 5 93 3GPP TR 25.933 V5.4.0 (2003-12)Regarding the schedule of the work in ITU-T and 3GPP, it may be desirable to hold intermediate versions of “Q.IP-ALCAP” in 3GPP, until the final version of this protocol is approved by ITU-T SG11. Details how to handle suchintermediate specification are to be determined.6.10.5.2.1 Overall Scenario for “Q.IP-ALCAP”The following figure 6-41a gives an overview on the application of “Q.IP-ALCAP” in IP/AAL2 interworking. It showsthe user plane of an “A2IP connection” which is the concatenation of AAL2 type links (“AAL2 link” in figure 6-41a)with an IP link (“A2IP link” in figure 6-41a). Figure 6-41a is exactly the scenario as depicted in TRQ.AAL2IP.iw [67]which was (according to [68]) accepted as a baseline text specifying requirements by ITU-T.In this scenario, “Q.IP-ALCAP” shall support the establishment, maintenance, modification, and clearing of IP links aspart of a concatenation of AAL type 2 links with an IP link in a mixed AAL type 2 and IP environment. The IP part ofsuch a concatenated link is denoted in the figure as "A2IP link".The shaded area of figure 6-41a thus also shows thescope of TRQ.AAL2IP.iw [67]. AAL type 2 network IP network A2IP connection AAL2 link AAL2 link conversion port# A2IP link port# CID CID SW CID CID IP addr IP addr AAL2 path AAL2 path ATM ATM IP AAL type 2 VCC VCC service A2IP endpoint AAL type 2 switch A2IP Interworking Unit service endpoint Figure 6-41a: Scope of TRQ.AAL2IP.iw [67]Figure 6-41b gives additional details of the layering of the signalling protocols and visualises again the positions ofserved users in this scenario. The “A2IP Signalling” entities in figure 6-41b denote the signalling endpoints for the“Q.IP-ALCAP”. Note, that in the course of work on “Q.IP-ALCAP” the scope of an “AAL2 Served User” has beenextended in a way that it can be the user of an AAL2 type signalling protocol or A2IP type signalling protocol. Theprimitives exchanged between an “AAL2 Served User” and an “A2IP signalling” entity will differ from the primitivesdescribed in Q.2630. Note: A draft Q.IP-ALCAP was provided for information in [69]. 3GPP
    • Release 5 94 3GPP TR 25.933 V5.4.0 (2003-12) AAL2 IP AAL2 Served User AAL2 Served User SAP SAP Primitives Primitives Primitives AAL type 2 A2IP Layer Management Layer Management Primitives Switch Interworking Unit AAL2 AAL2 A2IP AAL2 Signalling Signalling Signalling Signalling SAP AAL2 Signalling A2IP Signalling SAP AAL2 Signaling / PDUs PDUs A2IP Signalling PDUs Primitives SAP Layer Management Layer Management Primitives SAP SAP SAP SAP SAP Generic Generic Generic Generic Primitives Primitives Primitives Primitives Signalling Transport Signalling Transport Signalling Transport Signalling Transport Converter Converter Converter Converter SAP SAP SAP SAP Specific Specific Specific Specific Primitives Primitives Primitives Primitives Signalling Transport Signalling Transport Signalling Transport Signalling Transport Primitives Primitives Primitives Primitives Figure 6-41b: Detailed Layering of Signalling for AAL2/IP InterworkingThe definitions corresponding to terms used in figures 6-41a and 6-41b are:A2IP connection: The logical concatenation of one or more AAL type 2 links and A2IP links between an AAL type 2service endpoint and an A2IP service endpoint. From the perspective of a Q.2630.1and Q.2630.2 AAL type 2 serviceendpoint, an A2IP connection is seen as an AAL type 2 connection.A2IP link: The logical user plane communication facility between two A2IP nodes. An A2IP link is designated by apair of IP address/port number combinations.A2IP node: An A2IP service endpoint or an A2IP Interworking Unit.A2IP interworking function: Functions residing in a A2IP interworking unit providing the bridge between an AALtype 2 signalling entity and an A2IP signalling entity.A2IP Interworking Unit: Interworking unit providing the conversion from AAL type 2 bearer to IP bearer(RTP[59]/UDP[42] or UDP[42] only). The Interworking Unit terminates AAL type 2 links and A2IP links. There is noserved user associated with an A2IP Interworking Unit. From UTRAN perspective, this unit is the Release 5 TNLInterworking Unit.A2IP service endpoint: A termination point of the IP part of an A2IP connection. There is an AAL type 2 served userassociated with an A2IP service endpoint.AAL type 2 served user: The user of an AAL type 2 or A2IP signalling protocol.A2IP signalling protocol: Control plane functions for establishing and releasing A2IP connections and themaintenance functions associated with the A2IP signalling. 3GPP
    • Release 5 95 3GPP TR 25.933 V5.4.0 (2003-12)6.10.5.2.2 Protocol Stack for “Q.IP-ALCAP”Protocol StackAs interworking between IP and ATM based RNCs appears only during the migration phase from an ATM basednetwork to an IP based one and only at the boarder between the two network types, the interworking solution – andtherefore the selected signalling protocol stack – should be straight-forward. IP based ATM based IWU RNC RNC Protocol IW Q.IP- Q.IP- Q.2630.2 Q.2630.2 ALCAP ALCAP Q.2150.1 Q.2150.1 Q.2150.3 Q.2150.3 MTP3-b MTP3-b SSCF SSCF SCTP SCTP SSCOP SSCOP IP IP AAL5 AAL5 L2 L2 ATM ATM L1 IP L1 L1 ATM/AAL2 L1 Figure 6-42: Protocol Stack for Transport Network Control Plane InterworkingFigure 6-42 presents the proposed protocol stack within the transport network control plane. The Signalling TransportConverter on SCTP is defined in [53].Benefits of this Protocol StackThe benefit of that protocol stack is, that most employed protocols are already in use inside the RAN and the additionalspecification work is low. Therefore a standardized interworking functionality can be easily introduced into the RANwithout the necessity of new protocols. Services provided by AAL2 signalling entities are unchanged. The interworkingunit itself can be based on an existing set of AAL type 2 service endpoints.6.10.5.2.3 Example: Connection Establishment on IurThis example shows transport bearer establishment and data on Iur. This shows the case where the legacy RAN is thedrift RNS. 3GPP
    • Release 5 96 3GPP TR 25.933 V5.4.0 (2003-12) RNC IWU RNC 1. RNSAP: RL Setup Request [] 2. RNSAP: RL Setup Response [TLA=A2EA ; TA=BID] 3. ERQ [NSEA=A2EA ; CEID = NULL ; DSAID = “unknown” ; ALC; OSAID ; SUGR = BID ; SSISU ; IPEID= IPRNC & UDPRNC] 4. ERQ [CEID ; NSEA=A2EA ; DSAID = “unknown” ; ALC; OSAID ; SUGR = BID ; SSISU] 5. ECF [DSAID ; OSAID] 6. ECF [DSAID ; OSAID ; IPEID= IPIWU & UDPIWU] 7. IP/UDP [IPIWU ; UDPIWU] 8. AAL2 [PathID ; CID] 9. AAL2 [PathID ; CID] 10. IP/UDP [IPRNC ; UDPRNC] Figure 6-43: Connection Establishment on Iur 1) IP based RNC (serving RNS) initiates establishment of the radio link with RNSAP message Radio Link Setup Request. 2) The legacy RNC node sends RNSAP message Radio Link Setup Response to the IP based RNC containing TLA and TA. TLA contains the ATM endpoint identifier of the ATM based RNC and TA contains an binding ID chosen form the ATM based RNC. 3) The IP based RNC sends an Q.IP-ALCAP establishment request message (ERQ) to the IWU that contains the IP endpoint identifier (IP address and UDP port of the IP based RNC for the new link). The CEID will be set to NULL. 4) The IWU acts as an AAL type 2 switch, but in addition it removes the IPEID and generates the CEID. 5) The CN node sends the connection confirm message (ECF) to the IWU. 6) The IWU acts as an AAL type 2 switch, but in addition it IPEID containing IP address and UDP port of the IWU for the new connection. 7) The IP based RNC sends data to the IWU using the assigned IP address and UDP port. 8) The IWU passes the data on to the ATM based RNC node using the established AAL2 connection. 9) The ATM based RNC node sends data to the IWU using the established AAL2 connection. 10)The IWU passes the data on to the IP based RNC using the assigned IP address and UDP port of the RNC.Connection release is simply the same as specified in [52]. Connection establishment initiated by the ATM based RNCworks respectively.6.10.5.3 IP-ALCAP based on Q.26306.10.5.3.1 BenefitsAAL2 signalling Q.2630 is used as the ALCAP in Rel99, Rel4 and Rel5 ATM UTRAN nodes. So Q.2630 will be inRel5 UTRAN irrespective of its presence in the Rel5 IP transport option. Q.2630 itself is expected to be a well-knownprotocol (behaviour, performance, operation&management) by the time it is introduced in any Rel5 IP UTRAN.IP-ALCAP as a whole is introduced in Rel5 IP transport option only as the control protocol between the IP UTRANnode and the stand-alone ATM/IP interworking unit. In the case where no interworking is required, i.e., there are only 3GPP
    • Release 5 97 3GPP TR 25.933 V5.4.0 (2003-12)Rel5 IP nodes and no IP/ATM interworking unit, then the IP-ALCAP is not required either. Thus the presence of IP-ALCAP is tightly coupled to the presence of ATM transport between the two UTRAN nodes.It is explained in this contribution that the needed change to the Q.2630 for it to provide the IP-ALCAP functionality issmall and specific to its application as the control protocol in the Rel5 IP TNL-IWU interface. Thus this change canwell be specified by the involved 3GPP Working Group alone, without any need for any involvement of any 3GPPexternal standards organization. This aspect is attractive in the sense that it excludes all additional risk inschedule/availability of the needed capability.During the discussions in RAN WG3 it has been argumented that any new protocol that is introduced in Re5 IPtransport should be an IETF protocol. However, the introduction of Q.2630 as the IP-ALCAP is to use an existing andwell-established UTRAN protocol (also used in CN) instead of introducing any new protocol at all.6.10.5.3.2 IP-specific information in Q.2630 in Served User Transport (SUT) parameterAll information that is conveyed in the control plane of the Rel5 IP TNL-IWU interface is only between the the peertermination points of the given interface. This is because of the following: 1) IP-ALCAP in Rel5 is introduced only as the control protocol between the Rel5 UTRAN IP node and its corresponding stand-alone Interworking Unit (the 3rd interworking alternative). 2) In this interface there are no intermediate AAL2 switches nor any other intermediate IP-ALCAP-aware nodes. 3) IP-ALCAP is not visible to the other side of the TNL-IWU, including any intermediate AAL2 switch there.The following figure depicts the scope and visibility of IP-ALCAP in Rel5 UTRAN. Rel5 UTRAN IP Node ATM UTRAN Node TNL IWU IP-ALCAP ALCAP ATM/AAL2 IP network network Figure 6-44: IP-ALCAP in Rel5 UTRAN: The scope6.10.5.3.2.1 Served User Transport parameter in Q.2630In Q.2630 [2] there is already today a parameter called Served User Transport (SUT). As defined in Q.2630, the SUT isa parameter "with significance to the served user only, therefore they shall not be examined by the nodal function[intermediate AAL2 switch]." Moreover, the SUT "carries the served user data that is transported unmodified to thedestination served user." The definition of SUT is similar in both existing Capability Sets, CS-1 and CS-2 of Q.2630and there is no reason foreseen for it to be excluded from the future Capability Sets (if any) either.The SUT parameter is very similar to the Served User Generated Reference parameter (SUGR), the major exceptionbeing that the SUT has variable length of up to 254 octets. The SUGR is used in Rel99/Rel4/Rel5 for the conveyance ofthe Binding ID between the two peer UTRAN nodes, in a similar fashion as it is now proposed for the IP relatedparameters to be conveyed in SUT.The IP "bearer" establishment procedure between the Rel5 IP UTRAN node and the stand-alone IWU requires a two-way signalling message exchange (Request-Confirm). It is also required (preferable) that each end point can allocate the"bearer" termination point in its side. That is, both endpoints should be able to signal their IP address and UDP port tothe other end point. This approach is in line with the principle adopted already in Rel99/Rel4 Iu-PS interface. In thecurrent Q.2630 the SUT has been defined only in the Establish Request (ERQ) message. That is, SUT is available onlyin the forward direction. Application of SUT in IP-ALCAP requires that the parameter is present also in EstablishConfirm (ECF) message. The addition of SUT in ECF can be considered a 3GPP specific change and there anapplication specific change as it is needed only in the IP TNL-IWU interface. As the SUT as a parameter has alreadybeen fully defined in Q.2630 (parameter ID, compatibility rules, etc.), its inclusion in ECF is simply a copy from ERQ.As there are no intermediate AAL2 nodes between the Rel5 IP node and the TNL-IWU, its inclusion in ECF does not 3GPP
    • Release 5 98 3GPP TR 25.933 V5.4.0 (2003-12)generate any incompatibility issue either (in Q.2630 there is an inbuild mechanism to cope with these issues, ref.below).6.10.5.3.2.2 Structure of informationBelow is the parameter format used in Q.2630 for all parameters. Parameter ID for Served User Transport is"00001000". Parameter compatibility is used for defining the behavior of the node when unrecognized information isreceived [table 7-20/Q.2630.1]. Table 7-2/Q.2630.1 – AAL type 2 parameter format 8 7 6 5 4 3 2 1 Octets Parameter identifier 1 Header Parameter compatibility 1 Parameter length 1 Payload Fields Table 7-7/Q.2630.1 – Identifiers of the AAL type 2 message parameters (concluded) AAL type 2 parameter Reference Acronym Identifier Served user transport 7.3.8 SUT 00001000 Table 7-15/Q.2630.1 – Sequence of fields in the served user transport parameter Field No. Field Reference 1 Served user transport 7.4.18In the following there is the structure of the Served User Transport field as defined in Q.2630 [chapter 7.4.18]. Table 7-38/Q.2630.1 – Structure of the Served User Transport field 8 7 6 5 4 3 2 1 Octets Field length 1 2 Served user transport nThe length of the Served User Transport parameter is variable from 1 to 254 octets, allowing a reasonable capacity forany information exchange. 3GPP
    • Release 5 99 3GPP TR 25.933 V5.4.0 (2003-12)It has already been agreed that a bearer in IP domain is identified by its UDP ports and IP addresses. Thus theinformation conveyed in SUT is, at least, the IP address and the UDP port of the originating node (the originator of thecorresponding IP-ALCAP message). The structures of the corresponding fields are proposed to be as follows. 8 7 6 5 4 3 2 1 Octets 1 UDP Port Number 2The UDP port Number has a fixed length of 2 octets: 8 7 6 5 4 3 2 1 Octets Field length 1 2 IP address nThe IP address has a variable length of max. 16 octets (IPv6). Variable length allows the field to be used with IPv4addresses as well (optional in Rel5 IP UTRAN).The traffic and QoS parameters can be conveyed in the following fields in the payload of SUT. 8 7 6 5 4 3 2 1 Octets TNL QoS Class 1 8 7 6 5 4 3 2 1 Octets Maximum bit rate in forward direction 1 2 Maximum bit rate in backward direction 3 4 8 7 6 5 4 3 2 1 Octets Average bit rate in forward direction 1 2 Average bit rate in backward direction 3 4 8 7 6 5 4 3 2 1 Octets Maximum SDU size in forward direction 1 2 Maximum SDU size in backward direction 3 4 3GPP
    • Release 5 100 3GPP TR 25.933 V5.4.0 (2003-12) 8 7 6 5 4 3 2 1 Octets Average SDU size in forward direction 1 2 Average SDU size in backward direction 3 4The coding of the other existing parameters in ERQ and ECF should be kept as it has been defined in Q.2630. Only thisway there is no other change needed than the introduction of SUT in Establish Confirm message. It is to be noted herethat the AAL2 Service Endpoint Address (A2EA) parameter conveys now the address of the destination ATM UTRANnode that was given in the corresponding xxxAP message. As the signalling bearer of IP-ALCAP is IP based, the IPaddress of the TNL-IWU is conveyed in the IP header instead of in IP-ALCAP itself. Those parameters that are notapplicable in Rel5 IP TNL-IWU interface should be left out if their presence is optional or otherwise filled with adummy value.In principle there are two ways of conveying the above defined information in the Served User Transport parameter.Either each element of information has its own identifier or the elements do not have any identifier but only length andvalue. In this proposal the elements of information do not have any identifiers and the length is included only in case ofvariable length element (IP address). This approach requires that the order of appearance of the elements is specified aswell. With this arrangement the above mentioned elements take 35 octets from the available 252 octets of payload.Should there be any other IP TNL-IWU specific information that needs to be conveyed between the two nodes, thisinformation can be conveyed in the similar fashion as above.6.10.5.4 Use of IETF RSVP for ATM/IP interworkingThis approach consist on the use of the Resource Reservation Protocol (RSVP) as the IP TNL control plane that allows: 1) The signalling of the QoS parameters to the IWU (IP originated case) 2) The application of the QoS signalled by Q.2630 (ATM Originated case) 3) The simplification of the IWU. This would be reduced to an IWF integrated in a typical IP router, less expensive to operators and easier to provide by vendors and also making the UTRAN transport more standard to the classical IP transport, since RSVP is commonly implemented in the IP routers.RSVP [54] is a protocol designed for integrated services in Internet allowing the establishment of simplex IP sessionsfor many different types of applications (it handles different flows with different QoS). The advantages of this protocolis that a limited number of messages are needed to define the behavior that is explained in the present document,together with the QoS orientation of RSVP. It also allows defining new objects where, in this case, the needed ATMparameters will be transferred to the IWU in order to be able to establish ATM connections.As basic operation, the TNL-IWU will receive either Q.2630 establishment requests or RSVP Path messages and beable to generate the appropriate messages on the other side with the information included in the received messages.Therefore, RSVP signalling is only valid between IP UTRAN node and IWU, and ATM signalling is valid betweenATM UTRAN node and IWU.6.10.5.4.1 Working scenariosThis clause covers the main scenarios including establishment and release of transport connections, including the issuesderived from this kind of implementation.6.10.5.4.1.1 ATM UTRAN Node initiated RL Setup procedureIn this scenario an ATM SRNC (CRNC) sends a RL Setup Request message to an IP DRNC (Node B), which sendsback a RL Setup Response message including SUGR (binding ID) and A2EA (Transport Layer Address) IWU amongother parameters.The TNL messages are depicted in the figure below: 3GPP
    • Release 5 101 3GPP TR 25.933 V5.4.0 (2003-12) ATM IP SRNC DRNC IWU (CRNC) (Node B) RL Setup Request RL Setup Response [A2EA_IWU, SUGR] ERQ [CID, OSAID, SUGR, A2EA_IWU, LC, SSCS, PT] Path [`SESSION, RSVP_HOP, TIME_VALUES, SENDER_TEMPLATE, SENDER_TSPEC, DCLASS, SUGR] Resv [`SESSION, RSVP_HOP, TIME_VALUES] ECF Path [`SESSION, RSVP_HOP, TIME_VALUES, SENDER_TEMPLATE, SENDER_TSPEC, DCLASS, SUGR] Resv [`SESSION, RSVP_HOP, TIME_VALUES] DATA TRANSFER RL Deletion procedure REL [CAUSE] PathTear [`SESSION, RSVP_HOP] PathTear [`SESSION, RSVP_HOP] RLC [ ] Figure 6-45: Interaction between ATM SRNC (CRNC) and IP DRNC (Node B)Procedure: 1) Radio Link Setup procedure. In addition to the SUGR, PT (only in R5) and SSCS Information, the IP node sends the Transport Layer Address of the IWU in the RADIO LINK SETUP RESPONSE message. 2) After RL Setup procedure is completed, SRNC (CRNC) sends an ERQ message to the IWU. 3) Upon reception of ERQ message and after granting the admission of the new AAL2 connection, the IWU sends a PATH message to the DRNC (Node B) with the help of a table to convert ATM ports to IP addresses. This message will include the QoS parameters needed for the Admission control (SENDER_TEMPLATE, SENDER_TSPEC, DCLASS and SUGR), and additionally it may provide the DiffServ code points to use for the bearer flow (with the inclusion of the DCLASS object in the Path message). 4) Upon reception of a Path message the DRNC (Node B) sends a RESV and a PATH messages to the IWU if no other session with the requested Binding-ID (SUGR) is set (note that a reservation is needed for each direction as well as a previous definition of the connection QoS by means of the PATH message). If any of these messages fail, a timer waiting for an incoming Path message in the IWU or the PathErr and ResvErr messages incoming to the IWU will make that SRNC (CRNC) and IWU consider the ERQ as failed. Also note that there is a need for a RNC_ID to A2EA_IWU conversion in the DRNC database. 5) Upon reception of the Path message, the IWU sends an ECF message to the SRNC (CRNC) and a Resv message to the DRNC (Node B). 6) At this point data can be sent in both directions. Note that the RSVP PATH and RESV must be maintained periodically. 7) The SRNC (CRNC) initiates the release of the transport connections with a REL message to the IWU. 8) Upon reception of a Q.2630 Release Req message the IWU sends back the confirmation (RLC) to the SRNC (CRNC). It is up to the implementation whether the RSVP is released by means of a PathTear message or waiting for the refresh timers expiry. However, it is recommended to implement the Tear down messages, to speed up the release of the IP bearer. 3GPP
    • Release 5 102 3GPP TR 25.933 V5.4.0 (2003-12)6.10.5.4.1.2 IP UTRAN Node initiated RL Setup procedureIn this scenario an IP SRNC (CRNC) sends a RL Setup Request message to an ATM DRNC (Node B), which sendsback a RL Setup Response message including SUGR and A2EA IWU among other parameters.The TNL messages are depicted in the figure below: ATM IP DRNC SRNC IWU (Node B) (CRNC) RL Setup Request RL Setup Response [A2EA, SUGR] Path [`SESSION, RSVP_HOP, TIME_VALUES, SENDER_TEMPLATE, SENDER_TSPEC, SUGR, , DCLASS, SUGR, A2EA, PT ] Resv [`SESSION, RSVP_HOP, TIME_VALUES] Path [`SESSION, RSVP_HOP, TIME_VALUES, SENDER_TEMPLATE, SENDER_TSPEC, SUGR] ERQ [CID, OSAID, SUGR, A2EA_IWU,PT, SSCS, PT] Resv [`SESSION, RSVP_HOP, TIME_VALUES] ECF DATA TRANSFER RL Deletion procedure PathTear [`SESSION, RSVP_HOP] REL [CAUSE] PathTear [`SESSION, RSVP_HOP] RLC [ ] Figure 6-46: Interaction between IP SRNC (CRNC) and ATM DRNC (Node B)Procedure: 1) After RL Setup procedure is completed, SRNC (CRNC) sends a Path message to the IWU. This message will contain additionally to the RSVP PATH parameters, the DCLASS object, the SUGR, A2EA and PT information in a new RSVP Object. 2) Upon reception of a Path message the IWU will respond with a Resv and a Path messages. 3) Upon reception of a Path message the SRNC (CRNC) will send a Resv message to the IWU. 4) Upon reception of a Resv message, the IWU will send an ERQ message to the DRNC (Node B). 5) The DRNC (Node B) will respond with an ECF message to the IWU, completing the establishment. 6) In this point data can be sent in both directions. Note that the RSVP Path and reservations must be maintained periodically. 7) The SRNC (CRNC) initiate the transport layer connections by sending a PathTear message to the IWU. 8) Upon reception of a PathTear message the IWU will send a REL message to the DRNC (Node B) to release ATM connection. 9) The DRNC (Node B) will send back a confirmation message to the IWU (RLC), completing the ATM connection release. 10)The IWU also sends a PathTear message to the SRNC (CRNC) in response to the previously received PathTear message. 3GPP
    • Release 5 103 3GPP TR 25.933 V5.4.0 (2003-12)Advantages: - There is a direct signalling and application of the same QoS across the entire interface. This is possible because of the interworking function integrated in RSVP as well as the possibility to signal DiffServ Code Point inside RSVP. - There is no limitation on the IP side respective to the method of QoS to be applied, it is possible to use either RSVP or DiffServ.Issues: - The IWU will have only one node associated to an ATM address + OSAID. This is to uniquely identify the IWU Transport Layer Address with an IP node. - In the DRNC (Node B) side there is a need for an RNC-ID to A2EA_IWU database to perform the addresses conversion. The IWU ATM address is a "default gateway" for the IP node to address all the ATM nodes. - In the IWU side there is a need for an A2EA_IWU + OSAID to IP address database to perform the addresses conversion. - There is a need to define a new object in RSVP that carries all AAL2/ATM QoS related fields needed in the procedure. - In case diffserv is used, the Path ID will be mapped to a DiffServ CP and the IWU will contain a table to map PT to diffserv CP. Here the DCLASS object will be used. - The IWU will have a timer that controls the PATH refresh procedure in order to release the ATM connection if any problem occurs in the IP side.6.10.5.4.1.3 RSVP considerationsIn this clause generic topics regarding RSVP such as Reservation Confirmation, traffic policing, recommended valuesfor timers or security considerations are not covered. For more information about them please refer to [54].The only modification in the RSVP protocol needed to make this solution feasible is the definition of a new object apartfrom the standardized ones (SESSION, RSVP_HOP, TIME_VALUES, etc.) assigning an unused value for an objectthat will contain the ATM parameters needed to be passed to the IWU in order for it to establish the correspondingATM connections towards the ATM UTRAN node.This new object must be defined according to the standard object format defined in [54]. Every object consists of one ormore 32-bit words with one fixed header with the object length, the chosen Class-num and C-Type (a value uniquewithin Class-num). After the header the content should be defined included the needed ATM parameters.6.10.5.5 Inter-working with a PWE3-Capable ATM SwitchThe signalling flow for the ATM-IP interworking solution based on a PWE-capable ATM switch as defined in section6.10.2.1.1 is presented in this section.Protocol StackAs interworking between IP and ATM based RNCs appears only during the migration phase from an ATM basednetwork to an IP based network and only at the border between the two network types, the interworking solution – andtherefore the selected signalling protocol stack – should be straight-forward and not entail new develoment effort.The reuse of Q2630 meets this straightforward consideration as it is simply needed to define a new layer-1 to reuse thisexisting TNL CP protocol on the IP part. The overview of the protocol stacks used is presented hereafter with the newpart in red. 3GPP
    • Release 5 104 3GPP TR 25.933 V5.4.0 (2003-12) PWE3-capable ATM based PE-node RNC RNC Q.2630.2 Q.2630.x Q.2150.1 Q.2150.1 MTP3-b MTP3-b SSCF SSCF SSCOP SSCOP AAL5 AAL5 ATM ATM ATM PWE3 PWE3 L1 L1 IP ATM/AAL2 Figure 6-46a: Protocol Stack for Transport Network Control Plane InterworkingBenefits of this Protocol StackThe benefit of that protocol stack is, that most employed protocols are already in use inside the RAN and the additionalspecification work is low. Therefore a standardized interworking functionality can be easily introduced into the RANwith only the necessity of a new PWE3 tunnelling layer. Services provided by AAL2 signalling entities are unchanged.The interworking unit is straighforward as it is an ATM switch equipped with a specific layer-1 and transparent to thesignalling flows. Minimum operation effort is needed to operate and maintain this ATM switch.Example: Connection Establishment on IurThis example shows transport bearer establishment and data on Iur. This shows the case where the legacy RAN is thedrift RNS. < PWE-RNC ATM RNC PE-node 1. RNSAP: RL Setup Request [] 2. RNSAP: RL Setup Response [TLA=A2EA ;BID] 3. ERQ [NSEA=A2EA ; 4. ERQ [CEID ; NSEA=A2EA ;; 5. ECF [DSAID ; OSAID] 6. ECF [DSAID ; OSAID ; 7. AAL2 [ Path-id ; CID] 8. AAL2 [PathID ; CID] 9. AAL2 [ PathID ; CID] 8. AAL2 [ PathID ; CID] 3GPP
    • Release 5 105 3GPP TR 25.933 V5.4.0 (2003-12) Figure 6-46b: Connection Establishment on Iur 1) The PWE3- RNC (serving RNS) initiates establishment of the radio link with RNSAP message Radio Link Setup Request. 2) The legacy RNC node sends RNSAP message Radio Link Setup Response to the IP based RNC containing TLA and a binding ID. TLA contains the ATM endpoint identifier of the ATM based RNC. 3) The PWE3-RNC selects a signalling Vp/Vc according to the received AESA address and sends a Q2630 establishment request message (ERQ) tunnelled over PWE3. The ERQ message contains the Path-id to be used for the user plane. 4) The PE-node is transparent for the ERQ message and may simply switch the Vp/Vc (act as an ATM switch) towards the next ATM switch or next aal2 switch or terminating UTRAN node. Step 4 is starighforward. 5) The legacy RNC node sends the connection confirm message (ECF) in reply. 6) The PE-node is transparent for the ECF message and may simply switch the Vp/Vc (act as an ATM switch) towards the next ATM switch or next aal2 switch or originating UTRAN node. Step 6 is starighforward. 7) The PWE3- RNC sends data to the legacy RNC node which is also transparently carried over the PWE3-tunnel. 8) Only switching at ATM level if needed. 9) The ATM based RNC node sends data to the PWE3 RNC which is also transparently carried over the PWE3- tunnel.Connection release is simply the same as specified in [52]. Connection establishment initiated by the ATM based RNCworks respectively.This sequence flow shows that this solution is the same as currently used but simply provides an adaptation of layer 1.6.10.6 Coexistence between Rel.5 and R99/R4 Iur Control Plane using SUA protocolClause 6.7.2 describes the option of SUA as IP based signalling User Adaptation Layer in Iur Control Plane.It is clear that SUA provides seamless functions and services as SCCP (from RNSAP point of view), and also, asadvantage, SUA is optimized to be used over SCTP/IP, providing e.g. SCCP-to-SCTP/IP address translation. See [26]for further details.6.10.6.1 Connecting an Rel.5 RNC to a R99/R4 RNCA way to interwork an Rel.5 RNC to a R99/R4 RNC is using signalling gateway. (this gateway can be embedded in thesame physical equipment as an RNC) Using SUA, the RNSAP SAP is maintained for both TNL options since SCCPand SUA provide the same primitives and services to RNSAP, so no changes to RNSAP are needed to support bothTNL options. With SUA, the RNL independence is maintained for Rel.5 as in R99/R4.The signalling gateway would perform the L2/L1 to AAL5/ATM/L1 conversion. In this case SUA does not add anyinterworking problem, since the signalling gateway performs the domain conversion from SCCP to SUA/SCTP/IP andvice versa. Also, it is noted that the signalling gateway could come from any vendor, since all protocol used in bothends of the SG are standardized. 3GPP
    • Release 5 106 3GPP TR 25.933 V5.4.0 (2003-12) RNSAP RNSAP SCCP SCCP SUA SUA MTP3-B MTP3-B SCTP SCTP SSCF-NNI SSCF-NNI IP IP SSCOP SSCOP AAL5 AAL5 L2 L2 ATM ATM L1 L1 L1 L1 ATM IP R99 RNC Signalling Gateway R4 RNC External Dual Stack R4/R99 RNC Figure 6-47: Interworking between External dual stack RNC and a Rel4/R99 RNCThis option permits the providers and operators to handle the different interworking scenarios in an efficient way, e.g.several Rel.5 RNCs sharing the same signalling gateway to a R99/R4 only RNC through an IP network, or RNCs withembedded signalling gateways connected to R99/R4 only RNCs and using both IP and ATM networks, whilemaintaining the RNSAP protocol as in R99/R4. R99 only R4 only RNC RNC IP SG ATM R99 only RNC R4 only Embedded RNC SG RNC Figure 6-48: Possible interworking scenarios using SUASummarising the conclusions: - SUA maintains the same primitives and services as SCCP and is optimized to be used over SCTP/IP, e.g. including the SCCP-to-SCTP/IP address translation. - There are no interworking problems between Rel.5 and R99/R4 Iur Control Plane when SUA protocol is used below RNSAP for Rel.5 stack. - With SUA, the Signalling gateway approach also gives flexibility to both providers and operators to implement the interworking between the R99/R4 and Rel.5 releases, depending on transport network characteristics and equipment availability, while maintaining open interfaces (Rel.5 and R99/R4 Iur) in both R99/R4 and Rel.5 RNCs. 3GPP
    • Release 5 107 3GPP TR 25.933 V5.4.0 (2003-12)6.11 SynchronizationNode synchronization requirements for an IP based UTRAN nodes should be investigated including minimizing delayvariation and clock frequency differences between an application source and sink.6.12 SecurityThis study area is related to security aspects.6.12.1 Security Threats[43] classifies between threats associated to the air interface, to the UE or to other part of the network. For the other partof the network, the identified threats are the following: - Unauthorized access to data: traffic eavesdropping, receiver masquerading, unauthorized access to stored data, traffic flow analysis. - Threats to integrity: manipulation of stored data, traffic or network elements by masquerading or any other way. - Denial of service: physical or protocol intervention, abuse of emergency services. - Repudiation: of charge, of traffic origin or delivery. - Unauthorized access to services: by masquerading or misusing privileges or services.6.12.2 Security Operation in IP networks6.12.2.1 IPSec architecturesIn IETF, security is a whole area of work, in which one group focuses especially on security architecture and IPSecprotocol suite [44], [45]. IPSec is a protocol providing authentication and integrity protection in two differentarchitectures: - End-to-end security provisioning between hosts: this solution puts the complexity into the hosts; - Gateway to gateway: IPSec is terminated in intermediate nodes (routers) that protect the data in a sub-part of the network that may be insecure.When the security is provided from host to host, two modes are possible: - Transport mode, in which integrity and authentication cover only transport protocol (above IP) and higher protocols. - Tunnel mode, in which the IP header is also protected. That mode needs a second IP header to be present to allow routing. - The tunnel mode is the only possible solution for gateway to gateway architecture. - Both modes cause additional overhead per IP packet.IPSec is a separate protocol in IPv4 but is fully integrated in IPv6. However its use is optional in IPv6. It is possible toprovide security to IPv6 hosts without using IPSec in the hosts, for instance with gateway to gateway tunnel mode.IPSec architecture assumes the existence of a Key management system. That system can be manually administered orcontrolled by IETF protocols like, ISAKMP [45].6.12.2.2 SCTP Security featuresSCTP (Stream Control Transmission Protocol) has been designed to transport signalling and control data on top of IP. Itdelivers a reliable transport service, like TCP. But it brings also some additional features. 3GPP
    • Release 5 108 3GPP TR 25.933 V5.4.0 (2003-12)It incorporates a cookie exchange mechanism at association establishment. That procedure was explicitly designed toprevent unauthorized connections to be set up at transport level.6.12.2.3 Firewalls and other systemsBeyond standard protocols and architecture defined by IETF, constructors have proposed their own security features inboxes often called "Firewalls". They most often implement standard security solutions but they also incorporateadditional functions.This kind of equipment is mainly dependent on the State of the Art of any kind of security experts. The decision to useit is out of the scope of UMTS standardization.6.13 Iu-cs/Iu-ps harmonizationThis study area is related to the possibility of removing the Iu-cs/Iu-ps distinction in the user plane and in the controlplane.6.13.1 GTP-U for Iu user plane6.13.1.1 Iu PSWith IP transport for UTRAN, GTP-U will be used on the IuPS interface as in Release 99 / Release 4 . However, whenreal-time applications are considered and IP header compression is used, the GTP-U header is relatively large. There arecurrently 2 possible headers that can be used for GTP-U. One consists of 8 octets, the other 12 octets. In addition, thereis the application independent GTP protocol that is used for 3G and GPRS charging. GTP uses a smaller header thanGTP (6 octets) but has (for individual packets or for a group of packets) acknowledgments also in the user plane, inaddition to having acknowledgements for the signalling plane packets. Protocol Type (PT) flag in the bit 5 of the headerindicates which of the two headers is being used.IP header compression allows the IP/UDP headers to be compressed to 2 – 5 octets. If a sequence number is neededwith GTP-U, the header size is 12 octets. For example, for a 40-octet payload, the GTP-U overhead alone can be over20% of the packet size (IP/UDP/GTP/payload) when a sequence number is included.For real-time applications much of the GTP-U header is not needed. A header definition for GTP-U should be definedthat is optimized for real-time applications.6.13.1.2 Iu CSGTP-U could be used for the IuCS interface over IP transport for the following reasons: - The requirements for the real-time IuPS applications and the real-time IuCS applications are the same.It results in the same protocols being used for both IuCS and IuPS (harmonization). GTP-U will be used for the IuPS interface so it will already be available for the IuCS in the Media Gateway. - It is under the control of 3GPP. Any desired modifications for optimization can be handled by 3GPP.An alternative to GTP-U is to use RTP: according to RFC 1889, RTP is designed to satisfy the needs of multi-participant multimedia conferences. It therefore provides more functionality than is required and has a large overhead of12 octets.The RTP header can be compressed but the decompressor needs to be updated for every packet so it adds processingload over IP/UDP compression alone.The advantage of RTP is that it is an IETF protocol. However, this protocol will be terminated where the framingprotocol is terminated at the UTRAN interface endpoint. It is therefore not important that it is an IETF protocol.6.13.1.3 GTP header for the Iu-PS user planeThe Release 99 / Release 4 GTP header is shown below. 3GPP
    • Release 5 109 3GPP TR 25.933 V5.4.0 (2003-12) Bits Octets 8 7 6 5 4 3 2 1 1 Version PT (*) E S PN 2 Message Type 3 Length (1st Octet) 4 Length (2nd Octet) 5 Tunnel Endpoint Identifier (1st Octet) 6 Tunnel Endpoint Identifier (2nd Octet) 7 Tunnel Endpoint Identifier (3rd Octet) 8 Tunnel Endpoint Identifier (4th Octet) 9 Sequence Number (1st Octet)1) 4) 10 Sequence Number (2nd Octet)1) 4) 11 N-PDU Number2) 4) 12 Next Extension Header Type3) 4)The last two fields would not be necessary to be carried in the Iu-PS, so the header size would be 8 (or 10) octets. NOTE: The GTP-U header is 8 octets unless one or more of the E, S, or PN bits are set, then it is 12 octets.The (*) bit is unused: - Version field: This field is used to determine the version of the GTP protocol. - Protocol Type (PT): This bit is used as a protocol discriminator between GTP (when PT is 1) and GTP (when PT is 0). GTP is described in the 3GPP TS 32.015, 3GPP 32.215 and in the GSM 12.15. - Extension Header flag (E): This flag indicates the presence of the Next Extension Header field when it is set to 1. When it is set to 0, the Next Extension Header field either is not present or, if present, must not be interprete. - Sequence number flag (S): This flag indicates the presence of the Sequence Number field when it is set to 1. When it is set to 0, the Sequence Number field either is not present or, if present, must not be interpreted. - N-PDU Number flag (PN): This flag indicates the presence of the N-PDU Number field when it is set to 1. When it is set to 0, the N-PDU Number field either is not present, or, if present, must not be interpreted.6.13.1.4 User plane header simplification considerations for the Iu-PSThe following simplifications to the GTP-U header could be considered in order to reduce overhead for real-timeapplications: 1) The length field could be removed. This would mean that the user plane multiplexing could not be done. 2) A one-octet message type field is larger than required for GTP-U and is based on GTP-C requirements. There are only a few GTP-U messages. However, for this discussion, it is assumed that GTP-U signalling messages are always sent with a full header. All GTP-U messages use a TEID value of 0.The following table shows the messages used by GTP-U: GTP-U Message TEID Echo Request 0 Echo Response 0 Error Indication 0 Supported Extension Headers Notification 0The following text defining the use of the TEID field in the GTP-U header is from the GTP specification, 29.060. - TEID: contains the Tunnel Endpoint Identifier for the tunnel to which this T-PDU belongs. The TEID shall be used by the receiving entity to find the PDP context, except for the following cases: 3GPP
    • Release 5 110 3GPP TR 25.933 V5.4.0 (2003-12) - the Echo Request/Response, Supported Extension Headers notification and the Version Not Supported messages, where the Tunnel Endpoint Identifier shall be set to all zeroes; - the Error Indication message where the Tunnel Endpoint Identifier shall be set to all zeros. 3) The sequence number in GTP might be larger than required for real-time applications. 4) The N-PDU number will never be needed since it is used only for non real-time applications to guarantee that packets are not lost or duplicated during the Routing Area Update procedure and SRNS Relocation. 5) GTP includes a 4 octet Tunnel Endpoint Identifier to identify a flow. This is a larger than required. It is shortened in the below presented alternative header scenarios "A" and "B" to use a 2 octet TEID. 6) Header Extensions do not need to be supported for real-time applications. If extensions are needed for an application, the full GTP header should be used.6.13.1.5 Proposed GTP-U-like header scenario "A" for real-time applicationsIt is assumed that the TEID/IP address is used to identify a flow (RAB/PDP context). GTP-U signalling messages willuse the full GTP header.The following table shows a proposed GTP-lite header for real-time applications: Octet 8 7 6 5 4 3 2 1 1 Version PT0 PT1 * S * 2 TEID (1st Octet) 3 TEID (2nd Octet) 4 Sequence Number (1st Octet) 5 Sequence Number (2nd Octet) Figure 6-49: GTP-lite header in alternative scenario "A" - Protocol Type 0, 1 (PT0, PT1): These flags indicate how the header and protocol should be interpreted as shown in the following table. (Only the PT0 exists currently in the 3GPP (and ETSI) GTP and GTP specifications, with the name Protocol Type, PT.) PT1 PT0 Meaning 0 0 GTP 0 1 GTP-full header 1 0 GTP-lite header - Sequence number flag (S): This flag indicates the presence of the Sequence Number field when it is set to 1. When it is set to 0, the Sequence Number field is not present.6.13.1.6 GTP-U-like alternative header scenario "B" for real-time applicationsAlso in the alternative scenario "B" it is assumed that the TEID/IP address is used to identify a flow (RAB/PDPcontext). GTP-U signalling messages will use also in this scenario the full GTP header.The above mentioned alternative "A" has several serious limitations which are tried to be improved in this headerscenario "B": 1) The alternative "A" violates against the current GTP/GTP protocol identification system standardized in the 3GPP TS 29.060, 3GPP TS 32.015, 3GPP TS 32.215 and against the ETSI GSM 09.60 and ETSI GSM 12.15 3GPP
    • Release 5 111 3GPP TR 25.933 V5.4.0 (2003-12) what comes to the usage of the bits 4 and 5 of the first header octet. It has been standardized and implemented previously that only the bit 5 of the octet 1 is "visible" and used in a common way in the GTP and GTP protocols. The tunneled GTP/GTP packets traveling in a 3G network have several years ago standardized to be identified and aven possible to filter from each other by this one bit 5. Also, the bit 4 is standardized independently in the GTP and GPT standards and not "visible" to each other of the two protocols. As GTP standards state: "Bit 5 of octet 1 of the GTP header is the Protocol Type flag and is 0 if the message is GTP. The Version bits indicate the GTP protocol version when the Protocol Type flag is 0." And, the Version bits are understood to mean the GTP or GTP version, depending on the PT bit being 1 or 0, correspondingly. This Version bits handling would not now work properly if there would be a third protocol header being identified on the bits 5 and 4 of the 1st octet. 2) Since in the lightweight GTP scenario "A" there is no length information, only one user data packet could be carried at a time by that GTP-lite protocol header alternative. That would mean high relative protocol overhead especially then when the transferred paylod packets are small. To avoid the total protocol performance problems resulting from this limitation, this scenario alternative "B" has the normal Length information that the normal GTP (and GTP) also have. Bits Octets 8 7 6 5 4 3 2 1 1 Version PT (*) E S PN 2 Message Type 3 Length (1st Octet) 4 Length (2nd Octet) 5 Tunnel Endpoint Identifier (1st Octet) 6 Tunnel Endpoint Identifier (2nd Octet) 7 Sequence Number (1st Octet)1) 4) 8 Sequence Number (2nd Octet)1) 4) 9 N-PDU Number2) 4) 10 Next Extension Header Type3) 4) Figure 35: GTP-lite header in alternative scenario "B"Like in the normal GTP, the two last fields would not be necessary to be carried here in the Iu-PS. So, the header sizewould be 6 (or 8) octets in the Iu-PS.In this scenario "B", the already standardized bit 4 and bit 5 usage in GTP and GTP is not violated. This requires thatthe identification of this "lightweight GTP header" is done otherwise. This would in practice mean the establishment ofa new Message Type to GTP, to form a side variant of the GTP protocol, what comes to the user plane. In this scenario"B" a new Message Type value would be needed to be allocated for the more lightweight GTP-like header, from theGTP Message type table in the 3G TS 29.060. This means that there is no difference in the octet usage in this respect, inrelation to the normal GTP.Thus there would be a properly working and a 3G TS compatible header but the size advantage gained in this scenario"B" would be only 2 octets, in comparison to the normal GTP header.(Additionally, one octet could maybe be saved if the Sequence Number would be considered necessary to be used and ifat the same time one-octet Sequence Numbers would be considered feasible.)6.13.1.7 Comparison of the GTP-U header and the possible new scenarios "A" and "B"When comparing the GTP, and ond the otherhand the lightweight GTP scenarios "A" and "B", the following thins canbe noted.Considerations about the alternative scenario "A": - The lightweight GTP-U alternative "A" seems too limited in capability and incompatible with existing 3G specifications, when compared against the alternative "B" and the normal GTP-U header. 3GPP
    • Release 5 112 3GPP TR 25.933 V5.4.0 (2003-12) - There is a serious disadvantage in the alternative "A" what comes to the requirement to have maximum stack performance, since the lack of the normal payload packet multiplexing capability of the GTP protocol would not be available and only one payload packet could be carried at a time (using the length information gained from the lower layer). This means that especially with small packets, the relative total header octet overhead would be significantly bigger than with the standardized normal GTP frame. - Additionally there would be the disadvantage of having to process a bigger amount of packets through the stack (up nd down), so the Iu-PS user plane performance would decrease with the lightweight GTP scenario "A" also due to that drawback which would affect all the lower layers.Considerations about the alternative scenario "B": - The size advantage of the lightweight GTP-U alternative "B" is only 2 octets in comparison to the normal, standardized and very widely used GTP header. (If the Sequence Number length would be sacrificed to be only half of the normal size, then one additional octet would be saved.) - The price to be paid for establishing the lightweight GTP-U header alternative "B" would anyway be very high: A new protocol side variant would need to be standardized and implemented for two node types, and maintained also in the future in the standards and the products. Also, additional product testing and documentation would be always required when new product releases are made. This would be against the general principle of keeping the interfaces as simple as possible and the protocol variants as few as possible. - What comes to the performance, there is no difference in practice between the alternative "B" and the normal GTP header, since the hardware typically reads the data fastest when the number of octets is dividable by 4, so even here the gained advantage looks very questionable. As known, the bandwidth is typically limited much earlier by the data processing power than by the transmission path as such.In conclusion to the detail considerations above, the normal, already standardized and implemented GTP protocolheader seems the best alternative for the Iu-PS user plane (in addition to being in the control plane).6.13.1.8 Motivation for GTP-UFor many applications, data must be delivered in the same order that it was sent. In IP networks it is possible thatpackets will be reordered or lost in the network. Therefore, sequencing information is required to allow data to bedelivered to the application in the correct order and to detect lost data. The support mode of the Iu framing protocol(IuFP) could provide a frame number, which is used to detect lost frames. It is not used to reorder out of order frames,which may be required by some applications.The transparent mode of the Iu framing protocol has no functionality so it does not provide sequence information. Forapplications that require in-sequence delivery but use the IuFP in transparent mode, the transport layer must provide it.One such application is transparent circuit switched data [48].GTP-U should be used for the transport protocol over UDP for the following reasons: 1) GTP-U provides the required sequence information. 2) GTP-U is already used on the IuPS interface. Since it meets the requirements for the IuCS there is no reason to introduce a new protocol in the RNC for the IuCS. 3) GTP-U is a simple protocol.6.13.2 RTP for Iu-cs interface6.13.2.1 Reasons for selecting an RTP/UDP/IP based Iu-cs User Data Transport stackEnabling voice quality monitoring by performing measurements and providing communication between sending andreceiving side. - Voice quality information is seen to be extremely important for network operators to meet typical requirements stemming from real-time traffic. Performing measurements requires sequence numbers and time stamp information to derive information about the quality of an IP trunk in terms of loss and delay (delay jitter). GTP- U does not have a time stamp. 3GPP
    • Release 5 113 3GPP TR 25.933 V5.4.0 (2003-12) - Quality reports from the receiving to the sending side of an IP trunk is a prerequisite for adaptive mechanisms (e.g adaptive connection admission control or routing mechanisms depending on the QoS of an IP trunk).RTP provides the means to perform QoS monitoring. - RTP and RTCP provide the means for in-sequence integrity/reordering and QoS monitoring of VoIP trunks.RTP is a standard IETF solution. - RTP/UDP/IP currently is the only IETF conform solution for real-time transport. Deciding upon this solution will follow a design principle, that has been established within RAN3, i.e. to follow a standard IETF solution.RTP is already optimized to be combined with Udp/IP. - For example, it authorizes a combined compression with existing mechanisms leading to a compressed length of 2 bytes whereas the GTP cannot share the compression context with UDP/IP and leads to 14 bytes overhead (12+2). This efficiency is very sensible (e.g. for voice flows)."6.13.2.2 Motivation for not choosing the RTP alternative6.13.2.2.1 GeneralThere have been contributions to RAN3 that propose the use of RTP for the IuCS interface. The main motivations forusing RTP provided in those contributions are: - It is used in the 3GPP circuit-switched core network for the Nb interface. - RTP has capability that is needed for real-time services over the IuCS interface. - RTP is an IETF protocol. - Bandwidth utilization. - The following clauses address these points for RTP.6.13.2.2.2 Commonality with Nb interfaceThe transport protocols are completely terminated in the media gateway on each interface. There are separate transportsessions established for the Iu interface and the Nb interface. Even if RTP were used on both the Iu and the Nb, the RTPsessions and stacks would be completely terminated on the Iu endpoint and the Nb endpoint in the MGW.It is still to be investigated wether timing information from the transport layer needs to be transferred between the Iuand Nb interfaces even though relevant timing information for an application is contained in the Iu/Nb framingprotocols. There is a "through connect" mode defined for the MGW but this is only at the framing protocol level, not atthe transport layer level. RTP is terminated but the framing protocol is not.6.13.2.2.3 Special RTP capabilityThe IP transport requirements for real-time traffic on the IuCS interface is the same as for the real-time traffic over theIub and Iur interfaces. The Iub interface has the strictest quality of service requirements since it can be a low speed link.RTP has not been proposed for these interfaces and is not being considered.According to RFC 1889, RTP is primarily designed to satisfy the needs of multi-participant multimedia conferencesusing IP multicasting but it is not limited to that particular application. The IuCS interface does not require multi-participant capability from the transport layer. Only unicast transport is required. Therefore, some of the capabilitydefined around RTP is not required.It has been proposed that the quality reporting functionality of RTP (using RTCP) is important for the IuCS. However,as discussed for the Iub and Iur interfaces during the IP UTRAN study, quality of service and resource managementshould be handled at the IP layer and below. The use of quality feedback at the application layer should not be required.Quality reporting is also not needed for rate control. This is handled by the Iu framing protocol.In the RTP RFC, quality of service monitoring is mandatory for multicast applications and optional for unicastapplications. 3GPP
    • Release 5 114 3GPP TR 25.933 V5.4.0 (2003-12)6.13.2.2.4 Bandwidth utilizationThe Iu interface is a high-speed interface so bandwidth utilization is not a high priority as it is for the Iub interface. RTPand GTP-U have the same header size (12 octets) when the sequence number is used with GTP-U. When the sequencenumber is not used with GTP-U, the header size is 8 octets. Without header compression, both the RTP and GTP-Uheader sizes are less significant in comparison with the IP/UDP headers.Header compression can be used with both RTP and GTP-U packets. Since the Iu is a high-speed interface, it is notpractical for each router to perform header compression on a link by link basis. Alternatively, header compressedpackets can be tunneled in PPP frames in an L2TP tunnel. Since the compressed packets are tunneled, they are notdecompressed/compressed at each hop.If it is determined that bandwidth utilization is an important concern for the Iu interface, then RTP has some bandwidthutilization advantage when tunneling compressed packets in PPP frames. RTP compression is performed in conjunctionwith IP/UDP compression so the resulting header is small. With GTP-U, the IP/UDP headers can be compressed but notthe GTP-U header. It should be decided if GTP-U with compressed IP/UDP headers is sufficiently efficient for the Iuinterface.It has been proposed to define a smaller GTP-U header that is optimized for real-time applications. Since this optimizedGTP-U header has not been specified yet it is not known how large it would be. However, RTP will have some amountof bandwidth utilization advantage even with an optimized GTP-U header.7 Agreements and associated agreed contributionsThis clause documents agreements that have been reached and makes reference to contributions agreed in RAN-WG3with respect to this study item. This clause is split according to the above mentioned Study Areas.7.1 External standardization7.2 QoS differentiationThe user plane protocol stack standardized for IP transport shall not preclude any of the following two networkconfigurations: - QoS differentiation provided by the IP network on a hop-by-hop basis, and - QoS differentiation provided on an edge-to-edge basis.The standard shall not preclude any of the following alternatives within the transport network: - flow per flow or aggregate classification, - classification based on packet per packet information or on flow addressing information, - classification made on information provided by the transport bearer initiator.The needed information for quality of service differentiation between several UTRAN flows shall be available at the IPlayer used for RNL flow addressing. The UTRAN NEs shall provide this QoS information to this IP layer.It is agreed that: 1) The IP hosts terminating the IP UTRAN transport interfaces (Iu, Iur, Iub) shall support Diffserv codepoint marking. 2) The Diffserv codepoint may be determined based on an operator configurable mapping from the application parameters. 3) This does not preclude the use of RSVP, configured UDP ports or over-provisioning, for example, if this is what an operator wants and its vendors support it. 3GPP
    • Release 5 115 3GPP TR 25.933 V5.4.0 (2003-12)7.3 Transport network bandwidth utilization7.3.1 MultiplexingNo additional multiplexing layer/functionnality shall be specified between UDP/IP and the UTRAN Frame Protocolssince adequate solutions exist below IP achieving the UTRAN requirements.PPPMux [10] provides efficient multiplexing capabilities for PPP.It was agreed that it can bring bandwidth efficiency benefits in some cases (e.g. AAL5 framing) but it was also agreedthat it will not be included in the final specifications.All multiplexing scenarios, introduced in clause 6.4.1.1.1, figure 6-12, bring specific benefits and shall be supported forIP Transport in UTRAN.7.4 User plane transport signallingALCAP is not required over the Iu (PS and CS), Iur and Iub interfaces between two IP UTRAN nodes or between IPUTRAN nodes and IP-CN.7.5 Layer 1 and layer 2 independenceThe use of one exclusive L2 protocol shall not be standardized for IP transport. One or a limited set of L2 protocolsshall be specified and required. The use of any L2 protocol fulfilling the UTRAN requirement towards layer one andtwo, shall not be precluded by the standard. Every IP UTRAN Node shall be able to support the PPP protocol [11]Because of concerns over interworking in the point-to-point case, all IP UTRAN Nodes shall be able to support HDLCframing [12]. This does not preclude the single implementation and use of any other L2/L1 protocols (e.g.PPPMux/AAL5/ATM [15], PPP/AAL2/ATM, Ethernet, MPLS/ATM, etc.). NOTE: No L2 termination between the two peer UTRAN Nodes.It should be clear from above that the decision is left to the operators for selecting the appropriate L2/L1 taken intoaccount the potential issues of interworking and performance.UTRAN NEs having interfaces connected via slow bandwidth PPP links like E1/T1/J1 shall also support IP HeaderCompression [51] and the PPP extensions ML/MC-PPP [20], [21]. Negotiation of header compression [51] over PPPshall be performed via [14].7.6 Radio Network Signalling bearerSCTP protocol shall be supported on Iub interface as signalling bearer for the NBAP application with the followingstack when IP Transport option is selected. 3GPP
    • Release 5 116 3GPP TR 25.933 V5.4.0 (2003-12) NBAP SCTP IP Layer 2 Layer 1On Iub, each signalling bearer between the RNC and Node B shall correspond to one single SCTP stream in UL andone single SCTP stream in DL direction, both streams belonging to the same SCTP association.The following Radio Network Signalling bearer protocol stack shall be supported on the Iu-cs, Iu-ps and Iur interfaceswhen IP Transport option is selected. PL RANAP/RNSAP SCCP M3UA SCTP IP DL Phys. Layer7.7 AddressingThe IP UTRAN nodes shall identify the user plane transport bearers in the Iub, Iur and IuCS interfaces by the UDP portnumber plus IP address (source UDP port number, destination UDP port number, source IP address, destination IPaddress).IP addresses shall be communicated via the radio network layer protocols (RANAP, RNSAP, NBAP) using the NSAPstructure [Annex A of 0], 0 for Iub, Iur and Iu-cs. The NSAP structure (encapsulation) is only used in the radio networklayer, in order to provide explicit identification of the type of the TNL address that is being conveyed by the given RNLprotocol.NSAP structure is not used in RANAP in Iu-ps but Iu-ps shall retain the straight IP addressing as is the case forRelease 99 and Release 4."The following figure depicts the encapsulation of a native IPv6 address in NSAP structure when conveyed in RANAP,RNSAP and NBAP. Octet 1 octet 2 octet 3 octet 4 3GPP
    • Release 5 117 3GPP TR 25.933 V5.4.0 (2003-12) AFI=35 (IANA) ICP=0 (embedded IPv6) IPv6 (byte 1) IPv6 (bytes 2-5) IPv6 (bytes 6-9) IPv6 (bytes 10-13) IPv6 (bytes 14-16) 0000 0000 Figure 7-3: IPv6 address embedded in NSAP structure in RANAP/RNSAP/NBAP7.8 Transport architecture and routing aspectsIP Hosting is a necessary function for a network element supporting of the UTRAN functions (Node B, RNC).UTRAN NEs shall have at least one IP address, onto one or several IP subnets.No restriction is imposed, regarding routing domains and autonomous systems.7.9 Backward compatibility with R99-R4/Coexistence with ATM nodesThe IP transport option shall ensure the co-existence of an ATM only UTRAN Node, an IP only UTRAN Node, or anUTRAN Node with both ATM and IP transport options in the UTRAN. An IP UTRAN node shall provide coexistencewith an ATM UTRAN Node via one of the followings: Rel5 IPIP UTRAN node Rel5 UTRAN node IP transport RNL Dual stack ATM transport option option IP ATM ATM IP Figure 7-4: Dual-stack capability Rel5 IP UTRAN node Interworking RNL TNL Interworking Interworking Function Function Function IP transport ATM transport option option IP ATM IP IPIP ATM ATM Figure 7-5: Interworking function, which is a logical part of the Rel5 IP UTRAN node, that enables each IP UTRAN node a 3GPP compliant Rel99/Rel4/Rel5 interface towards the UTRAN nodes having ATM transport option 3GPP
    • Release 5 118 3GPP TR 25.933 V5.4.0 (2003-12) Rel5 IP Rel5 IP UTRAN Rel5 IP Backward interface node TNL-IWU TNL compatible interface interface IWU Figure 7-6: A TNL Interworking Unit present between the IP UTRAN Node and the ATM UTRAN NodeThe traffic and QoS parameters signalled from the Rel5 IP node to its TNL-IWU in the Rel5 IP TNL-IWU interface aregeneric in nature (transport independent). These parameters are used for determining the needed transport resources inthe TNL-IWU.The following parameters are used: - TNL QoS Class: represented by a 8 bit field (e.g. defines the delay, delay variation and loss priority). The meaning of the bits are operator defined. - Bit rate (max & average). - SDU size (max & average).7.10 SynchronizationIt is recommended that clause 4.2 of TS 25.411 [60] should be split into two subclauses. One for synchronized case(proposal 4.2.1) and one for unsynchronized case (proposal 4.2.2). The synchronized case would be the ATM case. Theunsynchronized case needs different wording than the current proposal. It was suggested that Motorola modifiesproposal 4.2.2 for clarification.It shall be allowed to use Layer 1 interfaces that do not provide synchronization reference information in the IP UTRANtransport.7.11 SecurityIt is agreed that the IP network used for Rel5 IP UTRAN is a closed network.The definition of a closed network is as follows: there is no access from other networks or by other users to any of thephysical interfaces and transmission links used for UTRAN transport (Iu, Iur, Iub).It is also agreed that, within the closed network as above defined, the internal security threats can be considerednegligible.7.12 Iu-cs/Iu-ps harmonization7.13 Iur/Iub User plane protocol stacksOn the Iub interface, the following user plane protocol stack shall be supported when IP Transport option is selected.Note that UDP/IP header compression usage is stated in clause 7.5: 3GPP
    • Release 5 119 3GPP TR 25.933 V5.4.0 (2003-12) Iub FP UDP/IP Data Link Physical LayerOn the Iur interface, the following user plane protocol stack shall be supported when IP Transport option is selected.Note that UDP/IP header compression usage is stated in clause 7.5: Iur FP UDP/IP Data Layer Physical Layer7.14 Iu-cs/Iu-ps user plane protocol stacks7.14.1 Iu-csRTP protocol [59] shall be used on Iu-CS interface resulting in the following stack: PL Iu FP RTP UDP/IP Data Link Physical LayerThe support of RTCP [59] is optional (RNC and MGW may ignore RTCP packets).7.14.2 Iu-psThe protocol stack for the Rel5 Iu-PS User plane is GTP-U [46]/UDP/IP. PL Iu FP GTP-u UDP/IP Data Link Physical Layer7.15 IP version issuesFor Iu, Iur and Iub interfaces, it is agreed that, when IP Transport option is selected: 3GPP
    • Release 5 120 3GPP TR 25.933 V5.4.0 (2003-12) - UTRAN Nodes shall support IP version 6 [27], - UTRAN Nodes may support IP version 4 [49] as an option."Because of transition period it is felt preferable that dual stack support is the best way to evolve. This does not preventsingle stack support (IPv4 or IPv6). The decision is then left for operators taking into account the potential interworkingor performance consequences."8 Specification Impact and associated Change RequestsThis clause is intended to list the affected specifications and the related Change Requests agreed. It also lists thepossible new specifications that may be needed for the completion of the Work Task.8.1 TS 25.4018.1.1 ImpactsThis clause is intended to make reference to contributions and agreements that affect the specification.8.1.2 List of Change RequestsThis clause lists the agreed Change Requests related to the specification.CR 044, CR048, CR052, CR0538.2 TS 25.4108.2.1 Impacts8.2.2 List of Change RequestsCR 0328.3 TS 25.4118.3.1 Impacts8.3.2 List of Change RequestsCR009 3GPP
    • Release 5 121 3GPP TR 25.933 V5.4.0 (2003-12)8.4 TS 25.4128.4.1 Impacts8.4.2 List of Change RequestsCR 0108.5 TS 25.4138.5.1 Impacts8.5.2 List of Change RequestsCR 419, CR4668.6 TS 25.4148.6.1 Impacts8.6.2 List of Change RequestsCR 0308.7 TS 25.4158.7.1 Impacts8.7.2 List of Change RequestsCR 0958.8 TS 25.4208.8.1 Impacts8.8.2 List of Change RequestsCR 024 3GPP
    • Release 5 122 3GPP TR 25.933 V5.4.0 (2003-12)8.9 TS 25.4228.9.1 Impacts8.9.2 List of Change RequestsCR 0118.10 TS 25.4238.10.1 Impacts8.10.2 List of Change RequestsCR 5558.11 TS 25.4248.11.1 Impacts8.11.2 List of Change RequestsCR 0208.12 TS 25.4268.12.1 Impacts8.12.2 List of Change RequestsCR 0228.13 TS 25.4308.13.1 Impacts8.13.2 List of Change RequestsCR 030 3GPP
    • Release 5 123 3GPP TR 25.933 V5.4.0 (2003-12)8.14 TS 25.4328.14.1 Impacts8.14.2 List of Change RequestsCR 0018.15 TS 25.4338.15.1 Impacts8.15.2 List of Change RequestsCR 5978.16 TS 25.4348.16.1 Impacts8.16.2 List of Change RequestsCR 0218.17 TS 25.4428.17.1 Impacts8.17.2 List of Change RequestsCR 0029 Project Plan9.1 Schedulevoid 3GPP
    • Release 5 124 3GPP TR 25.933 V5.4.0 (2003-12) Meeting [expected] Input [expected]OutputAugust, 2002 RAN3#31 CRs to TNL-IWU protocol CRs to be submitted to TSG- RAN#179.2 Work Task Status Milestone Status1. Requirements definition ( 5 ) Completed2. User Plane (6.2) Completed3. Transport Architecture and routing aspects ( 6.9) Completed4. Radio Network Signalling Bearer ( 6.7 ) Completed5. Transport network bandwidth utilisation ( 6.4) Completed6. User plane transport signalling ( 6.5) Completed7. QoS ( 6.3) Completed8. Addressing (6.8 ) Completed9. Backward compatibility with R99-R4/ Study area completed. Agreements on scenarios Coexistence with ATM nodes ( 6.10) completed. No agreement yet on the protocol for external TNL- IWU scenario.10. Layer 1 and Layer 2 independence (6.6) Completed11. Synchronisation (6.11) Completed12. Iu-cs/Iu-ps harmonisation ( 6.13) Completed13. Security ( 6.12) Agreements only in the case of closed network. SA3 has taken the responsibility for further work.14. External Standardisation (6.1) Work in progress related to Coexistence with ATM nodes (external TNL-IWU scenario).10 Open IssuesBackward compatibility with R99-R4/Coexistence with ATM nodes: In the case of TNL Interworking Unit between theIP UTRAN Node and the ATM UTRAN Node, three proposals are still under discussion:1. Bearer control proposal using IETF SIP/SDP2. Bearer Control proposal using a new protocol ("Q.IP-ALCAP"),optimised for concatenation with AAL Type 2 links3. IP-ALCAP based on Q.2630 3GPP
    • Release 5 125 3GPP TR 25.933 V5.4.0 (2003-12) 3GPP
    • Release 5 126 3GPP TR 25.933 V5.4.0 (2003-12)Annex A: Simulation ModelA.1 IntroductionThe simulation model is intended to give criteria to compare different IP based Iub User Plane protocol stacks.ATM/AAL2 will be used as a baseline case for comparison.A.2 Simulation scenariosFour different traffic mixes are defined for the simulation runs: - 100 % voice, - 100 % data, - 80 % voice & 20 % data, with 5 voice users per data user - 20 % voice & 80 % data, with 3 data users per voice user.Data rates are 64, 144 and 384 Kbps.Throughput will be specified as a percentage of used bandwidth at source level, not including TNL protocol overheads(but TNL protocol overhead is included in simulation).NBAP and O&M traffic will not be included in simulations.A.3 Simulation model frameworkThe general simulator model can be split in four parts which are nearly independent from each other. Source Traffic Models RLC/FP Model Protocol Stack Models Last Mile Link Models Figure A-1: General Simulator ModelThis modular concept allows an efficient reuse of simulator modules for the investigation of different proposed protocolstacks and provides transparency for comparison.A.4 Source Traffic ModelsA.4.1 Speech source modelFor simulation, speech sources are based on AMR codecs with only the 12,2 kbps mode. Each AMR 12,2 kbps source ismodelled with an ON/OFF model for DTX, having the following statistics: 3GPP
    • Release 5 127 3GPP TR 25.933 V5.4.0 (2003-12) - Voice Call Duration Distribution: Exponential, mean: 120 s. - Duration of On-state Distribution: Exponential, mean: 3 s. - Duration of Off-state Distribution: Exponential, mean: 3 s.A.4.2 Data source modelTwo equivalent data source models can be used:A.4.2.1 Data Source Model 1Each data user is modelled as a WWW application, consisting of a sequence of file downloads. Each file download ismodelled as a sequence of packet arrivals, having the following statistics.Data model: Each web browsing download has Pareto distributed file size with a parameter α = 1,1, mean 12,000 bytes,minimal file size 1 858 bytes, maximal file size 5 000 000 bytes. The p. d. f. (probability density function) is α ⋅ k α  α +1 , k ≤ x ≤ m  f ( x) =  x α , where α=1.1, k=1858, and m=5,000,000  k , x>m  mα Chop the file into IP packets with size of 1 500 bytes (and one less than 1 500 bytes if size is not a multiple of 1 500).Inter-arrival time of IP packets is exponentially distributed with mean of 8,3 ms. This yields about 1445,78 Kbps IPpacket arrival rate (larger than 64, 144, 384 Kbps data transmission rates). Therefore, the inter-arrival time has nosignificant impact on simulation results.Reading time is defined by the time that the last bit of a file leaves from the RNC (G. data queue on the Figure 1) to thetime that the first bit of the next file arrives to the "C. RLC data buffer". The distribution of reading time is exponentialwith mean 12 sec.A.4.2.2 Data source model 2Interactive data traffic is mainly generated by WWW serving. As for the background traffic, the number of active userswill be assumed to be constant. The parameters are listed in table A-1. Table A-1: Interactive data traffic Class Parameter Values Remark Transmission bit rate [kbit/sec] 64, 144, 384 Packet Call # of packets per call distribution Geometric # of packets per call mean 25 packet inter arrival time distribution Exponential Packet inter arrival time packet inter arrival time mean 0.0083 sec within a packet call inter packet call time distribution Exponential Reading time between to reading time mean 12 sec consecutive packet calls Packet packet size mean 480 bytes αk α packet size distribution limited Pareto Pareto PDF: α +1 x with α=1.1, If X is a Pareto distributed k=81.5, random variable then packet m=66666 sizes are computed as P=min(X,m). Parameters are not independend. 3GPP
    • Release 5 128 3GPP TR 25.933 V5.4.0 (2003-12)A.5 RLC/FP modelA.5.1 Voice TrafficThe RLC layer is transparent for voice traffic. Therefore, no overhead and no functionality is required in the simulationmodel for voice traffic in the RLC layer.In the frame protocol, flows are composed to streams, which results in additional overhead as summarized in table A-2.The frame protocol PDU has a header of 2 Bytes and a trailer of 2 Bytes which results in a general 32 bit overhead perPDU. Each flow in the PDU has an overhead of 8 bits for the TFI, according to [8]. In the frame protocol, each flowwill be padded to 8 bit boundaries which results in additional overhead. Table A-2: Parameters for Stream Overhead Class Parameter Value/Size remark Stream overhead per stream packet (CRC + CFN) 32 bit Overhead added per stream packet, regardless of its contents Flow overhead per flow (TFI) 8 bit Overhead added once per flow in each stream packetThe following example explains the FP PDU generated for the 12,2 kbit/s AMR mode in ON state. 1) Header CRC, CFN 2 bytes; 2) 4 flows (DCH0-3) for class A, class B, class C and signalling; a) 4 x 8 bit TFI 4 bytes; b) 81 bit class A + padding 11 bytes; c) 103 bit class B + padding 13 bytes; d) 60 bit class C + padding 8 bytes; e) signalling 0 or 10 bytes; 3) Payload CRC 2 bytes.Signalling is assumed every 300 ms.A.5.2 Packet data TrafficThe RLC/FP splits the input packets into segments and also aggregates segments to new packets. While the input queueis not empty one or more new packets are created per TTI. Their size is chosen from a connection specific set ofpossible packet sizes. Depending on the signalled TFS, multiple small packets or one large packet are used to satisfy thetransmission demand. If required, padding packets are used as input to extend the new packets to the smallest possibleallowed size. 3GPP
    • Release 5 129 3GPP TR 25.933 V5.4.0 (2003-12) Table A-3: Packet data traffic RLC/FP model parameters Class Parameter Value/Size remark Scheduler inter packet time TTI of the connection Packet Control packet overhead 16 bit Length Indicator Segment segment size set {0, 320} bits Control segment overhead 16 bit Transport Peak data rate 64 kbps Format 144 kbps 384 kbps RLC Buffer size 256 kByte TTI 40 ms 20 ms optional TF set size 64 kbps {0,1,2,3,4,6,8} x 336 bits TF set for 20 ms 144 kbps {0,1,2,4,8,16,18} x 336 bits see 384 kbps {0,1,2,4,8,12,16,20,24,32,40,48} x 336 bits TSGR1#14(00)08 44A.6 Protocol Stack ModelsA.6.1 OverviewBy investigating the protocol stacks for IP transport e.g. PPPmux or CIP one can find that the modules needed forimplementation are: - header compression (FFS); - packetizer; - queues; - and the scheduler providing the prioritization for the voice traffic.In the different protocol stacks these functions are provided by different layers. For the performance study thesefunctionality can be modelled equally for all protocol stacks. The performance depends only on: - header overhead per stream which can not be shared; - header overhead per container to be sent over the link; - the position of the packetizer; - the position of the queues and scheduler.The overhead can be introduced by parameters. The positions for the packetizer and the queues with the schedulerdepend on the chosen implementation of the protocol stack. The implementations can be optimized per protocol stackdepending on the QoS strategy. Two possible structures are shown in figures A-2 and A-3. The structure implementedin the simulator model shall be given together with the simulation results. 3GPP
    • Release 5 130 3GPP TR 25.933 V5.4.0 (2003-12) data data stream stream voice voice stream stream Overhead Overhead / stream / stream Overhead Overhead / stream / stream Segment. Segment. packetizer packetizer ∆ t ∆ t scheduler Overhead / container Figure A-2: Implementation Structure, Variant 1 3GPP
    • Release 5 131 3GPP TR 25.933 V5.4.0 (2003-12) data data stream stream voice voice stream stream Overhead Overhead / stream / stream Overhead Overhead / stream / stream Segment. Segment. scheduler packetizer ∆ t Overhead / container Figure A-3: Implementation Structure, Variant 2A.6.2 Module FunctionsA.6.2.1 Header Compression (FFS) [Editors note: contributions are invited]A.6.2.2 PacketizerThe packetizer composes the input packets to containers up to a maximum size or up to a maximum time. This processintroduces additional delay to the streams. Table A-4: Packetizer Parameters Class Parameter Example Value remark Container time out 0,003 sec Maximum delay time Control max container size 2400 bit Maximum container sizeA.6.2.3 QueuesDue to the limited bandwidth of the Last Mile Link Model queues must be provided. This process introduces additionaldelay to the streams. Table A-5: Queue Parameters Class Parameter Example Value remark Queue Control Strategy FIFO max. size infinite No packet loss 3GPP
    • Release 5 132 3GPP TR 25.933 V5.4.0 (2003-12)A.6.2.4 Segment FunctionThe segment function splits the input packets to segments down to a fixed size. The related overhead shall beintroduced on a per stream or per container basis depending on the implementation. This process introduces no delay tothe streams. Table A-6: Segment function Parameters Class Parameter Value remark Segment Segment size tbd ControlA.6.2.5 SchedulerThe scheduler is a functional entity, which provides prioritized service for two input queues. In our model one voicequeue and one data queue are assumed. The voice queue shall be serviced until empty, at which time the data queueshall be serviced until the voice queue has become non-empty or the data queue is also empty. Voice packets cannotpreempt data packets.A.6.3 ExamplesIn the following table examples are given how the Protocol Stack Model could be used for protocols already introducedin above clauses. Table A-7: Examples Protocol Structure Overhead/stream Overhead/container Protocol 2 Variant 2 CUDP 3 byte PPPID 1 byte PPPlen 1 byte PPPmux 1 byte HDLC 3 byte Protocol 1 Variant 1 CIP 3 byte CUDP 4 byte PPP 1 byte HDLC 3 byteA.7 Last Mile Link ModelsA point-to-point connection between the Edge-Router and the Node B is considered as Last Mile Link. It shall bemodelled as infinite server providing a fixed service rate. Table A-8: Link Parameters Class Parameter Value remark Link Model n*E1 n=1 1,92 Mbps n=2 n=3A single E1 link is assumed.A.8 Performance criteriaThe most important performance criteria are delay and link utilization. The delay figures contain the packetizationdelay, the queuing delay and the transmission delay per individual stream. Confidence intervals shall be calculatedbased on the results of several independent simulation runs. Empirical studies have shown that about 10 simulation runsare the optimum to minimize computation time by still giving good statistical confidence. The duration of onesimulation run depends on the required confidence interval size. It is not possible to make an accurate forecast about the 3GPP
    • Release 5 133 3GPP TR 25.933 V5.4.0 (2003-12)required simulation time to achieve good statistical confidence. Therefore, the simulation time must be increased if theresults are not meaningful. It is important for the reporting of simulation results that confidence intervals are included. Table A-9: Performance criteria Statistic Confidence Level Remarks 99.9-percentile voice delay 0.95 link utilization Confidence level not important, can be calculated analytically 99.9-percentile transmission delay 0.95 99.9-percentile packetization delay 0.95 3GPP
    • Release 5 134 3GPP TR 25.933 V5.4.0 (2003-12)Annex B: AppendixThis appendix refers to "Bearer Control proposal using modified Q.AAL2" solution for ATM/IP interworking describedin clause 6.10.5.2.For the Delta-Specification [IPALCAP], it is supposed to include in [52] the changes as highlighted in subclausesbelow:B.1 Additions table 7-6, clause 7.2.2 of [2]: Parameters of the AAL type 2 signalling protocol messages Table 7-6/IP-ALCAP: Parameters of the AAL type 2 signalling protocol messages (part 1 of 2) Message Parameter ERQ ECF REL RLCCause − − M (Note 5)Connection element identifier (Note 6) M − − −Destination E.164 service endpoint address (Note 3) − − −Destination NSAP service endpoint address (Note 3) − − −Destination signalling association identifier (Note 1) (Note 2) M M MLink characteristics O − − −Originating signalling association identifier M M − −Served user generated reference O − − −Served user transport O − − −Service specific information (audio) (Note 4) − − −Service specific information (multirate) (Note 4) − − −Service specific information (SAR-assured) (Note 4) − − −Service specific information (SAR-unassured) (Note 4) − − −Test connection indicator O − − −IP endpoint identifier O O − −M Mandatory parameterO Optional parameter− Parameter not presentNOTE 1: This row designates the destination signalling association identifier field in the message header.NOTE 2: The destination signalling association identifier field contains the value "unknown".NOTE 3: Exactly one of these parameters must be present in an instance of the message.NOTE 4: At most one of these parameters is present in an instance of the message.NOTE 5: The "Cause" parameter is present in the release confirm message if:NOTE 6: The Connection element identifier contains the value "0" if the IP endpoint identifier exists.a) the RLC is used to reject a connection establishment; orb) the cause reports unrecognized information received in the REL message. 3GPP
    • Release 5 135 3GPP TR 25.933 V5.4.0 (2003-12)B.2 Additions to table 7-7, clause 7.2.2 of [2]: Parameters of the AAL type 2 signalling protocol messages Table 7-7/Q.2630.1: Identifiers of the AAL type 2 message parameters (concluded) AAL type 2 parameter Ref. Acronym IdentifierCause 7.3.1 CAU 00000001Connection element identifier 7.3.2 CEID 00000010Destination E.164 service endpoint address 7.3.3 ESEA 00000011Destination NSAP service endpoint address 7.3.4 NSEA 00000100Link characteristics 7.3.5 ALC 00000101Originating signalling association identifier 7.3.6 OSAID 00000110Served user generated reference 7.3.7 SUGR 00000111Served user transport 7.3.8 SUT 00001000Service specific information (audio) 7.3.9 SSIA 00001001Service specific information (multirate) 7.3.10 SSIM 00001010Service specific information (SAR-assured) 7.3.11 SSISA 00001011Service specific information (SAR-unassured) 7.3.12 SSISU 00001100Test connection indicator 7.3.13 TCI 00001101IP endpoint identifier 7.3.14 IPEID xxxxxxxxB.3 Additions to clause 7.3 of [2]: Parameter specification of the AAL type 2 signalling protocol messages7.3.14 IP Endpoint IdentifierThe sequence of fields in the IP endpoint identifier parameter is shown in table 7-xx. Table 7-xx/IP-ALCAP – Sequence of fields in the IP endpoint identifier parameter Field No. Field Ref. 1 UDP port number 7.4.19 2 IP address 7.4.20B.4 Additions to clause 7.4 of [2]: Field specification of the AAL type 2 signalling protocol parameters7.4.19 UDP port numberThe structure of the UDP port number field is shown in Table 7-yy; the field is a fixed size field of 2 octets. Table 7-29/IP-ALCAP – Structure of the UDP port number field 8 7 6 5 4 3 2 1 Octets 1 2 UDP Port Number 3GPP
    • Release 5 136 3GPP TR 25.933 V5.4.0 (2003-12)7.4.20 Served user transportThe structure of the IP address field is shown in Table 7-zz; the field is a variable size field. Table 7-zz/IP-ALCAP – Structure of the IP address field 8 7 6 5 4 3 2 1 Octets Field length 1 2 IP address nThe IP address field length can be either 4 (IPv4) or 16 (IPv6) octets.B.5 Additions to clause 8.2.2 of [2]: Nodal functions for AAL type 2 nodes without served user interaction8.2.2.4 Interworking with AAL type 2 nodes conforming only to ITU-T RecommendationQ.2630.1Interworking with AAL type 2 nodes conforming only to ITU-T Recommendation Q.2630.1 is guaranteed by setting thecompatibility information on new messages and parameters as specified in annex C.B.6 Additions to the annex of [2]: Nodal functions for AAL type 2 nodes without served user interaction 3GPP
    • Release 5 137 3GPP TR 25.933 V5.4.0 (2003-12)Annex C: Coding of the compatibility informationC.1 Coding of the compatibility informationC1.1 Parameter compatibilityTo ensure backward compatibility with AAL type 2 nodes conforming only to ITU-T Recommendation Q.2630.1, theparameter compatibility field of the new or differently used parameters shall be set as indicated in table C-1. Table C-1: Coding of the parameter compatibility information 8 7 6 5 4 3 2 1 pass-on not possible General action send notification instruction send notification instructionParameter Res. indicator indicator Res indicator indicator .IP Endpoint Identifier (IPEID) 0 0 01 0 0 01in RLC message do not send discard do not send discard notification parameter notification parameter 3GPP
    • Release 5 138 3GPP TR 25.933 V5.4.0 (2003-12)Annex D:Change History Change historyDate TSG # TSG Doc. CR Rev Subject/Comment Old New03/2002 15 - - Approved at TSG RAN #15 and placed under Change Control - 5.0.006/2002 16 RP-020421 001 2 IP-ALCAP: The ITU-T Solution 5.0.0 5.1.009/2002 17 RP-020628 003 1 Rapporteurs Corrections to TR25.933 IP Transport in UTRAN 5.1.0 5.2.006/2003 20 RP-030323 004* 2 Corrections to ATM-IP interworking 5.2.0 5.3.012/2003 22 RP-030681 005 Correction of PE-node as an ATM switch Solution 5.3.0 5.4.0 Note: *: corrected from CR003 to CR004 after RAN #20 3GPP