ETSI TR 101 877 V1.1.1 (2001-06)

Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Requirements Definition Study; Scope and Requirements for a Simple call

DTR/TIPHON-01008

Harmonizacija telekomunikacij in internetnega protokola prek omrežij (TIPHON) - Študija definicije zahtev - Vsebina in zahteve za preprosti klic

General Information

• Status: Published
• Publication Date: 11-Jun-2001
• Technical Committee: TIPHON 1 - TIPHON Requirements, charging and security matters
• Current Stage: 12 - Completion
• Due Date: 19-Jun-2001
• Completion Date: 12-Jun-2001
• Ref Project: SIST-TP TR 101 877 V1.1.1:2004 - Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Requirements Definition Study; Scope and Requirements for a Simple call

Standards Content (Sample)

SLOVENSKI STANDARD
SIST-TP TR 101 877 V1.1.1:2004
01-april-2004
Harmonizacija telekomunikacij in internetnega protokola prek omrežij (TIPHON) -
Študija definicije zahtev - Vsebina in zahteve za preprosti klic
Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON);
Requirements Definition Study; Scope and Requirements for a Simple call
Ta slovenski standard je istoveten z: TR 101 877 Version 1.1.1
ICS:
33.020 Telekomunikacije na splošno Telecommunications in
general
SIST-TP TR 101 877 V1.1.1:2004 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

SIST-TP TR 101 877 V1.1.1:2004

---------------------- Page: 2 ----------------------

SIST-TP TR 101 877 V1.1.1:2004
ETSI TR 101 877 V1.1.1 (2001-06)
Technical Report
Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON);
Requirements Definition Study;
Scope and Requirements for a Simple call

---------------------- Page: 3 ----------------------

SIST-TP TR 101 877 V1.1.1:2004
2 ETSI TR 101 877 V1.1.1 (2001-06)
Reference
DTR/TIPHON-01008
Keywords
IP, service
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: [phone] Fax: [phone]
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at http://www.etsi.org/tb/status/
If you find errors in the present document, send your comment to:
[e-mail]
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2001.
All rights reserved.
ETSI

---------------------- Page: 4 ----------------------

SIST-TP TR 101 877 V1.1.1:2004
3 ETSI TR 101 877 V1.1.1 (2001-06)
Contents
Intellectual Property Rights .4
Foreword.4
1 Scope.5
2 References.5
3 Definitions and abbreviations.5
3.1 Definitions . 5
3.2 Abbreviations. 6
4 Services and service capabilities framework.7
4.1 The ITU ISDN approach to describing services. 7
4.2 The TIPHON environment . 7
4.3 Service capability framework . 9
5 Building service applications .10
5.1 Structuring service applications . 10
5.2 Service application models . 11
6 Deriving service capabilities .12
6.1 Structuring service capabilities . 12
6.2 Service capability model. 12
7 Simple call service application.12
7.1 Simple call as a basic service application . 12
7.1.1 Scope of the simple call service application . 13
7.1.2 Behaviour of the simple call service application. 14
7.1.3 Use of service capabilities. 14
7.2 Service capabilities for simple call. 14
7.2.1 Simple connectivity control. 14
7.2.2 Simple registration. 15
8 Prioritized requirements.15
Annex A: Business role model in a TIPHON environment .16
A.0 Introduction.16
A.1 Consumer .16
A.2 Retailer.17
A.3 Service provider.17
A.4 Connectivity provider .17
A.5 Relationships between domains.18
History .19
ETSI

---------------------- Page: 5 ----------------------

SIST-TP TR 101 877 V1.1.1:2004
4 ETSI TR 101 877 V1.1.1 (2001-06)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://www.etsi.org/ipr).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI Project Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON).
ETSI

---------------------- Page: 6 ----------------------

