1. 1 Mobility and Intelligence in Telecom: How and where to handle it? Lill Kristiansen, Prof. Dr. Scient Dept. of Telematics, NTNU, Norway www.item.ntnu.no/~lillk lill.kristiansen@item.ntnu.no

2. 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. 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. 4 Traditional Telecom ’Grade’ Global distribution:A Real time issuesA ScalabilityA Availability (’5 nines’)A Handling of partial failures A Time to market, new featuresD/E ’Quality’ of new features A/C/E User interfacesfixed phonesD/E mobile phonesA/C Rich information services:D/E

5. 5 IS/IT Aspects: ’Grade’ Global distribution:early: D later: B Real time issuesC ScalabilityB/C/D Availability (’5 nines’)D/E Handling of partial failures (see previous bullet) Time to market, new featuresA/B ’Quality’ of new features C User interfacesearly:D |later:A/B Rich information services:A

6. 6 GUI for programming PBX phone Absence codes: 0: on training 1: busy 2: at home 3: meeting 4: lunch (23 minutes) 5: out of office 6: ill 7: travelling 8: 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. 7 TINA TINA-C core team: ’92- ’97 Tina T: ??-??

8. 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. 9 TINA entities and domains

10. 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. 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. 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. 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. n 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) l Mobility of my mail service è Implemented by web based interface (on PC and PDA- phones) l Mobility of my voice telephony service è Partly implemented by GSM (1-1 relation user/terminal)

14. 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) l Note the similarity between TINA personal mobility and 3GPP virtual home environment (VHE) (More later)

15. 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. 16 A typical CORBA / ODP figure: 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. 17 Turing Machines and Computations

18. 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. 19 Implementation design (TIMe) Software Hardware represents Implemented by represents Executed on

20. 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. 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. 22 Reference figure: standardization vs competition in 2G MSC HLR IN

23. 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. 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. 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. 26 Call-related, non-call related and 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. 27 Nomadism Convergence The IMS system from 3GPP

28. 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. 29 System topology Today Separate Networks Separate Users Separate Services Tomorrow Separate Accesses Same Core network Same User on different accesses Same Services Data/IP Networks PLMN PSTN/ISDN CATV Separate Services Separate users

30. 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 Access Communication Control Content Access

31. 31 Reference model wireless, mobile, nomadic wireless Fixed Fixed user Own PC /Fixed Phone Fixed relation My SIM card and my phone Fixed relation ’Mobile’ May be a dynamic relation between user and terminal Future Nomade

32. 32 UMTS IMS architecture HSS: Home Subscriber Services HLR-like CSCF: ’Call Server’ Call/Session Control Function P-CSCFProxy- I-CSCFInterrogating- S-CSCFServing - xGSNGPRS-noder Visited B Home A Visited A Home B GGSN SGSN Radio Access Network GGSN SGSN Radio Access Network P-CSCF I-CSCF HSS S-CSCF I-CSCF S-CSCF P-CSCF BA

33. 33 1 2 5 S-CSCF Home A P-CSCF Visited A 8 GGSN SGSN Radio Access Network 7 I-CSCF 6 A UMTS IMS registration 8 4 37 LocationUserProfile HSS

34. 34 1 2 78 96 34 5 P-SCSF Visited B S-CSCF Home A 10 1112 13 P-CSCF Visited A A B 18 GGSN SGSN Radio Access Network GGSN SGSN Radio Access Network 17 S-CSCF Home B I-CSCF HSS 1415 I-CSCF HSS 16 UMTS IMS call flow

35. 35 Including value added services P-SCSF Visited B S-CSCF Home A P-CSCF Visited A B 1 14 GGSN SGSN Radio Access Network GGSN SGSN Radio Access Network 213 S-CSCF Home B I-CSCF HSS 78 9 1011 6 I-CSCF HSS 3 5 12 9B B’s calendar GUI via e.g. Outlook 4 A

36. 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. 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. 38 Relations between home and visited network in 2G and 3G MSC HLR IN P-CS HSS OSA S_CS

39. 39 Home Site Access Site Access Site Ericsson IPT Architecture, “home centric” and “user-centric” Access and Connectivity Network Service Network PSTN GW PSTN Term. Agent Terminal Term. Agent PSTN GW PSTN Service Agent Home Site Service Agent User-GK (S-CSCF) Terminal User-GK (S-CSCF) Site-GK (P-CSCF) Site-GK (P-CSCF)

40. 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. 41 IS/IT + Telecom = ? + + + + = + +

42. 42 Outline of the talk

43. 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. 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. 45 DPE or DPEs n 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. 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. 47 BAD and DPEs revisited 2) 1 BAD domain with 2 different DPEs (2 DPE technologies) 1) 2 BAD domains each with its own DPE.

48. 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. 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. 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

51. 51 New research issues (2) 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?

52. 52 New research issues (3) 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. 53 Thank You! Questions?