ETSI TS 101 315 V1.1.1 (2002-03)

SLOVENSKI STANDARD
01-april-2004
+DUPRQL]DFLMDWHOHNRPXQLNDFLMLQLQWHUQHWQHJDSURWRNRODSUHNRPUHåLM7,3+21
L]GDMD'HILQLFLMHIXQNFLMVNLKRVHENRYLQIRUPDFLMVNHJDWRNDLQUHIHUHQþQLKWRþN
6PHUQLFH]DDSOLNDFLMRIXQNFLMVNHDUKLWHNWXUH7,3+21]DPHGGRPHQVNHVWRULWYH
Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON)
Release 3; Functional entities, information flow and reference point definitions;
Guidelines for application of TIPHON functional architecture to inter-domain services
Ta slovenski standard je istoveten z: TS 101 315 Version 1.1.1
ICS:
33.020 Telekomunikacije na splošno Telecommunications in
general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

Technical Specification
Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON) Release 3;
Functional entities, information flow
and reference point definitions;
Guidelines for application of TIPHON functional
architecture to inter-domain services

2 ETSI TS 101 315 V1.1.1 (2002-03)

Reference
DTS/TIPHON-02007
Keywords
architecture, internet, IP, service
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

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://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, send your comment to:
editor@etsi.fr
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 2002.
All rights reserved.
ETSI
3 ETSI TS 101 315 V1.1.1 (2002-03)
Contents
Intellectual Property Rights.5
Foreword.5
Introduction .6
1 Scope.8
2 References.8
3 Abbreviations.9
4 Introduction.9
4.1 Structure of the present document.9
5 TIPHON meta-protocol.10
5.1 Introduction.10
5.2 Example: Information flows for a call set-up in TIPHON abstract architecture .14
6 Registration.15
6.1 General structure.15
6.2 User at home scenario .15
6.2.1 Simple form: Attachment only.16
6.2.2 User registration.17
6.2.2.1 Verification.17
6.2.2.2 Authentication.17
6.2.2.3 Service attach notification.17
6.2.2.4 Ticket generation.18
6.2.2.5 Response to terminal.18
6.2.2.6 Attachment with SpoA.18
6.2.3 Single sign-on service.18
6.2.4 De-registration.18
6.3 Roaming user scenario .18
6.3.1 Relationships for roaming case.19
6.3.2 Registration with RpoA .20
6.3.2.1 Example.20
6.3.3 Service attachment with (proxy) SpoA.20
6.3.4 De-registration.20
7 Simple call applications and services.21
7.1 Simple call.21
7.1.1 Initiating the call .21
7.1.2 Clearing the call.23
7.2 Simple call with ICF.23
7.3 Support for intra-domain QoS .24
7.4 CLIP/CLIR.25
7.5 Event recording.27
7.6 Lawful interception.27
7.7 IP and SCN interworking .28
7.8 VoIP interconnect.29
7.8.1 VoIP interconnect with an example of IP address translation .30
7.8.2 VoIP interconnect with an example of QoS.31
7.9 Roaming User scenario .32
7.10 Number portability.34
7.10.1 Number portability - All Call Query.34
7.10.2 Pivot routing.35
7.10.2.1 Call drop-back.35
7.10.2.2 Onward routing.36
7.10.3 Query on Release (QoR).37
7.11 Priority Calls.38
ETSI
4 ETSI TS 101 315 V1.1.1 (2002-03)
7.12 Emergency Calls.39
7.13 Carrier Selection.40
Annex A (informative): Bibliography.41
List of figures.42
History .43

