1 Mobility and Intelligence in Telecom: How and where to handle it? Lill Kristiansen, Prof. Dr. Scient Dept. of Telematics, NTNU, Norway lillk

1

Mobility and Intelligence in Telecom:How and where to handle it?

Lill Kristiansen, Prof. Dr. Scient

Dept. of Telematics, NTNU, Norwaywww.item.ntnu.no/~lillk

[email protected]

2

My history (brief)

1979 - 1993 Univ. Of Oslo, Norway Studies in mathematical logic and computer science

1993 - 1998 Telenor R&D IN and TINA work Including TINA core-team work in ’96-’97

1998 - 2001 Ericsson AS, Norway Work on IP-telephony, (H.323 Gatekeeper, IPT2.0 ++) Work with standardization (ETSI Tiphon, 3GPP, OSA)

2003- - > Telematics, NTNU System engineering issues Network and services issues Involved in ARTS project (www.pats.no)

3

Outline of the talk

Selected aspects of IS/IT and telecom

TINA Service Architecture Mobility and middleware

Convergence: IS/IT + telecom = ICT Access antagonistic system Nomadism and mobility

A look back to design issues in 3GPP IMS (’99) Competition vs standardization Real time and scaling issues

TINA, middleware and telecom issues

Further research issues

4

Traditional Telecom ’Grade’

Global distribution: A

Real time issues A

Scalability A

Availability (’5 nines’) A Handling of partial failures A

Time to market, new features D/E ’Quality’ of new features A/C/E

User interfaces fixed phones D/Emobile phones A/C

Rich information services: D/E

5

IS/IT Aspects: ’Grade’

Global distribution: early: Dlater: B

Real time issues C

Scalability B/C/D

Availability (’5 nines’) D/E Handling of partial failures (see previous bullet)

Time to market, new features A/B ’Quality’ of new features C

User interfaces early: D| later: A/B

Rich information services: A

6

GUI for programming PBX phone

Absence codes:

0: on training1: busy2: at home3: meeting4: lunch (23 minutes)5: out of office6: ill7: travelling8: vacation

Remember: date is MMDD

Examples:*23*1*1200# busy ‘till 1200*23*1# busy rest of day*23*4# lunch (default 23 min.)*23*7*0618# travel ‘till June 18#23# cancel absence

7

TINA

TINA-C core team: ’92- ’97 Tina T: ??-??

8

TINA Telecommunication Information Newtorking Architecture

TINA was based on ODP

Aiming at ’advanced networked information services’ over a DPE (distributed processing environment) The DPE may support ’object mobility’

TINA also supported personal mobility

Some open questions to TINA Interworking with legacy, ++ In TINA ’every service is a service’

No distinction on persistent data vs call state data

Real time and scalability issues?

9

TINA entities and domains

10

TINA Service Architecture

The TINA session concepts: Access session

log on, and start service Service session

(e.g. A telephony multi party multi media service), Communication sessions (the actual media streams)

TINA separates service network and transport network. Somewhat similar to the layered approach in IMS/3GPP

TINA separated out several business roles: Service provider role Content provider role Transport provider role

BAD: Business Administrative Domain carrying out one or more of these business roles

11

TINA Agents

UserAgent (UA) A representation of the user in the domain of the service

provider A network centered entity Not to be confused with SIP UA:

SIP UA-client and UA-server are both on the endpoint

ProviderAgent (PA) A representation of the service provider in the domain of

the enduser

USM, SSM: (call) service session objects

ss-UAP: service specific UserAPplications

12

TINA: The UA and personal services

User Agent: A simple way to implement personal services

But: Some issues with the lack of an access network All EU-projects looking into TINA and wireless mobility introduced

an access network Some introduced mobility of the UA from home domain to the

visited domain This may easily destroy the concept of non-standardized, competitive

services, offered by personal UA, and personal USM

The statement ’UA is at home’ requires that even though the DPE may offer some object

mobility, the objects should not move freely around and into machines operated by others

