1. 1 Middleware and future telecom ’platform’ By Lill Kristiansen, ntnu

2. 2 Corba and telecom Corba has some properties for real-time –see sep. paper by Schmidt et al. on this Telecom has other specific properties –must scale well: treat millions of ’session objects’ like: –Often many instances of the same type of object is implemented on one machine (or cluster), as this will scale well

3. 3 Will ODP-based middleware enter telecom domain? My personal opinion is: –likely not (at least not everywhere in core network) The trade-off between abstraction and control –Avoid some details by abstraction, assume the ’platform’ does this for you –If the platform does not do it properly: You have a bad lunch, and have to redo it yourself Explicit control:model the group concept, the session control etc. at CO level, not using the hidden platform properties A free lunch? No!

4. 4 Abstractions and the reality The abstract view What really happens see next page

5. 5 20 real steps

6. 6 All the steps ’before anything’ 1.Query the client ORB’s connection cache for an existing connection 2.If the cache doesn’t contain a connection to the server, use a connector factory 3.Add the newly established connection S to the connection cache. 4.Also add connection S to the client ORB’s reactor since S is bi-directional 5.Use an acceptor factory to accept the new connection C from the client. 6.Add C to the server ORB’s connection cache since C is bi-directional 7.Also add connection C to the server ORB’s reactor so the server is notified when a request arrives from the client. 8.Wait in the reactor’s event loop for new connection and data events.

7. 7 Then ’the real thing’ Synchronous two-way request/reply processing. We now describe the steps involved when a client invokes a synchronous two-way request to a server, the server processes the request and sends a reply, and the client processes the reply. steps 9-20 then follows (the ’real thing’) –details in Schmidt paper A lot of hidden work! (and roundtrips)

8. 8 Rest of this paper Similarities and differences between –ODP, Corba for ’data’ and ’telecom’ What platforms will emerge if TINA/ODP will not arrive –a look at IMS, OSA, etc.

9. 9 Distributed system modelling Traditional computer science view: –UML / ODP –remote procedure calls –little focus on realtime Traditional telecom view: –SDL –state and message based signalling –tiny /dumb endpoints

10. 10 Visualising ’data’ vs ’tele’ Computer science: –RPC between objects on some machines –In OMG/CORBA: Traditional telecom: –Clear separation between: endpoints ’dumb’ Servers (’smart’) –Servers must treat many (1000s) instances of sessions Middleware

11. 11 CO, CORBA platform and telecom Each business administrative domain must choose the ORB that suits their needs Objects cannot move freely between domains –a telco server cluster may require real time, replication and availability –a web server may require somewhat less –Not a good idea to standardise all ORB services We want instead: –competition on platforms –simple interoperability between the adm. domains

12. 12 Upcoming technologies Core network in IMS needs full control of basic telecom properties –not modelled via TINA CO concepts and a platform, modelled more directely But still supports: –separation of call control and media flows Will offer interfaces to 3rd parties to make enhanced services

13. 13 Call servers / session instances In the IMS system we have Call/session control function (CFCS) –One S-CSCF (server) is treating many (1000s) of sessions –Not one specific ’object’ per session instance, no UA, PA, SSM etc. as Computational objects moving freely around on a (global) platform SIP ’call flows’ addresses the SCSF, not the individual ’session state’

14. 14 ’network middleware layer’ (see next slide) network control platform –treats session control, network control and mobility –less abstraction levels here: ensures good control of the telecom properties service support platform –enables 3rd parties to deploy services –a multimedia ’session graph’ (somewhat like IN) allowing ’legs’ parties and streams to be added, controlled and deleted

15. 15 (from Keiji Tachikawa, NTT DoCoMo,)

16. 16 Mobility Not all networks have the same capabilities –Application may ask the network or the endpoint about their capabilities Many applications will be linked to the network platform via the service support platform (in the home network of the user) Other applications may be specific to an access technology

17. 17 Example use of ’platforms’ Applications on the endpoints (terminals) run on the endpoint platform (OS) The application may be able to communicate with e.g. AP2 via the 2 platforms In this case the network control platform takes care of the mobility of the enduser and his terminal And a CORBA platform may take care of the replication and other middleware issues involving the 3rd party only (AP2 running on a service middleware, specific to the 3rd party)