SIST-TP TR 101 877 V1.1.1:2004
5 ETSI TR 101 877 V1.1.1 (2001-06)
1 Scope
The present document defines the TIPHON framework that enables services to be developed which are able to
inter-work across multiple communication network domains and diverse network technologies. The framework
identifies services, service capabilities and service applications and defines the relationships between them.
The present document:
• considers how Service Capabilities can be combined to develop Service Applications;
• defines the requirements for a Simple Call Service Application.
The content of the present document does not infer any details of the implementation of any of the concepts expressed
within it.
2 References
For the purposes of this Technical Report (TR), the following references apply:
[1] ETSI TR 101 835: "Telecommunications and Internet Protocol Harmonization over Networks
(TIPHON); Project method definition".
[2] ITU-T Recommendation I.130: "Method for the characterization of telecommunication services
supported by an ISDN and network capabilities of an ISDN".
[3] ITU-T Recommendation I.140: "Attribute technique for the characterization of telecommunication
services supported by an ISDN and network capabilities of an ISDN".
[4] ITU-T Recommendation I.210: "Principles of telecommunication services supported by an ISDN
and the means to describe them".
[5] ITU-T Recommendation I.112: "Vocabulary of terms for ISDNs".
[6] ETSI TR 101 287: "Network Aspects (NA); Terms and definitions".
[7] ITU-T Recommendation E.105: "International telephone service".
[8] ITU-T Recommendation E.106: "Description of an international emergency preference scheme
(IEPS)".
[9] TINA-C: "TINA Business Model and Reference Points".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
administrative domain: bounded entity within which all encompassed constituent elements are under common
ownership, operation and management
domain: result of the application of specific policies to a specific network technology
International Emergency Preference Scheme (IEPS): IEPS enables authorized users to have priority access to
telecommunication services and priority processing of communications in support of recovery operations during
emergency events
network: telecommunications network that provides telecommunications services
ETSI

---------------------- Page: 7 ----------------------

SIST-TP TR 101 877 V1.1.1:2004
6 ETSI TR 101 877 V1.1.1 (2001-06)
network abstraction LAYER: provides a set of communications capabilities to the Transport Abstraction Layer that
are derived from, but independent of, the capabilities of a specific underlying network technology
network operator: entity that is responsible for the development, provisioning and maintenance of telecommunications
services and for operating the corresponding networks
public: attribute indicating that the application of an item qualified as "public" is offered to any person
This attribute does not indicate any aspects of ownership.
private: attribute indicating that the application of an item qualified as "private" is offered to a pre-determined set of
users
This attribute does not indicate any aspects of ownership.
service: commercial offering to a customer
It comprises functionality - known as a service application - set in a business context. The business context is outside of
the scope of TIPHON to consider as it determined by commercial or political concerns.
service abstraction layer: element of the TIPHON Application Plane that provides a modular and extensible set of
Service Capabilities for use in the creation of Service Applications
service application: integrated set of one or more Service Capabilities
TIPHON will not specify service applications but may consider such groupings where this contributes to the
identification and definition of specific Service Capabilities. The ability to select and combine Service Capabilities
offers a structured, yet flexible, means for creating service applications that:
• are internally coherent and self consistent;
• enable the inter-operation of services between different implementations of TIPHON systems;
• enable inter-working with other systems.
service capability: indivisible and exclusive set of functionality including user and network capabilities
service independent requirement: requirement that applies without reference to currently invoked service capabilities
service provider: entity that provides services to its service subscribers on a contractual basis and who is responsible
for the services offered
The same entity may act as both a network operator and a service provider.
service provider access interface: interface between a network and a service provider's equipment for enabling the
service provider to access specific functionality of a network
transport abstraction layer: provides a set of domain independent capabilities derived from the underlying Network
Abstraction Layer in response to the transport and connectivity requirements of the Service Abstraction Layer
user: entity using the services of a network via terminal equipment
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
GSM Global System for Mobile communication
IEPS International Emergency Preparedness Scheme
ISDN Integrated Services Digital Network
RDS Requirements Definition Study
SCD Service Capability Definition
SP Service Provider
ETSI

---------------------- Page: 8 ----------------------

