ATM en Móviles

Project P810
Wireless ATM Access and Advanced Software

Techniques for Mobile Networks Architecture
Deliverable 1
Service requirements, state of the art and guidelines for the development
for future radio and mobile networks
Volume 2 of 2: State of the art of standardisation bodies and European
projects relevant for EURESCOM Project P810
Suggested readers:
• Managers, Strategic Planners, Researchers and Consultants Involved in the Development
of Advanced Mobile Networks
For full publication
July 1998
EURESCOM PARTICIPANTS in Project P810 are:
• BT
• TELECOM ITALIA S.p.a.
• Deutsche Telekom AG
• France Télécom
• Koninklijke PTT Nederland N.V.
• Portugal Telecom S.A.
This document contains material which is the copyright of certain EURESCOM

PARTICIPANTS, and may not be reproduced or copied without permission.
All PARTICIPANTS have agreed to full publication of this document.
The commercial use of any information contained in this document may require a
license from the proprietor of that information.
Neither the PARTICIPANTS nor EURESCOM warrant that the information
contained in the report is capable of use, or that use of the information is free from
risk, and accept no liability for loss or damage suffered by any person using this
information.
This document has been approved by EURESCOM Board of Governors for
distribution to all EURESCOM Shareholders.
 1998 EURESCOM Participants in Project P810

Deliverable 1 Volume 2: Annex
Preface
(Edited by EURESCOM Permanent Staff)
Project P810 is a 140 man-months Project running over two years. It started in
January 1998 and will finish in December 1999. There are six participating
companies in the Project: BT, Deutsche Telekom, France Télécom, CSELT and KPN
Research. CSELT is the Project Leader.
This Project is studying the applicability of Wireless ATM Access technology and
Advanced Software Techniques to mobile aspects of telecommunications networks. It
also considers how telecommunications can evolve to these future mobile systems.
This Deliverable is the first Deliverable from the Project and, as well as identifying
the state of the art of relevant work in standards, gives an initial set of service-derived
requirements and sets some targets for converging technologies in the future. From
this information it determines scenarios that will be used to focus future work of the
Project.
Deliverable 2 from the Project will be published in July 1999 and it will present
“Transport Requirements and Solutions on the Wireless Link”.
Deliverable 3 from the Project will be published in September 1999 and it will report
on “Evolution and Application of enabling Software Technologies to Mobile Network
Architectures”.
Deliverable 4 from the Project will be published in December 1999 and it will
summarise the Project results in a strategic report on “Network Architectures for
Future Wireless and Mobile Systems”.
 1998 EURESCOM Participants in Project P810 page i (x)

Volume 2: Annex Deliverable 1
page ii (x)  1998 EURESCOM Participants in Project P810

List of Authors
Sophie Aveline CNET France Telecom
DMR/SCM
38-40 rue du Général Leclerc
92131 Issy-les-Moulineaux, France
Thorsten Benkner Deutsche Telekom
AmKavalleriesand 3
D-64295 Darmstadt, Germany
P.O. Box D-64307 Darmstadt
Philippe Bertin CNET France Telecom
DMR/DDH
BP 59
35 512 Cesson Sevigne cedex
Bruno Cornaglia CSELT MR/ST
Via Reiss Romoli 274
I-10148 Torino, Italy
Guilhem Ensuque BT Laboratories
B55-131
Martlesham Heath
Ipswich IP5 3RE, United Kingdom
Maria Pia Galante CSELT MR/MA
Suzana Grujev KPN Research / STS
P.O. Box 421
2260 AK Leidschendam
The Netherlands
Willem Hollemans KPN Research / STS
P.O. Box 421
The Netherlands
 1998 EURESCOM Participants in Project P810 page iii (x)

Jean-Marc Lafond CNET France Telecom

DMR/SCM
38-40 rue du Général Leclerc
92131 Issy-les-Moulineaux, France
Joaquim Loureiro Portugal Telecom
DID/CET
Rua Eng² José Ferreira Pinto Basto
3810 Aveiro
Portugal
Thomas Magendanz GMD FOKUS
Kaiserin-Augusta-Allee 31
D-10589 Berlin, Germany
Fiona MacKenzie BT Laboratories
B55-131
Martlesham Heath
Ipswich IP5 3RE, United Kingdom
Enrico Scarrone CSELT MR/MA
Anton Verheijen KPN Research / STS
P.O. Box 421
The Netherlands
page iv (x)  1998 EURESCOM Participants in Project P810

Table of Contents
Preface............................................................................................................................. i
List of Authors ..............................................................................................................iii
Table of Contents........................................................................................................... v
Abbreviations ................................................................................................................ vi
1 Introduction................................................................................................................. 1
2 Overview of mobile and wireless networks standardisation....................................... 1
2.1 Third Generation Mobile Systems ................................................................... 1
2.1.1 UMTS (ETSI) ..................................................................................... 1
2.1.2 IMT-2000 (ITU).................................................................................. 7
2.1.3 European Projects ............................................................................. 12
2.2 Wireless ATM Systems.................................................................................. 19
2.2.1 BRAN (ETSI).................................................................................... 19
2.2.2 W-ATM (ATM Forum)..................................................................... 23
2.2.3 LMDS DAVIC .................................................................................. 24
2.2.4 European Projects ............................................................................. 26
3 Mobility in IETF ....................................................................................................... 38
3.1 IP Mobility Background ................................................................................. 39
3.2 IP version 4..................................................................................................... 40
3.3 IP version 6..................................................................................................... 40
3.4 Mobile IP........................................................................................................ 41
3.5 Mobile IP version 4 ........................................................................................ 41
3.6 Mobile IP version 6 ........................................................................................ 42
3.7 Link layer consideration................................................................................. 43
3.8 IETF Working groups..................................................................................... 45
4 Mobile Agent work ................................................................................................... 46
4.1 Basic Capabilities of Mobile Agent Platforms............................................... 47
4.2 Integrating Mobile Agent Technology and CORBA...................................... 49
 1998 EURESCOM Participants in Project P810 page v (x)

Abbreviations
AAL ATM Adaptation Layer
ABR Available Bit Rate
ABT/DT ATM Block Transfer / Delayed Transmission
ABT/IT ATM Block Transfer / Immediate Transmission
ACTS Advanced Communications Technologies and Services
APCP Access Point Control Protocol
ARQ Automatic Repeat reQuest
ASN.1 Abstract Syntax Notation .1
ATC ATM Transfer Capability
ATDD Adaptive TDD
ATDMA Advanced Time Division Multiple Access
ATM Asynchronous Transfer Mode
AWA Atm Wireless Access
AWACS Atm Wireless Access Communication System
B-ISDN Broadband Integrated Services Digital Network
BRAN Broadband Radio Access network
BSC Base Station Controller
BTS Base Transceiver Station
CAC Call Admission Control
CBR Constant Bit Rate
CC Call Control
CDMA Coded Division Multiple Access
CDV Cell Delay Variation
CER Cell Error Ratio
CES Circuit Emulation Service
CLP Cell Loss Priority
CLR Cell Loss Ratio
CMR Cell Misinsertion Rate
CoA Care-of Address (in Mobile IP)
CODIT COde DIvision Testbed
COFDM Coded OFDM
CORBA Common Object Request Broker Architecture
CSS Cell Site Switch
page vi (x)  1998 EURESCOM Participants in Project P810

CTD Cell Transfer Delay

DAE Distributed Agent Environment
DAVIC Digital Audio VIsual Council
DECT ETSI TDMA standard for Digital Enhanced Cordless Telephone
DBR Deterministic Bit Rate
DLC Data Link Connection
DPE Distributed Processing Environment
DQPSK Differential Quadrature Phase shift Keying
EMAS- E End-user Mobility-supporting ATM Switch - Entry
EMAS-N End-user Mobility-supporting ATM Switch - Network
ETSI European Telecommunications Standards Institute
FDD Frequency Division Duplex
FDMA Frequency Division Multiple Access
FIPA Foundation for Intelligent Physical Agents
FRAMES Future Radio Wideband Multiple Access Systems
GPRS General Packet Radio Service
GRAN Generic Radio Access Network
GSM Global System for Mobile communications
Hiperlan High Performance Radio Local Area Network
HDWDM High Density Wavelength Division Multiplexing
HO Handover
IETF Internet Engineering Task Force
IN Intelligent Network
IMT International Mobile Telecommunication
IP Internet Protocol
ISDN Integrated Services Digital Network
ISP Internet Service Provider
IT Intelligent Technology
ITU International Telecommunications Union
LAN Local Area Network
LE Local Exchange
LM Location Management
LMDS Local Multipoint Distribution Services
MAC Medium Access Control
MASIF Mobile Agent System Interoperability Facility
 1998 EURESCOM Participants in Project P810 page vii (x)

M-ATM Mobile-ATM
MBS Maximum Burst Size
MCR Minimum Cell Rate
MEDIAN wireless broadband CPN/LAN for professional residential
multimedia application
MONET MObile NETwork
MPEG Motion Pictures Expert Group
MS Mobile Station
MSC Mobile Switching Centre
MSCP Mobility Service Control Point
MT Mobile terminal
NA Network Architecture
NNI Network Network Interface
NO Network Operator
NTT Nippon Telegraph and Telephone corporation
nrt-VBR non real time Variable Bit Rate
OFDM Orthogonal Frequency Division Multiplexing
OMG Object Management group
OQPSK Orthogonal QPSK
O&M Operation and Maintenance
ORB Object Request Broker
PCR Peak Cell Rate
PCS Personal Communication System
PDU Protocol Data Unit
PHS Personal Handyphone System
PIR Project Internal Result
PNNI Private Network Network Interface
PNO Public Network Operator
POTS Plain Old Telephone System
PSK Phase Shift Keying
PSTN Public Switched Telephone Network
QAM Quadrature Amplitude Modulation
QoS Quality of Service
QPSK Quadrature Phase Shift Keying
RAINBOW Radio Access INdependent Broad band On Wireless
page viii (x)  1998 EURESCOM Participants in Project P810

RAISIN RAINbow extenSion for trial INtegration

RAS Radio Access System
rt-VBR real time Variable Bit Rate
RM Resource Management
RNC Radio Network Controller
RNS Radio Network Subsystem
RTP Real Time Transport Protocol
RTCP Real Time Control Protocol
SAAL Signalling AAL
SAMBA System for Advanced Mobile Broadband Applications
SBR Statistical Bit Rate
SCCP Signalling Connection Control Part
SCR Sustainable Cell Rate
SDH Synchronous Data Hierarchy
SECBR Severely Errored Cell Block Ratio
SIM Subscriber Identity Module
SIP Session Initiation Protocol
SMG Special Mobile Group (ETSI Group)
SNL Signalling Network Layer
SRTP Selective Reliable Transmission protocol
SS7 Signalling System 7
SVC Switch Virtual Circuit
SW Software
TCP/IP Transport Control Protocol/Internet Protocol
TDD Time Division Duplex
TDMA Time Division Multiple Access
UAL UMTS Adaptation Layer
UBR Unspecified Bit Rate
UMTS Universal Mobile Telecommunication Service
UNI User Network Interface
USIM User SIM
UTRA UMTS Terrestrial Radio Access
VBR Variable Bit Rate
VHE Virtual Home Environment
WAL Wireless Access Layer
 1998 EURESCOM Participants in Project P810 page ix (x)

WAND Wireless ATM Network Demonstrator

WATM Wireless ATM
WB-CDMA Wide Band CDMA
WDM Wavelength Division Multiplexing
W-LAN Wireless LAN
page x (x)  1998 EURESCOM Participants in Project P810

1 Introduction
This appendix is a state of the art (March 1998) of standardisation bodies implied in
the evolution of the mobile systems (UMTS, IMT-2000, ETSI/BRAN, ATM Forum -
Wireless ATM group -, Software Agents, Mobile IP - IETF -, ...) and also contains
presentations of some European projects relevant to EURESCOM Project P810.
This appendix gives details on some topics that are briefly presented in the main part
of Deliverable 1.
Some EURESCOM Projects are also relevant to this Project, but they are not
presented in this document because it is simpler to find a short abstract and more
details on the EURESCOM server for example.
In order to make this appendix easy to read the references of each part are at the end
of the corresponding section and a list of abbreviations is at the beginning of the
document.
2 Overview of mobile and wireless networks

standardisation
2.1 Third Generation Mobile Systems

The 3rd generation mobile systems are being standardised at European and
International levels as the successor of the GSM and PCS systems. In parallel, lots of
European projects (ACTS and EURESCOM) are dealing with those future systems; in
this review, they will illustrate the work of the standards bodies.
2.1.1 UMTS (ETSI)
UMTS stands for Universal Mobile Telecommunications Service. It is the European

approach to Third Generation Mobile Systems. It can be seen as a ‘successor’ to GSM
and is mainly standardised by the same body as GSM: the European
Telecommunications Standards Institute (ETSI), Special Mobile Group (SMG).
The main objectives of UMTS are:
1. Integration of residential, office and cellular services into a single system and
one user equipment (terminal)
2. Speech and service quality at least comparable to current fixed networks,
including security that cannot be compromised in mobile use
3. Service capability up to multimedia
4. Separation of service provision and network operation
5. UMTS user number independent of network or service provider
6. Capacity and capability to service the whole population
7. Seamless and global radio coverage achievable
8. Radio bearer capabilities up to 2 Mbit/s
 1998 EURESCOM Participants in Project P810 page 1 (51)

9. Radio resource flexibility to multiple networks and traffic types within a

frequency band
10. High frequency spectrum efficiency
11. Creation of direct satellite access for a mass user base
12. Use of WARC ‘92 frequency bands(1885-2025 and 2110-2200 MHz)
13. Low cost of services and terminals
14. Flexible personalisation, ease of use (concept of Virtual Home Environment)
15. Flexibility for the introduction of new services and technical capabilities
16. Applicability to different needs; public, private, basic telephony for simple
telecommunications; broadband multimedia for advanced telecommunications
Within ETSI, the UMTS work is split between the following bodies:
• TC-NA: Network Aspects
• EP-SMG: Special Mobile Group
• GMM-CG: Global Multimedia Mobility Co-ordination Group. This body
provides framework documents.
Sub-Technical Committees (STCs) of direct interest to UMTS are:
• SMG1: UMTS services and service capabilities
• SMG2: UMTS Terrestrial Radio Access (UTRA)
• SMG3: UMTS network architecture
• SMG4: Data and Telematic Services
• SMG6: UMTS network management
• SMG9: UMTS SIM
• SMG10: UMTS security aspects
• SMG11: UMTS speech aspects
• SMG12: System Architecture
• PT SMG: UMTS program management support of STCs
• NA6: Evolution from fixed network to UMTS
• NA2: Service and Numbering expertise providing support to other ETSI
groups.
UMTS Standards are developed mainly by SMG but also by NA in a structure
according to Figure 1:
page 2 (51)  1998 EURESCOM Participants in P810