ETSI
5 ETSI TS 101 315 V1.1.1 (2002-03)
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://webapp.etsi.org/IPR/home.asp).
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 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 Specification (TS) has been produced by ETSI Project Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON).
ETSI
6 ETSI TS 101 315 V1.1.1 (2002-03)
Introduction
Figure 1 shows the relationship of the present document with other TIPHON Release 3 deliverables.
TR 101 301
Release 3: Scope & Definition
TR 102 008
Definition of Terms
Transport Plane
Service Capabilities
TR 101 311 TS 101 878
Architecture & Reference
TS 101 314
configurations
Protocol
Implementer’s
TS 101 882 TS 101 315
Framework
guide
TS 101 883 TS 101 884 TS 101 885
H.323 profile SIP profile H.248 profile
TS 101 890 TS 102 027 TS 101 889 TS 101 804
SIP PICS H.248PICS
H.245
H.225
PICS, ATS, PIXIT
TS, ATS, PIXIT
Figure 1: Relationship with other TIPHON Release 3 documents
• TR 101 311 [8] provides the requirements on the transport plane,
• TS 101 878 [1] defines service capabilities that are used in the TIPHON Release 3 for a simple call,
• TS 101 882 [3] provides the protocol framework based on the TIPHON Release 3 architecture to implement the
simple call service capabilities as defined in the present document,
• TS 101 315 (the present document) is an implementer's guide that shows how to use of the meta-protocol to
realize the capabilities as defined in TS 101 878 [1].
• TS 101 883 [4] provides the protocol mappings for the ITU-T H-323 profile,
• TS 101 884 (see bibliography) provides the protocol mappings for the SIP profile,
ETSI
7 ETSI TS 101 315 V1.1.1 (2002-03)
• TS 101 885 [5] provides the protocol mappings for the ITU-T H-248 profile,
• TS 101 314 [2] provides the architecture and reference configurations for TIPHON Release 3.
ETSI
8 ETSI TS 101 315 V1.1.1 (2002-03)
1 Scope
The present document describes how the generic information flows as specified in the TIPHON baseline architecture
[2] and meta-protocol [3] will be used to specify certain inter-domain service capabilities, as required in TS 101 878 [1].
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies.
[1] ETSI TS 101 878: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; Service Capability Definition; Service Capabilities for a simple call".
[2] ETSI TS 101 314: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; abstract architecture and Reference Points Definition; Network Architecture
and Reference Points".
[3] ETSI TS 101 882: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; Protocol Framework Definition and Interface Requirement Definition;
General (meta-protocol)".
[4] ETSI TS 101 883: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; Technology Mapping; Implementation of TIPHON architecture using
H.323".
[5] ETSI TS 101 885: "Telecommunications and Internet protocol Harmonization Over Networks
(TIPHON) Release 3; Technology Mapping; Implementation of TIPHON architecture using
H.248".
[6] ETSI TR 101 301: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; Release Definition; TIPHON Release 3 Definition".
[7] ETSI TR 102 008: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; Terms and Definitions".
[8] ETSI TR 101 311: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; Service Independent requirements definition; Transport Plane".
[9] ETSI TS 101 520: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON); Implementation Conformance Statement (ICS) proforma for the support of packet
based multimedia communications systems; Support of ITU-T Recommendation H.323".
[10] ETSI TS 101 521: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON); Protocol Implementation Conformance Statement (PICS) proforma for the support of
call signalling protocols and media stream packetization for packet-based multimedia
communication systems; Support of ITU-T Recommendation H.225.0".
[11] ETSI TS 101 522: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON); Protocol Implementation Conformance Statement (PICS) proforma for the support of
control protocol for multimedia communication; Support of ITU-T Recommendation H.245".
[12] ETSI TS 101 804 (all parts): "Telecommunications and Internet Protocol Harmonization Over
Networks (TIPHON) Release 3; Technology compliance specifications".
ETSI
9 ETSI TS 101 315 V1.1.1 (2002-03)
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACQ All Call Query
APCS Authorized Priority Call Service
BC Bearer Control
BICC Beraer Independent Call Control
CC Call Control
CDR Call Data Records
CLIP Calling Line Identification Presentation
CLIR Calling Line Identification Restriction
CR Call Routing
FG Functional Group
ICF Isochronous Convergence Function
IMP Instant Messaging and Presence
IP Internet Protocol
ISDN Integrated Services Digital Network
ISUP ISDN User Part
MC Media Control
MSC Message Sequence Chart
NAT Network Address Translation
NNI Network-to-Network Interface
NWFG NetWork Functional Group
QoR Query on Release
QoS Quality of Service
QoSPE QoS Policy Element
RAS Registration Admission and Status
RPoA Registration Point of Attachment
RTP Real Time Protocol
SC Service Control
SDP Session Description Protocol
SIP Session Initiation Protocol
SLA Service Level Agreement
TPE Transport Policy Entity
TRM Transport Resource Manager
TU Transport Usage
UNI User-Network Interface
VoIP Voice over IP
4 Introduction
The present document is intended to provide the users of TIPHON specifications with guidelines on their usage for
specific scenarios.
4.1 Structure of the present document
Clause 5 gives an overview of the meta-protocol role as defined in the TIPHON process [3]. The remainder of the flows
in the present document are expressed in terms of this meta-protocol. Readers interested in the implementation of a
scenario described in the present document are encouraged to read the technology mpping documents dealing with each
individual technology mentioned in the present document. See TS 101 883 [4], TS 101 884 (see bibliography),
TS 101 885 [5] and DTS/TIPHON-03028R4 (see bibliography).
The TIPHON registration method is described in clause 6.
ETSI
10 ETSI TS 101 315 V1.1.1 (2002-03)
In clause 7 several call scenarios are described. The services being referred to in [1] are:
• Simple call setup,
• Simple call setup with ICF,
• Support for Intra-Domain QoS,
• Support for CLIR/CLIP,
• Billing,
• Lawful Interception,
• SCN Interworking,
• VoIP domains Interconnect supporting NAT,
• VoIP domains Interconnect supporting Inter-domain QoS,
• Roaming,
• Number Portability,
• Priority Calls,
• Emergency Calls,
• Carrier Selection.
5 TIPHON meta-protocol
5.1 Introduction
The telecommunications industry has a long tradition of creating specialist protocols for individual services. Often
several flavours of one protocol were used or several protocols existed to address the same problem. From an
interworking perspective these multiple protocols represent a significant challenge, because each of them assumes that
messages and code points are available to define the service. The consequence is that the service definition is different
on either side of an interworking point, often only in a subtle way. This means that interworking is a complex problem
involving a large number of compromises. More specifically, if there are n protocols to inter-work then there are
n x (n-1) interworking approximations that need to be developed.
TIPHON Release 3 introduces the use of a meta-protocol to manage the overall complexity to achieve multi-protocol
interworking. As shown in figure 2, the process of interworking is defined in terms of rules for encoding the code
points, mapping the messages and modifying states. As a consequence, the number of interworking approximations is
reduced to n rather than n x (n-1). A TIPHON service application is therefore defined in meta-protocol terms rather than
with any other protocol used at the point of interworking. A mechanism is then defined for interworking with each
desired, or candidate protocol. Hence a mapping to and from the meta-protocol (designed to support the services
needed) is defined for each concrete protocol to be used. This mapping must also take into account the behaviour of
underlying transport layers and protect against message loss. The derivation of these mappings is a complex task.
However, it is not always possible to apply the meta-protocol to generate a complete mapping to a given protocol. This
either results in writing new meta-protocol extensions or in deficiencies in the chosen concrete protocol.
ETSI
11 ETSI TS 101 315 V1.1.1 (2002-03)
SSeerrvviice ce
CaCappaabibililittiieess
AArrchchiittectuecturree
DaDattaa,,
SeSemmaannttiiccss
&&
BeBehahavviioouurr
MeMeta Pta Prrotocotocooll
EnEncoding ancoding and d
EnEnccoodidingng a anndd
MaMapping Rupping Rulleess
Mapping RMapping Ruulesles
PPrroottocol 1ocol 1 PPrroottocol 2ocol 2