SIST-TP TR 101 877 V1.1.1:2004
7 ETSI TR 101 877 V1.1.1 (2001-06)
4 Services and service capabilities framework
Traditional approaches to developing services offered by communications networks have largely been specific to a
single network technology, such as ISDN. This has tended to create problems in enabling services to operate across
multiple network technologies. An alternative approach is to derive a core set of capabilities in an abstract manner and
then map these on to selected network technologies though an abstract, technology neutral, network architecture. By
adopting this approach, the services developed on specific network technologies may be derived from a common core
set of capabilities. This enables easier inter-working between different network technologies at the functional level.
By using a common core set of capabilities to implement services, a basic level of functional inter-working should be
assured for TIPHON based networks. Furthermore, the approach enables technical inter-working problems to be
identified in a structured manner.
The traditional service development approach described has also restricted the development of services to the
limitations of the specific network technologies upon which they are based. The alternative adopted by TIPHON is a
more flexible and extensible approach to service development because it enables services to be constructed from the
aggregation of modular, re-usable components based on the concepts of service applications and service capabilities.
Service Interaction is a common problem within modern communications networks. The modular and hierarchical
approach adopted by TIPHON allows easier identification and resolution of such problems by enabling them to be
traced to the presence or absence of specific capabilities and the relationships between them.
4.1 The ITU ISDN approach to describing services
ITU-T Recommendations I.130 [2], I.140 [3] and I.210 [4] describe a method of describing service applications in the
Integrated Services Digital Network (ISDN) by bearer and teleservice attributes. In general bearer services offer bearer
attributes to teleservices and the teleservices provide service by manipulation of the bearer attributes. This approach
views attributes of an overall service application in 3 parts.
Table 1: ITU ISDN 3 layer service application model
Part Sub-part Assigned attributes (examples)
Low layer Information transfer Mode
Rate
Structure
Access attributes Access channel and rate
Access protocol
Signalling for each of layers 1 to 3
Information protocol for each of layers 1 to 3
High layer Type of User Information
Protocol functions for each of layers 4 to 7
General Supplementary Service provided
QoS
Interworking capabilities
In an environment comprising multiple network technologies, the lower layer attributes will vary between network
technologies. In this approach, the information transfer and access layer attributes cannot be considered common
between users.
4.2 The TIPHON environment
The TIPHON environment considers the case where multiple networks, possibly employing differing network
technologies, inter-work to provide end-to-end communications services as shown in figure 1.
This model supports the different business roles found within the heterogeneous communications environment
envisaged by TIPHON (see Annex A) and commonly found in modern public communications networks. The key
requirements for this environment are:
• separation of service applications and transport services hence enabling users to access their call handling
services irrespective of their transport connection;
ETSI

---------------------- Page: 9 ----------------------

SIST-TP TR 101 877 V1.1.1:2004
8 ETSI TR 101 877 V1.1.1 (2001-06)
• ability of service applications to work across multiple network domains thereby enabling users to access their
services irrespective of the network domain they are connected to;
• ability of service applications to work across multiple network technologies thereby enabling service providers
to offer services using a range of network technologies;
• ability to recursively construct network domains thereby enabling network providers to extend the reach of their
networks.
By introducing a number of layers of abstraction, the TIPHON model provides a framework that is able to describe an
end-to-end application capable of operating over a heterogeneous infrastructure.
TIPHON Application Plane
Service Application Layer
Service Abstraction Layer
Transport
Plane/Application
Plane Interface
Transport Abstraction Layer
Network Abstraction Layer
Terminal Access Transit Transit Access Terminal
Domain #1 Domain#1 Domain#1 Domain#2 Domain#2 Domain #2
TIPHON Transport Plane
Figure 1: The TIPHON network and service environment model
TIPHON identifies the following layers within this model:
• a Service Application Layer that provides the end to end communications application;
• a Service Abstraction Layer that is defined by a modular and extensible set of Service Capabilities that place
requirements on the Transport Abstraction Layer beneath it;
• a Transport Abstraction Layer that provides a set of domain independent capabilities derived from the underlying
Network Abstraction Layer in response to the transport and connectivity requirements of the Service Abstraction
Layer;
• a Network Abstraction Layer that provides a set of communications capabilities to the Transport Abstraction
Layer that are derived from, but independent of, the capabilities of a specific underlying network technology.
ETSI

