ETSI TS 101 882 V1.1.1 (2002-05)

Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 3; Protocol Framework Definition; General (meta-protocol)

DTS/TIPHON-03016

Harmonizacija telekomunikacij in internetnega protokola prek omrežij (TIPHON), 3. izdaja - Definicija ogrodja protokola - Splošno (meta-protokol)

General Information

• Status: Published
• Publication Date: 16-May-2002
• Technical Committee: TIPHON 3 - TIPHON Call control matters
• Current Stage: 12 - Completion
• Due Date: 05-Mar-2002
• Completion Date: 17-May-2002
• Ref Project: SIST-TS TS 101 882 V1.1.1:2004 - Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 3; Protocol Framework Definition; General (meta-protocol)

Standards Content (Sample)

SLOVENSKI STANDARD
01-april-2004
Harmonizacija telekomunikacij in internetnega protokola prek omrežij (TIPHON), 3.
izdaja - Definicija ogrodja protokola - Splošno (meta-protokol)
Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON)
Release 3; Protocol Framework Definition; General (meta-protocol)
Ta slovenski standard je istoveten z: TS 101 882 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;
Protocol Framework Definition;
General (meta-protocol)
2 ETSI TS 101 882 V1.1.1 (2002-05)
Reference
DTS/TIPHON-03016
Keywords
interface, IP, protocol, VoIP
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 networkdrive
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:
[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 2002.
All rights reserved.
TM TM TM
DECT , PLUGTESTS and UMTS are Trade Marks of ETSI registered for the benefit of its Members.
TM
TIPHON and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
3 ETSI TS 101 882 V1.1.1 (2002-05)
Contents
Intellectual Property Rights.6
Foreword.6
Introduction .6
1 Scope .8
2 References .8
3 Definitions and abbreviations.9
3.1 Definitions.9
3.2 Abbreviations .9
4 Introduction .10
Annex A (normative): Meta-protocol at reference point R.11
A.1 Overview .11
A.1.1 Reachable indication .12
A.1.2 Registration service definition.12
A.1.3 Ticket content and processing .13
A.1.3.1 Authentication.14
A.2 Registration for service applications .14
A.3 Registrar discovery.15
A.4 Constituent functional elements .15
A.4.1 Registrant .15
A.4.2 Registrar .15
A.4.3 SpoA.16
A.5 Information flows.16
A.5.1 U_RegistrationRequest.17
A.5.2 D_RegistrationConfirm.17
A.5.3 D_RegistrationReject .17
A.5.4 D_RegistrationPending .18
A.5.5 U_DeRegistrationRequest .18
A.5.6 D_DeRegistrationResponse.19
A.5.7 U_SpoAServiceAttachRequest.19
A.5.8 D_SpoAServiceAttachResponse .19
A.5.9 D_SpoAServiceAttachReject .20
A.5.10 U_SpoAServiceDetachRequest.20
A.5.11 D_SpoAServiceDetachResponse .20
A.5.12 D_SpoAClientAttachNotify .21
A.5.13 U_SpoAClientNotifyResponse.21
A.5.14 D_SpoAClientDetachNotify.21
A.5.15 U_SpoAClientDetachResponse.22
A.6 Behavioural description.22
A.6.1 Registration .22
A.6.1.1 Registrant.22
A.6.1.2 Registrar.25
A.6.1.3 SpoA .26
A.6.2 Deregistration .27
A.6.2.1 Registrant.27
A.6.2.2 Registrar.27
A.6.2.3 SpoA .27
A.7 Timers.29
A.7.1 TR001, Registration timer.29
ETSI
4 ETSI TS 101 882 V1.1.1 (2002-05)
A.7.2 TR002, Deregistration timer.29
A.8 Data definitions (ASN.1).30
Annex B (normative): Meta-protocol at reference point C.33
B.1 Overview .33
B.2 Constituent functional elements .36
B.3 Information flows.36
B.3.1 U_CallRequest .37
B.3.2 D_CallReject .38
B.3.3 D_CallReport .38
B.3.4 D_CallConnect .39
B.3.5 U_CCAdditionalDigits.39
B.3.6 D_CallRequest .39
B.3.7 U_CallAlert .40
B.3.8 U_CallConnect .40
B.3.9 Void.40
B.3.10 NW_CallRequest.40
B.3.11 NW_CallReport.41
B.3.12 NW_CallConnect .41
B.3.13 U_BearerRequest.41
B.3.14 D_BearerConnect .42
B.3.15 NW_BearerRequest.43
B.3.16 NW_BearerConnect .43
B.3.17 NW_CallReject .43
B.4 Behaviour .44
B.4.1 Call setup.44
B.4.1.1 Outgoing call (terminal originated, terminal behaviour) .44
B.4.1.2 Incoming call (Terminal Terminated, terminal behaviour).47
B.4.1.3 Network behaviour .50
B.4.2 Call Cleardown.52
B.4.2.1 Terminal behaviour.52
B.5 Timers.54
B.5.1 TC001, originating call control, call setup timer.54
B.5.2 TC002, terminating call control, call setup timer .54
B.6 Data definitions (ASN.1).54
Annex C (normative): Meta-protocol at reference point N.59
C.1 Media control service .59
C.1.1 Behaviour in IDLE state.63
C.1.2 Behaviour in ResPending state.63
C.1.3 Behaviour in MediaReserved state.63
C.1.4 Behaviour in RelPending state .63
C.1.5 Behaviour in M_ACTIVE state.63
C.2 Data definitions (ASN.1).63
Annex D (normative): Meta-protocol at reference point T .66
D.0 Introduction .66
D.1 Transport control state machine .68
D.1.1 Behaviour in IDLE state.69
D.1.2 Behaviour in TransportReserved State.69
D.1.3 Behaviour in TransportActive State .69
D.2 Data definitions (ASN.1).73
Annex E (normative): Implementation Conformance Statement Proforma Cover.74
ETSI
5 ETSI TS 101 882 V1.1.1 (2002-05)
E.1 Guidance for completing the PICS proforma.74
E.1.1 Purposes and structure.74
E.1.2 Abbreviations and conventions .74
E.1.3 Instructions for completing the PICS proforma.76
E.2 Identification of the implementation .76
E.2.1 Date of the statement.76
E.2.2 Implementation Under Test (IUT) identification .76
E.2.3 System Under Test (SUT) identification.76
E.2.4 Product supplier.77
E.2.5 Client (if different from product supplier).77
E.2.6 PICS contact person .78
Annex F (informative): Bibliography.79
History .80
ETSI
6 ETSI TS 101 882 V1.1.1 (2002-05)
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 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 Specification (TS) has been produced by ETSI Project Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON).
Introduction
The present document is a product in TIPHON release 3 (see TR 101 301 [6]) of step D of the TIPHON development
process described in TR 101 835 [7].
The approach being taken to standardization in TIPHON represents a departure from that used in the past for PSTN,
ISDN and GSM. Its aim is to allow much greater scope for competition through innovation in the design of equipment
and services. Its aim is also to provide adequate standardization to facilitate the operation of services across
interconnected networks, even networks that use different technologies. The present document presents the initial core
set of service capabilities envisaged to be required to enable service providers to offer services on TIPHON networks
that may safely inter-work with existing PSTN services while enabling more advanced services to be subsequently
developed.
ETSI
7 ETSI TS 101 882 V1.1.1 (2002-05)
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 520 TS 101 521 TS 101 522 TS 101 804
H.323 PICS SIP PICS H.248PICS TS, ATS, PIXIT
Figure 1: Relationship with other TIPHON Release 3 documents
• TR 101 311 [9] provides the requirements on the transport plane;
• TS 101 878 [3] defines service capabilities that are used in the TIPHON Release 3 for a simple call;
• TS 101 882 (the present document) 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 [5] is an implementer's guide that shows how to use of the meta-protocol to realize the capabilities as
defined in TS 101 878 [3];
• TS 101 883 [10] provides the protocol mappings for the ITU-T H-323 profile;
• TS 101 884 provides the protocol mappings for the SIP profile;
• TS 101 885 [11] provides the protocol mappings for the ITU-T H-248 profile;
• TS 101 314 [1] provides the architecture and reference configurations for TIPHON Release 3.
ETSI
8 ETSI TS 101 882 V1.1.1 (2002-05)
1 Scope
The present document defines protocol frameworks for reference points defined in the TIPHON architecture
TS 101 314 [1] that are required to implement the capabilities described in TS 101 878 [3] such that implementations
compliant to the framework using candidate protocols interoperate.
The protocol framework takes the form of a set of meta-protocols described both in syntax (using Abstract Syntax
Notation 1 (ASN.1 (see bibliography)) and in behaviour (using Message Sequence Charts (MSCs
(see ITU-T Recommendation Z.120 in bibliography) and simple Specification and Description Language (SDL
(see ITU-T Recommendation Z.100 in bibliography)) diagrams in addition to text). The meta-protocols show both the
service primitives used by higher or lower layers to invoke, control and report on the progress of the meta-protocol, and
the Meta Protocol Data Units (M-PDUs) used to communicate with peer entities.
Meta-protocols are described in this edition of the present document for the following reference points defined in
TS 101 314 [1]: R; C; N and T.
The present document is applicable to the protocols that are necessary to support TIPHON Release 3.
Where the text indicates the status of a requirement (i.e. as strict command or prohibition, as authorizations leaving
freedom or as a capability or possibility), this may modify the nature of a requirement within a candidate protocol used
to provide the capability.
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 314: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; Abstract Architecture and Reference Points Definition; Network
Architecture and Reference Points".
[2] ETSI TR 101 877: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON); Requirements Definition Study; Scope and Requirements for a Simple call".
[3] ETSI TS 101 878: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; Service Capability Definition; Service Capabilities for a simple call".
[4] ISO/IEC 9646-7: "Information technology - Open Systems Interconnection - Conformance testing
methodology and framework - Part 7: Implementation Conformance Statements".
[5] ETSI TS 101 315: "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".
[6] ETSI TR 101 301: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; Release Definition; TIPHON Release 3 Definition".
[7] ETSI TR 101 835: "Telecommunications and Internet Protocol Harmonization over Networks
(TIPHON); Project method definition".
[8] ETSI TR 102 008: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; Terms and Definitions".
[9] ETSI TR 101 311: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; Service Independent requirements definition; Transport Plane".
ETSI
9 ETSI TS 101 882 V1.1.1 (2002-05)
[10] ETSI TS 101 883: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; Technology Mapping; Implementation of TIPHON architecture using
H.323".
[11] ETSI TS 101 885: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; Technology Mapping; Technology Mapping of TIPHON reference point N
to H.248/MEGACO protocol".
[12] ETSI TS 101 520: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON); Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON);
Support of ITU-T Recommendation H.323".
[13] 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".
[14] 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".
[15] ETSI TS 101 804: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; Technology compliance specifications".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TR 101 877 [2] and TS 101 878 [3] apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations defined in TR 101 877 [2], TS 101 878 [3] and the
following apply:
API Application Programming Interface
ASN.1 Abstract Syntax Notation One
BC Bearer Control
CC Call Control
CCUA Call Control User Agent
FE Functional Entity
FG Functional Grouping
GoS Grade of Service
IP Internet Protocol
IPTN IP Telephony Network
ISDN Integrated Services Digital Network
MC Media Control
M-PDU Meta Protocol Data Unit
MSC Message Sequence Chart
PCM Pulse Code Modulation
PDU Protocol Data Unit
PSTN Public Switched Telephone Network
QoS Quality of Service
SAP Service Access Point
SC Service Control
SCN Switched Circuit Networks
SDL Specification and Description Language
SL Service Layer
SNCC Serving Network Call Control
ETSI
10 ETSI TS 101 882 V1.1.1 (2002-05)
TCC-SAP TIPHON Call Control SAP
TLL-SAP TIPHON Lower Layer SAP
TNCC Transit Network Call Control
TRL TIPHON Resource Location
TR-SAP TIPHON Registration SAP
TT-SAP TIPHON Transport SAP
URI Uniform Resource Identifier
4 Introduction
The annexes in the present document contain normative descriptions of the meta-protocols that apply to the reference
points defined in TS 101 314 [1]. Each annex is complete and the interactions between the meta-protocols are further
described in TS 101 315 [5].
ETSI
11 ETSI TS 101 882 V1.1.1 (2002-05)
Annex A (normative):
Meta-protocol at reference point R
TIPHON networks shall offer a Registration point of Attachment (RpoA). If the RpoA is not offered then the network
cannot be considered as TIPHON enabled.
EXAMPLE: If a TIPHON network is IP based with configuration of terminals (hosts) offered by DHCP then
the DHCP procedure will give the terminal its IP address parameters, DNS parameters, and the
Registration point of Attachment (RpoA) as well as "anonymous" services that the user of that
transport domain can invoke without prior authorization (e.g. emergency services and information
services).
A.1 Overview
The registration meta-protocol operations enable a user (the registrant) to seek and gain authority to invoke service in
some domain for which ingress/egress is strictly controlled. The service applications to be offered shall be determined,
in part, by data held in the user profile.
Figure 2 shows the relationship of the core elements in registration.
User registration
Registrant Registrar
Service preparation
Service attachment
SpoA
Figure 2: Relationship of registration entities
The registration service shall enable a user to receive service in both home and visited domains. The registrar to which a
registrant registers shall maintain a profile of service applications for the registrant. The registrar may authorize access
to service applications in the domain in which the registrant is situated or in some other domain in which the entity
controlling the service application is located.
Registration may be an implicit service offered at subscription to terminals, in such cases the meta-protocol described in
this clause shall not apply.
NOTE: This can be compared with attachment of a telephone set to a PSTN switch or PABX.
The registration meta-protocol is in two stages:
• the registrant registers with the registrar and if successful gains access to the profile of service applications; and
• if successful, the registrar shall supply the credentials for each service application in the form of a ticket to be
used by the registrant when requesting service from an application server.
Each service application available to the registrant may be offered by different service providers. These service
providers may be in different domains and offer different SpoAs for each of them. The ticket shall indicate that the
registrant is authorized to use the service application via the appropriate SpoAs. The ticket shall also identify that
registration is valid for a fixed period.
When first performed within a session the registration mode shall be identified by setting the RegistrationMode element
(see clause A.5) to "InitialRegistration". Periodic re-registration may occur at any time and shall follow the protocol
described in this clause by setting the RegistrationMode element (see clause A.5) to "LocationUpdate".
ETSI
12 ETSI TS 101 882 V1.1.1 (2002-05)
The terminal has to be registered and authorized before being able to make or receive service, however this "Register
before service invocation" may be overridden for certain call types (e.g. emergency calls).
Each registrant has a unique registration identity that shall permit the domain of the home registrar to be identified.
A.1.1 Reachable indication
By successful completion of the registration service the registrant (user) indicates to the registrar (home) that the
registrant is reachable and attached.
If the registrant no longer wishes to be reachable for any registered service application in the user profile the registrant
shall explicitly detach from that service application by communicating with the SpoA.
If the registrar decides that the user should no longer be reachable for a service application or set of service applications,
e.g. if a pre-paid account has been depleted, the registrar shall explicitly initiate the de-registration protocol in order to
inform the registrant.
A.1.2 Registration service definition
The registration service shall be offered across a network or set of networks (parts of which may be under different
administrative control). The registration service shall be invoked by the use of primitives visible at the TIPHON
Registration Service Access Point (TR-SAP) and shown in table 1.
Table 1: Registration primitives visible at TR-SAP
Primitive Short description Capability (see note)
TR_RegistrationRequest_req Allows the user plane to initiate a registration.
TR_RegistrationRequest_conf Gives the result of a user initiated registration to the
user plane.
TR_DeRegistrationRequest_req Allows the user plane to initiate a de-registration.
TR_DeRegistrationRequest_conf Gives the result of a user initiated de-registration to
the user plane.
TR_RegistrationStatus_ind Informs the user plane of any notification from the
registrar.
NOTE: The capability cross references to the capability definition in TS 101 878 [3].
Table 2: Parameters in registration primitives
Primitive Parameters
Request Confirm Indication
TR_RegistrationRequest UserID, RegistrationResult -
[TerminalID]
[List of ServiceApplications]
TR_DeRegistrationRequest UserID, DeRegistrationResult -
[ List of ServiceApplications]
TR_RegistrationStatus - - TBD
The parameters in the registration primitives shall take the following values:
RegistrationResult =
Success {list of ServiceApplications};
FailureReason {list of ServiceApplications};
No response from Registrar;
Protocol timer expired;
…
ETSI
13 ETSI TS 101 882 V1.1.1 (2002-05)
DeRegistrationResult =
Success;
No Active Registrations;
…
ServiceApplication =
Service#1;
Service#2;
…
TR_RegistrationRequest_conf
TR_DeRegistrationRequest_conf
TR_RegistrationStatus_ind
TR-SAP
TR_RegistrationRequest_req
TR_DeRegistrationRequest_req
Registration Service
Figure 3: Services offered by the registration service identified by primitives
A.1.3 Ticket content and processing
A service authorization ticket shall:
• identify the user (as registrant);
• identify the registrar (as the issuer of the ticket);
• identify the service application(s);
• identify the service provider for each of the service application(s);
• show the time period during which service application(s) is (are) to be provided to the user; and
• optionally provide a means to cryptographically authenticate the user to the service provider(s).
The user identity in the ticket shall be the identity required by the service application. A single user may have many
different identities depending upon the service application(s) chosen. If a user has more than one identity a ticket shall
be provided for each identity and this shall contain the list of service applications for the identity.
ETSI
14 ETSI TS 101 882 V1.1.1 (2002-05)
The ticket shall be defined in ASN.1 as follows:
TicketType ::= SEQUENCE
{
registrantId VisibleString,
registrarId VisibleString,
serviceCredential SET OF ServiceCredentialType,
cryptoDigest DigestType OPTIONAL
}
ServiceCredentialType ::= SEQUENCE
{
serviceAppId ServiceApplicationType,
spoA SpoAType, -- shall be in the user's terminal addressing realm
startTime GeneralizedTime,
stopTime GeneralizedTime, -- Shall be greater than StartTime
cryptoDigest DigestType OPTIONAL
}
A.1.3.1 Authentication
The registration service may include a strong authentication embedded (or implicit) service. When authentication is
offered the registration request shall contain the registrant's credentials in the form of an authentication token.
The following entities should be authenticated:
• terminals with dynamically provisioned parameters;
• functional elements within the network with dynamically provisioned parameters;
• terminals with variable point of transport attachment;
• terminals with variable point of service attachment;
• functional elements within the network with variable point of transport attachment; and
• functional elements within the network with variable point of service attachment.
If strong authentication is not used the resulting authorization, even if successful, shall be deemed to be not
authenticated. The service applications to be offered shall be determined, in part, by data in the user profile. On
successful authentication the result given to the user shall indicate how to reach these service applications securely
(i.e. such that the application server knows that the request comes from an authenticated source).
A.2 Registration for service applications
Successful registration shall allow the registrant access to service applications. A local copy of the service application
entitlement (user service profile) may be maintained at the registrant terminal. The capabilities of the terminal to
support each of the service applications in the service entitlement shall be maintained locally to the terminal. On single
function terminals the service profile may be treated as implicit.
When requesting registration the registrant shall indicate those service applications from the service entitlement that the
registrant wishes to receive and that the registrant's terminal is able to support.
ETSI
15 ETSI TS 101 882 V1.1.1 (2002-05)
A.3 Registrar discovery
The identity and address of the registrar may be provided to the user (or user's terminal) at the time of provisioning, or
by using a configuration protocol (e.g. DHCP), by the registrar and maintained within the service profile as a populated
registration identity element.
The registration identity shall be of the following form:
RegIdType ::= SEQUENCE
{
registrarId VisibleString,
registrarLoc TRL,
registrantId VisibleString
}
Where the TRL element type shall indicate a TIPHON Resource Location and be of the type below:
TRL ::= SEQUENCE
{
protocolID VisibleString,
nameorAddress VisibleString,
port INTEGER OPTIONAL
}
A.4 Constituent functional elements
Service applications shall always be executed in the home environment. The home environment may be real or virtual.
Table 3: Registration functional elements
Identity Name
FE1 Registrant
FE2 Registrar (see note 1) pointed to by RpoA
(see note 2)
FE3 Application Server pointed to by Service point of Attachment (SpoA)
(see note 2)
NOTE 1: Contains a register of currently registered terminals (keyed to Registration identity (regID)).
NOTE 2: FE2 and FE3 may be implemented as distributed entities.
A.4.1 Registrant
The registrant is the logical entity being registered and may take the form of a terminal (e.g. telephone transceiver) or be
more directly related to the user (e.g. a human offering credentials).
When requesting registration the registrant shall provide to the registrar a list of service applications for which it is to be
registered.
A.4.2 Registrar
The registrar shall maintain the user profile of the registrant.
The registrar shall also maintain a record of SpoAs for each RpoA in order to optimize the binding to local application
servers for each registration. The registrar shall validate a registration request against the user profile and identify a
service provider local to the registrant's RpoA. If a SpoA is identified locally to the RpoA this SpoA shall act as a home
service environment. If no SpoA can be identified locally to the RpoA the SpoA shall be offered from an appropriate
but more distant server.
Having identified an appropriate service registrar the registrar shall contact it to request authorization for the registrant.
The resulting authorization shall be sent to the registrant in the form of a ticket and shall identify the SpoA.
ETSI
16 ETSI TS 101 882 V1.1.1 (2002-05)
A.4.3 SpoA
In the context of registration the SpoA shall maintain the attachment of users to service.
A.5 Information flows
The information flows described in table 4 and in the succeeding clauses comprise the registration service M-PDUs.
The formal ASN.1 declaration of these M-PDUs is given in clause A.8.
Table 4: Registration M-PDUs
M-PDU name (see notes 1, 2) Direction Elements M/O/C
U_RegistrationRequest FE1 to FE2 RegId M
RegistrationMode M
RpoA M
ServiceApplicationId M
AuthenticationToken O
D_RegistrationResponse FE2 to FE1 RegId M
ServiceCredentials M
D_RegistrationReject FE2 to FE1 RegId M
ServiceRejectReason M
D_RegistrationPending FE2 to FE1 RegId M
U_DeRegistrationRequest FE1 to FE2 RegId M
D_DeRegistrationResponse FE2 to FE1 RegId M
RegistrationRemovedFlag M
U_SpoAServiceAttachRequest FE1 to FE3 RegId M
ServiceRequestTicket M
D_SpoAServiceAttachResponse FE3 to FE1 RegId M
ServiceOfferTicket M
D_SpoAServiceAttachReject FE3 to FE1 RegId M
ServiceRejectReason M
U_SpoAServiceDetachRequest FE1 to FE3 RegId M
ServiceOfferTicket M
D_SpoAServiceDetachResponse FE3 to FE1 RegId M
ServiceDetachedFlag M
D_SpoAClientAttachNotify FE2 to FE3 RegistrarID M
RegistantID M
ServiceAppId M
RegistrantAuthTicket M
U_SpoAClientNotifyResponse FE3 to FE2 RegistrarID M
ClientAcceptedFlag M
SpoAAuthTicket C
D_SpoAClientDetachNotify FE2 to FE3 RegistrarID M
RegistantID M
ServiceAppId M
RegistrantAuthTicket M
U_SpoAClientDetachConfirm FE3 to FE2 RegistrarID M
ClientDetachedFlag M
NOTE 1: M-PDUs prefixed by "U_" indicate M-PDUs generated by a terminal and have direction only towards the
network (i.e. Up to the network).
NOTE 2: M-PDUs prefixed by "D_" indicate M-PDUs generated by the network in the direction only of the terminal
(i.e. Down from the network).
ETSI
17 ETSI TS 101 882 V1.1.1 (2002-05)
A.5.1 U_RegistrationRequest
The U_RegistrationRequest
...