session ii: mobility - tina-c · tcsm tla eml cp ne ne fcc cc ccf csm csmf lnc eml cp nml cp tm...

1

Session II: Mobility

Chair: Choong Seon Hong, Korea Telecom

1

TINA architecture extensions tosupport terminal mobilityFrans Panken: Lucent Technologies

Spyros Batistatos, Kostas Zygourakis: IntracomKimmo Raatikainen : University of HelsinkiSebastiano Trigila : Fondazione Ugo Bordoni

TINA'99; 12-15 April, Hawaii Frans Panken Slide 2

Outline• Background• Introduction of problem area: handover• Description of approach• Explanation of the solution• Implementation notes• Conclusions

2


Background: ACTS project DOLMENDevelop, validate and promote a service architecture

applicable to fixed and mobile, heterogeneous andmulti-provider, telecommunications networks1. By extending TINA models and definitions2. By implementing a service machine3. By exercising the service machine


TINA + Mobility Extensions = OSAM

3


Mobility extensions by OSAM1. Towards personal mobility

– New roles in the TINA business model– New concepts of UA home and UA visited– New reference points

2. Towards terminal mobility– Concept of mobile DPE and mobile bridging– Handover awareness in TINA– Mobile resource adaptation


Challenges to terminal mobility• Mobile systems, of the future, will allow just

one single point of presence of roaming terminal• Handover should be possible between different

technologies and between different connectivityproviders

• Quality of service in mobile environmentsshould be guaranteed

4


Handover types• Backward handover• Forward handover• Handover with macro-diversity• Soft handover• Hard handover


Handover cases

subnetwork subnetwork

layer network

layer network layer network

connectivity provider connectivity provider

MobileStation

MobileStation

MobileStation

MobileStation

MobileStation

4 3 2 1

5


TINA stakeholders involved• Connectivity provider

– On its own– In agreement with consumer

• Consumer (terminal / user)• Retailer


Solutions• Bottom-up approach for the three phases of

handover: initiation, decision and execution• Upgrade of TINA NRA• Abstraction of resource adapter for wireless

networks

6


Handover phases1. Handover information gathering phase:

– Identify the need for handover

2. Handover decision phase:– Determine whether and how to perform

handover

3. Handover execution phase:– Execute the actual re-routing of connections


Information gathering phase (1/2)• Measurements

– Radio link quality– Target radio access node

• Handover policies– Profile and service information (user & provider)

• Operation criteria

7


Information gathering phase (2/2)Extending TINA’s computational model

• Measurements:– Mobile station Measurements (MSM)– Radio Access Node Measurement (RANM)

• Handover policies:– User handover profile (UHP), Terminal Handover

Profile (THP)– Connectivity Provider Handover Profile (CPHP)

• Handover Initiator (HoI)


Service components ServiceSession

CommunicationSession

ConnectivitySession

LayerNetwork

Subnetwork

Subnetwork

SML

NML

EML

NEL

ConsumerDomain

Mobile terminal Radio Access Nodes Core Network

RetailerDomain

TCSM

TLA

EML CP

NE NE NE NE NE

FCC CC CCF

CSMFCSM

LNC

EML CP EML CP EML CP EML CP

NML CP NML CP

TM TM

LNCConnectivity

ProviderDomain

HoI: Handover InitiatorHP: Handover Profile

MSM:HTA: Handover Terminal Agent

HoC: Handover Co-ordinator

RANM: Radio Access Node MeasurementsMobile Station Measurement

MSM RANM

Computational modelHandover information gathering phase

HoI HoI

THPCHP

Key:DOLMEN-relatedhandover components

8


Handover decision phase• Discover reason for handover• Possible conflicts network / terminal• Find the network control point• Determine handover type• Consider constraints on handover completion time• Determine layer network limitations• NRA extension: 2 components:

– Handover Coordinator (HoC)– Handover Terminal Agent (HTA)


Computational modelHandover decision phase

Service components ServiceSession

CommunicationSession

ConnectivitySession

LayerNetwork

Subnetwork

Subnetwork

SML

NML

EML

NEL

ConsumerDomain

Mobile terminal Radio Access Nodes Core Network

RetailerDomain

MSM RANM

HoI HoI

CHP

THP

TCSM

TLA

EML CP

NE NE NE NE NE

FCC CC CCF

CSMFCSM

LNC

Key:

DOLMEN-relatedhandover components

EML CP EML CP EML CP EML CP

NML CP NML CP

TM TM

LNCConnectivity

ProviderDomain

HoI: Handover InitiatorHP: Handover Profile

MSM:HTA: Handover Terminal Agent

HoC: Handover Co-ordinator

RANM: Radio Access Node MeasurementsMobile Station Measurement

HoCHTA

9


Handover execution phase• Control point of transfer• Combining and multi-casting• Re-routing:

– set up new connections– release superfluous connections

• Bridge (or tunnel) data to prevent loss of data• Security functions


Mobile network adaptation (1/2)• Introduce QoS and traffic classes to support

streams and kTN traffic on a variety ofmobile wireless networks

• Common transport service that can beadapted to different wireless networks

10


Mobile network adaptation (2/2)

MNA_network

TLA

ControlChannel

ControlChannelkTN

TN TNTN

Mobile Terminal Radio Access Node

Wireless Connection

ControlChannel

kTN

CP_mobile

TN channels

ATM Connections

ControlChannel

Control

Stream Interface

ApplicationStream Interface

Application

MNA-lib

MDBR MNA-lib

FDBR

MNA_master

MNA_terminal

ATM_adapter

Control Control

TerminalRAN

Controller

NetworkRAN

Controller


International trial

FIN Connectivity Provider

FIN Retailer

Conn. ProviderSoftware

LAN

LAN

WLANBase Station

ATM Switch

Mobile TerminalConsumer Software

UK ConnectivityProvider

GSMBase Stations

GSMBase Station

Controller SS7 IWF

ATM Switch

LAN

IP Router IP Router

LAN

ApplicationServer

Web Server

SS7 IWF

3rd partyService Prov.

Consumer

Internet

ApplicationServer

Web Server

Service NodeRetailer Software

Service NodeRetailer SoftwareConn. Provider

Software

Service Access Nodes

Mobile LNSoftware

ATM SwitchOMS station

Mobile TerminalConsumer Software Consumer

GSM BSC

DACS

MSC Functionality

(V.24 in and IP out)

UK Retailer

FIN ConnectivityProvider

Service AccessNode

Mobile LN Software

11


Experiments• Three different layer networks:

GSM, WLAN & ATM• Two applications to exercise the service

machine:audio conferencing & information browsing

• Handover:– Backward: software buttons– Forward: hardware suppression of radio link


Conclusions• Refinement of TINA NRA to support all

three phases of handover• Handover between different layer networks,

and different connectivity providers• Reliable and seamless handover by means of

mobile network adaptation

1

TINA’99 - Oahu, Hawaii, April 1999 1

A TINA-based Environment forMobile Multimedia Services

Alexandre Souza PintoEduardo Jacob de Oliveira

Luis Fernando FainaEleri Cardozo

State University of Campinas - UNICAMPSchool of Electrical and Computer Engineering

Campinas - SPBrazil


Research Goals

To develop distributed infrastructures for supportingmultimedia services over high speed networks(Internet, Intranets, VPNs, Public Networks, etc.).

Special Interests:• open standards (TINA, ODP, CORBA, TCP/IP, ...)• mobility (user, session, terminal)

2


Research Status

• CORBA-compliant TINA DPE

• WWW-compliant TINA Service Architecturecomponents


DPE Architecture

RTP

TCP / UDP ATM AAL5

HARDWARE

NCCE

StreamFacilities

Life-cycleFacilities

DPE Interface

OODBMS

Object Request Broker (ORB)

3


Life-cycle Facilities

• Allow distributed objects to be deployedand managed across the network

• Follow the ODP engineering viewpoint:> engineering computational object> cluster> capsule> processing node


Engineering Computational Objects

I1

I2 I3

TINA Object(computational viewpoint)

TINA Object(engineering viewpoint)

I2 I3

I1

ManagementInterface (MI)

I1 I2 I3

CORBA Objects

MI

eCO Manager

TINA Object in CORBA(engineering viewpoint)

eCO

4


Clusters

ClusterManager

channel


Capsules

ClusterManager

ClusterManager

ClusterManager

Capsule Manager

ApplicationFactory

ManagementFactory

CORBA Servant

5


Nodes

Node Manager

CapsuleCapsule

Capsule


Management Interfaces