This is somewhat in conflict with general DPE figures

13

General mobility definitions

Terminal mobility is the ability of a terminal to change physical location. This includes terminals which can continue to support services while moving, and those that cannot. (From TINA-C) Similar definitions are given in standardization documents

describing currently existing mobile systems.

Service mobility (of a particular service) is defined as the ability for a user to obtain that particular service independently of user and terminal mobility. (Ericsson contribution to ETSI Tiphon 1999) Mobility of my mail service

Implemented by web based interface (on PC and PDA-phones)

Mobility of my voice telephony service Partly implemented by GSM (1-1 relation user/terminal)

14

Personal services

Personal mobility enables users to use services that are personalized with their preferences and identity ubiquitously, independently of both physical location and specific equipment. … (From TINA-C in the mid-90’ties)

Note the similarity between TINA personal mobility and 3GPP virtual home environment (VHE) (More later)

15

TINA DPE and ’mobile objects’

Objects ’float freely’ on top of the DPE

Object mobility and other DPE services are assumed

The domain boarders are not shown In contrast

with previous TINA figure 15

16

A typical CORBA / ODP figure:

Object Services Common Facilities

Application interfaces Domain interfaces

Object Request Broker (ORB)

Object mobility and other DPE services are assumed

The domain boarders are not shown

The network(s) are not shown no kTN

nor TN

17

Turing Machines and Computations

18

’Data’ and ’code’:Theoretical and practical issues

According to (Gödel and) Turing: There exist one Universal Turing machine that can

simulate every other machine, i.e., take every other machine (’code’) as (data) input

Theory: There is no real difference between ’data’ and ’code’ Imply the unsolvability of the Halting problem etc

Praxis: In order to control real time and scalability issues we need to separate data and code. Code is some software executed on some HW

We separate functional req. and non-functional req

We may use SDL + TIMe method (from R. Bræk ’93)

19

Implementation design (TIMe)BLOCK TYPE LocalStation 1(1)

Panel

DOOR

LSControl

[(validity)]

[code]

[opened, closed]

[open, close]

[(inp)][(out)]

[(validity)] [Code]

P1

CE

CU

D

C

e

[(inp)][(out)]

[(validity)] [Code]

BLOCK TYPE LocalStation 1(1)

Panel

DOOR

LSControl

[(validity)]

[code]

[opened, closed]

[open, close]

[(inp)][(out)]

[(validity)] [Code]

P1

CE

CU

D

C

e

[(inp)][(out)]

[(validity)] [Code](*): Datacomm.

Note: Operating system and Error handling interface to all other blocks.

Operating system

Message routing

Error handling

SS TYPE General

(*): Application

(*): In /Out

communication network

field bus

(*): Datacomm.

Note: Operating system and Error handling interface to all other blocks.

Operating system

Message routing

Error handling

SS TYPE General

(*): Application

(*): In /Out

communication network

field bus

Software

Hardwarecommu- nication network

(*): Controlled process

field bus

Local computer

Process Interface

(*):

(+): Local hardware

Central computer

Terminals

(+): Central hardware

HS TYPE General hardware

<1> <1>

<1> Execute SS TYPE General

communication network

(*): Controlled process

field bus

Local computer

Process Interface

(*):

(+): Local hardware

Central computer

Terminals

(+): Central hardware

HS TYPE General hardware

<1> <1>

<1> Execute SS TYPE General

represents

Implemented by

represents

Executed on

20

Agent definitions

Agents may be classified by their mobility, i.e. by their ability to move around some network. This yields the classes of static agent or mobile agent.

Secondly, they may be classed as either deliberative agent or reactive agent. Deliberative agents derive from the deliberative thinking

paradigm: the agents possess an internal symbolic, reasoning model and they engage in planning and negotiation in order to achieve coordination with other agents.

(Definitions from Nwana, IS/IT)

21

Mobility and mobile code

Service mobility is not a synomym for mobile code

