Vol3 - Eurescom

Project P847-GI

What is TINA and is it Useful for the TelCos?

Deliverable 2

A TelCo Assessment of TINA

Volume 3 of 4: Annex 2 - Assessment of TINA in the real world

Suggested readers:

Managers, TINA-C members

For full publication

February 1999

EURESCOM PARTICIPANTS in Project P847-GI are:

 France Télécom



TELECOM ITALIA S.p.a.



Telenor AS



Telecom Eireann

This document contains material which is the copyright of certain EURESCOM

PARTICIPANTS, and may not be reproduced or copied without permission

All PARTICIPANTS have agreed to full publication of this document

The commercial use of any information contained in this document may require a license from the proprietor of that information.

Neither the PARTICIPANTS nor EURESCOM warrant that the information contained in the report is capable of use, or that use of the information is free from risk, and accept no liability for loss or damage suffered by any person using this information.

This document has been approved by EURESCOM Board of Governors for distribution to all EURESCOM Shareholders.



1999 EURESCOM Participants in Project P847-GI

Deliverable 2 Volume 3: Annex 2 - Assessment of TINA in the Real World

List of Authors

Carlo Alberto Licciardi (CSELT/Telecom Italia)

David Muldowney (Broadcom/Telecom ireann)

Didier Guy (CNET/France Telecom)

Helge Berg (Telenor)

Kjell Hermansen (Telenor)

Michael Barry (Broadcom/Telecom ireann)

Paolo Coppo (CSELT/Telecom Italia)



1999 EURESCOM Participants in Project P847-GI page i (v)

Volume 3: Annex 2 - Assessment of TINA in the Real World Deliverable 2

Table of Contents

List of Authors ................................................................................................................ i

Table of Contents ........................................................................................................... ii

Abbreviations ................................................................................................................ iv

1 Introduction ............................................................................................................ 1

2 TINA oriented initiatives in Standard Bodys ......................................................... 3

2.1 ITU-T ........................................................................................................... 3

2.1.1 SG10 ................................................................................................ 3

2.1.2 SG 11 ............................................................................................... 3

2.1.3 SG 13 ............................................................................................... 4

2.1.4 SG16 ................................................................................................ 4

2.2 Object Management Group .......................................................................... 5

2.2.1 Telecom Service Access and Subscription ..................................... 5

2.2.2 Multiple Interfaces & Composition RFP ........................................ 5

2.2.3 Business modeling concepts............................................................ 5

2.2.4 Wireless communication and mobility support ............................... 5

2.2.5 Pluggable protocols ......................................................................... 5

2.2.6 CORBA and Intelligent Network Interworking .............................. 6

2.2.7 A/V streams control and management ............................................ 6

2.3 IETF ............................................................................................................. 6

2.3.1 PINT: Phone IP iN Teleworking services ....................................... 6

2.3.2 MGCP Media Gateway Control Protocol ....................................... 6

3 TINA enabling products ......................................................................................... 9

3.1 Definition of TINA Compliance .................................................................. 9

3.1.1 Alignment In Principle .................................................................... 9

3.1.2 Concept Conformance ..................................................................... 9

3.1.3 Layering/Partitioning Compliance .................................................. 9

3.1.4 Information Model Compliance .................................................... 10

3.1.5 Technical Compliance ................................................................... 10

3.1.6 Operational Compliance ................................................................ 10

3.2 TINA Compliant Systems .......................................................................... 10

3.2.1 Starvision ....................................................................................... 11

3.2.2 The Aero platform from Windward Solutions .............................. 11

3.2.3 Bridgewater ................................................................................... 11

3.2.4 Sprint-ION ..................................................................................... 11

3.2.5 JAIN .............................................................................................. 12

3.2.6 JINI ................................................................................................ 12

3.2.7 Geoplex ......................................................................................... 12

3.2.8 Parlay APIs .................................................................................... 12

3.2.9 PINT .............................................................................................. 12

3.3 Product Compliance Matrix ....................................................................... 12

4 Experience Gained from TINA ............................................................................ 15

4.1 Global One Alliance ................................................................................... 15

4.2 EURESCOM .............................................................................................. 15

4.2.1 P508 Evolution, migration paths and interworking with

TINA ............................................................................................. 15

4.2.2 P608 TINA concepts for third generation mobile systems ........... 16 page ii (v)





4.2.3 P715 EURESCOM Services Platform .......................................... 17

4.3 ACTS ......................................................................................................... 18

4.3.1 ReTINA ......................................................................................... 18

4.3.2 VITAL........................................................................................... 18

4.3.3 PROSPECT ................................................................................... 21

4.3.4 TOSCA ......................................................................................... 22

4.3.5 DOLMEN ..................................................................................... 22

4.3.6 REFORM ...................................................................................... 22

4.3.7 SCREEN ....................................................................................... 23

5 Conclusions .......................................................................................................... 25

References ................................................................................................................... 27



1999 EURESCOM Participants in Project P847-GI page iii (v)


Abbreviations

GII

IETF

IIOP

IN

ION

IP

ISDN

ITU

LAN

N-ISDN

ODL

OMG

PNNI

PNO

POTS

QoS

A/V

AAA

AAL

ACTS

API

ATM

B-ISDN

B-ISDN

CORBA

CSI

CTI

DEN

DMF

DPE

DSP

DSS

FPLMTS

Audio/Visual

Authentication, Authorisation and Accounting

ATM Adaptation Layer

Advanced Communication Technology and Services

Application Programmers Interface

Asynchronous Transfer Mode

Broadband Integrated Services Digital Network

Broadband ISDN

Common Object Request Broker Application

Carrier Scale Interworking

Computer Telephony Integration

Directory Enabled Networks

Digital Media Forum

Distributed Processing Environment

Digital Signalling Processing

Distributed System Schema

Future Public Land Mobile Telecommunications System

Global Information Infrastructure

Internet Engineering Task Force

Internet Inter ORB Protocol

Intelligent Network

Integrated On-demand Network

Internet Protocol

Integrated Services Digital Network

International Telecommunications Union

Local Area Network

Narrowband ISDN

Object Definition Language

Object Management Group

Private Network to Network Interface

Public Network Operator

Plain Old Telephone System

Quality of Service page iv (v)




RFP

SCMS

SNMP

TC

TCP

TINA

TINA-C

TINA-SA

TMN

UMTS

UNI

UPT

VPN

WWW


Request For Proposal

Service Creation and Management System

Simple Network Management Protocol

Transaction Capability

Transport Control Protocol

Telecommunications Information Networking Architecture

TINA Consortium

TINA Service Architecture

Telecommunications Management Network

Universal Mobile Telecommunications System

User Network Interface

Universal Personal Telecommunications

Virtual private Network

World Wide Web



1999 EURESCOM Participants in Project P847-GI page v (v)


1 Introduction

The Telecommunications Information Networking Architecture (TINA) Consortium was founded to address in the telecom community the common need for improving the way services are designed and the common opportunity for future services. The primary objective of TINA is to define and validate an open architecture for distributed telecommunications and software applications. The TINA initiative is now in its second phase and the consortium has been reorganised to focus on the management of distributed telecommunications objects, handling mobility in a transparent manner, service management components and specific targeted applications such as multimedia and Internet services. The TINA Consortium expects that the actual adoption of TINA by the industry will begin before the end of this second phase.