UMTS Services: SMG 1
UMTS Generic Radio Access: SMG 2
GSM Core Network Evolution: N/B ISDN Core Network Evolution:

SMG 3 NA6
Figure 1: Organisation of UMTS standardisation

UMTS Introduction Phases
ETSI has defined certain broad characteristics for third generation terminals and
networks. Work on the definition of UMTS has been carried out for a number of
years. Recently ETSI published its Global Multimedia Mobility (GMM) concept.
That concept makes an important contribution to the process of definition of UMTS.
A work plan has been proposed that calls for the development of two phases of
UMTS with a first phase leading to the introduction of UMTS services by 2002.
Phase 1: Operation possible in 2002
Services:
• Multimedia [144-512] kbit/s for wide area mobility, 2 Mbit/s for restricted
mobility
• High quality speech using low bitrates
• Advanced addressing mechanisms
• Virtual home environment for service creation and service portability
• Seamless indoor, outdoor and far outdoor
• Dual mode/band of operation of GSM/UMTS in one network
• Roaming between GSM and UMTS networks
Terminals:
• Dual mode/band GSM/UMTS
Access networks
• New BSS in the UMTS/FPLMTS spectrum
• Spectrum efficient
Core transport:
• Evolution from GSM and N-ISDN
• Mobile/fixed convergence elements
Timescales:
• UMTS concept: mid-98
• Regulatory framework: licensing, spectrum
• Basic parameters of the standard
• Operators’ commitment

• UMTS standards: end 99

• UMTS trials: 2001
• UMTS operation possible: 2002
Phase 2: around 2005 ?
Phase 2 involves the introduction of a UMTS Core Network (CN) and the deployment
of the full-blown architecture and set of services.
However, the exact details are still «to be determined» and this is were I think the
work of Project P810 will fit. The foreseen timescales (2005) seem unrealistic.
There is a danger that equipment manufacturers impose a lightweight UMTS Core
Network evolved from GSM and N-ISDN that might not be well-suited to support
multi-media capabilities. The issue of switch upgrade from n*64 kbps to e.g. ATM to
support the multi-media features is one of the main evolution stumbling blocks.
Starting point in 2002: UMTS Phase 1
When UMTS Phase 1 will be ready for operation in 2002 it is very likely that the
UMTS Terrestrial Radio Access Network (UTRAN) will be interconnected with the
GSM NSS. The initial deployment of UTRAN will cover isolated islands (e.g. city
centres, business areas, industrial plants …) while the overall coverage will be
provided by the GSM2+ infrastructure (GSM and GPRS). This situation is illustrated
in Figure 2 [Draft UMTS 23.20].
HLR
MAP
A
ISUP ISUP
MSC G-MSC N-ISDN
GSM BSS Gb IP IP
IP
SGSN GGSN Networks
Au
(Gbu) X.25
IWU1A IWU1Gb X.25
(IWU1) (IWU2)
UMTS Core
UTRAN Network
(Phase 2)
Iu
Figure 2: Evolution of the GSM network towards UMTS network

The Gb interface has been tailored to transparently transport IP datagrams in efficient
way to a GSM BSS and subsequently to a GSM terminal making a particular use of
the GSM air interface (GPRS).
It is possible that UTRAN, which needs to support packet-oriented services in an
efficient way, may not be easily adapted to the Gb interface. Therefore, it is envisaged
to open a new interface (Gbu) in the SGSN to allow an IP-based dialogue with the
UTRAN.
The environment for value-added and supplementary services in the phase 1 UMTS
network will consist of evolved versions of the existing GSM tools (SIM toolkit,

CAMEL, MEXE, MS API …) used in a co-operative manner (e.g. a service

implemented using CAMEL is provided with a man-machine interface implemented
using MEXE). Standardised services will be phased-out and replaced by flexible
‘toolkit’ counterparts to fit with the philosophy of UMTS and allow flexibility to the
operator.
The UTRAN consists of a set of Radio Network Subsystems connected to the Core
Network through the Iu and interconnected together through the Iur as shown in
Figure 3.
C o re N etw o rk
Iu Iu
RNS RNS
Iu r
C e lls
Figure 3: Possible UTRAN Architecture

Each RNS is responsible for the resources of its set of cells. A RNS consists of a
Radio Network Controller and one or more abstract entities currently called Node B
as shown in Figure 4. Node B are connected to the RNC through the Iub interface.
RNC
Iub Iub
Node B Node B
Cells
Figure 4: RNS Architecture

The RNC is responsible for the Handover decisions that require signalling to the User
Equipment. The RNC comprises a combining/splitting function to support macro
diversity between different Node B.
The functions and internal structure of Node B is for further studies. However, a Node
B can comprise an optional combining/splitting function to support macro diversity
inside a Node B.
The next step (UMTS Phase 2?)
In order to provide real multimedia opportunities for the UMTS customers, the UMTS
Core Network (CN) will be deployed. It will provide the separation of transport and
services. Additionally it will offer integrated service control and management by
service intelligence using developments of e.g. MAP, INAP, ISUP on the telecom side
and developments of e.g. CORBA, TINA,… on the IT side.
ATM is seen as a strong contender for the UMTS Core Network [Draft UMTS 23.30]
since it offers great flexibility to support various services (Virtual Circuits/Paths,
QoS, bandwidth reservation,…) and especially real-time services. The role of the Inter
Working Units (IWUs) adapting GSM A interface and GPRS Gb/Gbu interface to the

Iu interface would then be to provide adaptation between different transport

technologies (PCM-based voice circuits to ATM, IP to ATM).
In the UMTS Phase 2 network extensive tools will exist to create value-added and
supplementary services. It is possible that tools from information technology (e.g.
distributed computing – CORBA, Software Agents …) will make the distribution of
data and logic largely transparent from the application designer’s perspective. This
implies a blurring of the distinction between network-based and terminal-based
services. However, in the mobile wireless environment special techniques may be
required to take account of the unreliability of the radio interface and the relatively
high cost of transmission (e.g. using co-operative software agents in the BSS ??).
UMTS activities in ETSI SMG STCs
• SMG1: Services and Facilities
ETSI STC SMG 1 is responsible for the specification of services for the digital
personal communications systems, i.e. GSM 900, DCS 1800 and UMTS.
UMTS aims to standardise service capabilities and not the services themselves.
Service capabilities consist of bearers defined by QoS parameters and mechanisms
needed to realise services.
• SMG2: Radio Aspects
ETSI STC SMG 2 is responsible the physical layer of the radio interface and the study
of all radio engineering aspects of GSM 900, DCS 1800 and UMTS.
• SMG3: Network aspects for GSM
ETSI STC SMG 3 is responsible for the specification of the network aspects of
GSM 900, DCS 1800 and GPRS, including network functions and signalling.
• SMG4: Data Services
ETSI STC SMG 4 is responsible for the data and telematics services of GSM, DCS
1800 and UMTS, including the interworking with other networks.
Most of the work so far has been concerned with GSM only (HSCSD, GPRS
interworking, SMS services, GSM API …). The chairman has been pushing for
several monthes to introduce UMTS issues but with no success so far.
• SMG6: Network Management – O&M
ETSI STC SMG 6 is responsible for the network management functions and
interfaces of GSM, DCS 1800 and UMTS.
• SMG9: UIM
This STC is responsible for the specification of the Integrated Circuit (IC) card /
Mobile Equipment interface for GSM, DCS 1800 and UMTS and for monitoring
developments relating to the use of IC cards outside of ETSI.
• SMG10: Security
ETSI STC SMG 10 is responsible for all security aspects of GSM, DCS 1800 and
UMTS.

• SMG11: Speech
ETSI STC SMG 11 is responsible for the specification of speech coding and decoding
algorithms, speech related functions, the acoustical properties of terminal and speech
transmission in GSM900, DCS 1800 and UMTS.
SMG 11 current work includes:
• Adaptive Multi-Rate (AMR) Speech Codec for both GSM and UMTS
• Quality assessment of new speech codecs
• SMG12: System Architecture
ETSI STC SMG 12 is in charge of analysing the different technical solutions possible
to meet the requirements of the stage 1 in order to keep one solution, and to realise the
stage 2 which consists of distributing the functions in the network entities and of
describing the associated flows.
2.1.2 IMT-2000 (ITU)
IMT-2000 (International Mobile Telecommunication) are third generation mobile

systems being standardised by ITU-R/TG8-1 for the radio aspects and by ITU-T/SG11
for signalling and protocols.
These systems include at least a terrestrial component plus eventually a satellite one
and are scheduled to start service around the year 2002 subject to market
considerations. They may be utilised as stand alone mobile systems or as part of the
fixed network.
The IMT-2000 should conform the objectives and characteristics given bellow in
order to provide a regional and/or world-wide use with a wide range of
telecommunication services.
It has to be noted that the definition of services are lead in ITU by SG2 but SG11 has
recently entered the debate, leading to unstable situation. Moreover the work on IMT-
2000 is moving a lot and this state of art (March 98) may change considerably during
the forthcoming months.
Service features
⇒ Support of VHE
The individual wishes of each user could be met without constraining interoperability
of and roaming between networks. The concept of « Virtual Home Environment »
(VHE) has been proposed as an approach.
The VHE is a capability whereby a user is offered the same service experience in a
visited network as in his home network. The degree to which the VHE matches the
actual home environment may be subject for example to the degree of co-operation
between the visited network, to their relative technical capabilities and the
compatibility of the user terminal.
⇒ Support of Multimedia services in IMT-2000
Multimedia services combine two or more media (i.e. audio, video, graphics, etc) into
a single integrated service.

Examples of IMT-2000 multimedia services which could be supported by one or

several multimedia communication tasks:
• Mobility services (specifically related to the mobility of the user, like location
service)
• Conference services (providing bi-directional and synchronised real-time transfer
of voice and possibly moving pictures)
• Distribution services (providing continuous flow of information from a central
source)
• Retrieval and collection services (allowing to retrieve information from one or
several sources in parallel)
• Message services (offering user-to-user communications with store-and-forward
capabilities)
⇒ Principles of handling digital Data Services in IMT-2000 systems
IMT-2000 systems will support services based on data transmission in an efficient,
economical and user friendly way. The service requester will have maximum freedom
in communicating the characteristics of the requested service to the network. This
includes a combination of data service types (i.e. communication configurations -
point to point, point to multipoint or multipoint to multipoint communications-, area
selection, communication modes -connection oriented or connectionless-, bit rate -
constant, variable or asymmetric-,...) and their quality of service (QoS guaranteed/best
effort, bit rate/throughput, delay characteristics, maximum bit error rate, ...).
IMT-2000 systems will also support multiconnection ; that means the possibility to
establish several connections with different characteristics such as QoS, bit rate,...
depending on the types of the connections (voice, data, ...). For the moment this is an
option in the final text. The other option will be the possibility to establish different
types of connections with the same constraints (i.e. same level of quality for all the
connections of one user !).
⇒ Requirements on Privacy and Fraud prevention
Security mechanisms for the protection of the IMT-2000 user, service provider and
network operator should guarantee a maximum of privacy and fraud prevention, that
are at least as good as in the second generation wireless systems.
Some special security issues that arise from user/terminal mobility and inter-PLMN
roaming are:
• Confidentiality of user messages
• Privacy of user/subscriber related data
• Privacy of billing data
• Authentication of the user
These features should be fulfilled in a user friendly way or transparent to the user.
⇒ User Registration
User registration is a feature by which a user associates himself and his service profile
with the terminal for the purpose of accessing telecommunication services and by

which a network becomes aware of the existence and of the location of a terminal and
its associated user(s).
In order for an IMT-2000 user to be registered on an IMT-2000 terminal, an IC Card
associated with the user has to be present in the terminal.
⇒ IMT-2000 Emergency Call
Any IMT-2000 mobile terminal should be allowed by the network to make a call
attempt to an emergency call centre.
Network Configuration
After considerable discussion a list of interfaces has been developed which are
considered to be necessary to be identify.
These are:
• The Network to network Interface (NNI)
• The Mobile Terminal to Radio Access Network interface (MT-RAN)
• The User Identity Module to Mobile Terminal interface (UIM-MT)
For further study is the Radio Access network to Core network (RAN to CN)
Two complementary pictures are produced, one showing in Figure 5 the physical
viewpoint and the other in Figure 6 the functional viewpoint. This is done as it was
seen as essential that the radio independent protocols such as call control, application
and service control and mobility management are carried transparently from the user
agent in the terminal to the core network (other cases for further study).
Note 1: a) Functional requirements / objectives will be common among family
members.
b) Functional elements and information flows may be different among
family members.
Note 2: There may be intra-family member communication which perform similar
functionality to the NNI but this is outside the scope of the ITU.
UIM MT RAN CN CN
UIM - MT MT - RAN RAN - CN NNI

Interface Interface Interface
[UNI]
Core networks of other IMT-
2000 Family members
Figure 5 : Physical interfaces of an individual IMT-2000 family member

Core networks of other IMT-

2000 Family members
UIM MT RAN CN CN
UIM-MT MT - RAN RAN - CN CN - CN
MT - CN
UIM - CN (visited)
UIM - CN (home)
Figure 6: Functional communication of an individual IMT-2000 family member
For a given user in roaming situation, and for a typical call, the CN shown in Figure 5
interacts with at least two CNs in the ‘other CN’ families, one related to the UIM (for
authentication for example) and the other related to the other party in the call. The CN
on the left is called the ‘Serving CN’, the CN on the right is called the ‘Home CN’
and is related by subscription to the UIM, and the ‘Transit CN’, possibly another CN
on the right which provides a communication path from the Serving CN towards
another party.
Depending on the work progress, the documents Q.FIN and Q.FNA should be
finalised in May 1998, the information flows should be defined by the end of the year.
For the moment, these two documents Q.FIN and Q.FNA are not very detailed nor
clear, so they may be delayed.
Radio Interface
IMT-2000 is defined by a set of interdependent ITU Recommendations. ITU-R Task
Group 8/1 is investigating and defining the radio aspects of IMT-2000. The work will
culminate in the development of a series of recommendations that will specify the
radio interface, or interfaces, to be used by IMT-2000. It is a design objective of IMT-
2000 that the number of radio interfaces should be minimal and, if more than one
interface is required, that there should be a high degree of commonality between
them.
⇒ Time Schedule of the Radio Interface Development process
Critical milestones in the Radio Interface Development Process:
(0) Issue request for candidates RTT (Radio Transmission Technologies) March 1997
(1) ITU proposed cut off for submission of candidate RTT proposals, to June 1998
be confirmed by evaluation groups
(2) Cut off for submission of evaluation reports to ITU Sept. 1998
(3) TG 8/1 determines the key characteristics for the IMT-2000 radio March 1999
interfaces
(4) TG 8/1 completes development of radio interfaces specification Dec. 1999
recommendations (approx.)