Figure 2: Meta-protocol enabled interworking
More formally, the TIPHON meta-protocol is an application level functionality, which encompasses a whole host of
applications required for next generation telephony. It provides a super set of capabilities to support the telephony
application, in a protocol and transport technology independent way. The meta-protocol consists of call state machines,
which can perform the call processing. Different standard (and non standard) protocols can be mapped to this superset
functionality to provide interworking between them. It can be implemented in its entirety to develop communications
application servers, or it can be used as a tool to enhance existing protocols and to provide interworking between them.
The basis of the meta-protocol is the TIPHON abstract architecture, which defines functional layers, reference points
and interfaces between the functional layers. (See [2] for a full definition of this structure.) A functional layer performs
a specific set of tasks, e.g. the Call Control functional layer performs call processing; the Bearer Control functional
layer performs bearer setup/negotiation, etc. A set of these layers forms a functional group.
TIPHON architecture defines five layers of functionality, which are:
• Service layer,
• Service Control layer,
• Call Control layer,
• Bearer Control layer,
• Media Control layer.
ETSI
SCSCSCNNN PPPlanelanelane
12 ETSI TS 101 315 V1.1.1 (2002-03)
OOrriiggininaattiningg//
OrOrOrigiigiiginnnatiatiating/ng/ng/TTTeeerrrmmmiiinnnatiatiating Neng Neng Netwotwotworrrk Fk Fk FGGG TTeermrmininaattiningg//
InIntermtermedediateiate
TTeerrmmininatinatingg
OOrrigiginainatingting
NNeetwtworork FGk FG
TerTermmiinnaall F FGG
SeServirvinngg HomHomee
GaGatteewaway Fy FGG
NetNetwworork FGk FG NeNettwwororkk FG FG
UseUserr
SeServicrvicee
CRCR QoQoSSPPEE CRCR QQooSPESPE CRCR QQooSPESPE
QQooSPESPE pprrofileofile
ProfProfileile
S3S3 S4S4 S3S3 S4S4 S3S3 S4S4
S4S4
S1S1 S2S2
S1S1
SCSC2’2’ SSCC22’’ SCSC2’2’
SCSC SCSC
SCSC
SCSC
SCSC
R1R1 RR22
TREGTREG SRSREGEG HRHREEGG
SCSC22
SCSC11 SCSC22 SSCC22 SCSC22
C3C3
C1C1 C2C2 C2C2 C2C2
CCCC CCCC CCCC CCCC CCCC
C2C2
C1C1 C3C3
C2C2
C2C2
BCBC BCBC BCBC
BCBC
BCBC
N2N2
N1N1 NN22 N2N2 N3N3
M3M3
M1M1 MM22 M2M2 M2M2
MCMC MCMC MCMC MCMC MCMC
T2T2
T2T2
T1T1 T2T2 T1T1
TUTU TPTPEE TUTU TPETPE TUTU TPTPEE
I6I6 I4I4 I6I6 I4I4 I6I6 I4I4
I1I1
I1I1
I2I2 I2I2
TRTRMM TRMTRM TRTRMM TRMTRM TRTRTRMMM
I3I3 I3I3 I3I3 I3I3
I5I5 I5I5
I3I3
I3I3 I5I5
ICICFF TFTF ICICFF ICICFF TFTF ICICFF ICICFF TFTF ICICFF
TTeermrminainatingting//
OOrrigiginatinating/ing/
OrOriginiginatinatingg
CoCorree t trraannssppoorrt t
TTeermrmininaattiningg
InIngregressss//EEggreressss EgEgress/ress/InInggrress ess
GaGatteewawayy FG FG
dodommaaiinn
TerTermmiinnalal F FGG trtransanspportort d doommaainin ttrransanspporort dt doommaainin