GSM (and 3G) systems uses no mobile code Instead some ’user data’ are sent from HLR to VLR/MSC,

and call-related service (e.g., the call forwarding service CFNR) is executed locally in the MSC in the visiting domain.

The CFNR service reside in every MSC at all times Because CFNR is a standardized service

22

Reference figure:standardization vs competition in 2G

Home-NW

End-point

V/access-NW

End-point

S)

C)

Home-NW

V/access-NW

A Side (originating) <-- --> B side (terminating)

Home-NW

End-pointEnd-point

V/access-NWV/access-NW

End-pointEnd-

point

S)

C)

S)

C)

Home-NW

V/access-NW


MSC HLR

IN

23

SDL and agents: upgrades and ‘learning’

SDL is an abstraction of static, reactive agents (after Nwana’s definition)

Telecom systems (like GSM, PSTN, UMTS, IMS) are often modeled using SDL

When we upgrade the existing telecom system this is not done during active calls, but as a management service

If we consider such management services, we may say that also mobile agents are used in telecom today

Some Frameworks for Plug-And-Play (ServiceFrame, maybe Tapas) assumes that role negotiation (and hence ’learning’) takes place during call-related services In that case we may say that dynamic, deliberate agents are also

in use. ServiceFrame still models with EFSM, which scales well

24

Some issues in ODP used in telecom

Coming from the IS/IT side ODP/CORBA works well for data services. In IS/IT we have fewer, bigger objects, as well as less

realtime requirements

BUT 2 important questions: Realtime Scalability

We will look a little bit closer into real time issues and mobility

25

Discrete and continuous mobility

Continuous = During call call related services during call setup (ex CFU ->

VM) during active call (e.g. handover in GSM)

Discrete = not during a call, non-call related service execution such as:

Log on / registration from a mobile Activating call forwarding to voicemail (VM)

Alternative terminology from the IS/IT-side During service session Between service sessions

26

Call-related, non-call relatedand management services

What someone consider ‘discrete’ other consider ‘continuous’, this depends on the service session E.g. performing ‘modem hijacking’ during a web-browsing

session is considered ‘continuous’ in this setting, from the service point of view

Different services have different real time requirements, Call related:

strong real time requirements

Non-Call related: medium real time requirements

Management related medium to loq teal time req.

27

Nomadism

ConvergenceThe IMS system from 3GPP

28

Convergence: Towards IMS and IP

New network architecture Access antagonistic New handling of user and terminal issues

Many terminals per user Many access technologies (also wired access, WLAN, Utran,)

Competition and time to market TINA ’Co-operative solution …competitive world’ Fast, rich, new services, personalization

29

System topology

Today

• Separate Networks • Separate Users • Separate Services

Tomorrow

• Separate Accesses• Same Core network• Same User on different accesses• Same Services

Dat

a/IP

Net

wo

rks

Dat

a/IP

Net

wo

rks

PL

MN

PL

MN

PS

TN

/ISD

NP

ST

N/IS

DN

CA

TV

CA

TV

Separate Services

Separate users

30

UMTS from release 5: IMS: IP Multimedia Subsystem

Same Core network

Same User on different accesses

Same Services

I can use WLAN, ADSL, LAN, UTRAN (GPRS) etc. as accesses in ONE system

I can have several devices and move between them

Servers

Users

Backbone Network

AccessAccess

Communication Control

Content Content

Access

31

Reference model wireless, mobile, nomadic

wirelesswireless

FixedFixed

Fixed user

Own PC/Fixed PhoneFixed relation

My SIM card and my phoneFixed relation’Mobile’

May be a dynamic relation between user and terminal

Future

Nomade

32

UMTS IMS architecture HSS: Home

SubscriberServicesHLR-like

CSCF: ’Call Server’Call/SessionControl Function

P-CSCF Proxy-

I-CSCF Interrogating-

S-CSCF Serving-

xGSN GPRS-noder

Visited B

Home A

Visited A

Home B

GGSN

SGSN