This document looks at the role of TINA in real world telecommunications scenarios.

It is intended to facilitate the adoption of TINA by shareholders. This document aims to provide information on TINA standards, technologies products and experiences which can be used by the shareholder in the design and deployment of TINA compliant systems and services. The document is structured as follows.

Chapter 2 details the handling of TINA and TINA oriented activities in standardisation. The Object Management Group (OMG) is currently developing standardised interfaces for access to telecom services and also for the control and modification of audio/visual streams. Both of these are expected to be TINA oriented.

Standardisation activities in the ITU and IETF which are TINA related or are likely to have an influence on TINA in the marketplace are also discussed.

Products for TINA compliant platforms, architectures and service creation models are currently under development. Chapter 3 looks at some of the TINA compliant and

TINA enabling products being developed for and by the telecom industry.

Chapter 4 details experiences from participation in EURESCOM, ACTS and in-house projects by the Project partners. Initially these projects tended to be research oriented but as the TINA specifications developed they have become more implementation based. These projects highlight the usefulness and applicability of TINA to service and network management.



1999 EURESCOM Participants in Project P847-GI page 1 (27)

Volume 3: Annex 2 - Assessment of TINA in the Real World Deliverable 2 page 2 (27)





2 TINA oriented initiatives in Standard Bodys

2.1 ITU-T

A number of different protocols are being specified both in ITU-T and in IETF to enable access, control and streaming of multimedia services. Table 1 below presents a list of emerging protocols for multimedia services being developed by the ITU and the

IETF.

Network access, registration H.323, RAS

Call signalling H.225/Q.931/2

Special resources control - Media Gw controllers MGCP, SGCP, IPDC, RSGCP,

GLP, RTSP

Multimedia-multiparty session control - invitation H.323, SAP, SIP, SDP, PINT

H.245 Negotiation of capabilities, logical channels mgmt., etc.

Quality of service

Directory services and address translation audio/video/data transport

RSVP, RTP

LDAP, finger, rwhois

IP multicast and RTP

Table 1 – Emerging protocols for multimedia services

Further information on the IETF standards can be found in Annex 1 (PIR3.2). This section describes TINA related or TINA influenced submissions to study groups of the ITU. It contains inputs that have been submitted by TINA member companies and that are based on some of the results of the TINA-C consortium.

2.1.1 SG10

SG 10 is Responsible for technical languages, the methods for their usage and other issues related to the software aspects of telecommunication systems.

Questions in this Study Group of relevance to TINA are

2/10 ITU-T Object definition language

3/10 Software platforms and middlewares for the telecom domain

TINA-C ODL (Object definition Language) has been provided to ITU-T SG10

Question 2 by Deutsche Telekom . It has been refined and is due for a recommendation in 02/99 as ITU-T Z.130.

Deutsche Telekom has provided a contribution to ITU-T SG10/Q3 "Middleware

Standardisation". The input is based on the draft DPE 2.0. There should be a determination in June 1999 during the joint rapporteurs group meeting with a possible recommendation in late 1999/early 2000. (Currently Z.DPE/Z.600).

2.1.2 SG 11

Study Group 11 is responsible for studies relating to signalling requirements and protocols for telephone, N-ISDN, B-ISDN, UPT, mobile and multimedia communications. It is the Lead Study Group on Intelligent Network and FPLMTS.





Questions in this Study Group which benefit from TINA concepts are

1/11 Signalling and protocol framework for an evolving environment

6/11 New signalling capabilities and requirements for advanced broadband multimedia services

DT has provided business modelling concepts based on the TINA-C Business Model and Reference Points TINA-C document to ITU-T SG11 Question 1.

NTT has provided information model and computational model based on TINA-C

Service Architecture (version 5) to ITU-T SG11 Question 1. The models are captured in Q1's baseline documents, but the "Determination/Decision" dates are still unclear;

1999 March/December at the earliest; if missed, 2001 or later.

FT has provided high level functional description of part of operations defined in

TINA-C Ret specification (version 1.0) to ITU-T SG11 Question 1. Its status is the same as previous item. Further contributions are expected (e.g., from SARP-WG or

FT or Alcatel or...) for full descriptions and IDL definitions.

ITU-T SG11 Q6 has a TINA-like business model and a TINA-like Session model

(both contributed by Lucent) that are captured in their draft Technical Report TR

Q.2001 (not Recommendation), which is planned to be "Determined", if successful in

March 1999. TINA members companies are planning to provide contribution to clarify the session model and change their TINA-like models to exact TINA models.

2.1.3 SG 13

Study Group 13 is responsible for studies relating to general network aspects and the initial studies of the impact of new system concepts and innovative technologies on telecommunication networks with far-reaching consequences, including broadband

ISDN and global information infrastructure studies, taking into account the functional responsibilities of other Study Groups. SG13 is the Lead Study Group on General network aspects, Global Information Infrastructures (GII) and Broadband ISDN.

DT has presented business-modelling concepts to ITU-T SG13 and it is the intention to provide a contribution to the next SG13 meeting. The content is the same as for

SG11/Q1.

2.1.4 SG16

This group is responsible for studies relating to multimedia service definition and multimedia systems, including the associated terminals, modems, protocols and signal processing. Study Group 16 is the Lead Study Group on Multimedia services and systems.

Alcatel have made a number of TINA related submissions to SG 16 Question 12-14.

One is related to the mapping between INAP and MGCP the other one is related to how (and why) a MGCP call agent can be interfaced with a TINA Retailer by using

TINA-Ret RP specification.

Alcatel proposed thus to mimic the TINA Access Session, making it applicable in the

H323 or MGCP environment. The AAA part would be unique, and done in this manner. The charging (if any) would also greatly benefit from a centralised logical access management. Alcatel proposed also to start using IDL like interface page 4 (27)




Deliverable 2 Volume 3: Annex 2 - Assessment of TINA in the Real World specification instead of (together with) text based protocols in order to exploit advantage of Object Orientation.

2.2 Object Management Group

2.2.1 Telecom Service Access and Subscription

In October 1998, OMG issued a Request For Proposal (RFP) for Telecom Service

Access and Subscription [OMG3]. The service requested by this RFP consists of standardised interfaces and mechanisms for enabling end-users to access and configure a telecommunication service according to their own wishes and to allow value-added service providers to offer their services to end-users. This RFP solicits proposals for a retailer service with end-user authenticated access to the following features: selection of telecommunication services from a list of available services, either for subscription or for accessing. The service enables subscription by end-users to access services, provides end-users with authenticated location transparent access to telecommunication services and allows customisation of end-user preferences for services provided by Service Providers. Potential submissions are likely to be TINA oriented.

2.2.2 Multiple Interfaces & Composition RFP