Figure 3: TIPHON application architecture
Figure 3 shows an example of TIPHON architecture, FGs and reference points for the applications.
For the whole system to work, each functional layer carries out a set of tasks, and communicates information requests
and responses, to other functional layers. This flow of information takes place on reference points bothvertically and
horizontally.
This abstract architecture can be mapped to real "boxes", e.g. The CC and BC layers map to a NWFG (e.g. a
SoftSwitch, SIP B2BUA, H.323 gatekeeper); the Service layer could map to a Registration Server, or a Parlay Server.
The information flows between these functional layers take place at reference points in the form of real protocols, e.g.
the C reference point could be supported by H.323, SIP, BICC, ISUP etc; the N reference point could be supported by
the Megaco/H248 protocol.
But all the above standardized protocols behave differently, are technology dependent, and do not always allow a
seamless service interworking. Also, these protocols do not fulfil the requirements of all the reference points. The
meta-protocol was developed to encompass the behaviour and context of all the functional layers into one set of
functionality.
Some of the services provided by the meta-protocol are given below:
• Registration of subscribers,
• Authentication of users,
• Authorization of services,
• Provide services in home or visiting network (roaming),
• Call Control functionality,
• Call setup/teardown/call management,
ETSI
SSeerrvviiccee
MMeeddiiaa BBeeaarreerr Call
control
Transport
Transport Transport
flows Control Service
TTIIPPHON ApplHON Appliiccaattiion Pon Pllaannee
TTrranansporsportt P Pllaneane
Transport Tra Transport
nsport
flows Control Service Call
control
SSeerrvviiccee
ccoonnttrrooll
13 ETSI TS 101 315 V1.1.1 (2002-03)
• Bearer Control functionality (departure from the old monolithic CC functionality, as the bearer is no more tied
tightly to the Call Control):
- Bearer setup/teardown/management,
• Aggregate bearer:
- (old trunking facility in packet networks),
• Service control/access/provision:
- Access to switch based and non switch based services,
• Media control functionality, to manage different types of media, having different attributes,
• Provides all of above for multimedia sessions.
There are several parts of the meta-protocol, which refer to the TIPHON reference points they support, hence, the type
of services those reference points provide. The reference points supported by the meta-protocol are:
Table 1: Mapping of Reference points to target protocols
Reference Purpose Candidate protocols
point
R Registration
C Call Control SIP, H.323, BICC, ISUP
BC Bearer Control SDP, H.245, BICC-SDP
M Media RTP
N Media Control MEGACO/H.248
T Transport Control MEGACO/H.248 + EMP (TS 101 332)
S Services (access to)
SC Service Control INAP, Parlay, OSA, JAIN, SIP