Radio Access Network

GGSN

SGSN

Radio Access Network

P-CSCF

I-CSCF

HSS HSS

S-CSCFI-CSCFS-CSCF

P-CSCF

BA

33

1

2

5S-CSCFS-CSCF

Home A

P-CSCFP-CSCFVisited A

8GGSNGGSNSGSNSGSN

Radio Access NetworkRadio Access Network

7

I-CSCFI-CSCF6

A

UMTS IMS registration

843 7

Location UserProfile

HSS

34

1

2

7 8

96

3 4

5

P-SCSFP-SCSFVisited B

S-CSCFS-CSCF

Home A

10

1112

13

P-CSCFP-CSCFVisited A

A B

18GGSNGGSNSGSNSGSN


GGSNGGSNSGSNSGSN


17

S-CSCFS-CSCF

Home B

I-CSCFI-CSCF

HSSHSS

1415

I-CSCFI-CSCF

HSSHSS

16

UMTS IMS call flow

35

Including value added services

P-SCSFP-SCSFVisited B

S-CSCFS-CSCF

Home A

P-CSCFP-CSCF Visited A

B

114

GGSNGGSNSGSNSGSN


GGSNGGSNSGSNSGSN


2 13

S-CSCFS-CSCF

Home B

I-CSCFI-CSCF

HSSHSS

7 89

1011

6I-CSCFI-CSCF

HSSHSS

35

12

9B

B’s calendar GUI via e.g. Outlook

4

A

36

Where to place the S-CSCF?

A long discussion on where to place the Serving Call State Control Function S-CSCF (’Call server’ in IETF)

S-CSCF acts as ’user representative’ The place to hook in personalized call screnning,

personalized forwarding etc

S-CSCF was decided (2000?) to be placed in Home-network only, not in Visited network I.e. to go for a solution different from the solution in GSM

MSC and Camel has their origin in the visited network Easy way to implement VHE

P-CSCF in visited network, but not involved in personal services (for emergency, for QoS-support,..)

37

Arguments against visited S-CSCF

Security architecture becomes more complex

Multiple relationship and roaming models between various operators

The transport of the user profile from (HSS) to the visited network is in itself problematic, since the visited network may belong to a competitor. Customer data are valuable customer care data, and you do not share it with your competitor.

More interfaces need to be inter-operator, and as such complex and strict standardisation needed

Behaviour of services need to be understood, rather than gaining from the external service creation environment per operator

Time to complete the Architecture work in SA2 becomes much longer

38

Relations between home and visited network

in 2G and 3G

Home-NW

End-point

V/access-NW

End-point

S)

C)

Home-NW

V/access-NW


Home-NW

End-pointEnd-point

V/access-NWV/access-NW

End-pointEnd-point

S)

C)

S)

C)

Home-NW

V/access-NW


MSC HLR

IN

P-CSHSS

OSA

S_CS

39

Home Site

AccessSite

AccessSite

Ericsson IPT Architecture, “home centric” and “user-centric”

Access and Connectivity Network

Service Network

PSTNGW

PSTN

Term.Agent

TerminalTerm.Agent

PSTNGW

PSTN

ServiceAgent

Home Site

ServiceAgent

User-GK(S-CSCF)

Terminal

User-GK(S-CSCF)

Site-GK(P-CSCF)

Site-GK(P-CSCF)

40

Virtual Home Environment (input to ETSI Tiphon 1999)

Registration via visiting GK to home GK

Home GK

Services

User/subscriber database

Visited GK

•The user may log on from anywhere

•Visited GK control his own resource

•The visited GK contact home GK and routes the call (but not necessarily the media) via the home GK

I/f

41

IS/IT + Telecom = ?

+

+

+

+

=

+

+

42

Outline of the talk

43

Some important ODP transparencies

Location transparency Hides the details of the location (node) of one object from

the communicating other objects

Migration transparency Hides the details of a migration function from the

application objects

Failure transparency