The same draft Z.130 (as submitted to ITU-T SG10 but differently packaged) has been submitted by GMD-Fokus to OMG for the RFP. To-date there is a competing submission still on the table (OMG-STRUDL) by IONA, DSTC et al. which has the same roots in TINA-C ODL. Adoption of this RFP has been delayed until the component model RFP has been finished.

2.2.3 Business modelling concepts

DT has provided business modelling concepts to OMG as input to the development of a telecom domain reference architecture. The content is the same as for ITU-T

SG11/Q1. This OMG TDTF effort seems to have stalled.

2.2.4 Wireless communication and mobility support

DT has provided input to the OMG RFI on wireless communication and mobility support. The input is an excerpt from the DT auxiliary project "PCS in TINA"

2.2.5 Pluggable protocols

DT, Humbold University and OOC (http://www.ooc.com) have tried, without success, to issue an RFP on Pluggable Protocols (a DPE issue).

The specification for an intended submission of a pluggable protocol RFP has been contributed to the Real-time submission and the IN/CORBA interworking submission by OOC and Humbold University (both RFP had similar requirements). In both cases the pluggable protocol specification has been removed from the final submissions in order to create consensus among the submitters. The issue of pluggable protocols is still unresolved in OMG. However inside the TINA community a growing interest can




Volume 3: Annex 2 - Assessment of TINA in the Real World Deliverable 2 be observed for implementing pluggable protocol specifications (for example through

Expersoft).

2.2.6 CORBA and Intelligent Network Interworking

The CORBA and Intelligent Networks Systems interworking RFP solicits proposals for the following: 1. Interworking mappings between Transaction Capability (TC) and

IIOP. 2. Orb over SS7 [OMG2]. There exists a revised, joint proposal from AT&T,

IONA Technologies, GMD Fokus, NORTEL and Teltec. Technology adoption is underway. This work is based on some of the results of EURESCOM P508

[EUR508D2]. Implementations of this OMG standard will allow opening of the IN to e.g. external service providers. This RFP focuses on the Syntactical and the semantic mapping between IN and CORBA. In order to allow IN/TINA interworking an adaptation unit between the IN/CORBA gateway and a TINA system is needed. The

TINA Consortium has issued an RFP asking for proposals concerning TINA/IN interworking [TINA1].

2.2.7 A/V streams control and management

The Audio/Visual Streams, issued by OMG in 1997 [OMG1], asked for solutions concerning stream control, stream description, stream modification, flow synchronisation and Quality of Service of Audio/Visual Streams. At present there exists two implementations, a commercial from IONA Technologies and a noncommercial from University of Washington. In [McGrath et al] it is illustrated how the OMG A/V Streams can be used to implement TINA Connection Management.

2.3 IETF

2.3.1 PINT: Phone IP iN Teleworking services

PINT defines a protocol for invoking certain telephone services from an IP network.

These services include placing basic calls, sending and receiving faxes, and receiving content over the telephone. The protocol is specified as a set of enhancements and additions to the SIP 2.0 and SDP 2.0 protocols. Further information on PINT and SIP can be found in Annex 1 (PIR 3.2)

TINA related contributions to PINT include a TINA-based business model including

End-Users, Internet Providers and PSTN Providers, from FT. Between the Internet and PSTN providers it is proposed that Retailer relationship from the TINA Business model be used. It is also proposed that service specific interfaces should be defined in

IDL for PINT services between the PSTN Providers and Internet Providers and for services such as click2dial between the End Users and Internet Providers.

2.3.2 MGCP Media Gateway Control Protocol

MGCP protocol is the result of the attempt to make SGCP and IPDC protocols to converge in a unique protocol suite (draft 0.1 was issued on November 9 th ). Therefore it should supersede both. The MGCP assumes a call control architecture where the call control “intelligence” is outside the gateways and handled by external call control elements. A telephony gateway is a network element that provides conversion between the audio signals carried on telephone circuits and data packets carried over page 6 (27)




Deliverable 2 Volume 3: Annex 2 - Assessment of TINA in the Real World the Internet or over other packet networks. More information on MGCP and the

MGCP architecture can be found in Annex 1 (PIR 3.2).

One concern with regards to the MGCP call agent is that multiple authentication needs to be done from the same terminal. Imagine a user connecting to Internet. The user needs to provide an ID and password, and the Radius based Access control will handle the log-in to the ISP/ data service. If this user wants to place a phone call, they should not have to provide another couple of ID/password.

Alcatel have proposed that TINA session concepts be applied to MGCP to ensure a clean cut between the access session and the service session in the Voice over IP service, so that further service session mobility will be trivial, accommodating a legal environment where two different operators provide access and call service (a third one could offer additional services).

The proposal entails the mimicking of the TINA Access Session making it applicable in the MGCP environment. Adoption of such a centralised logical access management would facilitate unique Authentication, Authorisation and Accounting (AAA) across all sessions and would also be of benefit in. charging. These access session facilities would be provided by an Access Manager.

The access to a service provider (called retailer in the following text, in order to differentiate third party service providers from the first service provider, which is in direct contact with the end user) describes the consumer-retailer dialogue which must offer the following capabilities:



Initiation of dialogue between the consumer and retailer,



Identification of the domains to each other



Establishment of a secure association between the domains,



Set up of the default context for the control and management of usage functionality,



Discovery of service offerings,



Listing of access sessions, services sessions and subscribed services,



Initiation of usage session(s)



Control and management of service session

The distinction between the access session and the service session itself is valuable for the user who accesses only once the network, without authenticating each time he wants to access a service, and for the retailer who can have a global view of the consumers, which is efficient for the service management. The access must be independent of the service and the type of the terminal. It is inspired from the TINA access session, which was actually partly inspired from SIP.









3 TINA enabling products

3.1 Definition of TINA Compliance

TINA is a broad specification with many facets. Each of these has its own concepts, partitioning, information model, and other details. TINA needs to define compliance separately for each of these facets. Thus a system may comply with TINA at a different level in different facets. This is consistent with current usage of TINA specifications and also allows a vendor to play a single limited role in the business of service provisioning.

To aid the development of TINA systems, different levels of compliance have been defined. The compliance framework, as defined in the CAT (Compliance and Testing)

Working Group led by Sprint, is layered from the top down into six layers:

1.

Alignment In Principle

2.

Concept Conformance

3.

Layering/Partitioning Compliance

4.

Information Model Compliance

5.

Technical Compliance

6.

Operational Compliance

Each of these layers builds upon the layer above. Compliance at each of these levels needs to be defined so that compliance can be judged.

3.1.1 Alignment In Principle

A system is considered to have Alignment in Principle if it is aligned with the first principles of TINA, e.g. the role of intelligent software in setting up services, separation of logical and physical descriptions of services

Being Aligned in Principle means that a business has taken the first steps towards providing value-added services in a flexible way. It enables a business to take on one or more of the TINA business roles without performing them all.

3.1.2 Concept Conformance

Systems that are organised according to top level TINA reference models, such as the retailer model, are TINA Concept Conformant. Such business is organised to perform one or more distinct business roles.

TINA concept conformance allows there to be industry shared recognition of problems with a solid context for dealing with them. Clarity and completeness of

TINA concepts is critical to expressing this. Once concisely expressed these concepts and basic models will be broadly valued and accepted.

3.1.3 Layering/Partitioning Compliance

A system has layering/partitioning compliance if it is functionally decomposed in accordance with TINA. In such a system, TINA reference points exist logically, but do not comply with the TINA specified interfaces.





Layering/Partitioning compliant systems are able to execute a TINA business role in the telecommunications services business. They provide the ability to be flexible in defining, deploying, or leveraging telecommunications services. Compliant systems are able to manage development and maintenance of systems using TINA as a template. Functional programming requirements are a priori known and TINA programming knowledge can be applied. Bridging is possible between systems at this level of conformance. However the clarity and completeness of TINA model will become an issue at this compliance level and there is a need that the layering and partitioning requirements be made distinct and enforceable.

3.1.4 Information Model Compliance

A system which uses object classes defined according to TINA and has operations defined with semantic equivalence to TINA operations has Information Model

Compliance.

These systems support straightforward bridging between other TINA Compliant third party systems within or external to a service provider. The main issue with these systems is that the externalised information model is linked with internal model. This means that it is not typically possible to unlink internal and external views of the system.

3.1.5 Technical Compliance

A system has technical compliance if it conforms to the reference points and can interoperate over these interfaces; without any extra agreements or interfaces.

Technical Complaint systems are functionally adequate with respect to TINA and support assured interworking. They support the purchase and deployment of third party software solutions and their integration with other TINA systems.

For a system to be technical compliant, completeness and adequacy of the reference point must be demonstrated for each reference point interface.

3.1.6 Operational Compliance

Systems that both technically conform to TINA and can interoperate at a guaranteed service level in terms of responsiveness, availability and other service level guarantees have Operational Compliance.

These systems are ready to inter-operate with any other business with similar TINA compliant systems.

No TINA system has demonstrated the ability to operate at this level. TINA will be meaningful once this is proven.

3.2 TINA Compliant Systems

This section describes the compliance level of a different TINA based, TINA -like and TINA competing systems. A table summarising the TINA compliance levels of each product is presented in section 0. Further information on these products, including a detailed description can be found in Deliverable 1 Annex 1 (PIR 2.2). page 10 (27)





3.2.1 Starvision

Starvison provides the SCMS platform which is claimed to be TINA based. The platform seems to offer a separation between the service and connectivity resources allocated for the service. It’s not clear how this is achieved. Presumably this platform facilitates implementation of services that satisfy the “align in principle” to a high degree.

Starvision offer products for Service Providers who can utilise a TINA network to provide services using these products. For example the StarED product allow education institutions to offer education services over a broadband network. Roles of the TINA business model like 3 rd party service provider and connectivity provider (or retailer) can be supported.

3.2.2 The Aero platform from Windward Solutions

The Aero platform from Windward Solutions is a platform for developing and maintaining CORBA based systems and so it doesn’t make sense to try to categorise the level of compliance of the development platform itself to TINA. However, Aero should facilitate development of services which to an unknown level of degree can support most of if not all of the TINA compliance points. In addition, Windward solutions has implemented large portions of TINA connection management

3.2.3 Bridgewater

The Bridgewater platform provides conceptual compliance with Ret access part (AAA functionality and in particular authentication mechanism and service selection). The solution can be seen as an alternative to TINA Retailer access implementation but functionality for Customer Service Management could be imported to complement a

TINA Retailer implementation.

3.2.4 Sprint-ION

This platform can be seen as a full TINA implementation including service architecture, connection management and distributed platform. In particular the ION

DPE can be seen as an enhancement of a CORBA DPE, suitable for

Telecommunication requirements. The Ret reference Point is supported at operational level. The Network Resource Information Model can be made compliant to TINA

NRIM 2.2 with a few enhancements.





3.2.5 JAIN

JAIN can be considered as a framework on top of which TINA objects could be implemented in JAVA and independently of underlying hardware and operating systems. The architecture can be considered compliant up to the level of layering/partitioning compliance. JAIN could also be an enabling technology also for the definition of APIs that allows TINA SA to control heterogeneous networks; MAP for GSM, INAP for IN, MGCP for Call Agents and Media Gateways. From the

Reference Points perspective JAIN has a layering compliance level at least for ConS.

3.2.6 JINI

JINI can be considered as an enabling technology for TINA objects/interfaces distribution and trading. It could increase performance with respect to OrbixWeb in case of Provider Agent applet downloading. It can be seen as a sort of competitor of

CORBA DPE, especially in the context of trading services.

JINI does not address TINA architectural issues, but low-level interaction among JINI object adopts mechanisms which are in line with Reference Point concepts.

3.2.7 Geoplex

The Geoplex platform is very similar to the Bridgewater platform, and the same comments apply here.

3.2.8 Parlay APIs

Parlay provides the network APIs that are needed to build TINA services. The defined

APIs could be seen as a first implementation of Tcon and ConS reference points on top of a real network scenario which may be GSTN or IP based. On top of these APIs services could be easily specified/ implemented using TINA SA concepts and objects.

They could also facilitate the definition of Ret-3 rd party Reference Point.

3.2.9 PINT

PINT servers are designed to support Internet access to traditional GSTN services: phone calls, fax. Therefore they can be considered as enabling gateways for TINA consumer access to GSTN. In particular PINT servers use SIP protocol invitation mechanisms, that are very close - but not the same- to TINA invitation handling. PINT could be used by TINA architects to interact with underlying network with an abstract interface conceptually it implements Tcon and ConS Reference Points.

3.3 Product Compliance Matrix

The following table evaluates compliance of TINA related industry products in terms of the above defined compliance framework. Evaluation is performed separately for business model, computing architecture, service architecture and resource management architecture. Numbers indicate the compliance level for that category.

An evaluation of which areas of TINA are challenged or supported by these industrial approaches is also listed.

Business Model Computing Service Resource Competes Supports page 12 (27)





(Alignment with

Reference Point

Functionality)

Bridgewater Ret = 1

Architecture

(CA)

Architecture

(SA)

Management

Architecture

(RMA) with

Out of scope TINA Access session = 1

Out of scope TINA

Access

Session

ION

JAIN

JINI

Geoplex

Customer Service

Management

Ret = 5

ConS = ¾

Tcon = 2

TINA DPE = 5,

6 in perspective

ConS = ¾ for IN DPE = 2

4

3, potentially up to 6

4, 5 in perspective

Out of scope

CORBA

DPE

CORBA

DPE,

TINA DPE

All parts of TINA

Service

Architecture

(provides a framework for implementation)

Ret, ConS, Tcon

= 2

DPE = 2 2, potentially up to 6

Out of scope but could be up to 6 in principle

CORBA

DPE,

TINA DPE

TINA SA, RMA

(Could improve performance through selective downloading)

Ret = 1 Out of scope Access session = 1,2

Out of scope TINA

Access

Session

Customer Service

Management

Parlay

PINT

ConS = 2

Tcon = 2

3Pty = 2

ConS = ¾ for IN

Ret access = 2

DPE = 1 (need of network and

3 pty API)

Out of scope

(PINT is protocol oriented)

Could be Out of scope TINA RMA

CORBA

DPE

SA. Could provide API for

ConS and Tcon facilitating the development of

SA

Access = 2 Out of scope SA, in particular invitation handling

ConS

Tcon

Starvision Ret = 4

Cons = 3

Tcon = 1

Windwards

AERO

Out of Scope

CORBA DPE =

6

SA = 4, in perspective 6

RMA = 3, in perspective 6

CORBA DPE

=6

Out of scope Out of scope

All parts of TINA except TINA

DPE

Developments on

CORBA DPE and possibly

TINA DPE

Table 2 TINA Compliant Products









4 Experience Gained from TINA

4.1 Global One Alliance

The Global One Alliance TINA Trial is a joint effort of an international TINA testbed that ran from February 1997 to mid-1998. The partners of the Global One Alliance, namely Deutsche Telekom, France Telecom, and Sprint used this testbed to validate

TINA.

The trial consisted of a large-scale experimental implementation of multi-operator services based on a multi-retailer TINA platform. The testbed was built by integrating distinct TINA platforms and computational objects, relying on their compliance to

TINA reference points.

The Global One Alliance TINA Trial is based on three types of services. All of them run on top of the same infrastructure and share a set of computational objects.

1.

The Universal Access service allows any user to retrieve his well-known environment and services from anywhere in the world operated by Global One for the cost of a local call to the nearest Point of Presence.

2.

The Call Completion service (UPT-like service) allows a user to be reached for telephone call anywhere he is (i.e. whatever the terminal he has registered at may be), via a Personal Number. This service shows an application of TINA concepts to legacy telephone systems.

3.

A third group of services provides a set of group communication services including videoconference and joint document edition facilities.

4.2 EURESCOM

4.2.1 P508 Evolution, migration paths and interworking with TINA

P508 ran from February 1995 to December 1997. The aim of the Project was to develop a common vision of whether, when, where and how the TINA technology is applicable in the existing European Public Networks environment. To meet this objective, the Project investigated and developed evolutionary, migration and interworking strategies to TINA from existing, legacy, systems such as TMN, IN,

Broadband and the Internet. This resulted in a set of network scenarios which could be used by PNOs in order to set up their proper migration paths towards a full TINArised network [EUR508D2]. Some of the conclusions of the Project are as follows,

The applicability of TINA is mostly valuable in the area of services, both control and management. This is due to the lack of a vast installed base for service control and management, and the general need to improve the time to market of new services. In this situation the integration with existing solutions for service provision costs relatively less than the integration with well consolidated solutions such as the call/connection control in current switching systems for the POTS. The benefits of using TINA stem also from the ability to support in an integrated way control and management applications and the ability to easily accommodate for changes in standardisation. TINA offers flexible solutions which reduce the costs of software development. Adoption of TINA guarantees a protection in investment and the reuse of some existing solutions.





TINA can play a significant role in the evolution of IN networks [508-WP]. The current trend in the IN world is to distribute the intelligence in the network by using distributed platforms, and in defining interfaces between the intelligent layer and the transport network. TINA has a role in defining requirements and specifications for the distributed intelligence layer, especially concerning the characterisation of CORBA platforms for telecommunications. It is also possible to use the TINA Service

Architecture and have TINA components interact with legacy IN platforms via adaptation units. An approach that seems more useful, from a PNO point of view, consists of having TINA define a library of reusable components tailored for IN which can make use of current IN interfaces, such as INAP, and future interfaces in order to control switching resources. In this way the complexity of the adaptation unit can be avoided, still maintaining the advantages of the distributed and open approach introduced with TINA.

Alignment of TINA and TMN architectures could be accomplished by effecting some modifications and simplifications in TINA. This would then enable a significant reduction in complexity in adaptation and inter-working between the two systems, which would allow the introduction of TINA to be much more cost-effective. Where

TINA systems will score over TMN is in the use of distributed platforms, modelling concepts and open interfaces. As markets open up there will be a proliferation of service providers and retailers, and it is highly likely that they will use the latest technology and the systems with the greatest flexibility - in other words, TINA. So to maximise potential for offering new services to the customer, the network operator will need the flexibility to interoperate with these new clients. This flexibility will be provided by TINA.

The Project concluded that there is not too much scope for applying TINA to the

Internet due to the fact that TINA tends to be designed for Telecom applications for broadband networks. The communication session model does not cope well with many simultaneous connections each of short duration. Furthermore there is a different pace between the specification and development of solutions in Internet and

TINA. Also the Internet is more “industry and market” oriented than TINA, more and more products are now being made available to exploit the Internet, e.g. increased functionality is offered on the WWW with use of Java applets. Possible application areas for TINA include the management of routers on ATM networks, or support services with a guaranteed Quality of Service. TINA could learn from the Internet experience and many Internet technologies could be embraced to support TINA concepts such as use of Java for building distributed applications and the use of the

Network Computer or lightweight clients as the standard terminal equipment.

Integrating TINA solutions with current signalling mechanisms, such as the B-ISDN

UNI or the CTI (Computer Telephony Integration) interfaces will be best accomplished by specifying APIs, corresponding to the different signalling interfaces, that can be accessed by TINA components. In this case, it is fundamental that TINA defines a set of components that are tailored to these APIs, so that complex generalpurpose adaptation units can be avoided.

4.2.2 P608 TINA concepts for third generation mobile systems

P608 ran from August 1996 to April 1998. The purpose of the Project was two fold; firstly to investigate how UMTS can benefit from TINA principles in the areas of service & network management and administrative processes and to support the realisation of UMTS standards in these areas based on TINA principles. Secondly, the page 16 (27)





Project aimed to specify how terminal mobility and handover can be taken into account in TINA specifications for DPE and connection management.

The control and management platform of UMTS was identified as a potential target for the application of TINA concepts. One reason is that current IN and TMN concepts, considered as architectural basis for the UMTS control and management platform, are evolving toward CORBA and TINA. Furthermore, [EUR608D1] showed how, in the Enterprise viewpoint, the UMTS business model can be mapped to the

TINA model facilitating the exploitation of TINA concepts in UMTS.

The UMTS and TINA architectures set out to solve different problems. Each of the proposed architectures has some pitfalls, and each has useful features. TINA excels in the area of management, service m anagement in particular, an area where UMTS is not overly strong. UMTS has incorporated mobility from its inception, an area that was neglected within TINA. It is desirable to utilise concepts from both UMTS and

TINA in order to help each architecture to overcome its problems. The Project showed that UMTS concepts can be successfully introduced into the TINA architecture to provide mobility support and further work in this area is carried out by the TINA consortium.

Two approaches were examined in some detail. The first, namely the re-utilisation of existing technologies as a mobile-enhanced transport network with TINA as a management platform, provides a valid means of incorporating mobile terminals into the TINA fold. The second approach, to directly enhance the TINA object-oriented model to support UMTS features such as macro-diverse and multi-bearer connections, has been regarded with interest by the TINA organisation.

Also, a proposal for better Service Management based on TINA concepts was introduced for UMTS. TINA is suitable for handling diverse kinds of UMTS requirements in the area of service management, user profile implementation and control, subscription, and accounting in particular.

4.2.3 P715 EURESCOM Services Platform

EURESCOM Project P715 began in March 1997 and is scheduled to run until

February 1999. The objective of P715 is to develop a service platform based on the

TINA service architecture. The TINA DPE and service architecture tests were developed using various commercial CORBA products. Using this platform, a number of services have been developed, centred on the retailer-consumer reference points in the TINA business model, including a chat service and a distributed scheduler.

TINA is used to provide a common environment in which users can access multiple retailers regardless of location. A user can log onto any retailer and avail of the services provided by that retailer. This process is enabled by a set of well-defined open interfaces. Although it can be quite an effort to move away from proprietary service provisioning mechanism into a more open environment, such a move provides obvious benefits to the user who can now receive services from a wide range of retailers.





4.3 ACTS

4.3.1 ReTINA

The goal of the ReTINA project is to develop and demonstrate an industrial- quality

Distributed Processing Environment (DPE) for the telecommunications industry.

Specifically, the objectives of the ReTINA project are threefold:

 to develop a TINA-compliant, industrial-strength DPE, and associated specifications for use by manufacturers and procurers;

 to demonstrate and experiment with information network services implemented on the project's DPE and involving heterogeneous environments, in terms of size and supporting technology.

 to establish its DPE platform and associated technologies as a world-wide de facto standard for TINA-C compliant telecommunications applications, and to contribute to the development of standards for the telecommunications industry at large.

ReTINA has specified and developed a real-time DPE and computing services. It has made contributions to the TINA-C and the OMG on the notification, trading, persistence and transaction computing services and on fault-tolerance, real-time behaviour and minimum requirements in CORBA

4.3.2 VITAL

The overall objective of the VITAL project " is to develop, implement, demonstrate, and validate an Open Distributed Telecommunication Architecture (ODTA) for deploying, managing and using a set of heterogeneous multi-media, multi-party, and mobility services" .

VITAL is probably one of the world's richest source of experience in implementing

TINA specifications. The TINA architecture was challenged in a set of trials by means of a set of tele-training applications. The application suite featured Desktop

Audio/Video Conferencing (on IP and ATM), Chat, Slide Presentation, Shared

Whiteboard, Digital Library and Juke Box applications. The demonstrators further show that the VITAL ODTA is capable of supporting personalisation of services and on-line administration of new subscribers. The integrating architecture, the ODTA, runs on top of a truly heterogeneous transport network consisting of ATM, Internet and ISDN equipment of different manufacturers.

VITAL proves that the TINA-based architecture like the ODTA can indeed act as a virtual market place for telecommunications services. This includes support for multiple cooperating and competing service providers through a federation mechanism.

The VITAL experience has proven the great extent to which TINA implementations are re-usable. It is therefore projected that many of the modules developed in VITAL will be re-used beyond the duration of the project, even if the system as a whole may become obsolete with time. VITAL has implemented, validated and integrated communications software technology and applications (NetMeeting, Meetingpoint,

…) that are available today. VITAL has integrated these technologies into an open page 18 (27)




Deliverable 2 Volume 3: Annex 2 - Assessment of TINA in the Real World architecture for delivering a wide variety of services over heterogeneous network environments.

Vital trials have validated the architecture in terms of reusability, extendibility and scalability of the identified components. The ODTA components are implemented and tested on available distributed object-oriented technology.

VITAL extended and refined TINA architecture to provide the selected service features. Possible gaps and inconsistencies have been resolved by using input from areas such as Intelligent Networks (IN), Telecommunications Management Networks

(TMN), Internet and JAVA technology.

Besides Vital has proven that TINA services are easily accessible via a common web browser interface and platform independent thanks to the use of JAVA language and

Applet technology for retailer software. The following sections shortly describe how and why.

4.3.2.1 DEPLOYING services in Java

Java language has been used as the main development language for the Consumer parts of the VITAL services. Java provides a simple widget approach to GUI implementation as well as providing a much simpler interface to the Vital DPE, implemented in Orbix. This interface is provided by OrbixWeb, which maps CORBA to Java so Consumer services could be developed in a single language.

Java comes with the added advantage of being a platform-neutral language - the same code can be run on any platform, providing that a Java Virtual Machine (JVM) is available. The language also supports the development of programs, called Applets, that can be downloaded in a Web Page and run in a Web Browser. Using Java language allows Service providers to make services run on the widest range of platforms.

VITAL services are divided into two categories:

 preinstalled services that require installation on the Consumer terminals;

 downloadable services that use a Web based solution to service deployment and don't require software pre-installation.

4.3.2.2 The Retailer Applet

The Retailer Applet is a Java Applet which enables a user to connect to a specific

Retailer, establish an Access Session and then run Service Sessions for downloadable services. The code for the Retailer Applet is independent of the Retailer, being configured by a number of parameters in its HTML tag.

The Retailer Applet is loaded (see Figure 1) when the user points his browser at a

Retailer's web page. At this point the Applet creates a PA Initial object and presents a window, allowing the user to attempt to log into the Retailer and establish an Access

Session. The user is then presented with a list of services to which he has subscribed.

The Applet is implemented in such a way that a browser can not be running more than one Retailer Applet at any one time. This means that the browser can have one connection to one Retailer. The Retailer Applet is started in its own thread to prevent the Applet from being stopped and subsequently terminated when the user points his browser at a different web page. All visual components for the Retailer Applet are




Volume 3: Annex 2 - Assessment of TINA in the Real World Deliverable 2 implemented in their own frame, outside of the provider's Web page. The user is free to continue to use his browser once connected to a Retailer.

Retailer Domain X

Download Applet

Web Server

User Machine

Interact with ODTA

ODTA Components

Figure 1 Interaction between Domains (applet downloading)

The ODTA components within a Retailer Domain may be distributed across a number of machines, and are unlikely to be running on the same one, by exploiting advantages of distributed processing.

4.3.2.3 Implications of Deploying Services with Applets

Vital has shown that Java and Applet technology is sufficiently mature to allow all user terminal components of the architecture to be downloaded in an Applet. This eliminates the need for any pre-installed components on the user's terminal, this having several advantages:



Users do not need to install software themselves so there are fewer support requirements on the Retailer. No disk space is taken up on the user's terminal either.



Code is obtained from a central point making updates to the terminal components very simple. The Retailer only needs to change the code on his webserver which will then be available to all users. There is no need to ship software updates to users and again offer support when they have problems installing them.

The inheritance approach to server implementation has shown that new services can be delivered in a very short time. The developer is left to concentrate on the servicespecific aspects of the new service whilst being given the framework which will allow the service to be downloadable.

Java enabled web browsers are becoming available on an ever increasing range of platforms. As a result the number of potential users who can access services deployed in this way is increasing, providing a larger target market for prospective Retailers.

Some services are unsuitable for deploying in this way. The DVAC (Desktop Video

Audio Conference) is an example of a service which places specific requirements on the users terminal - there must be a video card and camera available.

Applet service deployment in this way provides for a highly scaleable architecture for service provision. As software is not distributed to users in the conventional sense, the administration overheads to the Retailer are no different whether there are two or two thousand subscribers. The main issue of scalability now becomes one of network bandwidth and a fast enough response time for users coming online. page 20 (27)





4.3.3 PROSPECT

The aim of PROSPECT was to realise and validate via a commercial/business enduser trial, the integrated end-to-end management of Integrated Broadband

Communication services in a multi-service provider and broadband network architecture, incorporating Internet, TINA and TMN technologies. A prototype Tele

Education Service was implemented of a Tele-Education service used to test the management systems across multiple domains.

The project drew heavily on TINA specifications in its designs. These TINA specifications were not complete at the beginning of the project and this, together with the very closed mode of operation taken by TINA-C made it difficult to track developments in the TINA architecture closely. Therefore, TINA specifications were used to provide some architectural and structural ideas, but no attempt was made to adhere to later TINA specifications as they emerged.

A major departure from TINA was in the mechanism used for controlling and managing the network. IP applications were used for user services, principally Webbased applications and multicast-based conferencing. This required the management of an IP network infrastructure, in the form of customer routers connected by an ATM backbone, forming a Virtual Private Network (VPN) functioning as a multi-domain

Intranet, or Extranet. Apart from being informed by some general concepts in the

VPN design, the TINA Network Resource Architecture was not used in Prospect. In fact a general analysis of the TINA Network Architecture reveals that its hierarchical and centralised nature would make any mapping onto the distributed routing approach of the Internet a clumsy one [PROSPECT14].

TINA specifications for subscription and accounting management were taken directly from the Service Architecture and augmented to support IP based services. A separation of service independent and service dependent parts was adopted for session control from the TINA model and proved a very valuable concept. Interactions between the session control logic and subscription and accounting management were largely service independent and so, using these components for different services required very little modification. Clearly identifying where a component is service independent and where it is service dependent was highlighted as an important part of managing its reuse in different service management applications.

Following the principles of the VPN integration architecture particular attention was paid to modelling inter-domain administrative gateway functions, such as authentication, authorisation, accounting and access control, by means of TINA’s session management components (e.g., USM, SSM). For these aspects, the TINA-SA did provide useful structuring and separation principles, thereby supporting the underlying assumption that such functions can be encapsulated and to a large extent separated from the core service functionality.

The component model of the TINA Service Architecture was found to be very flexible, supporting different stakeholder models in different trials with the need for very little reconfiguration However, the immaturity of current TINA-Internet integration work, especially in addressing scaleable, performance and deployment issues makes integration at the network level a major challenge.

TINA tends to be regarded as a complete solution, and that a high level of conformance to a TINA framework is required to gain benefit from individual components. Prospect has shown that this is not necessarily the case and that TINA components can be integrated into less rigid solution frameworks.





4.3.4 TOSCA

The objective of the TOSCA project was to develop an open service creation platform which can be applied to TINA and IN architectures. Rapid service creation is recognised as a key requirement for the business opportunities offered by networks providing component-based services. This project aimed to build upon the current pragmatic approaches to service creation for Intelligent Networks so as to expand upon their functionality, address the openness of these platforms and develop an approach which will provide a streamlined migration to TINA, and combined

IN/TINA, service creation.

The first part of the project developed a service creation and deployment platform for a TINA based target network. This service creation platform drew upon industrial practice, mainly in the creation of intelligent network services. The unification of the

IN and TINA approaches to service creation was addressed by emphasis on the use of

SDL tools coupled with OMT principles and IDL/ODL interfaces.

The service creation platform incorporated semi-automated composition/decomposition of services, service validation and interaction detection.

The importance of the user interface to the service creation system merited special attention and a number of interface types were explored which cater for various types of designer from non-technical to technical.

In the second part of the project, the TINA creation process was extended to include intelligent network interworking. In this part, a number of services were developed, which are of a cross platform nature. Co-ordination of the services created between two IN platforms and between an IN and TINA platform was explored.

4.3.5 DOLMEN

The ACTS project DOLMEN examined extensions and refinements of the TINA architecture to address personal and terminal mobility. It’s aim was to develop, validate and promote a Service Architecture (called Open Service Architecture for

Mixed fixed and mobile environments - OSAM) for open provision of communication services over both fixed and mobile, heterogeneous and multi-provider, telecommunications networks. The work has been carried out in the context of two technology trials: 1.construction of a Service Machine compliant to the Architecture;

2.porting of the Service Machine functionality over a heterogeneous information processing and telecommunications infrastructure (including 2nd and 3rd generation mobile facilities) provided by two National Hosts with international connections; and

3.deployment of two applications (distributed hypermedia information browsing and audio-conferencing), to exercise the facilities provided by the Service Machine.

[Trigila] states that terminal and personal mobility have impacts on the business model and reference points in TINA. DOLMEN suggested extending the TINA business model with two new roles: the DPE provider and the Terminal Provider in order to deal with terminal and personal mobility.

4.3.6 REFORM

The scope of the REFORM project is to specify, design and develop a system providing the necessary means and functions for ensuring network performance and availability within acceptable levels under normal and fault situations. Specifically, the objectives of the REFORM project are: To study, specify and develop page 22 (27)





1.

in the control plane



OAM mechanisms for fault detection, focusing on faults caused in or escalated in the ATM network layer;

 fast and reliable ATM network layer self-healing mechanisms and related

OAM protocols;

 routing and spare resource control algorithms;

2.

in the management plane

 adaptive load balancing algorithms with inherent self-healing capabilities and suitable fail-safe protocols for routing information exchange;

 intelligent dynamic distributed and centralised routing algorithms and service migration algorithms;

 cost-effective spare resource allocation and management schemes;

The REFORM system was implemented using a CORBA based TINA framework.

The system covers both the control and management planes of network operation, with emphasis on performance, configuration and fault management areas. In particular, REFORM is concerned with restoration mechanisms in the ATM network layer and their integration with the control and management layers functionality, aiming at providing an integral and network-wide treatment to the problem of fault restoration. Specifically, the REFORM system will incorporate rapid and reliable

ATM network layer self-healing mechanisms, in the control plane, intelligent load balancing, dynamic routing and resource management functions, spread across the control and management planes, all interworking together with the overall goal to ensure cost-effective network performance and availability under normal and fault situations.

4.3.7 SCREEN

The objective of the SCREEN project was developing an approach for service creation targeted to multivendor environments, supporting CORBA and TINA. The project aimed to produce a seamless tool-supported approach to component-based service creation, consolidating and extending existing and emerging technologies. The primary objectives of the project were:

 to define and demonstrate service creation environments (SCEs) targeted to specific service architectures and to distributed processing environments (e.g.

TINA, CORBA),

 to demonstrate creation of services from reusable components,

 to demonstrate the effectiveness of SCEs in treating quality of service (QoS) constraints and service interaction concerns,

 to promote the use of SCEs by means of trials and documenting sound engineering practices for service creation.

Using commercial tools, a Service Creation environment (SCE) for TINA based services was developed. Coupled with this, engineering practices for service creation targeted to TINA platforms were documented as a kind of user manual for service creation addressed to service developers. These were based on use of a dedicated set




Volume 3: Annex 2 - Assessment of TINA in the Real World Deliverable 2 of methods, tools and languages and covering service creation for any service domain for which the TINA DPE provides distributed provisioning.

The resulting service creation engineering practices and SCE were evaluated by means of both internal and external trials, with the ACTS DOLMEN and ACTS

VITAL projects. The outcomes of these trials were used to iteractively test and improve the engineering practices, and to validate the key aspects of the engineering practices: Stepwise development, service creation roles and their interface, reuse, use of the DPE primitives, handling of user-presentation and feature interaction handling. page 24 (27)





5 Conclusions

TINA Concepts are sound and have been adopted in other systems. The influence of

TINA on evolving architectures, such as AT&T Geoplex and Sun Microsystems Jain has been described in Deliverable 1 Annex 1 (PIR 2.2). This document has examined the role of TINA in different Telecommunications and Information Technology standards bodies, such as the ITU and the OMG.

Within the ITU-T, TINA principles and concepts have been proposed in a number of study groups. These include the adoption of the TINA -C ODL in SG-10 and the application of TINA concepts to signalling capabilities and frameworks for telecommunications networks in SG-11 relating to general network aspects. In ITU-T

SG 13 the TINA business model has been proposed for study. SG16 is studying multimedia service definition and multimedia systems; here TINA can play a role in the provision and management of multimedia services. The H.323 protocol developed by the ITU will also have an important role in the development of multimedia services and systems. TINA also is expected to have a significant impact in the development of

ITU IN CS4

The OMG remains an important forum for promoting TINA concepts and for product development using TINA based architectures and services. In the OMG, TINA related developments include the development of A/V Stream control and management, interworking between CORBA and IN based architectures, and Telecom Service

Access and Subscription. In the future other OMG initiatives such as the use of

Business Modelling Concepts, the adoption of pluggable interfaces and the development of wireless communication and mobility support by the OMG will continue to have strong TINA influences.

The IETF is another important forum for dissemination of TINA results and concepts.

TINA concepts and results have been used in IETF sponsored initiatives such as,

NAVDEC and PINT. An in-depth description of IETF related projects can be found in

Annex 2 (PIR 3.2).

Many new and evolving systems emerging from the ITU, IETF and OMG while not

TINA based, are likely to have significant TINA-like features which have been derived from the TINA specifications. At the same time the development of fully

TINA systems for service creation and deployment is likely continue especially for IN and TMN services. The TINAC has developed compliance criteria for TINA systems.

A number of TINA compliance levels have been defined which allow a system to be classified with a range of compliance levels according to whether it has adopted

TINA principles or is a full implementation of a TINA system.

Systems which provide a high level of TINA compliance include SPRINT ION which can be seen as a full TINA implementation. Starvision also offer a platform, SMCS, which is TINA based. Many technologies can be used to support the development of

TINA based services and these typically have a high level of compliance with the business model and architectural principles. JINI, JAIN, and Aero from Windward are examples of such technologies. It is worth noting that even technologies which compete with TINA or with aspects of TINA, such as the Resource Management

Architecture or the DPE also comply with TINA principles. JINI, JAIN, Geoplex,

Parlay and PINT are examples of technologies which compete with TINA or aspects of TINA and can yet remain TINA compliant.





The Global One Alliance, a joint effort involving Deutsche Telekom, France

Telecom, and Sprint, has conducted a large scale experimental implementation of multi-operator services based on a multi-retailer TINA platform; offering Universal

Access, UPT and Group communication services. The testbed was built by integrating distinct TINA platforms and computational objects, relying on their compliance to

TINA reference points.

Experience with TINA through both ACTS and EURESCOM Projects has shown that

TINA provides a flexible, adaptive service creation and management architecture for the development of new and innovative telecommunications services. These projects have developed TINA platforms for service creation and the deployment of multiparty multimedia services and have shown how TINA and TINA concepts can be applied to IN, TMN, personal mobility and Internet based services. Although the size and scope of TINA means that a lot of effort is initially required when building a

TINA system; once the initial system is in place the prototyping and development of new TINA services is speedy and efficient. page 26 (27)





References

EUR508D2]

