Voice over IP in the context of 3G mobile communications
6 Selecting the NGN target for future development
6.1 General
The interconnection scenarios, shown in Figure 5, clearly indicate that there are some challenges related to the evolution towards a harmonised NGN. The cur-rent situation is characterised by a plethora of multi-media platforms (e.g. for VoIP production), and no common target for architectural development. This is as seen resulting in fragmentation and the need for extensive interworking. The consequence of this lack of technical harmonization is loss of advantage of scale, reduced value of new multimedia services caused by lack of ubiquity, and high complexity in networks and their operation.
Previously the International Telecommunications Union (ITU) was able to manage the required specifi-cation and harmonisation work to allow nations and operators to maintain the desired interoperability.
However, today there is no such strong coordination, and much of the development is left to completely obey the laws of commercial competition. This is good in many respects, but without a common archi-tecture setting the direction of development, and ensuring service interoperability and ubiquity, the users of telecommunication services and the opera-tors will mainly suffer because of limitations in ser-vice availability, in quality, in traffic volume, and in incurred costs of service production.
6.2 Generic core architecture
Figure 8 sketches the top level of a proposed NGN service architecture that could benefit both operators and their subscribers. This architecture may be adopted to ensure both service ubiquity and network harmonisation.
The only interworking shown explicitly is towards PSTN / ISDN (1) service network, described in the
“IMS VoIP interworking with PSTN/ISDN/CS domain” section, and towards the H.323 domain of the Internet (2) [17], [18]. All other interworking is implicit in the Figure 8, and characterised by all being against the common core effectively eliminat-ing the need for the N square interworkeliminat-ing arrange-ments for N different technologies (e.g. service net-works).
The Application Server (AS) (Figure 8) is attached to the common core. Thereby being capable of supply-ing ubiquitous access independent services in the core representation. These services will be interworked with the service representations at the existing service specific networks at the edge of the common core.
There will be ample room for competition within the framework despite the harmonised core that will effectively set the direction of evolution. Vendors can gain from increase in scale in core technologies.
The number of different network elements will be reduced, and the competitive arena will move in the direction of new services, maintaining bridging of new and existing technologies.
The challenge is to agree on the core technologies.
This is because of the huge invested interest in the different existing technologies allowing little room for selecting one as the core and basis for future development. The principal candidate technologies are the 3G cellular technologies and the IETF defined Internet technology. A good solution would probably be to select the best of breed from these candidates and to agree the following key characteristics and solutions for the new core architecture:
• Multimedia service architecture (e.g. SIP)
• Mobility management scheme for global (macro) mobility
• Core set of codecs
• IP bearer service with QoS control mechanism (e.g.
DiffServ)
• Core VPN solution
• Common multicast mechanisms and protocols
• Naming and addressing without overloading the semantics of IP addresses
• Core Authentication Authorisation and Accounting (AAA)
• Core API for bearer access (enabling application portability).
A discussion of these points applied as components in a service-oriented architecture can be found in [19].
One important point is that most of the above func-tionality is readily available. The major challenge will therefore be to agree on a choice for the target architecture. Agreeing on such a selection together with an open approach can be expected to create a very innovative and competitive market for global service production, benefitting the end-users, opera-tors and vendors by increasing the overall revenue in telecommunications.
6.3 IETF core architecture
The IETF based alternative core approach is shown in Figure 9. Here Mobile IP is chosen for global mobil-ity management (i.e. macro mobilmobil-ity). The UMTS is merely considered to be an access technology, on the level of a wireless local area network, with a MAP based local mobility management.
6.4 3G GRX-based core architecture A competing alternative for the core is the GPRS/
GRX backbone as shown in Figure 9 and expanded in Figure 10. (The GPRS architecture with IMS is briefly described in Appendix A.) The GPRS Roam-ing Exchange (GRX) [20] is built on a private or pub-lic IP backbone and transports GPRS roaming traffic via the GPRS Tunnelling Protocol (GTP) [21]
between the visited and the home PLMN (Public Land Mobile Network). A GRX Service Provider (operator) provides of a set of routers with links con-necting to the GPRS networks and links concon-necting to other GRX nodes for peering. The GRX service provider thereby acts as a hub. There is no need for a GPRS operator to establish a dedicated connection to each roaming partner; instead the GPRS operator establishes a connection to the GRX. This allows easier implementation of new roaming relations and rapid time to market for new operators. An alternative is therefore to apply an enhanced GRX backbone as the common converged core.
When the GGSN (Gateway GPRS Support Node) and the SGSN (Serving GPRS Support Node) are located in different networks, they may be interconnected via the IP based Gp interface. This interface provides similar functionality to that of the Gn interface (shown in Figure A1 in Appendix A), however it usu-ally includes extra security functionality based on Figure 8 Target core for service innovation
IP (”Internet”) H.323 domain PSTN / ISDN service domain
NGN generic common core
Disparate services, technologies and access networks are interworked at the edge of the NGN common core.
AS 1
2
mutual agreements between operators. The Gp Inter-face connects PLMNs together. Gp must support appropriate routing and security protocols to enable an end user to access its home services from any of its home PLMN’s roaming partners. Many GPRS
operators/carriers have abstracted these functions through the GRX (Figure 10). This function is typi-cally provided by a 3rd party IP network offering VPN (Virtual Private Network) service that connects all the roaming partners together. The GRX service Figure 9 IETF based core alternative
Figure 10 GRX/GPRS based logical core alternative WLAN
LAN
Pots ISDN
Gateway based service interworking or tunneling IP end-to-end with service transparence
Internet
UMTS
New access UTRAN
H.323
AS HAWAII
(Cellular IP)
GERAN UTRAN GPRS
Core network
Interworkingat the MobileIPlev el
CCS#7based interworking IP based core evolving towards (Mobile) IP(v6), controlled service quality and
IMS Global IMS FMC services
DNS
GPRS 2
GRX
UMTS
New access AS-1
ISDN
GSM BSS UTRAN GPRS
1
Interworking attheGTPlevel
IP/GTP based core, with controlled service quality
MAP based mobility management Global IMS FMC services
GPRS 3
A g e n t
ISDN
Internet
AS-2 AS-3
Internet
provider handles aspects of routing and security between the GPRS networks. The GRX may addi-tionally operate DNS and ENUM services.
The role of the Agent (Figure 10) is to facilitate inter-working and interoperability from both a technical and commercial perspective, key functions include:
• Contract brokering – access to multiple operators/providers via a single agreement;
• Service control and interworking (e.g. for the Internet);
• Accounting and settlement – a single partner for inter-network accounting;
• Mobility management for end systems roaming outside the 3G-domain (e.g. GTP/MAP and Mobile IP interworking);
• IP packet transport (control plane and user plane) – with the prerequisite QoS.
The GRX specifications [20] now state that the GRX shall also support the conversational class of services:
• Max Delay 20 ms
• Max Jitter 5 ms
• Packet Loss 0.5 %
• SDU Error Ratio 10-6
This makes the GRX backbone well suited for e.g.
VoIP and conversational applications.
The Agent depicted in Figure 10 is purely logical, and does not indicate relaying of user plane traffic at a central point. GPRS network 2 and 3 are shown without interworking and service infrastructure.
These networks apply the interworking infrastructure and service infrastructure as offered by the Agent.
(The Agent represents the home network for sub-scribers of GPRS 2 and GPRS 3.)
This hosting offered by the Agent may be utilised as follows:
• Common service production for all operators;
• Common service production for all affiliates of e.g. a multinational operator;
• Hosting of services for third party service providers.
In the basic GRX network only SGSNs and GGSNs implement the GTP protocol. No other systems need to be aware of GTP. The implications of interworking at the GTP level (i.e. for the Agent functionality)
needs further investigation, but is outside the scope of this presentation.
Subscriber identification is of significant commercial importance, and is a key aspect of the architecture.
Operators of GSM/GPRS based cellular networks are mostly in favour of applying the SIM-card for this purpose. However, alternatives are needed as FMC and VoIP also require non-SIM capable user equip-ment access to the common core as a minimum for use of the basic voice service.
6.5 Administrative operations support systems
It is claimed that one of the most important aspects of the proposed harmonization, by introducing the IMS service overlay, is to give operators the opportunity to clean up and take control over the plethora of existing and partly incompatible administrative operations support systems. This has the potential of signifi-cantly reducing the operational and capital expendi-ture. How this is to be achieved in practice needs further study. However, introduction of a new set of administrative support systems integrated with the IMS, spanning the functionality ranging from CRM, via Order to Billing is an interesting but ambitious option. Such a new system might prove commercially viable if based on common harmonised data defini-tions.
7 Conclusions
Interoperability between the different voice services has to be ensured in order to maximize the value of the next generation IP based voice and multimedia services both for the end users, and for the industry as a whole. This presentation has shown that this inter-working for 3GPP based systems is exceedingly com-plex. It is therefore proposed to define a new archi-tecture for the core network. This core archiarchi-tecture will both simplify the interworking, and act as target architecture for future development. However, it can be difficult to standardise this architecture because of conflict of interests between the involved industry players. Operators may therefore protect their inter-ests by choosing their internal core, and benefit from reduced complexity and minimising duplication of network and service development. The technologies not selected as core may be phased out as the core implements the capabilities and capacity to take over the service production. IMS for Fixed Mobile Con-vergence is the first implementation step, but there are still multiple issues, like target topology, naming and addressing, global and localized mobility man-agement etc., that are to be clarified before the full core network can be implemented. The proposed core architecture is also a tool for migration, and in
princi-ple allows adoption of the best solutions from each of the existing mobile and fixed technologies for the core. This is possible while still maintaining the opportunity and flexibility for innovation in services and in access technologies.
The ETSI TISPAN work can be viewed as a first step by standardising the common core overlay technol-ogy. However, as explained, much more than an FMC version of the IMS needs to be settled. The con-flicts lie in the zone between the 3G and the IETF solutions. This represents a major challenge when it comes to selecting the core. Uniting the forces to arrive at a common core by selecting the best alter-natives would in the long run benefit most parties.
The 3GPP has now started the work to construct a new IP based mobile system (AIP NGN) taking the 3GPP system as a starting point. Modifications are planned in order to arrive at a less complex system targeted to the future communication demands. Sup-port of seamless mobility between heterogeneous access networks is a highly stated requirement. The 3GPP is expecting the standardization work to be completed by mid-2007. The new recommendations that will be produced will hopefully realize a harmo-nized architecture with a common core as suggested here.
The proposed core with an IMS overlay is anticipated to give operators the opportunity to clean up and take control over the plethora of administrative operations support systems thereby reducing the operational and capital expenditure. However, this needs further investigation.
8 References
1 3GPP. 3rd Generation Partnership Project; Tech-nical Specification Group Services and System Aspects; General Packet Radio Service (GPRS);
Service description; Stage 2 (Release 6). Decem-ber 2004. (TS 23.060 V6.7.0)
2 3GPP. 3rd Generation Partnership Project; Tech-nical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 6). December 2004. (TS 23.228 V6.8.0)
3 ETSI. Telecommunications and Internet Con-verged Services and Protocols for Advanced Net-working (TISPAN); NGN Release 1; NGN-IMS Stage 2 definition (endorsement of TS.23.228).
September 2005. (TS 182 006 V 0.0.7)
4 Rosenberg, J et al. SIP: Session Initiation Proto-col. June 2002. (RFC 3261) URL:
http://www.ietf.org/rfc/rfc3261.txt?number=3261.
5 3GPP. 3rd Generation Partnership Project; Tech-nical Specification Group Core Network; Sig-nalling flows for the IP multimedia call control based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 5). January 2005. (TS 24.228 V5.11.0)
6 3GPP. 3rd Generation Partnership Project; Tech-nical Specification Group Core Network; IP Mul-timedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 6). January 2005. (TS 24.229 V6.5.1)
7 3GPP. 3rd Generation Partnership Project; Tech-nical Specification Group ore Network; Cus-tomised Applications for Mobile network Enhanced Logic (CAMEL) Phase 4; CAMEL Application Part (CAP) specification (Release 6).
December 2004. (TS 29.078 6.4.0)
8 3GPP. 3rd Generation Partnership Project; Tech-nical Specification Group Core Network; Open Service Access (OSA); Application Programming Interface (API); Part 1: Overview (Release 6).
December 2004. (TS 29.198-1 V6.3.1)
9 ETSI TISPAN homepage. URL:
http://portal.etsi.org/Portal_Common/home.asp.
10 ETSI. Telecommunications and Internet con-verged Services and Protocols for Advanced Net-working (TISPAN); NGN Release 1: Release Def-inition. June 2005. (TR 180 001 V0.4.2)
11 ETSI. Telecommunications and Internet con-verged Services and Protocols for Advanced Net-working (TISPAN); NGN Functional Architecture Release 1. August 2005. (ES 282 001 V 1.1.1)
12 3GPP. 3rd Generation Partnership Project; Tech-nical Specification Group Core Network; Inter-working between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks (Release 6). March 2005. (TS 29.163 V6.6.0)
13 Garcia-Martin, M. 3rd-Generation Partnership Project (3GPP) – Release 5 requirements on the Session Initiation Protocol (SIP). IETF Internet Draft, Work in Progress, October 11, 2002, Infor-mational RFC, RFC 4083, on 2005-5-25. URL:
http://www.ietf.org/rfc/rfc4083.txt.
14 Garcia-Martin, M et al. Private Header (P-Header) – Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partner-ship Project (3GPP). January 2003. (RFC 3455) URL: http://www.faqs.org/rfcs/rfc3455.html.
15 3GPP. 3rd Generation Partnership Project; Tech-nical Specification Group Services and System Aspects; Report on alternative architectures for combining CS Bearers with IMS; Release 6. June 2005. (TR 23.899 V1.2.0)
16 3GPP. 3rd Generation Partnership Project; Tech-nical Specification Group Services and System Aspects; Feasibility study on combined Circuit Switched (CS) calls and IP Multimedia Subsystem (IMS) sessions (Release 7). March 2005. (TR 22.979 V7.0.0)
17 Schulzrinne, H, Agboh, C. Session Initiation Pro-tocol (SIP)-H.323 Interworking Requirements.
July 2005. (RFC 4123) URL:
http://www.ietf.org/rfc/rfc4123.txt
18 Singh, K, Schulzrinne, H. Interworking Between SIP/SDP and H.323. Proceedings of the 1st IP-Telephony Workshop (IPTel’2000), Berlin, April 2000. [online]
http://www1.cs.columbia.edu/~kns10/
publication/iptel2000.pdf.
19 Grønbæk, I. A Service Oriented Architecture for Multi-domain Mobility. Proceedings of ICT 2005 – 12th International Conference on Telecommuni-cations, Cape Town, South Africa, May 3–6, 2005. (ISBN 0-9584901-3-9)
20 GSM Association. Permanent Reference Docu-ment IR.34, Inter-PLMN Backbone Guidelines, Version 3.5.2. August 2004.
21 3GPP. 3rd Generation Partnership Project; Tech-nical Specification Group Core Network and Ter-minals; General Packet Radio Service (GPRS);
GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface (Release 6). June 2005. (TS 29.060 V6.9.0)