interface eCOManager { long addInterface ( in Object interface_ref ); long removeInterface (in Object interface_ref ); sequence<Object> getInterfaces ( ); long checkpoint ( in string template ); long recover ( in string template ); long Delete ( ); long deactivate ( in string template );};

6


Management Interfaces - cont’d

interface ClusterManager { eCOManager makeECO (in string object_name ); sequence<eCOManager> getECOs ( ); long checkpoint ( in string template ); long recover ( in string template ); long Delete ( ); long deactivate ( in string template );};



interface CapsuleManager { ClusterManager makeCluster ( in string cluster_name ); sequence<ClusterManager> getClusters ( ); long reactivate (in string cluster_name, in string template ); long migrate ( in string cluster_name, in string capsule_name, in string node_name );};

7


interface NodeManager { long createChannel ( ... ); long destroyChannel ( in ChannelCtrl the_ctrl );};



Stream Facilities

• Allow the establishment, control and managementof audio and video streams

• Based on the OMG specification Control andManagement of Audio/Video Streams (A/V Streams)

8


A/V Streams - Overview

StreamControl

StreamEndpoint

StreamEndpoint

VirtualDevice

VirtualDevice

Multimedia Device

A-side

StreamEndpoint

StreamEndpoint

VirtualDevice

VirtualDevice

Multimedia Device

B-side

Stream

Flows


Migration Issues

In our DPE implementation clusters migratethrough deactivation followed by reactivationin another capsule.

9


Migration Issues - cont’d

Capsule Manager

ApplicationFactory

ManagementFactory

Capsule Manager

ApplicationFactory

ManagementFactory

ClusterManager

ClusterManager

1. migrate (cl1, cap2, host2) 3. reactivate (cl1, t1)

2. deactivate (t1) 5. reactivate (t1)

4. createClusterManager (cl1)

6. createApp ( ... )



How to migrate stream endpoints with the cluster’sobjects ?

1. by migrating multimedia devices with the cluster

2. by extending the stream control operations inorder to facilitate stream reconfiguration

10



interface AppMMDevice : MMDevice { long checkpoint ( in string template ); long recover ( in string template ); long Delete ( );};

interface AudioDevice : AppMMDevice { };

interface VideoDevice : AppMMDevice { };



interface ChannelCtrl : StreamCtrl { long configureChannel ( ... ); long configureEndPoints ( ... ); long deactivateChannel ( ); long reactivateChannel ( ); long changeEndPoint ( ... );};

11


Migration Issues - Example

Microphone Speaker

AudioDevice

Cluster Cluster

AudioDevice

audio channel

AudioStreamCtrl

migration


Migration Issues - ExampleClient Source

CapsuleCluster 1 eCO 1 AppMM

Devicemigrate (cl1, cp2, h2)

deactivate(t1) deactivate(t1)

checkpoint(t1)

Delete()

deactivateChannel()

Cha

nnel

Ctr

Des

tinat

ion

Cap

sule

reactivate(cl1, t1)

recover()recover() recover()

changeEndPoint( ... )

reactivateChannel()

12


Mobile Application

StreamFacilities


as-UAP(applet)

ss-UAP(applet)

PA(applet)

N

DPE Interface

StreamFacilities


WebServer

HTTP UA SSM IAServiceFactory

ChannelCtrl UAIIOP

IIOP

RTP/UDP

Pro

vide

r D

omai

nC

onsu

mer

Dom

ain

cluster capsule

Web Browser

ORB (Orbix)

ORB (Orbix)

ORB (OrbixWeb)

DPE Interface


Mobile Application - cont’d

13


Mobile Application - cont’d


Concluding Remarks

• A DPE must address migration in acomprehensive manner

• TINA Service Architecture can turnInternet applications into Internet services

• CORBA, Web and TINA fit well !

14


Research Directions

• A fully Java-based DPE based on components

• Frameworks for service developments

• Clusters as mobile agents

• Total migration transparency

1

1TINA ’99, 13 April 1999

Experience lessons from extendingthe TINA service architecture

with user mobility

Hessel Idzenga, Frans Panken Lucent Technologies

Clair MooreKPN Research

213 April, 1999

Outline

• Background: DOLMEN• Separation of UAH & UAV• Service federation• Performance measurements

2

313 April, 1999

Trends–market penetration of mobile phones

increases: GSM, UMTS, IMT-2000– fixed-mobile convergence–separation of access, transport and

services–network-independent service layer–services offered to roaming user

independent of location

413 April, 1999

Mobility extensions by OSAM• Towards personal mobility

– New roles in the TINA business model– New concepts of UA home and UA visited– New reference points

• Towards terminal mobility– Concept of mobile DPE and mobile bridging– Handover awareness in TINA– Mobile resource adaptation

3

513 April, 1999

Roaming users• Split of UA

UA HomeUA Visited

• UAV: operationalcomponent

• UAH: “database”component

UAV UAH

IA

PA

Start session

End session

Receive invitations

Personal profile

Subscriptions

Registrations

Credentials

UA

home domainvisited domain

613 April, 1999

Access scenario

PA IA

RequestNamedAccess(userID, credentials) SecurityInfo

(userID, credentials)

OK

UAH

Terminal Visited domain Home domain

UAV

Return(UAV_ref)

create

getSubscriptionInfo

subscriptionList

getPersonalProfile

personalProfileOK

4

713 April, 1999

SSM

DomainIdReq(serviceType)

return (domainID)

InviteUser(inviteeID, sessionDescr.)InviteInSession (inviteeID,sessionDescr.)

InviteInSession (inviteeID,sessionDescr.)

OKOK

Other Domain

Invite(User @homeDomain)

Registration and invitation

PA UAV

RegisterUserReq (serviceType, terminalID) RegisterUserReq

(serviceType, domainID)

OKOK

UAH

Terminal Visited domain Home domain

813 April, 1999

• Disadvantages– 6 session components per session + 2 peer agents.– master-slave: who is in charge of the session, who

selects connectivity provider– Peer Agent is actively involved in each federated

session

Service Federation• service session spanning 2 service domains• TINA approach:

– service contract– PeerUSMs, PeerAgents

Domain 2Domain 1PeerAgent

USM

SSM SSM

Peer USM

Peer USM

USM

PeerAgentSF SF

create create

5

913 April, 1999

Domain 2Domain 1

Service Federation, accessDOLMEN approach

• service contract• access session

between domains• Service Federation

at SF levelIF 1

SF 1 SF 2SF_Fed SF_Fed

IAPA

IF 1

NamedAccessReq(serviceproviderName)

NamedAccessReq(serviceproviderName,

SF_1ref)

SF_1ref

SF_2ref

SF_2ref

Service Federation

1013 April, 1999

Domain 1

Service Federation, usageDOLMEN approach

USM1

SSM1

SF1

create

Domain 2

SF2CreateFedUSM

USM2

USM ref

create

6

1113 April, 1999

AdvantagesSimplicity:

– Re-use of the access session components,– Avoids involvement of Peer Agents in usage,– Avoids peerUSMs that obscure the control of

the session with regard to master or slave role,

while maintaining service contract and controlover access

1213 April, 1999

Implementation• Using standard

component template– provide IDL and

component configuration,framework code isgenerated

– delegation of interfaceinvocations to Coreobject

• Demonstrated in NHs ofUK and Finland

Core

Factory

Admin

Core

Interface object

Container

7

1313 April, 1999

Creating a UAH

0

500

1000

1500

2000

2500

1 5 10 15 20 25Number of users

Mem

ory

use

[Kby

tes]

Total work set sizeText work set sizeNon text work set size

1413 April, 1999

Set up of an access session, UAV

0

500

1000

1500

2000

2500

3000

3500

1 5 10 15 20 25Number of consumers

Mem

ory

use

[Kby

tes]

Total work set size

Text work set size

Non text work set size

8

1513 April, 1999

Set up of audio session

0 500 1000 1500 2000 2500 3000 3500

UAH-RetUK

UAV-RetUK

USM-RetUK

SSM-RetUK

UAH-RetF

UAV-RetF

USM-RetF

SSM-RetF

Memory usage [Kbytes]

Non-text work setText work set sizeTotal work set size

1613 April, 1999

Conclusions• Ret RP syntax OK; semantics poorly defined:

properties, name-value pairs, any’s• Service Federation made straight-forward with SF-

federation• Component template useful for uniform coding style

and for re-use of components• Performance evaluation:

– no excessive memory when # consumers increases– UAV more demanding than UAH– uniform memory usage among components in audio session

session ii: mobility - tina-c · tcsm tla eml cp ne ne fcc cc ccf csm csmf lnc eml cp nml cp tm...

Documents