CORBA offers object services as well, such as: Life cycle service, Naming service, Trading service,

Notification service, etc.

44

Some issues in ODP used in telecom

Coming from the IS/IT side ODP/CORBA works well for data services. In IS/IT we have fewer, bigger objects, as well as less

realtime requirements

BUT 2 important questions: Realtime:

It is not said if the migration shall take place during active calls (i.e. continuously), or with less realtime requirements

Scalability: Does this scale to milliouns of small object instances as we

normally handle in telecom? Telecom traditionally handles the many instances of small

objects by ’multiplexing’, Individual objects are grouped ( e.g. into an HLR)

45

DPE or DPEs

From TINA Service Architecture ‘The overall objective of the service architecture is to

support the most general case of business administrative domains, interacting with one another over a DPE, in order to offer business objects or applications for commercial gain’

We need to find the right meaning of ‘a DPE’ ‘A DPE’ meaning ‘one common DPE used by all BADs.’ ‘Several DPEs’ meaning ‘each BAD choosing a DPE that

suits their own requirements and with some basic interworking between the DPEs to ensure interoperability).’

46

BAD and DPE

BAD Business Administrative Domain Examples: Enduser domain (Lill’s stuff), Service Provider Domain (confmeet@net, Norway), Content provider domain (Video&Film Inc.), Network Provider (e.g. Telenor NW, CableEnergy Inc)

Each BAD may have different needs of a DPE Different real-time requirements Different availability requirements = = > Different BAD may use different DPEs

The DPEs must be interconnected, since a telecom service stretches over many domains

47

BAD and DPEs revisited

Object Serv.2

Common Fac.2

Application I/F 2

Domain I/F 2

DPE2

Object Serv.1

Common Fac.1

Applic. I/F 1

Domain I/F 1

DPE1

BAD1

Object Serv.2

Common Fac.2

Applic. I/F 2

Domain I/F 2

DPE2

Obj. Serv.1

Common Fac.1

Applic. I/F1

Domain I/F1

DPE1

BAD 1 BAD 2

2) 1 BAD domain with 2 different DPEs (2 DPE technologies)

1) 2 BAD domains each with its own DPE.

48

Object mobility, migration etc

Should the objects move inside one BAD, or between BADs?

Should the objects move continuously? During a call setup?

What exactly does migration and relocatioin mean in terms of realtime requirements

49

New definitions

IntraDPE mobility (DPE mobility): Mobility of objects between nodes in one DPE domain. (within DPE1 or within DPE2). Implicitly this means that the objects stay inside one BAD

IntraDomain mobility (IntraBAD mobility): Mobility of objects (between possibly different DPEs) within the same BAD. To support such mobility, the concept of design portability from

TINA [6] may be needed.

InterDomain mobility (InterBAD mobility): Mobility of objects between business administrative domains. The issue of ‘foreign code’ will now pop up.

50

New research issues (1)

Hotelling and Service Level Agreement (SLA) This case is not covered by the pevious definition of BAD, Intra/inter BAD mob. needs further refinement

Object Serv.2

Common Fac.2

Applic. I/F 2

Domain I/F 2

Applic. I/F 1

Domain I/F1

Company 3

Company 1 Company 2

DPE

51


Where should we place the (‘intelligent’) functionality and the mobility? In the platform? (In the ORB?) As common facilities? As object services? Or should we make the intelligence explicitly as a

distributed application?

Object Services Common Facilities

Application interfaces Domain interfaces

Object Request Broker (ORB)

52


Model Driven Architecture MDA for telecom UML2.0 with SDL integration is a start How to pick ’best of both ’data’ and ’tele’ when making

new design methodoloies for ’Information Networked Architectured Services’ Maintaining the telecom qualities ( such as realtime and

scalability)

53

Thank You!

Questions?

Documents

1 Mobility and Intelligence in Telecom: How and where to handle it? Lill Kristiansen, Prof. Dr. Scient Dept. of Telematics, NTNU, Norway lillk