[EUR608D1]

EURESCOM Project P508 "Evolution, Migration Paths and

Interworking to TINA", Deliverable 2: "Migration Strategies and

Interworking with legacy systems", January 1997.

EURESCOM Project P608 “TINA Concepts for 3 rd Generation

Mobile Systems” Deliverable 1 “Opportunities to utilise TINA

Concepts within UMTS Standards / UMTS Mobility

Requirements on TINA”

[H.323] ITU-T, Recommendation H.323, “Visual Telephone Systems and

Equipment for Local Area Networks which provide a Non-

Guaranteed Quality of Service."

[McGrath et al]

TINA 97, “A CORBA Framework for Multimedia Streams”, D.

McGrath, M Chapman

[TINA-NRIM] TINA Consortium; Doc No TB_LR.010_2.1_95 “Network

Resource Information Model”; TINA-C August 1995

[NTT]

[OMG1]

[OMG2]

[OMG3]

NTT et al “The Tina Trials”, http://www.tinac.com/

“Control and Management of Audio/Visual Stream -Final report on the RTF”, ftp://ftp.omg.org/pub/docs/telecom/98-10-04.pdf

“Interworking between CORBA and Intelligent Network

Systems” RFP, ftp://ftp.omg.org/pub/docs/telecom/97-12-06.pdf