---------------------- Page: 10 ----------------------

SIST-TP TR 101 877 V1.1.1:2004
9 ETSI TR 101 877 V1.1.1 (2001-06)
The TIPHON network and service environment model is separated into two planes that exist across the various network
domains encountered in the end-to-end communications path. The upper plane comprises the Service Application and
Service Abstraction Layers and is termed the TIPHON Application Plane. This plane addresses the implementation of
end-to-end communications applications. The lower plane includes the Transport and Network Abstraction Layers and
is termed the TIPHON Transport Plane. The TIPHON Transport Plane provides domain independent communications
capabilities to the TIPHON Application Plane. Requirements placed upon the TIPHON Transport Plane by the
TIPHON Application Plane are expressed in Service Independent Requirements documents in accordance with the
TIPHON project method [1].
The present document describes the framework for Service Capabilities in the Application Layer. The Network
Abstraction Layer and Transport Abstraction Layer are defined by sets of Service Independent Requirements and are
described elsewhere.
4.3 Service capability framework
TIPHON identifies a number of concepts when considering the TIPHON Application Plane. These are derived from a
decomposition of a service into constituent elements. TIPHON places the following meanings on the terminology used
to describe services as follows:
Service: commercial offering to a customer. It comprises functionality - known as a Service Application - set in a
business context. The business context is outside of the scope of TIPHON to consider as it determined by commercial
or political concerns.
As shown in figure 2, Service Applications are constructed in a modular fashion from Service Capabilities within the
TIPHON Service Abstraction Layer.
Service
Service Application
Service Capability
Service Capability
Service Capability
User Network
Capability Capability
Commercial Context
Figure 2: Services and Service Capabilities
Service Application: a Service Application is an integrated set of one or more Service Capabilities. TIPHON will not
specify Service Applications other than Simple Call but may consider such groupings where this contributes to the
definition of specific service capabilities. The ability to select and combine Service Capabilities offers a structured, yet
flexible, means for creating service applications that:
• are internally coherent and self consistent;
• enable the inter-operation of services between different implementations of TIPHON systems;
• enable inter-working with other systems;
• enable service providers to develop differentiated services that inter-work across multiple networks and multiple
network technologies.
ETSI

---------------------- Page: 11 ----------------------

SIST-TP TR 101 877 V1.1.1:2004
10 ETSI TR 101 877 V1.1.1 (2001-06)
Service Capability: an indivisible and exclusive set of functionality including the capabilities of users and networks
that represent functionality required by either users of the service or for inter-service provider connection. A Service
Capability does not include the definition of communication:
• types such as voice, video or text;
• formatssuch asspecificcodecs.
Since these are examples of attributes of a specific Service Application. A Service Capability must negotiate and
manipulate these attributes by incorporating mechanisms, such as the ability to select a particular communication type
and associate with it a specific communication format.
Every Service Capability has an Identifier that enables it to be distinguished from other Service Capabilities.
An existing Service Capability may be augmented by additional functionality, in which case a new Service Capability is
created. Service Capabilities become related to each other when used to design a Service Application, as shown in
figure 3. Service Capabilities do not interact other than through a Service Application.
Service Applications
Service
Application
Layer
Service
Abstraction
Layer
Service Capabilities
Figure 3: TIPHON Service Capability Framework
Service Capabilities are combined in the definition of Service Applications, which inherit their functionality and
attributes. To be TIPHON compliant, TIPHON Service Capabilities may not be supplanted by independently defined
Service Capabilities that provide the same functionality. Service Applications may also include additional functions that
are not defined by TIPHON. Simple Call is an example of a Service Application. Other Service Applications may be
defined using varying combinations of Service Capabilities, including those used to construct the Simple Call Service
Application.
5 Building service applications
There are essentially two approaches to the development of Service Applications. One approach is to analyse the
requirements of an envisaged Service Application and then decompose this to the point of identifying the constituent
Service Capabilities that will be required for implementation - a "Top Down" approach. The other approach is to take an
existing set of Service Capabilities and use these to construct a Service Application - a "Bottom Up" approach. Both of
these approaches are equally valid, although the former approach is likely to be more common until a number of
Service Capabilities are identified.
5.1 Structuring service applications
In determining which Service Capabilities will be required to construct a Service Application, or identifying whether
new Service Capabilities will be required, the service designer will create a model for the service application. This will
consider the:
• scope of the Service Application and the application of the design to the various domains envisaged;
• complete behaviour of the application, including under failure conditions;
ETSI

---------------------- Page: 12 ----------------------

SIST-TP TR 101 877 V1.1.1:2004
11 ETSI TR 101 877 V1.1.1 (2001-06)
• identification of inter-working through the reuse of well known or published Service Capabilities;
• reuse of existing Service Capabilities;
• identification of requirements for new Service Capabilities.
Building applications is outside the scope of the TIPHON project. However, using example service applications may be
valuable in helping define the components.
5.2 Service application models
To enable Service Applications to be developed that will inter-work across the various domains within the TIPHON
environment, they need to reflect an end-to-end model of this kind. To aid this process, TIPHON has identified the
application environment model, shown in figure 4. In the example shown, there are three Service Capabilities, A, B and
C. These are distributed across the TIPHON network and service environment model and instantiated as C ,C and C ,
o T2 T
etc.
C C C
o T2 T
B B B B B B
o a1 T1 T2 a2 T
A A A A A A
o a1 T1 T2 a2 T
Terminal Access Transit Transit Access TeTerrmmiinnaall
Domain #1 Domain #1 Domain #1 Domain #2 Domain #2 DoDommaaiinn ##12
Figure 4: Service Capabilities interworking across Domains
This model encompasses the following concepts:
• communication is required between Service Capabilities to achieve inter-operable and seemless Service
Application inter-working and service provision across heterogeneous network domains. This shall be achieved
through the support of Service Capabilities and the associated information flows by the communications network
technology mappings developed by following the TIPHON process. These are indicated by flows such as A to
o
A in figure 4, which are developed as part of steps C and D of the TIPHON project process;
a1
• Service Applications may also contain components that need to communicate information flows other than those
required to support the needs of Service Capabilities. These information flows need to be associated with the
Service Application with which they are involved. Domains that provide only communications transport
capabilities that are not involved with the behaviour of the particular Service Application shall pass these
information flows unchanged. In such cases it must be possible to identify the entity on whose behalf the
information is carried. This is indicated by flows such as C to C in figure 4;
o T2
• multiple network domains may exist, including multiple transit domains, each of which may offer differing types
of capabilities.
ETSI

---------------------- Page: 13 ----------------------

SIST-TP TR 101 877 V1.1.1:2004
12 ETSI TR 101 877 V1.1.1 (2001-06)
6 Deriving service capabilities
6.1 Structuring service capabilities
TIPHON identifies core Service Capabilities through the analysis of elemental Service Applications as part of a
TIPHON Requirements Definition Study [1]. Service Applications, such as Simple Call that constitute the simplest
form of an application that implements the functionality of a particular type of service, are examined and candidate
Service Capabilities proposed. These Service Capabilities are then described in TIPHON Service Capability Definition
documents that contain information listed in this clause.
In order to permit inter-operation it is important that the core capabilities and communications support for Service
Capabilities remain unchanged when new Service Capabilities are derived from the core version.
A desirable feature of Service Capabilities is that they may be used without causing unwanted interactions between
Capabilities. Therefore the changes made to core capabilities should not interact with the changed core capability or
with other capabilities.
6.2 Service capability model
The TIPHON Service Capability Model identifies the following elements for a Service Capability Definition:
• scope;
• behaviour, including state transitions;
• Service Capability Identifier;
• failure modes.
A Service Capability Definition has to describe the above items at the points a
...