⇒ Minimum Performance Capabilities for IMT-2000 Candidate Radio

Transmission Technologies
Task group 8/1 will consider candidate radio transmission technologies that meet the
following minimum performance capabilities in at least one test environment.
Table 1 shows the minimal requirements for the terrestrial test environments.
Test Environment Indoor Office outdoor to indoor and Vehicular
Pedestrian
Mobility consideration Mobility type : low Mobility type : medium Mobility type : high
* *
Handover Required Required Required *
Support of general Required / Not Required / Not required Required / Not

service capabilities required required
Packet data Required Required Required
Asymmetric services Required Required ** Required **
Multimedia Required Required Required
Variable bit rate Required Required Required
Data services key user bit rates user bit rates user bit rates
capabilities
BER BER BER
Circuit-switched low at least 2048 kbit/s at least 384 kbit/s *** at least 144 kbit/s
and long delay
≤ 10 -6
≤ 10 -6
≤ 10-6
Packet at least 2048 kbit/s at least 384 kbit/s *** at least 144 kbit/s
≤ 10-6 ≤ 10-6 ≤ 10-6
Table 1: Minimum performance capabilities for IMT-2000 Candidate - Radio

Transmission Technologies
* Seamless handover required within the environment
** The evaluated technologies close but not capable to meet the minimum
performance capabilities for user bit rates (not less than 64 kbit/s) will also be
considered.
*** Maximum bit rate for data is one of the important key criteria for evaluation
of IMT-2000 technologies. Some technologies will be accepted with only
144 kbit/s under constraints.
References
[1] ITU-T Draft Recommendation Q.FIN version 2.1 TD WP 3/11 MAUI-170R2, 7-
16 January 1998.
[2] ITU-T version 10.1 of Draft new Recommendation Q.FNA, Network Functional
model for IMT-2000 (previously known as FPLMTS), 7-16 January 1998.

2.1.3 European Projects
2.1.3.1 FRAMES
FRAMES (Future Radio Wideband Multiple Access Systems) is an ACTS project

created in 1995 to define a specification for a UMTS air interface, and to serve as an
input towards the Standardisation process taking the backward compatibility to 2nd
Generation systems into consideration.
Frames does not aim to create services but to define an architecture.
The project concentrates on the Radio interface definition, validation and
demonstration to meet different operating environments and wideband service needs.
The project has planed to build a pair of BS demonstrators and Mobile Terminals.
That was the main objective of the FRAMES project when it was created.
The choice of the Radio interface has already been made: finally there were two
possibilities (WCDMA and TD/CDMA) which have both been kept. Consequently,
today it is not so sure that the demonstration part of the project will be held.
⇒ Overview of the Air Interface
The Figure 7 represents the layer structure, the protocols and the algorithms (into
dotted boxes) of the radio interface of Frames.
LA Y E R 3 C ore N etw ork dependent Protocols
U M T S A daptation Layer
A dm ission Control Radio Bearer Radio Resource Inter-C ell H andover

A lgorithm Control C ontrol A lgorithm
Logical Link Control

LA Y E R 2
Radio Link Control Link A daptation

A lgorithm
MUX M edium A ccess Control Resource A llocation

A lgorithm
Physical Layer
LA Y E R 1
Figure 7: Radio interface of FRAMES

Two modes of access have been studied in the Frames project. The first one, called
FMA1 is wide-band TDMA ; the second one, FMA2, is Wide-band CDMA.
⇒ GRAN Concept
The FRAMES objective is to define a Generic Radio Access Network (GRAN) which
shall give a wideband and a narrow band radio access to the users of different,
existing and future, core networks (B-ISDN, N-ISDN, GSM, UMTS, PSTN,
Internet,...).
Concerning the architecture, the GRAN can be connected to any type of core network.
The inter-working is realised through two inter-working functions located in the fixed
part of the GRAN (IWF) and in the mobile terminal (UAL - UMTS Adaptation
Layer).

GRAN
GSM UAL1 Iu
IWF1 GSM CN
Im
Iu
USIM B-IDSN UAL2 Im IWF2 B-IDSN CN
MT RAN
Im Iu
Internet UAL3 IWF3 Internet CN
Im Iu
RAINBOW UAL4 IWF4 RAINBOW CN
Terminal
Figure 8: Inter-working of the GRAN with the cores of the networks considered
in the project Frames
Two generic interfaces are also defined in the GRAN: Iu interface in the fixed
network (official name for FRAMES and ETSI), and Im in the mobile (unofficial
name).
⇒ Layer 3
The structure of layer 3 shows the concept of generic access network well. This layer
is divided into 2 sub-layers: the protocols depending of the core network (CC, MM)
are located into the upper sub-layer and the protocols (RBC, RRC) depending of the
GRAN are in the lower sub-layer. The UAL is located between the two sub-layers and
translates the primitives used in the core network (RR in GSM for example) into
«generic» primitives.
UMTS UMTS UMTS UMTS - nwk Z Switch
MS BS RNC IWU of core nwk Z
CM X CM Y CM Z CM relay CM Z
MM X MM Y MM Z
UAL X UAL Y UAL Z
MM relay MM Z
RRC RRC RRC BC BC L3 BSS-CN Z L3 BSS-CN Z

RBC RBC RBC protocols protocols
L2 radio L2 radio L2 L2 L2 UMTS nwk Z nwk Z

lower lower lower
L1 radio L1 radio L1 L1 L1 layers layers layers
UMTS radio interface BS/RNC interface Iu interface IWU - core nwk Z

interface
GRAN dependent layer 3 protocols
CN dependent layer 3 protocols
Figure 9: Layers and protocols in the GRAN and the core network
The Radio Network Layer (RNL) contains the protocols RBC (Radio Bearer Control)
and RRC (Radio Resource Control). The bearers are created with some characteristics
as traffic charge, QoS,... as the characteristics defined in ATM.
RBC has to establish, maintain and liberate the bearers while RRC is in charge of the
handover (all bearers have to change of base stations at the same time during a
handover).

⇒ Layer 2
The function of layer 2 is to realise two types of radio bearers for layer 3 giving a
QoS: the initial radio bearer (first bearer established by the mobile terminal) and other
radio bearers (established after the initial bearer). The initial bearer is used to transmit
the RNL signalling, and if necessary the signalling for the core network. The other
bearers are used to transport user data and the signalling of the protocols which
depend on the core network the GRAN is linked with. The initial bearer has to be kept
as long as other bearers are maintained.
The setup call procedure for the first radio bearer (initial) is always initiated by the
mobile terminal (RBC) due to a paging message or due to the necessity to send a
message. This procedure is different from the procedure used to establish other radio
bearers. The call setup is sent on a common uplink channel (RACH - Random Access
Channel). Then the network gives an identity (level MAC) to the mobile terminal.
This identity is unique to each mobile terminal and is valid inside a unique cell, it will
be changed when the mobile will move into another cell.
The setup of other bearers is done through signalling of layer 3 (RBC) which is
transmitted on the initial radio bearer.
Layer 2 is composed of 2 sub-layers: LLC and RLC/MAC. The service access points
(SAP) are represented in Figure 10 by black points. The sub-layer RLC/MAC has also
an internal structure. Consequently, the Layer 2 has 3 sub-layers.
Layer 3
LLC
LLCi LLCi LLC
sublayer
MANAGEMENT
MAC
RLC RLC RLC
RLC/MAC
MAC sublayer
TCH TCH TCH RACH PCH BCCH peer-to-peer
channels
Layer 1
Figure 10: Structure of Layer 2

• The entities LLC and RLC are created in association of a radio bearer and their
function is to guarantee the negotiated QoS (ex : ARQ, FEC,...).
• The MAC entities are created at the initialisation of the equipment in which they
are located (mobile terminals, mobile stations). One MAC entity in one base
station is shared by all the radio bearers of the cell. A couple of MAC entities
manages the delivery of the radio resources between the different radio bearers.
The LLC sub-layer is common between the two modes (FMA1 and FMA2) whereas
the protocol RLC/MAC is specific to each mode. We are not going to go into detail

on the two modes, but the information is available if it is useful for another task of the
project.
⇒ Layer 1
The multiple access defined in the FRAMES project (Frames Multiple Access) is
composed by two modes : FMA1 (spread) and FMA2.
Table 2 gives the main characteristics of these two modes.
FMA1 FMA2
Spread
Multiple access method TDMA / CDMA DS-CDMA
Duplexing method FDD and TDD FDD
Transmission bit rate from a few kbit/s to 2 Mbit/s with good granularity
Channel spacing 1.6 MHz 4.8 / 9.6 / 19.2 MHz
Carrier chip/bit rate 2.167 Mchip/s 3.84 / 7.68 / 15.36 Mchip/s
Time slot structure 8 slots/TDMA frame -
Spreading Orthogonal, 16 chips/symbol Spreading factor 4-256, short codes
for DL and UL; long code optional
for UL
Frame length 4.615 ms 10 ms
Multirate concept Multislot and multicode Hybrid spreading, both variable rate
spreading and multicode
Number of users per 1-64 Variable
frame
Interleaving Inter-slot and inter-frame interleaving Inter-frame interleaving
Detection Coherent, based on training sequence UL: Coherent detection (reference bit
based; adaptive rate)
DL: Coherent detection (pilot channel
based, or reference bit based with
AA)
Additional diversity Frequency hopping per frame or slot, Time Macrodiversity
means hopping
Power control Slow power control, 50 dB dynamic range UL: Open loop and fast closed loop
(80 dB dynamic range, adaptive rate
and step size)
DL: Fast closed loop (20 dB dynamic
range, adaptive rate and step size)
Handover Hard handover Soft handover
Inter Frequency Hard handover Supported within specification
handover
Interference reduction Joint detection for intra-cell and inter-cell Short codes supports multi-user
interference suppression detection in UL and DL
Channel allocation Slow and fast DCA supported -
Table 2: General characteristics of FMA1 and FMA2
In January, ETSI had to choose one mode between these air interfaces and has chosen
to keep FMA1 spread (TD/CDMA) and FMA2 (W-CDMA).
Some slight modifications have been done in the characteristics of W-CDMA.
Each of these two interfaces have their own band of spectrum ; a large part is
dedicated to W-CDMA, while a smaller part is allocated for TD/CDMA.
⇒ Conclusion
The next step of the FRAMES project is to study the optimisation and harmonisation
of FDD WCDMA and TDD TD/CDMA modes and to demonstrate and validate TDD
TD/CDMA concept.

⇒ References
[1] « Description des protocoles du réseau d’accès dans le projet FRAMES », J-
M. Lafond, E. Puga Pereira, D. Verrier, NT/DMR/SCM, France Télécom,
1997.
[2] ACTS/FRAMES Deliverable 45 « FRAMES Radio Network Layer », RN3,
draft v. 0.71, January 1998.
[3] ACTS/FRAMES Deliverable 17 « Layer 2 Radio Protocol Definition », RN2,
Issue 1, Januray 1997.
[4] ACTS/FRAMES/AC090/CNET/RN3/DN/I/020/a1 « GRAN bearer concept »,
draft, December 1997.
2.1.3.2 RAINBOW
⇒ Objectives
The main Project objectives are summarised in the following list.
• To demonstrate the feasibility and evaluate the complexity of a generic UMTS
access infrastructure, characterised by a protocol architecture and network
configurations able to cope with different UMTS innovative radio access
techniques.
• To identify possible solutions for the migration from the second generation
mobile systems to UMTS: in this sense UMTS network infrastructure must
represent an evolutionary step of second generation systems and services.
• To identify the boundaries, within the UMTS Radio Access System, between
radio independent and radio dependent control and transport functions and define
the services provided through these boundaries.
• To contribute to the UMTS standardisation process within ETSI/SMG5/SMG3
and ITU.
• To study possible solutions for the integration of the UMTS Radio Access
System in the B-ISDN and IN context for both transport (ATM based) and
control procedures.
• To explore the impact of multimedia services and variable bit rate techniques on
the transport and control procedures of the UMTS Radio Access System.
⇒ Main Background Experiences in Rainbow
• 2nd Generation systems: DECT, GSM, DCS 1800.
• Projects: MONET, CODIT, ATDMA, MAGIC.
• Standards: B-ISDN, IN.
• Emerging standards: UMTS, IMT 2000.
⇒ The Rainbow System: Basic Characteristics
The radio interfaces considered are not based on W-ATM. These interfaces are based
on standard GSM and DECT for 2nd generation systems, and on the interfaces defined
by the projects CODIT and ATDMA for third generation systems. The core network
and the RAS network transport is realised by an ATM network based on B-ISDN

signalling. This arrangement will verify the feasibility of ATM independently on the
selected radio interface.
The Cell Site Switch (CSS) and the LE entity includes all the transport tied to the
handover, macrodiversity and other mobility mechanism.
The Mobility Service Control Point (MSCP) contains the control functions needed to
control the mobility process (e.g. handover and LM control functions for handover)
and the correlated storage functions. MSCP core controls inter CSS and inter LE HO,
MSCP access controls inter CSS HO. In the case of inter CSS direct connection
MSCP access could control also inter CSS HO.
The Base Transceiver Station (BTS) implements the radio related control and
transport functions. Radio coverage, channels control, mo-demodulation are
performed in a direct relationship with the Mobile Station (MS).
B-ISDN
N MSCP
C E core
O T LE
R W
O CC
E
R
K
CSS CSS MSCP CSS

access
R
A UMTS
S
BTS BTS
BTS BTS BTS
2nd generation Radio Lower Layers &

Radio Lower Layers Environment Emulator
(for 3rd generation radio access techniques)
MS MS
Figure 11: Overview of Rainbow system

Different topologies are studied for the interconnection of the network entities
forming the Radio Access System, as well as the MSCPs in the access could be
present or not. This is due to the will to support different environments, from the
outdoor rural ones (few user on a wide area) to the indoor business cases(a lot of
users in a small area).
This result is obtained using a specialised transport layer for signalling (the SNL),
which makes independent the user terminal (as well as the network functions) from
the deployment of the signalling function used in the particular environment. It
substitute the SCCP SS7 layer.
It should be noted that the switching functions tied to mobility that are to be dealt
within the Local Exchange and the CSS (e.g. bridging for handover, combining and
multicasting for macrodiversity) in general modify the Call Control functionality.
This means that both LE and CSS are switches that are enhanced to support mobility
for both control and transport.
In order to guarantee a smooth evolution from the present ATM switches, the option
of the use of a UMTS Mobility Server is foreseen. LE and CSS could be thought as

composed by a “normal” ATM switch plus a mobility server which integrates the
normal switching and control function in order to support mobility.
⇒ Additional Information on the Packed (IP) Service
Packed services in Rainbow could be based on an ARQ mechanism implemented
between the terminal and the CSS or the LE in order to limit end to end
retransmission.
⇒ Demonstrated Rainbow Services
• Voice (ATDMA, CODIT, GSM, DECT) inside the Rainbow system and towards
PSTN
• Data (IP-WWW) (CODIT)
• Video MPEG 4 (ATDMA)
It should be note that the GSM terminal is a commercial one , while the DECT one is
modified only in the control function (the DECT radio interface is preserved).
The demonstrations are inclusive of a wide set of mobility features:
• Handover (hard, soft, network and mobile initiated, forward and backward, …..),
Location Management, Macrodiversity, Multi -Bearer,etc.
• and it is performed for a complete set of deployment scenarios (public, business,
indoor, outdoor, etc.…).
⇒ Rainbow Extension: RAISIN
• More concept studies on : W-ATM, VB5.2, Software Radio, VHE,...
• Integration of IP service in the network (the MS becomes a sort of router)
• Demonstration of WWW and voice services on a real third generation interface
(WB CDMA) by means of a joint demonstration with FRAMES
⇒ Conclusions
The main results of Rainbow could be summarised as follow:
• It is possible to define a network architecture that it is completely independent on
the radio interface used. This architecture is flexible and it could match the
different environments maintaining a good efficiency. The complexity is not
excessive and it could be implemented with a reasonable effort.
• A network with these characteristics has been specified by Rainbow in terms of
architecture, protocols and functions, also using specification formal languages
(SDL and ASN.1).
• The basis of this network architecture are mainly derived from GSM, the RACE
II MONET project, B-ISDN and from Intelligent Network. In particular the
control is re-interpreted exploding the traditional IN function in term of
elementary function for the mobility support and introducing a new advanced
signalling network layer instead of SCCP.
⇒ References
Rainbow Technical annex (revision of 03/06/97)
Deliverable AC015/DTM/CIT/DS/021/b1: Trials planning and specification
(15/10/97).

2.2 Wireless ATM Systems

With the explosion of the ATM technology, there is a development of Wireless ATM
systems being standardised by ETSI and ATM Forum.
2.2.1 BRAN (ETSI)
⇒ History and Background

In order to improve the efficiency of the standardisation work at ETSI it was decided
in 1996 to merge parts of TM4 (Digital Radio Relay) and RES10 (HIPERLANs =
High Performance Radio Local Area Networks) to the new ETSI project BRAN
(Broadband Radio Access Networks). Both, TM4 and RES10, planned to use W-
ATM as transport mechanism. The goal was to use synergy effects and to accelerate
standardisation. ETSI-BRAN started in April 1997.
⇒ Objectives
There are three "Top Level Objectives" of ETSI-BRAN:
• Development of specifications for "high quality fixed radio access networks"
• Development of specifications for HIPERLANs
• Exploit synergies of both approaches
Currently the BRAN project plans to standardise to following three systems:
• HIPERLAN type 2: Broadband microcellular radio system which provides high
speed communication between portable computing devices and broadband ATM
and IP based networks. User mobility is supported within the local service area;
wide area mobility (e.g. roaming) is outside the scope of BRAN and can be
supported by upper layers standards.
• HIPERACCESS: Outdoor, broadband, fixed point-to-multipoint radio access
network with no (or very limited) mobility.
• HIPERLINK: Broadband, fixed point-to-point radio system providing very high
speed rates (up to 155 Mbit/s).
BRAN’s work is starting with the HIPERLAN/2 system. HIPERACCESS
requirements are also in under study.
Table 3 summarises the three BRAN types. There are still many open questions
according to availability of spectrum, especially for HIPERACCESS and
HIPERLINK, then 3 types of HIPERACCESS systems have been distinguished
regarding spectrum features and regulation (license or licensed exempt).
There are controversial discussions whether to allow unlicensed point-to-multipoint
systems in the frequency allocation for HIPERLAN/2 as well. This would influence
the channel assignment procedure for HIPERACCESS (would have to be dynamic)
and also the capacity of the different HIPERxxx systems.
The significance of HIPERLINK is also an open question. In the face of commercial
SDH ptp radio systems with data rates up to 155 Mbit/s it is questionable why such a
system should be standardised.

BRAN System Use Expected Frequency Band Mobility Range Radio Rate Config Comments
majority use. License Mbit/s uration
Regime
HIPERLAN 1 Wireless LAN Indoor 5,15-5,25 Ambulant 50 m Exempt 20 mp-mp ERC Decision erc/DEC/(96)03.
[5,25-5,3]
HIPERLAN 2 Wireless access, Indoor Around 5 GHz Ambulant 50 m Exempt 25 p-mp CEPT SE24 currently investigating the
ATM or IP possibility of extra spectrum in the 5 GHz
area.
HIPERLINK Wireless Indoor private 17,1-17,3 GHz Fixed 150 m Exempt 155 p-p Was formerly called HIPERLAN 4 in
infrastructure networks, TR 101 031 .
Outdoor tbd 100 mW EIRP limit. CEPT Rec. T/R22-
06 refers.
HIPERACCESS/E Wireless access, Outdoor, Around 5 GHz Fixed 0,5-5 km Exempt 25 p-mp Previously known as HIPERLAN 3.
HA/E ATM or IP Private (support TR 101 031defines requirements for
(Exempt) Networks for HIPERLAN 3. Operation not envisaged
nomadic in the range 5,15-5,25 Ghz. See also
users tbd) comment on HIPERLAN/2
HIPERACCESS/U Urban Fixed Outdoor, >10 GHz. Fixed 0,5-5 km Licensed 25 p-mp The amount of spectrum required at
HA/U Access, ATM or Public Operator mp-mp various frequencies is under
(Urban) IP consideration
HIPERACCESS/R Rural Fixed Outdoor, <10 GHz . Fixed 0,5- Licensed 25 p-mp The amount of spectrum required at
HA/R Access, ATM or Public Operator 5 km mp-mp various frequencies is under
(Rural) IP consideration
Table 3: Summary of Current BRAN System Types and Definitions
page 20 (51)  1998 EURESCOM Participants in Project P810

⇒ Project structure
The BRAN project is structured in four work groups (WG1 - WG4).
WG1: Requirements and business aspects
In the first step a technical report (TR) on "Requirements and architecture(s) for fixed
radio systems" shall be produced for HIPERACCESS. There is already such a report
on HIPERLANs (TR 101 031) available. It seems that there are different air interfaces
required for FRA (fixed radio access) and HIPERLANs (esp. type 2).
WG2: Spectrum and regulatory matters
This work group investigates the availability of radio spectrum for fixed wideband-
WLL-systems and continues co-operation with CEPT with respect to HIPERLANs
(additional spectrum above 5.25 GHz shall be applied for). Up to now the discussion
with operators of mobile satellite systems (MSS, e.g. ICO, GLOBALSTAR) has been
dominant. These operators want to use the frequency range between 5.15 and
5.25 GHz for MSS-feeder-links, although this spectrum is foreseen for HIPERLAN/1
(already completed standard), HIPERLAN/2 and HIPERACCESS. MSS-operators
claim to limit HIPERLANs to indoor use only with a maximum transmission power of
10 mW. Of course, BRAN has a different opinion on that topic.
WG3: Radio access network specifications
Here the fundamental work for the development of technical specifications shall be
done. The first step is the HIPERLAN/2 standard. Figure 12 shows the proposed
reference model for the future HIPERLAN/2.
H2.1
H/2 - H/2 - AP Mobility External

Wireless AP Enhanced
User Trans- Network
Terminal Controller Switch
ceiver
Adapter
H2.0 H2.2
H/2 Wireless H/2 -
ATM Terminal Wireless
Access Point
Figure 12: HIPERLAN/2 reference model

The system architecture is displayed in Figure 13. The main focus of WG3 is the
RADIO PHY layer and the RADIO DLC layer (MAC and LLC). Many different
proposals for these layers have been made and discussed. From these inputs a
"Technology Inventory" document shall be assembled in which advantages and
disadvantages of the various techniques are compiled. This system architecture is now
under modification to provide facilities for supporting direct IP connections. The aim
of this new proposal is to use the same DLC layer to carry IP packet or ATM cells
independently (this requires some adaptation functions in the upper layers in order to
adapt IP packets or ATM cells to DLC-SDU features).

Using IP above the ATM layer is not excluded but is outside the scope of BRAN
standardisation. However, since the beginning of year 1998, under the impulsion of
Ericsson and Telia, ETSI BRAN is going to study IP and ATM at the same level of
introduction in the network and in the radio interface.
Wireless ATM Wireless ATM Access Point Mobility

Terminal Enhanced
ATM SWITCH
Radio Resource Radio
Application Management Resource
and and Mobility
Mobility Mobility Support Management
Support
Q2931 Q2931
m m
SAAL AAL-X SAAL
ATM
ATM ATM
RADIO DLC RADIO DLC
RADIO PHY RADIO PHY PHY PHY
Figure 13: System architecture of HIPERLAN/2

The technology inventory is the basis for the standardisation of HIPERLAN/2.
The document has been finalised in February 1998.
WG4: Interworking specifications
The working group WG4 deals with network infrastructure and interworking.
WG4 is under editing a Technical Report in close co-operation with the ATM Forum
in order to define a common ETSI - ATM Forum reference model for Wireless ATM
Access Systems (WACS). This document defines also the division of standardisation
responsibilities between the two bodies.
⇒ Time Schedule and Milestones for HIPERLAN/2
The milestones for the HIPERLAN/2 standardisation are given below:
Feb 98: Technology Inventory
Sep 98: System Overview
Apr 99: Technical Specification (TS) for PHY and DLC
Dec 99: Network Management TS
Dec 99: HIPERLAN/2 Essential Requirements & Test Methods EN (European
Norm)
Apr 2000: HIPERLAN/2 Radio and Protocol Conformance Test Specifications
(CTS)
The time schedule for HIPERACCESS will be very similar but with a delay of about
three to six months. Figure 14 presents on overview of the standardisation process.

Scenarios Technology Reference

Business Inputs Inventory Model
User Inputs
State-of-the-art WG4
BRAN #7 BRAN #7 BRAN #7

2/98
Requirements
Selection
System
Overview Other HIPERXs
are considered
HIPERLAN/2 BRAN #10
9/98 in Parallel
Technical
Specifications
DLC PHY Network Radio CTS Protocol Essential Requirements &

Mgmt. CTS Test Methods EN
BRAN #14 BRAN #14 BRAN #18 BRAN #20 BRAN #22 BRAN #18
4/99 4/99 12/99 4/00 9/00 12/99
BRAN #xx
??/??
Standard
Standard
Standard
HIPERLAN2
HIPERLAN
HIPERLAN
Figure 14: Overview of HIPERLAN/2 standardisation
2.2.2 W-ATM (ATM Forum)
⇒ The scope of WATM is the support of mobility within an ATM network

The basic idea is to develop the signalling enhancement needed for Location
Management, for Handover, for the security issues required by a shared bearer like
the radio one and by the fact that the users become roaming users.
The radio interfaces themselves are considered to be developed by other groups like
for example (but it is presently the only example) the ETSI BRAN (Hiperlan at 5
GHz), and therefore the details of these interfaces are outside the scope of WATM,
except in terms of requirements.
A quite compressed description is offered in this document to explain the basic
tendencies in the group, a more complete one is present in the baseline document
mentioned in the references [BTD].
As general comments, it should be noted that, for the moment, the basic ideas present
in the group seem to be derived by:
• ETSI BRAN for the radio interface,
• IMT 2000 requirements for basic service requirements,
• IN and GSM models for mobility management,
plus a lot of proposal carried by different manufacturers, derived from proprietary
ideas and systems.
To find the reference architectures and models defined by the Wireless ATM group,
to find the corresponding WATM requirements, see the Baseline Text of this working
group [BTD].

⇒ Status and comments

The scope of the WATM is extremely wide, and presently the effort is devoted to
simple scenario, for which a lot of discussion takes place, and the visions in some way
shared are contained in the living list document [LTD]. Practically only for HO and
the APCP protocol a minimum consensus were obtained, but also these arguments are
not stable and are at risk of re-discussion, considering also the relations with ETSI
BRAN.
Furthermore the aspects related with the transport of the signalling information for
security and location management are not clarified and are presently in the domain of
other ATM Forum groups, as well as the QoS aspects, which could be heavily
impacted by the wireless case.
The major problem in the WATM group is that the group has two souls, one
represented by the traditional cellular telecommunication manufacturers and by some
mobile operators, the other one represented by the information technology companies.
One looks at wireless LAN as much simple as possible with a low (or null) degree of
mobility, the other one is thinking at a something closer to a cellular network, similar
to the indoor UMTS environments.
It could generates some impasses to the group, which, as usual in ATM Forum,
remains in every case capable of unpredictable accelerations.
⇒ References
[BTD] Baseline Text for Wireless ATM specifications - version 1_06 - Anaheim,
February 98.
[LTD] Living list document of Wireless ATM working group -version 1_06-
Anaheim, February 98.
2.2.3 LMDS DAVIC
⇒ Overview
The challenge of network operators is to deliver wireless products and services that
meet customer demands as soon as possible, deploying low-power high bandwidth
and reliable wireless local loops.
One of the possible choices is represented by LMDS (Local Multipoint Distribution
Services) systems. LMDS is a Federal Communications Commission (FCC)-coined
description for a terrestrial fixed service cellular broadband technology operating in
the millimetre wave bands, such as 28 GHz band in USA or 40 GHz band in Europe
(also called MVDS, Multipoint Video Distribution Systems). LMDS aims to provide
a low fixed cost highly scaleable technology that would, if implemented with proper
planning and dimensioning, provide an acceleration for the introduction of advanced
digital services such as dynamic bandwidth on demand. In fact with the large
available bandwidth (1-2 GHz), leveraged by a cellular and sectored architecture,
tomorrow’s demands for broadband services can be met without the delays and costs
associated with a wired solution.
The first studies for the definition of the physical interfaces for LMDS systems have
been realised by the DVB (Digital Video Broadcasting). This system is defined as the
functional block of equipment performing the adaptation of the baseband TV signals
from the output of the MPEG-2 transport multiplexer to the LMDS channel
characteristics. Afterwards DAVIC (Digital Audio Visual Council) has improved the

DVB specifications by introducing the definition of a MAC protocol for the wireless
return channel, so that DAVIC systems can also support bi-directional transmission
over millimetre radio waves.
The main extension DAVIC has introduced is the definition of a frame structure
suitable for the support of ATM cells with reasonably low CLR (Cell Loss Ratio)
both on the channel from the network to the end user (downlink) and on the reverse
one (uplink). Figure 15 and Figure 16 show the time slot structures on the uplink and
downlink respectively.
Packet n
Packet n+1
SYNC
1 byte
SYNC
1 byte
PAYLOAD
187 bytes
PAYLOAD
187 bytes } ATM transport MUX packets
(two-packet sequence)
7 ATM cells + 3 control bytes per two-packet sequence

CTRL0 ATM cell 1 ATM cell 2 ATM cell 3 ATM cell 4 (part)
Packet n 1 byte 53 bytes 53 bytes 53 bytes 27 bytes
CTRL1 cell 4 (cont) ATM cell 5 ATM cell 6 ATM cell 7 CTRL2
Packet n+1 1 byte 26 bytes 53 bytes 53 bytes 53 bytes 1 byte
Figure 15: Downlink Time Slot Structure for ATM services
4 bytes 53 bytes 10 bytes 1 byte

Preamble ATM cell RS Parity Guard
Figure 16: Upstream Time Slot Structure for ATM services
This Physical Layer Interface is point-to-multipoint: TDM from the Access Node to
the user and TDMA from the users to the Access Node. According to the downstream
channel two types of modulation can be used: QPSK modulation (Grade A) or 16-
QAM (Grade B).
The LMDS systems should represent a good solution for providing various services
such as telephony, Video On Demand, Internet access, Video Conference to business
and residential customers. These services have different requirements in terms of both
average and peak rate, as well as different delay constraints and the traffic load can
result in most of the situations heavier on the downstream channel than on the
upstream channel. The load unbalance between uplink and downlink has already been
recognised in the definition of LMDS, hence the available bandwidth in the two
direction is different. The spectrum allocations for downstream and upstream
transmissions depend on the country administrations.
The MAC Protocol proposed in DAVIC specifications for LMDS systems describes
the messages for establishing, maintaining and managing the physical wireless media
for communication between an AIU (Air Interface Unit) at the head-end access node
and an NIU (Network Interface Unit) at the subscriber premises (see Figure 17).
network AIU AIU RF RFU NIU

Tx/Rx
RFU:Radio Frequency Unit
Figure 17: LMDS System Architecture

Both the downstream and upstream frames are divided into time slots that encapsulate
ATM cells.
The downstream MAC Control Message structure that is utilised when the
downstream channel is carrying ATM cells is shown in Figure 18. With ATM
transport, the Access Node transmits a Frame_Start AAL5 PDU with
VPI/VCI=0xFF/0xFFFF once per frame period. MAC messages can also be sent on
individual MAC VCs (0xFF/niu_id) to minimise processing by each NIU/STB.
}
SYNC PAYLOAD
Packet n 1 byte 187 bytes ATM transport MUX packets
SYNC PAYLOAD (two-packet sequence)
Packet n+1 1 byte 187 bytes
7 ATM cells + 3 control bytes per two-packet sequence

CTRL0 Frame Start Cell 1 ATM cell 2 ATM cell 3 ATM cell 4 (part)
Packet n 1 byte 53 bytes 53 bytes 53 bytes 27 bytes
CTRL1 cell 4 (cont) ATM cell 5 ATM cell 6 ATM cell 7 CTRL2
Packet n+1 1 byte 26 bytes 53 bytes 53 bytes 53 bytes 1 byte
Figure 18: Downstream MAC Control Message structure (ATM structure)

The downstream scheme is time division multiplex and the time slot types are divided
into frame start slots and random access slots. The upstream scheme is time division
multiple access and the time slot types are divided into polling response slots,
contention slots, and reserved time slots.
⇒ References
[1] ETS 300 429, "Digital broadcasting systems for television, sound and data
services; Framing structure, channel coding and modulation for cable
systems", December 1994.
[2] DAVIC 1.3 Part 8, "Lower Layer Protocol and Physical Interfaces",
September 1998.
2.2.4 European Projects
2.2.4.1 CABSINET
The ACTS Project CABSINET (Cellular Access to Broadband Services and

INtEractive Television) has two headline objectives:
• To study and verify a last mile Two Layer Macrocell/Microcell wireless
architecture providing multi-user access to interactive TV and broadband
services.
• To demonstrate an interactive cellular TV (with in-band return path) application
of this architecture in urban and rural environment.
The Project provides a so called Two Layer Network (TLN), as shown in Figure 19,
where the Macrocell uses the 40 GHz band transmitted by the Base Station and the
Microcell is obtained by a passive Local Repeater that converts the available

bandwidth into the 5.8 GHz band and allows to cover areas not in line-of-sight with
the Base Station. The user terminal will be a Fixed Terminal if it directly receives the
signal from the Base Station (40 GHz) and a Portable Terminal if it receives the signal
from the Local Repeater.
The Project shall also use as much as possible the already developed standards, such
as DVB [1] and DAVIC [2] specifications for the macrocell environment.
The capacity per channel shall be about 34 Mbits/s in downstream and 512 kbits/s in
upstream (about 30 Mbits/s after CDMA spread spectrum).
Three main blocks shall be developed: Base Station, Nomadic Terminal (Local
Repeater and Portable Terminal) and Fixed Terminal.
The workplan of the Project can be divided into three parts:
• The first one defines the final architecture and the parameters for any subsystem
block (December 97);
• The second one shall realise the subsystem blocks (June 98);
• The last one shall integrate the subsystem blocks and perform the final trial (June
99).
⇒ References
[1] ETS 300 429, "Digital broadcasting systems for television, sound and data
services; Framing structure, channel coding and modulation for cable
systems", December 1994.
[2] DAVIC 1.3 Part 8, "Lower Layer Protocol and Physical Interfaces",
September 1998.

ATM Link Service

SERVICE RF Head
(FIBRE) Provider
PROVIDER End
Interface MACROCELL MICROCELL
Line of Sight
FIXED System
Consumer 40 GHz
Tranceiver
STB
Consumer 40 GHz
Transceiver
STB
NORMADIC System
40GHz to
5Ghz Local
Nomadic 5GHz
Repeater Transceiver
Figure 19: Diagram of the CABSINET system

2.2.4.2 MEDIAN MAC Layer
The ACTS project MEDIAN (AC006) has the objective to offer W-ATM in indoor
environment with 150 Mbit/s at 60 GHz.
PHY-Layer
Environment Indoor (4-6 m range), portable (no mobility during operation)
Bitrate 150 Mbit/s (ATM)
Frequency range 60 GHz
max. RF power > 10 mW
Antennas directive
Mult.access/duplex sche. TDMA/TDD (const. frame length, 64 Sl., var. Up/Dwn border)
Modulation scheme 512-OFDM (DQPSK-submodulation, only 286 subcarriers used)
FEC RS (55,71)
For more details on the physical layer, see the reference [MED96].
LC-Layer
The medium access scheme used in MEDIAN in TDMA with adaptive, i.e. variable
down-/uplink separation. A fixed frame length of 64 slots is used, see Figure 20. The
first slot of a frame is a so called reference symbol and is used by the MS for
synchronisation. Next a broadcast cell follows. Thus the MSs are informed on the
composition of a frame and the slot assignment. So the slot assignment can be
changed from frame to frame, i.e. MEDIAN can offer a very flexible slot assignment.
However, the information of the i-th broadcast cell is valid for the (i+2)-th frame in
order to consider processing delay of the hardware. The last slot of a frame is always
used as a random access slot ("available slot") for uplink requests/signalling
(contention mode) by the MS.
tim e slo t n u m b e r
R e fe re n c e S y m b o l 0
i-th B ro a d c a st C e ll 1
i-th A ssig n e d to R V C I a 2
d o w n lin k
fra m e A ssig n e d to R V C I a 3
A ssig n e d to R V C I b 4
i-th T D D A ssig n e d to R V C I b 32
fra m e A ssig n e d to R V C I a 33
A ssig n e d to R V C I b 34
N o t u se d s lo t 35
i-th
u p lin k
fra m e N o t u se d s lo t 61
A ssig n e d to R V C I c 62
A v a ila b le S lo t 63
R e fe re n c e S y m b o l 0
(i+ 1 )-th B ro a d c a st C e ll 1
(i+ 1 )-th A ssig n e d to R V C I c 2
d o w n lin k
fra m e A ssig n e d to R V C I c 3
A ssig n e d to R V C I a 4
i-th T D D A ssig n e d to RVCI c 38

fra m e A ssig n e d to RVCI b 39
A ssig n e d to RVCI c 40
A ssig n e d to RVCI b 41
(i+ 1 )-th
u p lin k
fra m e A ssig n e d to R V C I b 61
N o t u se d s lo t 62 tim e
A v a ila b le S lo t 63
Figure 20: MEDIAN frame

A payload slot is 55 byte long and carries a so called "extended cell" (see Figure 21),
consisting of a 2 byte MAC header and a 53 byte PDU (protocol data unit). The PDU

can contain an unchanged 53 byte ATM cell (transparent transmission) or a MEDIAN

signalling cell. A VPI/VCI pair (24 bit) is compressed to a 5 bit wide RVCI (Radio
VCI) to save transmission capacity (header compression). Furthermore the RVCI is
used in the broadcast cell to inform the MS on where (slot number) downlink data is
available for it as well as where in the uplink portion it is allowed to transmit. The
MAC header is also used to transport request information via the uplink (e.g. queue
length) and sequence numbers for an optional ARQ scheme.
MAC header ATM - PDU
MAC header MEDIAN Signalling - PDU
MAC - PDU = Extended Cell
Figure 21: MEDIAN Extended Cell

⇒ References
[MED96] MEDIAN Partners, "Final System Design", CEC Deliverable No.AC006/
MED/PAR/DS/R/054/b1, 1996.
2.2.4.3 MagicWAND
MagicWAND (Wireless ATM Network Demonstrator ) is an ACTS project (AC085)

which has the goal to develop a W-ATM demonstrator offering 20 Mbit/s in the
5.2 GHz range for indoor applications.
MagicWAND is a joint European project to specify and implement a wireless access
system for ATM that extends the service characteristics and benefits of ATM
technology to mobile users. Communication between the mobile, portable terminals
and the access points will take place in the 5 GHz frequency range at a nominal
transmission speed of 20 Mbps and a range of up to 50 meters.
User trials in hospitals and office environments will be conducted in 1998 to evaluate
and demonstrate the feasibility of a radio-based ATM access system.
The project actively promotes the standardisation, notably in ETSI and the ATM
Forum, of wireless ATM access as developed in this project
⇒ Technical Approach
The MagicWAND project (Wireless ATM Network Demonstrator) covers the whole
range of functionality from basic (wireless) data transmission to shared multi-media
applications. The primary goal of the project is to demonstrate that wireless access to
ATM, capable of providing real multi-media services to mobile users, is technically
feasible. The project partners have chosen to use the 5 GHz frequency band for the
demonstrator and perform also studies on higher bit rate operation 50 Mb/s in the 17
GHz frequency band.

⇒ Summary of Trial
The aim of the user trials is to verify a wireless, customer premises, access system for
ATM networks that maintains the service characteristics and benefits of ATM
networks in the 5 GHz range allocated to wireless high speed data transmission. The
feasibility of a radio based ATM access system will be demonstrated by the user trials
with selected end-user groups in hospital (medical consultation) and office
environments (mobile computing).
The medical consultation shows an advanced scenario, fully exploiting the wireless
ATM service capabilities in the hospital environment. The JVTOS (Joint Video
Telecommunication Operating System) will be used with an X- ray viewing
application using both native audio and video services over ATM. In this scenario,
doctor will be equipped with mobile terminal while visiting patients. With the help of
wireless ATM connection, doctor is able to retrieve patient information from network,
consult expert doctors and share documents.
The mobile computing trial, will demonstrate legacy applications built on top of the
TCP/IP protocol stack such as Internet Web-browser over the wireless ATM link with
university students as an user group.
⇒ Achievements
The main result of the project will be a Wireless ATM Access Network
Demonstration system which will serve as a proof of concept for the developed
technology and help the wireless ATM standardisation work in the relevant fora.
The current achievements of the project include the complete functional system
specification on the demonstrator which has been specified with the SDL
(Specification and Description Language) and verified with the simulation model. In
addition, the project has defined the exact demo platform set-up and therefore enabled
the basis for the implementation work which has been started on all parts of the
system.
⇒ Expected Impact
The main benefit of wireless ATM is that it enhances the effectiveness of people in
many occupations and businesses by providing them with location independent and
high capacity [20 Mbit/s] access to broadband infrastructure networks. Wireless ATM
will allow users to transmit and receive data at realistic data rates and controlled
service levels that match those of the wired ATM world. This assurance of service is
imperative as long distance ATM services are relatively expensive and users can not
be expected to accept service degradation on the final (radio) link.
For more details on the physical layer, see reference: [ALD96].
⇒ DLC-Layer
The MAC protocol of MagicWAND, MASCARA (Mobile Access Scheme based on
Contention and reservation for ATM) [PRO97], is based on a TDMA structure with
variable frame length. The slot length corresponds to one ATM cell including
(wireless) overhead. The duplex scheme is TDD with variable downlink/uplink
separation. Figure 22 shows the structure of a MASCARA time frame.

Figure 22: MASCARA time frame

The "FH period" is a broadcast control field and informs the MSs on the composition
of a time frame, position as well as direction of transmission (down/up) of assigned
slots ("slot map entry"). Furthermore the time of the next broadcast transmission is
indicated (future, ⇒ energy saving).
All data/control information is packed in a MPDU (MAC protocol data unit) that
consists of a header field and the MPDU payload field. In order to reduce the
overhead (MAC and PHY) the ATM payload (cells) are combined in "cell trains" and
are transmitted "en block" (see Figure 23). This meets the structure of ATM cell
streams because usually larger AAL packets of up to 64 kBytes are separated to 48
byte cells in the ATM layer.
Figure 23: Cell train concept of MASCARA

The MPDU header consists of a Net-ID (2 bytes), the MAC addresses of source and
destination (2 bytes each), MPDU info (15 bytes), packet type (1 byte), body length (1
byte) and a 4 byte CRC of the header.
A MPDU body contains the payload and cell header (ATM payload) as well as
control information in the case of the FH-MPDU. The 48 byte ATM payload is
transmitted transparently whereas the ATM cell header will be modified. Only PT and
CLP are not changed. VPI/VCI are converted/shortened to a 16 bit MAC address and
a 8 bit MVC-ID (MAC virtual circuit).
The assignment of capacity is centrally controlled by the BS. The MS transmits
requests for uplink capacity via piggybacking or in contention mode according to S-
ALOHA to the BS. For this a 16 bit field "MVC info" is used in the cell header. 8 bits
tag the MVC-ID for which the request is valid, the other 8 bits quantify the demand in
the next frame.

Figure 24 displays the way a ATM cell is included in a frame. PHY overhead and
MPDU header fit exactly into a time slot. The MPDU payload is build with a cell
train and requires n time slots. By this measure the overhead can be reduced
significantly.
Figure 24: Time frame structure

The scheduler employed within MASCARA is called PRADOS (Prioritised Regulated
Allocation Delay-Oriented Scheduling) [PAS97]. It is based on the lifetime of the
ATM cells. A priorisation is performed according to the service class: CBR, rt-VBR,
nrt-VBR, ABR, UBR. Fairness is maintained by token assignment. For each MVC
(not UBR) tokens are generated with constant rate. The token counter is decremented
with each slot assignment to that particular MVC. This function is related to the ATM
usage parameter control function "leaky bucket". MVCs with positive token counter
are prioritised against those with lower token counters. The rate with which tokens are
generated depends on the traffic contract.
The LLC sublayer uses Go-Back-N ARQ with window size 16. ARQ is only used for
non-real-time connections. There is no repeat limitation. It is the task of the higher
layers (e.g. TCP) to care about flow control. ACKs are transmitted in the WDLC
header inside the MPDU header (piggybacking if possible).
⇒ References
[ALD96] Aldis et. al., "Physical Layer Architecture and Performance in the
WAND User Trial", ACTS Summit´96, Grenada.
[PAS97] Passas N. et al., "Quality-of-Service-Oriented Medium Access Control
for Wireless ATM Networks", IEEE Comm. Mag., November 1997.
[PRO97] Pronios N.B., "The WAND Project DLC - An Option for HIPERLAN
II", ETSI BRAN WG3, TD34.

2.2.4.4 SAMBA
SAMBA (System for Advanced Mobile Broadband Applications) main area of work
is around the Trial Platform which includes the following steps: specification, design,
implementation, fabrication, stand-alone modules tests, integration, inter-modules
tests and finally the operation and evaluation of the measured results.
The system evolution work – with much smaller effort – comprised studies for the
future MBS and first contributions to standardisation bodies (ETSI and ATM Forum)
have been issued and presented.
⇒ SAMBA Trial Platform
The key objectives of the Trial Platform are related to the following three areas:
• Services and applications - to demonstrate mobile multimedia applications up
to 34 Mbit/s.
• System - to demonstrate basic mobile functions such as reliable ATM cell
transmission, medium access, handover and radio resource management, and the
connection with an ATM network [1].
• Technology - to demonstrate the practical feasibility by developing and
implementing a «person-portable» mobile terminal including suitable antennas,
MMICs and ASICs [2] [3] [4].
The Trial Platform consists of a digital cellular radio network transferring ATM cells
over the radio link interconnected to the fixed ATM network via a RIA (Research in
Action) node of the Portuguese National Host (Figure 25).
Video Server
Signalling
User Data
ATM Network
ATM Terminal UNI

incl. UNI
application SW Mobile Term.
+ Mode 1 (MTA)
UNI signalling Base Station
Transceiver 1
Base Station ATM switch

Controller
Mobile Term. Base Station ATM

Mode 2 Transceiver 2 Mobility Server
+
using PVCs UNI sign.
Figure 25: Samba Trial Platform architecture

Two user applications were specified and will be demonstrated at EXPO ’98 in
Lisbon: a wireless TV camera for news gathering and a medical application. The
former was chosen because high-quality video is the key element in a whole range of
different user applications and the latter due to the importance of good
communications in medical emergency situations. On the mobile side, standard user
equipment compliant with ATM UNI3.1 is used.
The specific requirements and constraints of the Trial Platform had to be taken into
account and led to various simplifications as shown in Table 4.

Requirements Constraints Simplifications

40 GHz band Only one production run for ICs One type of transmission burst
34 Mbit/s ATM cell bit rate Non-flexible baseband processing No time alignment and adaptive
unit power control
2 cell types: »street» and 240 ns max. delay spread for One control unit for 2 cells
»wide» equaliser
Seamless handover Early freezing of parameters for Radio handover only
ASIC design
Residual bit error rate <10-9 MT speed - 50 km/h max. No capacity problems
Person-portable mobile Budget limitation: e.g. only simple No spectrum efficiency
terminal antennas requirements
Multimedia/multiservice Non-linear power amplifier, low Simple handover measurements
capability output power
Demonstration at EXPO ‘98 Unknown propagation Simplified MAC and LLC
environment protocols
Table 4: Characteristics of the air interface
The air interface comprises a physical layer, a Medium Access Control (MAC) layer
and a Logical Link Control (LLC) layer in order to provide the required Quality of
Service (QoS) to the ATM layer. The physical layer is the most critical item; the
given limitations result in a trade-off between the requirements and the
implementation capabilities. Figure 26 shows the frame and burst structures.
The MAC layer controls the access to the shared medium by performing a fair
statistical multiplexing algorithm according to the negotiated QoS and the available
capacity. The essential QoS parameters are Cell Loss Ratio (CLR), Cell Transfer
Delay (CTD) and Cell Delay Variation (CDV). Special attention has to be paid to the
maximum cell delay of real-time oriented (CBR, VBR) services. The assignment of
slots to virtual channels is controlled by a central entity located in the base station.
80 slots, 54800 symbols, 1.7125 ms
Frame
Structure slot 0 slot 1 slot 2 slot 3 ... slot 78 slot 79
P TB PL 1 TS 1 PL 2 TM PL 3 TS 2 PL 4 CI CR TE GT
Symbols 32 8 130 32 130 8 130 32 34 16 80 8 45
1.406 µ s
640 symbols , 20.000 µs
685 symbols , 21.406 µs
Figure 26: Frame and burst structures

The LLC layer has to perform all functions that are related to a specified Virtual
Channel (VC), and which have to be adapted to the specific conditions of the air
interface. The main task is to implement appropriate error control and to guarantee
data integrity. It is based on adaptive selective repeat - automatic repeat request
(ASR-ARQ), and it co-operates closely with the forward error correction (FEC) unit
in the physical layer, which marks all non-correctable blocks. The LLC layer uses the
services of the MAC layer, which is responsible for multiplexing the ATM cells of all
VCs on the radio resource.

Handover is performed seamlessly by the mobile terminals (forward handover), and it

is based on link quality measurements. The responsible entity is in the LLC layer.
⇒ System studies and support of concertation and standardisation mechanisms
This area includes System Evaluation, Network Issues and the Air Interface, and the
corresponding concertation and standardisation activities. The main objective was to
give support to Trial Implementation and Operation.
Mechanisms for network resource and mobility management were developed and
analysed. Problems for handover at the network side were identified, particularly
maintaining the ATM connection. Therefore different protocols, maintaining a
particular QoS, were specified and simulated. Interwork, interconnecting and
integration of MBS islands with other networks are also studied.
SAMBA contributions are expected in the radio and network areas, namely on
mobility resources management, cellular planning, handover algorithms, MAC
protocols, transmission aspects and radio channel modelling.
⇒ References
[1] A. Kadelka, N. Esseling, J. Zidbeck, J. Tuliluoto: SAMBA Trial Platform -
Mobility Management and Interconnection to B-ISDN. ACTS Mobile Summit
97.
[2] C. Fernandes, M. Filipe, L. Anunciada: Lens Antennas for the SAMBA Mobile
Terminal. ACTS Mobile Summit 97.
[3] B. Byzery, C. Cordier, M. Pertus, P. Talbot, E. Delhaye: A Ka Band GaAs
MMIC Chip Set for a 40 GHz Mobile Broadband Front-end. ACTS Mobile
Summit 97.
[4] T. Fujino, M. Miyake, K. Murakami, A. Shibuya, F. Ishizu, H. Kubo, T.
Shikama, B. Penther: Baseband Signal Processing Technologies for 64 Mbit/s
Mobile Radio Transmission at 40 GHz. ACTS Mobile Summit 97.
[5] M. Prögler: MBS Air Interface Principles. RACE Mobile Telecommunications
Summit 1995, Cascais (P), 22-25 Nov. 1995, pp. 293-298.
[6] M. Prögler (editor): Specification of the Air Interface. CEC Deliverable
A0204/DB/F3F/DS/P004/b1, May 1997.
2.2.4.5 AWACS
The AWACS project target is the development of a system concept and testbed
demonstration of tetherless public access to the B-ISDN services.
The AWACS demonstrator offers low mobility to the wireless terminals, in the band
of 19 GHz band , with bit rates up to 34 Mbit/s within a range of 100 meters. It is
based on an existing hardware (AWA, provided by NTT), which capabilities are
updated in order to support mobility and to increase spectrum and power efficiency.
⇒ The AWA concept
Awa is essentially a wireless extension of an ATM-based multimedia network.
AWA improves the mobility of wired terminals and wireless LAN, and it allows a
quite high transmission speed at a sacrifice of mobility, which is tailored on users

which remain still or walk slowly, because need to look at the visual information by
their eyes.
To summarise:
• Wireless extension of an ATM based multimedia network
• ATM handling capability for flexible bit rate, various services and connections
for multimedia services
• High speed transmission with limited mobility up to 10Mbit for each user
• Dual access capability for both private and public, indoor and outdoor access.
AWA employs a single carrier non equalised modem, with antenna diversity at the
broadband base station in order to achieve an air interface bit rate of 70 Mbit/s with a
Line of sight in the range of 50 or 100meters.
It uses a TDMA/TDD, where every channels contains multiple valid ATM cells in
order to maintain an high frame efficiency.
Some details about the AWACS system
⇒ The services
Various indoor scenario were studied and simulated.
Multimedia services including voice, data and MPEG1 video were demonstrated.
⇒ The handover scheme
The HO makes use of site diversity, setting up a second channel before switching
from the previous one (primary and secondary link).
The MAC layer
The MAC protocol in AWACS tries to cope with the inherent statistical multiplexing
scheme of ATM. The MAC acts as a sort of concentrator. The statistical multiplexing
characteristics of the ATM cell stream are implemented by sharing the air resources,
using a time basis principle for the transmissions of ATM cells bursts
The demonstrator uses a 32 burst frames with a length of 62.5 µs (4388) bit per burst
(it allows a transport of 8 cells per burst).
Due to the asymmetrical nature of the concentration function at the BTS, the BTS
itself is considered to be the appropriate master of the MAC protocol. The MAC
provides the following control mechanism:
• Acknowledgement of slots
• Reservation of slots
• Announcement of slots
These information are transported in downlink by means of specific control bursts.
The downlink overhead is of 64 octets (two octets for each referenced burst in the
frame), split in 32 octets of acknowledgements and 32 octets of reservation. Two
bursts in the frame are dedicated to this downlink overhead.
The following information are transferred by the terminals in the uplink direction as
overhead of each transmitted burst:
• Number of ATM cells (8 bits)

• Minimum residual life for all the cells stored in the MT (8 bits)
• Maximum waiting time of all the cells stored in the MT (8 bits)
• 8 bits reserved for further use
These information are used in combination with the static QoS information in order to
maintain the QoS control and assign opportunely the resources.
⇒ Conclusion
The core result of AWACS is the demonstration the it is possible to provide slow
mobility services at high bit rate and at high frequencies, without any kind of
equalisation and any countermeasures against the multipath fading. These results were
obtained by using a narrow beam antenna, but it has validated the AWACS concept,
which foreseen the use of electronically controlled directive antenna such as beam
switched sector antenna. Intelligent, smart antenna are the proposed solution in order
to provide the typology of services studied by AWACS.
⇒ References
AWACS Technical Annex.
AWACS Deliverable 7 (draft) -Report on 19 GHz AWACS Report on Radio Access
Methods for AWACS demonstrator.
AWACS Deliverable 10 (draft) -Report on 19 GHz AWACS Trial results.
3 Mobility in IETF
The Internet Protocol (IP) provides the functionality for interconnecting end systems
across multiple networks. For this purpose, IP is implemented in each end system and
in routers. Higher-level data at a source end system are encapsulated in an IP PDU for
transmission. This PDU is then passed through one or more networks and connecting
routers to reach the destination end system.
Figure 27: Protocol architecture including IP

3.1 IP Mobility Background

The Mobile IP standard is being formulated at the Internet Engineering Task Force
(IETF), an open forum of vendors, manufacturers and researchers associated with the
evolution of the Internet architecture. The IETF has a number of working groups
(WG), each looking at specific issues. The integration of mobile nodes into existing
networks is addressed by the Mobile IP WG which has been established since 1992.
There is a number of WG’s that are looking at activities related in support of mobility,
illustrated by the following list.
1. Mobility Problem: If the end system moves, then the connection will be broken.
All the transport and application layer software will be broken due to this
change.
2. Why support on the Network Layer?
3. Physical layer technologies keep changing.
• Do not want to modify the application layer (host) software since it will
involve tremendous cost to change it.
• The IP approach does not guarantee delivery. Therefore, successive
datagrams can follow different routes through the Internet. This solves the
traffic congestion by changing routes.
4. Goals of supporting mobility:
• Don't want to change the host software since this change will induce
tremendous cost considering the current size of the Internet.
• Ensure interoperability with the existing infrastructure. Don't want to re-
invent a new Internet Protocol.
• The handling of mobility should be totally transparent to the upper layers
and the applications running on the end systems. In other words, don't
change the IP address when the host moves around. This can maintain the
TCP/IP connections or other application usage.
⇒ Mobile IP Architecture
5. Architecture: Location and Routing Management
• How to locate and route packets to mobile hosts.
• Address Translation Mechanisms based on two-tier addressing
⇒ Improvements for Mobile IP
6. Route Optimisation, constitutes an on-demand location update protocol.
• Using Minimal Encapsulation within IP, add 8 bytes to the original IP
datagram.
7. IP v6:
• No foreign agent is needed, the mobile stations send binding requests to the
correspondent nodes, minimise network load.
• The home agent becomes less involved, thus enhancing scalability and
reliability.

• Better security (undecided).

• Using routing header instead of the LSR option of IP v4.
• Improved scheme for handling options.
• IP multicasting and other forms of addressing.
3.2 IP version 4
Figure 28 depicts the IP PDU of the currently implemented IP version 4 (IPv4, the IP
header is at least 20 octets long).
IP header Information
Figure 28: IP PDU structure

IP provides a connection-less service (datagram service) between stations. On top of
the IP layer it is possible to use the Transmission Control Protocol (TCP) which is
connection oriented or the User Datagram Protocol (UDP) which is connection-less.
As the Internet has grown, it became apparent that the existing version of IP (IPv4)
was inadequate to meet the performance and functional requirements for the Internet.
The main driving motivation for the adoption of a new version of IP was the
limitation imposed by the 32-bit address field in IPv4, but also other considerations
like performance, networks service classes drove to the design of IPv6 [IPv6].
3.3 IP version 6
To meet the addressing needs, IPv6 uses 128 bit addresses instead of the 32 bit
addresses of IPv4. This is a huge increase of addressing space (factor of 296). Even if
addresses are very inefficiently allocated, this address space seems to be future proof.
A simplification and speed up of the IP routers are achieved by reducing the number
of fields in the packet header (remaining future proof through allowing separate
extension headers to be added). Another simplification of the processing is achieved
by keeping the IP header length fixed (IPv4 header is of variable length). It should be
possible to associate packets with particular service classes, perform the routing
function on the basis of those classes, and allow the networks along the route to make
use of this class information. In particular, it is important to be able to support real-
time services and to specify priority levels. IPv4 provides only a minimal assistance in
this area whereas IPv6 enables the labeling of packets belonging to a particular traffic
flow for which a sender requests special handling.
An IPv6 protocol data unit (known as a packet) has the general form shown in Figure
29.
Figure 29: IPv6 PDU general form

3.4 Mobile IP
Basically, Mobile-IP [MobileIPRe] extends the existing Internet Protocol to allow a
portable computer to be moved from one network to another without changing its IP
address and without losing existing connections.
The architecture needed to support mobility is build around three functional entities:
• Mobile Node: A host or router that changes its point of attachment from one
network (or subnetwork) to another.
• Home Agent: A router on a mobile node’s home network which tunnels
datagrams for delivery to the mobile node, and maintains current location
information for the mobile node.
• Foreign Agent: A router on a mobile node’s visited network provides routing
services to the mobile node while registered.
Figure 30 depicts an example of a network configuration based on the above
mentioned three functional entities. See [MobileIP, RFC2002] for more information
related to IP mobility support.
2 3
Home Agent Foreign Agent Mobile Node

4
1 4
Host
1. Datagram to Mobile Node arrives on home network via standard IP routing

2. Datagram is intercepted by home agent and is tunneled to the Foreign Agent
3. Datagram is detunneled and delivered to the Mobile Node
4. For datagrams sent by the Mobile Node, standard IP routing delivers each to its
destination
Figure 30: Mobile IP example
3.5 Mobile IP version 4

The draft specification for IP Mobility Support demonstrates a method to allow
transparent routing of IP datagrams to mobile IP nodes on the Internet.
At present, the routing of an IP packet is sub-composed into two stages. First, the
packet is routed to the correct network using the network address prefix of the IP
address. Then, once the packet has arrived at the correct network, the host address
portion of the IP address is used to route the packet to the correct host on the local
network. So, at the moment, a packet can only be correctly delivered to a host if that
host is connected to its local ‘Home’ network.

3 2 b its
N etw o rk A d d ress H o st A d d ress
N b its (3 2 -N ) b its
Figure 31: IP packet address format

The draft proposes that whenever a mobile node is not connected to its Home
Network, a ‘care-of’ address is associated with it. This ‘care-of’ address represents
the network to which the mobile node is currently connected.
3.6 Mobile IP version 6

In this latest version of the IP protocol (which is still only at the draft stage), several
modifications have been made to the protocol to handle situations which were not
considered when the IP protocol was originally designed. Mobile user terminals are
one major case in point. Version 4 of the IP protocol does not handle mobile IP nodes
very gracefully.
The major change to the IPv4 version of mobility support is that each IPv6 node keeps
a cache list of the Home and ‘care-of’ addresses of every node with which it
communicates. This relationship between a Home address and a ‘care-of’ address is
known as a ‘binding’. Instead of simply sending a packet onto the network (and the
packet subsequently being routed to the Home Agent, then forwarded to the mobile
node via the Foreign Agent) each node looks in its cache to see if the remote node’s
Home address is listed.
⇒ IP in view of UMTS
Some key IP characteristics related to UMTS are discussed below:
• Large existing infrastructure: The Internet is estimated to have about 40 million
users, all interconnected. The growth rate of the Internet is predicted to be at
10% of its total base every month.
• Interoperability between heterogeneous systems: The Internet Protocol provides
the functionality for interconnecting end systems across multitude of diverse
networks.
• Low efficiency for ‘short’ packet applications: IP is not efficient when ‘short’
packets (which is however typical for mobile applications) need to be transferred
as there is an overhead of minimum 20 octets (header size) in the currently
deployed IPv4, and 40 octets in the new version IPv6.
• Effective switching solutions: Even though the IP protocol is flexible enough to
allow scalable networks to be implemented, it suffers from the very long
datagram packet structure preventing (or seriously limiting) the implementation
of effective switching solutions.
• Mobile IP: Solves the ‘macro’ mobility (comparable with discontinuous
mobility) management problem, though is less well suited for ‘micro’ mobility
(comparable with continuous mobility) management applications. Mobile IP
relies on protocol tunnelling to deliver packets to mobile nodes [RFC2005], it
uses layer three instead of layer two functionality (mobility detected by polling
instead of real mobility procedures).

• Association between packets and service classes: A new requirement on IP

networks is to be able to support real-time services. Two solutions are the
introduction of flow labels and priority levels. IPv4 provides only a minimal
assistance in this area whereas IPv6 enables the labelling of packets belonging to
a particular traffic flow for which a sender requests special handling.
• Limitation imposed by address field in IPv4: To meet the addressing needs, IPv6
uses 128 bit addresses instead of the 32 bit addresses of IPv4.
3.7 Link layer consideration

The mobile node may use link-layer mechanisms to decide that its point of attachment
has changed. Such indications include the Down/Testing/Up interface status [5] and
change in cell or administration. The mechanisms will be specific to the particular
link-layer technology, and are outside the scope of this document.
The Point-to-Point-Protocol (PPP) [10] and its Internet Protocol Control Protocol
(IPCP) [11] negotiate the use of IP addresses. The mobile node should first attempt to
specify its home address, so that if the mobile node is attaching to its home network,
the unrouted link will function correctly. When the home address is not accepted by
the peer, but a transient IP address is dynamically assigned to the mobile node, and
the mobile node is capable of supporting a co-located care-of address, the mobile
node may register that address as a co-located care-of address. When the peer
specifies its own IP address, that address must not be assumed to be a foreign agent
care-of address or the IP address of a home agent.
⇒ TCP Considerations
• TCP Timers
Most hosts and routers which implement TCP/IP do not permit easy configuration of
the TCP timer values. When high-delay (e.g., SATCOM) or low-bandwidth (e.g.,
High-Frequency Radio) links are in use, the default TCP timer values in many
systems may cause retransmission or time-outs, even when the link and network are
actually operating properly with greater than usual delays because of the medium in
use. This can cause an inability to create or maintain TCP connections over such
links, and can also cause unneeded retransmission which consume already scarce
bandwidth. Vendors are encouraged to make TCP timers more configurable.
• TCP Congestion Management
Mobile nodes often use media which are more likely to introduce errors, effectively
causing more packets to be dropped. This introduces a conflict with the mechanisms
for congestion management found in modern versions of TCP [5]. Now, when a
packet is dropped, the correspondent node’s TCP implementation is likely to react as
if there were a source of network congestion, and initiate the slow-start mechanisms
[5] designed for controlling that problem. This problem does illustrate that providing
performance transparency to mobile nodes involves understanding mechanisms
outside the network layer. It also indicates the need to avoid designs which
systematically drop packets; such designs might otherwise be considered favourably
when making engineering trade-offs.

⇒ Internet Protocol (IP) Multicast

The IP multicast delivery mechanism provides a popular basis for delivery of
continuous media to many participants in a conferencing application. However, the
best-effort nature of multicast delivery results in poor playback quality in the presence
of network congestion and packet loss.
IP multicast service can be based on different technical solutions: the underlying
multicast or broadcast capabilities are exploited in the LANs, while multicast routers
are used for LAN interconnection. IP multicast is a multipoint-to-multi-point service
that allows dynamic management of multicast groups (hosts can join and leave a
multicast group at any time), and provides packet replication and distribution tree
creation functions. MBone, the multicast backbone grown on the Internet, is
becoming popular and interconnects an increasing number of multicast LANs. MBone
is used to provide audio and video across the Internet. Many other applications can
take advantage of IP multicasting, such as multiparty teleconferences and
telemeetings, distributed simulations, and multiple database synchronization. Most of
these applications are resource-demanding in terms of high bit rates, replication
capacity, small delays, and reliability.
• SRTP
The Selectively Reliable Transmission Protocol (SRTP) operates in three distinct
modes: best-effort multicast, reliable multicast using negative acknowledgments with
a NAK suppression mechanism to avoid congestion at the sender, and lightweight
reliable transaction-oriented unicast. SRTP is designed to run in user space and form a
sublayer between applications and the kernel-level Internet protocol stack.
• RTP
The Real Time Transport Protocol (RTP), has gained widespread acceptance as the
transport protocol for video and voice on the Internet. RTP is used by H.323 terminals
as the transport protocol for multimedia. It provides services such as timestamping,
sequence numbering, and payload identification. RTP uses UDP in the transport layer.
It also contains a control component, the Real Time Control Protocol (RTCP), which
is used for loose session control, QoS reporting, and media synchronisation, among
other functions. One problem that is raising here is the flood of RTCP packets which
occurs when many users join a multicast RTP session at nearly the same time. The
IETF is developing also a protocols such as Session initiation protocol (SIP) for
multimedia session initiation. Since RTP was designed for multicast, it was
engineered to work well with both large and small sessions. The principle difficulty in
achieving scalability to large group size is the rate of RTCP packet transmission from
a host. If each host sends packets at some fixed interval, the total packet rate sent to
the multicast group increases linearly with the group size. As the group size grows,
the time between report from any one particular user becomes very large and may
easily exceed the duration of group membership. This means that timely reporting of
QoS problems from a specific user will not occur.

3.8 IETF Working groups

There are many other IETF working groups that are looking at a number of related
topics that are needed for mobility support. These include the following working
Groups (WG):
• IPNG (ipngwg) IP Next Generation (IPv6) WG is working on specifying the IPv6
protocol & its associated extensions.
• Point-to-Point Protocol Extensions (pppext) WG is defining the use of other
network layer protocols and options for PPP. This WG is also looking at layer 2
Tunneling protocols (l2TP included) for remote access to the internet and
corporate intranets.
• Dynamic Host Configuration Protocol (DHCP) WG will produce a protocol for
automated allocation, configuration and management of IP addresses and TCP/IP
protocol stack parameters.
• The DNS Incremental Transfer, Notification, and Dynamic Update WG is
concerned with three areas of future DNS protocol development.
• Remote Authentication Dial-In User Service (radius) WG.
• Roaming Operations (Roamops) WG. The purpose of this group is to develop or
adopt procedures, mechanisms and protocols to support user roaming among
groups of Internet service providers (ISPs). This is different from, but related to,
the work of the IP Routing for Wireless/Mobile Hosts Working Group (mobile
IP) in that the roamops group is not concerned with the movement of hosts or
subnets, but of users.
• Mobile Ad-hoc Networks (manet). A "mobile ad hoc network" (MANET) is an
autonomous system of mobile routers (and associated hosts) connected by
wireless links--the union of which form an arbitrary graph. The routers are free to
move randomly and organise themselves arbitrarily; thus, the network’s wireless
topology may change rapidly and unpredictably. Such a network may operate in a
standalone fashion, or may be connected to the larger Internet.
• IP Security (IPSEC) WG. The IPSEC will develop mechanisms to protect client
protocols of IP. A security protocol in the network layer will be developed to
provide cryptographic security services that will flexibly support combinations of
authentication, integrity, access control, and confidentiality.
• Resource Reservation Setup Protocol (RSVP). The primary purpose of this
working group is to evolve the RSVP specification and to introduce it into the
Internet standards track. The working group will also serve as a meeting place
and forum for those developing and experimenting with RSVP implementations.
⇒ References
[1] Lawrence S. Brakmo and Sean W. O’Malley, "TCP Vegas: New Techniques for
Congestion Detection and Avoidance," in SIGCOMM ’94 Conference on
Communications Architectures and Protocols, (London, United Kingdom), pp.
24-35, October 1994.
[2] Douglas E. Comer, Internetworking with TCP/IP Volume I, Englewood Cliffs,
New Jersey: Prentice Hall, 1991. (The book is a good description of TCP/IP
and associated protocols.)

[3] Sally Floyd, "TCP and Explicit Congestion Notification," ACM Computer
Communication Review, vol 24, pp. 8-23, October 1995.
[4] Sally Floyd and Van Jacobson, "Random Early Detection Gateways for
Congestion Avoidance," IEEE/ACM Transactions on Networking, vol. 1, pp.
397--413, Aug. 1993.
[5] Van Jacobson, "Congestion Avoidance and Control," ACM Computer
Communication Review, vol. 18, pp. 314--329, Aug. 1988. Proceedings of the
Sigcomm ’88 Symposium in Stanford, CA, August, 1988.
[6] Raj Jain, "A Delay-Based Approach for Congestion Avoidance in
Interconnected Heterogeneous Computer Networks," ACM Computer
Communication Review, vol. 19, pp. 56-71, Oct 1989.
[7] Zheng Wang and Jon Crowcroft, "Eliminating Periodic Packet Losses in the
4.3-Tahoe BSD TCP Congestion Control Algorithm," ACM Computer
Communication Review, vol. 22, pp. 9--16, Apr. 1992.
[8] Zheng Wang and Jon Crowcroft, "A New Congestion Control Scheme: Slow
Start and Search (Tri-S)," ACM Computer Communication Review, vol. 21, pp
32-43, January 1991.
[9] Ramon Caceres and Liviu Iftode. Improving the Performance of Reliable
Transport Protocols in Mobile Computing Environments. IEEE Journal on
Selected Areas in Communications, 13(5):850--857, June 1995.
[10] William Allen Simpson, editor. The Point-to-Point Protocol (PPP). RFC 1661,
July 1994.
[11] Glenn McGregor. The PPP Internet Protocol Control Protocol (IPCP). RFC
1332, May 1992.
4 Mobile Agent work

An agent can be described as a software component that performs a specific task
autonomously on behalf of a person or organisation. Therefore, it contains some level
of intelligence, ranging from predefined rules up to self-learning AI inference
machines. Thus agents may operate rather asynchronously to the user (they are often
event or time triggered) and may communicate with the user, system resources and
other agents as required to perform their task. Moreover, more advanced agents may
cooperate with other agents to carry out tasks beyond the capability of a single agent.
Finally, as mobile or even active objects, they may move from one system to another
to access remote resources or even meet other agents and cooperate with them.
In the context of this Deliverable the emphasis is on mobile agents, since the mobile
agent technology is ready to use and could provide more benefits in the field of
telecommunications than intelligent agent technology.

The envisaged advantages of Mobile Agents compared to traditional approaches for

client/server processing include among others:
• Asynchronous/autonomous task execution, i.e. client systems releasing agents
may terminate, while the agent independently controls the task execution;
• Reduction of network traffic and client processing power i.e. weak clients
may outsource tasks and low bandwidth environments (e.g. wireless) may be
used, since interactions are performed locally and only results may be trasnfered
via the network;
• Robustness: reduction of dependence of network availability and client/server
availability, i.e. already migrated agents are not anymore affected by network
failures/breakdowns;
• Automation of distributed task processing, i.e. agent performs predefined task
at different places based on iternary;
• Decentralised / local task processing i.e. dedicated agents are travelling close to
the resources and thereby enabling better performance through load balancing;
• Flexibility: On-demand software distribution / service provisioning, i.e. modular
service structure allows to download required or new functionality to dedicated
network nodes
• Network-centric computing / flexible end user systems, i.e. modular service
structure allows to download required or new functionality to end systems;
• Adaptation/Combination of existing services, i.e. agents may act as gateways
or filters integrating even multiple services.
The boom of research activities related to mobile agents started in the early 1990th. A
built on top of distinguished operating systems, based on different programming
languages and technologies. Even new languages have been realised, exclusively
designed for the support of mobile agents. However, within the last few years,
common trends can be noticed. Interpreter-based programming languages like Java
build the basis for most of today’s agent platforms, and several approaches are
associated to the integration of mobile agents and RPC-based middleware like the
Common Object Request Broker Architecture (CORBA) [CORBA-95]. In order to
establish a common basis for future developments and to enable the interoperability
of agent platforms of different manufacturers, several standardisation bodies have
been build.
4.1 Basic Capabilities of Mobile Agent Platforms

In course of time, several fundamental requirements for Mobile Agent Platforms have
been identified due to experiences that have been made during research and
development activities. These requirements have to be fulfilled by any state of the art
mobile agent platform.
⇒ Agent Execution Support
An agent platform must provide the capability to create mobile agents, taking into
account agent-specific requirements regarding the runtime environment. Before the
creation, the platform has to retrieve the agent’s code, that may either be delivered
during the creation request, or downloaded separately from an external code base.

⇒ Management Support
It is necessary for agent administrators to be able to monitor and control their agents.
The control aspect comprises among others the temporary interruption of an agent’s
task execution, its premature termination, or the modification of its task. The
monitoring of an agent is associated with its localisation in the scope of the whole
distributed environment. Regarding an agent system, all hosted agents as well as the
occupied system resources have to be monitored and controlled by the system
administrator.
⇒ Security Support
The privacy and integrity of agents as well as agent systems must be guaranteed
throughout their entire lifetimes. This requirement comprises the encryption and
decryption of agents during migration, the authentication and authorisation of agents
and agent systems, and access control regarding the resources of an agent system or
even of an agent offering some functionality.
⇒ Mobility Support
Of course, mobility is one of the most fundamental aspects. A special mobility
support must be provided by the platform, supporting remote execution as well as
migration. Note that the mobility aspect cannot be sufficiently handled without
regarding the security support mentioned above.
⇒ Support for Unique Identification
Mobile agents as well as agent systems have to be uniquely identifiable in the scope
of the entire agent environment. Thus, special support is required for the generation of
unique agent identifiers.
⇒ Transaction Support
An important requirement is the support of correct and reliable execution of agents in
presence of concurrency and occurrence of failures. Therefore, transaction support
must be provided.
⇒ Communication Support
Agents should be able to communicate with each other as well as with platform
services. Several mechanisms are possible, such as messages, method invocation or a
blackboard mechanism. Communication through messages may be done point-to-
point, by multicasting or broadcasting. Furthermore, agent communication includes
support for semantic analysis.

Agency (QKDQFHG
6HUYLFHV ID Security Agent Transaction
Information Generator Service Execution Service
Base Service
Agent Agent Agent

Transport Management Communication
Service Service Service
Network
Figure 32: Basic Capabilities of Mobile Agent Platforms

Further functional requirements may rise depending on concrete applications.
However, these additional features should be separated from the basic, inevitable
capabilities mentioned above. They should be handled as add-ons that can be
‘plugged’ into a core system in order to individually enhance its functionality. Apart
from these functional requirements, various generic demands have to be regarded,
such as performance, efficiency, portability, and support for the integration of legacy
components.
Figure 32 shows the structure of a core agency, comprising several services in order
to fulfil the basic functional requirements identified above. Note that some of the
services provide remote interfaces in order to be accessible by external actors, such as
other agent systems, agents, or human users.
Vicarious for the variety of today’s mobile agent platforms, the following list briefly
describes and compares five products: Telescript and Odyssey from General Magic
[GM], Aglets Workbench (AWB) from IBM [IBM], Voyager from ObjectSpace [OS],
and Grasshopper from IKV++ [IKV].
4.2 Integrating Mobile Agent Technology and CORBA

The Common Object Request Broker Architecture (CORBA) has been established as
an important standard, enhancing the original RPC based architectures by allowing
relatively free and transparent distribution of service functionality. Besides, mobile
agent technology has been proved to be suitable for the improvement of today’s
distributed systems. Due to its benefits, such as dynamic, on-demand provision and
distribution of services, reduction of network traffic and the reduction of dependence
regarding server failures, various problems and inefficiencies of today’s client/server
architectures can be handled by means of this new paradigm [Mag-96a]. However, for
several applications RPCs still represent a powerful and efficient solution. Thus, an
integrated approach is desirable, combining the benefits of both client/server and
mobile agent technology, and on the other hand eliminating or at least minimising the
problems that rise if one of these techniques is used as ‘stand-alone’ solution. Figure
33 shows this integrated approach by means of a distributed agent environment (DAE)
that is built on top of a CORBA distributed processing environment (DPE).

Provider System End User System SCP / SSP/ Switch

(SMS)
Agency Agency Agency

Distributed
Agent
Environment Enhanced Basic Enhanced Basic Enhanced Basic
(DAE) Services Services Services Services Services Services
Distributed
Processing
Communication Channel (ORB)
Environment
(DPE)
Figure 33: The Distributed Agent Environment

Today, the CORBA standards gain high acceptance in the world of distributed
computing. Various service specifications have been developed, providing
standardised, implementation-independent interfaces and a common protocol, and
thus enabling a high degree of interoperability between applications of distinguished
manufacturers. In contrast to this, mobile agent technology is driven by a huge variety
of different approaches regarding implementation languages, protocols, platform
architectures and functionality. In order to achieve a sufficient integration with
CORBA, a standard is required for mobile agent technology. This standard has to
handle interoperability between distinguished agent platforms, and the usability of
(legacy) CORBA services by agent-based components.
The idea behind the MASIF (Mobile Agent System Interoperability Facility) standard
is to achieve a certain degree of interoperability between mobile agent platforms of
different manufacturers without enforcing radical platform modifications. MASIF is
not intended to build the basis for any new mobile agent platform. Instead, the
provided specifications shall be used as an ‘add-on’ to already existing systems.
⇒ References
[ACTS-98] ACTS Agent Cluster:
http://www.fokus.gmd.de/ima/miami/public/service/agent_cluster
[Breu-98] M. Breugst, I. Busse, S. Covaci, T. Magedanz: ‘GRASSHOPPER - A
Mobile Agent Platform for IN Based Service Environments’, IEEE IN
Workshop, Bordeaux, France, May 10-13, 1998.
[Che-95] D. Chess, et. al.: ‘Itinerant Agents for Mobile Computing’, IEEE
Personal Communications Magazine, pp. 34-59, Vol. 2, No. 5,
October 1995.
[CORBA-95] OMG: The common object request broker: Architecture and
specification. Technical report, Revision 2.0, July 1995.
[FIPA] Foundation for Intelligent Physical Agents: http://www.fipa.com/
[IEEE-96] S. Krause , T. Magedanz: ‘Mobile Service Agents enabling
"Intelligence on Demand" in Telecommunications’, Proceedings of
the IEEE Global Telecommunications Conference, pp.78-85, ISBN:
0-7803-3336-5, IEEE Press, 1996.

[MASIF-97] Crystaliz Inc, General Magic Inc, GMD FOKUS, IBM, TOG: OMG
Joint Submission ‘Mobile Agent Facility’, November 1997, available
through ftp://ftp.omg.org/pub/docs/orbos/97-10-05.pdf
[Mag-96a] T. Magedanz, K. Rothermel, S. Krause: ‘Intelligent Agents: An
Emerging Technology for Next Generation Telecommunications?’,
in: Proceedings of IEEE INFOCOM ’96, pp. 464-472, IEEE Catalog
No. 96CB35887, ISBN: 0-8186-7292-7, IEEE Press, 1996 (San
Francisco, March 24-28 1996).
[Mag-96b] T. Magedanz, R. Popescu-Zeletin: ‘Intelligent Networks - Basic
Technology, Standards and Evolution’, International Thomson
Computer Press, ISBN: 1-85032-293-7, London, June 1996.
[Mag-96c] T. Magedanz, R. Popescu-Zeletin: ‘Towards Intelligence on Demand -
On the Impacts of Intelligent Agents on IN’, Proceedings of 4th
International Conference on Intelligent Networks (ICIN), pp. 30-35,
Bordeaux, France, December 2-5, 1996.
[RFP-95] OMG: Common facilities rfp3. Request for Proposal OMG TC
Document 95-11-3, Object Management Group, Framingham, MA,
November 1995.
[Zha-98] T. Zhang , T. Magedanz, S. Covaci: ‘Mobile Agents vs. Intelligent
Agents - Interoperability and Integration Issues’, 4th International
Symposium on Interworking, Ottawa, Canada, July 6-10, 1998.

ATM en Móviles

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ATM en Móviles

Uploaded by

Copyright:

Available Formats

Project P810

Wireless ATM Access and Advanced Software

For full publication

This document contains material which is the copyright of certain EURESCOM

 1998 EURESCOM Participants in Project P810

 1998 EURESCOM Participants in Project P810 page i (x)

page ii (x)  1998 EURESCOM Participants in Project P810

 1998 EURESCOM Participants in Project P810 page iii (x)

Jean-Marc Lafond CNET France Telecom

page iv (x)  1998 EURESCOM Participants in Project P810

 1998 EURESCOM Participants in Project P810 page v (x)

page vi (x)  1998 EURESCOM Participants in Project P810

CTD Cell Transfer Delay

 1998 EURESCOM Participants in Project P810 page vii (x)

page viii (x)  1998 EURESCOM Participants in Project P810

RAISIN RAINbow extenSion for trial INtegration

 1998 EURESCOM Participants in Project P810 page ix (x)

WAND Wireless ATM Network Demonstrator

page x (x)  1998 EURESCOM Participants in Project P810

2 Overview of mobile and wireless networks

2.1 Third Generation Mobile Systems

2.1.1 UMTS (ETSI)

UMTS stands for Universal Mobile Telecommunications Service. It is the European

 1998 EURESCOM Participants in Project P810 page 1 (51)

9. Radio resource flexibility to multiple networks and traffic types within a

page 2 (51)  1998 EURESCOM Participants in P810

UMTS Services: SMG 1

UMTS Generic Radio Access: SMG 2

GSM Core Network Evolution: N/B ISDN Core Network Evolution:

Figure 1: Organisation of UMTS standardisation

 1998 EURESCOM Participants in Project P810 page 3 (51)

• UMTS standards: end 99

Figure 2: Evolution of the GSM network towards UMTS network

page 4 (51)  1998 EURESCOM Participants in P810

CAMEL, MEXE, MS API …) used in a co-operative manner (e.g. a service

Figure 3: Possible UTRAN Architecture

Figure 4: RNS Architecture

 1998 EURESCOM Participants in Project P810 page 5 (51)

Iu interface would then be to provide adaptation between different transport

page 6 (51)  1998 EURESCOM Participants in P810

2.1.2 IMT-2000 (ITU)

IMT-2000 (International Mobile Telecommunication) are third generation mobile

 1998 EURESCOM Participants in Project P810 page 7 (51)

Examples of IMT-2000 multimedia services which could be supported by one or

page 8 (51)  1998 EURESCOM Participants in P810

UIM - MT MT - RAN RAN - CN NNI

Figure 5 : Physical interfaces of an individual IMT-2000 family member

 1998 EURESCOM Participants in Project P810 page 9 (51)

Core networks of other IMT-

UIM-MT MT - RAN RAN - CN CN - CN

Figure 6: Functional communication of an individual IMT-2000 family member

page 10 (51)  1998 EURESCOM Participants in P810

⇒ Minimum Performance Capabilities for IMT-2000 Candidate Radio

Support of general Required / Not Required / Not required Required / Not

Table 1: Minimum performance capabilities for IMT-2000 Candidate - Radio

 1998 EURESCOM Participants in Project P810 page 11 (51)

2.1.3 European Projects

FRAMES (Future Radio Wideband Multiple Access Systems) is an ACTS project

A dm ission Control Radio Bearer Radio Resource Inter-C ell H andover

Logical Link Control

Radio Link Control Link A daptation

MUX M edium A ccess Control Resource A llocation

Figure 7: Radio interface of FRAMES