P810D4
advertisement
Project P810-PF Wireless ATM Access and Advanced Software Techniques for Mobile Networks Architecture Deliverable 4 Principles and Solutions for IP based Mobile Networks Suggested readers: Strategic Planners, Researchers and Consultants Involved in the Development of Advanced Mobile Networks. For full publication November 1999 EURESCOM PARTICIPANTS in Project P810-PF are: BT TELECOM ITALIA S.p.a. Deutsche Telekom AG France Télécom Koninklijke PTT Nederland N.V. Portugal Telecom S.A. This document contains material which is the copyright of certain EURESCOM PARTICIPANTS, and may not be reproduced or copied without permission. All PARTICIPANTS have agreed to full publication of this document. The commercial use of any information contained in this document may require a license from the proprietor of that information. Neither the PARTICIPANTS nor EURESCOM warrant that the information contained in the report is capable of use, or that use of the information is free from risk, and accept no liability for loss or damage suffered by any person using this information. This document has been approved by EURESCOM Board of Governors for distribution to all EURESCOM Shareholders. 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks Preface This book will give you quite a wide impression of the techniques that are leading towards the future mobile networks. It also exploits some of the architectures that will form the basis of such evolution. This book aims to blend the traditional cellular networks with emerging IP techniques, following the success that experience both Internet - in terms of users - and cellular networks - in terms of users and revenues. A lot of activities in this area are ongoing; the book will provide you with a knowledge about basic principles and recommendations to face these topics and to understand the technical basis of the emerging solutions. Nevertheless, as you will realise browsing through the following pages, the technical overview and results presented here are addressing issues from a general point of view. Therefore, telecommunications operators will have to go more deeply into these issues, considering their existing network and their own national constraints as well as economic criteria, before making any choice concerning an implementation or a technology to be deployed. 1999 EURESCOM Participants in Project P810-PF page i (xiii) Principles and Solutions for IP based Mobile Networks Deliverable 4 Executive Summary This book is produced by the EURESCOM Project P810. P810 was investigating possible network architectures for future mobile networks with a thorough view on access and core network technologies. Starting from an ATM-centric view and expanding the work on a general IP-centric view on mobile networks, the project presents its final considerations in this book, which wants to provide the technical tools and the evolution vision required in order to drive the future of mobile networks on the IP/cellular network integration path. The evolution (and success) of IP is mainly driven by the vast number of available and upcoming applications and the ongoing integration of multiple applications under a single user interface (e.g. Web browsers), which makes it very attractive for service provision in mobile networks. IP usually assumes very little from the underlying transport platform and copes with heterogeneous underlying technologies. ATM now can be seen as one transport platform solution (with specific advantages) among others. P810 thus formulated its main goals as: To picture the vision of an IP and mobile telecommunication network blend and to provide guidance in how to apply IP solutions to a mobile communications network. The book organisation is presented in the following description. The IP and mobile telecommunication network blend This section provides the rationale of the emerging role of IP and some considerations on the evolution of Mobile networks. Some general scenarios for UMTS evolution are presented, starting from the incoming GPRS network. IP transport for the mobile user This section provides an overview of the GPRS functional architecture, treats Mobile IP as a basis for global mobility across different networks and provides an introduction to local mobility schemes in wireless LANs and to related IP micromobility topics. Real-Time services on IP networks This section discusses topics on how to provide real-time services in IP networks with a focus on queuing and resource reservation techniques as well as IETF proposals for differentiated and integrated services and IP tag-switching techniques. Furthermore, the problem of how to provide IP QoS with mobile terminals is addressed. Service provisioning in an IP based scenario In the first part this section gives an introduction and overview of the Wireless Application Protocol (WAP) and related topics. In the second place selected topics of IP-server based VHE provisioning are dealt with. Integration and interworking with the existing networks This section gives an overview of IP call control and session management techniques based on H.323 and SIP. Additionally, interworking and integration aspects for IP networks and Intelligent Networks (IN) are discussed. In this context the role of user and service profiles is dealt with. The final part of this section then goes into IP interworking with SS7 signalling and gives some details on IP routeing in cellular networks and protocol mapping. page ii (xiii) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks Evolution of UMTS towards IP based solutions This conclusive section provides an overview of possible emerging architectures for mobile network based on IP solutions, taking into account GSM/GPRS, UTRAN and wireless LANs accesses. A basic description of the key elements is provided, taking into account networks as well as service features. 1999 EURESCOM Participants in Project P810-PF page iii (xiii) Principles and Solutions for IP based Mobile Networks Deliverable 4 List of Authors Sophie Aveline CNET France Telecom DMR/RMO 38-40 rue du Général Leclerc 92131 Issy-les-Moulineaux, France Guillaume du Roscoat CNET France Telecom DMR/RMO 38-40 rue du Général Leclerc 92131 Issy-les-Moulineaux, France Bernd Bochow GMD-FOKUS Kaiserin-Augusta-Allee 31 D-10589 Berlin, Germany Georg Neureiter T-Nova Deutsche Telekom Innovationsgesellschaft mbH Active Networks & Mobility (T34.3) Goslarer Ufer 35 D-10589 Berlin, Germany Guilhem Ensuque BT Advanced Communications Technology Centre Mobility Futures Unit, B55-131B Adastral Park, Martlesham Heath Ipswich IP5 3RE, United Kingdom Maria Pia Galante CSELT MB/SA Via Reiss Romoli, 274 10148 Torino, Italy Enrico Scarrone CSELT MB/SA Via Reiss Romoli, 274 10148 Torino, Italy page iv (xiii) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks Table of Contents Preface ............................................................................................................................ i Executive Summary ....................................................................................................... ii List of Authors .............................................................................................................. iv Table of Contents ........................................................................................................... v Abbreviations and Acronyms ...................................................................................... vii 1 The IP and mobile telecommunication network blend........................................... 1 1.1 The vision .................................................................................................... 1 1.2 What will be UMTS? ................................................................................... 2 1.3 Evolving from GPRS ................................................................................... 3 2 IP transport for the mobile user .............................................................................. 5 2.1 General Packet Radio Service ...................................................................... 5 2.1.1 GPRS reference model .................................................................... 6 2.1.2 GPRS transmission protocol stacks ................................................ 7 2.1.3 Data packet routeing in GPRS ........................................................ 8 2.1.4 Basic procedures for GPRS........................................................... 10 2.1.5 Location Management in GPRS ................................................... 11 2.1.6 Evolution scenario of GPRS towards an IP-based UMTS ............ 12 2.2 Mobile IP for global roaming .................................................................... 15 2.2.1 Generalities ................................................................................... 15 2.2.2 Enhancements to Mobile IPv4 ...................................................... 19 2.2.3 Mobile IPv6 .................................................................................. 20 2.2.4 Mobile IP limitations and potential solutions ............................... 21 2.2.5 Possible use/role of Mobile IP for UMTS .................................... 23 2.3 Registration for mobile terminals considering an IP only based network ...................................................................................................... 27 2.3.1 Radio access authentication and MIP authentication .................... 27 2.3.2 UMTS registration with Mobile IPv4 ........................................... 28 2.3.3 UMTS registration with Mobile IPv6 ........................................... 32 2.3.4 Major constraints for Mobile IP in third generation mobile system ........................................................................................... 33 2.4 Wireless LANs and mobility ..................................................................... 34 2.4.1 Layer 2 mobility support in Wireless LANs ................................. 34 2.4.2 Layer 3 Local Mobility: ‘cellular IP’ ............................................ 38 3 Real-Time services on IP networks...................................................................... 45 3.1 Queuing techniques.................................................................................... 45 3.2 IntServ and RSVP ...................................................................................... 46 3.2.1 RSVP messages ............................................................................ 46 3.2.2 RSVP issues and limits ................................................................. 47 3.2.3 Towards a layered architecture ..................................................... 47 3.3 DiffServ ..................................................................................................... 47 3.4 ATM .......................................................................................................... 49 3.5 MPLS ......................................................................................................... 49 3.6 Complete architecture to manage QoS in IP networks .............................. 50 3.7 Guarantee of QoS with mobile terminals................................................... 50 3.7.1 Difficulties due to the mobility of IP terminals ............................ 50 3.7.2 Solutions for IP terminals ............................................................. 51 1999 EURESCOM Participants in Project P810-PF page v (xiii) Principles and Solutions for IP based Mobile Networks 3.7.3 Deliverable 4 Combining UMTS - IP .................................................................. 52 4 Service provisioning in an IP based scenario ....................................................... 53 4.1 Wireless Application Protocol: Internet applications for mobile users ...... 53 4.1.1 Why WAP? ................................................................................... 53 4.1.2 The WAP model ............................................................................ 54 4.1.3 The WAP architecture ................................................................... 55 4.2 Server-based VHE ...................................................................................... 57 4.2.1 IP-based VHE service provisioning .............................................. 58 5 Key elements for integration ................................................................................ 60 5.1 Call Control aspects ................................................................................... 60 5.1.1 Basic IP Call Management ............................................................ 60 5.1.2 H.323 call control .......................................................................... 62 5.1.3 SIP call control .............................................................................. 63 5.1.4 Gateway architecture ..................................................................... 65 5.1.5 IP call management in UMTS ....................................................... 66 5.2 Mobility Management integration/interworking ........................................ 68 5.2.1 Architectural Options .................................................................... 68 5.2.2 Architectural Proposals ................................................................. 70 5.3 Sharing user profiles................................................................................... 73 5.3.1 From service profiles to user profiles ............................................ 74 5.3.2 Subscriber profiles ......................................................................... 76 5.3.3 Subscriber profiles in a hybrid CO/CL environment..................... 76 5.4 IN integration/interworking........................................................................ 77 5.4.1 Network architecture ..................................................................... 77 5.4.2 CO/CL-interworking based on Intelligent Peripheral ................... 78 5.4.3 Service logic interworking ............................................................ 80 5.4.4 Mobile terminal access to IN services in the hybrid CO/CL scenario.......................................................................................... 82 5.4.5 IN service logic in the TIPHON environment ............................... 84 5.5 SS7 integration with IP networks ............................................................... 85 5.5.1 General information about IP routing protocols ............................ 86 5.5.2 Cellular networks: OSPF and BGP as signalling transport network .......................................................................................... 89 5.5.3 Protocol mapping .......................................................................... 92 5.5.4 SS7 on IP? ..................................................................................... 94 6 Evolution of UMTS towards IP based solutions .................................................. 95 6.1 Evolution scenarios .................................................................................... 95 6.2 Key networks components and features ..................................................... 98 References .................................................................................................................. 103 page vi (xiii) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks Abbreviations and Acronyms 3G Third Generation 3G.IP 3G.IP focus group 3GPP Third Generation Partnership Project AAA Authorisation Authentication & Accounting AAL ATM Adaptation Layer AAL2 AAL type 2 ABR Area Border Router ADSL Asymmetric Digital Subscriber Line ARP Address Resolution Protocol AS Autonomous System ASBR Autonomous System Border Router ATM Asynchronous Transfer Mode BGP Border Gateway Protocol B-INAP Broadband-INAP B-ISDN Broadband Integrated Services Digital Network BRAN Broadband Radio Access Network BS Base Station BSC Base Station Controller BSS Base Station System BSSAP Base Station System Application Part BSSGP Base Station System GPRS Protocol BTS Base Transceiver Station CAC Call Admission Control CAMEL Customised Application for Mobile network Enhanced Logic CAP CAMEL Application Part CBT Core Based Tree CC/PP Composite Capability/Preference Profiles CDMA Code Division Multiple Access CL ConnectionLess CN Core Network CO Connection Oriented CoA Care-of-Address CORBA Common Object Request Broker Architecture CPU Central Processing Unit 1999 EURESCOM Participants in Project P810-PF page vii (xiii) Principles and Solutions for IP based Mobile Networks Deliverable 4 CS Capability Set CSCF Call State Control Function CSE CAMEL Service Environment DAB Digital Audio Broadcasting DHCP Dynamic Host Configuration Protocol DLC Digital Link Control DNS Domain Name Service DS Differentiated Service DSCP Differentiated Service Code Point DVMRP Distance Vector Multicast Routing Protocol EDGE Enhanced Data rate for the Gsm Evolution EGP Exterior Gateway Protocol ESP (IP) Encapsulating Security Payload ETSI European Telecommunications Standards Institute FA Foreign Agent FH Frequency Hopping FIFO First In First Out GGSN Gateway GPRS Support Node GPRS General Packet Radio Service GPS Generalised Processor Sharing GRE Generic Record Incapsulation GSM Global System for Mobile Communication GSN GPRS Support Node GSTN General Switched Telephone Network GTP GPRS Tunnelling Protocol HA Home Agent HAWAII Handoff-Aware Wireless Access Internet Infrastructure HDAA Home Domain Allocation Agency Hiperlan High Performance Radio Local Area Network HLR Home Location Register HTML HyperText Markup Language HTTP HyperText Transfer Protocol IAPP Inter Access Point Protocol ICMP Internet Control Message Protocol IEEE Institute for Electrical and Electronics Engineering IETF Internet Engineering Task Force page viii (xiii) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks IESG Internet Engineering Steering Group IGSN Internet GPRS Support Node IMSI International Mobile Subscriber Identity IMT International Mobile Telecommunication IN Intelligent Network INAP IN Application Protocol IP Internet Protocol IP Intelligent Peripheral IPCP Internet Protocol Control Protocol IPsec Internet Protocol Security ISDN Integrated Services Digital Network ISP Internet Service Provider ISUP ISDN-User Part ITU International Telecommunication Union IWF Interworking Function LAN Local Area Network LDAP Lightweight Directory Access Protocol LLC Logical Link Control LSP Label Switched Path LSR Label Switched Router MAC Media Access Control MAP Mobile Application Protocol MCU Multipoint Control Unit ME Mobile Equipment MExE Mobile Station Application Execution Environment MGCP Media Gateway Control Protocol MIP Mobile IP MM Mobility Management MMAC MultiMedia Access Control MN Mobile Node MOSPF Multicast Open Shortest Path First MPLS Multi Protocol Label Switching MS Mobile Station MSC Mobile Switching Centre MSISDN Mobile Station ISDN MT Mobile Terminal 1999 EURESCOM Participants in Project P810-PF page ix (xiii) Principles and Solutions for IP based Mobile Networks MTP2 Message Transfer Part layer 2 MTP3 Message Transfer Part layer 3 NA Network Architecture NAI Network Access Identifier NAS Network Access Server NAS Non Access Stratum NAT Network Address Translation NBAP Node B Application Protocol NO Network Operator NSAP Network Service Access Point NSS Network Sub System OSI Open Systems Interconnection OSPF Open Shortest Path Protocol PCS Personal Communication System PDA Personal Digital Assistant PDN Packet Data Network PDP Packet Data Protocol PDU Protocol Data Unit PGPS Packet GPS PHB Per Hop Behaviour PHS Personal Handyphone System PIM Protocol Independent Multicast PIR Project Internal Result PLMN Public Land Mobile Network PPP Point to Point Protocol PSTN Public Switched Telephone Network PTM Point To Multipoint PTP Point To Point QoS Quality of Service R Router RA Routing Area RAI Routing Area Identity RAN Radio Access Network RANAP Radio Access Network Application Part RARP Reverse Address Resolution Protocol RAS Registration, Admission and Status page x (xiii) Deliverable 4 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks RED Random Early Detection RIO RED In and Out RIP Routing Information Protocol RLC Radio Link Control RNC Radio Network Controller RNS Radio Network System RNS Radio Network Subsystem RNSAP Radio Network Subsystem Application Protocol RRC Radio Resource Control RSVP Resource reSerVation Protocol RTCP Real Time Control Protocol RTP Real Time Protocol SAP Service Access Point SAT SIM Application Toolkit SCCP Signalling Connection Control Part SCCP-SIM Signalling Connection Control Part - SIMulated SCF Signalling Control Function SCP Service Control Point SDF Service Data Function SGSN Serving GPRS Support Node SIM Subscriber Identity Module SIP Session Initiation Protocol SLA Service Level Agreement SLS Sequence Link Selection SMS Short Message Service SMTP Simple Mail Transfer Protocol SNDCP SubNetwork Dependent Convergence Protocol SoHo Small office Home office SPC Signalling Point Code SRF Specialised Resource Function SRNS Serving RNS SS7 Signalling System 7 SSF Service Switching Function SSP Service Switching Point SW Software T/TCP Transaction/Transmission Control Protocol 1999 EURESCOM Participants in Project P810-PF page xi (xiii) Principles and Solutions for IP based Mobile Networks Deliverable 4 TCAP Transaction Capabilities TCP Transmission Control Protocol TCP/IP Transmission Control Protocol/Internet Protocol TDMA Time Division Multiple Access TIPHON Telecommunications and Internet Protocol Harmonisation Over Networks TOS Type Of Service TPP Third Party Provider TSAP Transport layer Service Access Point UDP User Datagram Protocol UE User Equipment UMTS Universal Mobile Telecommunication System UPT Universal Personal Telephony URI Uniform Resource Identifier URL Uniform Resource Locator USIM User SIM USSD Unstructured Supplementary Service Data UTRAN UMTS Terrestrial Radio Access Network VASF Value Added Service Function VC Virtual Circuit VHE Virtual Home Environment VLR Visiting Location Register VoIP Voice over IP W3C World Wide Web Consortium WAE Wireless Application Environment WAN Wide Area Network WAP Wireless Application Protocol W-CDMA Wideband CDMA WDP Wireless Datagram Protocol WFQ Weighted Fair Queuing WIN Wireless IN W-LAN Wireless LAN WML Wireless Markup Language WRED Weighted RED WSP Wireless Session Protocol WTA Wireless Telephony Application page xii (xiii) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks WTAI Wireless Telephony Application Interface WTLS Wireless Transport Layer Security WTP Wireless Transaction Layer WWW World Wide Web 1999 EURESCOM Participants in Project P810-PF page xiii (xiii) Deliverable 4 1 Principles and Solutions for IP based Mobile Networks The IP and mobile telecommunication network blend It is now nearly certain that IP will be the dominant end-to-end protocol used by a tremendous number of available applications. Moreover, recent developments in IP technology may open up the possibility of efficient transport of real-time multimedia content. This book proposes an evolved architecture that blends the roles of a classic Mobile Operator and Internet Service Provider. In this framework, GPRS (as it is IP-based) could be taken as the starting point of an evolution enabling to bridge the gap between a most-likely GSM-evolved UMTS Release 99 network and the full-blown mobile multimedia vision for UMTS. The ultimate goal is to converge the developments in mobile technologies and IP technologies, taking the best of each. 1.1 The vision Two parallel trends nowadays exist: the explosion of Internet usage with fixed accesses and the explosion of the mobile market (mainly GSM in Europe). Next generation mobile networks aim to provide the possibility of high data rate access with mobile terminals, for example for Internet consultation. The new mobile system is called UMTS (Universal Mobile Telecommunication System) within standardisation bodies. In such a context, the non-exhaustive list below illustrates some examples of areas where convergence or adaptation between classic mobile communications and the IP world could emerge. IP in the end-to-end The Internet protocol suite is becoming a determining element for user data applications, often the only choice available. Emerging mobile systems as UMTS take into account Internet protocols at the user application and transport layers, whereas other emerging technologies as wireless IP or cellular IP extend the use of those protocols to provide mechanisms for mobility management, handover, … Global mobility IP mobility procedures (evolution of Mobile IP and micro-mobility schemes) may provide mobility across data networks and also inside wireless LANs. Classic mobility management schemes will continue to play a central role in the access part and will probably also rely on IP for the transport of signalling messages (UMTS Release 2000). A common server platform to handle transactions In the future, HTTP may incorporate IP call control (e.g. SIP, H.323) to provide the basis of the VHE. A common method for call and session management of multimedia calls and access to supplementary services will evolve from the already well known and broadly accepted Web services towards a unified and portable user interface. IP servers for Supplementary Services Multimedia session control architecture and call processing could provide IN-like services and interworking with classic intelligence. Then, evolving from the current IN architecture, IN services might rely to a greater extent on IP-based 1999 EURESCOM Participants in Project P810-PF page 1 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 servers and services, finally converging to a common service platform to provide all the required service capabilities for the VHE. Quality of Service in large-scale IP networks Since current IP networks are not yet well suited for real-time services, evolution of IP will include novel approaches to allow for service guarantees even in largescale networks. Where today’s IP networks have to be over-dimensioned to a fair amount in order to satisfy the demands of multimedia communications, future IP networks will provide multiple service categories (DiffServ and edge buffering/shaping) and resource reservation (IntServ and RSVP). Real-time GPRS in the access part In the evolution of GPRS towards UMTS, interactive mobile multimedia applications with guaranteed Quality of Service will be supported. In this context, the integration of IP services with guaranteed Quality of Service will make application development to become the major driving force for the success of mobile system provision. 1.2 What will be UMTS? Release 99 of UMTS will be essentially GSM Release 99 (that is with CAMEL and GPRS) with the addition of a UTRAN access network. UTRAN is based on WCDMA and AAL2 switching, the Core Network is an evolution of GSM/GPRS network: voice will be over the GSM core network and data mainly over the IP-based GPRS backbone. This will give higher capacity for the operator and possibly higher bit rates for the end user. However, we can see that this is a very watered-down version of the initial vision for UMTS. Notably, the VHE (common look & feel across networks and automatic customisation of services) will be almost non-existent for data services and very restricted for voice services (CAMEL); and the bit rates offered to the user will be well below the 2Mbps target that was first envisioned. Given the above context, the realisation of the full-blown UMTS vision with full VHE capability, multimedia content and high bit rates on demand seems difficult to achieve in an evolutionary fashion. At the same time, an innovative solution may be too radical a change to be adopted by existing GSM operators in the deployment timescales of UMTS as they would require too big an increment in investment on top of their newly acquired GPRS, CAMEL and UTRAN infrastructures. The other trend that has to be accounted for is the growing importance of IP as possibly sole end-to-end data transport protocol due to the success of applications such as web browsing and email. It seems therefore sensible to draw up a UMTS architecture based on IP and GPRS. This is also the approach followed inside focus groups like 3G.IP 1, that have heavily influenced the requirements for UMTS Release 2000 (R00). First, GPRS is attractive as a starting point for evolution towards UMTS since GSM operators are committed to it but new entrants are on a pal with established operators as the system has not been deployed yet. Second, GPRS is based on IP and is still evolving, offering an opportunity of convergence. Indeed, recent developments in the IETF tend to make possible to 1 It is not a case: some companies and people that have participated to and developed their knowledge in P810 are also deeply involved in 3G.IP. page 2 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks develop an entirely IP-based real-time mobile telephony and multimedia service. Convergence with GPRS should be sought after for acceptance in 3GPP as the UMTS Core Network standard for Release 2000. For high bit rate connectivity and private network coverage, the interworking of this IP/GPRS-based UMTS with wireless LANs (2.4 GHz and 5GHz: IEEE 802.11 and Hiperlan families) should be pursued. Another interesting trend is the emergence of industry standards, aside of the politically-approved standards, such as WAP for web content formatting on wireless links and Bluetooth for short range radio links in the SoHo or Home environment. 1.3 Evolving from GPRS As outlined above, GPRS constitutes an interesting starting point from which to evolve towards UMTS. Incremental evolutionary steps from the current GPRS architecture should enable to achieve the UMTS vision in the planned time scales and provide the opportunity of convergence with the evolution of IP services as standardised in the IETF so that the UMTS operator will blend the roles of ISP and classic GSM/Mobile operator. The following evolutionary steps are foreseen: Greater GPRS flexibility Implementing the optional interfaces between the GPRS nodes (SGSN and GGSN) and the VLR/MSC and HLR will significantly enhance GPRS flexibility. Then, CAMEL interaction with GPRS will allow early value-added services such as packet screening (equivalent to an individual firewall), fraud-control, operatorspecific services such as pre-pay… Support for real-time services Since the aim of this book is to investigate the possibility to have a single UMTS internetworking technology based on IP, real time interactive services such as telephony and videoconferencing will be provided by IP protocols. GPRS has been designed to make optimum use of the radio bandwidth using the characteristics of bursty data. Even with its ‘guaranteed QoS’ features, the support of real time, short delay, services will be unsuitable in GPRS’s current form. Indeed, GPRS currently guarantees only delays in the seconds range. For real-time services such as interactive voice or videoconferencing, end-to-end delay and delay variation have to be constrained in the 100 ms and 10 ms range respectively. In this context, the introduction of a UMTS access network will allow microdiversity functions enhancing handover procedures and delays. At this time, IP protocols do not adapt content of a transmission on the characteristics and variations of the transmission. Consequently, they need specific procedures related to the mobile access and core networks to provide QoS adaptation. Interworking with the PSTN Current analysis shows that IP telephony will not wipe out the standard telephony service overnight. and that bit transport costs are similar in the PSTN and IP domain. Thus, there will be a (growing) demand for seamless interworking between traditional telecommunications networks and IP-based multimedia communications based on IP call control. A framework for PSTN interworking is now emerging amongst IP vendors and standardised in the IETF (mmusic, iptel, 1999 EURESCOM Participants in Project P810-PF page 3 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 ipsg, pint… working groups); the ITU also has a framework, albeit less generic, based on the H.323 standard. Such standards could be successfully re-used in an evolved GPRS for interworking to the PSTN. In such a network composition the critical area of billing should include IP telephony and circuit switched telephony, as well as networks interworking (UMTS, GSM/GPRS, IP, PSTN). Support of Supplementary Services across networks - VHE The support of supplementary services is required in the IP domain to provide similar and additional features to the ones that exist in the GSM/PSTN domain. Service and gateway architectures based on the emerging Call Control Standards for IP Telephony have been proposed by ETSI (TIPHON) and ITU (SG16). Services have been proposed by vendors (e.g. Lucent proposes an Internet Call Forwarding based on SIP). Another interesting area is the effort by the new signalling transport Working Group in the IETF to standardise a Call Processing Syntax enabling users and system managers to implement service ‘scripts’ on proxy agents (SIP proxies or H.323 gatekeepers). The use of such advances in an IP-based UMTS should be investigated to the extent of providing the required service capabilities for VHE to get closer to the initial vision for UMTS. page 4 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 2 Principles and Solutions for IP based Mobile Networks IP transport for the mobile user The section provides an overview of the GPRS functional architecture and basic procedures, drawing special attention to newly introduced functional elements and their relationships with the existing GSM framework, and outlining a possible GPRS evolution path towards a UMTS IP-based Core Network. It then moves to global mobility scenarios based on Mobile IP. Assuming that IP will form the heart of connection-less multimedia communications in the fixed domain and customers will want to benefit from the same services in the mobile domain, mobility mechanisms that integrate easily with IP technologies are needed. A common network architecture model that is able to cope with the needs of future mobile users concentrating on a Mobile IP architecture suitable for UMTS is therefore introduced. Finally an in-depth discussion on methods and scenarios for common (or at least interoperable) mobility management mechanisms between IP-based 3G systems and wireless LANs is provided, since wireless LANs will form an essential complement to Third Generation mobile systems for high bandwidth connectivity. 2.1 General Packet Radio Service GPRS provides actual packet radio access for mobile GSM users and complements the current data services available through today’s GSM networks, such as circuitswitched data and Short Message Service. It will facilitate a variety of applications such as telemetry, Internet browsing, email and broadcast services ([1], [2], [3], [4]). Its main innovations are: It exploits packet switching to transfer both user data and related signalling . It reserves radio resources only when there is something to send/receive. It increases data transmission speed from 9.6 kbps up to a maximum of 150 kbps It offers a connection to standard data networks (such as IP, X.25), extending the Internet computing towards the mobile users. GPRS provides new radio multiple access mechanism which allows more MSs to share the same physical channel, assigning to each user from 1 to max. 8 timeslots inside the same TDMA frame. This is true for the uplink and downlink, separately, thus it permits asymmetric channel allocation. Moreover, the radio resources may be dynamically shared among voice and data services according to the current network load or operator’s choice. On each time slot four coding schemes and relative speeds (from 9.05 Kbit/s to 21.4 Kbit/s) apply [5]. Thus, the raw data rate would be of almost 200 kb/s, bound to decrease due to the overhead of error correcting codes. GPRS provides two basic bearer services: Point-to-Point (PTP) for applications over IP and X.25 and Point-to-Multipoint (PTM) for broadcast data transmissions. At subscription time the user can specify a set of properties, such as data throughput and some QoS parameters (e.g. priority, transmission delay, bit error rate), also according to the different related charge offers [3]. GPRS has been specified to support frequent transmissions of small amount of data and occasional large data batch. In contrast with current circuit-switched connections where users have dedicated connections during their entire call, whether or not they are sending data, with packet access, users will only pay for the amount of data they actually communicate, and not for the idle time. Then, users could be “virtually” 1999 EURESCOM Participants in Project P810-PF page 5 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 connected for hours at a time and only incur connect charges related to the traffic volume actually exchanged. 2.1.1 GPRS reference model The GPRS reference model is logically based on a GSM network, with the addition of support nodes, shown in Figure 1. Two types of GPRS Support Nodes (GSN) are defined: the Gateway GSN (GGSN) and the Serving GSN (SGSN), providing the functionality necessary to implement the GPRS service. Physically, the GSNs can be integrated with the MSCs or constitute a separate network element. In the same figure, the communication interfaces between GPRS and GSM entities are shown. In particular, the HLR content has to be modified to contain also new GPRS user data, such as the address of the SGSN currently responsible for the user, the type of Packet Data Protocol (e.g. IP or X.25), the address of the reference GGSN and the subscribed Quality of Service. In the GSM-GPRS networks, two IP backbone networks are defined: an intra-operator backbone, connecting the SGSN and the GGSN of the same operator (Gn interface) an interoperator backbone, connecting the SGSN and the GGSN of different operators (Gp interface, which is the Gn interface with the addition of proper security functions). The GGSN and the SGSN have corresponding functions in the Mobile IP concept as the Home Agent (HA) and the Foreign Agent (FA). The GGSN keeps traces of routeing information for mobile registered hosts, in order to be able to send the PDUs to the current MS attachment point (SGSN). To forward IP or X.25 packets between each other, the SGSN and the GGSN encapsulate these packets using a specialised protocol called GPRS Tunnelling Protocol (GTP), which is completely transparent and irrelevant to the user who experiences a simple wireless connection to a Packet Data Network (PDN). This is done to ensure security in the backbone network and to simplify the routeing mechanism and the delivery of data over the GPRS network. Also, this tunnelling technique relieves the GPRS network of understanding external PDN protocols and enables adding support for other data networks in the future with the minimum change in the GPRS standard. Below is provided an overview of the main network nodes is provided. GGSN The GGSN provides interaction with PDNs and it is connected to the SGSN via a backbone network, based on IP. The GGSN updates the location register using routeing information provided by the SGSN about the path to a MS, and routes the external PDN protocol packet encapsulated over the GPRS backbone to the SGSN currently serving the MS. It also extracts and forwards PDN packets to the appropriate data network and handles the billing of data traffic. SGSN The main functions of the SGSN are to detect new GPRS MSs in its service area, handle registration of the new MSs, send/receive data packets to/from the GPRS MS, and keep record of the location of MSs inside its service area (routeing areas). The SGSN executes also the security procedures and access control: to verify if a new MS is allowed to join the GPRS network, it interrogates a database (GPRS register) where page 6 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks the mapping between the mobile’s identity (IMSI) and the PDN address is stored. The SGSN is connected to the BSC through the Gb interface, using the Frame Relay technique. It provides the interface Gd towards the G-MSC that is connected to SMS Centre, to provide Short Messages transmission service through GPRS. SMS-GMSC SMS-IWMSC SMS-C MAP-H MAP-C Gd MSC/VLR HLR MAP-D Gs A Gb TE MT R Gc Gr BSS SGSN Gi Gn Um PDN GGSN TE Gf Gp EIR GGSN Other PLMN Signalling Interface Signalling and Data Transfer Interface Figure 1: Functional architecture 2.1.2 GPRS transmission protocol stacks The GPRS transmission protocol stacks are presented in the Figure 2 [4]. Application IP/ X.25 IP / X.25 SNDCP LLC LLC Relay RLC RLC MAC MAC GSM RF GSM RF GTP GTP LLC UDP / TCP UDP / TCP BSSGP BSSGP IP IP Frame Relay L1bis Frame Relay L1bis L2 L2 Um MS SNDCP L1 Gb BSS L1 Gn SGSN Gi GGSN Figure 2: GPRS protocol layering The transmission plane is organised in levels in order to transfer user information and the necessary control procedure (e.g. error corrections, flow control, …). 1999 EURESCOM Participants in Project P810-PF page 7 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 The independence of the transmission plane of the Network Subsystem from the concrete radio access network is provided by the Gb interface. Later on, a brief explanation of the GPRS protocols will be given. GTP: it realises the tunnelling of user and signalling data between the GSNs. SubNetwork Dependent Convergence Protocol (SNDCP): this transmission functionality maps network-level characteristics onto the characteristics of the underlying network. Logical Link Control (LLC): it provides a highly reliable ciphered logical link. LLC shall be independent of the underlying radio interface protocols in order to allow introduction of alternative GPRS radio solutions with minimum changes to the NSS. Relay: in the BSS, this function relays LLC PDUs between the Um and Gb interfaces. In the SGSN, this function relays PDP PDUs between the Gb and Gn interfaces. Base Station System GPRS Protocol (BSSGP): this protocol transports the routeing and QoS information between BSS and SGSN. The benefits of the described architecture are listed below: - the SGSN does not need to use the same protocol that the MS is using (at the application level); - only one protocol (IP) must be supported between the SGSN and the GGSN, and this protocol can be different from the one used by the MS. From the standpoint of the data network, the GPRS network is comparable to a subnetwork of the data network. For example, in the Internet, the GGSN acts like an IP router behind which the entire GPRS is hidden. A computer in the Internet then sees the GPRS as an IP subnetwork to which the messages are sent, as the GPRS network were a completely standard Internet implementation. 2.1.3 Data packet routeing in GPRS In Figure 3, three different routeing schemes are illustrated: mobile-originated (path 1), mobile-terminated message when the MS is in its Home Network (path 2), and mobile-terminated message when the MS has roamed to another GPRS operator’s network (path 3). In these examples, the operator’s GPRS network consists of multiple GSNs (with a gateway and serving functionality) and an intra-operator backbone network. With interworking capabilities, the GGSN can be connected to data networks and to an interoperator backbone network that connects the GPRS networks of different operators using one standard protocol. page 8 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks Figure 3: Routeing of data packets Path 1 The MS sends a data packet to a PDN. The packet is encapsulated into a SNDCP unit that is sent, using the LLC protocol, over the air interface to the SGSN currently serving the MS. When the SGSN has received the packet error free, it encapsulates the PDU into the GPRS backbone packet that is sent to the GGSN handling the traffic from the MS to the data networks. The GGSN extracts the PDU and forwards the data to the appropriate data network. The GGSN that is used by an MS is determined during the registration phase of the MS [6]. Usually, the SGSN can select the GGSN by itself but, in same cases it is possible to force the outgoing traffic through a specific GGSN. The specific GGSN is defined in GPRS register. This method lets mobile users roam in a GPRS network that does not support the data protocol used by the MS. In this case, the outgoing traffic is also routed through the MS’s Home Network to a GGSN that can handle the data protocol used by the MS. Path 2 In the second example, a host in a data network is sending a PDU to an MS located in the Home GPRS network. The data packet is routed in the data network using the standard routeing mechanisms until the packet arrives at a GGSN. In the GGSN the address of the receiver is extracted and mapped to the current location of the MS. The PDU is first encapsulated into a backbone network packet and sent to the SGSN which is currently serving the MS. The SGSN removes the backbone network encapsulation, and the original PDU is encapsulated into the SNDCP data unit and sent to the MS using LLC protocol. When the MS receives the packet, it removes the LLC and SNDCP headers and forwards the PDU to the appropriate application. 1999 EURESCOM Participants in Project P810-PF page 9 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 Path 3 This last example is almost the same as the previous one. However, here the MS has roamed into another GPRS network and the Home GPRS network must send the PDU over the interoperator backbone to the visited GPRS network. The visited GPRS network routes the packet further to the appropriate SGSN. 2.1.4 Basic procedures for GPRS To access the GPRS services, a user must notify his presence in the visited routeing area, executing the procedure of GPRS attach. This operation creates a logical link between the MS and the SGSN (with the assignment of a Temporarily Logical Link Identity), via which the MS can receive SMS, paging from SGSN, eventual RA updating, … During the attach procedure, user data are copied from the HLR to the SGSN. An MS has three states in the GPRS system: IDLE, STANDBY, and READY. The three-state model represents the nature of packet radio use better then the normal GSM two-state model (IDLE or READY) [4]. This information is held at MS and SGSN and it is denoted Mobility Management (MM) context. In the IDLE state, the MS does not have a logical GPRS context activated or any PDN address allocated. In this state, the MS can only receive multicast messages that can be received by any GPRS MS. Because the GPRS network infrastructure does not know the location of MS, it is not possible to send messages to the MS from external data networks. When the MS is switched on, the first procedure performed between the MS and the GPRS network is radio synchronisation. This procedure is carried like it is already specified in GSM. The MS monitors GPRS information transmitted on the broadcast control channels to find out the locations of GPRS channels. When the MS wants to enable the data network protocol (start using the GPRS service), it initiates a GPRS Attach procedure. The main objectives of this procedure are: to send the PDN address of the MS to the GPRS network infrastructure, report the current whereabouts of the MS, create entries for the assigned PDN address in the GGSN routeing table, initiate charging and statistical procedures. The MS is authenticated and ciphering parameters between the MS and the SGSN are exchanged. The registration is forwarded to the GGSN in which the location of the MS is updated. The GGSN may inform the previous SGSN to remove the MS from the previous registers. If the GPRS login procedure was successful, the MS enters the READY state, and then moves to the STANDBY state if the READY timer expires with no data transfer. Data could be transmitted between an MS and the GPRS network only when the MS is in the READY state. In the READY state the SGSN knows the cell location of the MS. In the STANDBY state, the location of the MS is only known to the accuracy of a Routeing Area, which can consist of one or more cells within a GSM location area. When the SGSN wants to send a packet to an MS that is in the STANDBY state, the MS must be paged. Because the SGSN knows the routeing area in which the MS is page 10 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks located, a packet paging message is sent. After receiving the paging, the MS gives its cell location to the SGSN to establish the READY state. The data transmission begins soon after packet paging through the channel indicated by the paging message. The purpose of the packet paging is to simplify the process of receiving packets. The MS has only to listen to the packet paging message instead of all the data packets in the downlink channels. When an MS has a packet to be transmitted, access to the uplink channel is needed. The uplink channel is shared by a number of MSs and is allocated by a BSS. The MS requests use of the channel in a packet random message. The transmission of the packet random access message follows Slotted Aloha procedures. The BSS allocates an unused channel to the MS and sends a packet access grant message in reply to the packet random access message. The description of the channel (one or multiple time slots) is included in the packet access grant message. The data is transmitted on the reserved channels. The MS may activate or deactivate PDP contexts while in READY state. Regardless if a radio resource is allocated to the user or not, the MM context remains in the READY state even when there is no data being communicated. The READY state is supervised by a timer. A Mobility Management context moves from READY state to STANDBY state when the READY timer expires. In order to move from READY state to IDLE state, the MS must perform the GPRS Detach procedure. The main reasons for the STANDBY state are to reduce the load in the GPRS network caused by cell-based routeing update messages and to serve the MS battery. When an MS is in the STANDBY state, there is no need to inform the SGSN of every cell change, but only of every routeing area change. The operator can define the size of the routeing area and, in this way, adjust the number of routeing update messages. 2.1.5 Location Management in GPRS The Location Management function provides: - mechanism for cell and PLMN selection, - mechanism for the network to know the Routeing Area for MSs in STANBY and READY states, - mechanism for the network to know the Cell Identity for MSs in READY state. The term “handover” is not suitable to indicate the passage of the MS, engaged in a data transfer, from one cell coverage area to another, like it happens in the GSMCircuit Switched connections case. “Cell update” or “Routeing Area Update” procedures are performed instead. This is mainly due to the packet nature of the information exchanged between the MS and the network in GPRS. In fact, a packet data transfer permits: - a frequent and dynamic radio resources re-assignment (made at the beginning of the transfer of a flow of Radio Blocks to/from an MS). - the acknowledged mode of operation of the LLC and the RLC-MAC layers (that allows to detect if packet losses have occurred and to force retransmission) User data can in general be transmitted during MM signalling procedures (attach, authentication, Routeing Area Update) if the terminal allows it, but it should be limited in order to minimise the need for retransmission between the MS and the SGSN. 1999 EURESCOM Participants in Project P810-PF page 11 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 The MS detects that a new cell has been entered by comparing the cell’s identity with the one stored in the MS Mobility Management context2. The MS detects that a new Routeing Area (RA) has been entered by periodically comparing the RAI stored in its MM context with that received from the new cell. When the MS camps on a new cell, either a Cell Update or a Routeing Area Update is required. 2.1.6 Evolution scenario of GPRS towards an IP-based UMTS The UMTS system will likely consist of a new Access Network (the UTRAN) connected to a Core Network based on the evolution of both the GSM and GPRS networks. Two different switching platforms are likely to be used to separately handle circuit switched and packet switched traffic. Whatever the destiny for the voice traffic, connectionless data traffic will probably rely on a GPRS-enhanced platform. Those operators that have strong interests in utilising IETF standards may find convenient to push the packet switched platform towards an IP-based core network using IP/mobile IP networking allowing GPRS backwards compatibility. In order to lead evolution of current 2nd generation mobile systems towards an IPbased UMTS architecture, some enhancements have to be carried out to the GPRS network. A possible implementation of the UMTS target architecture is represented in Figure 4 [2]. The SGSN and the GGSN node are combined into the IGSN (Internet GPRS Support Node) and adapted: to the Iu interface to UTRAN. to use Mobile IP, for handling inter IGSN mobility. Thus, in this scenario Mobile IP is used to handle only macromobility events, that is: - in the UMTS core network - between different types of systems (UMTS, LAN, …), and between GPRS PLMNs. An example of MS registration can help clarifying co-operation between GPRS and Mobile IP. Let’s suppose that the mobile terminal decides to access its home network. - It sends a registration request through the serving UTRAN to the IGSN - The IGSN contacts the HLR for an authentication procedure. - Once authenticated, the mobile terminal will ask for a Mobile IP CareOfAddress (CoA, see also section 0), that is a temporarily address assigned to the MS by the serving network (Mobile IP v.6) or an address of a Foreign Agent in the network that will forward incoming packets. - The mobile terminal informs its Home Agent to update the look up table of home addresses with the new CoA. 2 The Cell Selection and Reselection procedure belong to Radio Resource Functionality and not to Mobility Management functions. Since the MS cannot camp on more than one cell, a cell that supports GPRS service has to be chosen. The operation may be either MS or Network controlled. page 12 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks - The Home Agent could contact the HLR in order to verify whether the MS CoA is authorised to be registered (through the new Gh interface) - IGSN will produce charging records while the MS is connected and transmits data. If the MS is roaming in a visited network, the local IGSN will contact the HLR of its home network, via the international SS7 network or by tunnelling the MAP messages through the Internet or an inter PLMN IP based backbone network. Then, if authorised, it will be given a CoA by the visited network and will register it to its Home Agent, as explained above. Internet UTRAN IGSN IP Iu IP / MobileIP home network MAP HA HLR SMS AUC ... Data & Signaling Signaling Gh MAP IP IGSN Iu UTRAN Figure 4: Evolution scenario for UMTS At present, the evolutionary path that starts from near term GSM/GPRS and drives to a UMTS evolved architecture, like the one just presented, can be divided in three steps, all backwards compatible with networks and terminals that cannot handle Mobile IP. Stage 1 The first stage represents the minimum architectural requirement for an operator to support Mobile IP services (Figure 5). GPRS is still responsible for roaming within and between the PLMNs. Mobile IP is used : - for roaming between different kinds of systems (e.g. between UMTS and a LAN), and - optionally between different GPRS PLMNs,. A Foreign Agent needs to be associated to those GGSNs addressed by the MS that wants to use a Mobile IP service. In the PDP context activation with the GGSN/FA node, the MS must receive the associated CoA: this new address must be communicated to the Home Agent, to let it tunnel incoming packets to the current serving network. The FA will de-tunnel these packets and, together with GGSN, will map the MS home address to the PDP context. The MS keeps the same CoA for all the duration of the PDP context. 1999 EURESCOM Participants in Project P810-PF page 13 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 UTRAN Gp RNS HA GGSN GGSN SGSN SGSN CN Firewall Iur HA HA MAP RNS HLR etc. Gn Firewall GGSN FA SGSN RNS Internet R CN UTRAN Iu Figure 5: CN architecture with GPRS MM within and between GPRS PLMN, and Mobile IP MM between different types of systems and optionally between GPRS PLMN Stage 2 In a further step, SGSN and GGSN may be co-located into a unique node just to push the IP backbone network as close as possible to the access network (Figure 6). UTRAN Firewall RNS Gp FA SGSN+ GGSN Iur CN Gi HLR etc. SGSN+ GGSN FA R HA MAP RNS HA HA IP Gn R Internet R Firewall SGSN+ GGSN FA RNS UTRAN Iu R CN Figure 6: CN architecture with GPRS MM for active MS and Mobile IP MM for inter-SGSN handover. The SGSN and the GGSN are co-located The drawback of this configuration is that a highly mobile MS can perform a lot of inter-SGSN handovers during a long session, resulting in an inefficient routeing scheme, if the PDP context is performed with the same GGSN. A way to skip this inconvenient could be the following. When active, the MS would move from the old SGSN to the new SGSN, keeping the PDP context in the old GGSN as long as the session is open. Once in the idle state, the PDP context could be page 14 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks changed to the GGSN associated with the new SGSN, and a new CoA can be obtained. The GPRS interfaces, Gn and Gp, are still included to provide user roaming in those networks that do not support Mobile IP. Stage 3 The last evolution step foresees Mobile IP to handle, additionally, all intra-systems mobility, including handovers between IGSNs and handovers between two GPRS networks (Figure 7). UTRAN UTRAN HA Firewall RNS FA IGSN Iur CN IGSN FA R HA HA MAP IP RNS HLR etc. Internet R R Firewall IGSN FA RNS Iu R CN Figure 7: CN architecture with Mobile IP MM within the core network, between different types of systems and between GPRS PLMNs 2.2 Mobile IP for global roaming In the future, IP will form the heart of connectionless multimedia communications in the fixed domain and customers will want to benefit from the same services in the mobile domain. Therefore, we have to find mobility mechanisms that integrate easily with IP technologies. A mobility management mechanism is needed to enable roaming between heterogeneous mobile networks, in whose mobility is handled by specific mechanisms (e.g. GSM handover, UTRAN handover, BRAN handover, IAPP handover). This could be provided by Mobile IP. This is why Mobile IP protocol is presented as well as related issues and developments. 2.2.1 Generalities Mobile IP allows a mobile terminal to roam from network to network without any reconfiguration of IP address. More importantly, it also allows active sessions (web, file transfer, streaming, conferencing…) to be maintained when the terminal moves. In addition, the mobile terminal is always identified by a unique IP address which allows it to be contacted wherever it may be. 1999 EURESCOM Participants in Project P810-PF page 15 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 As explained in the previous section and [114], there is an opportunity of convergence between an evolved UMTS network based on GPRS and Mobile IP. GPRS could be complemented by using Mobile IP internally and global roaming between GPRS domains - and ultimately between UTRANs - could be provided using Mobile IP. Mobile IP would then become the sole roaming ‘protocol’ in the IP domain both within the operator’s backbone and externally. The basic form of Mobile IP as defined in RFC 2002 [7] is presented in the following paragraphs. 2.2.1.1 Terminology – Basic mobile IP assumptions A terminal with mobility capabilities is known as a mobile node (MN) or mobile host (MH), and any terminal or server communicating with it is known as a correspondent node (CN) or correspondent host (CH). Mobile IP assumes that the mobile node has a permanent IP address belonging to a subnetwork, called the home network, where it can be reached by standard internet routing protocol. Typically, the home network is the Ethernet segment subnetwork to which the MH is usually attached. Any other subnetwork in which the mobile host may roam is called the foreign network. In a foreign network, the mobile host temporarily acquires a new routable address, called the care-of-address (CoA). The mobility functions needed by the mobile node are administered at the network level (IP layer) by mobility agents: either by a Home Agent (HA) in the home network or by a Foreign Agent (FA) in the foreign network. Figure 8 illustrates a simple mobile environment whereby a mobile node moves from a home network to a foreign network (it is ‘unplugged’ and ‘re-plugged’ at the new location). Correspondent Node HOME NETWORK FOREIGN NETWORK Foreign Agent Home Agent INTERNET Mobile Node Figure 8: Mobile IP terminology page 16 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 2.2.1.2 Principles and Solutions for IP based Mobile Networks Overview of Mobile IP Mobile IP provides three mechanisms in order to enable host mobility: Discovery mechanism This enables the mobile node to know in which network it is located and to ‘discover’ the identity of the local mobility agent. The discovery mechanism works by having the agents (home and foreign) to send broadcast messages periodically on their local subnetworks. The broadcast message, called an advertisement, includes the IP address of the agent. From these advertisements, the mobile node can then deduce its network location, set its default gateway router accordingly, and acquire a CoA. Registration mechanism It enables the mobile node to register its CoA with the Home Agent, thus ‘telling’ it the new location. The mobile node will send to the home agent a registration request message containing the CoA, possibly through the foreign agent (if the mobile node is in its home network, no registration is required since normal Internet routing will enable to reach it there). Tunnelling mechanism It enables the delivery of packets from correspondent nodes to the mobile node when the latter is roaming in a foreign network. Once the home agent has accepted the registration, it caches the CoA of the mobile node. It will then be able to capture the packets destined for the mobile node and send them to the appropriate location. This is achieved by tunnelling the packets to the CoA, usually by doing an IP in IP encapsulation [8]. Encapsulation enables to decouple the application layer data flow from the network layer information, thus enabling to maintain active sessions with correspondent hosts even if the mobile node is moving across subnetworks. 2.2.1.3 Detailed operation in the Foreign Network Agent discovery, Care-of-Address Once the mobile node has detected that it has moved to a foreign network (either by receiving Foreign Agent advertisements or if the last HA advertisement has timedout), it needs to acquire a CoA. Mobile IP allows two mechanisms for the acquisition of a CoA: The mobile node can use a Foreign Agent’s IP address (given in the advertisements), in which case it is called a foreign Care-of-Address. The mobile node can alternatively acquire a CoA dynamically through a mechanism, such as Dynamic Host Configuration Protocol (DHCP), if the subnetwork is not served by a Foreign Agent. It is then a co-located care-of address. Registration with the Home Agent The mobile node will then attempt to register its CoA with the Home Agent. It can do so by sending a Registration Request message. This message is sent to the FA if the MN has a foreign CoA. The FA will then relay it to the Home Agent. Alternatively, in the case of a co-located CoA, the MN sends the registration request directly to the HA. Once the registration is successful after an optional authentication check, the mobile node and the Foreign Agent are notified about it by registration reply messages sent by 1999 EURESCOM Participants in Project P810-PF page 17 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 the Home Agent. The Home Agent will maintain a soft-state mobility binding which associates the mobile node’s original IP address (its home address) with its care-of address. The Foreign Agent will maintain a similar binding if a foreign care-of address is used. When the mobile node moves to another Foreign Network, it will need to register a new care-of address with the Home Agent. Incoming packets delivery: tunnelling After the registration with the Home Agent is completed, the Home Agent is able to relay packets to the mobile node through tunnelling (Figure 9): 1. A packet destined to the mobile node is routed to the home agent. 2. The Home Agent intercepts the incoming packet. 3. The Home Agent encapsulates the incoming packet in a ‘new’ IP packet, which is tunnelled to the CoA as maintained in the mobility binding. Several encapsulation techniques are allowed, but IP in IP encapsulation [8] must be supported by all implementations. 4. a) Foreign CoA case: The FA decapsulates the packet. It then identifies the destination Mobile Host (MH) in its binding table using the home address contained in the destination address field of the de-capsulated (original) packet. The packet is then sent ‘over the wire’ (local subnet) in a MAC frame The frame is received by the MN, which passes the datagram on to the appropriate application. 5. b) Co-located CoA case: The tunnel endpoint is the MN itself and no further delivery mechanism is needed other than the mobile node itself decapsulating the packet and passing on the datagram to the appropriate application as before. Correspondent Node FOREIGN NETWORK HOME NETWORK Home Agent <Home@, CoA> Mobility Binding Foreign Agent Mobile Node Figure 9: Mobile IP packet delivery mechanism when the Mobile Node is on a foreign network Outgoing packets forwarding page 18 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks In the opposite direction, the mobile node directly sends packets to correspondent nodes, using its home address as the datagrams’ source address. 2.2.2 Enhancements to Mobile IPv4 2.2.2.1 Route Optimisation In base Mobile IP, the triangular route followed by packets from the correspondent node to the mobile node in a foreign network may not follow an optimal path across the Internet. All incoming packets must first go to the Home Agent. The route optimisation feature [25] attempts to resolve this triangular routing problem by introducing additional IP functionality in the correspondent node, the home agent and the foreign agent. Route optimisation allows the correspondent node to cache the mobility binding of the mobile node, thus enabling it to send packets to the mobile node directly (Figure 10). When a mobile node moves to a foreign network, it will register with the Home Agent as mentioned for base mobile IP. Any subsequent datagram destined to the mobile node will be captured by the Home Agent. On noticing this, the Home Agent will then still tunnel the datagrams to the mobile node. In addition, it will also send a Binding Update message to the correspondent node in order to create or update the node’s mobility binding cache. The direct route will then be used by the correspondent node to tunnel packets to the mobile node. The route optimisation draft also provides additional extensions to allow the recovery of 'in flight' packets between the HA and a previous Foreign Agent by sending registration messages with the PFANE extension (Previous Foreign Agent Notification Extension). Correspondent Node <Home@, CoA> Mobility Binding Fir st da Bin d ing Up ets ck te Pa HOME NETWORK FOREIGN NETWORK First Packets Home Agent <Home@, CoA> Mobility Binding Foreign Agent Mobile Node Figure 10: Mobile IP Route Optimisation 2.2.2.2 Mobile IP and dial-up access While Mobile IP, as defined in RFC 2002 [8], provides robust support for host mobility across subnet boundaries, its support for roaming across administrative 1999 EURESCOM Participants in Project P810-PF page 19 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 domain boundaries does not conform to established practices amongst ISPs for PSTN dial-up access, which can be extended to dial-up access from circuit-switched 2G mobile networks. Some short-term ‘fixes’ have been specified: Interaction with PPP. RFC 2290 creates a new IP Control Protocol (IPCP) option to resolve the under-specification of the interaction between Mobile IP and PPP through IPCP. This enables the Network Access System (NAS) to correctly act as a Foreign Agent for the dialling-in Mobile Node. Interaction with RADIUS. In addition to the feature described above, [15] proposes a new RADIUS [16] attribute (‘Mobile-IP-Configuration’). Its use would be to allow the local RADIUS server to enforce Mobile IP Authorisation/Configuration and Accounting at the NAS after the Authentication Phase. The Mobile Node can then choose to use Mobile IP or not during IPCP negotiation. Standardised Identification. [17] defines the Mobile IP Network Access Identifier Extension, which enables to transmit a user's NAI [41] in a Mobile IP message. The NAI standardises the format of user and service provider identification material to facilitate AAA operations when roaming (e.g. interaction with a RADIUS Server in a visited ISP domain). This really provides personal mobility (user) on top of the terminal mobility provided by Mobile IP. This feature also enables direct interaction between Mobile IP entities and standard AAA servers when not in a dial-up access scenario (e.g. WLAN or GPRS access). In dial-up scenarios, the NAI extension enables to request dynamic home address allocation by the home agent. Stronger Authentication. The Mobile IP Challenge/Response Extension [18] mechanism is not specific to the dial-up scenario. However, since this mechanism provides a better protection against replay attacks than the authentication extensions initially proposed in RFC 2002, it is a good choice for roaming dial-up users who want to have Mobile-IP service. In the longer term, Mobile IP will have to evolve conform to the Roaming [19] and AAA [20] frameworks currently under specification at the IETF. 2.2.3 Mobile IPv6 IPv6 includes many features that are missing in the current IP version 4: Stateless Address Auto-configuration [13] Neighbour Discovery [14] IPv6 also attempts to drastically simplify the process of renumbering, which could be critical to the future 'routability' of the Internet [21], [22]. These features will help to streamline mobility support for better performance. 2.2.3.1 CoA acquisition in Mobile IPv6 Mobility Support in IPv6 [23], as proposed by the Mobile IP working group, follows the design for Mobile IPv4. It retains the ideas of a home network, home agent, and the use of encapsulation to deliver packets from the home network to the mobile node's current point of attachment. While discovery of a care-of address is still required, a mobile node can configure its own care-of address by using Stateless Address Auto-configuration [13] and Neighbour Discovery [14]. Thus, foreign agents page 20 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks are not required to support mobility in IPv6. IPv6-within-IPv6 tunnelling [24] is also already specified. 2.2.3.2 Route Optimisation in IPv6 IPv6 mobility borrows heavily from the route optimisation ideas specified for IPv4 [25] particularly the idea of delivering binding updates directly to correspondent nodes. When it knows the mobile node's current care-of address, a correspondent node can deliver packets directly to the mobile node's home address without any assistance from the home agent as is the case in IPv4. 2.2.3.3 Security One of the biggest differences between IPv6 and IPv4 is that all IPv6 nodes are expected to implement strong authentication and encryption features to improve Internet security. This affords a major simplification for IPv6 mobility support, since all authentication procedures can be assumed to exist when needed and do not have to be specified in the Mobile IPv6 protocol. Even with the security features in IPv6, however, the current working group draft for IPv6 mobility support specifies the use of authentication procedures as infrequently as possible. The reasons for this are twofold. First, good authentication comes at the cost of performance and so should be required only occasionally. Second, questions about the availability of Internet-wide key management are far from resolved at this time. 2.2.3.4 Source Routing In contrast to the way in which Route Optimisation is specified in IPv4, in IPv6 correspondent nodes do not tunnel packets to mobile nodes. Instead, they use IPv6 routing headers, which implement a variation of IPv4's source routing option. A number of early proposals for supporting mobility in IPv4 specified a similar use of source routing options ([29], [30]) but these were not performing well with IPv4. However, IPv6's more careful specification solves this problem. Consequently, correspondent nodes can use source-routing options in headers without penalty. This allows the mobile node to easily determine whether correspondent nodes do not have the right CoA. 2.2.4 Mobile IP limitations and potential solutions Mobile IP provides a basic framework for satisfying the requirements of in-session mobility without compromising the integrity of Internet routing in a simple and robust manner. In this section, the weaknesses of the basic Mobile IP concept is analysed when thinking about using it 'as is' in a public commercial environment, where IP and cellular networks are converged. The main issues are: 2.2.4.1 Security interworking Capacity overhead Handover latency Security issues Firewall traversal / ingress filtering 1999 EURESCOM Participants in Project P810-PF page 21 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 Firewalls or Border Routers cause difficulty for Mobile IP because they block all classes of incoming packets that do not meet specified criteria. Specifically in the case of ingress filtering, they block those packets that appear to have a source address outside the network they belong to, as is the case with traffic from mobile nodes in a foreign network. Solutions to this problem in Mobile IPv4 typically involve 'reverse' tunnelling outgoing packets from the CoA to the Home Agent. The Tunnel Establishment Protocol [26] lays the foundations for achieving firewall traversal using compound tunnels. Mobile IPv6 also offers a solution in the home address destination option [23]. Authentication framework, Distribution of keys, trust relationships Mobile IP provides a basic authentication mechanism between the Home Agent, the Mobile Node and potentially the Foreign Agent. However, it does not address the issues of key distribution and trust relationships between these entities, which may be quite complex in the public environment where roaming between various administrative domains is possible, possibly internationally. Work is under way to address these issues and integrate Mobile IP more tightly with the emerging AAA infrastructure. Support of Private Addressing With privately-addressed corporate networks, it may happen that a FA is shared by multiple mobile nodes belonging to multiple corporate networks with overlapping address spaces. If two MNs belonging to these networks happen to share the same FA and happen to get from their corporate network the same IP address, the FA receiving packets from two different Home Agents for the same Home Address will not be able to resolve the address clash and how to forward the packets. 2.2.4.2 Capacity overhead Access Transmission Encapsulation and header overheads particularly impact the capacity requirements and performance of real-time services, since these require small packets to overcome delay variation and packetisation delays. This is particularly of importance in the radio access network where transmission capacity is expensive. With short packets, 20-bytes IP headers along with RTP/UDP headers and the duplication of information due to encapsulation prove to be an overkill on the capacity available to the user's multimedia data (compressed voice or video). Solutions to this involve header compression techniques ([36], [37] [38][39]) and the reduction of encapsulation overhead through e.g. Minimal Encapsulation [12]. Core/Signalling Transmission Unlike traditional mobility management procedures in mobile telephony networks, mobile IP does not define paging areas. Therefore, the MN must update the HA every time it changes location. This requires the exchange of signalling messages (registration request and reply) in the 'core' network. This is further worsened by the need to send Binding Updates across the network with route optimisation. page 22 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 2.2.4.3 Principles and Solutions for IP based Mobile Networks Handover Latency In Mobile IP, the Home Agent and Correspondent Nodes bindings are updated only after the MN has moved to its new location. It can therefore be considered as a hard forward handover scheme since there is a lag of time during which the data sent to the MN from the HA or CN can be lost or delayed. This latency is made up of several components: Association delay Movement Detection delay Traffic re-routing delay, made up of: HA binding updating delay CN binding updating delay 'In flight packets' re-routing delay. Potential solutions at the IP level involve minimising the need to send registration/update messages across the network, which incurs a big round-trip delay. The general idea is to take a hierarchical approach that separates global mobility provided by Mobile IP, from a local mobility management scheme such as those presented in section 0. 2.2.5 Possible use/role of Mobile IP for UMTS The scope of this section is to introduce a common network architecture model using Mobile IP [40] that is able to cope with the needs of future mobile users. 2.2.5.1 Network reference model The Figure 11 depicts the logical view of the proposed network architecture. Foreign Network IP based Core Network AAA+ Security Gateway DHCP Mobility Management (FA+) GSM, UMTS AAA+ Dial Up Location Tracking Location Tracking DNS Security Gateway Unified Authentication Directory Server Location Tracking Location Tracking DHCP Mobility Management (HA+) Wireline LAN (802.3) Wireless LAN (802.11) Access Network Home Network Figure 11: Network reference model The following sections describe the functionality of the components of the network reference model. 1999 EURESCOM Participants in Project P810-PF page 23 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 Home Network The Home Network is very similar in concept to the home network defined in [7] and the home network defined in the wireless networks. Basically, the Home network is a combination of the two with some extensions. With regard to the relevant mobility related functions, the Home Network: Maintains the mobile user's subscription and associated subscriber profile. Provides mobility to subscribers on a 'larger' scale. It is responsible for maintaining the current location of the mobile user. Allocates mobile node IP addresses. Supports a 'unified' directory for subscriber profiles independent of the access network type. Stores policies and profiles associated with mobile users. Provides Authorisation functions associated with the mobile user. May provide the Authentication functions required to authenticate the mobile users. Supports Service Level Agreements (SLA) with all Foreign Networks it wants its users to roam in. Supports a policy that allows 'hiding' the user's location. This policy will mandate that the home be an anchor point for datagrams sent to it's users while they are roaming. Home Network Mobility Components Later on, some functions associated with the components of the Home network are described. Mobility Management (MM) Mobility management is comprised of two functions: mobile user location tracking and performing routing update functions for mobile nodes. These functions are very similar to what Home Agents do in Mobile IP [7] and what Home Location Registers do in wireless networks, with some enhancements. The location tracking function of the MM expects to receive a single mobile user registration message from the foreign networks that is independent of the access network used at the foreign network. This is true for all messages sent from the foreign networks to the home networks. The architecture supports the concept of a centralised location tracking function for the home network. However, the architecture does not preclude the idea of having a distributed location tracking function. AAA+ The protocol used to send messages between a foreign network and a home network is the AAA protocol, with extensions to support mobility management (hence AAA+). The single security association between the foreign and the home network can be used to alleviate the need for security associations between Mobile IP FA, HA components and dynamic session key establishment ([41] and [42]). It is suggested that the security framework be based on IPSec. page 24 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks Authentication Server The authentication server is a combination of certificate authority, key management system, and digital signature verification server. The authentication server receives roaming mobile user authentication requests via the AAA+ and authenticates the user. Unified Directory The Unified Directory is the database that contains all the home user's subscriber profiles, network policies, and any other data that needs to be stored at the Home Network. The subscriber profiles in the directory are independent of the access network association. Access to data in the Unified Directory from other components within the network is via a single protocol, LDAP. DHCP In the Home Network, the DHCP server may be used to assign IP addresses to roaming mobile stations that do not have a permanently configured IP. DNS In the home network, Dynamic DNS is the protocol used to update DNS with a roaming user's mobile node allocated IP address. If the home network is responsible for allocating the IP address, DNS is updated by DHCP. If the foreign network is responsible for allocating the IP address, the home network mobility manager will update DNS. Security gateway The security gateway performs all the necessary 'firewall' functions. Foreign Network The Foreign Network is very similar in concept to the foreign network defined in Mobile IP [7] and the foreign network defined in the wireless networks. Basically, the Foreign Network is a combination of the two with some extensions. The Foreign Network is the serving area network for one or more access networks. It can support multiple Access Networks (AN), where each AN is associated with a different technology, e.g. one AN may be a CDMA RAN, another AN may be GSM RAN. Moreover, the Foreign Network: Provides mobility management for mobility within the access networks that it serves. Provides local services. Routes data to the mobile user via the access link that the mobile node is currently attached to. Routes data that is sent by the mobile user. Allocates IP address to be used by the mobile nodes if allowed by policy. Supports the establishment of Service Level Agreements (SLA) with all Home Networks that want to allow their users to roam within the foreign network. Supports user authentication to be provided after the user has registered. 1999 EURESCOM Participants in Project P810-PF page 25 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 Foreign Network Mobility Components Here follows a brief description of some functions associated with the components of the Foreign Network. Mobility Management (MM) Foreign Network's mobility management is comprised to three functions: mobile user location tracking within the foreign network, handoffs between foreign networks and performing routing update functions for datagram delivery to the access network/mobile node. These functions are very similar to what Foreign Agents do in Mobile IP [7], with some enhancements. The location tracking function of the MM expects to receive the same formatted mobile user registration message from each of the heterogeneous access networks. The architecture supports the concept of a centralised location tracking function within for the foreign network. However, the architecture does not preclude the idea of having a distributed location tracking function. AAA+ (as in the Home Network) DHCP In the Foreign Network, the DHCP server may be used to 1. assign co-located care of addresses to private network mobile nodes and 2. if policies indicate, assign IP addresses to roaming mobile stations that do not have a permanently configured IP. Security Gateway The security gateway performs all the necessary 'firewall' functions. It supports ESP IPSec security associations with other network security gateways. 2.2.5.2 Access Network Mobile networks and access technologies allow a user to gain access to a Foreign Network. They can be of several types: 2.2.5.3 GSM mobile access networks (and their evolution to 3rd generation, UMTS) 802.11 wireless LAN access 802.3 wireline LAN access Dial-up network access … IP Network The IP network provides the routing of datagrams between Home Networks and Foreign Networks. The IP network can be the public Internet or a closed network. 2.2.5.4 Mobile Nodes It can be argued that all nodes in the future will be mobile, or at least have the potential to be mobile. Stationary nodes, generally called correspondent nodes in page 26 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks Mobile IP [7], will only have to be equipped with the appropriate access specific interface card(s) and software that can perform the network registration functions. The mobile nodes should be equipped with the functions and interfaces to access the wireless or mobile networks. Mobile node software will need to determine when and which access networks are available and perform the appropriate registration functions. 2.3 Registration for mobile terminals considering an IP only based network This chapter focuses on the procedure to register a mobile which only accesses packet switched services combining two levels of mobility: mobility within the radio subsystem and mobility within the network subsystem. The circuit switched access is not taken into account. As IP based network, we consider the network architecture described in section 0 which is represented in Figure 5, Figure 6 and Figure 7. We will underline the roles of the different location registers involved: HLR, HA and FA. 2.3.1 Radio access authentication and MIP authentication At this stage of research in IETF, the common understanding is to keep Access Network authentication and IP-based authentication as separate things [44]. Indeed while the first one is related to fair radio resource sharing, the second one does more generally depend on agreements between visited and home network. Regarding the fact that the Radio Access is UTRAN, the Access Network authentication will be performed by VLR/HLR databases and MAP signalling . Two ways of proceeding can be drafted: 1. Access Network authentication is first performed. Subscriber information in HLR also contains IP-based authentication material that will be used by SGSN for authentication in the IP world. In this case, the UE does not perform itself IP authentication. IP-based authentication material means all the information that Mobile IP needs to perform authentication3. 2. Only the UE is aware of information to send to the IP network for authentication purpose. Two independent authentication procedures are then initiated from UE. In the following sections, we focus on the IP authentication for IP Mobility as the procedure (HLR, VLR) is not changed in the access network compared to GSM/GPRS procedures. 3 The binding in the HLR between MSISDN or IMSI and the IP address of the mobile terminal could be done with a NAI (Network Access Identifier) that allows to create an IP address from an IMSI [41]. For example, if the NAI is of the form user@realm, a table resident in the wireless access network or in the HLR may contain ranges of IMSI and corresponding realm. IMSI range Realm 214790 – 214799 abc_company.net 914680 – 972689 def_company.net 972700 – 972730 hij_company.net 1999 EURESCOM Participants in Project P810-PF page 27 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 As mobility is not handled the same way with versions 4 (RFC 2002 [7]) and 6 of the Internet Protocol, we will point out the differences between them. 2.3.2 UMTS registration with Mobile IPv4 With Mobile IPv4, a mobile terminal is always registered in a Foreign Agent. The temporary address assigned to the mobile terminal (i.e. CoA) is given by the FA. 2.3.2.1 Roles of the location registers Considering Figure 5, Figure 6, Figure 7, several location registers have been identified and this part underlines their specific roles. HLR Given the architecture of the second generation mobile network, we cannot avoid to have a HLR database. This database will have about the same roles as in GSM/GPRS networks, it could contain: - IMSI - MSISDN - Address of the IGSN currently responsible for the user (the IGSN associated to a FA) - HA address (if the HA is not attributed dynamically per connection) - Profiles for data communications - Security keys HA The HA contains permanent addressing information if it permanently registers Mobile User (in this case the HA should not be discovered dynamically). The HA contains the MSISDN of the mobile user (MSISDN which has been transformed into an IP address), the default algorithm MD5 and keys of 128 bits for authentication of the FA and the CoA of the mobile terminal (i.e. IP address of the FA). FA The FA associated to the IGSN contains the binding between the MSISDN, the home address, potentially the Home Agent address and the current location/address of the mobile terminal within the access network. 2.3.2.2 Interfaces A simplified picture of the network is drawn in Figure 12 showing the protocols at the interfaces. page 28 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks Underlying Network MAP HLR VLR MAP MAP FA HA IGSN Radio Access Network AAA AAA HDAA Or AAA Figure 12: Signalling message between location database and servers 2.3.2.3 Registration procedure Option 1: Interworking between Radio Access authentication and IP authentication in the HLR The registration procedure can be the following when the mobile is under his home network: 1. Registration procedure, authentication process with the HLR via IGSN as for GPRS. 2. If registration to HLR is successful, the IGSN FA updates the HA with the CoA of the mobile terminal (i.e. the IP address of the IGSN). The HA may be dynamically attributed. 3. Authorisation and authentication process between FA and HA with AAA (Authentication – Authorisation – Accounting) protocols. 4. Registration ACK or NACK sent back to the mobile terminal using GPRS signalling. 1999 EURESCOM Participants in Project P810-PF page 29 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 UTRAN 1 2 RNS 3 Firewall FA 4 R IGSN Iur 3 MAP 1 RNS 1 HLR etc. HA 4 IP Internet R R Firewall IGSN RNS R FA CN Iu Figure 13: Registration procedure with UTRAN and Mobile IPv4 If the binding between the user address and the Home Agent address is not found in the HLR nor in the Foreign Agent, the Foreign Agent may proxy the registration request to the Home Agent via a HDAA [42] (Home Domain Allocation Agency) which will assign a Home Address within the Home Domain. The HDAA does not perform any processing on the Registration Request, but simply forwards the request along with the newly allocated IP address to a Home Agent within the network that is able to handle the request. With such a procedure, the Home Agent may be dynamically associated. Consequently, the authentication should be performed at the home network or home administrative domain where the user has his subscription for the IP part of the procedure, for instance through AAA functionality. The Mobile IP authentication will be performed between the HA and the FA. In order to insure security within the IP network between FA and HA, they are associated to AAA servers which allows Authentication, Authorisation and Accounting. Such servers can be based on DIAMETER [43]. To insure security transmission between HA and FA so that addresses cannot be identified while transmitted over the IP network, some IPSec protocol may be used. UE MM IGSN RNC LOCATION UPDATING REQUEST 1 SA MM MAP MAP ACCESS NETWORK AUTHENTICATED 1 MAP SEND AUTHENTICATION INFO 1 MAP SEND AUTHENTICATION INFO ACK * MIP MIP MM LOCATION UPDATING ACCEPT Home Network HLR MAP Access Network Authentication MAP Registration request [Care Of Address, NAI] 2 MIP 3 Mobile IP Authentication Registration request ack 3 4 MIP 4 MM *.MAP_SEND_AUTHENTIFICATION_INFO_ACK is to be meant as an upgraded MAP message containing IPbased authentication information (Home address, NAI, algorithms, keys…) Figure 14: More detailed messages flow for registration page 30 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks Roaming in a visited access network will not change the previous procedure, except the fact that the authentication for the radio access network will need to interrogate the HLR from the VLR. Option 2: Full independence between Radio Access authentication and IP authentication Mobile IP authentication of UE can be directly triggered by mobile. In this case HLR does not need to be upgraded. The drawback is the existence of a second authentication procedure on the radio link. Figure 15 presents the messages flows in this case. UE MM MIP RNC IGSN LOCATION UPDATING REQUEST 1 Registration request 1 Encapsulated in RRC message MIP_Direct_Transfer FA MM MIP Encapsulated in RANAP message MIP_Direct_Transfer MAP ACCESS NETWORK AUTHENTICATED 1 MAP SEND AUTHENTICATION INFO 1 MAP SEND AUTHENTICATION INFO ACK * MIP MIP LOCATION UPDATING ACCEPT Registration request ack Encapsulated in RRC message MIP_Direct_Transfer Registration request [Care Of Address, NAI] MIP MAP MM Home Network HLR 2 MIP 3 MAP MAP Registration request ack 3 4 MIP 4 MM 4 MIP Encapsulated in RANAP message MIP_Direct_Transfer *.MAP_SEND_AUTHENTIFICATION_INFO_ACK is to be meant as NOT upgraded. No IP information is carried on it. Figure 15: Messages flows for registration if HLR is not upgraded. The two authentication procedures are totally independent Discussion on the benefits and drawbacks of the two options Conceptually these two approaches (MIP authentication from the UE or not) addresses two different concerns: First approach attempts to spare radio resources and pushes forward an integrated solution GSM-SS7/MIP. Second approach keeps the two domains independent and does not need HLR updates but introduces redundant procedures. To make a choice, several parameters play a role: If MIP information to be sent to Home Network is huge, it could be better to store it only in UE instead of adding heavy modification in HLR. If an all-IP Core Network appears to replace the SS7 solution, the two redundant procedures would only be a temporary stage. Second approach would allow soft introduction of Mobile IP in a UMTS network without modification in HLR. First approach could replace the first one if Mobile IP and MAP appear to coexist as a stable stage. 1999 EURESCOM Participants in Project P810-PF page 31 (109) Principles and Solutions for IP based Mobile Networks 2.3.2.4 Deliverable 4 If Mobile IP is only used for macro-mobility, MIP authentication is rarely performed. In this case procedure duplication may appear as marginal. Roaming in a different type of access network In the case of a different access network it is clear that Option 2 is still valid since Radio Access authentication is fully independent from IP authentication. If Option 1 is applied an interworking function must be implemented in the database that plays the role of the HLR to link Radio Access identification and IP authentication material. 2.3.3 UMTS registration with Mobile IPv6 The major difference of Mobile IPv6 compared to Mobile IPv4 is that the Foreign Agent functionality is no more used. Indeed, the CoA is directly obtained by the Mobile Station, which has Mobile IP capability. The Foreign Agent whose function was to manage the temporary addresses from the allocated CoA is no more involved in Mobile IP procedure. As far as UMTS is concerned, the UE is not really an IP node. When receiving IP packets, the IGSN forwards them towards RNC with special UMTS addressing and multiplexing. When the UE is associated a temporary IP address (e.g. conceptually equivalent to the SMTP address TMSI@subnetwork.domain.com), the IGSN has to map this address on a UTRAN Bearer. Consequently if the UE assigns itself this CoA, it will need to send it to IGSN so that it performs address resolution between IP and UTRAN. Moreover the IGSN will be the true termination point for this address since the actually used address to route packets after IGSN will be a UTRAN identifier. As a conclusion: 1. It seems to be much more profitable if CoA is allocated by IGSN (Radio resources would be wasted for no benefits otherwise) as in section 0. 2. On the other hand if Option 2 of section 0 is applied, radio resources are already used for MIP authentication. Therefore UE capability to define itself its own CoA may find some interest. IGSN does not need the Foreign Agent capability of CoA allocation – and then becomes much simpler – it just needs to forward the encapsulated MIP message to the Home Network. The two authentication procedures remain independent. page 32 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 UE MM MIP Principles and Solutions for IP based Mobile Networks RNC IGSN LOCATION UPDATING REQUEST Home Network MM Registration request (addressed to Home Agent/HAAA) [Care Of Address, NAI] Encapsulated in RRC and RANAP messages MIP_Direct_Transfer HLR MIP Store Care-Of-Address to perform correct routing MIP MIP Registration request (addressed to Home Agent/HAAA) [Care Of Address, NAI] MAP MAP AUTHENTICATION MIP MM MIP LOCATION UPDATING ACCEPT Registration request ack MAP SEND AUTHENTICATION INFO MAP SEND AUTHENTICATION INFO ACK MAP MAP Registration request ack MM MIP Figure 16: Messages flows in IPv6 with two procedures on the radio link 2.3.4 Major constraints for Mobile IP in third generation mobile system Considering Third Generation Mobile Systems, it is important to keep in mind the backward compatibility with the Second Generation Mobile Infrastructure. Mobile IP could provide a “macro-mobility” in the core network. This means that user mobility within access networks will be handled locally whereas mobility to establish connection within the core network to the ‘right’ entry point of the access network is managed by Mobile IP. This allows to be compatible with existing systems such as GPRS. Mobile IP will allow a way to manage mobility in the core network independently from the access network technology. Protocols within the Internet should provide encryption for Mobile IP signalling and for user traffic. Quality-of-service mechanisms are expected to enable widespread use of real-time services between stationary nodes, there will be a demand for using the same kind of services when being mobile. When network resources allow, there should be mechanisms to handle quality of service for mobile users, particularly in case of reverse tunnelling, route optimisation and handover. Authentication, Registration We may differentiate two phases for authentication: the initial phase (full authentication at initial registration or when a mobile node requests a new home agent), and subsequent authentication (performed at handover within the same administrative domain). 1999 EURESCOM Participants in Project P810-PF page 33 (109) MIP Principles and Solutions for IP based Mobile Networks Deliverable 4 The Mobile IP protocol specifies registrations to be performed at the home agent, and to be based on the home IP address of the mobile node. However, additional solutions and extensions to Mobile IP have introduced identification and authentication based on the Network Access Identifier (NAI). Basing the authentication on the IP address means that it is the host that is authenticated, while authentication based on the NAI results in authentication of the mobile user. The latter alternative would alleviate the connection between a specific user and a specific host, and provide a secure way for dynamic allocation of IP addresses. This is the reason why it will be possible to re-use the same types of identification as in second generation mobile systems. As seen previously, the full authentication should not be performed at the home agent, since the home agent may be dynamically allocated. Moreover, for reasons of subscription handling and charging, the full authentication should always be performed at the home domain or by the home operator, that is where the user has his subscription. 2.4 Wireless LANs and mobility The need for common, or at least interoperable, mobility management mechanisms between 3G systems and wireless LANs is becoming more acute as shortcomings in user connection bit rates become apparent in 3G systems. This paragraph presents here several mechanisms aimed at providing mobility on these radio LANs and stresses the importance and necessity of layer 3 (IP layer) mechanisms in order to enhance Mobile IP as well as to provide interworking and QoS guarantee support. 2.4.1 Layer 2 mobility support in Wireless LANs This section presents mobility mechanisms that have been designed to provide mobility on top of the Physical (Layer 1) and Medium Access Control (Layer 2) layers of radio LANs. However, these schemes make use of data frames and semantics on a 'per-hop' basis at the Logical Link Control layer (Layer 2 in the OSI architecture) and are transparent to the IP routing functions. 2.4.1.1 Proprietary layer 2 mobility schemes Some wireless LAN products provide ‘roaming’ capabilities. These encompass two mechanisms: radio and MAC-level de-association and re-association procedures (now standardised in e.g. IEEE 802.11 [75]) as well as ‘handover’ procedures that are usually initiated by the Mobile Station and relayed by the new Access Point (AP) to inform the old AP that it can release the resources previously used by the roaming MS. Such handover protocols use a proprietary interface to the SNAP/LLC service, alongside normal application data and network OS protocols. The problem with these roaming schemes is that they are proprietary. Mobile Stations can not therefore roam between access points from different vendors. page 34 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 2.4.1.2 Principles and Solutions for IP based Mobile Networks The Inter-Access Point Protocol (IAPP) Origin of IAPP The IAPP (Inter-Access Point Protocol) [77] is a specification that defines how access points from different vendors communicate with each other to support mobile stations roaming across cells. The IAPP specification builds on the baseline capabilities of the IEEE 802.11 standard. Where the IEEE 802.11 standard addresses the physical and media access control layers of the OSI reference model, the IAPP specification tackles higher-level OSI layers such as logical link control that facilitates inter-access point communications. Overview The IAPP specification describes methods of access point co-ordination in a wireless network and provides information necessary for the efficient handling of mobile clients. Figure 17 shows a wireless LAN system architecture in which stations are associated with a particular access point. A distribution system is used to extend the wireless coverage area, which is viewed as a single logical network. All stations can communicate with all other stations providing an appropriate Integration Service is present in the access points. For example, an integration service is needed for a wireless station to communicate with a server that is a node on the distribution system. Server Router Distribution System AP a STA a1 AP b STA a2 STA b1 Figure 17: IAPP topology The internals of the Distribution System are not defined by IEEE 802.11 and there is no exposed interface to the Distribution System. The integration between the distribution system and IEEE 802.11 networks is handled entirely in the access point and is transparent to the applications and network software running on both ends. The IAPP provides a mechanism by which access points can exchange information, which is used to enhance mobile client access to the distribution system. Figure 18 provides a pictorial view of the applicable protocol stack. 1999 EURESCOM Participants in Project P810-PF page 35 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 Access Point Management IAPP handler UDP IP Other network (Hiperlan, MMAC…) IEEE 802.11 MAC MAC Management Interface Figure 18: IAPP protocol stack in the Access Point The IEEE 802.11 system supports mobility across coverage area limits (which are referred to as BSS boundaries). Stations may move from one BSS to another and maintain their higher-level network connections. This mobility is enabled through the use of IEEE 802.11 management frames and the Inter Access Point Protocol (IAPP) which is used to communicate on the distribution system (wired or wireless). The IAPP is implemented on top of UDP/IP so that it will work across router boundaries. The IAPP is an extension to existing management protocols. By specifying how access points will communicate with each other, the IAPP defines two major functionality: Roaming by mobile stations across BSS boundaries Methods to handle access point awareness Mobile station roaming The HANDOVER methods of the IAPP enable to: Inform the old AP that support for a mobile station has been assumed by another AP, allowing it to: Release the resources that were assigned to support the station Update its layer 2 filter table to appropriately forward frames destined for the mobile station Discard or forward buffered frames for the roaming mobile station This is achieved by a forward handover signalling protocol in which the new and old Access Points exchange addressing information. This is further explained below. Update filter tables of intermediate MAC bridges to appropriately forward frames destined for the mobile station. The handover procedure is tied into the IEEE 802.11 Reassociation procedure (or similar from a different wireless protocol); it is initiated when an access point receives a reassociation-request from a mobile station. Via the Reassociation-request message of 802.11, the mobile station provides the MAC address of the old AP. The new AP is required to translate this MAC address into the old AP's IP address. This can be accomplished by various mechanisms such as address resolution protocols (e.g. RARP) or configuration management. Building a page 36 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks translation table from ANNOUNCE messages is an option provided by the IAPP itself (see next sub-section). Figure 19 outlines the main steps and message exchanges of the IAPP Handover protocol. Mobile Station Old Access Point Distribution System (IP or Layer 2 fwd) New Access Point IEEE 802.11 Reassociation IAPP Handover re-association requests HANDOVER.request Retries or timeout re-association response HANDOVER.response Figure 19: IAPP HANDOVER protocol Access point awareness IAPP defines an ‘Announce’ protocol. The intention of this protocol is to: Inform the other access points that a new access point has become active and provide the new AP’s addressing and configuration information. Inform the other APs of the continued operation of a particular AP. Allow an AP to request addressing and configuration information from the other APs Allow APs to negotiate over configuration attributes The ANNOUNCE protocol PDUs are multicasted to other IAPP-compliant Access Points and carry Access Point information elements such as: MAC address, ANNOUNCE protocol advertisement interval, frame forwarding capabilities, handover timeout, MAC beacon period, PHY layer (e.g. FH or DS), PHY channel, … 2.4.1.3 Hiperlan 2 (BRAN) and MMAC mobility Mobility Functions are not addressed by BRAN or MMAC systems. The standardisation work done in these bodies will not address the layers above the MAC. 1999 EURESCOM Participants in Project P810-PF page 37 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 It is therefore possible to use IAPP as a mobility mechanism for BRAN or MMAC Access Points. Alternatively, Access Points could behave as IP routers with a wireless interface and implement Layer 3 mobility schemes as described in the next section. 2.4.2 Layer 3 Local Mobility: ‘cellular IP’ There is a number of reasons why it may be desirable to implement 'micro-mobility' functions at the IP layer: 2.4.2.1 Legacy wireless LANs roaming schemes are not interoperable IAPP only addresses mobility within a subnet Mobile IP has capacity and performance limitations It provides the opportunity to integrate mobility with other network-related frameworks: QoS, IPSec, multicast… Basic micro-mobility protocols Fast handover protocol This scheme proposed by Bell Laboratories and Berkeley University [80] makes a clever use of the gratuitous and proxy ARP features of the address resolution protocol to maintain the illusion that wireless hosts reside on a wired link. The handover protocol itself is a lightweight forward handover scheme that uses ICMP packets for signalling. It enables fast handover of IP traffic between base station routers. The most intelligent feature of this protocol is to re-use gratuitous ARP as a ‘location updating’ procedure for the local corresponding hosts and the gateway router(s). Multicast protocols for mobility This approach is similar to the virtual connection trees that were once proposed for wireless ATM [87]. However, IP has a whole suite of multicast routing protocols (MOSPF [82], DVMRP [81], PIM [83] and [84], CBT [85] and [86]) that make this approach more attractive for IP traffic rather than ATM traffic. The idea is that Mobile Hosts are ‘identified’ by a multicast group address. Other hosts wishing to communicate with the Mobile Host join this multicast group. Intermediate routers then ‘conspire’ (using one of the multicast routing protocols mentioned above) to form a multicast ‘tree’ between the Mobile Host and its correspondents. In these schemes, base stations are multicast routers (Figure 20). Mobile Host Correspondent Host Figure 20: Multicast mobility generic principle page 38 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks When it changes radio cell, the Mobile Host first establishes Layer 2 connectivity with the new base station. It then sends an ‘ICMP Membership report’ to ask the base station to join the multicast tree. The multicast routing protocol process in the base station then handles the protocol-dependent signalling to form the new branch. Multicast routing protocol ‘join’ messages only travel in the network up to the nearest on-tree router. Branches at old locations either timeout or are explicitly ‘pruned’. Micro-Mobility concepts The main features of these two basic schemes can be summarised as follows: 2.4.2.2 Host addresses have no topological significance within the 'mobile subnet'. Mobility-enabled nodes (base stations) do not perform IP routing but use PerHost Forwarding instead. Mobility signalling messages trigger the creation or deletion of Per-Host Forwarding entries in the IP routing table of mobility-enabled nodes. Host mobility is 'invisible' outside the 'mobile Subnet': datagrams destined to mobile hosts are routed normally down to the gateway. Mobility is restricted to the 'mobile subnet'. The schemes propose to handle inter'mobile subnet' mobility with Mobile IP. Cellular IP and HAWAII The next paragraphs present common features of other recent, more elaborate, micromobility schemes that build on these concepts: Cellular IP [91] and the HandoffAware Wireless Access Internet Infrastructure, or HAWAII [90]. Mobility-enabled stub Domain To achieve the desired de-coupling between macro-mobility and local, 'continuous' changes in the host's point(s) of attachment with the network, a two-level architecture is assumed. The top-level of the hierarchy is the Internet as we know it: a collection of interconnected packet-switched networks in which datagrams are forwarded according to routing tables (dynamically established and maintained by protocols such as RIP, OSPF, EIGRP…) that map the subnet part of the destination address in a packet's header to a router interface. At the bottom level (see Figure 21), a collection of interconnected mobility-enabled Nodes forms a stub Domain, in which all traffic has either been sourced in the Domain itself or will be sunk in it. At the edge of this stub mobility-enabled Domain are Nodes with (wireless) Layer 2 interfaces, also called Base Stations4, between which Mobile Hosts are free to roam. The mobility-enabled Domain connects to the higher level of the hierarchy through a unique Domain Ingress Node. Viewed from the higher-level Internet, the Domain is a 'flat' address space (subnet). All packets addressed to this subnet are routed to the Domain Ingress Node. 4 Here we assume that Base Stations implement IP routing. In fact, as far as the mobility scheme is concerned, mobile hosts communicate with neighbouring mobility-enabled IP nodes. Such a node may not necessarily be the device (base station) to which the mobile node is physically connected, but may be 'deeper' in the transmission network (e.g. data IWF). 1999 EURESCOM Participants in Project P810-PF page 39 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 Figure 21: Mobility-enabled stub domain architecture and terminology Time-invariant topology of default routes The mobility Domain is configured so that a loop-free topology of directed routes exists at all times between all mobility-enabled nodes and the Domain Ingress Node. Once established, this topology doesn't change (except in case of link or node failure). Compared to host mobility patterns, this topology is invariant. The mechanism used to establish and maintain this topology is scheme-dependent. The following default traffic routing rules apply within the Domain to enforce stub operation and delivery to inactive Mobile Hosts: By default, any traffic originated in the Domain is propagated 'up' the topology towards the Domain Ingress Node (source routing or hop-by-hop). This is essential to mobility management. By default, any traffic originated outside the Domain (mobile terminated traffic) is propagated 'down' the topology from the Domain Ingress Node or discarded. The exact forwarding mechanism (broadcast, unicast, multiple unicasts, multicast - hop-by-hop or end-to-end) is scheme-dependent. This is essential to paging (explained later). The case of intra-Domain traffic (e.g. mobile-mobile traffic) handling is schemedependent. Note that a mobility-enabled Domain is an overlay to a standard IP network. However, the mobility-enabled Domain remains logically disjoint of the underlying IP network and stub operation is enforced. This is because the time-invariant topology of default routes is rooted at the Domain Ingress Node and exterior Internet routers route IP addresses for the Domain's space to the Domain Ingress Node. Note also that several Domains may be configured on the same 'physical' IP Network but they are still logically separate. Distributed Per-Host Forwarding page 40 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks All schemes are distributed: all Nodes within the Domain have forwarding tables that may contain Per-Host Forwarding Entries (PHFEs). A PHFE contains the one-hop reachability information for an individual Mobile Host: it is a mapping between a Mobile Host Identifier and one of the Nodes interfaces through which the Host can eventually be reached. These PHFEs override the default traffic forwarding rules stated in the previous paragraph. PHFEs are only used to forward data to Mobile Hosts, that is 'downlink' mobile terminated traffic only. Please note: Location-independent Mobile Host Identifiers are mapped to IP addresses from the Domain. In current schemes, this mapping is implicit (i.e. there is no Host ID/IP Address translation function) and permanent. Address assignment is scheme-dependent and also depends on how the scheme interworks with Mobile IP. PHFEs are maintained as soft-states (they have limited lifetimes). The refresh mechanism is scheme-dependent. Whether the co-existence of several PHFEs for a single Mobile Host within a Node is allowed is scheme-dependent. This may be desirable for 'soft' handover or advance branch setup to minimise the gap during handover. Hop-by-hop standard IP routing is used to forward 'uplink' traffic such as control messages (or mobile-originated user data if hop-by-hop forwarding is mandated). The time-invariant topology of default routes enables hop-by-hop 'uplink' packets to always travel up to the Domain Ingress Node if they are not discarded by an Intermediate Node. This ensures that location information is always forwarded to the Domain Ingress Node, which has a role similar to the Gateway MSC in GSM networks. End-to-end standard IP routing is used to forward other 'uplink' traffic. Therefore Mobile Originated (MO) user data does not necessarily have to go through the Domain Ingress Node. There can be multiple Internet gateways for MO user data. Per-Host Time-variant tree of routes Mobility Management is performed by maintaining a time-variant tree of routes from the Domain Ingress Node to the Mobile Host, for every Mobile Host currently in the Domain's coverage area. This tree is formed by the succession of PHFEs in the Domain's Nodes for that particular Mobile Host. Requirements: New PHFEs need to be created along the path from the BS up to the Domain Ingress Node when a Mobile Host first powers up in the coverage area of a BS that belongs to the Domain or when an already powered-up Mobile Host hands over to the Domain from e.g. another Domain, a fixed LAN, a BRAN access network, … Existing PHFEs need to be updated (or new ones created) when a Mobile Host enters the coverage area of a new base station or after a radio black-out. Existing PHFEs need to be periodically refreshed as long as the Mobile Host remains powered-on and is in the Domain's coverage area. 1999 EURESCOM Participants in Project P810-PF page 41 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 Old PHFEs may need to be explicitly deleted after a handover if loss of packets is to be avoided. Mobility Management operations: The PHFE create/update/refresh functions are triggered in each Node by incoming 'uplink' traffic: either control messages or MO user data packets that propagate towards the Domain Ingress Node. Figure 22: HAWAII Per Host Forwarding Entries (PHFEs) update after handover and explicit delete of PHFEs pointing to the old Base Station [90] The PHFE explicit delete function requires to send control messages 'downlink' of the default topology and maybe also direct messages (e.g. between old and new BS Figure 22) using end-to-end standard IP routing. Interworking with Mobile IP It is assumed that the Domain Ingress Node acts as a Home Agent for the Mobile Hosts that are 'usually' in the Domain it serves. However, since it does not have linklayer connectivity with Mobile Hosts, it does not broadcast Agent Advertisements. The way by which nodes can tell whether they are in their home Domain or not is scheme-dependent. Other Mobile IP-related functions are also performed by 'edge' nodes (Mobile Host, Base Station, Domain Ingress Node): Mobility Agent Advertisement Registration Request Processing Home Agent binding refresh Decapsulation of tunnelled packets page 42 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks The repartition of Mobile IP functions between edge nodes is scheme-dependent. Depending on how these functions are distributed, Mobile Hosts will be identified in a Foreign Domain by either their Home Address (dynamically or statically assigned) or a co-located Care-of Address (see Figure 23). Figure 23: HAWAII Per Host Forwarding Entries (PHFEs) update after handover and explicit delete of PHFEs pointing to the old Base Station [90] Support of paging In public cellular wireless networks, paging trades off location tracking accuracy (and hence 'connection' delay) for a better utilisation of resources. In the context of mobility schemes, paging support achieves two goals: Paging minimises power consumption of terminals that do no transmit data (idle state) by allowing them to refresh/update their PHFEs in the Domain less frequently. Paging reduces signalling load and memory requirements incurred by the maintenance of PHFEs for idle Mobile Hosts in all nodes of the Domain. Requirements on micro-mobility schemes to support paging (from [90]and [91]): Some Nodes in the Domain may maintain a Paging Table in addition to the PHF table, (which we now call Routing Table). In any case, a Paging Table is maintained at the Domain Ingress Node. A State Machine (null, active, idle) has to be maintained in the Mobile Host and in Nodes that have Paging Tables. State determination and synchronisation within such Nodes can be achieved by comparing the soft-states of both Routing and Paging entries. Outline of paging operation: 1999 EURESCOM Participants in Project P810-PF page 43 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 In idle state, Mobile Hosts only send periodic Paging Update control messages. If paging is supported at Layer 2, Mobile Hosts also send Paging Updates when they cross paging area boundaries. Paging is initiated by a Node that receives traffic destined to a Mobile Host for which it has a paging entry but no routing entry. Incoming traffic is buffered at the Node until the paging procedure is completed. A Paging Request control message is broadcast 'downlink' of the time-invariant topology of default routes. Upon reception of the Paging Request, the Mobile Host switches to active state and sends a Paging Response or a Routing update that is propagated in the 'uplink' direction until it reaches the Node that initiated Paging. The Node stops buffering and forwards previously buffered traffic. page 44 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 3 Principles and Solutions for IP based Mobile Networks Real-Time services on IP networks Although the IP protocol has held centre stage since the development of the Internet, IP packet switching still cannot meet the requirements of number of services concerning QoS provisioning. Consequently, the real-time services provided by UMTS systems (voice, video, …) may not be reliable if the interconnection of UTRAN is realised through an all-IP backbone. The two main factors that strongly impact real-time requirements are: Transmission end-to-end delay Delay variation First of all, this chapter will show that these issues are directly related to bandwidth reservation and queues handling. Different approaches and solutions are shown: Latency problems are closely related to queuing techniques. These can be addressed by guaranteeing a certain amount of bandwidth. RSVP is a solution for bandwidth reservation BUT presents some drawbacks especially for large scale networks. Diffserv and MPLS can bring alternatives to these problems. The conclusion of this chapter will present a synthetic architecture that attempts to take into account the different constraints. 3.1 Queuing techniques The control of latency and delay variation strongly depends on the queuing techniques implemented in the nodes of the network. A packet arriving in a node is processed before it is put in a queue for retransmission purpose. This operation can vary according to the size of the packet and the state of congestion in the network. The currently used Best Effort algorithm in IP networks (simple FIFO queues) does not allow any preference for any packets (requiring a certain QoS or not). Some queuing techniques may allow to provide different kinds of QoS. These take two aspects into account: a) Ordering of packets in output queues and b) Packet loss management. a) Ordering techniques FIFO Class Based Queuing Simplest way of proceeding: all packets are treated with the same priority. Packets are put in different queues which are all FIFO. Each queue is affected a priority. Priorities can be handled by different scheduling algorithms among which is the Weighted Round Robin algorithm: each queue is assigned a ratio of time. (Weighted) Fair Queuing The idea is to allocate a given ratio of bandwidth to a service as soon as this service requests for resources. This could be applied if the bandwidth could be arbitrarily fragmented between services which is obviously not the case. GPS (Generalised Processor Sharing) is an ideal but unrealistic application of the concept. Therefore PGPS (Packet adapted version of GPS) is usually used instead. 1999 EURESCOM Participants in Project P810-PF page 45 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 b) Packet loss management Simple Overflow RED (Random early detection) and WRED (Weighted Random early detection) Packets are dropped when the queue overflows. Random Early Detection is a queue management scheme that drops packets randomly. Since packets are randomly selected, they are likely to belong to different flows. This will trigger the TCP flow control routines at different end hosts to reduce their send rates at different time. By doing so, RED can prevent the queue at the routers from overflowing, and therefore avoid the drop-tail behaviour of routers when their queues overflow. RED has been proved to be very useful and is now widely deployed. RIO (RED with If the traffic does not exceed the bit rate specified with the ISP, it is In and Out) considered as in profile. Otherwise, the excess packets are considered as out of profile and are put into the same queue as ‘in’ packets to avoid out of order delivery. RIO basically maintains two RED algorithms, one for in packets and one for out packets. There are two thresholds so that the ‘out’ packets are first dropped and if the second threshold is overcome the ‘in’ packets are also dropped. 3.2 IntServ and RSVP The Intserv framework specifies four components: the packet scheduler, the admission control routine, the classifier and the reservation setup protocol, usually RSVP. Applications requiring guaranteed service must set up the paths and reserve resources before transmitting their data. The admission control routines will decide whether a request for resources can be granted. Best Effort traffic can be sent immediately without any admission control or path setup. When a router receives a packet, the classifier will put the packet in a specific queue based on the classification result. The packet scheduler will then schedule the packet accordingly to meet its QoS requirements. RSVP is a signalling protocol that provides a simple way to allocate bandwidth. 3.2.1 RSVP messages The RSVP reservation mechanism is done in two steps by the mean of two messages. PATH Message and RESV Message: The PATH Message is sent by the transmitter to all recipients and contains characteristics of the stream – i.e. burst size, mean rate. The RESV Message is sent by the recipient(s). It configures the different routers to reserve the correct amount of bandwidth. The routing of the message is achieved through the path stored in the PATH message. A non RSVP router will just forward the messages transparently. If a message is lost one can wait up to 30 seconds before completing the procedure. To avoid such delay, one solution may be to use a special and high-priority queue in each node dedicated to this signalling (see also 0). page 46 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks 4 Transmitter 1 2 3 Receiver Receiver Flow of RESV message Network node Resources reservation Figure 24: Transmission of RESV Messages from the receivers to the transmitter in RSVP 3.2.2 RSVP issues and limits Some constraints have to be considered within RSVP: CPU limitations: Extracting information such as source/destination addresses and ports to sort incoming packets, process for reservation, heavy calculation (PGPS), etc., needs a rather high CPU capacity. Over-provisioning: The reserved bandwidth will most of the time induce a much lower delay that the guaranteed one (i.e. RIO) due to over dimensioning of the RSVP protocol. - This can be solved by setting RSVP parameters a bit less strictly. Soft State: Each router has to be configured by RSVP in a soft state in fact each time the PATH message is sent. The PATH messages are present during a connection to reroute the flows when the network is congested. This increases a lot the volume of signalling and prevents from installing a too large network of RSVP routers. 3.2.3 Towards a layered architecture The computing overhead at each hop is really a big matter and prevents from implementing RSVP as a general technique: this must be used when needed and avoided in large scale networks. But it is so far the only way to guarantee time delays and to leave in the same time all the unused capacity to lower quality services. As it is not realistic to have an IP backbone using RSVP routers, we can take advantage of the RSVP capability of ignoring non RSVP routers: indeed an interesting architecture could integrate low scale IP access networks implementing RSVP connected with each other by an over-dimensioned IP backbone implementing other solutions for real-time services. 3.3 DiffServ Differentiated services enhancements to the Internet protocol aim at enabling scalable service discrimination in the Internet without the need for per-flow state and signalling at every hop. In Differentiated Services, packets are classified and marked at the network ingress routers to create several packet classes. Packets in different classes receive different 1999 EURESCOM Participants in Project P810-PF page 47 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 services. It is a way for customer to request a specific performance level on a packet by packet basis, by marking the DS field of each packet with a specific value. Differentiated Service Field and forwarding treatment The DS field (structure in Figure 25) corresponds to the field of IP packet header in which the Differentiated Services class is encoded. It is the Type of Service (TOS) octet in the IPv4 header or the Traffic Class octet in the IPv6 header. 0 1 2 3 4 5 6 7 DSCP CU DSCP: Differentiated Service CodePoint CU: Currently Unused Figure 25: Structure of the DS Field Six bits of the DS field are used as a codepoint (DSCP) to select the Per Hop Behaviour (PHB: description of the forwarding treatment) a packet experiences at each node. The DSCP field allows to differentiate priorities among several flows, larger numerical value meaning higher priority. Class Selector Compliant PHBs can be realised by a variety of mechanisms, including strict priority queuing, weighted fair queuing (WFQ) as already mentioned in section 0. [48]. Service level agreements In order to receive Differentiated Services from its ISP, a customer must have a Service Level Agreement (SLA) with his ISP. A SLA basically specifies the service classes supported, and the amount of traffic allowed in each class. After being marked by customers according to the desired service, the ingress node of the ISP networks classifies, polices and possibly shapes the packets, depending on the agreed SLA. When a packet enters one domain from another domain, its DS field may be re-marked, as determined by the SLA between the two domains. Using different classification, policing, shaping rules and scheduling algorithm in the routers, many services can be provided, for example, 1) Premium Service for applications requiring low delay and low delay variation; 2) Assured Service for applications requiring reliable but not fixed delay bounds; 3) Olympic Service, which provides three tiers of services: Gold, Silver and Bronze, with decreasing quality; and 4) Best Effort Service, which is the same as today’s Internet service. Comparison of Diffserv with RSVP/Intserv There are only a limited number of service classes indicated by the DS field. The DS fields of packets of flows from different sources to different destinations may be marked identically. These packets will receive identical services inside the ISP networks. Since service is allocated in the granularity of a class, the amount of state information is proportional to the number of classes, not proportional to the number of flows. Differentiated Services therefore provide a scalable QoS solution to ISP networks. Sophisticated classification, authentication, marking, policing and shaping operations are only needed at boundary. ISP interior routers need only to implement Behaviour Aggregate (BA) classification and some simple scheduling algorithm. Therefore, Differentiated Services is easier to implement and deploy than Integrated Services. page 48 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks A drawback of Differentiated service protocol is that there is no guarantee concerning the end-to-end time delivery. It only concerns a priority management among the packets. As an RSVP/Diffserv solution might be a very valuable one, Section 0 is entirely dedicated to an example that brings both concepts together in the same framework. 3.4 ATM Another way to differentiate flows with different QoS is to multiplex IP packets on ATM Virtual Circuits (VC). Each VC is affected a class of service. Within a VC, Best Effort scheduling algorithm is applied. This is basically the same principle as Diffserv except the fact that ATM can guarantee QoS for one VC which cannot be the case for a Diffserv class. Everything happens as if the IP traffic uses different pipes in the network according to its service classes. The VCs are of course re-configurable according to the amount of traffic in different classes of service. It is worth noting that nothing is guaranteed for one application since congestion might happen within a class of service. 3.5 MPLS This technique is conceptually directly derived from the ATM concept described above. MPLS is a forwarding scheme. It evolved from Cisco’s Tag Switching. In the OSI seven-layer model, it is between Layer 2 and Layer 3. The network protocol can be IP or others. This is why it is called Multi-Protocol Label Switching. MPLS is a way to build Virtual Paths in all-IP networks. Such a Virtual Path is called LSP (Label Switch Path) and is set up between a series of MPLS capable routers, also called LSRs (Label Switched Routers). The reservation capability of ATM is not present in MPLS. A MPLS LSP can be considered as a tunnel. When a packet enters the start point of the tunnel, its path is completely determined. The packet will follow the tunnel and emerge at the other end. Benefits and limits, comparison with ATM Controlling the routeing allows to have a more optimised use of the network. For instance it is possible to reserve some parts of the network to real-time traffic and to send Best Effort streams on a more likely congested part. This is the most valuable point for our purpose. MPLS does not provide any priority driven techniques to insure better service for any given Class of Service. It should be associated with Diffserv to achieve such a purpose. It has less overhead than ATM. ATM would require each boundary switch to be an ATM switch and an address resolution protocol between IP and ATM addresses. It still keeps the connection-less flexibility feature (no need for systematic connection establishment procedures). 1999 EURESCOM Participants in Project P810-PF page 49 (109) Principles and Solutions for IP based Mobile Networks 3.6 Deliverable 4 Complete architecture to manage QoS in IP networks As presented before, RSVP is not scalable for large IP networks whereas Diffserv and MPLS are able to differentiate traffic with different QoS even in large IP networks. However Diffserv and MPLS are less reliable than RSVP as far as QoS is concerned because they only prioritise the traffic and they do not give any insurance on the delivery time of the traffic as RSVP does. Consequently, to guarantee QoS in IP networks, the use of RSVP is optimum in corporate networks whereas in transit networks Diffserv or MPLS is more adequate. To provide an acceptable alternative, Diffserv has to be associated with an overdimensioning of the network. The example of Figure 26 proposes a framework in which Diffserv capable networks provide aggregate QoS services, and they co-exist and interoperate with RSVP/Intserv capable hosts and stub networks, which use end-to-end signalling and RSVP. This example is presented with Diffserv but MPLS could have been deployed in the transit network. Tx Stub Network ER1 BR1 Transit Network BR2 Stub ER2 Network Figure 26: Example of Network Configuration Edge Routers (ER1, ER2) and Boundary Routers (BR1, BR2) are deployed at the interface between Differserv and Intserv networks. In this manner, it is possible to provide end-to-end QoS through a combination of networks that support RSVP style reservations and networks that support Diffserv style prioritisation. The successful arrival of RESV messages at the original sender indicates that admission control has succeeded both in the RSVP regions of the network and in the Diffserv regions of the network. 3.7 Guarantee of QoS with mobile terminals As seen before to provide a given level of QoS in fixed IP network is not so easy and IETF is still searching for appropriate solutions. 3.7.1 Difficulties due to the mobility of IP terminals This part aims at underlining the supplementary difficulties to guarantee a level of QoS in a network supporting the Mobile IP protocol and managing mobile terminals. The path of the connection between two mobile terminals is going to be modified by the move of one of them; the newly involved routers in this connection may not be able at that time to provide the same QoS and the process of reservation of the RSVP protocol for example has to be re-done between the two terminals. A service degradation may apply for the users. In the Diffserv case, if a user wants to change his service profile (Service Level Agreement) he has to notify his ISP. After notification, the network nodes have to page 50 (109) 1999 EURESCOM Participants in Project P810-PF Rx Deliverable 4 Principles and Solutions for IP based Mobile Networks be configured manually by a network operator within one or more ISP domains. This results in significant delays in the range of hours or even days. Therefore, Diffserv based on static service level agreements is not suited for dynamically changing communication requirements in the Internet. Highly dynamic environments and the static bandwidth allocation concept of Diffserv are contradictory. The goal should be to support dynamic service level renegotiations in order to allow appropriate response to the dynamics of mobile users. 3.7.2 Also with Diffserv, billing is based on SLAs which are either pre-configured or dynamically setup if a SLA negotiation protocol is used. In addition to the static SLA negotiations, additional billing and accounting procedures have to be provided for the case that a mobile node visits a foreign network and requests to use the SLAs of the foreign network. Currently, some protocols are under development to exchange QoS parameters between users and ISP as well as between ISPs. In general, the mobile node needs some mechanisms to indicate to an entity of the network that it desires a certain QoS. Solutions for IP terminals The adaptability of the mobile terminal to the characteristics of a network seems to be an important element in order to combine Mobile IP and Diffserv. This adaptability could be realised at several levels: optimisation of the route or not depending on the level of quality that is required for the requested service, with for example route optimisation for the services that are not too sensitive to the bandwidth variations, adaptation of a service when a handover occurs and when the new path is not able to support the same SLA as before the handover. Consequently, it seems that to combine Diffserv and Mobile IP, new protocols need to introduce some kind of signalling for Diffserv so that the mobile terminals are capable to indicate the requested type of service. This new signalling protocol could include some functions relative to billing. In order to define a service model, two classes of real-time applications have been identified: the tolerant services and the intolerant services in respect to packet delay variations. These two classes correspond to the following service classes respectively: predictive services and guarantee services. To provide a guarantee service to a mobile user, two alternatives are possible: this guarantee may depend on the location (i.e. since the user moves from one cell to another, there is no more guarantee) or his guarantee may be location independent (i.e. the mobile terminal has the same guaranteed QoS wherever he is, given a ‘mobility profile’). The ‘mobility profile’ is the set of locations (i.e. cells) in which the user may possibly go during a call. In such a case, bandwidth reservations shall be realised for each mobile terminal following all the paths in the network leading to cells in which he may go. Outside the area corresponding to his ‘mobility profile’, the quality of service is not guaranteed. Nevertheless this process wastes a lot of bandwidth and is not realistic in UMTS. The main goal of this scheme is that delay intolerant applications do not need to wait for re-negotiation of quality of service during a call (when handover happens). 1999 EURESCOM Participants in Project P810-PF page 51 (109) Principles and Solutions for IP based Mobile Networks 3.7.3 Deliverable 4 Combining UMTS - IP We have seen before the specific problems due to the mobility of terminals in the case of Mobile IP to provide guarantee on QoS, the same difficulties are found while combining an IP network or Mobile IP network with a UMTS network. To manage different QoS, it is proposed to distinguish the types of flows (Diffserv approach). This differentiation may be done on other criteria: types of users and types of access networks (if several are linked to the same IP network). Differentiation of users means that the subscription of a user will correspond to a priority level of Diffserv protocol. The main drawbacks of such a process are the fact that the priority level of a flow may not be changed and that all the flows from the same user (audio, data, …) are indicated with the same priority level in the network. When application classes are given different priority levels, drawbacks mainly are that same types of flows form different users have the same priority level (except if a priority order between types of services and users is introduced). Further audio and video flows are competing (in certain case audio flows should have priority over video flows, in other case the priority order should be reverse). As a conclusion, a combination of these two types of priority should be realised to be more coherent as far as quality of service is concerned for mobile applications. However these techniques do not solve a possible congestion problem in the network. To sum up those problems for QoS provisioning, it seems that the use of RSVP is optimum in corporate networks whereas in transit networks Diffserv or MPLS is more adequate. To provide an acceptable alternative, Diffserv has to be associated with a fine dimensioning of the network. However, to add mobility in IP networks also complicates the way to guarantee some traffic contract and at that time no satisfying solution has been found. page 52 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 4 Principles and Solutions for IP based Mobile Networks Service provisioning in an IP based scenario This section focuses on methods and scenarios for service access by mobile users in an IP-based UMTS scenario. In the first place it provides an introduction and architectural overview on the wireless application protocol (WAP) which is conceived as a means for optimising the data content to the characteristics of the user interface and screen size of the handsets. Then, we present a short introduction to wireless-IN services with special attention to possible scenarios for Virtual Home Environment Service (VHE) provisioning by IPbased servers within the CAMEL service environment. 4.1 Wireless Application Protocol: Internet applications for mobile users In today mobile communication market, the number of services provided by operators and service providers that use Short Message Service (SMS) and Unstructured Supplementary Service Data (USSD), is growing. Among these data services, Voice mail notification or Email send and receive may be mentioned. At the same time, the Internet explosion suggests that there is a potential for wide public acceptance of several types of data services that can be made available via standard communication products. With 3rd generation mobile networks, the convergence of these two network technologies is bound to occur. A new era is opening in which operators will use wireless data services as a competitive advantage to differentiate their networks from their competitors in a well-developed mobile communication market. Operator’s effort in the enhancement of wireless data service, as well as that of Internet service providers, will be both to enable new services, in a fast and flexible manner, and to make them easier to be used, allowing end users of mobile terminals intuitive and simple content interaction. WAP is conceived as a means to fulfil the basic needs of the operators and the mobile users, optimising the data content to the characteristics of the user interface and screen size of the handsets. The WAP Forum is a widely industry-supported organisation, and, as a de facto standardisation body, produces the application framework and network protocols for wireless device such as mobile telephones, pagers, and PDAs. 4.1.1 Why WAP? Internet technology has been developed for data networks of desktops and large computers, characterised by medium to high bandwidth. But when thinking to access Internet from mobile stations, some fundamental limitations have to be taken into account. In particular handheld devices have restricted power consumption, small displays, different input device (e.g. a phone keypad), etc; the wireless network has heavy bandwidth limitation, high bit error rates, sensible delays (for example the one due to interleaving). 1999 EURESCOM Participants in Project P810-PF page 53 (109) Principles and Solutions for IP based Mobile Networks 4.1.2 Deliverable 4 The WAP model WAP adopts a model that closely follows the WWW programming model, in the sense that its components have been adapted to the characteristics of a wireless environment and optimised for the use of mass-market handhold devices. Actually: WWW-standard URLs are used to identify WAP content on servers or local resources in a device (e.g. call control functions) Content and applications are specified in well-known standard formats derived from the WWW HTML or JavaScript Standard networking protocols are based on the WWW HTTP communication protocol5 A micro browser, suitable for handheld terminals, enables the communication of requests from the mobile device to the network web server. A user agent (that is a client-side in-device software) interprets network content referenced by the URL and displays it to the end-user. To access information on Internet servers from mobile stations, WAP utilises proxy technology, that is a sort of intermediary program acting as a “translator” between the clients and the servers that have no means of direct communication. In particular, proxy functionality is split in a: Protocol Gateway, which translates requests from the WAP protocol stack (see later) to the WWW protocol stack (HTTP and TCP/IP) Content Encoders and Decoders, which translate the WAP content into suitable formats to reduce the size of data over the air link and the computational energy required by the client device to process that data. A schematic representation of a WAP network is shown in Figure 27. Wireless Telephony Applications (WTA) support is also included in the figure. Mobile terminals cannot communicate directly with web servers, but have to submit their requests to the WAP proxy. In the example, the web server may: provide content in WWW standard format and in this case filter functionality (HTML filter) is required to translate it into a WAP format (Wireless Markup Language). provide content in WAP standard format directly to the WAP proxy. Web Server WML WAP Proxy WML HTML HTML Filter Wireless Network BinaryWML MS WTA Server Figure 27: An example of WAP network 5 Actually, WAP redefines HTTP and splits it between WSP and WTP. page 54 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks In every case the proxy encodes the responses from the web into the compact binary format understood by the client. 4.1.3 The WAP architecture The WAP architecture is designed in a layered stack as shown in Figure 28. A set of well-defined interfaces enables each of the architecture layers to be accessible by the upper layers or directly by external applications (e.g. electronic mail, calendar, phone book, electronic commerce) or services (e.g. white and yellow pages). The leftmost stack shows WWW architecture for comparison sake. The mapping should be meant only as indicative, because it is not possible to trace a one-to-one layer correspondence between the two protocol stacks. INTERNET HTML JavaScript WAP Application Layer (WAE) Other Services and Applications Session Layer (WSP) HTTP Transaction Layer (WTP) TLS - SSL Security Layer (WTLS) Transport Layer (WDP) TCP/IP, UDP/IP Bearers: GSM-SMS GSM-USSD GSM-GPRS Etc… Figure 28: WAP Architecture 4.1.3.1 WAE The Wireless Application Environment is an application framework based fundamentally on WWW technologies and philosophies, adapted and extended to support also Mobile Telephony services. WAE technologies offer a micro-browser environment, provided essentially with: WML, a lightweight language similar to HTML but optimised for use in mobile terminals WMLScript, a script language similar to JavaScript to give dynamism to WML pages WTA and WTAI, a collection of libraries and interfaces for call and feature control mechanisms at disposal of content programmers to develop advanced Mobile Telephony Services Standardised data formats for e.g. images, phone book records, calendar event, and business card… 1999 EURESCOM Participants in Project P810-PF page 55 (109) Principles and Solutions for IP based Mobile Networks 4.1.3.2 Deliverable 4 WSP The Wireless Session Protocol is currently suited for browsing applications, and it is optimised for narrow-band bearers with long latency. It provides WAE either connection-oriented or connectionless session services. It includes HTTP functionality extended with facility for long-lived session states, data push and session suspend/resume. 4.1.3.3 WTP The Wireless Transaction Protocol is necessary to reliably support browsing applications, which require request/response mechanisms (i.e. transactions). It relieves the upper protocols from re-transmissions requests or acknowledgments when datagram services are used, and improves efficiency for connection-oriented services. It is designed to efficiently operate in wireless datagram networks and for implementation in “thin” clients. 4.1.3.4 WTLS Based on the industry-standard TLS, the Wireless Transport Layer Security provides data integrity, privacy, authentication between two communicating applications. 4.1.3.5 WDP The Wireless Data Protocol represents the transport layer of the WAP stack and operates above the data capable bearer services supported by various networks, acting as a “convergence” layer between such data services and the rest of the protocol stack. This is accomplished by adapting the transport layer to the specific features of the underlying bearer (e.g. GSM SMS, GSM USSD, GSM GPRS). Since each transport mechanism offers different qualities of service (in terms of throughput, bit error rate and delays), the WDP has to compensate for or tolerate these varying levels. As an example, the WAP transmission plane suitable to work over a GSM-GPRS bearer is shown in Figure 29. The GPRS is one of the several possible instances of the wireless network, depicted in Figure 29 offering a transport service to the communications between a mobile client and the WAP proxy (or server). page 56 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks WAE WAE WSP WSP WTP WTP UDP UDP IP SubNetwork SubSubNetwork Network IP Tunnel Tunnel SubNetwork TCP/IP Or Other SubNetwork TCP/IP or other SubNetwork Physical Physical Physical Base Station SubSubNetwork Network GSM RF MS GSM RF Physical BSS Physical Physical SGSN GGSN WAP Proxy/Server Figure 29: WDP architecture The messages issued by the WAE user agent are sent to the WSP. According to the fact that the service is connection-oriented or not, it sends the packet to the WTP layer or directly to the WDP layer. In the GPRS case, the WDP consists of a UDP layer, indicating the WDP destination port addressed in the WAP proxy and WDP source port. The UDP operates above the IP layer running on the Mobile Station and providing a logical connection all through the GPRS network up to the GGSN. The Gateway then sends the WDP packets to the WAP proxy via a Tunnelling Protocol, which is the interface between the Gateway that supports the GPRS service and the WAP Proxy/Server. The subnetwork may be again TCP/IP, X.25 or any common networking technology chosen by the operator. 4.2 Server-based VHE Currently the VHE service requires either to access (at the home network) or download (to the visiting network) information or data describing the user service profile, service logic programs, specialised announcements and voice print patterns. VHE services are based on generic WIN (Wireless Intelligent Network) services. In GSM phase 2+ and UMTS, WIN services will be provided on top of the CAMEL (Customised Application of Mobile Enhanced Logic) platform, that defines protocols and service creation environments ([66], [67], [68], [69]). CAMEL summarises IN service logic components into the CAMEL Service Environment (CSE) and allows for service provisioning by third party providers (TPP). Figure 30 depicts the functional architecture to support WIN services based on CAMEL. Communication between Location registers, MSC and SCP at application level is covered by MAP [70]. Communication between SSF and SCF is covered by CAP [69]. Both rely on TCAP. VHE provisioning requires either temporary download of user service profiles from home network to visiting network (shadow home service), relaying SSF queries from the visiting network to the home network's SCF (relay home service), directly interfacing SSF in the visiting network with the home network's SCF (direct home 1999 EURESCOM Participants in Project P810-PF page 57 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 command) or interfacing call control functions of visiting and home network (actual home service). In an IP based architecture server based VHE refers to either provisioning of VHE services to IP based SIP or H.323 clients, or provisioning of IN services to VHE using IP-based servers. Providing IP-server based VHE to IP-based clients seems to be out of scope, since roaming between different IP-based access networks connected to an IP-based core network could be handled completely by Mobile IP. But, since Mobile IP still poses security threats to home network and visiting network, it is not yet widely accepted. Roaming between IP-based access networks inter-worked to an SS7 core network might be handled e.g. by the Diameter protocol suite [71]. Home Network HLR MAP SCF CAP MAP MAP CAP SSF VLR SSF Gateway MSC Anchor MSC Interrogating Network Visiting Network HLR: Home Location Register MSC: Mobile Switching Center VLR: Visitor Location Register SCF: Service Control Function SSF: Service Switching Function CAP: CAMEL Application Part MAP: Mobile Application P art Figure 30: Functional Architecture for CAMEL Support according to [66] 4.2.1 IP-based VHE service provisioning The direct way to implement an IP-based VHE server is to act as a third party provider (TPP) and to provide the functionality of a service node to the CSE. Enhanced user/service interaction then might be implemented to the TPP e.g. as a web server. In this scenario a VHE server is able to execute service logic programs. Alternatively a VHE server might be used to download service profiles only. But service logic programs and user data might become quite large (e.g. 4000 SIBs rsp. 200 Mbytes of compiled code for an IN video conferencing service) and demand for a common execution environment. Although a common execution environment for service logic programs probably will be available (e.g. by executing Java byte code), the mere amount of data for downloading currently will have a severe impact on the overall network performance and will rise the post-selection delay to an unacceptable level. In the scenario depicted by Figure 31, SS7 signalling transport relies on IP. In the IETF several draft proposals currently are dealing with IP/SS7 interworking that focus on the provision of IP services to support TCAP over IP (e.g. [72][74]). Simply speaking, the services provided by MTP3 will be mapped onto IP. Another point is the addressing of SS7 entities by IP which is treated by e.g. [73]. page 58 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks In the UMTS domain, the signalling gateway should be co-located to the GGSN for performance reasons. Alternatively it is possible to co-locate the gateway to the SGSN and to use GTP for tunnelling TCAP over IP or physically co-locate the gateway to the MSC as a dedicated functional entity. In the TPP domain, signalling gateway and SCF should be co-located or, for performance reasons, might be integrated into one functional entity talking CAP over TCAP over IP to an IP-enabled SSF. Finally, in an IP-based VHE server environment a high level of security (in terms of authorisation, authentication and encryption) is mandatory, since dynamically downloading or enabling access to new services will also dynamically reconfigure the SSF by generating and deleting service trigger conditions. MSC BSSAP SGSN GTP GGSN IP GGSN+ SSF TCAP Signalling Gateway CAP IP-based Core Network TCAP over IP TPP Signalling Gateway SCP TCAP SCP Figure 31: Sample architecture for an IP based VHE Server 1999 EURESCOM Participants in Project P810-PF page 59 (109) Principles and Solutions for IP based Mobile Networks 5 Deliverable 4 Key elements for integration A number of key elements have been identified as critical for the integration of IP networks and traditional mobile telecommunication networks as well as for the harmonisation of communication protocols used in both worlds. In detail these are: Call Control; Mobility Management; Subscriber profiles; IN services; Signalling transport. The following sections will treat those key elements in some detail in order to give a clear view on requirements, available solutions and critical issues on the integration of connection oriented and connectionless portions of future mobile telecommunication networks. 5.1 Call Control aspects In the evolution towards UMTS, call control and session management for basic voice calls and PDP context establishment will be based on principles known from GSM. Nevertheless, multimedia services in UMTS will require additions that allow call handling using elements from H.323 or related standards [93], [94], [95]. Current proposals aim to run a call control and session management protocol for multimedia calls transparently via a PDP context established using GSM session management in order to allow transparent handover and roaming between GSM and UMTS, provided that GSM is capable of supporting the ongoing media service. For this purpose, it is envisaged to use IP call control based on H.323 and related protocols and probably IETF SIP and related protocols although the latter is not yet widely accepted. Evolving from the internet telephony and the video over LAN section currently the IETF RFC2543 for SIP (Session Initiation Protocol) and the ITU-T "umbrella" standard H.323 are providing a framework for audio, video and data communications over IP-based networks. IP call control is provided as a component function within. Compared to H.323, SIP is a fairly new proposal that claims to be easier for implementation and to provide faster connection set-up. On the other hand H.323 claims to be a more mature standard and becomes now widely accepted by the communications equipment industry. Additionally version 2 of H.323 provides fast connection set-up procedures. 5.1.1 Basic IP Call Management IP call management basically has to implement servers or gateways function based services for each of the listed topics. Call Control This includes application level signalling for call establishment (point-to-point and multipoint calls using unicast and/or multicast transport of media stream data), for authentication, for authorisation and admission control, for address page 60 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks resolution, for user mobility support and for call forwarding/call distribution as well as for end-system capability exchange. Related topics are the specification of addressable entities and signalling transport requirements (assured/unassured or multicast) as well as server requirements (stateless or stateful) and security (e.g. encryption of signalling messages or media streams). Call Control services This includes registration and location services for users and end-systems as well as redirection and proxy servers, alias resolution services and servers for multipoint conference establishment and/or call centre applications. In a wider sense, multipoint conference management (e.g. distribution of invitations, joining of conferences) and management of external multipoint control units (MCU) are services to IP call control. Additionally, interworking with non-IP based networks like N-ISDN, B-ISDN or GSTN requires signalling gateways and the management of media stream gateways. Interworking with location services of end-system mobility enabled transport networks is mandatory especially when roaming between different access networks. Resource control Due to its best effort nature, resource control and QoS provisioning in the context of IP relies on proper interfacing with the underlying transport layer. For this purpose, e.g. RSVP [47] provides a way of signalling resource requirements and policy parameters and gives an abstract description of transport layer management interfacing. Additionally, bandwidth management (e.g. on behalf of clients without resource management facilities and in conjunction with admission control) and management of multipoint control units are possible resource control server functions. Media stream control This includes media stream synchronisation, type conversion and encryption as well as merging and distributing media streams in multipoint conference calls (e.g. by dedicated media processors). Billing/Charging Since charging strategies for packet based and circuit switched networks are quite different and due to increased service resource requirements for multimedia calls within packet based networks, dedicated servers might be required to support resource reservation requests and/or interworking with circuit switched networks. Mobility support To support personal mobility, either passive methods (e.g. sending registration requests to a location server) or active methods (e.g. location detection by active badge systems) might be used. This results in call redirection or forwarding to certain end systems, or trying several possible user locations. Mobility also might be provided either by Mobile IP or by location management facilities of an underlying end system mobility enabled transport network. 1999 EURESCOM Participants in Project P810-PF page 61 (109) Principles and Solutions for IP based Mobile Networks 5.1.2 Deliverable 4 H.323 call control In its revision 2, the H.323 recommendation for packet-based multimedia communications provides a framework for audio, video and data communications across IP-based networks [54]. It relies on several accompanying recommendations such as H.225.0 [61] (call signalling and media stream packetisation), H.245 [55] (control protocol and format negotiation), H.450.x [62][63][64] (supplementary services) and H.332 [65] (support of panel-style conferences). H.323 signalling is based on Q.931 [56]. H.323 messages are encoded using ASN.1 PER. H.323 requires reliable transport using TCP for control information except for registration, admission and status messaging (RAS) that requires UDP. Media stream and related control information (RTCP and RSVP) transport relies on RTP [57] respectively UDP. Interworking is specified in several accompanying recommendations (e.g. H.246) with N-ISDN (H.320 and H.322) terminals, GSTN (H.324) Terminals and B-ISDN (H.310 and H.321) terminals to be implemented by a signalling and media stream conversion gateway. Media stream encryption is optional to H.323 and follows recommendation H.235. H.323 introduces the gatekeeper as an optional network management entity to provide call control services to an H.323 zone (a zone is defined by its managing gatekeeper). The gatekeeper is responsible for address translation (alias addresses to transport addresses), user registration, admission control, bandwidth control and zone management via RAS channel signalling. A gatekeeper may also provide services like call management, bandwidth management, call authorisation and directory services. An H.323 network may consist of none, one or more connected gatekeeper entities. The inter-gatekeeper protocol is not specified. To connect an H.323 network to the outside world, a gateway has to provide translation functions for signalling and media streams. In this case a gatekeeper is mandatory since it is responsible for translating incoming call addresses to network addresses. H.323 addresses are either H.323 entity network addresses (e.g. hostnames or IP addresses), connection endpoint addresses (TSAP, e.g. port numbers) or aliases. The network and TSAP address formats are specific to the underlying network architecture. Alias addresses might be e.g. E.164 addresses (optionally including zone specific access codes), e-mail addresses or more general alphanumeric strings representing names (H.323 Ids). H.323 alias addresses are unique within a zone and may reference a host, a conference or a user. Optionally location services and proxy servers are provided by a gatekeeper. That is, a gatekeeper might perform call routing and connection setup on behalf of its clients to achieve call screening or to locate a user by successively trying to connect to different endpoints. One of the deficiencies of H.323 - its complex and rather slow connection setup procedure - has been addressed by the fast connect procedure introduced in version 2 of the recommendation. This allows clients to start media stream transmissions immediately after the call setup phase shown in Figure 32 or even overlap the setup with media stream delivery. page 62 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks Caller Gatekeeper Callee ARQ (RAS) Authentication ACF/ARJ TCP SYN * TCP SYN ACK ACK Setup (H.225) Call Proceeding ARQ (RAS) ACF/ARJ Alerting Connect Call Setup Authentication SYN ** SYN ACK ACK Termcap set (TCS)/master-slave Capability Exchange TCS/master-slave/TCSack/MSack TCSack/MSack/Open logical channel (OLC) OLC OLCack OLCack Media Stream Establishment RTP Session * ** Starting TCP session for H.225 Media Stream Connection Setup Starting TCP session for H.245 Control Protocol Connection Setup Figure 32: Sample H.323 connection set-up (simplified RAS signalling ) According to H.323, a gateway has to reflect the characteristics both of a circuit switched terminal and of a packet based H.323 network endpoint in an H.323 network, in a transparent fashion. This includes the conversion of signalling information as well as the transcoding of media stream format. Simply speaking, an H.323 terminal appears as a native ISDN, B-ISDN or PSTN terminal to the interworked network. Depending on the architecture and capabilities of the gateway conversion function, the H.323 terminal might access available network functions (e.g. IN) either directly or through the help of a gatekeeper/proxy. H.323 does not specify gateway or routing functions that do not use H-series protocols, which means that interworking functions to different protocols (e.g. to access SIP servers) are not considered to be H.323 gateways. Architectural details of H.323 gateways are vendor specific and might include conversion functions or use protocols that are not covered by the standard, e.g. RSVP [47]. 5.1.3 SIP call control SIP generates HTTP-like text based messages of variable length [49]. SIP messages are either a request from a client to a server or a response from a server to a client. The protocol does not require assured message transfer and thus can be used atop UDP or TCP. Parallel requests are supported (sending multiple requests without waiting for individual responses) and multiple SIP transactions can be carried in a single datagram. SIP servers are usually stateless. 1999 EURESCOM Participants in Project P810-PF page 63 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 SIP addresses are called SIP URLs and may contain components like (or similar to) email addresses, host names/numeric IP addresses or proxy/gateway addresses and thus may reference either persons, locations or services. A SIP URL and session description might be embedded into a web page. Clicking on that link might trigger the invitation for a conference referenced by this link. A SIP URL might also include a phone number and a gateway address or name to reference a user via an internet telephony gateway to the PSTN [53] or address a user agent server. Due to its text based messaging, protocol extensions are introduced by defining new keywords (request/response headers) as e.g. done by [50] to request the called to setup a multi-party call. User data, i.e. multimedia data streams, then are handled by an appropriate RTP session. In this case SIP relies on RSVP [47] (resource reservation), RTP [57] (realtime transport), RTSP [58] (real-time streaming media control), SAP [59] (session announcement) and SDP [60] (session description) for multimedia session establishment. SIP supports media encryption using SDP and caller and called authentication using HTTP mechanisms. SIP location services are invoked from a proxy or redirect server whenever information about the possible location of a user is required. A request to a location server might return one or more user addresses, or none if a user could not be located. This may include a query to the domain name services (DNS) to resolve the hostname portion of a SIP URL. Depending on the type of connection request (invitation), a list of user addresses then might be interpreted to set-up a connection to the first address, to the first available address or to all addresses of the list. A proxy server acts both as a server and a client to either internally process the request or to perform requests on behalf of the client, e.g. after address translation. A redirect server responds to a client request by providing one or more addresses to the client, e.g. to redirect a call to a new location if the user moved to a different host or location (Figure 33). Obtaining information about the location of a user might be either active, e.g. using an active badge system for individuals, or passive by a registar accepting registration requests from the user. A registrar is often co-located with a proxy or redirect server. SIP interaction with location services is not specified. In this context SIP location services might be implemented by a gateway to GSM/UMTS location registers. For address resolution SIP uses services from the underlying IP network (e.g. ARP). Interworking between SIP and PSTN or ISDN is proposed to be provided by dedicated SS7 signalling and media gateways [52][53]. The IETF currently is working on a specification to allow the termination of native SS7/ISDN or in-band (e.g. DTMF) signalling at the gateway, but work is in a quite early stage. It is assumed that interworking with e.g. Q.931 is straightforward. page 64 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks Host (Redirect Server) Caller INVITE name@host Location Service Caller INVITE name@host location request Location Service Host ( Proxy Server) location request name1@host1 302 Moved name1@host1 name1@host1 Called INVITE name1@host1 ACK Called INVITE name1@host1 200 OK 200 OK 200 OK ACK ACK RTP Session ACK RTP Session Figure 33: Sample SIP connection set-up using Redirect and Proxy Servers 5.1.4 Gateway architecture The ETSI Project TIPHON (Telecommunications and Internet Protocol Harmonisation Over Networks) specifies interoperability mechanisms to enable multimedia communications between circuit switched networks and IP based networks. The TIPHON gateway is composed of a signalling gateway, a media gateway and a media gateway controller. One or more of these can be co-located and may also be combined with gatekeepers or with other gateways. Gatekeeper D Gatekeeper F C Media Gateway Controller A Back End G J Signalling Gateway E.b Sw itched Circuit Network N B Terminal Media Gateway E.a TIPHON Gate way Figure 34: ETSI TIPHON Gateway Architecture The Signalling Gateway provides the signalling mediation function between IP and the circuit switched domain. It may support e.g. H.323 in the IP domain and channel associated or non-channel associated signalling in the circuit switched domain. The Media Gateway provides the media mapping and/or transcoding functions. It maps (e.g. tandem free operation) or transcodes the media in the IP domain (e.g. media transported over RTP/UDP/IP) and media in the circuit switched domain (e.g. PCM encoded voice, GSM, etc.). The Media Gateway Controller is located between the Media Gateway, the Signalling Gateway and the Gatekeeper. It provides the call processing (call handling) 1999 EURESCOM Participants in Project P810-PF page 65 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 function for the Gateway: it receives signalling information from the circuit switched network and IP signalling from the Gatekeeper and controls the Media Gateways. The ITU-T H.323 Gateway functional decomposition is shown in Figure 35. Sw itched Circuit Network Signalling Signalling Gateway H.323 Signalling Gateway Controller RAS Signalling H.225 Signalling H.245 Signalling B High La yer Resource Control Gateway Control Logic SCN Signalling C SCN Sig. T ransport D A Low Layer Resource Control Packet Netw ork Media Termination Media Gateway Sw itched Circuit Netw ork Figure 35: ITU-T H.323 (SG16) gateway functional decomposition The Media Termination function terminates media streams in the packet and circuit switched domains and provides the required conversion functions. The Gateway Controller relies on the interface A protocol to create, modify and delete Media Gateway connections. Signalling interworking between the packet domain and the circuit switched domain is performed by the Gateway Control Logic component. The interface B protocol supports packet signalling transport and interworking between H.323 (i.e. H.225, H.225 RAS and H.245 protocols) and the Gateway Control Logic. Interface C describes the ISDN type call control function between the circuit switched domain and the Gateway Control Logic whereas interface D protocol conveys nonchannel associated circuit switched signalling . This decomposition preserves SS7 code points and allows the SS7 switch to serve multiple decomposed Gateway Controllers. The Signalling Gateway consists of the Signalling Transport termination to handle channel associated signalling, such as the ISDN PRI D channel. The Signalling termination supports interfacing with SS7 signalling transfer points. Resource control consists of a high level and a low level portion. High Layer Resource Control handles resources in the Gateway Controller. Low Layer Resource Control handles resources in a media gateway device. 5.1.5 IP call management in UMTS At the current status of discussion in 3GPP, call management of multimedia calls in UMTS R00 might be based on IP call control and session management probably using H.323. This scenario requires special provisions for roaming users regarding the role page 66 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks of gatekeepers. Figure 36 depicts the scenario for a mobile multimedia call between two H.323 users. H.323 Client A BS RNC SGSN Sitekeeper RNC User Gatekeeper NAT/ALG BE Operator C Domain BS H.323 Gateway GGSN SGSN H.323 Gateway GGSN Sitekeeper Operator A Domain (Client A' s Home Netw ork) User Gatekeeper NAT/ALG BE H.323 Client B BS RNC SGSN Operator B Domain (Client B' s Home Netw ork) H.323 Gateway GGSN Sitekeeper Telecom IP Interconnection backbone User Gatekeeper NAT/ALG BE Figure 36: Sample H.323 roaming scenario in UMTS In this example, Client A is roaming from its home network (Operator A) to Operator C and Client B is staying at its home network. All operators are assumed to provide gateways to the circuit switched domain (H.323 Gateway) and connect to the IP domain via some type of NAT (Network Address Translation)/ALG (Application Layer Gateway)/BE (Border Element) entity. In a first step Client A and Client B have to perform a PDP context activation involving MT, SGSN and GGSN. As one result a best-effort radio access bearer will be established between MS and SGSN to be used for identification and registration of the User Gatekeeper. The clients next identify their respective gatekeepers and register using H.225 RAS control signalling. Requests and replies from/to Client A are forwarded via the Operator C domain Site Keeper to A's home network User Gatekeeper. During H.323 call set up clients establish a new PDP context requesting real-time radio access bearers in order to decrease transmission delay for H.323 control signalling and for media streams. Clients then set-up the H.323 call according to Figure 32 starting with a Q.931 Setup message send to their User Gatekeepers. Client A messages are forwarded by the visited Site Keeper, whereas Client B messages are sent to Client A's User Gatekeeper which in turn forwards them to the visited Sitekeeper and then to Client A MT. In order to establish media streams between Client A and Client B, one or more RTP "connections" are established between both of them. The required location and routing information is provided by the corresponding User Gatekeepers. 1999 EURESCOM Participants in Project P810-PF page 67 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 If Client A wants to set-up a call to the circuit switched domain via a H.323 gateway, call processing is performed much the same way, except that the H.323 gateway of the visited network is used. For this purpose, the visited Site Keeper performs message forwarding between Client A and its home network User Gatekeeper and, respectively, between the User Gatekeeper and the visited network H.323 Gateway. It should be noted that this general scenario could be easily mapped with the last proposals for 3GPP Release 2000 all IP based solution [124]. In that solution Site Keeper, User Gatekeeper and H.323 Gateway functions are combined into a single network element called CSCF (Call State Control Function). 5.2 Mobility Management integration/interworking This chapter proposes a way to provide an integrated mobility management mechanism in the IP domain and review possible solutions. In our contribution, the term 'Mobility Management' (MM) covers mainly two functions: Registration, The process by which a user accesses a service through a terminal and a communications infrastructure. This may entail the allocation of an address used by the infrastructure to establish communications to the user, to check subscription rights, … Location management. In a general manner, in fixed networks for instance, addresses serve as both Locators (routing indication) and Identifiers (user indication). In mobile networks such as UMTS/IMT-2000, personal and terminal mobility require to separate these two roles in different semantics and to maintain a dynamic mapping between them (e.g. in GSM mapping between IMSI and Roaming Number). This is the role of the location management mechanism. There have been detailed studies of this problem for IPv6 - see [28] for details. Both of these functions require to authenticate the user to avoid impersonations (communications routed towards a non-intended recipient) or fraudulent usage (access to the infrastructure by a non-authorised user). 5.2.1 Architectural Options Several architectural frameworks are being proposed both in the mobile and IP worlds, that could be used to fulfil the Registration/Location Management/Authentication functions: Application-specific schemes for web access; media streaming, VoIP, … Mechanisms for current fixed and mobile networks, ISP dial-up… 'Out-of-band' Authentication Authorisation and Accounting in the IP domain Mobile-IP 'end-to-end' In the next paragraphs, these different approaches are detailed and illustrated by some examples. 5.2.1.1 Application-specific mechanisms The 'Mobility Management' model currently in use in the Internet community relies on application-level mechanisms to achieve host/server location transparency and resolve page 68 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks the Identifier/Locator dilemma posed by 'overloaded' IP addresses. In IPv4 and v6, it has been chosen to use 'overloaded' addresses (i.e. that are both locators and identifiers) in order to preserve the scalability of existing and future IP routing mechanisms [28]. Application-specific MM mechanisms include: 5.2.1.2 DNS [116] with the possibility of dynamic updates [118] to enable the resolution of host names that acquire IP addresses dynamically through DHCP [119], potentially through different service providers. Web (HTTP)-based applications often use ad-hoc or proprietary authentication mechanisms to allow access to certain services e.g. 'secured' web pages or extranets, free email services … SIP [49] provides the ability to query a 'Location Service' (not defined by SIP) as part of a multimedia session setup procedure (e.g. for VoIP). This Location Service enables to map a user 'name' to its current point of attachment to an IP network. SIP also provides a 'REGISTER' method to allow users to update the Location Service with e.g. their current IP address. Current network schemes Some Layer 2 mechanisms are in existence that enable roaming. Roaming can be defined as 'the ability to use any one of multiple Services, while maintaining a formal, customer-vendor relationship with only one Service Provider' (definition loosely adapted from [25]). Such mechanisms include: UPT for IN-enabled fixed networks MAP for GSM networks PPP and RADIUS [16] for Internet Service Provider (ISP) dial-up… However, in the context of UMTS, we require a global roaming capability. This requires either to: Perform interworking between the various mechanisms. Repeat Mobility Management (MM) procedures that perform the same function several times with the different infrastructures. For instance, in the case of GSM Internet dial-up access, authentication is first performed with the HLR when powering the handset and later when accessing the ISP's NAS with PPP and maybe RADIUS. Clearly, while it is possible that in the short term separate MM infrastructures will coexist, the longer-term goal is an integrated framework that alleviates the need for interworking or functional duplication. 5.2.1.3 'Out-of-band' AAA infrastructure In the IETF roaming groups (roamops) [25] and AAA [20] working groups, two approaches to a standard 'Roaming' infrastructure are being proposed. The two proposals share similar concepts: they specify application-level protocols between IP hosts and an 'infrastructure' of servers and proxies that perform NAS configuration and mediate between ISPs to exchange subscriber data such as 1999 EURESCOM Participants in Project P810-PF page 69 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 authentication parameters (algorithms, passwords…), service profiles (e.g. user wants to be connected to ISP1 between 08.00 and 18.00 and to ISP2 outside these hours)… However, roamops target specific requirements for roaming between ISPs; whereas AAA has the much broader scope to enable 'policy' implementation in IP networks. Such policies include roaming and authentication but also cover diverse topics such as QoS… Recently the IESG, a supervisory board for IP standards, has ruled that roamops should stop specifying its own AAA protocol (DIAMETER [71]) and adopt the solution currently being specified in the AAA IETF working group. However, many players believe that the AAA protocol will not be available in the next 2 to 3 years. It is therefore likely that roamops will carry on with DIAMETER while putting its requirements to AAA. 5.2.1.4 Base Mobile IP and Mobile IP 'end-to-end' Lastly, Mobile IP provides in-session mobility to IP hosts and is on its way to become an IETF standard. However, in its basic form, Mobile IP does not cope efficiently and securely with mobility between administrative domains, a key requirement for IMT-2000. The main thrust of recent work in the IETF Mobile IP working group is trying to address this issue of robust interworking between Mobile IP's procedures and other frameworks such as AAA [20], roamops [25] or cellular networks. With the Tunnel Establishment Protocol (TEP [27]), the possibility of splitting the various functions of base Mobile IP mobility agents between arbitrary numbers of Surrogate Agents is opened up. Such Surrogate Agents could act as 'flexibility points' for the Mobile-IP tunnel setup procedure/ registration update at which integration with other frameworks can happen, transparently to the Mobile IP clients. This is what we call 'end-to-end' Mobile IP, because here Mobile IP carries all the information needed by the other infrastructures (e.g. AAA or cellular) in extensions to Base M-IP messages. The Mobile Host is not involved since it is Surrogate Agents and not Mobile Nodes who perform the necessary interactions. A series of Internet Drafts have exploited this idea to serve specific requirements: Dynamic Home Address Allocation [42], THEMA, Regional Tunnel Management [45], … For instance, using TEP and Mobile IP DIAMETER extensions [46], Surrogate Agents can check AAA policy before allowing the tunnel setup across provider networks' boundaries. 5.2.2 Architectural Proposals This paragraph presents several ways in which the architectural frameworks from the previous section could be integrated to fulfil the global roaming requirement of IMT2000. 5.2.2.1 Cellular networks and AAA Since both cellular networks and IP networks maintain user authentication mechanisms, there is an opportunity to integrate the two functions for both types of services given that with IMT-2000/UMTS mobile internet access will proliferate. page 70 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks The issue here is what route should this integration take? Two possibilities exist: 1. Use the cellular HLR/AuC (or equivalent functions) as 'back-end' policy databases for AAA servers (be they RADIUS, DIAMETER or future AAA protocol…). 2. Directly interface the HLR/AuC with AAA proxies. In effect, this case strips out the AAA server of the IP network and uses the cellular functions as a replacement. This may however require more extensive modifications to the HLR or a new IWF to mediate between the SS7 interface of the HLR and the IP interface of AAA proxies. VLR SS7 networks HLR / AuC HLR / AuC Possible integration using IT (CORBA, DCOM…) Cellular Infrastructure Policy Database / subscribers profiles AAA server 1 Policy Database / subscribers profiles Policy Database AAA proxy AAA broker AAA proxy AAA server 2 AAA Infrastructure Location Service Location Service SIP Proxy FA SA Visited ISP Network Access Device: PSTN NAS, MSC IWF, SGSN, IGSN... Applications Servers e.g. session control (SIP) SIP Proxy SA Backbone Provider HA Home ISP DHCP 1 DHCP 2 Figure 37: Cellular networks and AAA integration options. Full lines represent option 1 and dotted lines represent option 2 5.2.2.2 Cellular networks and Mobile IP 'end-to-end' With Mobile IP, there is the opportunity to integrate fully Mobility Management between cellular and IP networks (Figure 38). A 3GPP feasibility study describes deployment scenarios for Mobile IP within GPRS/UMTS [2]. TIA TR45.6, the US standardisation body for IMT-2000 also proposes to integrate Mobile IP in CDMA2000 networks. With the current Mobile IP and AAA integration proposals (see previous section), there is the opportunity to fully integrate the cellular and IP infrastructures. 1999 EURESCOM Participants in Project P810-PF page 71 (109) Principles and Solutions for IP based Mobile Networks VLR SS7 networks HLR / AuC Deliverable 4 HLR / AuC Possible integration using IT (CORBA, DCOM…) Cellular Infrastructure Policy Database / subscribers profiles AAA server 1 Policy Database / subscribers profiles Policy Database AAA proxy AAA broker AAA proxy AAA server 2 AAA Infrastructure Location Service Location Service SIP Proxy FA SA Visited ISP HA Network Access Device: •PSTN NAS •MSC IWF •SGSN •IGSN... Applications Servers e.g. session control (SIP) SIP Proxy SA Backbone Provider HA Home ISP DHCP 1 DHCP 2 Figure 38: Possible integration of Mobile IP 'end-to-end' and cellular mobility management 5.2.2.3 Cellular networks, base Mobile IP and application-specific mechanisms The problem with the previous scenario depicted in Figure 38 is that it is derived from the basic Mobile IP scheme, in which whenever a Mobile Host changes FA in a visited network, the 'home' HA needs to be updated. Here it is proposed an original architecture in which the need to update a remote HA is alleviated by the introduction of an application-layer mechanism such as SIP's Location Service (Figure 39). Moreover this adds Personal Mobility on top of the Terminal Mobility provided by base Mobile IP. It proposes that in each provider domain in-session mobility is controlled by a 'local' HA, that updates an application-level Location Database e.g. through the use of a 'REGISTER' method sent to a SIP proxy. Other Authentication and Authorisation functions would be performed as normal AAA operations. With this scheme, M-IP tunnelling across provider networks' boundaries would only be needed only when a Mobile Host has a running session (e.g. VoIP call) when it changes network. After the session ends, the MH would acquire a local IP address, register it with the local HA, which would in turn update the 'home' SIP proxy. The introduction of this extra session control layer between the network and 'policy' infrastructure using SIP is similar to the Packet Cable proposals for IP Telephony [51]. page 72 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks VLR SS7 networks HLR / AuC HLR / AuC Possible integration using IT (CORBA, DCOM…) Cellular Infrastructure Policy Database / subscribers profiles AAA server 1 Policy Database / subscribers profiles Policy Database AAA proxy AAA broker AAA proxy AAA server 2 AAA Infrastructure Location Service Location Service SIP Proxy Applications Servers e.g. session control (SIP) SIP Proxy HA FA SA Visited ISP SA Backbone Provider Network Access Device: •PSTN NAS •MSC IWF •SGSN •IGSN... HA Home ISP DHCP 2 Figure 39: Using a session control layer, the need for long distance MIP tunnelling can be alleviated, with the addition of personal mobility features 5.3 Sharing user profiles Global Multimedia Mobility to be offered by 3rd generation mobile networks or future fixed/mobile integrated networks consists of the following mobility types [96]: Terminal mobility. It is the ability of a wireless terminal to access telecommunication services from several locations, even while moving, and the capacity of the network to identify, locate and track that terminal. Personal mobility. It is the ability of a user to access telecommunication services on any terminal (wireless or wired) on the basis of a personal number and the capacity of the network to provide those services according to the user's service profile. Personal mobility involves the network capability to locate the terminal associated with the user for the purpose of addressing, routing and charging the user's calls. Service mobility. It refers to the network capability to provide personalised services to the user at any user designated terminal/location and to identify the user at any access location, by supporting terminal and personal mobility. The exact services the user can invoke depend on the capabilities of the terminal at that location and on the network serving the terminal. A major characteristic of service mobility is the provision of personal service customisation capability, resulting in personalised user services: personal service customisation enables the user to define service parameters and user-specific service execution i.e. modes of service adaptation to different communication media, user location, available terminals, interfaces for service presentation and interaction, and the state of terminals. 1999 EURESCOM Participants in Project P810-PF page 73 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 Service profiles provide service specific personalisation information, i.e. parameters set at the time of service subscription (e.g. default diversion numbers related to time of day), and parameters subject to service and/or user modification (e.g. data transfer capabilities). The support of customised services necessitates the extension of service profiles to user profiles. A user profile is stored for each user containing personal information for user-specific execution of user services, e.g. with respect to dedicated terminal capabilities. In the UMTS/IMT-2000 context, personal service environment portability across network boundaries and between terminals defines the concept of the Virtual Home Environment [97] VHE will be created by a combination of capabilities located in the service provider, network operators and terminal equipment. Applications/Clients Client 2 ...... Client n Application Interface Service Capability Features Service Capabilities MExE and SAT APIs HLR CSE MExE GSM/GPRS/UMTS Protocols SAT Server CAP/MAP MS Functionality, Standardized Services Terminal View GSM/GPRS/UMTS Protocols Network Figure 40: Possible VHE service framework The VHE platform most likely will be based on wireless IN service capabilities in the 3G mobile access network (e.g. CAMEL stage2+ [98]) and on IN CS 3.1+ [99] capabilities in future integrated core networks. The service execution environment in the mobile equipment will be based on MExE [100] [101] and SAT [102]. Services might be provided either by the home environment (which is responsible for the overall provision of services to users), by the serving network or by third party service providers. Hence, user profiles contain references to distributed information and thus can be seen as distributed profiles. User profiles will be stored in a secure way in the terminal (ME or SIM) and will be managed by the ME and the network. To allow modification of user profile content by the service or service provider, user profiles will be duplicated in and/or uploaded to the service environment and updated in or downloaded to the mobile terminal. 5.3.1 From service profiles to user profiles According to [97] each uniquely identifiable user profile consists of a single and unique combination of a user interface profile and a user services profile. A user may define one or more user interface profiles e.g. to match the capabilities of different terminals, and many user services profiles to identify selected services and service parameters. A User Interface Profile consists of (e.g.): menu settings (menu items shown, menu structure, placement of icons, ...) page 74 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks terminal settings (ringing tone and volume, font type and size, screen and text colour, language, content types and sizes accepted, ...) network related preferences (language used for announcements, ...). A User Services Profile consists of (e.g.): a list of services subscribed to and references to service preferences for each of those services if applicable service status. User profiles are selected and activated on a per call basis. That is, a user might establish multiple calls, each associated with a different profile simultaneously for a single terminal. For incoming calls, the user profile is selected by the user address [103]. User Profile 1 A Service Profile User Profile 2 C Service Profile Services Virtual Home En vironment Customized, Portable Ser vices: Customized as Ser vice Profi les D Service Profile A A Service Profile B Service Profile E Service Profile C D E MExE SAT Server B Home Environment & 3rd P arty Services: Built by Netw ork Oper ator or 3rd Party Application Interf ace Service Capability Features Service Capabilities HLR CSE GSM/GPRS/UMTS Protocols CAP/MAP Serving Network Service Capability F eatures: Built by Netw ork Oper ator Service Capabilities: Pre-set by Standards Network Figure 41: User customised, portable services in the VHE The MExE functional description [101] gives a more detailed impression on which elements are likely to be summarised in the user profile, although MExE does not clearly distinguish between the roles of user interface profile and user services profile. Prior to the invocation of any service specified in the selected user profile, service profiles have to be checked for compatibility with terminal capabilities and service features. This might also require uploading to the network, modification by the network, and downloading of modified profiles to the terminal. Presumably this process requires some type of user interaction or confirmation. For this purpose, the UMTS/VHE non-framework service capability feature "Terminal Capabilities" provides a way to retrieve the terminal capabilities from the information stored in the ME and the USIM using the standardised API. This information can be considered part of the user profile. 1999 EURESCOM Participants in Project P810-PF page 75 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 The underlying service capability will be provided by the capability and content negotiation support of MExE [101]. MExE capability negotiation relies on the exchange of HTTP [106] or WSP [107] messages. On top of these (or better as an extension) the W3C CC/PP (Composite Capability/Preference Profiles) exchange protocol [108] is used to describe a user agent profile (UAprof) using the Resource Description Framework (RDF) specified by the W3C [109] and the WAP forum UAPROF WG [110]. MExE content negotiation aims to find the best possible presentation of content with respect to user preferences and terminal capabilities. It relies on the existing content negotiation capabilities already found in HTTP or WSP. It is not clear at the moment, how changes in terminal capabilities during the lifetime of a call (e.g. when removing a handheld from its docking station with its keyboard, mouse and monitor) are reflected to the handling of user profiles. Although MExE supports unsolicited notification of a terminal capability change, UMTS/VHE requires the selection of a profile to take place prior to call set-up. 5.3.2 Subscriber profiles Previous sections dealt with the users view of service profiles. From the network side, additional information is required to fully describe service capability features. In IMT2000 this information is referenced as the subscriber profile [105]. A subscriber has a contractual relationship with a service provider and may also be a user, but a user does not need to be a subscriber. Users that are not subscribers may be able to modify service parameters and profiles but are not able to subscribe to services. Subscribers may authorise further users to access services. Subscriber profiles include ([104], [105]): references to, or a local copy of items found in the repository providing the user profile (e.g. terminal capabilities, service profiles, ...), standardised billing and charging user profiles, security and authentication data, and service trigger profiles (e.g. trigger conditions, trigger information, ...). To support service transportability, information contained in the subscriber profiles is downloaded from the home environment to the visited network. This allows for dynamic arming of triggers in order to reduce the signalling load between visited network and home environment. Management of subscriber profiles (and databases) is considered to be a network capability related to roaming and service portability. The management of user profiles, as discussed in the previous section, is a subset of this functionality. The (optional) service features "Service Profile Modification" and "Service Profile Interrogation" allow the user to modify respectively to make requests about some of the parameters of the service subscription. 5.3.3 Subscriber profiles in a hybrid CO/CL environment As can be seen from the previous sections and from [105], service provisioning is strongly based on IN functionality. Thus, the support of a distributed subscriber/user page 76 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks profile in a hybrid CO/CL environment mainly involves IN interworking issues with the connectionless CN as discussed in section 0. In IN CS2 the Intelligent Access Function (IAF) provides access to non-IN structured network entities, such as IP-based servers. Thus the IAF implements the IWF between CO and CL domain of Figure 45. For example, an IAF is required to facilitate the access to user profile components stored in the MExE service environment (e.g. terminal capabilities). 5.4 IN integration/interworking In the first place, this section discusses options and possible interworking scenarios for an IN service logic, located in the connection oriented part of an hybrid CO/CL network architecture, and IP based servers and services located in the connection-less portions, probably sharing the same transport network. In this context, CO/CLinterworking mainly is assumed to provide additional opportunities for enhancement of existing IN services or for providing new services. From the users side of view, those enhanced or new services might include, for example: to use TCP/IP-based or WAP based HTML, Java and/or Web access to perform user-to-IN service interaction, or to provide Internet access to MTs without TCP/IP support, ranging from e-mail to SMS up to Web content to speech or fax transcoding (e.g. [111]). From the operators' side of view this might include: to enable Third-party provider (TPP) service provisioning using IP-based servers, as already discussed in section 0, to share resources (e.g. transcoding units) between the CL/IP domain and the CO/IN domain. Additionally, simultaneous access methods from a terminal located in the mobile domain to IN services and IP-based servers located in the CO respectively CL parts are addressed. 5.4.1 Network architecture For discussion of Interworking scenarios and access methods, a hybrid network architecture as depicted in Figure 42 is assumed. 1999 EURESCOM Participants in Project P810-PF page 77 (109) Principles and Solutions for IP based Mobile Networks Server MT BSS Server Operator Backbone SGSN Server GGSN IWU Radio Access Connection Less Inter net Firewall IN Service Environment IP MSC/ SSP Mobile Domain Firewall Server IWU CSE SCP Deliverable 4 SCP GMSC Access Network IP LE/ SSP Connection Oriented Core Network Figure 42: Assumed CO/CL hybrid network architecture Regarding the Mobile Domain and the Radio Access, no special assumptions are made. The following discussion seems to be valid for any type of radio access network that interoperates with the type of mobile operators network under consideration. The Access Network is assumed to provide a packet service based on IP, e.g. GPRS in the context of GSM/UMTS. In the connection oriented part, WIN services are provided by the CAMEL Service Environment (CSE). The Core Network is assumed to provide IN services based on INAP respectively BINAP. Connections to the internet are assumed to be provided via firewalls or interworking units with appropriate security functions. For further discussion, it is assumed that direct interoperateability of WIN (based on CAMEL/CAP) and IN in the CN (based on INAP) will not be available in the short or medium term, also due to differing capability sets. 5.4.2 CO/CL-interworking based on Intelligent Peripheral Figure 43 emphasises three different cases of interworking using an intelligent peripheral node as an interworking unit to the CL network: page 78 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks Server Server Operator Backbone SGSN Server GGSN 1 MT BSS IN Service Environment IP MSC/ SSP Radio Access 3 Firewall IWU CSE Mobile Domain Connection Less Inter net 2 IWU SCP Firewall Server SCP GMSC Access Network IP LE/ SSP Connection Oriented Core Network Figure 43: Intelligent Peripheral based interworking scenario is the intra-operator scenario, where the IP interfaces the service logic to IP-based servers connected to the same operators connectionless backbone in order to provide e.g. gateway services like an SMS or fax interface to e-mail services. provides access to WAN servers e.g. for Web access using transcoding units (e.g. text-to-speech), IP-telephony or intra-/interoperator connections via the global internet. is addressed only for the sake of completeness. Since the IP must not assume special functions for the addressed IP-server, this case covers the same functionality as for case . A fourth case, where the CN IP accesses a server connected to a mobile operators backbone is omitted since it has significance only in the context of fixed/mobile convergence. An Intelligent Peripheral (IP) might take the role of a specialised resource function (SRF) and service data function (SDF) to the IN service logic. It might also execute part of the service logic, which does not conform to the standards, but nevertheless might become necessary in order to implement complex services or to interact with IP-based servers. In the latter case, the IP takes the role of an interworking function i.e., it acts as a server to the service logic and as a client to the IP-based server. Usually, the Intelligent Peripheral is active only for the time the service logic needs to process (i.e. establish) the call. In special cases, e.g. for complex services, the user might need to modify the call or to directly control functions of the IP and co-located interworking functions during the whole lifetime of the call. In this case the service logic partly executes on the IP service node in order to free scarce SCP resources. Interaction with the service usually takes place by in-band signalling. Additionally, IN CS2 enables call associated and non-associated out-of-band signalling by its user to IN service interaction feature (USI). The USI capability is an end-to-end application protocol restricted to short messages and low bandwidth signalling . Thus it is not suitable for extensive interaction with the service, but might be used to invoke a dedicated resource interface function and to establish a control connection to the IP 1999 EURESCOM Participants in Project P810-PF page 79 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 service node. It might also be used to download the code for the resource interface function to the terminal, which enables the service to adapt to the terminal capabilities. Figure 44 shows an example for user interaction with the service logic for these cases. SCP Service Logic USI Server Signalling LE/MSC MT USI RIF IP SSP Control USI SDF SRF IWF Backbone Application Data IWF Figure 44: User/Service interaction example Currently the USI capability is not available for CAMEL stage 2, since CAP [69] is an extension to IN CS1 and maps its InitialDPArg BearerCapability parameter for compatibility reasons to the ISUP [112] User Service Information field used for USI in INAP. 5.4.3 Service logic interworking The interworking scenarios depicted in Figure 45 are based on the assumption that tunneling TCAP messages through IP is supported. In this case part of the service environment is relocated to IP-based servers in the connection-less domain. Encapsulation of TCAP messages into TCP/IP packets must be performed by a dedicated interworking unit. These scenarios resemble those discussed in the previous section, if the Intelligent Peripheral is migrated to the connectionless domain. Thus, this is a more evolved scenario compared to the interworking based an intelligent peripherals. IN CS2 introduced an Intelligent Access Function as a special case of a dedicated interworking unit. The IAF network entity resides in the non-IN (here CL respectively IP) network. It provides access to and from the SCF of the IN-structured network and maps the information between the internal and external representation. Clearly it is also possible to move the service logic completely to the connectionless domain. Although this might be suitable in selected scenarios (e.g. if the network infrastructure relies on VoIP only), it is a bad idea to replace a well established and robust IN infrastructure without a good reason. Nevertheless it seems reasonable to migrate a certain set of services (including the service logic) to the connectionless domain. In the first place, this can increase the scalability where a single SCP per service becomes a bottleneck for a complex service (such as a video conference). In the page 80 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks connectionless domain the service request simply might reference an IP-based server farm e.g. via IPv6 anycast. Another reason might be that the requested service is implemented completely in the connectionless domain such as an e-mail or Web interface. Server Server Operator Backbone SGSN Server GGSN 1 MT BSS 2 Firewall 3 IWU Firewall IWU IN Service Environment SCP IP MSC/ SSP Radio Access Connection Less Inter net CSE Mobile Domain Server SCP IP LE/ SSP GMSC Access Network Connection Oriented Core Network Figure 45: Service logic interworking scenario In Figure 45, again is the intra-operator scenario for providing e.g. gateway services. e.g. provides access to IP-based TPPs outside the mobile operators network. Clearly, security issues like authentication and encryption are of utmost importance when opening the SSF-SCP, SCP-SDF or SCP-SRF interface to the global internet. Regarding security issues, for scenario the same holds as said before in the context of scenario . As a special case, the mobile network WIN service logic and the CN IN service might reference the same IP-based server in the connection-less core. This can be seen as a way for sharing resources and to overcome interoperateability restrictions, thus being a (limited) evolution path towards fixed/mobile convergence. Figure 46 shows a possible IP-based server architecture for IN interworking, assuming that the service logic has been moved to the connectionless domain. SSF-SCF BCSM SSF IP-IWF TCAP over IP SSF-SCF IP-IWF SCF* IP Application Layer Protocol Scatter Gather Service Logic CCF BCSM SSP IWU Connection Oriented Server Connection Less Figure 46: Simple IP-based server architecture for IN interworking 1999 EURESCOM Participants in Project P810-PF page 81 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 Here the SSP exports its SSF-SCF interface to the connectionless domain using an interworking function to TCAP over IP. The core of an interworking unit to IP-based servers is a minimum functionality SCF*. It provides a minimum service logic needed to implement the basic call state model (BCSM) for originating and terminating side and interworks to the connectionless domain using a service dependent application layer protocol. Optionally a scatter/gather unit distributes service requests to one out of many servers that executes the main part of the service logic. 5.4.4 Mobile terminal access to IN services in the hybrid CO/CL scenario In a CO/CL hybrid scenario where (part of) the service logic is provided within the connectionless domain, service invocation might be handled within the connectionoriented domain and user to IN service interaction might be handled within the connection-less domain. This allows to provide a type of unified user interface to the service, based on "standard" applications like Web-browsers rather than servicespecific interfaces based on e.g. a resource interface function (with a proprietary programming interface). A typical scenario could be: 1. user at MT dials service number; 2. service triggered and service logic invoked on IP-based server; 3. service logic translates calling party number (e.g. IMSI) to IP address; 4. server sends UDP or HTTP packets to IP address and wellfined port number; a) server on MT invokes user/browser interface (if required); b) custom user interface downloaded (if applicable); 5. user interface activated and user dialogue started. Clearly this is a "best-case" scenario which requires some type of "high-end" equipment at the MT e.g., a multi-tasking/threading operating system, multiple concurrent protocol stacks and a certain degree of terminal re-configurability (Figure 47). Connection Less User Application Server/ Dispatcher Custom User Interface MT Common User Interface Packet Data SGSN Operator Backbone Server Data IWU Fax Voice MSC/ SSP SCP Connection Oriented Figure 47: Basic MT service access/interaction scenarios: fully featured MT It is a challenging task to provide service access or interaction in a manner described above also for MTs with more restricted terminal capabilities. Usually, mobile terminals are designed with a focus on size and energy efficiency, thus providing less page 82 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks processing power, storage capabilities and display/input device capabilities. E.g. in [113] some approaches for delivering graphics capabilities or Web content to thin clients are discussed on a basis of functional partitioning between wireless terminals and network infrastructure and data-specific transformation/translation. Applied to the scenario described above, if the terminal capability records in the servers data base states that the addressed terminal does not provide packet service capabilities, the service logic might establish a connection between the calling endsystem and a proxy located in the connectionless domain. The proxy then provides and controls a gateway function to the CO domain in order to perform protocol translation if the terminal has data capabilities (e.g. PPP or WAP) or content translation (e.g. text to speech) if the terminal only has voice capabilities (Figure 48). Connection Less User Application Custom User Interface Proxy Data MT Common User Interface Server (Media) Gateway IWU Data-Specific Transformer Fax Common User Interface Operator Backbone Voice MSC/ SSP MT SCP Connection Oriented Voice Figure 48: Basic MT service access/interaction scenarios: Voice&Data/Fax MTs In any case the service logic provides the same user interface to the client. User interface design thus must take into account the effects of content translation on the presentation and intelligibility of interface elements. Most likely this will require a standardisation of design guidelines. It is an interesting open issue, how an IN service can be activated from the connectionless domain if the service logic is distributed to CO and CL domains. This has some importance for MTs providing packet data service only as can be seen in the scenario depicted in Figure 49. User Application Server/ Dispatcher Packet Data Custom User Interface Common User Interface Connection Less SGSN Operator Backbone Server (Media) Gateway IWU VoIP Proxy MT MSC/ SSP SCP Connection Oriented Figure 49: Basic MT service access/interaction scenarios: Packet Data only MT 1999 EURESCOM Participants in Project P810-PF page 83 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 If IP call control and/or VoIP support is enabled in the MT and in the network, a proxy can initiate a call setup in the CO domain. If this feature is not available, there has to be some means for the IP-based server to send a trigger condition backwards to the SSF. Probably, for certain services the SCP-initiated call setup feature might be able to provide a workaround for this problem. 5.4.5 IN service logic in the TIPHON environment As discussed earlier in this section, interworking of IN and IP service logic can be achieved by the means of gateways respectively interworking functions (refer to case 1 of Figure 45). Several options are currently discussed within ETSI and ITU-T. Figure 50 gives a practical approach assuming a TIPHON gateway. In this scenario a gatekeeper provides access to the IN service logic using an INAP to H.323 gateway. Thus, IN services might be considered as backend services to the gatekeeper as discussed in TIPHON phase 2. G Gatekeeper C SCF F Media Gateway Controller A H.323/INAP Gateway E.b Signalling Gateway J SSF N CCF B Media Gateway Terminal E.a Terminal TIPHON Gate way SSP Figure 50: Sample interworking of IP and IN service logic From an IN point of view the exact location of service logic in an IP network is implementation dependent. In a H.323 scenario, service logic often will be accessible via the gatekeeper function as depicted in Figure 51. VASF VASF VASF VASF CA CA D URF H.225 H.245 Gatekeeper A RAS B Terminal URF Gatekeeper C TIPHON Gateway E CA URF VASF RAS Call Agent User Registration Function Value Added Ser vice Function Registration, Admission and Status Figure 51: TIPHON architecture service support page 84 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks The Call Agent component of a gatekeeper implements call control and access to a Value Added Service Function (VASF). The VASF might be co-located to the gatekeeper or connected via an external interface. Special attention has to be paid to service interaction with the user. If the service logic is located in the CO domain, the H.323 terminal needs to access the H.323/INAP gateway via a dedicated service node in the CL/IP domain which has to be assigned and authorised by the gatekeeper. If the service logic is located in the CL/IP domain, the gatekeeper is responsible for providing access to the service. In order to collect auxiliary information, the service logic signals with the gatekeeper Call Agent function only. Alternatively, the gatekeeper might authorise the requesting terminal to contact directly some service node (e.g. a proxy) which allows user interaction to take place during the whole lifetime of the session. This basically can be presented to the user as a regular (secure) web-server access. The latter case also applies if the gatekeeper (or an attached function) emulates an SCF and relies on entities (e.g. SDF or SRF) located in the CO domain. 5.5 SS7 integration with IP networks In the context of the integration of CO/CL networks, taking into account that the basic signalling SS7 application protocols paradigms should basically still applies in the context of MAP, CAMEL, INAP, ISUP etc…, one of the basic consideration is that, from the point of view of transport SS7 looks as a datagram network. De facto a SS7 network is a packet network specialised for the transport of signalling information, with ad-hoc addressing (global title translation, for example) and reliability characteristics. In a world that mixes a CO network like the AAL2 one with CL ones like an IP/AAL5 one, and requires an high quantity of signalling application communications between them (GPRS requires communication with HLR), it looks quite logical to verify if the deployment of a SS7 network is required. I S U P MAP CM MM T CAP I S U P MAP BSSMAP T CAP SCCP SCCP SCCP MT P MT P BSC BSSMAP TCAP SCCP - SIM - CO SCCP - SIM -CL MT P MTP - SIM SCCP BSSMAP A MAP ISUP IP ATM MT P C/D MSC/VLR HLR PSTN Figure 52: SS7 adaptation This section therefore makes some consideration about the feasibility of the transport of the SS#7 application protocols over IP. In the context of radio-mobile systems the case of the transport of BSSMAP and TCAP is considered, i.e. the provision of a SCCP simulated interface (SCCP-SIM), capable to provide both SCCP CO an CL services (Figure 52). This case could be extended to all the other protocols making use of SCCP, such as, in the case of UMTS, RNSAP and RANAP. 1999 EURESCOM Participants in Project P810-PF page 85 (109) Principles and Solutions for IP based Mobile Networks 5.5.1 Deliverable 4 General information about IP routing protocols One first consideration is that in general the IP routing protocols are extremely fast to resolve failure problems. What is still to be demonstrated is the possibility to emulate SS7 routing capabilities. As starting point some basic definitions and considerations on the most common routing protocols are provided. Internal routing: When the destination of the packet is on the same network External routing: When the destination of the packet is on a different network Address resolution: data link mapping of the IP address into a MAC address Static resolution: The routing is set by hand by the network managers, i.e. when new machines are introduced as well when some machine break, the routing tables should be updated. Dynamic resolution: it makes uses of routing protocols, in order to have a continuos dynamic update of the routing tables reflecting the current status of the network. ARP is the traditional protocol for routing within a subnet. In the case of a broadcast transport as Ethernet the mechanism is based on a broadcast request followed by unicast answers. For the external routing the host should address the router closest to the destination, for this reason the routers advertise their presence with broadcast messages sent every 7 minutes (but the hosts could stimulate the process by means of an opportune message). A router could indicate to a host the fact that there is another router closer to the destination by means of a redirection message. All these mechanisms were developed originally on network of limited dimensions, belonging to IP network used during the ‘70ies. Associated with the diffusion of IP networks , while the concept of Autonomous Systems (AS) as networks belonging to different administrations was emerging, new routing protocols were considered as described in the following sections page 86 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 5.5.1.1 Principles and Solutions for IP based Mobile Networks Interior gateway protocol: routing inside the same AS RIP [115] is a protocol between routers belonging to the same AS; it foreseen a continuos exchange of the routing information (every 30 seconds) about reachable nodes, associated with a cost function which represents the number of hops. Host refers to a default router, after that the path is optimised using the traditional redirection messages. The mechanism of generating and updating of the routing tables is in general convergent in a quick way, but in some cases of failures (when the network becomes separated in two non connected subnets), the algorithm could not converge. In order to avoid it, a limitation in the number of hops (15) is set, making this protocol non scalable for the use in large networks. Moreover the simple cost function based on hops count does not allow advanced routing based on traffic or load sharing. OSPF [117] is a link state protocol developed by the IETF used to find the routing table in the AS. It is based on the “distributed map” concepts: all nodes maintain a ‘view’ of the network topology, which is regularly updated by a flooding protocol. In other terms every router has a database which describes the network structure (Figure 53). This database is used to compute the shortest path between one source node and the other nodes in the network by means of Dijkstra algorithm or Shortest Path First (SPF). Its complexity compared to that of RIP is: N= Nodes ; M = Link ; 1 B A 4b 3 D 6 OSPF: o(M*log M) ; 2 C 5 E FROM A A B B B C C D D E E E RIP : o(N*M) TO LINK DISTANCE B 1 1 D 3 1 A 1 1 C 2 1 E 4 1 B 2 1 E 5 1 A 3 1 E 6 1 B 4 1 C 5 1 D 6 1 Figure 53: OSPF network topology rappresentation To every link is possible to associate different metrics, which are used to apply the “shortest path” algorithm and achieve different routeing tables. D (Delay) T (Throughput) R (Reliability) C (Cost) If exist equal cost paths, they can be used to perform load sharing of traffic. The protocol itself is heavily influenced by the dimension of the network (database dimension, SPF algorithm, length of protocol messages). For this reason OSPF allows the division of an AS in independent areas, each one is independent from the other in terms of routing information and topology (Figure 54). The Dijkstra algorithm is applied in each area and then through Area Border Router (ABR) routing tables are exchanged. 1999 EURESCOM Participants in Project P810-PF page 87 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 Figure 54: Sample of network division in OSPF areas Area Border Router (ABR) : AB2, AB4, BC1, BC3 Autonomous System Boundary Router (ASBR) : BB0, BB1 ASBRs are necessary to communicate local routing table to each others Autonomous Systems. 5.5.1.2 Exterior gateway protocol: routing between ASs EGP [123], Exterior Gateway Protocol, is based on the exchange of reachability information with the addition of mechanism of polling for the support of continuity check. The main limit is that it foresees a tree structure of the ASs and it does not allows loops. It is suitable for a structure based on the presence of core network with attached ASs, such as the one depicted in the following Figure 55: AS3 AS4 AS1 AS2 Core Network AS5 AS7 AS8 AS6 Figure 55: EGP network model for routing BGP [122]. The modern Internet is built from the meshed interconnection of backbones. EGP does not support this kind of topology, and IETF has had to develop another protocol: Border Gateway Protocol. BGP is a protocol for the routing between routers belonging to different ASs. BGP does not constrain the deployment architecture, because it enables loops prevention in complex topologies (Figure 56). BGP is more efficient than EGP, because after the initial exchange, the routers memorise the paths provided by their partners. This information will not be repeated, and the routers will send updates only for the paths that change (EGP exchanges every time the full routing table). page 88 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks AS2 AS7 AS3 AS1 AS6 AS4 AS5 Figure 56: BGP network model for routing 5.5.2 Cellular networks: OSPF and BGP as signalling transport network The RIP and EGP schemes normally don't fit with the traditional deployments of the cellular networks. BGP and OSPF [120] are more suitable for the replacement of SS7. Starting from a classical mobile signalling network deployment with four transit nodes (South 2 and North 2 are also gateway for international traffic towards other networks), it is showed by means of an example, the applicability of OSPF and BGP to support equivalent SS7 capabilities. Let start showing how OSPF and BGP could be used in this context [121]. The reference signalling architecture used in this example is shown in Figure 57. It is derived from a quite common deployment architecture use in first GSM years. HLR TR North1 TR South1 MSC/VLR North Area MSC/VLR South Area TR North2 TR South2 Figure 57: Signalling network reference architecture 5.5.2.1 Internal routing protocol OSPF The entire PLMN will be an AS on which OSPF runs. The use of OSPF allows multiple functions suitable to support equivalent SS#7 capabilities: Quick convergence: (M log M)OSPF (N*M)RIP 1999 EURESCOM Participants in Project P810-PF page 89 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 Multiple metrics. D(delay), T(throughput), R(reliability), C (Cost). See below how they can be used. Multiple paths. Are necessary to make load-sharing and achieve a fault-tolerance network. Large number of nodes (RIP max 15 hops). The AS can be divided in three OSPF areas (Figure 58): HLR OSPF AREA 1 ABR1 North1 ABR2 South1 OSPF AREA 2 MSC/VLR South Area MSC/VLR North Area ASBR1 North2 ASBR2 South2 OSPF AREA 0 BACKBONE Figure 58: OSPF Areas The subdivision into areas allows the reduction of the routing traffic and load; every area acts as an independent area from the routing point of view Faster OSPF algorithm Area Border Router (ABR): TR Autonomous System Boundary Router (ASBR): TR/North2, TR/South2 The basic point required to obtain equivalent routing functions to SS7 is to assign the metrics appropriately. In fact, signalling national traffic is routed using routes that are different from those which are used for international traffic. To satisfy this requirements, two different metrics are assigned to each link: R for national traffic, and C for international traffic (Figure 59, Figure 60). page 90 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks HLR 1(R ) ABR1 North1 (a1) 1(R ) 1(R ) MSC/VLR North Area 1(R ) ABR2 South1 1(R ) 1(R ) 3(R ) (a) 1(R ) 1(R ) MSC/VLR South Area 3(R ) ASBR1 North2 ASBR2 South2 1(R ) 1(R ) Figure 59: National traffic cost metric HLR 1(C ) ABR1 North1 2(C ) 1(C ) MSC/VLR North Area 1(C ) ABR2 South1 1(C ) 1(C ) MSC/VLR South Area 1(C ) (b) 1(C ) 2(C ) 2(C ) ASBR1 North2 1(C ) ASBR2 South2 2(C ) Figure 60: International traffic cost metric In this way two routing tables are computed, one for each metric. The metric that has to be applied to route a packet could be determined by the value of the ToS field in the IP header: to route national traffic ToS field of an IP packet will be set to R bit, and to C bit for international traffic. Please note however that such a use of the Type of Service header field does not comply with standard IETF specifications and is only used here as an example of what could be achieved with an IP routing protocol that enables to compute routing tables for different classes of traffic. The topic of such QoS-oriented routing protocols is a vast area out of the scope of the present document. Standard values of the ToS field are currently being specified as part of the Diffserv framework for QoS on IP networks. For instance, the entry for the North Area – ASBR2 South link in the pictures above, so that load-sharing and fault-tolerance are achieved, would look like: 1999 EURESCOM Participants in Project P810-PF page 91 (109) Principles and Solutions for IP based Mobile Networks From To MSC/VLR North ASBR2 South2 Cost R 2 Deliverable 4 Next Hop link (a) or link (a1) Cost C 1 Next Hop link (b) Table 1: Routing tables for metric R and C In this way national traffic is routed through (a) and (a1) links, whereas international traffic is routed through (b). Multiple choices for national traffic allow load-sharing and fault-tolerance. 5.5.2.2 Protocol BGP BGP is supposed to be deployed with ASBR1 and ASBR2. Each autonomous system transmits its routing table to the other PLMN (Figure 61). In this way each one knows the network that can be reached by the ASBR. Moreover the ASBR could not enable the neighbour ASBR to flood its routing information. It may depends on agreements between operators. P LM N 1 ASBR P LM N 3 ASBR ASBR ASBR B G P Border Gateway Protocol ASBR ASBR P LM N 2 Figure 61: BGP routeing relations 5.5.2.3 Address translation: DNS (Global Title translation and IP address mapping) The upper levels make use of SS7, E164 and E212 addresses, while the lower levels make use of IP addresses. This problem could be easily solved with a direct mapping of E164 and E212 addresses into IP addresses by means of DNSs interoperator interrogable, while the Signalling Point Code (SPC) could be mapped by means of an operator private DNS, this because SPC are valid locally only, instead E164 and E212 are valid at international level. This is the basic also to allow the address translation required for Global Title translations 5.5.3 Protocol mapping The following lists make a comparison of MTP2 , MTP3 and SCCP major functionality and about how they could be supported in an IP environment. Underlined functions are supported. MTP2 and MTP3 MTP 2 delimitation and alignment of the signal units page 92 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks error revealing error correction error rate control on the signalling links (provided by means of OSPF) MTP 3 Signalling messages Routing (automatically provided by IP routing) Discrimination. (automatically provided by IP routing) Distribution (SI Service Indicator), provided by means of TCP ports Signalling network management Signalling traffic management (provided by means of OSPF) Signalling paths management (provided by means of OSPF) Signalling links management (provided by means of OSPF) In general, some functions are not present in IP or are provided in different ways. Basically, IP and OSPF/BGP are capable to support the major set of MTP2 and MTP3 functionality. The other functions are provided by lower layers or are meaningless in an IP environment. SCCP SCCP provides four 4 classes of service class 0 - Basic connectionless class 1 - Sequenced connectionless class 2 - Basic connection oriented class 3 - Flow control connection-oriented class Generally, only class 0 and sometimes class 1 are used in the classical mobile networks, class 3 and 4 are more used by Intelligent Networks. It must be noted that the sequence control is based on the following principle, which is quite rough, as showed by the following SCCP primitive: N-UNITDATArequest/indication(Called Address, Calling Address, Sequenced Control, User Data) Sequenced Control = 0 => Class 0, SLS is incremented module n every service request Sequenced Control = 1 => Class 1, SLS is fixed for every called address Class 1 does not perform a real load sharing because all traffic from a source to a destination is send on the same links. This is necessary to deliver packet in sequence. OSPF allow a real load sharing based on traffic independently from the called address, and therefore automatically adjusted dynamically. This is possible because the class 4 protocols used are connection oriented and perform resequencing of packets. Basic functions for these classes are provided in an IP environment, but the need for the provision of an SCCP interface force to implement an adaptation layer. The basic processing for this adaptation layer is to map the SCCP primitives into the opportune calls to IP protocols. 1999 EURESCOM Participants in Project P810-PF page 93 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 Mapping for SCCP classes Three protocol stacks are implemented (Figure 62), two of which provide a connectionless interface (SCCP-SIM-CL) and the other one a connection oriented interface (SCCP-SIM-CO). TCAP TCAP TCAP SCCP-SIM-CL SCCP-SIM-CL SCCP-SIM-CO TCP T/TCP TCP IP IP IP ATM ATM ATM Figure 62: Alternative solutions and adaptation layers The connectionless interface could be implemented by using UDP protocols, but even if it is a connectionless protocol the services offered by SCCP connectionless interface are not so primitive as those of UDP. So the adaptation layer can be based on TCP or T/TCP and considering that the performance of T/TCP are extremely close to the one of UDP in terms of delay, it is suggested to use T/TCP which allow a common solution. It should be noted that the implementation of the mentioned layers is really quite simple (a little bit more complicated for the connection oriented service due to a more extensive instance mapping between the upper SCCP interface and T/TCP). 5.5.4 SS7 on IP? The most important consequence of the previous discussion is that the present IP protocols are perfectly suitable for the implementation of a signalling network equivalent to the SS#7 network in terms of functionality and performance. Condition for this implementation is the use of an IP network dedicated to the signalling (logically separated from the user plane traffic) and, in the case of re-use of the upper layer of SS7, an implementation of an adaptation layer to provide an SCCP interface is required. The use of dynamic routing protocols (as OSPF and BGP, which are really performant), in addition with reliable routers (such as the last generations of backbone ones) allow to provide a reliability in line with the telecommunication network standard requirements. Under that condition, the applicability of IP for the transport of the SS7 signalling application protocol is required. For completeness, it should be noted that another more complicated approach is presently under development in IETF (SIGTRAN). This approach foresees the development of more dedicated protocol adaptations and extensions. The above considerations allow to transport traditional telecommunication signalling over IP independently from the results of the works in IETF and the time when these results will be finalised. page 94 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 6 Principles and Solutions for IP based Mobile Networks Evolution of UMTS towards IP based solutions The study of the evolution of mobile networks, taking into account the more and more widespread IP technology and its immaturity in most of the relevant telecommunication fields (scalability, QoS, Mobility management…), has underlined the fact that, at the end of 1999, it is very difficult to anticipate the future mobile network architecture into details for the coming 3 to 10 years. As a consequence, in the next section we have chosen to sum up the evolution trends concerning the architecture of mobile networks considering the increasing role of the packet domain. The components of such a network are detailed in section 0. This conclusion should not be read as a solution for the evolution of mobile networks, but as some trends and components that are today envisaged. 6.1 Evolution scenarios Starting from current or very short term architecture, Figure 63 provides an overview of the network architecture able to offer IP services with mobile access. This can be realised through GSM/GPRS and corporate wireless LANs. PSTN Operator (Telco) IN SCP SS7 STP STP STP STP IN DB (SDF) STP Internet Service Provider Customer TX NAS TX Servers: DNS, WWW, email, Radius…. PSTN Corporate Network LAN backbone G-MSC Wireless LAN VLR BTS BSC MSC CSE GSM BSS HLR GPRS GSM Operator IP over WAN Servers GGSN SGSN LAN backbone Big ISPs Telcos Bandwidth resellers ... Figure 63: Current architecture for IP services and mobile access through GSM/GPRS and Wireless LAN In Figure 63, Figure 64 and Figure 65, Blue clouds represent packet networks, Straight lines represent circuit-switched connections. (in principle PSTN could also be included), Orange objects represent intelligence functions associated with PSTN or GSM communication networks (SS7, IN databases, HLR, CAMEL, …), 1999 EURESCOM Participants in Project P810-PF page 95 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 Blue objects represent IP entities (routers, servers, packet routing network, …), Green objects represent Mobile IP agents and modified routers for local mobility, Pink objects represent value-added services such as format translation/adaptation, and GPRS* refers to an evolved form of the currently envisioned GPRS towards UMTS functionality. Starting with GSM and GPRS-based core networks, the operators will have the possibility to improve their service offering. Furthermore, UMTS will give them enlarged radio spectrum and increased capacity, so as to meet growing customer demand, with which current saturated GSM networks cannot cope efficiently, as well as support the novel high-bandwidth services provided by the evolving core networks. Allowing mobility and higher bit rates, UMTS stays in line with GSM and GPRS as it will use GSM/GPRS enhanced databases and enhanced core network equipment (MSC, SGSN and GGSN). Allowing mobility and higher bit rates, UMTS Release 99 stays in line with GSM and GPRS as it will use GSM/GPRS enhanced databases and enhanced core network equipment (MSC, SGSN and GGSN). Figure 64 introduces the UMTS access network (UTRAN) which will be linked through RNC to the circuit switched domain (MSC) and to the packet switched domain (SGSN). Two different SGSN are shown in order to highlight that an operator may choose either to upgrade its 2G equipment or to introduce 3G equipment (differentiated with * symbol). At the bottom of this figure, a Wireless LAN access has been introduced, which corresponds for example to the Broadband Radio Access Network technology. This access could be supported by UMTS core network equipment. During the same period of time, some fixed network technologies will emerge with Voice over IP gateways, gatekeeper and signalling gateways so that an IP telephony node can 'talk' to PSTN and SS7 nodes, with security servers, with IP mobility servers, PSTN Operator (Telco) IN SCP SS7 STP STP STP STP IN DB (SDF) STP Internet Service Provider Customer TX TX NAS Signalling Gateway Call Agent or H.323 gatekeeper SIP proxy, Dynamic DNS, Diameter …. WWW, email …. PSTN IP backbone HA/FA PIG or Media Gateway VLR BTS BSC MSC CSE HLR GSM Operator GPRS UMTS Operator Base Wireless LAN Station cells Routers HA/FA G-MSC GSM BSS Profiles DB IP over WAN Servers GGSN SGSN IP backbone Node B UMTS CN = GPRS* RNC UTRAN SGSN* GGSN* Big ISPs Telcos Bandwidth resellers ... Wireless LANs BRAN Figure 64: Evolved Architecture with the introduction of UMTS and new IP fixed network technologies page 96 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks Central to the operation of mobile networks are the functions of mobility management that enable the correct establishment of communications to/from users. Mobility management functions cross many 'layers' of a wireless network: radio access, security, quality of service management, usage policing, data routing, … Today's network evolution let us make a guess at a possible future converged architecture incorporating the functions of both a mobile operator and an ISP. Figure 65 provides a conceptual overview of a possible future network architecture in few years, taking into account the trends we have identified. The next paragraphs expand on the assumed technological steps. Operator’s Server Farm (may be mirrored at various locations) Signalling IN SCP Gateway SS7 PSTN HLR CSE WAP Server SIP proxy, Dynamic Call Agent DNS, Diameter, Transcoding or H.323 HA/FA Text-to-Speech... WWW, email... gatekeeper STP Profiles DB: •policies (Security, QoS…) •subscriber profiles •billing records NAS BTS Media Gateway BSC GSM BSS Operator’s IP backbone SGSN Node B Node B supports •QoS for rt services •multicast •AAA RNC provides •Fixed IP •VoIP •GPRS •UMTS=GPRS* GGSN IP WAN UTRAN IGSN Border Router + Firewall Wireless LAN cells Wireless LAN cells Figure 65: Converged architecture merging the functions of ISP and mobile operator Such possible network architecture evolves from current IP networks formed by routers interconnected by any transmission technologies. Core nodes support mechanisms providing grades of quality of service (e.g. using diffserv), confidentiality of information transfers (e.g. using IPSec) and efficient support for reliable unicast and multicast packet communications between any set of edge routers (dynamic routing protocols: OSPF, EGP). Edge routers enable access to/from any combination of Layer 2 technologies, be it dial-up from connection-oriented legacy networks (PSTN, ISDN, GSM…), direct connectionless access from legacy infrastructure (LANs) or newer technologies (ADSL, GPRS, UTRAN, Wireless LANs, BRAN/Hiperlan 2, broadcast networks: DAB, satellite…). Edge routers may incorporate transcoding devices to fit the specific Layer 2 data format into IP packets (e.g. modems at a NAS or a Media Gateway). Traffic measurement capabilities for individual user 'flows' may be incorporated at edge nodes to police usage. 1999 EURESCOM Participants in Project P810-PF page 97 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 Mobility Management is implemented at the network layer, so that future IP-based mobility procedures can take advantage of other network-layer facilities such as multicast, QoS guarantees support, security, … Mobile IP provides a user ID to network address translation capability that enables global roaming. Its Home Agents / Foreign Agents can be viewed as ‘tunnel servers’ that encapsulate and despatch datagrams to roaming users. With the high-density of highly-mobile users that will characterise future high-speed pico-cellular networks, Mobile IP needs however to be complemented by more distributed mechanisms providing real-time mobility across a network domain, such as GSM or UMTS in wide-area cellular networks, or the emerging IP micro-mobility schemes for 'Fourth Generation (4G)' high-speed picocellular networks. Functions above the network layer are typically implemented in servers, whose physical location is arbitrary and can be distributed in server 'farms' using distributed computing technologies such as DCOM, CORBA, … or client-proxy(ies)-server protocols that can provide the required location transparency. Such distribution of network functionalities using IT will enable to meet customer demand in a scalable fashion. Servers provide the network 'intelligence' and application-specific functionality: 6.2 Interworking with voice networks: SS7 nodes can be upgraded with IP interfaces so that they can 'talk' to signalling gateways and call control servers (SIP Proxies or H.323 Gatekeepers) IN interworking: IP interconnection between SS7 'routers' (STPs) or IN SCPs (or CAMEL service nodes) and VoIP call control servers allows to share common subscriber information in databases and to provide legacy services extension of IN interworking: e.g. to provide IP-based UPT (personal mobility) through a combination of name resolution servers such as DNS or LDAP, and call-control servers (SIP, H.323) Service interaction: web servers provide a front-end to subscriber and policy databases so that users can change their service profile in a user-friendly manner Content dynamic adaptation/filtering: because multiple access technologies with different transfer capabilities coexist, there is a need to provide 'on-the-fly' content adaptation. Interaction may be needed with subscriber policy stores to check QoS requirements, formatting preferences, terminal capabilities… This can be today achieved by e.g. WAP servers or web proxies that dynamically strip out graphics, compress media streams… Legacy internet services: email, web, media streaming on demand… Key networks components and features As seen in the previous section, this network evolution focused on a core network architecture based on IP. It assumed IP to act as the ‘glue’ to provide global connectivity, mobility between networks, and a common platform for service provisioning for different types of access networks. For their importance in the near to medium term evolution of global mobile telecommunications, three types of access networks have been selected as representative: GSM/GPRS, UMTS, and wireless LANs. GSM GPRS represents the convergence between the worlds of mobile networks and packet data networks. Main applications will be messaging (e.g. SMS) and bursty data page 98 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks up to approximately 150kb/s. Field trials will take place in 1999 and deployment is expected to start in 2000. GPRS shares resources with the existing GSM circuit-switched network, but also requires modifications and heavy investments to the network architecture: implementation of a new type of service nodes and physical link connections to all involved BSCs, software modifications to the access segment and to the HLR and related databases. It will enable traffic-volume-based charging to mobile data applications. Additionally it puts the mobile network operator into the role of an Internet Service Provider. As an ISP the operator offers additional services like DNS registration, Email and Web-hosting, and as a transport resource provider he offers an access service to other ISP's subscribers or corporate clients. Although GPRS stage 2 offers multiple QoS classes (delay and packet loss constraints), it does not offer real-time services, since the required QoS classes are not defined as well as the mechanism to support them. Wireless LANs could form a complement to third generation mobile systems for high bandwidth connectivity in the range of 10 Mbit/s and above. WLANs usually operate in the rural or business environment with comparably small area coverage and, opposing to GSM/UMTS, are usually unmanaged or operated on a corporate basis. Emerging standards like HIPERLAN and IEEE 802.11 currently cover physical layer and DLC layer aspects only. Communication between access points, which is essential for implementing local mobility schemes, is not covered by the standards and is left to the distribution system, i.e. the WLAN backbone segment. As a complement to 3G mobile systems, WLANs could need a common or at least interoperable scheme for mobility management. Local mobility in WLANs currently is provided by proprietary roaming schemes or by the upcoming Inter-Access Point Protocol (IAPP). To interoperate with an IP-based core network, without falling back to a Mobile IP solution that would introduce an unwanted amount of transport overhead and server requirements to the local area, several approaches for ‘layer 3 micromobility’ have been made. These are covered by the term ‘cellular-IP’ and are based on IP multicast or new protocols (such as HAWAII, Cellular IP or MANET…). Such micro-mobility schemes create dynamic 'tree' topologies using per-host forwarding entries (as opposed to standard aggregatable IP routes) to connect mobile hosts to a 'standard' IP core networks via 'stub' IP access networks made up of mobileaware routers. Global roaming between different types of mobile networks, such as UMTS and Wireless LAN, is assumed to be provided by Mobile IP based on IPv4 or IPv6 in this book. Since GPRS is a standard specifically conceived for mobile networks, integration with fixed IP network and Mobile IP is not seamless on the first hand. Thus, this book reviews some proposals on Mobile IP and GPRS integration based on modifications to the GPRS support nodes. Whereas GPRS handles the micro-mobility, Mobile IP handles the macro-mobility in order to provide seamless global roaming between networks. These proposals integrate SGSN and GGSN into a single Internet-GSN logically belonging to the access network and allow the mobile terminal to implement Mobile IP. For backward compatibility, control procedures are inherited from GPRS. This is seen as a possible evolution path to support Mobile IP in the UMTS core network. 1999 EURESCOM Participants in Project P810-PF page 99 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 Both SS7-based mobile networks and IP networks provide functions to handle Mobility Management (MM). The two main procedures covered by MM are Registration and Location tracking/updating. Both of these procedures must include a user authentication phase. Solutions that attempt to integrate the way these functions are performed across SS7/connection-oriented and IP networks incorporate the SS7 procedures and entities (such as MAP and the HLR) with emerging network (and application) level frameworks for IP networks such as Roaming (roamops), AAA or Mobile IP. The addition of a session control 'layer' mediating between the network mobility mechanisms and the AAA infrastructure would enable personal mobility and alleviate some of the limitations of Mobile IP. Such a session control mechanism could be SIP. All these mechanisms require 'policy'/user profiles databases that could be integrated with the HLR/AuC using IT such as DCOM, CORBA… A special topic covers mobile terminal registration in the IP/GPRS/UMTS context. Two different ways of performing registration, distinctively consisting of the authentication and location registration, in a UMTS/Mobile IP world are presented. These proposals assume a network composed of the access network with UTRAN technology and a core network built on both UMTS and Mobile IP Mobility Management. The node between access network and core network is an IGSN able to interrogate the HLR and coupled with the Mobile IP Foreign Agent. These two procedures could be considered as the key elements for building up the new registration process with ‘classical’ mobile networks and Mobile IP. Preference towards one approach or the other may strongly depend on the kind of evolution from UMTS initial release to future versions the operators would envisage. Open issues are: how to solve the trade-off problem between radio resource optimisation and infrastructure separation of IP and UTRAN given the demand for a smooth and realistic evolution, the exact layout of information to store in the HLR for Mobile IP authentication support, and the frequency of different authentication procedures (especially Mobile IP authentication). Besides mobility support, and since UMTS networks will provide real-time services, the interconnection of different types of access networks using an IP-based core network requests IP to be able to provide reliable real-time services too. Integrated services provide best-effort, predictive or guaranteed QoS (controlled-load and guaranteed services) based on resource reservation using RSVP signalling for bandwidth allocation and packet scheduling at every network hop. However, the computing overhead at each hop is really a big matter and prevents from implementing RSVP as a general technique: it must be avoided in large scale networks, but it is so far the only way to guarantee time delays and to leave in the same time all the unused capacity to lower quality services. Differentiated services enable scalable service discrimination based on the Type of Service field in the IPv4 header and respectively the Traffic Class field in the IPv6 header without the need for a per-flow state and signalling at every hop. Additional problems arise if IP real-time services are to be supported in conjunction with terminal mobility. When a terminal moves, the communication path and nodes involved in the path usually will change too, e.g. when roaming between different access networks (WLAN–UMTS, GSM-UMTS, ...), where a re-establishment of page 100 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks Mobile IP tunnels take place. Consequently, integrated as well as differentiated services computation has to be performed again. Concerning service provisioning, an IP-based network architecture could open up the opportunity for bringing a broad range of new services from an existing infrastructure to mobile users. However, this would require the adaptation of service capabilities and content to the restricted capabilities of portable terminals (in terms of computing power, output and input capabilities (e.g. screen size & colors, audio codecs, small keypads, voice activation features…). For this purpose WAP defines a suite of wireless protocols optimised for the mobile environment and able to work across different wireless (mainly datagram) network technologies. Hand-held terminals need to provide a micro-browser that uses protocols and languages inherited from HTTP and HTML. A gateway functionality converts protocols, languages and content to enable access to WAP servers, or more generally to all Web servers in the Internet world. However, WAP can only be seen as a medium-term 'fix' that will need to evolve so that service provision is unified across both fixed and mobile IP networks. This evolution must incorporate more and more standard IP-compliant procedures in the very wireless-carrier-specific WAP protocols. In order to merge the features and services of data networks with those of voice networks, a Wireless Telephony Application framework has been introduced. WTA is a tool for building telephony applications, designed for network operators and equipment vendors. It enables real-time processing of telephony events to the end-user while browsing. Additional integration with the telephony network is for further consideration. Future mobile terminals or WLAN multi-mode terminals might support packet based access only and might rely on access network services and facilities to interoperate with circuit-switched networks. Thus, there might be a certain demand for IP call control and media transcoding at the end-system and in the network in order to provide telephony applications to packet based mobile terminals for instance. Originally introduced to support call control for IP telephony and to address interworking issues with connection oriented networks as PSTN and (B-)ISDN, IP call control now evolves along two different paths: H.323 (ITU) and SIP (IETF). Initially not designed for interworking, both of them might share single components like signalling gateways or media stream gateways to a certain degree. Both of them provide a set of functions for name translation, lookup, routeing, logging, access control and firewalling. An IP-based architecture might also be used as a common (integrated) platform for service provisioning to different types of access networks and end-systems. This allows for a unified service presentation and user interaction for example by WML based Web access, as well as the support of user profiles which will be adapted to the situation of the user (location, end-system in use, subscription, preferences, …). In this context, one way to provide the UMTS Virtual Home Environment could be based on Intelligent Network services. The main challenges will be to provide access to IN services for IP based clients, and to provide an interface between IP based server belonging to third party providers and the VHE service logic. On the client side, access to the service logic requires a signalling gateway that has to reflect the characteristics of an end-system to the service switch (or MSC) for an IP based client. This can be provided to both H.323 and SIP clients. Thus access to IN services and IP servers is achieved separately and it is up to the user application to present both in an integrated view. 1999 EURESCOM Participants in Project P810-PF page 101 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 In the CAMEL Service Environment, a Third Party Service Provider gains access to the service switching function through a managed interface. IP based servers allow to present access to the same service by either using IP access through a web page and IN access through the service control function interface. Additionally an IP based server farm might provide a higher degree of scalability. Providing services to the CSE based on IP servers requires interworking with the service logic. This mainly seems to be a problem of tunnelling TCAP respectively SCCP messages through IP which is not only a matter of protocol message encapsulation but also demands for assured transfer, in sequence delivery and low delay transport to be provided by the IP segment in order to avoid an unacceptable increase in service activation delay. It has also impact on security and requires authentication, authorisation and encryption of messages to avoid obstruction of the SSF. On the operators side, the support of IP server based service provisioning requires the implementation of an IP-enabled SSF. In an IP based scenario, operators service creation (and management) might be performed in the conventional way using the appropriate service creation environment. VHE service customising and service profile creation (and management) can be performed by the operator or mobile user, for example via a web interface to the VHE server. page 102 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks References [1] CSELT, “Tecniche di trasporto per sistemi mobili di terza generazione”, Internal Report 1997 [2] DTR/SMG-0323XXU Draft Technical Report, “Combined GSM and Mobile IP Mobility Handling in UMTS IP CN”, version 0.3.0, 14/01/1999 [3] GSM 02.60 Technical Specification “Digital Cellular Telecommunications System (Phase 2+); General Packet Radio Service (GPRS); Service Description; Stage 1”, version 6.1.0, Release 1997 [4] GSM 03.60 Technical Specification “Digital Cellular Telecommunication System (Phase2+); General Packet Radio Service (GPRS); Service Description; Stage 2”, version 6.1.1, Release 1997 [5] GSM 03.64 Technical Specification, “Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Overall description of the GPRS radio interface; Stage 2”, version 6.0.1, Release 1997 [6] Nokia Magazine Papers, “Packet Radio Service for the GSM Network”, 1997, URL: http://www.forum.nokia.com/nf/magazine/papers [7] C. Perkins, ed., "IP Mobility Support", IETF RFC 2002, Oct. 1996 [8] C. Perkins, "IP Encapsulation Within IP", IETF RFC 2003, May 1996 [9] J. Postel, “Internet Control Message Protocol”, IETF RFC 792, 1981 [10] S.E. Deering, ed., "ICMP Router Discovery Messages", IETF RFC 1256, Sept. 1991 [11] S. Hanks, T. Li, D. Farinacci and P. Traina, "Generic Record Encapsulation (GRE)", IETF RFC 1701, October 1994 [12] C. Perkins, "Minimal Encapsulation Within IP", IETF RFC 2004, Oct. 1996 [13] S. Thomson and T. Narten, "IPv6 Stateless Address Auto-configuration", IETF RFC 2462, December 1998 [14] T. Narten, E. Nordmark, and W. Simpson, "Neighbour Discovery for IP Version 6 (IPv6)", IETF RFC 2461, December 1998 [15] B. Aboba, “Support for Mobile IP in RADIUS”, Work in Progress (draft-ietfradius-mobileip-00), April 1998 [16] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997 [17] Pat R. Calhoun, Charles E. Perkins, “Mobile IP Network Access Identifier Extension”, Work in Progress (draft-ietf-mobileip-mn-nai-03), June 1999 [18] Charles E. Perkins, Pat R. Calhoun, “Mobile IP Challenge/Response Extensions”, Work in Progress (draft-ietf-mobileip-challenge-02), May 1999 [19] B. Aboba, G. Zorn, “Criteria for Evaluating Roaming Protocols”, IETF RFC 2477, January 1999. [20] J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, M. Holdrege, D. Spence, “AAA Authorization Architecture and Requirements”, Work in Progress (draft-ietf-aaa-authorization-reqs-00), June 1999. 1999 EURESCOM Participants in Project P810-PF page 103 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 [21] I. Castineyra, J. Chiappa, and M. Steenstrup, "The Nimrod Routeing Architecture", IETF RFC 1992, Aug. 1996 [22] M. Crawford, "Router Renumbering for IPv6", Work in Progress (draft-ietfipngwg-router-renum-08.txt), February 1999 [23] D. B. Johnson, C. Perkins, "Mobility Support in IPv6", Work in Progress (draftietf-mobileip-ipv6-07.txt), November 1998 [24] A. Conta and S. Deering, "Generic Packet Tunnelling in IPv6 specification", IETF RFC 2473, December 1998 [25] B. Aboba, G. Zorn, “Criteria for Evaluating Roaming Protocols”, IETF RFC 2477, January 1999 [26] C. Perkins and D. B. Johnson, "Route Optimisation in Mobile IP", Work in Progress (draft-ietf-mobileip-optim-08), 25 February 1999 [27] Pat Calhoun, Gabriel Montenegro, Charles Perkins, “Tunnel Establishment Protocol”, Work in Progress (draft-ietf-mobileip-calhoun-tep-01), March 1998. [28] M. Crawford et al., “Separating Identifiers and Locators in Addresses: An Analysis of the GSE proposal for IPv6”, Work in Progress (draft-ietf-ipngwgesd-analysis-04), February 1999 [29] C. Perkins and P. Bhagwat, "A Mobile Networking System Based on Internet Protocol (IP)", Proc. USENIX Symposium on Mobile and LocationIndependent Computing, Aug. 1993, USENIX Assoc., pp. 69-82 [30] D.B. Johnson, "Scalable and Robust Internetwork Routeing for Mobile Hosts", Proc. 14th Intl. Conf. Distributed Computing Systems, June 1994, pp. 2-11 [31] V. Gupta and S. Glass, "Firewall Traversal for Mobile IP: Guidelines for Firewalls and Mobile IP Entities", draft-ietf-mobileip-firewall-trav-00 (expired), Mar. 1997 [32] J. Zao et al., "A Public-Key Based Secure Mobile IP," Proc. ACM Mobicom 97, ACM, New York, Oct. 1997, pp. 173-184 [33] P. Ferguson and D. Senie, "Ingress Filtering in the Internet", Work in Progress (draft-ferguson-ingress-filtering), Oct. 1997 [34] G. Montenegro, “Reverse Tunnelling for Mobile IP”, RFC 2344, May 1998 [35] C. Bormann, "Providing integrated services over low bit rate links", Work in Progress (draft-ietf-issll-isslow-04), August 1998 [36] V. Jacobson, "Compressing TCP/IP headers", IETF RFC 1144, February 1990 [37] M. Degermark, B. Nordgren, S. Pink, "IP Header Compression", IETF RFC 2507, February 1999 [38] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", Work in Progress (draft-ietf-avt-crtp-04.txt), November 1997 [39] M. Engan, S. Casner, C. Bormann, "IP Header Compression over PPP", Work in Progress (draft-engan-ip-compress-02.txt), December 1997 [40] C. Becker, B. Patil, E. Qaddoura, “IP Mobility Architecture Framework”, (draft-ietf-mobileip-ipm-arch-00.txt), September 1999 [41] B. Aboba, M. Beadles, "The Network Access Identifier" RFC 2486, January 1999 page 104 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks [42] P. Calhoun, C. Perkins, "Mobile IP Dynamic Home Address Allocation Extension", draft-ietf-mobileip-home-addr-alloc-00.txt, November 1998 [43] P. Calhoun, C. Perkins, “Diameter Mobile IP Extensions”, Work in Progress, IETF draft, , Sun Laboratories, November 1998 [44] Tom Hiller, Lucent Technologies, Charles Lo, Airtouch Communication, “3G Wireless Data Provider Architecture Using Mobile IP and AAA”, Work in Progress, IETF draft, March 1999 [45] Pat R. Calhoun, Gabriel Montenegro, Charles E. Perkins, “Mobile IP Regionalized Tunnel Management”, Work in Progress, (draft-ietf-mobileip-regtunnel-00), November 1998. [46] “Diameter Mobile IP Extensions”, IETF draft, work in progress, P. Calhoun, C. Perkins, Sun Laboratories, November 1998 [47] Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification, IETF RFC 2205, September 1997 [48] A Framework for Use of RSVP with Diffserv Networks, Work in Progress (draft-ietf-diffserv-rsvp-01.txt), November 1999 [49] M.Handley, H.Schulzrinne, E.Schuler, J.Rosenberg, "SIP: Session Initiation Protocol", IETF RFC 2543, March 1999 [50] Schulzrinne, Rosenberg, "SIP Call Control Services", Work in Progress (draftietf-mmusic-sip-cc-00.txt), August 1998 [51] W. Marshall et al., "Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP-based Distributed Call Control Mechanisms", Work in Progress (draft-dcsgroup-mmusic-arch-00), June 1999. [52] Greene et. al., "SS7-Internet Interworking - Architectural Framework", Work in Progress (draft-greene-ss7-arch-frame-00.txt), July 1998 [53] S. Donovan, M. Cannon, "A Functional Description of a SIP-PSTN Gateway", IETF (draft-donovan-sip-gw-client-00.txt), November 1998 [54] ITU-T, "ITU-T Recommendation H.323: communications systems", February 1998 Packet-based multimedia [55] ITU-T, "ITU-T Recommendation H.245: Control protocol for multimedia communication", February 1998 [56] ITU-T, "ITU-T Recommendation Q.931: ISDN user-network interface layer 3 specification for basic call control", May 1998 [57] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", IETF RFC 1889, January 1996 [58] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol (RTSP)", IETF RFC 2326, April 1998 [59] M. P. Maher, C. Perkins, "Session Announcement Protocol: Version 2", Work in Progress (draft-ietf-mmusic-sap-v2-00.txt), November 1998 [60] M. Handley, V. Jacobson, "SDP: Session Description Protocol", IETF RFC 2327, April 1998 [61] ITU-T, "ITU-T Recommendation H.225.0: Call signalling protocols and media stream packetization for packet based", February 1998 1999 EURESCOM Participants in Project P810-PF page 105 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 [62] ITU-T, "ITU-T Recommendation H.450.1: Generic functional protocol for the support of supplementary services in H.323", February 1998 [63] ITU-T, "ITU-T Recommendation H.450.2: Call transfer supplementary service for H.323", February 1998 [64] ITU-T, "ITU-T Recommendation H.450.3: Call diversion supplementary service for H.323", February 1998 [65] ITU-T, "ITU-T Draft Recommendation H.332: H.323 extended for looselycoupled conferences" [66] GSM 03.78 TS "Digital cellular telecommunications system (Phase 2+); Customised Applications for Mobile network Enhanced Logic (CAMEL); Stage 2", version 5.3.2, November 1997 [67] GSM 02.78 TS, "Digital cellular telecommunications system (Phase 2+); Customised Applications for Mobile network Enhanced Logic (CAMEL); Service definition, Stage 1", version 5.4.0, January 1998 [68] ETSI, "Draft EN 301 152-1: Intelligent Network (IN); IN Capability Set 1 (CS1) extension; Intelligent Network Application Protocol (INAP); Customised Applications for Mobile network Enhanced Logic (CAMEL); Part 1: Protocol specification", January 1998 [69] GSM 09.78, TS "Digital cellular telecommunications system (Phase 2+); Customised Applications for Mobile network Enhanced Logic (CAMEL); CAMEL Application Part (CAP) specification", version 5.3.0, January 1998 [70] GSM 09.02 ,TS, "Draft EN 300 974: Digital cellular telecommunications system (Phase 2+); Mobile Application Part (MAP) specification", version 6.1.0 Release 1997, July 1998 [71] P. R. Calhoun, G. Zorn, P. Pan, "DIAMETER Framework Document", Work in Progress, (draft-calhoun-diameter-framework-02.txt), December 1998 [72] W. Bressler, "SS7 Level Two over IP", Work in Progress (draft-bresslersigtran-ipss7l2-00.txt), January 1999 [73] L. Coene, "Internet and SS7 addressing", (draft-coene-ss7-IP-addr-00.txt), January 1999 [74] N. Glaude, T. Blain, R. Cable, "SS7 to IP Signalling Gateway Transport Architecture", (draft-glaude-ss7-gw-00.txt), November 1998 [75] IEEE "Wireless LAN Medium Access Control and Physical Layer Specifications", IEEE Std 802.11-1997, November 1997 [76] A. Claessen, L. Monteban and H. Moelard (AT&T GIS), “The AT&T GIS Wavelan air interface and protocol stack”, Proc. of Wireless Networks ‘Catching the mobile future’, 18-23 Sept. 1994, IOS Press, pp. 1442-6 vol.4 [77] H. Moelard (Lucent), M. Trompower (Aironet), “Inter Access Point Protocol Wireless Networking Distribution System Communication”, Work in Progress (draft-trompower-iapp-00), March 1998 [78] C. Castellucia, “A hierarchical Mobile IPv6 proposal”, INRIA technical report TR-0226, November 1998 [79] C. Perkins, "Mobile IP Local Registration with Hierarchical Foreign Agents", Work in Progress (draft-perkins-mobileip-hierfa-00), February 1996 page 106 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks [80] R. Caceres and V. N. Padmanabhan, "Fast and scalable handoffs for wireless internetworks", Proc. of ACM MobiCom '96, November 1996 [81] D. Waitzman, C. Partridge, S.E. Deering, “Distance Vector Multicast Routeing Protocol (DVMRP)”, IETF RFC 1075, November 1988 [82] J. Moy, “Multicast Extensions to OSPF (MOSPF)”, IETF RFC 1584, March 1994. [83] Stephen Deering (Cisco) et al., “Protocol Independent Multicast Version 2 Dense Mode Specification”, Work in Progress (draft-ietf-pim-v2-dm-03.txt), June 1999 [84] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, “Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification”, IETF RFC 2362, June 1998 [85] A. Ballardie, “Core Based Trees (CBT) Multicast Routeing Architecture”, IETF RFC 2201, September 1997 [86] A. Ballardie, “Core Based Trees (CBT version 2) Multicast Routeing – Protocol Specification”, IETF RFC 2189, September 1997 [87] A. Acampora, “An architecture and methodology for mobile-executed handoff in cellular ATM networks”, IEEE JSAC, vol. 12 no. 8, Oct. 1994, pp. 1365-75 [88] S. Seshan, H. Balakrishnan, R. H. Katz, “Handoff in Cellular Wireless Networks: the Daedalus Implementation and experience”, ACM/Baltzer Journal on Wireless Networks, 1995 [89] A. Mihailovic, M. Shabeer, H. Aghvami, “Sparse mode multicast as a mobility solution for internet campus networks”, paper submitted to PIMRC’99 [90] R. Ramjee, T. La Porta, S. Thuel and K. Varadhan, “IP micro-mobility support using HAWAII”, Work in Progress (draft-ramjee-micro-mobility-hawaii-00), February 1999. [91] A. Valko (Ericsson/CU), A. Campbell, J. Gomez, “Cellular IP”, Work in Progress (draft-valko-cellularip-00), November 1998 [92] C. Castellucia, “Towards a Unified Hierarchical Mobility Management Framework”, Work in Progress (draft-castellucia-uhmm-framework-00), June 1999 [93] Ericsson, "H.323 Roaming Scenarios in UMTS", 3GPP temporary document S2-361, May 1999 [94] Ericsson, Nokia et. al., "Call Control and Session Management for Multimedia Services", 3GPP temporary document S2-99191, April 1999 [95] ETSI, "Evolution of the GSM platform towards UMTS; UMTS 23.20 version 1.6.1", 3GPP DTR/SMG-032320U V.1.6.1 July 1999 [96] EURESCOM P919, Services",June 1999 "PIR 2.1: Identified Integrated Fixed/Mobile [97] 3GPP TS 22.121 "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Service Aspects; The Virtual Home Environment", version 3.0.0, June 1999 1999 EURESCOM Participants in Project P810-PF page 107 (109) Principles and Solutions for IP based Mobile Networks Deliverable 4 [98] 3GPP TS 23.078, "3rd Generation Partnership Project; Technical Specification Group Core Network; Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 2 - Stage 2", version 3.0.0, May 1999 [99] ITU-T, "Draft Recommendation Q.1231; Introduction to Intelligent Network Capability Set-3.1", May1998 [100] GSM 02.57 "Digital cellular telecommunications system (Phase 2+); Mobile Station Application Execution Environment (MExE); Service Description; Stage 1", version 7.0.0, Release 1998, March 1998 [101] GSM 03.57, "Digital cellular telecommunications system (Phase 2+); Mobile Station Application Execution Environment (MExE); Functional Description; Stage 2", version 1.7.1, April 1999 [102] GSM 11.14 "Digital cellular telecommunications system (Phase 2+); Specification of the SIM application toolkit for the Subscriber Identity Module Mobile Equipment (SIM - ME) interface ", version 5.9.0, Release 1996, November 1998 [103] 3GPP TS 22.101 "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects Service aspects; Service principles", version 3.6.0, June 1999 [104] ITU-T, "Recommendation Q.1701; Framework for IMT-2000 Networks", June 1998 [105] ITU-T, "Draft New Recommendation Q.1711, Network Functional Model for IMT-2000", June 1998 [106] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1l", IETF RFC 2068, January 1997 [107] WAP Forum, "Wireless Session Protocol Specification", WAP Forum, April 1998, URL: http://www.wapforum.org/what/technical.htm [108] W3C, "CC/PP exchange protocol based on HTTP Extension Framework", W3C Note 24 June 1999, URL: http://www.w3.org/TR/NOTE-CCPPexchange [109] W3C, "Composite Capability/Preference Profiles (CC/PP): A user side framework for content negotiation", W3C NOTE 30 November 1998, URL: http://www.w3.org/TR/NOTE-CCPP/ [110] URL: http://www.wapforum.org/what/docs/WAP-W3C-white-paper_v1.2.html [111] M.C.Chan, T.Y.C.Woo, "Next-Generation Wireless Data Services: Architecture and Experience", IEEE Personal Communications, February 1999 [112] ITU-T, "ITU-T Recommendation Q.761 - Signalling System No. 7 - ISDN User Part functional description", September 1997 [113] P.Lettieri, M.B.Srivastava, "Advances in Wireless Terminals", IEEE Personal Communications, February 1999 [114] EURESCOM P810, T4, PIR4.2 "IP architecture scenario", 1999 [115] G. Melkin, “RIP version 2”, IETF RFC1388 [116] P. Mockapetris, "Domain Names - concepts and facilities", IETF RFC 1034, November 1987. [117] J. Moy, “OSPF version 2”, IETF RFC1583 page 108 (109) 1999 EURESCOM Participants in Project P810-PF Deliverable 4 Principles and Solutions for IP based Mobile Networks [118] P. Vixie, editor, "Dynamic Updates in the Domain Name System (DNS UPDATE)", IETF RFC 2136, April 1997. [119] Droms, R., "Dynamic Host Configuration Protocol", IETF RFC 2131, March 1997. [120] K. Varadan, “BGP/OSPF interaction”, IETF RFC1043 [121] A. Artale, “Migrazione della segnalazione dei sistemi radiomobili di seconda e terza generazione su IP”, CSELT/University of PISA, July 1999 [122] K. Loughld, Cisco Systems, “Border Gateway Protocol”, IETF RFC1267 [123] E. C. Rosen, “Exterior Gateway Protocol”, IETF RFC888 [124] 3GPP R2000 Adhoc-group, “Architecture for an All IP network”, draft 0.1.4, September 1999 1999 EURESCOM Participants in Project P810-PF page 109 (109)
