Wireless Future - Telenor

Protocol) and RSVP [8] (Resource ReSerVation
Protocol).
The other approach has been termed Adaptive
QoS Middleware. This consists of both an
enhanced end terminal stack as well as QoS brokers,
mobility gateways and media filters located
within the network – forming a complete distributed
architecture for QoS management (Figure
3). Applications are presented with a standard
API, rather than having to deal with session
and QoS negotiation and violations themselves.
The BRAIN project has recognised the merits of
both approaches and developed a modular, component-based
architecture that encompasses
both. We have designed enhancements to the terminal
stack (Figure 4) that provide interfaces to
a number of different application types: legacy
(type A); those that utilise session protocols
(type B); those that can make use of a component
API (providing frame grabbers, packetizers
...) (type C); and those that can make use of a
full blown QoS broker to deal with all connection
issues (type D).
The QoS enabled transport interface, also called
Service Interface (SI), allows a complete separation
of the BRENTA from a specific network
implementation which could be provided by
over-provisioning or by more complex protocols
such as RSVP. Well-known transport primitives
at the SI interface will be enhanced by additional
primitives to give applications the facility to use
QoS, with a specific focus on the needs in the
wireless and mobile domain.
The Access Network
The BRAIN Access Network (BAN) (Figure 5)
is intended to be deployed over a campus sized
area – a city centre, Science Park or airport.
Within this domain it will offer terminals Quality
of Service (QoS), Terminal Mobility and
Vertical Hand-over support. Personal mobility
and service creation will largely reside outside
of the BAN.
Terminal mobility will be provided by a modified
micro-mobility protocol such as MER TORA [9],
[10] or HAWAII [11]. A mobile host terminal
will acquire an IP address for at least the duration
of a session and the routers of the BAN will create
per-host entries to allow packets to reach the
mobile, wherever it moves within the domain. At
present the BRAIN project is evaluating the currently
proposed protocols for micro-mobility
against an evaluation framework [12] derived
from the perceived requirements from the usage
scenarios outlined above.
The evaluation framework consists of three
parts. Firstly a deconstruction of the protocol
Telektronikk 1.2001
Application
Session
layer
Transport
layer
Network
BRAIN
Air Interface
layers
Type A Type B Type C Type D
design issues involved: fast handover, paging,
security, address management and so on. Secondly
a classification of micro-mobility protocols
against these design issues. Finally an evaluation
against requirements such as scalability,
robustness and efficiency.
Results present so far ([12], [13], [14]) show that
there are only three fundamental approaches to
IP micro-mobility and that a per-host routing
approach is probably optimal – for BRAIN scenarios.
Another important area of BRAIN research is to
produce an interface definition for the layer2/3
User
Equipment
BRAIN
ACCESS
NETWORK
BRAIN
Wireless
Routers
BRAIN QoS
Broker GUI
Broker BRAIN high level API
BRAIN component level API
Session layer protocols (H.323, SIP;...)
QoS enabled transport interface
QoS and mobility support
Transport layer
IP layer supporting QoS and mobility
Service Specific Convergence Sublayer for IP
HIPERLAN/2 DLC layer
HIPERLAN/2 physical layer
BRAIN Mobility
Gateway
Figure 4 BRAIN End Terminal
Stack
Figure 5 The BRAIN IP
access network
IP Network
BRAIN ACCESS
NETWORK
QoS
Mobility Management
Control
61