“Telecommunication Service Subscription and Access” RFP, ftp://ftp.omg.org/pub/docs/telecom/98-09-07.pdf

[P508-WP] R. Minerva, C. Moiso; White Paper on Intelligent Networks and

CORBA; OMG TF, Nice, November 1996

[PROSPECT14] AC052/WP1/D14B/001; Prospect Deliverable 14m” D14B -

Final System Model”; August 1998

[Starvision]

[TINA1]

[TINA-95]

[Trigila]

[Windward] http://www.starvision.com/Starvision/news-investment.html

“IN access to TINA services &Connection Management (IN-

TINA Adaptation Unit)”, Request For Proposal

TINA Consortium. Service Architecture . Version 2, March 1995.

The ACTSLINE conference: Advances in Telecommunication

Network Management and Service Creation, “Architecture for

Mobile-Fixed Integration” http://trafalgar.windwardsolutions.com/main.htm




Vol3 - Eurescom

What is TINA and is it Useful for the TelCos?

Deliverable 2

A TelCo Assessment of TINA

Volume 3 of 4: Annex 2 - Assessment of TINA in the real world

Suggested readers:

For full publication

February 1999

List of Authors

Table of Contents

Abbreviations

1 Introduction

2 TINA oriented initiatives in Standard Bodys

2.1 ITU-T

2.2 Object Management Group

2.3 IETF

3 TINA enabling products

3.1 Definition of TINA Compliance

3.2 TINA Compliant Systems

3.3 Product Compliance Matrix

4 Experience Gained from TINA

4.1 Global One Alliance

4.2 EURESCOM

4.3 ACTS

5 Conclusions

References

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib