TSAS:

1
TSAS
TINA Reference Points become an OMG
StandardPresentation to the TINA 2000 Conference
Linda Strick, GMD Fokus strick_at_fokus.gmd.de
Marcel Mampaey, Alcatel marcel.mampaey_at_alcatel.be
2
Overview of the presentationand Structure of
Submitted Document

• Objectives of the submission (section 1)
• Submitters (section 1)
• Response to RFP Requirements (section 2)
• Architecture (section 3)
• Core Segment (section 4)
• Service Access Segments (section 5)
• Subscription Segments (section 6)
• Compliance Points (section 8)

3
Objectives

• The service requested consists of standardized
  interfaces and mechanism for
• enabling end-users to access and configure a
  telecommunication service according to their
  wishes and
• to allow value-added service providers to offer
  their services to End-users.
• It manages contracts for end-users and service
  providers,
• locates matches between user requirements and
  service providers subscription offers
• enables the establishment of mutually anonymous,
  but authenticated, access between end-user and
  service provider.

4
Submitters
Also supported by

• Alcatel
• ATT
• Deutsche Telekom AG
• GMD Fokus
• Hitachi
• Lucent Technologies
• Nippon Telegraph andTelephone Corporation
• Nortel Networks
• Siemens AG

• British Telecommunications plc.
• Cisco Systems
• Humboldt University
• IBM TelecommunicationsIndustry
• KPN Royal Dutch Telecom
• Sprint
• Sun Microsystems

5
TSAS and Parlay

• Parlay Group
• Create an open Application Programming Interface
  (API) that would enable secure, public access to
  core capabilities of telecommunication and data
  networks.
• Members ATT, BT, Cegetel, Cisco, Ericsson, IBM,
  Lucent, Microsoft, Nortel Networks, Siemens, and
  Ulticom (formerly DGMS)

• Release 2.1 out now
• TSAS
• Core part fed into Release 2.0 / 2.1 -gt compliant
• Intend to keep Parlay and TSAS consistent for
  Service Access and Subscription
• Provide points of flexibility where different
  approaches are possible
• e.g. Authentication

6
TSAS and TINA

• Most of the specification is based on TINA specs,
  BUT
• The entire specification is re-structured
  according to the flexible segment concept and
  to OMG guidelines, and modernized according to
  contributors validation work
• Core segment is strongly modified and simplified,
  and aligned with corresponding Parlay 2.1 specs.
• Service access segments are re-structured and
  simplified (over-specification suppressed)
• Subscription segments are re-structured and
  simplified, information model is updated
  according to recent evolutions
• TSAS specs are fed-back to TINA for endorsement
  by TINA
• Liaison to ITU-T after spec stabilization in OMG
  for aligningthe Q series supplements 27 and 28

7

• Objectives of the submission (section 1)
• Submitters (section 1)
• Response to RFP Requirements (section 2)
• Architecture (section 3)
• Core Segment (section 4)
• Service Access Segments (section 5)
• Subscription Segments (section 6)
• Compliance Points (section 8)

8
Response to RFP requirements

• Relationship to existing OMG specifications
• Mandatory requirements
• Retailer administration interface requirements
• Initial access related interface requirements
• Service access related interface requirements
• Optional requirements
• Issues to be discussed
• From the points above none
• Security

9

• Objectives of the submission (section 1)
• Submitters (section 1)
• Response to RFP Requirements (section 2)
• Architecture (section 3)
• Core Segment (section 4)
• Service Access Segments (section 5)
• Subscription Segments (section 6)
• Compliance Points (section 8)

10
TSAS Architecture
General principle
Domain X
Domain Y
User
Provider
Provider
User
11
TSAS Architecture
Business Model
Consumer
Domain
ServiceProviderDomain
RetailerDomain
Subscriber
End-User
12
Segmentation principles
13
Segments Framework

• The segment is an optional set of functions
• A segment can be activated and de-activated with
  Framework operations
• One segment corresponds to either
• one set of interface(s) on one domain
• two such sets of interface(s), each on one of
  thepeer domains
• The segments are limited to access
  functionality,access related functionality (such
  as invitations),or subscription related
  functionality

14
Segments defined in TSAS

• Core segment (mandatory)
• Service access segments
• Invitation segment
• Context
• Access Control
• Subscription segments
• Subscriber administration
• Service provider administration

• Service Discovery
• Session Control

• End-user administration
• End-user customization

15

• Objectives of the submission (section 1)
• Submitters (section 1)
• Response to RFP Requirements (section 2)
• Architecture (section 3)
• Core Segment (section 4)
• Service Access Segments (section 5)
• Subscription Segments (section 6)
• Compliance Points (section 8)

16
TSAS Domains and Roles
17
TSAS Domains and Roles
Provider
User
18
TSAS Domains and Roles
19
Service Access

• Service Access
• A consistent approach to allowing users to access
  telecoms services in a controlled and secure way.
• Three Phases
• Initial Contact
• Authentication
• Access

20
TSAS phases

• Initial Contact
• allow both domains to initiate interaction
• interface DfTsasInitial
• Authenticate
• allow both domains to authenticate the identity
  of the other domain
• interface DfTsasAuthenticate
• not used if CORBA security is available
• Access
• allow both domains to access interfaces and
  services
• interface DfTsasAccess

21
TSAS phases initial contact
22
TSAS Client contacts TSAS Provider(application
level authentication)
23
TSAS Client contacts TSAS Provider(CORBA
Security used for authentication)
DfTsasAccess
TSAS Client
DfTsasInitial
TSAS Client gains areference to
DfTsasInitialof TSAS Provider
Initial Contact
Access(start ofaccess phase)
request_access( )
CORBA Security is identified as themechanism
used to authenticate domains.DfTsasAuthenticati
on interfacesare not used.
Authentication
24
TSAS Client contacts TSAS Provider(mutual
authentication)
25
Operations on Access interface

• After successful authentication, an access
  session exists, and the Access interface is
  available
• Interface Access void select_service ( )
  void sign_service_agreement ( ) void
  end_session ( ) void list_segments ( ) void
  get_segment ( ) void release_segments ( )
  void end_access ( )

26

• Objectives of the submission (section 1)
• Submitters (section 1)
• Response to RFP Requirements (section 2)
• Architecture (section 3)
• Core Segment (section 4)
• Service Access Segments (section 5)
• Subscription Segments (section 6)
• Compliance Points (section 8)

27
Some naming conventions
Business Model
28

• Objectives of the submission (section 1)
• Submitters (section 1)
• Response to RFP Requirements (section 2)
• Architecture (section 3)
• Core Segment (section 4)
• Service Access Segments (section 5)
• Subscription Segment (section 6)
• Compliance Points (section 8)

29
Subscription business model

Subscriber
Signs contract about service
usage
Authorize
Uses services
Retailer
User
30

Subscription business model cont

• Service Provider subscription

Sign contract about service retailing
Provide service
Service Provider
Retailer
31
Subscription Segments

Consumer
RetailerDomain
Domain
Subscriber/ End-User Admin
ServiceProviderDomain
Service Provider Admin
Subscriber
End-User Customiza tion
End-User
32
Simple Subscription

33
Subscription with user management

34

• Objectives of the submission (section 1)
• Submitters (section 1)
• Response to RFP Requirements (section 2)
• Architecture (section 3)
• Core Segment (section 4)
• Service Access Segments (section 5)
• Subscription Segment (section 6)
• Compliance Points (section 8)

35
Compliance points

• Three compliance points defined
• Core segment
• Service access segments
• Subscription segments

36
Thank you for your attention