TINA: Concepts that are Actually Turning into Reality With IP and NGN

1. TINA: Concepts that are Actually Turning into Reality With IP and NGN Jean Craveur, Fabrice Dupuy, Jean-Marc Pageot, Stéphane Pensivy

2. Outline • Seven years that have being turned into one, by Internet • Concepts that are turning into reality • The Business Model • The Retailer • The Service Architecture • The need of API • Some Technical issues that are still to be looked at • Conclusion

3. Seven years that have being turned into one, by InternetSince 1993... • TINA consortium birth! • The 1993 main focus: IN / PSTN, ATM, QoS, VoD/Videoconferencing • Telecommunication experts forecast: the value will be more and more on the (value added) services and content provisioning (compared to “pipe” provisioning, or “dumb network”) • TINA, a group of technical experts defining the basis of • an architecture that clearly splits the service layer and the transport layer with a high focus on the above mentioned acronyms and services • the first business model based on the cooperation of different service providers • the convergence between (up-to-date) Telecommunication Technologies and (up-to-date) Information Technologies (IT), particularly through the use of DPEs (Distributed Processing Environment) • ... for a business case, not totally identified

4. Seven years that have being turned into one, by Internet ... to 2000 • The technical evolution... • The Internet phenomena !!! • The mobile market boom !!!! • 330 millions subscribers in Europe, in June 2000 • The NGN wave, ridden also by new entrant manufacturers • ... associated with the regulatory and market evolution and pressure... • copper local loop unbundling • radio local loop unbundling • UMTS standard favouring the third party service providers • ... bring the missing business cases and make some TINA principles more up-to-date than ever : • the business model, • the need of a Service Architecture • the use of the latest IT technologies and off-the-shelves environments

5. Concepts That are Turning into RealityThe Business Model • Deregulation, market demands make necessary to define the business responsibilities - An overall architecture is needed • various on-going activities (ITU-T, ETSI, IETF, MSF, ISC, OMG..) • The TINA work gets acceptance in various bodies • adoption of TINA business model by ITU-T SG11 • adoption of (Ret) reference point by OMG TSAS • The separation between Service Provider and Network Resource Provider • Hot topic and spread concern (NGN, 3G mobile)!!!! • Various on-going activities such as Jain or Parlay (with TINA Access Session semantic for the Parlay framework) • The result of this work has to be endorsed by bodies driven by specific business cases • Parlay phase 2 adopted in UMTS for VHE

6. Concepts That are Turning into RealityThe Retailer • TINA SA 5.0 definition: “...providing Customers access to services” • The concept was appealing but without clear business cases few years ago... • The telecommunication landscape evolution makes the separation between access and services a cornerstone • local loop unbundling • NGN advent with access and residential gateways • customers’ portal accessible from different devices (WAP phone, PC,...) and access networks (ADSL, GSM, GPRS) • A good ground is naturally the Retailer Platform specifications, and the notion of TINA Access Session

7. Concepts That are Turning into RealityThe Service Architecture • TINA SA 5.0 objectives: • Objective 8: “Definition of partition and layering principles leading to the separation of services from the network and computing infrastructure and related resources” • Objective 9: “Definition of interfaces providing an abstract view of the network and computing infrastructure that enables service applications to make use of network and computing resources transparently” • Objective 10: “Definition of principles and mechanisms that allow third-party development of services and applications”

8. Concepts That are Turning into RealityThe Need of API • Shortening time-to-market is also facilitated by the shortening the service development process • The service development process must be open • in term of tools and environment - towards off-the-shelves tools & environment • in term of actors - towards open and published interface • The notion of API is a enabling factor to ease and speed this step • numerous tolls and environment (C++ libraries or Java packages) available • These tools and environment are already mastered by a large community of developers - The Internet community • API vs Protocol: they are complementary • use of protocols for specifying interaction between remote systems • use of APIs to ease the service development process • The success of APIs in telecommunication business and market relies highly on their ability to be consistent with legacy telecommunication protocols

9. Application Server A (SCP) Application Server B (SCP?) Application Server C Service control API: Proprietary API: Jain, Parlay,.. Protocol: Proprietary Protocol: INAP, SIP or proprietary API: Proprietary Protocol: INAP H.323 Call control Media Gateway Controller Media Gateway Controller SIP-BCP BICC ISUP/SS7 ISUP/SS7 MGCP/H.248 MGCP/H.248 PLMN IP ATM PSTN Resource Control Media Gateway Media Gateway Study caseWhich Service Platform for NGN • Risk of loosing the separation brought by IN between the service logic and call control!!!

10. Some technical issues that are still to be looked at • Multi-party Call Control : • A real requirement from service provider, that implies a sophisticated flexible accounting system, not fully implemented yet • Hopefully, in the new NGN products, less constrained (SIP, H.323) • Intelligent Peripheral Integration in a NGN network • The Intelligent Peripheral will evolve toward an Internet Integration (IP-IP) • These will create IP subnetworks with specific QoS requirements to manage by the service providers • Services Interaction • The profile notion and its externalisation that will be more and more crucial do not solve the problem of consistency execution of various services. • First step : For a service provider, to list the information manipulated by its services to be able to detect the potential concurrency access of various services on the same information. • Second step : Build a consistent execution of the various services. Yet an open issue with some solutions to investigate.

11. Conclusion • Not all specifications bodies manage to turn their results into standard de facto, widely accepted by the market. Let us remind that TINA-C primary aim was R&D cooperation, i.e. collaborative assessment of technology innovation • Even if TINA is not a standard de facto, the Consortium has been particularly successful in anticipating, vulgarising, influencing, promoting concepts/ideas. • Since 1993, the telecommunications context has changed dramatically : IP, mobile, NGN. • The best TINA concepts are naturally turning into specifications and products in the bodies addressing specific market needs (3GPP, OMG, IETF, SoftSwitch, etc)