P809-GI
Mobility in the broadband environment based
on IN evolution
Deliverable 2
Network Architecture for Broadband Mobility
Volume 1 of 2: IN architecture for the benchmark services
Suggested Readers:
 Network and System implementers
 Network Planners
 Network Integration Engineers
For full publication
June 1999
EURESCOM PARTICIPANTS in Project P809-GI are:

BT

Deutsche Telekom AG

FINNET Group

France Télécom

Portugal Telecom S.A.

Swisscom AG

Tele Danmark A/S

Telecom Eireann

TELECOM ITALIA S.p.a.

Telefónica 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 P809-GI
Deliverable 2
Volume 1: IN architecture for the benchmark services
Preface
(Prepared by the EURESCOM Permanent Staff)
EURESCOM Project P809 was started in January 1998 with the main objective of
enabling broadband networks, using IN, to support all forms of mobility. The Project
has ended in May 1999. There were 10 companies participating in the Project – Finnet
Group, BT, Swisscom, Tele Danmark, Deutsche Telekom, France Télécom, CSELT,
Portugal Telecom, Telefónica and Telecom Eireann. The planned size of the Project
was 15.6 man-years over 15 months. France Télécom was the Project leader.
The first Deliverable from the Project contained descriptions of typical benchmark
services that are relevant for broadband mobile multimedia services. In particular it
identified the new mobility requirements of broadband multimedia services on the
basis of the GMM framework and existing mobility services in the narrowband
environment. This gave a good overview of the sort of Broadband multimedia service
that is likely to emerge and the demands these services will put on the Intelligent
Network to provide these services while supporting terminal and personal mobility.
This Deliverable is the second from the Project and it has been divided into two
volumes. Volume 1 examines the IN architecture issues arising from the benchmark
services of Deliverable 1. It also looks at the impact of IP and the terminal
requirements. Volume 2 concentrates on the fixed-mobile convergence issues.
The third Deliverable of the Project contains an Evolution Strategy for achieving
broadband multimedia mobility evolving from today’s networks.
© 1999 EURESCOM Participants in Project P809-GI
page i (xi)
Volume 1: IN architecture for the benchmark services
pages ii (xi)
Deliverable 2
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2
Volume 1: IN architecture for the benchmark services
Executive summary
This Deliverable was prepared by the EURESCOM P809 project: “Mobility in the
Broadband Environment based on IN Evolution”. In Part 1 of the Deliverable, we
examine the use of the Intelligent Network (IN) to provide multimedia services in a
mobile environment, the developments in ‘intelligent’ terminals, the use of the
Internet Protocol (IP) in broadband service provision and the implications for network
interfaces and protocols.
Our research in P809 has shown that object orientation and distributed processing
techniques can be used to provide broadband multimedia services in a mobile
environment. Therefore we recommend that SIBs should no longer be used to build
the service creation environment. Instead, new Object Oriented techniques should be
used. To support this the required IN functionality for selected ‘benchmark’ services
was modelled as an example. Both connection oriented and packet mode services
were examined. The connection oriented services were 'Meet-me conference', 'Add-on
conference', 'Video on demand' and 'Virtual private network'.
Object orientation techniques enabled the services to be modelled on the Global and
Distributed Functional Planes. Traditional IN functional entity actions can be mapped
to object oriented operations. The messages between objects in different functional
entities can correspond to standard Intelligent Network Application Protocol (INAP)
information flows.
Both Broadband Integrated Services Digital Networks (B-ISDN) and IP networks can
use the same Asynchronous Transfer Mode (ATM) switching fabric. The support of
both packet-switched and connection oriented services on the same core network is an
extension of the Global Multimedia (GMM) concept.
Two approaches to mobility in IP networks are presented. The first one uses the
Ipsilon IP-switching technology and/or the Resource Reservation Protocol (RSVP).
The other is based on gateways which tunnel the IP packets through the switched
ATM network.
Network interfaces for mobility support are identified and examined. These include
the interfaces between the core networks of distinct mobile operators, where each
operator plays one or more Universal Mobile Telecommunications System (UMTS)
roles. These roles were identified in P809 Deliverable 1. The interface between the
UMTS Terrestrial Radio Access Network (UTRAN) and the core network of a mobile
operator is discussed. Other interfaces within the core network of a mobile operator
are required for competitive procurement purposes.
With regard to protocols, advanced service creation and support in the Global System
for Mobile communications (GSM) environment will use the Customised
Applications for Mobile networks Enhanced Logic (CAMEL) system, which is an
adaptation of IN for mobile networks. Currently, CAMEL Phase II is implemented by
manufacturers and specification work on CAMEL Phase III is underway. Both GSM
and UMTS are expected to deploy CAMEL Phase III services and these will be based
on the INAP protocol. The GSM Mobile Application Protocol (MAP) will be
enhanced for UMTS mobility management.
We also have identified architectural and service capabilities which 'new' terminals
will need in a multimedia mobile environment.
© 1999 EURESCOM Participants in Project P809-GI
page iii (xi)
Volume 1: IN architecture for the benchmark services
Deliverable 2
This Deliverable charts a way forward to integrated mobile multi-media services as
envisaged in the GMM report. It should assist EURESCOM shareholders in
developing value added multimedia services and help in planning the infrastructures
needed to support such services. It will also provide a basis for work in the
EURESCOM P919 project.
pages iv (xi)
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2
Volume 1: IN architecture for the benchmark services
List of authors
Harri Hansén
AF
Ari-Pekka Kanerva
AF
Geoff Richman
BT
Paul Glennon
BT
John Charles Francis
CH
Christoph Mäder
CH
Narcisse Mahova
CH
Astrid Wilcken
DK
Finn Kristoffersen
DK
Niels Kristian Kristiansen
DK
Petia Todorova
DT
Hartmut Brandt
DT
Rached Hazem
FT
Claudine Guedj
FT
Yves Huon
FT
Domitille Menard
FT
Gaetano Morena
IT
Giuseppe Plagenza
IT
Carlo Bruno
IT
Jaime Ferreira
PT
Gustavo Pinto Basto
PT
Gaspar Moreno
TE
Bartolome Salas-Manzanedo
TE
Ignacio Berberana
TE
Richard Collins
TI
Andrew Kelleher
TI
© 1999 EURESCOM Participants in Project P809-GI
page v (xi)
Volume 1: IN architecture for the benchmark services
Deliverable 2
Table of contents
Preface ............................................................................................................................. i
Executive summary ....................................................................................................... iii
List of authors ................................................................................................................ v
Table of contents ........................................................................................................... vi
List of Acronyms......................................................................................................... viii
Glossary of terms .......................................................................................................... ix
1
Introduction ............................................................................................................ 1
2
IN architecture for the benchmark services ............................................................ 2
2.1 IN evolution to Object Oriented service definition ...................................... 2
2.2 Benchmark services and applications .......................................................... 4
2.3 Global Functional Plane models of the benchmark services ....................... 4
2.4 Add-on broadband video conference service ............................................... 5
2.5 Conclusions .................................................................................................. 9
3
Functional entity requirements and Distributed Functional Plane models .......... 11
3.1 Access network architectures ..................................................................... 11
3.2 Core network aspects ................................................................................. 11
3.2.1 Video on Demand service ............................................................. 12
3.2.2 Add-on broadband video conference service ................................ 12
3.2.3 Meet-me broadband video conference service .............................. 14
3.2.4 Broadband Virtual Private Network service ................................. 15
3.2.5 Mobility requirements of IN/ B-ISDN for multimedia
service support .............................................................................. 16
4
Mobility in IP-based networks ............................................................................. 17
4.1 IP/ATM architecture based on IP switching or the RSVP ......................... 17
4.2 IP/ATM architecture based on gateways and tunnelling ........................... 18
4.3 Mobility management ................................................................................ 20
4.4 The IP QoS chain ....................................................................................... 20
4.4.1 Integrated services (RSVP) ........................................................... 20
4.4.2 Differentiated services .................................................................. 21
4.4.3 Other QoS solutions ...................................................................... 21
5
Terminal requirements for broadband mobile multimedia services ..................... 23
5.1 Overview .................................................................................................... 23
5.2 Application domain considerations for 3G terminals ................................ 25
5.3 Mechanisms to download information to the terminal .............................. 27
5.3.1 Mobile terminal requirements ....................................................... 27
5.3.2 Security aspects ............................................................................. 27
5.4 Possible mechanisms for VHE ................................................................... 28
5.4.1 Service execution within the UMTS Subscriber Identity
Module .......................................................................................... 28
5.4.2 Service execution within the mobile equipment ........................... 29
5.5 Multi-mode terminals ................................................................................. 30
5.6 Handover management ............................................................................... 31
6
Impact of mobility on network interfaces and protocols ...................................... 33
pages vi (xi)
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2
6.1
6.2
7
Volume 1: IN architecture for the benchmark services
Interfaces identified for mobility support .................................................. 33
Protocol Aspects ........................................................................................ 34
Conclusions .......................................................................................................... 35
Referenced documents ................................................................................................. 36
© 1999 EURESCOM Participants in Project P809-GI
page vii (xi)
Volume 1: IN architecture for the benchmark services
Deliverable 2
List of Acronyms
ATM
Asynchronous Transfer Mode
B-ISDN
Broadband Integrated Services Digital Network
B-VPN
Broadband Virtual Private Network
CAME
Customized Applications for Mobile networks Enhanced Logic
CN
Corresponding Node
CS
Capability Set
DFP
Distributed Functional Plane
ETSI
European Telecommunications Standards Institute
FE
Functional Entity
FA
Foreign Agent
FMC
Fixed Mobile Convergence
GFP
Global Functional Plane
GMM
Global Multimedia Mobility
GPRS
General Packet Radio Service
GSM
Global System for Mobile communications
GSM MoU
GSM Memorandum of Understanding (association of GSM
operators)
HA
Home Agent
HN
Home Network
IETF
Internet Engineering Task Force
IMT-2000
International Mobile Telecommunications 2000
IN
Intelligent Network
INAP
Intelligent Network Application Protocol
INCM
Intelligent Network Conceptual Model
IP
Internet Protocol
IPSOFACTO
IP Switching Over Fast ATM Cell Transport
ISDN
Integrated Services Digital Network
ITU
International Telecommunications Union
JMV
Java Virtual Machine
LG1
Level 1 Gateway
MAP
Mobile Application Protocol
MMI
Man Made Interface
MN
Mobile Node
MoU
Memorandum of Understanding
pages viii (xi)
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2
Volume 1: IN architecture for the benchmark services
MPEG
Motion Picture Expert Group
OO
Object Oriented
PC
Personal Computer
PIN
Personal Identification Number
PNNI
Private Network-Network Interface
PNO
Public Network Operator
PSTN
Public Switched Telephone Network
QoS
Quality of Service
RN
Remote Network
RSVP
Resource ReserVation Protocol
SIB
Service Independent Building Block
SIM
Subscriber Identity Module
STB
Set-Top Box
UML
Unified Modelling Language
UMTS
Universal Mobile Telecommunications System
USIM
User/Subscriber Identificatiion Module
UTRAN
UMTS Terrestrial Radio Access Network
VASP
Value Added Service Provider
VHE
Virtual Home Environment
VoD
Video on Demand
WATM
Wireless ATM
WWW
World Wide Web
Glossary of terms
Authentication: A property by which the correct identity of an entity or party is
established with a required assurance. The party being authenticated could be a user,
subscriber, service provider or network operator.
Capability: The ability of an item to meet a service demand of given quantitative
characteristics under given internal conditions.
Connectionless service: A service which allows the transfer of information among
users without the need for end-to-end call establishment. Connectionless services may
be used to support both interactive and distribution services.
Fixed network service: A service with a set of capabilities that allows service profile
management but not any type of mobility.
Handover: The action of switching a call in progress from one cell to another
(intercell) or between radio channels in the same cell (intracell) without interruption
of the call. Note: Handover is used to allow established calls to continue when mobile
© 1999 EURESCOM Participants in Project P809-GI
page ix (xi)
Volume 1: IN architecture for the benchmark services
Deliverable 2
stations move from one cell to another (or as a method to minimise co-channel
interference).
Home Environment: In '3rd Generation mobile systems, this denotes the expression
of the overall picture of service presentation, service access and service handling
procedures as seen by the user and as indirectly specified in the associated
subscription. It has the background of one or more 3G networks that form the
permanent technical basis for the respective service provision. It replaces the term
"home network" in 2G system [TG.21].
IMT 2000: International Mobile Telecommunication 2000. FPLMTS/IMT-2000:
Those systems which conform to the corresponding series of ITU Recommendations
and Radio Regulations .
Intelligent network: A telecommunication network based on an architecture that
provides flexibility for facilitating the introduction of new capabilities and services,
including those under customer control.
Interactive service: A service which provides the means for the bi-directional
exchange of information between users or between users and hosts.
Location service: A particular mobility service in which location information can be
provided to authorised users or to relevant authorities in case of emergency calls or
for vehicular traffic management.
Migration: Movement of users and/or
telecommunication networks to new networks.
service
delivery
from
existing
Mobile service: A service with a set of capabilities that allows some combination of
terminal mobility and service profile management.
Mobility manager: A repository of information and its associated processes accessed
by personal mobility management or terminal mobility management. Notes: 1) A
mobility manager is used for location management, terminal registration and personal
registration. 2) A mobility manager is a functional concept which may be
implemented in different ways, for example, as a database or in a signalling transfer
point.
Multimedia service: A service in which the interchanged information consists of
more than one type (e.g. video, data, voice, graphics). Notes: 1) Multimedia services
have multivalued attributes which distinguish them from traditional
telecommunication services such as voice or data. 2) A multimedia service may
involve multiple parties, multiple connections, the addition/deletion of resources and
users within a single communication session.
Network architecture: A network configuration which identifies and defines
physical entities and physical interfaces between these physical entities.
Network operator: A provider of network capabilities needed to support the services
offered to subscribers.
Packet transfer mode: A transfer mode in which the transmission and switching
functions are achieved by packet oriented techniques, so as to dynamically share
network transmission and switching resources between a multiplicity of connections.
Personal mobility: The ability of a user to access telecommunication services at any
terminal on the basis of a personal telecommunications identifier, and the capability
of the network to provide those services according to the user’s service profile. Notes:
pages x (xi)
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2
Volume 1: IN architecture for the benchmark services
1) Personal mobility involves the network capability to locate the terminal associated
with the user for the purposes of addressing, routing, and charging of the user’s calls.
2) The word access is intended to convey the concepts of both originating and
terminating services. Management of the service profile by a user is not part of
personal mobility.
Public network operator: A provider of the network capabilities needed to support
the services offered to the general public.
Roaming: The ability of a user to access wireless telecommunication services in
areas other than the one(s) where the user is subscribed.
Security: The protection of information availability, integrity and confidentiality.
Service profile: A record containing information related to a user in order to provide
that user with a defined set of services.
Service provider: A person or another entity that has the overall responsibility for
the provision of a service or a set of services to the users and for negotiating network
capabilities associated with the service(s) he/she provides.
Terminal mobility: The ability of a terminal to access telecommunication services
from different locations and while in motion, and the capability of the network to
identify and locate that terminal or the associated user. Notes: 1) This ability implies
the availability of telecommunication services, ideally, in all areas and at all times. 2)
Terminal mobility may be provided according to the mobile terminal’s or the users
service profile.
Universal mobile telecommunications system: Future multi-function mobile system
with wideband multimedia capabilities as well as present narrow band capabilities.
UMTS is the planned European member of the ITU IMT-2000 family concept. UMTS
will probably consist of a family of interworking networks, delivering the same new
and innovative personal communication services to users regardless of used networks.
User: A person or other entity authorised by a subscriber to use some or all of the
services subscribed to by that subscriber.
Virtual home environment (VHE): A system concept for service portability in
UMTS across network borders. In this concept, the visited network emulates, for a
particular user, the behaviour of his home environment. For the user, adaptation of
service handling is therefore unnecessary.
© 1999 EURESCOM Participants in Project P809-GI
page xi (xi)
Deliverable 2
1
Volume 1: IN architecture for the benchmark services
Introduction
The Intelligent Network provides service independent functionality. Classical IN
proposed the use of 'service independent building blocks' (SIBs), which could be
combined to provide a wide range of services quickly and efficiently. The services
would be independent of the underlying network infrastructure and could be adapted
to particular requirements on an individual basis. The legacy IN model has not been
able to meet these requirements. P809 studied an Object Oriented (OO) approach
which promises to be more successful.
This Deliverable is in two parts. Part 1 begins by examining the functionality needed
to support mobility in multimedia services based on IN evolution. A number of
'benchmark' services were selected and analysed. The basis of the selection is given in
P809 Deliverable 1 and Service Plane aspects are discussed there. Typical broadband
services have been chosen. The most important service types are represented.
However, the services are not intended for standardisation as such. The services were
modelled so as to identity their IN requirements.
Currently, GSM voice services are offered by several EURESCOM Public Network
Operators (PNOs). New GSM technologies, such as High Speed Circuit Switched
Data and the General Packet Radio Service (GPRS), will provide higher bitrate
services.
In 2002, some EURESCOM Public Network Operators (PNO) will offer UMTS. This
cellular system uses new radio access technologies and frequencies and will be
positioned, in the first instance, for mobile data support. From a core network
perspective, it will build on the ‘GSM platform’. In this regard, the GSM
Memorandum of Understanding (MoU) indicates a preference for the evolution of
GPRS components for core network support of UMTS. Standardisation work for
UMTS will be carried out in the European Telecommunications Standards Institute
(ETSI) 3rd Generation Partner Project (3GPP), to take account of the needs and
market requirements of GSM operators worldwide, these developments will have far
reaching implications.
The convergence of fixed and mobile services and platforms must be carefully
planned. Part 2 of this Deliverable deals with fixed-mobile convergence.
The growth of IP and intelligent terminals is transforming existing networks. Their
effects on future networks will be profound and accordingly attempts have been made
to assess these here.
All these changes must be implemented in standards. P809 examines some possible
impacts on network interfaces and protocols .
© 1999 EURESCOM Participants in Project P809-GI
page 1 (36)
Volume 1: IN architecture for the benchmark services
2
Deliverable 2
IN architecture for the benchmark services
A key objective of the IN is to provide service-independent functions that can be used
as ‘building blocks’ to construct a variety of services. This allows easy specification
and design of new services. A second objective is network-implementationindependent provision of services. This approach isolates the services from the way
the service-independent functions are actually implemented in various physical
networks, thus providing services that are independent of underlying physical
network infrastructure(s). ‘To introduce new services quickly’ is the IN leitmotiv.
To achieve that goal, much work has been done based on the concept of SIBs.
However this hard work resulted in heterogeneous functions difficult to process. The
legacy IN conceptual model did not fulfil these hopes.
The GFP model for the add-on video conference is shown as an example. Models for
the other benchmark services are available on request from EURESCOM.
2.1
IN evolution to Object Oriented service definition
Future IN specifications will improve modelling techniques so as to provide serviceindependent models and network-implementation-independent service provision,
through a flexible INCM model. There is a need to modify the SIB based model to
capture new Object Oriented (OO) methodology for defining IN services.
Compared to the SIB approach, OO methodology is considered a promising technique
for service modelling. The main advantages of the OO approach are:

the object model can be derived from textual specifications in a rather intuitive
and flexible way.

the object-oriented approach can model the overall behaviour of the system.

the object-oriented approach is very flexible: Object classes are independent,
modular, portable, reusable and easily extensible.
The possibility to extent the object model is especially important when addressing
new aspects in IN service modelling, in this Project the broadband service and
mobility aspects. Therefore, we have investigated using OO methodology to describe,
in a flexible way, the IN systems involved in providing the selected benchmark
multimedia services in a mobile environment.
Nevertheless, our Project has rejected one ITU-T proposal for GFP modelling which
is to translate SIBs in an object oriented approach. Indeed, we consider in that case
that the advantages of the object model will be reduced, because the boundary of SIBs
and therefore ‘operations block’ are reused. That means that in this approach the view
of the system is unchanged. We rejected the SIB translator method, because it has the
drawbacks of SIBs without actually benefiting from OO techniques.
To take full benefit of the object-oriented approach, the system should be described
from the beginning using an OO approach. This also at means that we consider the set
of service features in the IN service plane very constraining and limiting.
On the other hand, in order to model the service on the GFP, we do not consider
distribution of the application or distributed processing nodes. Therefore the ODP
does not suit our object oriented model.
page 2 (36)
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2
Volume 1: IN architecture for the benchmark services
Therefore, in order to produce an object-oriented model of the GFP, we use the object
approach from the beginning. Nevertheless, we are not focused in P809 on OO service
modelling.
In the object-oriented approach which we followed, there are two modelling steps:
first the system analysis step and, secondly, the design model step. In our study we
only performed the analysis step as this is sufficient to define the GFP level service
models.
Indeed, the purpose of an object oriented method, such as OMT (and UML notation),
is to model the real world of the system. This system model can be completed by
modelling also the behaviour of the objects.
Analysis is the first step of this method, but before achieving models it is necessary to
establish a textual description of the problem, which emphasises general information
about the needs of the parties (users, providers etc.), the interactions of the system
with other entities, the type of information exchanged etc. Then, it is possible to
identify relevant object classes which include physical entities, concepts etc and the
associations between the classes which correspond to dependencies between the
classes, such as interactions, communications, ownership etc. The last step of object
modelling is to group classes into modules. A module is a set of related classes which
capture some logical subset of the entire model (OMT 91). So, a telecommunication
model may contain modules for managing the resource configurations of the switch,
routing the calls, processing the messages exchanged with other modules, providing
information.
In the current Project, the object modelling of services is concerned with devising
models of several services but with the aim of identifying the service classes and
modules for realising precisely the global service. So, the service modules will be in
accordance with the Service Plane of the IN architecture and also with the distributed
aspects of the implementations because an object is by itself an execution independent
entity. Some modules will be more IN network related, such as INAP interfaces, but
this won’t be a problem for the modelling approach which doesn’t take into account
the details of the implementations. Only the external aspects of each object, accessible
through an interface, are relevant for the modelling approach and the basic IN
functions will be available by means of the methods of the interfaces.
From the mobility perspective, we have noticed the inability to model explicitly the
handover and roaming mechanisms on an object oriented GFP plane service model.
These mechanisms are not explicitly part of the model as the ‘access network’ and
‘another IN system’ are considered external entities of the modelled IN system.
The object model is less successful at the DFP level and we have identified some
important problems which must be addressed if the methodology is to be useful at the
DFP level. These are:
a) the development of generalised objects,
b) the assignment of the objects to particular functional entities,
c) the interactions between the IN and the basic call,
d) charging integration,
e) call and connection separation issues.
We have defined objects to model the functionality needed for the benchmark
services. The objects belong to classes which, at first sight, appear to be diverse.
© 1999 EURESCOM Participants in Project P809-GI
page 3 (36)
Volume 1: IN architecture for the benchmark services
Deliverable 2
However, the classes are of two categories, service specific and service independent.
From the service independent classes used in the benchmark service models, general
classes for service modelling may be derived. The set of general classes could form
the basis for an OO service modelling repository.
2.2
Benchmark services and applications
They following 'benchmark' services were selected for analysis [P809 Deliverable 1]:

Video on demand

Video conference (add-on and meet-me)

Broadband virtual private network

World Wide Web services

Multimedia messaging services.
The selection includes connectionless and connection-based applications, distribution
services and interactive services.
The nature and scope of a service are not changed by its provision in a mobile
environment. However, personal and terminal mobility will impose some additional
requirements.
The benchmark services were chosen to illustrate a range of problems in providing
broadband functionality using IN. These services have many common elements. It is
important, where possible, to use a common set of object classes for several services
so as to simplify software provision. This is the rationale behind the IN approach. To
meet this objective we must try to reduce the number of object classes. Mechanisms
are needed to group the classes together for ease of use, maintenance and reusability.
We identified common elements shared by several, and in some cases all, services. It
may be useful to consider a generalised service model, a kind of template for general
service provision. This might enable some generalised object classes to be specified.
Operations to provide personal mobility, terminal mobility and user profile portability
are common to all services and it should be possible to use some common object
classes for these aspects.
2.3
Global Functional Plane models of the benchmark services
The Global Functional Plane (GFP) models an Intelligent Network as a single entity.
Mobility imposes additional demands on the model. The main demands are for
'personal mobility', 'terminal mobility', 'roaming' and the 'virtual home environment'.
(Definitions of these are given in the glossary above). The concept of ‘actor’ was
introduced into the modelling in order to analyse the services including the mobility
and broadband aspects. The system to be modelled and its actors are shown in Figure
2.1. The 'system' is the core IN. The 'actors' external to the system, who exchange
information with it, are the users the terminals and non-IN systems. Modelling of the
mobility features requires the inclusion of an 'IN system' actor (needed for roaming
features) and a 'wireless access system' actor (for handover features).
page 4 (36)
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2
Volume 1: IN architecture for the benchmark services
USERS
(external actors) :
USERS
IN System
for
multimedia
services
TERMINAL
Non IN SYSTEM
(e. g. B-ISDN)
IN SYSTEM
WIRELESS ACCESS
SYSTEM
Figure 2.1: the 'system' and its 'actors'
Mobility management procedures are required to support the mobile user. Callunrelated mobility management procedures include 'location registration',
'authentication' and 'additional user'. Call related procedures include 'retrieval of home
domain' and 'handover'.
The architecture developed for the Global Functional Plane envisaged that most of the
service functionality would be located within the IN. However, ownership issues
influence the assignment of objects to functional entities.
The location of objects will be influenced by the business model. It is necessary to
define the domains involved in instances of service provision. Business and
ownership issues affect the network architecture.
2.4
Add-on broadband video conference service
To illustrate the OO approach which was used to model the benchmark services, part
of the the Add-on video conference service model is shown below. The starting point
for the modelling is a textual description of the service:
The broadband video conference services (BVC) provide real-time conferencing
facilities, in which audio, video and data can be exchanged. Two conference types are
commonly considered; ‘add-on’ and ‘meet-me’. In the ‘add-on’ video conference, a
caller assumes the role of conference co-ordinator deciding on conference
configuration, initiation and termination.
Figure 2.2 shows the ‘actors’ in a session.
© 1999 EURESCOM Participants in Project P809-GI
page 5 (36)
Volume 1: IN architecture for the benchmark services
Deliverable 2
NETWORK
Participant C
Co-ordinator
Participant B
Participant A
Figure 2.2: Add-on video conference actors
Multipoint to multipoint connections with signal merging and distribution are
required. The server is controlled by the service and not by the participants, relying on
the IN for conference reservation, set up and configuration. The conference coordinator initiates the conference, accepts new participants and requests termination.
Network
Connection
A
B
S
C
D
Figure 2.3: Multi-point to multi-point connections based on a server
Service capabilities, representing service activities or phases, include: service
registration, service activation, cancelling a previous registration, or adding a new
participant to a conference.
Service access may be achieved directly through the core B-ISDN network or through
a UMTS. These networks provide the terminal mobility features, including handover
support, in which the IN itself is not normally involved. Terminal and personal
mobility are important requirements. In terminal registration’, the network is informed
of terminal presence and capabilities. In ‘user registration’, the user interacts with the
service, providing his identity and credentials.
In ‘service reservation’, a conference is scheduled and reserved. ‘Service activation’
can be requested by producing the conference identifier issued in the service
registration procedure.
The objects needed for the service model are derived from the textual description. In
this Project UML is used to model the services. For the definition of the object model
several classes are necessary. Some of these classes are specific to the service or
service dependent (Figure 2.4). The central element is the add-on video conference
class, inheriting the generic Service class properties and associations.
page 6 (36)
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2
Volume 1: IN architecture for the benchmark services
User
H o m e D om a in
S e r vi c e
Nam e
P IN
1 ..*
1 ..*
A tt a ch e d F la g
A d d - o n V id e o C o n fe r e n c e
P a r ti c i p a n t
C o n fe r e n c e T i tl e
1 ..*
C o m m u n i c a ti o n p ro fi le
S c h e d u le
+has
M u l ti p o i n t S e r ve r
R e s e rv e d C a p a c ity
+has
1
+us es
C ha rg e m o d e
1
A c ti va ti o n ( )
D e a c ti va ti o n ( )
C o - o r d in a to r
T o ta l C a p a c i ty
1
0 ..*
c o n tr o ls
C o n tr o l A d d r e s s
+ s u p p o r ts
R e s e r v a ti o n ( )
1
Figure 2.4: Add-on video conference service classes
The entities which govern terminal and user relationships are shown in Figure 2.5.
User
H o m e D om a in
Name
1 ..*
1 ..*
P IN
S e r vi c e
(fro m S e rv i c e )
A tta c h e d F l a g
1 ..*
A tta c h T o T e r m i n a l ()
D e ta c h F r o m T e r m i n a l ()
- i s s u p p o r te d b y
1 ..*
+ i s a tta c h e d to
0 ..*
1 ..*
- i s c o m p a ti b l e w i th
T e rm i n a l
N e tw o r k A c c e s s P o i n t
T e r m i n a l a d d re s s
A tta c h e d F l a g
i n i ti a l i s e ( )
Ad d re s s
+ i s a tta c h e d to
0 ..*
c a n c e l()
0 ..*
At ta c h T o A c c e s s P o i n t( )
D e ta c h F r o m A c c e s s P o i n t()
Figure 2.5: Mobility classes and relationships
The identified objects and the corresponding classes are specified and structured.
Figure 2.6 shows the service independent classes.
© 1999 EURESCOM Participants in Project P809-GI
page 7 (36)
Volume 1: IN architecture for the benchmark services
Deliverable 2
Personal Mobility Manager
Service
Register User()
1..*
Service Component
Deregister User()
1
(from Service)
Authorise()
User Data()
Service Choice()
Authentication
Log
Start logging()
Stop logging()
CallControl
Authorised Relationship
Id
Charge
root address
AuthenticateUser()
StartCharging()
EndCharging()
AddParty()
EndAuthorisation()
RemoveParty()
UserData()
EndCall()
AbandonCall()
Resource management
Data Management
User Interaction
Allocation()
menudata
DisplayMenu()
Userdata()
Modification()
Retrieve()
Deallocation()
Resource Data()
Modify()
Store()
ConnectionControl
root address
DisconnectParty()
Continue()
ConnectParty()
EndConnection()
AddressTranslation
DisconDetect()
CurrentAddress
Translate()
Figure 2.6: Service independent classes
Identification of the service independent classes forms the basis for the definition of a
service independent class library. Specialisation of service independent classes to
specific service classes is illustrated in Figure 2.7.
U s e r In te r a c ti o n
D a ta M a n a g e m e n t
m e n u d a ta
R e tr i e ve ( )
M o d i fy( )
D i s p l a yM e n u ( )
S to r e ( )
U s e r d a ta ( )
C o n ti n u e ( )
E xe c u te
n a m e : typ e = i n i tva l
A d d - o n V C D a ta M g t
e xe c u te ( )
R e s e r va ti o n M e n u
V C S e r ve r D a ta M g t
P a r ti c i p a n tD a ta M g t
A c ti va ti o n M e n u
A u th o r i s _ i d ()
Figure 2.7: Specialised service objects
From the structural model of the service defined by the classes and objects, the
behaviour is specified using the UML 'use case' notation. This specifies the
information exchanges between the objects. Methods of the objects can be derived
from these scenarios. Finally, the classes may be grouped into containers, called
‘packages’ in UML. Packages are collections of related classes, which provide
support for certain tasks. For example, the classes identified for the benchmark
page 8 (36)
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2
Volume 1: IN architecture for the benchmark services
services were distributed in three packages. These packages are collections of
interface components, of service operation components and of information
components.
2.5
Conclusions
P809 adopted an object oriented approach. At the Global Functional Plane level the
use of an such an approach is feasible.
We decided not to use a 'SIB translation' (one to one correspondence between SIB
operations and objects) approach here. To obtain the full benefit of OO, the system
was examined using an OO methodology. Starting from the textual descriptions, the
functional and operational requirements of each service were identified. Interactions
with other entities were specified and the exchange of information described. These
were analysed using sequence diagrams, leading to the definition of object classes.
The objects were grouped into modules, sets of related classes which capture logical
subsets of the overall model.
Our proposal for IN professionals is that SIBs will no longer be used in future IN
specifications to build the service creation environment. New OO techniques such as
UML or CORBA provide an alternative way to disseminate IN services or
applications into smaller parts or packages. These packages can then be broken down
into Object Classes and interfaces.
The next wave of IN will permeate the information infrastructure and will involve the
integration of mobility, the Internet and multimedia. A flexible way to create and
model services is essential if operators are to gain the competitive upper hand.
© 1999 EURESCOM Participants in Project P809-GI
page 9 (36)
Volume 1: IN architecture for the benchmark services
page 10 (36)
Deliverable 2
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2
3
Volume 1: IN architecture for the benchmark services
Functional entity requirements
Functional Plane models
and
Distributed
In this chapter, a core network functional architecture is evolved using the Intelligent
Network. The architecture enables the benchmark multimedia services to be provided
in a mobile environment. An integrated IN/B-ISDN core network is extended to offer
mobility functions.
The Distributed Functional Plane (DFP) gives a distributed view of an Intelligent
Network. It details the functional entities (FE) involved in the service provision. The
GFP functions required for the benchmark services were mapped to the DFP. An
outline of the architecture is given for each service.
An object oriented methodology is used rather than the traditional IN one.
Comparisons are made between the two approaches. Different ways of mapping the
mobility functions betwen the GFP and DFP are shown.
The work is based on ETSI, ITU-T and ATM FORUM activities.
The wireless access scenarios, Fixed access scenarios and DFP descriptions of the
benchmark services are available on request from EURESCOM.
3.1
Access network architectures
In a mobile environment, there is no permanent association between a user address
and a unique point in the network. Wireless access systems currently being developed
include GSM, Digital European Cordless Telephone (DECT), Cordless Telephone
(CT) 2, Wireless ATM and Wireless Local Area Network (WLAN). UMTS
International Mobile Telecommunication (IMT) 2000 will provide mobility with
global coverage and bit rates up to 2Mbit/s.
IMT-2000 (including UMTS) will serve both fixed and mobile users. Both wired and
cordless technologies will support fixed access.
3.2
Core network aspects
The mapping from the OO model to the DFP can be performed by assuming a new
DFP architecture whereby the distribution of the functions remains hidden to the
service, e.g. the CORBA architecture. In the current INCM, GFP entities are SIBs,
but, for mapping to the DFP, GFP functions could be used instead. Finally, a direct
mapping from a GFP model to an INCM DFP model is possible if certain assumptions
are made.
Figure 3.1 illustrates the three approaches. If a DFP network architecture based on the
INCM is chosen, GFP functions are derived from the OO model, indicated by d in the
figure. Each function is then mapped to a function in the DFP via m1. Alternatively, if
an OO network architecture is assumed, the GFP OO model can be mapped directly
on to the DFP OO architecture, indicated by m2 in the figure. The direct mapping
from an OO GFP model to a DFP INCM model indicated in the figure by m3 is
possible only if OO concepts can be related to those in the INCM architecture.
© 1999 EURESCOM Participants in Project P809-GI
page 11 (36)
Volume 1: IN architecture for the benchmark services
GFP
Deliverable 2
OO model
d
Functions
m1
DFP
m2
m3
INCM architecture
(e.g. IMT-2000)
OO architecture
(e.g. CORBA)
Figure 3.1: Mapping from GFP to DFP
3.2.1
Video on Demand service
The following functional entities are identified within the ‘system’ :
SCF: Service control functionality
SSF: Switching functionality, concerned with routing and switching operations
SDF: Service database, a repository of service and user information
SRF 1: Level 1 gateway database
SRF 2: Level 2 gateway database
SRF 3: Billing manager & charging functionality.
Objects dealing with mobility are allocated among the functional entities SDF, SCF,
SRF1 and SRF3.
VoD requires non call related interactions; the updating to databases when videotapes
are added to or deleted etc. The locations of objects for these interactions is done in
two functional entities: the SDF and the SCF.
3.2.2
Add-on broadband video conference service
The DFP architecture for the add-on conference service was derived from the GFP
architecture described in Section 2.4 above. Classes were organised in three packages;
one for service related objects, another for classes which are used as service building
blocks (‘object oriented’ SIBS) and the third for mobility related classes (Figure 3.2)
Mobility and Network
Add-on VC Service
Common Services
(SIBS)
Figure 3.2: Add-on vdeo conference packages
page 12 (36)
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2
Volume 1: IN architecture for the benchmark services
Instances belonging to classes strongly related to the service are located at the core
network. They may be either at the SCF or SDF, depending on their run-time status.
Some of these classes are specific to this service (e.g. Co-ordinator, Participant), or
service dependent while others (User) may be common to other services.
The specialised resources, needed for a conference, may be also located at the
SCF/SDF. As an example, the reservation service method available at the Add-on
video conference object will perform the association between a particular service
instance and its allocated server.
Add-on VC Service classes identified are: Service, User, Profile, Add-on VC,
Participant, Co-ordinator, Multipoint Server, Profile, Service Profile and User Profile.
Mobility classes and relationships with service classes are shown in Figure 3.3.
User and Service classes are part of the service package and are represented to show
relationships between them. Mobility classes identified are Terminal, Network Access
Point and Personal Mobility Manager.
The Personal Mobility Manager and Terminal classes will be located in the core
network.
Figure 3.3: Mobility classes and relationships with service classes
The Common Services package contains the blocks needed to build new services. As
such, they are service logic objects which reside at the core network in the service
processing environment. Object classes are grouped according to their purpose, i.e.
mobility, general logic and call processing.They are: Service, Service Component,
Log, Charge, Authentication, User Interaction, Resource Management, Data
Management, Address Translation, CallControl and ConnectionControl.
© 1999 EURESCOM Participants in Project P809-GI
page 13 (36)
Volume 1: IN architecture for the benchmark services
3.2.3
Deliverable 2
Meet-me broadband video conference service
The DFP architecture for the meet-me conference service was derived from the GFP
architecture. There are five main packages (Figure 3.4).
M M C o n fA pp l i_
Q u e u e M g r_ p k g
pk g
C o n n e c t io n
S e rve r_ p k g
P ro file M g r_ p k g
C h a rg e M g r_ p k g
Figure 3.4: Global package diagram
Each package is described in a class diagram. An example is shown in Figure 3.5, the
class diagram of the ProfileMgr_pkg package.
page 14 (36)
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2
Volume 1: IN architecture for the benchmark services
Figure 3.5: Class diagram of ProfileMgr_pkg package
In the diagram, the interactions related to mobility appear as methods and the
information as attributes.
The IMT2000 functional architecture appears to comply with the mobility
requirements. However, the home network must know the exact location of functions
in the visited network. This has confidentiality implications.
3.2.4
Broadband Virtual Private Network service
In the B-VPN model the object classes needed to provide B-VPN in a mobile context
are grouped into three packages:
Interface components containing classes for interaction with the actors external to the
IN-system.
Service operation components containing classes for the service provision control.
Information components containing classes with information on the service elements
and external actors.
© 1999 EURESCOM Participants in Project P809-GI
page 15 (36)
Volume 1: IN architecture for the benchmark services
Deliverable 2
The operations related to mobility aspects are defined as procedures. UML use cases
were used to specify these procedures:

User registration / de-registration

Terminal registration / de-registration

Service configuration / activation

Service invocation / termination
The set of GFP functions are mapped to the INCM DFP.
The IN B-VPN DFP model is based on the following assumptions:
3.2.5

The reference architecture of the network is IMT2000.

The core network is B-ISDN with IN-support.

The DFP model includes only the functions that are derived from the mobility
aspects in the GFP model.
Mobility requirements of IN/ B-ISDN for multimedia service support
The following requirements are identified:

Support of the full range of connection types: point–to-point, point–to–
multipoint, multicast, broadcast

Support of a large range of QoS attributes: delay, delay variation, maximum
delay, maximum and minimum error rate, etc.

Information transfer rate attributes: peak bit rate, minimum bit rate, etc.

Bearer service attributes negotiation/re-negotiation

Basic transport capabilities (ATM, AALs)

Call control capabilities for end to end user connection establishment, extended
to support Mobile Call Handling

Call-unrelated information transport capabilities

Connection control capabilities supporting handover and macrodiversity, based
on mobility services added to B-ISDN

Mobility procedures (location management, handover, etc.) should not be visible
to the subscriber during active call

Provide billing and charging capabilities

Integration with IN-CS3 mobility functions provisioning

Mobility service provisioning on top of basic transport capabilities for location
management

User and terminal profile support

Security management

Service mobility

Global roaming.
page 16 (36)
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2
4
Volume 1: IN architecture for the benchmark services
Mobility in IP-based networks
This chapter examines the architectures needed to provide packet services (IP over
ATM) in a mobile environment with an adequate quality of service (QoS). It is
possible to have both B-ISDN and native IP on top of the same ATM switching fabric.
The support of both packet switched and connection oriented services on the same
core network is an extension of the GMM concept. Appropriate extensions of the
WATM architecture are proposed.
Two approaches are presented here. The first one uses an IP-switching technology
and/or the RSVP protocol. The feasibility of this approach has recently been
questioned. A similar approach could be based on the Multi Protocol Label Switching
(MPLS) technology developed by the IETF or on Cisco TAG switching. These
approaches require the devlopment of ATM switches with extended capabilities to
support IP traffic, or modifications to existing ATM switches.
The second approach is based on routers, gateways and tunnelling. Best effort
packets are carried on permanent virtual connections (PVC) between the gateways.
Switched virtual connections should be established for quality of service aware IP
traffic. The advantages of this second approach are that no modifications or
extensions to the ATM switches are needed and that IP traffic with different QoS
requirements can be transmitted using the UNI signalling protocol.
4.1
IP/ATM architecture based on IP switching or the RSVP
This architecture replaces connection oriented ATM signalling with IP protocols.
However, it still uses the fixed ATM and the WATM radio interface for the transport
of both IP data packets and control data. The UMTS Iu-interface is likely to be based
on ATM transportation and this should make it easier to connect the dual-mode
WATM access network to both IP and ATM core networks. The IP and ATM core
networks could also be implemented in the same physical devices (on top of an ATM
switch). The construction of dual-mode terminals and access networks
(connection/packet oriented) should be feasible, as the WATM hardware
infrastructure can be used for both modes (radio parts, fixed transmission links and
switching fabrics).
A similar approach has been proposed in which the WAND Wireless ATM system is
modified to provide an efficient wireless access to the Internet backbone over the
5GHz WAND radio link. The reference architecture, shown in Figure 4.1, is in line
with the ATM Forum functional architecture (ATMF/98-0402) and the ETSI BRAN
model. The additional entities are shaded. The BRAN HIPERLAN/2 is a natural
selection for the radio interface, as it is also the principal WATM radio interface of
the ATM forum.
© 1999 EURESCOM Participants in Project P809-GI
page 17 (36)
Volume 1: IN architecture for the benchmark services
Mobile Terminal
Access
Point
APCP
RRM
APCP
ATM
HIPERLAN
5 GHz Radio
RSVP
Control
TCP/UDP
Convergence
layer
HIPERLAN
5 GHz Radio
TCP
IP
ATM
SDH
MM = Mobility Management
RRM = Radio Resource Management
RSVP
IP
IP
ATM
ATM
SDH
Control
IFMP
IFMP
IFMP
IP
MM
MM
TCP/UDP
TCP/UDP
RSVP
EMAS
EMAS
MM
Control
Deliverable 2
SDH
SDH
SDH
APCP = Access Point Control Protocol
SDH = Synchronous Digital Hierarchy
Figure 4.1: Wireless broadband IP access system architecture
The ATM switching in the network is controlled with the Ipsilon Flow Management
Protocol (IFMP). The IP packets are first transmitted as best-effort data, i.e., the
packets are routed at the OSI layer 3 based on the destination address. When the
EMAS detects an IP packet flow, it creates an ATM connection for the IP packets
belonging to the flow1. In this way the IP routing is by-passed and the packets are
switched at the OSI layer 2. Note that no connection set-up is needed prior to the
transmission of data-packets but a traffic flow can still be end-to-end switched at the
OSI layer 2.
When the EMAS adjacent to the radio interface detects an IP-flow, it establishes an
ATM connection (virtual channel) over the radio interface using the call control
protocols of the WATM radio interface. If IFMP is not available, the RSVP messages
can be used to establish these connections. The RSVP is used to indicate the required
bandwidth and delay characteristics. On the other hand, the ATM QoS parameters
could also be derived from the IP traffic classes of the ‘differentiated services’ QoS
approach. This allows the mapping of IP QoS parameters to the radio link without
modifying the WATM radio interface. The radio link schedules the traffic based on
the ATM QoS parameters and so the prioritisation of IP data flows can be achieved
over the radio interface.
The feasibility of the Ipsilon concept has recently being questioned. It is suggested
that the establishment of the radio interface connections should be based on the
RSVP, not the IFMP. A similar approach to the one presented above could also be
based on the Multi Protocol Label Switching (MPLS) technology developed by the
IETF, or the Cisco TAG-switching, which can be considered to be an implementation
of the MPLS.
4.2
IP/ATM architecture based on gateways and tunnelling
The approach presented above requires ATM switches with extended capabilities to
support IP-traffic. This is acceptable if widescale usage of (mobile) IP applications is
1
The packets can be identified using the flow labels they carry.
page 18 (36)
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2
Volume 1: IN architecture for the benchmark services
assumed2. It is not feasible to modify existing ATM core network switches.
Manufacturers are also reluctant to modify their ATM products, especially as there
are no generally accepted standards for IP extended ATM switches. Thus, an
approach without new switch requirements would be very beneficial in many cases.
One such approach is presented here.
The end-to-end IP connection is divided into two parts; a native IP access part and a
B-ISDN (ATM) core network part. The functionality required to support the transport
of QoS aware IP traffic over the B-ISDN core network is implemented on a gateway
connecting the IP-access part to the B-ISDN network. The gateway is connected on
one side to an IP router or terminal and, on the other, to an ATM switch. Any type of
IP access can be used between the terminal and the gateway3. The gateway tunnels IP
packets to other gateways using the switched connections of the B-ISDN. An example
is shown in Figure 4.2.
Intranet access
Fixed
Terminal
P-NNI/
B-ISUP
Gateway
Router
IP radio access
B-ISDN
UNI
Router
P-NNI/
B-ISUP
Gateway
Access
Point
Mobile
Terminal
UNI
P-NNI/
B-ISUP
IP-Routing
IP-Routing
IP-Routing
Figure 4.2:
IP-Routing
IP traffic tunnelled through B-ISDN core network
The different gateways are connected to each other using permanent virtual channels
(PVCs). These PVCs carry the best effort IP-packets sent between the IP-networks.
Switched virtual connections could be established to support QoS-aware IP traffic.
The connections would be triggered by the RSVP protocol and the ATM QoS
parameters for these connections would be derived from the QoS parameters carried
by the RSVP. To establish these connections, the gateway needs to convert IP-routing
information to the B-ISDN (E.164) address of the ‘target’ gateway and then set up the
connection with ATM UNI signalling protocols (UNI 4.0 or Q.2931).
The differentiated IP services approach could be supported by mapping the different
IP service classes to separate PVCs with traffic contracts matching the requirements
of the specific IP service classes. The ATM adaptation layer 5 (AAL 5) could be run
over the virtual connections to ensure reliable packet transmission over the B-ISDN
network (i.e. through the tunnel).
This approach has some similarities to the MPLS. The major difference is that the
management of the ATM connections for the transportation of IP traffic is not
integrated to the ATM switches but implemented in a separate gateway (server) which
uses UNI signalling to manage the ATM connections.
2
Also the wireless ATM framework requires modifications to the ATM standards.
3
Radio LANs, Hiperlan, GPRS or URAN for radio access. Ethernet and IP-routers for
fixed intranet access. LAN emulation, Classical IP or MPOA for IP over ATM access.
© 1999 EURESCOM Participants in Project P809-GI
page 19 (36)
Volume 1: IN architecture for the benchmark services
4.3
Deliverable 2
Mobility management
In a mobile system where IP-addresses are used for routing, the effects of mobility
will be seen at different levels; mobility inside an access network4, between different
access networks and between different networks. For mobility inside an access
network, the WATM radio access mobility schemes can be used because handovers,
addressing issues and radio resource management, are similar for packet and
connection oriented services as long as the ‘serving’ EMAS is not changed. However,
the implementation of inter-access network mobility for a packet switched network
differs from connection oriented networks (e.g. routing vs. switching, different
connection control and connection admission control).
The Mobile-IP protocol or the IPv6 mobility functions can be used to route IP-packets
between different EMASs. The IPv6 includes automatic address configuration, useful
for mobile terminals. The EMASs would provide the Dynamic Host Configuration
Protocol (DHCPv6) functionality, home agent services and the mobile terminal
location management database.
The IP mobility functions lack many which are vital to public mobile systems. These
functions include charging, access control, terminal authentication and service profile
management. These services can be implemented with IN, especially as the IN can be
assumed to be available at the node for both service creation and mobility
management for the connection oriented mobile services. In the case of IP, the IN
would not be used for service creation but only for mobility management. This is very
similar to the way CTM is used to introduce mobility to the narrowband ISDN. IN
mobility management is a natural choice for the dual node core network.
4.4
The IP QoS chain
The ‘best effort’ service currently supported by the IP may suffice for many nonrealtime services but, for sophisticated IP multimedia services, some IP QoS concept
is required. The IP can operate over many transmission media and thus many different
QoS applications will co-exist on a single route. The IP QoS concept should be able to
use the QoS attributes of the underlying transmission media to create an end-to-end
stand-alone QoS concept at the IP level. Currently, the Internet Engineering Task
Force (IETF) has two approaches to IP QoS; Integrated Services and Differentiated
Services.
4.4.1
Integrated services (RSVP)
With integrated services, an application explicitly indicates its traffic characteristics
to the network. In practice, the information is signalled and the resources reserved
with a protocol called RSVP. The resources can include buffer space and scheduling
time. Each router on an RSVP connection stores the information on traffic
characteristics and reserved resources for the connection. The resulting state-machine
is ‘soft’ as data packets can be routed also in the Idle-state (as best effort data) and the
return from the Active-state to the Idle-state is done with a timer. This simple state
management was chosen to increase the scalability of the protocol and to make it fault
4
It is considered that the access points (base stations) connected to a single EMAS
make up an access network. Thus, mobility between access networks is characterised by the
change of the ‘serving’ EMAS.
page 20 (36)
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2
Volume 1: IN architecture for the benchmark services
tolerant. However, scalability is a major problem for the RSVP (as it is for all statebased systems).
QoS mapping standards between the RSVP and ATM Forum UNI are being prepared
by the IETF. These standards will allow the use of RSVP. The tunnelling of the IP
packets through an ATM wide-area network should remedy the scalability problems
of the RSVP.
4.4.2
Differentiated services
The differentiated services approach uses IP header bits to differentiate between QoS
classes. The QoS class field of IPv6 can be used to indicate how delay and packet loss
tolerant the traffic is. The packets carrying different values in their QoS class fields
will be placed in separate queues. The network operator can dynamically define the
amount of buffer space and the scheduling priorities for each queue, thus controlling
the delay and loss probability which the packets experience.
The major advantage of this approach is that no signalling is needed and the inherited
scalability of IP is preserved. On the other hand, the differentiated services approach
is likely to require much network monitoring and maintenance if it is to work
effectively. It is possible to use RSVP and differentiated services simultaneously.
4.4.3
Other QoS solutions
Many technologies improve QoS. IP-switching technologies can bypass the IP-routing
with ATM switching (the routing is typically a bottleneck and it reduces the QoS). A
reliable and fair charging mechanism would improve the QoS of users by limiting the
generated traffic and allowing the operators to invest more on the network. (The
customers using the capacity will pay for it). There are also several IP-routing
protocols which improve QoS by taking the QoS requirements into account when the
routing decisions are made. The term ‘QoS routing’ covers these protocols.
© 1999 EURESCOM Participants in Project P809-GI
page 21 (36)
Volume 1: IN architecture for the benchmark services
page 22 (36)
Deliverable 2
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2
5
Volume 1: IN architecture for the benchmark services
Terminal requirements for broadband mobile multimedia
services
Terminals will play a major role in the introduction of broadband mobile multimedia
services. This chapter addresses mobile terminal development in relation to services
such as Video Conference, Video On Demand and enhanced WWW.
Mobile handset technology will have a profound impact on overall network
architecture. Technologies such as WAP and the SIM Application Toolkit, which
facititate the development of new mobile telecommunication networks, will impact on
the overall network infrastructure. They will require additional transport bearer
capabilities and additional ad-hoc nodes (e.g. WAP proxy). They will also make new
demands on terminals, including those providing users with multimedia services.
This chapter includes a complete list of requirements for the provision of broadband
multimedia services using mobile handsets. The most innovative capabilities, such as
over-the-air download mechanisms and support of multiple access modes, are
examined. Security issues are investigated.
5.1
Overview
A mandatory set of general-purpose requirements for UMTS terminals has been
proposed (SMG1 UMTS 22.07). However, the proposed set of capabilities needs to be
extended to cater for broadband mobility. Features relating to IC cards, applications
and mobility have been identified.
Features related to the use of IC cards:

Physical and functional interface between the terminal and the IC card.

Mechanisms to download information (such as data, scripts, software and new
API) into the terminal SMG1 UMTS 22.07).

Security for downloadable data and applications.

Standardized execution environment for downloadable services (e.g. MexE, SIM
Application Toolkit) .
Features related to applications:

Identification of the terminal capabilities (speech codec, display type, radio
capabilities, etc.).

VHE (SMG1 UMTS 22.07).

External standardized functional interface, e.g. API (SMG1 UMTS 22.07).

Availability of specific applications on the terminal, e.g. micro-browsers
(conforming to WAP architecture).

Capability to interface with specific devices, eventually integrated with the
terminal e.g. video cameras for the Broadband Video Conference service or
monitors for VoD.

Mechanisms to encode/decode video/audio streams, e.g. MPEG for video
streams.
© 1999 EURESCOM Participants in Project P809-GI
page 23 (36)
Volume 1: IN architecture for the benchmark services
Deliverable 2

Intramedia and/or intermedia synchronization of the various media streams in
order to provide a proper presentation of the multimedia information (see SMG1
UMTS 22.60).

Standardized API to interact with the terminal, e.g. SIM Application Toolkit.

Unicode.
Features related to mobility:

Registration/deregistration to SP and NO.

Location update.

Connection oriented or connectionless services.

Unalterable equipment identification.

Emergency calls even without a USIM.

Authentication and encryption mechanisms.

Handover for multimedia and Internet/Intranet services (SMG1 UMTS 22.60).

Different access modes, e.g. DECT, GSM-900/1800, GPRS-900/1800, UMTS
FDD/TDD CDMA .
All these requirements are needed for broadband multimedia services. However, only
some of these features depend on the specific broadband multimedia service for their
provision. These are:

Availability of specific applications on the terminal.

Capability to interface with specific devices.

Support of mechanisms to encode/decode video/audio streams.

Support of techniques for synchronization of media streams.
Each service can be associated with a set of applications which must be present on the
terminal in order to make the service itself available to users. The table below shows a
possible mapping of service-to-applications for the benchmark services.
Service
Application
Enhanced WWW
Web browser
Multimedia Messaging
Mail client
Broadband Video Conference Client application for management and monitoring of
video conferences
Video on Demand
Client application for video selection and image
handling
Distributed TV
Client application for channel management and image
vision
Broadband
Network
Virtual
Private Various applications, such as users directories or
phonebooks
Table 5.1 - Mapping services-to-applications
page 24 (36)
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2
Volume 1: IN architecture for the benchmark services
It is essential that services which require high-quality audio and video capability (e.g.
video conference, DTV or VoD) can interface with a range of devices. They will be
integrated with the terminals themselves, eventually. Users should be able to direct
the output to monitors, VCRs or other similar devices.
The support of mechanisms to encode/decode video/audio streams is important for
services which require the transfer of audio/video information to or from terminals.
VPN is the only benchmark service which does not need such a feature.
Finally, techniques for synchronization of media streams are needed for services
which require the simultaneous presentation of many audio/video data streams. This
involves all the benchmark services.
All the remaining features are related to a particular service. So, all the requirements
presented in this chapter are necessary for broadband multimedia services. The only
exception is the support of Unicode, which is optional.
5.2
Application domain considerations for 3G terminals
The concept of the ‘application domain’ appears in the ETSI Program Advisory
Committee EG5 Global Multimedia Mobility report (PAC EG5). Figure 5.1 shows an
overall framework containing application client/servers, terminal equipment, access
and core networks.The following points are noted:
1.
Interaction between a 3G application client and 3G terminal equipment is based
on a 3G Client-API.
2.
Interaction between a 3G application server and a core network is based on a 3G
Server-API.
3.
Interaction between a 3G application server and an access network is based on a
3G Server-API.
Figure 5.2 illustrates applications and services in the mobile terminal and the
User/Subscriber Identification Module (USIM). The following 3G client-API
requirements are identified:
1.
The 3G Client-API should enable the application client to access parameters and
information handled in the terminal. This includes terminal location, QoS and
bandwidth parameters, advice of charge information and parameters for error
handling.
2.
The 3G Client-API should support notification and confirmation requests from
the terminal to the application client. This includes notifications regarding
bandwidth re-negotiations and modifications, requests for confirmation of renegotiated or modified bandwidth, requests for confirmation of new charging
tariffs, for changing service domains or network operators and notification of
errors.
3.
The 3G Client-API should support instructions from the application client to the
terminal. This includes instructions for service profile modifications, for setup
and release of real-time connections and data connections, for answering calls,
for sending mail (point-to-point or point-to-multipoint) and for modification of
the terminal session management parameters.
© 1999 EURESCOM Participants in Project P809-GI
page 25 (36)
Volume 1: IN architecture for the benchmark services
Deliverable 2
4.
The 3G Client-API should enable the application client to access information on
the USIM in the terminal. This includes user information, mobility and security
information.
5.
The 3G Client-API should enable the terminal to access information on the
USIM (USIM handled by the application domain). This includes user, mobility
and security information.
6.
The 3G Client-API should support transport of authentication information from
the USIM to the network and from the network to the USIM.
Application
Client
Application
Server
Application
Server
Application
Domain
3G Server API
3G Client API
Terminal
Access
Equipment Networks
Core
Networks
Figure 5.1: Application domain APIs
User
USIM/IC-Card
Terminal
Network
- MMI -
...
Mob. Security SS
...
Applications &
Services
Speech
Fax
API
Appl.
Video
Audio
Data
Basic UMTS
Terminal/USIM
Features & Services
Domain
Appl.
SMS
Appl.
Terminal/USIM
Application
Domain
Network API
Basic UMTS
Control &
Transport
Network Capabilities
Service Capabilities
Bearer Capabilities)
Figure 5.2: Applications and services in the mobile terminal / USIM
page 26 (36)
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2
5.3
Volume 1: IN architecture for the benchmark services
Mechanisms to download information to the terminal
Most technology used at present to download data involves protocols such as FTP,
HTTP, which are linked to the TCP/IP protocol. Some mobile network providers have
suggested that data could be downloaded using the short message service/smart
message service.
A client/server architecture is assumed here. The resources are distributed throughout
the network and the terminal (fixed or mobile) acts as a client seeking these resources.
5.3.1
Mobile terminal requirements
The main requirements are to:

Integrate a browser in the terminal and use one of the existing protocols (via
SMS, FTP, HTTP etc.).

Integrate a new protocol interpreter in the terminal.
In this case, the terminal (via the protocol interpreter), in interactive mode, should be
able to:
- open a connection
- make a request (download request) towards a server
- get a response from the server
- close the connection.
In such an environment, each connection could consist of a single transaction with
each connection independent of previous ones.

Integrate a standardized Open API or a JVM (Java Virtual Machine) in the
terminal to support different interfaces (e.g. home networking - exchange control
data with coffee machines, lights, burglar alarms).
In a mobile environment, attention must be paid to the changing radio environment,
handover and service disruption. A large memory cache is needed in the terminal, e.g.
to read newspapers without interruptions from changes in the radio environment. The
newspaper could be downloaded beforehand, using the spare capacity of the network
when utilization is low.
5.3.2
Security aspects
There are security risks to servers, to the local area nodes which host servers and to
users of the servers.
Security precautions shall cover confidentiality (prevent unauthorized access),
integrity (no modification of existing information), availability (guaranteed access),
legitimacy (authorized entities) and accountabilities (entities held responsible).
Two main procedures can be identified:
Authentication not required
© 1999 EURESCOM Participants in Project P809-GI
page 27 (36)
Volume 1: IN architecture for the benchmark services
Deliverable 2
The terminal acts as an anonymous user to access and download data. A policy is
required to identify responsibilities in case of misuse.
Authentication required
In case authentication is required, it can refer to the user, the terminal or both. Mutual
authentication between all parties involved in a transaction is also possible.
Access priorities: Proper mechanisms must be defined in order to check whether the
terminal/user is allowed to access the data and, eventually, what it is allowed to do
(different groups may be granted different levels of access). Procedures for
granting/revoking access to the system must be also implemented. Different log-in
(remote/local) methods shall be provided.
Ciphering: Transfer of encrypted objects shall be supported.
Different security policies or mechanisms may be supported. Recovering procedures
from virus attacks need also to be provided.
5.4
Possible mechanisms for VHE
Several solutions can be identified. They differ as to the location of service execution
(service control); service execution in the home network, in the USIM, in the mobile
equipment or in the serving network. The second and third of these are considered
here. They could be fulfilled using GSM toolkits (e.g. CAMEL, SIM-Toolkit, MexE)
and new techniques. The architecture model is used for different scenarios.
5.4.1
Service execution within the UMTS Subscriber Identity Module
Support of VHE can be realised by the exchange of service related data or service
logic from the home network to the USIM. The software is then executed on the ICCard. Remote Programming, (enhanced) SIM-toolkit or JavaCard offer possible
solutions.
Requirements: A secure and standardized execution environment and API within the
USIM is needed. This requirement leads to an open USIM operating system. An
electronic certification process with hash algorithms or encryption techniques can be
used to guarantee the source and quality of the downloaded software. The copyright
problem must be solved.
Uses: This mechanism can be used for personalised MMI for operator specific
services, banking applications or the update of subscriber data.
page 28 (36)
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2
Volume 1: IN architecture for the benchmark services
DATterm
MMIC
DATserv
DAThome
PRGserv
PRGterm
PRGhome
EXEterm
EXEserv
EXEhome
CoCterm
CoCserv
CoChome
Serving Netw ork
Home Netw ork
DATUSIM
PRGUSIM
Mobile Equipment
EXEUSIM
USIM
DAT : Service-Profile/Data
PRG: Service Program
EXE: Service Execution Environment
CoC:
Communication Control
MMIC : MMI Control
Figure 5.3: Case 2, service execution in the USIM
The case of the SIM-toolkit is covered by the capability of the USIM to store service
data and programs as well as to provide an execution environment which interacts
with the mobile terminal.
5.4.2
Service execution within the mobile equipment
As with the USIM mechanism, a download of software into the mobile equipment can
support VHE. A distinction between two execution environments with different levels
of security is useful: one for the UMTS service provider with larger functionality
range and one for value added service providers (VASP) with less functionality but
higher security. Functionality and security refer to the UMTS network and should not
limit the range of services of the VASP. Remote Programming, Mobile Station
Execution Environment (MExE), Wireless Application Protocol (WAP) and Suns
Java-Technology offer possible solutions.
Requirements: As with the USIM, a secure and standardized execution environment
and API within the terminal is needed. This requirement leads to an open terminal
operating system. As with the USIM requirements, an electronic certification process,
with hash algorithms or encryption techniques, can be used to guarantee the source
and quality of the downloaded software. However, the copyright issue must to be
addressed. One new aspect has to be considered. ME software could operate with a
specific USIM, enabling adaptation and personalization of ME functions which are
related to a specific subscription and not available for another one.
Uses: Codec update, firmware update, download of announcements, enhancements of
applications in general.
© 1999 EURESCOM Participants in Project P809-GI
page 29 (36)
Volume 1: IN architecture for the benchmark services
DATterm
MMIC
Deliverable 2
DATserv
DAThome
PRGserv
PRGterm
PRGhome
EXEterm
EXEserv
EXEhome
CoCterm
CoCserv
CoChome
Serving Netw ork
Home Netw ork
DATUSIM
PRGUSIM
Mobile Equipment
EXEUSIM
USIM
DAT : Service-Profile/Data
PRG: Service Program
EXE: Service Execution Environment
CoC:
Communication Control
MMIC : MMI Control
Figure 5.4: Case 3, service execution in the mobile equipment
The case of a mobile station execution environment is covered as follows: The
execution environment in the terminal uses service programs and user specific data
provided by the ME or the USIM to interact with the communication control and
MMI control. The service program and data may have been downloaded from the
home, or even the serving, network.
5.5
Multi-mode terminals
UMTS will be introduced as the ‘European’ ETSI family member of IMT-2000. In the
early phases, where limited radio coverage is provided for UMTS, it will rely on GSM
for wide area coverage. Seamless handover between GSM/GPRS and UMTS is a
requirement. UMTS may evolve from 2nd generation GSM and terminals will need to
support both GSM and UMTS.
GPRS is being introduced as an overlay packet service using GSM mobility
management. GPRS-only terminals may be produced. However, to integrate GSM
GPRS and UMTS subscriptions into a single terminal, GPRS mode needs to be
included.
Dual mode GSM/DECT terminals are becoming available and supported by PNOs to
integrate residential and business access with wide-area cellular systems. DECT
should be considered as another option for the terminal. ETSI EP DECT has proposed
to ITU- R that DECT be an IMT-2000 family member. This strengthens the argument
for inclusion of DECT in future terminals.
The following modes, therefore, need to be supported:

DECT - 1800

GSM – 900

GSM – 1800

GPRS – 900

GPRS – 1800
page 30 (36)
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2

UMTS FDD CDMA

UMTS TDD CDMA
Volume 1: IN architecture for the benchmark services
For seamless operation, all modes need to be operational simultaneously.
5.6
Handover management
Mobility management procedures for the terminal are associated with the movement
of the UIM contained in the terminal and not on the active user services. For
GSD/GPRS, there is a single handover between base-stations even though two
different bearers are involved. These principles can be extended to cover broadband
multimedia with minimal adaptation.
Handover may be implemented seamlessly depending on the mechanisms involved.
For connection-less packet traffic, end-end control of the packet flow (buffering,
retransmission of packets etc.) may provide seamless operation. For real-time services
on connection orientated bearers, a minimal disturbance strategy may be adopted.
Network initiated handover: In the case of a well structured topology for an access
network, e.g. GSM cellular, the network will be aware of terminals moving from the
radio coverage of one cell to an adjacent cell. Handover is initiated by the network
making a connection to the new base-station and disconnecting from the old basestation. Identification of component legs of the call is managed by the MSC.
Terminal initiated handover: In the case of DECT, an intelligent radio access
technology, the terminal is aware of potential serving base-stations. When certain
criteria have been met, the terminal signals to the ‘new’ base-station requesting a
handover. If the base-stations are interconnected, e.g. within a cluster controller, the
handover procedure is constrained to that level and even the switch may not be
involved. However, for cases of intra-switch, inter-switch and inter-network, the core
network is involved.
© 1999 EURESCOM Participants in Project P809-GI
page 31 (36)
Volume 1: IN architecture for the benchmark services
page 32 (36)
Deliverable 2
© 1999 EURESCOM Participants in Project P809-GI
Deliverable 2
6
Volume 1: IN architecture for the benchmark services
Impact of mobility on network interfaces and protocols
This chapter identifies the open interfaces required for 3G mobile systems.
Requirements on protocols at each interface are determined in terms of mobility
management and service support, and are provided in an associated appendix.
Specifically, enhancements to the MAP protocol which are desirable for mobile
multimedia support are identified together with protocol requirements for B-VPN
(also termed ‘Virtual Home Environment’ in the mobile context).
MAP protocol enhancements in the evolved GSM core network will be specified by
3GPP at a series of planned meetings throughout 1999. Meetings are collocated with
ETSI SMG to ensure common GSM/UMTS core network specifications. 3GPP has the
mandate to prepare, approve and maintain globally applicable technical
specifications for the 3rd Generation mobile system based on evolved GSM core
networks.
At the end of May 1999, there were 347 members of the GSM MoU Association, with
operators providing GSM services to more than 160 million customers—equivalent to
65% of the world's total market for digital wireless communications. There were 323
GSM networks operating commercial services in 133 countries and areas. Recently,
major satellite operators (ACeS, Globalstar, ICO, Iridium) have adopted the GSM
Platform with MAP protocol support. To date, all licensed 3G operators have joined
the GSM Association and 3G systems will be an integral part of the Global System for
Mobile communications (GSM). The GSM platform will provide world-wide
multimedia service support made possible by the MAP protocol.
6.1
Interfaces identified for mobility support
Figure 6.1 gives a functional perspective of the third generation core network
proposed by the GSM MoU Association. The proposed standardised open interfaces
are described in Table 6.1.
Subscription Data
Function
Mobility Function
4
X
Home MM
Function
5
Services
Function
6
3
7
2
UTRAN or
other access
networks
Transport Function
8
1
Similar/other
Core Networks
Figure 6.1: 3G functional core network architecture
© 1999 EURESCOM Participants in Project P809-GI
page 33 (36)
Volume 1: IN architecture for the benchmark services
Deliverable 2
Identifier
Description
Interface 1
Access - core network interface.
Interface 2
Interface between the serving transport function and serving mobility
function.
Interface 3
This interface provides the capability
customised/operator specific services.
Interface 4
This interface may be used to support location dependent services.
Interface 5
The serving mobility function uses this interface to update the home
mobility management function/subscriber database. The subscriber database
needs this information to ensure that incoming calls are delivered to the
appropriate network.
Interface 7
This interface is used between the transport function and the subscriber
database for the retrieval of routing information for incoming calls.
Interface 8
Network interface.
to
support
VHE
Table 6.1: Standardised open interfaces proposed by GSM Association
6.2
Protocol Aspects
The support of mobile multimedia services and B-VPN (Virtual Home Environment)
necessitates new information elements and messages.
More information on protocols at each interface may be obtained on request from
EURESCOM.
page 34 (36)
© 1999 EURESCOM Participants in Project P809-GI
and
Deliverable 2
7
Volume 1: IN architecture for the benchmark services
Conclusions
The main conclusion drawn from these studies are:
a)
SIBs should no longer be used to build the service creation environment. Instead,
new Object Oriented techniques should be adopted.
b)
Object orientation and distributed processing techniques can be used to provide
broadband multimedia services in a mobile environment. The required IN
functionality has been identified and several ‘benchmark’ services were modelled
as examples.
c)
Object orientation techniques enabled the services to be modelled on the Global
and Distributed Functional Planes. Traditional IN functional entity actions can be
mapped to object oriented operations. The messages between objects in different
functional entities can correspond to standard INAP information flows.
d)
Both B-ISDN and IP networks can use the same ATM switching fabric. The
support of both packet-switched and connection oriented services on the same
core network is an extension of the GMM concept.
e)
Two approaches to mobility in IP networks have been investigated. One uses the
Ipsilon IP-switching technology and/or the RSVP. The other is based on
gateways which tunnel the IP packets through the switched ATM network.
f)
Network interfaces for mobility support have been identified and examined.
These include the interfaces between the core networks of distinct mobile
operators, where each operator plays one or more UMTS roles. The interface
between the UMTS Terrestrial Radio Access Network and the core network of a
mobile operator was examined. Other interfaces within the core network of a
mobile operator are required for competitive procurement purposes.
g)
With regard to protocols, advanced service creation and support in the GSM
environment will use the CAMEL system, which is an adaptation of IN for
mobile networks.
h)
The architectural and service capabilities which 'new' terminals will need in a
mulitmedia mobile environment have been identified.
© 1999 EURESCOM Participants in Project P809-GI
page 35 (36)
Volume 1: IN architecture for the benchmark services
Deliverable 2
Referenced documents
(P809 D1) EURESCOM P809. Deliverable 1, Broadband Multimedia Requirements,
April 1998.
EURESCOM P506. Harmonisation/integration of B-ISDN and IN. Deliverables 1 &
2. August and October 1996.
EURESCOM P607. Top-down approach applied to Multi-media Services. Deliverable
1, Volume 1. September 1997.
(GMM) ETSI Program Advisory Committee Chairman's Report, GMM: Global
Multimedia Mobility A Standardisation Framework for Multimedia Mobility in the
Information Society, October '96.
(TG.21)
GSM MoU Permanent Reference Document: TG.21 V3.0.0, UMTS
Service Requirements and Concepts, January '97.
(TG.25)
GSM MoU Permanent Reference Document: TG.25 V3.0.0, UMTS
Roaming / Mobility Aspects, September '97.
SMG1 UMTS 22.07: UMTS Terminal & Smart Card Concepts. Version 3.
page 36 (36)
© 1999 EURESCOM Participants in Project P809-GI