1 / 17

Middleware and future telecom ’platform’

Middleware and future telecom ’platform’. By Lill Kristiansen, ntnu. 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:

scorpio-goldberg
Download Presentation

Middleware and future telecom ’platform’

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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. 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. The abstract view What really happens see next page Abstractions and the reality

  5. 20 real steps

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

  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. 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. 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 Distributed system modelling

  10. 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 Visualising ’data’ vs ’tele’ Middleware

  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. 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. 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. ’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. (from Keiji Tachikawa, NTT DoCoMo,)

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

More Related