There are sub parts of the above reference points, e.g. the C reference point consists of C1, C2 and C3. Each of these
subparts carry slightly different information since they operate between functional groups with a different role in call
processing, but provide the same type of service: Call Control signalling.
TTeermrmiinalnal//
BBaack-ck-endend
SSIIPP cl cliientent
SoSoffttSSwwiittcchh
serservverer
SESE SESE SESE
MMGG control control SiSigg--GGWW
HH.22225 (5 (RRASAS)) H.H.22225 (5 (RRAASS),), H.H.222255 ( (RRAASS),), ININAAPP
SCSC SCSC SCSC
SISIPP
SCSC SCSC
H.H.22225 A5 Annnn GG H.H.22225 A5 Annnn GG
OSOSPP
H.H.22225 (5 (QQ.993311)) HH.222255.0.0 ( (QQ.9.93311)) HH.22225.5.0 (0 (QQ.993311))
IISSUUPP/Q.9/Q.93311
CCCC CCCC CCCC
CCCC CCCC
SIPSIP SIP,SIP, B BIICCCC SISIP, BP, BIICCCC
QSQSIIGG
H.H.224455 H.H.242455 H.H.242455
BCBC BCBC BCBC
BCBC
SDSDPP SDSDPP SDSDPP
SSooftSftSwwiitctchh
H.H.24248/8/MMEEGGAACOCO
H.H.24248/8/MMEEGGAACOCO
RTRTPP
RTRTPP
MCMC
MCMC MCMC
MDMD
MGWMGW
GaGatteewwaayy
TTrraannsspportort p pllananee

Figure 4: Example implementation of TIPHON architecture
The reference points listed in table 1 can be used as guidance of what capabilities need to be supported in an open VoIP
system. Standard protocols, such as SIP, H.323, BICC, Megaco, can be mapped to these reference points for secure and
QoS enabled intra-domain and inter-domain communications. Figure 4 shows the placement of the standardized
protocols on TIPHON abstract architecture.
ETSI
ll SSeerrvviiccee
MMeeddiiaa BBeeaarreerr Ca
rrooll rrvviicceess
ccoonnttrrooll ccoonnttrrooll control ccoonntt SSee
Call
control
SCSCSCN PN PN Plllaaannneee
14 ETSI TS 101 315 V1.1.1 (2002-03)
The mapping to standard protocols allow the implementation of the TIPHON system according to the choice of
technology (protocols) of a vendor or service provider. Because TIPHON specifies the mapping of individual
technologies (protocols) to the meta-protocol, it means that interworking these protocols via the meta-protocol is an
automatic result.
The service capabilities supported by TIPHON meta-protocol can be used to develop standard or operator specific
services, allowing for "innovation for revenue generation". These standard service capabilities supported by TIPHON
R3 are based on the requirements study [1].
For example, a service provider deploying H.323 can Interconnect with a service provider deploying SIP, or BICC; or
even support customers on its network with devices using different protocols. If this service provider needs to
interconnect with a network that uses a different technology, an entity is needed that provides the service of this
provider over that technology. The TIPHON approach allows this service provider to express the service in a
technology independent way and purchase entities that provide this service over any applicable technology. Also if a
technology is implementing a service in a way that is compatible with the TIPHON mapping, protocol conversion is
made easier because the underlying state machines of both implementations can be linked to the state-machine of the
TIPHON meta-protocol.
5.2 Example: Information flows for a call set-up in TIPHON
abstract architecture
The Functional entities in the TIPHON can communicate with each other using the meta-protocol. The information
flows can be Horizontal and Vertical, as shown in figure 3. This clause shows an example of a Simple Call set-up
between two terminals, as well as the information flow that takes place between different Functional entities, such as
Call Control (CC) and Service Control (SC). This example concentrates on call flows only in the TIPHON Application.
TeTerrmmiinnaall--NetNetwwororkk TerTermmiinnalal--NNetetwwoorrkk
SSSSeeeerrrrvvvviiiicescescesces SerSerSerServvvviiiicescescesces
IInntteerrffaceace IInntteerrffaceace
33 – – SS33 V Vaalliiddatate Accee Accessss 444 44 – – SS33 V Vaalliiddatate Accese Accesss 1144 – – SS33 V Vaalliiddatate Accese Accesss 1155  –– SS33 Val Valiiddatate e AAccesccesss
333 141414
aand Rond Rouuttiinng Reg Requequestst aand Routnd Routiing Confng Confiirrmm aannd Rod Rouuttiinng g ReReqquueesstt aand Rond Rouuttiinng Confg Confiirrmm
SeSeSeSerrrrvvvviciciciceeee SerSerSerServvvviiiicccceeee
ConConConConttttrrrroooollll CoCoCoContntntntrrrroooollll
13 –13 – SSC2C2 AAcccceess ass and nd 1166 – – SSCC22 AccesAccesss an andd
22 – – SSCC22 AccesAccesss an andd 55 – – SSCC22 AccesAccesss an andd
RoutRoutiinng Reg Reququeesstt 151515 RoRouuttiinng Confg Confiirrmm
RoutRoutiinng Reg Reqquueesstt RoutRoutiinng Confg Confiirrmm
222 555
1 –1 – CC1 Ca1 Callll & C1Be & C1Beaarreerr Re Requequestst 1122  –– CC2 Ca2 Call ll & C2Be& C2Beaarreerr  Re Requequestst 2323 – – CC1 1 CaCall & ll & C1BeC1Beaarreerr  ReRequequesstt
111 121212
CaCaCaCallllllll CaCaCaCallllllll
383838 ConConConConttttrrrroooollll 3131 – – CC2 2 CaCallll & & C2BeC2Beaarreerr Conf Confiirrmm CoCoCoContntntntrrrroooollll 242424
38 –38 – CC1 Ca1 Callll & C1Be & C1Beaarreerr Conf Confiirrmm 2424 – – CC11 Ca Call &ll & C1Be C1Beaarreerr Conf Confirirmm
666 323232 252525
3322 – – MMooddiiffyy B Bearer Rearer Reeqquuesestt
66 - - BBearearer Rer Reeqquueesstt 17 -17 - BBeeaarreerr Re Requequestst
2255 – – MMooddiiffyy B Bearer Rearer Reeqquuesestt
111111 303030
22 -22 - BBeeaarreerr Conf Confiirrmm
222222 3300 – – MModiodiffyy Be Beaarreerr Conf Confiirrmm
1111 - - BBearerearer CCoonnffiirrmm
3377 – – MModiodiffyy B Beeaarreerr Conf Confiirrmm
BeBeBeBeaaaarrrreeeerrrr BBBBeareareareareeeerrrr
ConConConConttttrrrroooollll CoCoCoContntntntrrrroooollll
7 –7 – NN2 Me2 Medidiaa Re Reseserrvvaattiioonn ReReqquueesstt 1818–– NN22 M Meedidiaa RReesseervarvattiioonn
777 333333 181818 262626
3333  –– NN22 M Meeddiiaa E Essttaablbliissh h RReeqquueesstt 2266 –– NN22 M Meeddiiaa E Essttaablbliissh h RReeququeesstt
ReReqquueesstt
1010 – – NN2 2 MMeeddiiaa Re Reseserrvvaattiion on ConConffiirrmm 101010 363636 212121 292929 2299 – – NN22 MMeeddiiaa E Esstatabblishlish CoConnffiirrmm
21 –21 – NN2 Me2 Medidiaa Re Reseserrvvaattiioonn
36 –36 – NN2 Me2 Medidiaa Es Esttaabblliisshh ConfConfiirrmm
ConfConfiirrmm
MeMeMeMeddddiiiiaaaa MeMeMeMeddddiiiiaaaa
ConConConConttttrrrroooollll CoCoCoContntntntrrrroooollll
8 –8 – TT2 2 TTrraannsportsport Re Reseserrvvaattiioonn rreequequestst 1199 – – TT22 TTrraannspspoorrt Rt Reesseerrvvaatiotionn
343434 272727
3344 – – TT2 2 TTrraannssportport Est Estaabblliisshh ReReququeesstt 2727 – – TT22 T Trraannsporsportt E Essttaablbliissh h ReRequequestst
rreequequestst
9 –9 – TT2 2 TTrraannsportsport r reeseservarvattiion Con Coonnffiirrmm
999 353535 202020 2288 – – TT22 TTrraannspspoorrt Et Esstatabblishlish Co Connffirirmm
20 –20 – TT22 TTrraannsporsportt r reeseserrvvaattiioonn
3535 – – TT22 T Trraannsporsportt E Essttaablbliissh h ConfConfiirrmm
CoConnffirirmm
IPIPIPIP IPIPIPIP
Figure 5: Call set-up using meta-protocol
Figure 5 shows the sequence of events that takes place in a simple call set-up. The message prefixes, e.g. C1, T1, refer
to the information flows that take place on the corresponding reference points: C1 reference point, and T1 reference
point.
It is envisaged that it can be difficult for the reader to follow the events taking place in the functional entities, and
subsequent information flows vertically and horizontally in the TIPHON application plane. Therefore, the call flows in
the rest of the present document utilize the Message Sequence Charts (MSC), to show how the meta-protocol supports
the services as defined in TS 101 878 [1].
ETSI
15 ETSI TS 101 315 V1.1.1 (2002-03)
6 Registration
In the TIPHON service-model, a user has a contract with one (or more) service providers. Prior to using the service, the
user shall attach to the service node that provides the service. The service node that shall be used for a particular
invocation of the service may be known a-priori or may be selected dynamically, based on the context like user
location, user permissions and preferences and load-sharing.
6.1 General structure
The registration service allows a user (registrant) to register with a registrar. The registration service includes the
authentication and authorization of a subscriber (user/registrant) to access a service. It is a pre-requisite: a successful
registration would normally lead to access services which the user is entitled to use; whereas, an unsuccessful
registration would normally lead to refusal of service. The latter may however not apply in certain cases, e.g. accessing
emergency services.
In figure 6 an overview is given of the basic registration mechanism.
User registration
Registrant Registrar
(registration server)
(user at terminal) RPoA
Service preparation
ervice attachment
Service node
SPoA
(Softswtich )
Service node
(instant messaging
SPoA
server)
Figure 6: General structure of the TIPHON registration mechanism
1) User registration: The user registers for the service and shows entitlement for the service used.
2) Service preparation: The registrar selects a service node at which the user shall use the service and informs the
service node that the user is entitled to use the service.
3) Service attachment: The user (terminal) attaches to the service node and the service can be delivered.
TIPHON has developed a registration meta-protocol which defines the context, procedures and behaviour of the
Registration service. This registration meta-protocol can be mapped to standard protocols such as SIP, or RAS (H.323).
The TIPHON architecture identifies two reference points for registration: R1 and R2. R1 supports UNI and R2 supports
NNI.
Two registration scenarios shall be supported:
• the "User at home" scenario; and
• the "Roaming user" scenario.
6.2 User at home scenario
The NORMAL "User at home scenario" registration process involves the following steps:
• registrar discovery;
• registration with registrar;
• registration with application server.
The complete procedure is not necessary for all deployments. We start with the simplest scenario and add functionality
upon that.
ETSI
16 ETSI TS 101 315 V1.1.1 (2002-03)
Before any kind of registration takes place, a user/terminal needs to know who the registrar is, who to register with. In
the simple case the signalling handle on the registrar (the RpoA) can be provisioned in the terminal.
However TIPHON allows for a dynamic discovery mechanism. The details of this mechanism are outside the scope of
TIPHON Release 3.
6.2.1 Simple form: Attachment only
In its simples form the user at home scenario can default to simply the service attachment. The user may have been
provided with a username and password and/or a suitable cryptographic key that will prove the user's right to access the
service. Also in the simplest form, there is just one service node or the user terminal can select one on its own.
Registrant SpoA
The Registration Address is
known,
Service Attach Request
Authentication Information is
available
Service Attach Response
Registration Complete.
Use of Requested Services
Figure 7: Service attachment
In figure 7, a simple service attachment is shown. The user provides credentials that give it entry to the service (may be
null for an anonymous service) and may provide details of the service desired (may be null if there is only one service
provided at that node). This information is sent to the address of the service node (SpoA, Service point of Attachment).
The service node stores the relevant data, acknowledges to the user.
When the user is no longer interested in the service, the user (terminal) may detach from the service as is shown in
figure 8.
Registrant SpoA
De-Registration
Service Detach Request
Service Detach Response
Figure 8: De-attachment
After this detachment, the user must re-attach if further service is required.
ETSI
17 ETSI TS 101 315 V1.1.1 (2002-03)
6.2.2 User registration
Requiring that users register prior to service attachment is a more flexible and secure method.
Once the identity of the registrar and its signalling handle RpoA is known, the next step is to register with it using a
registration protocol. It is, however, important at this stage to clarify the difference/commonality between the RpoA and
registration server. RpoA is the access interface to a registrar. It may or may not be co-located with the registration
functional grouping. There may be a case when an RpoA serves as a Registrar location server, receives registration
requests, and provide the address of a relevant registration server. For simplicity, we consider a case where RpoA is the
registrar (co-located with the registration functional grouping).

Registrant RpoA SpoA
Registrant attempts to
Register with the RpoA
U_Registration Request
Authentication/Authorization
takes place
The RpoA Informs the relevant
SpoA o f the registration, and
requests the SpoA to provide the

required service
The RpoA provides the
D_ SpoA Client Attach Notify
Address( es ) of the SpoA ,
The SpoA A grees to
along with Auth Tokens
provide the requested
U_ SpoA Client Notify Response
Service. SpoA pr ovides the
D_Registration Confirm
Authorization Token for the
session
Figure 9: Simple user registration
The user registration scenario is shown in figure 9.
It is a four step process in which the terminal (user) initiates Registration by sending a "Registration Request" message
to the RpoA. Using the Registration Request message to the RpoA (Registration point of Attachment), the user is
identified to the registrar. This message may also carry the request for services the user wants to use. If no services are
mentioned, the registrar assumes that all services the user is entitled to are requested.
Upon receipt of this message, the following procedure takes place at RpoA.
6.2.2.1 Verification
The user is verified as a subscriber based on the Public identity he provided in the Registration Request. This
verification could involve communications between the RpoA and a database. The communication with the database is
outside the scope of TIPHON Release 3.
6.2.2.2 Authentication
Authentication takes place to check that the user is what he claims to be (via Public id). The RpoA checks for the
authentication information in the Registration Request message. If the authentication information (combination of
private id and password) is not available, the registration request is declined. The user then sends another registration
request with appropriate authentication information (in a secure manner - to be discussed later).
6.2.2.3 Service attach notification
After success authentication, the RpoA checks the services requested by the Registrant. This could involve matching the
requested services with a local (to registrar) service profile. This step is outside the scope of the present document.
The registrar selects a service node(s) that shall host the service for the user and notifies this node that it shall serve as
this role. The RpoA searches for the possible application servers (telephony, IMP, etc) that can provide the services
requested by the registrant. Once found, the
...