ETSI TR 184 007 V2.2.1 (2008-11)

Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Naming/Numbering Address Resolution (NAR)

RTR/TISPAN-04016-NGN-R2

General Information

• Status: Published
• Publication Date: 18-Nov-2008
• Technical Committee: TISPAN 4 - TISPAN Numbering Addressing and routing
• Current Stage: 12 - Completion
• Due Date: 17-Oct-2008
• Completion Date: 19-Nov-2008

Standards Content (Sample)

Technical Report
Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN);
Naming/Numbering Address Resolution (NAR)

2 ETSI TR 184 007 V2.2.1 (2008-11)

Reference
RTR/TISPAN-04016-NGN-R2
Keywords
addressing, enum, DNS
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://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
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 2008.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
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 TR 184 007 V2.2.1 (2008-11)
Contents
Intellectual Property Rights . 4
Foreword . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definitions and Abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 8
4 Introduction . 10
5 Rationale for the Analysis of Naming Numbering Address Resolution and of the Basic Structure
of a Naming Numbering Address Resolution Framework . 11
5.1 Motivation - Use Cases . 11
5.2 Steps requiring further Investigation . 19
6 Basic Structure of the Naming/Numbering Address Resolution Framework . 20
6.1 NAR Methods - Generic Approach . 20
6.2 Fundamental Principles and Requirements . 21
6.3 NAR Process in TISPAN NGN . 22
7 Gap-Analysis . . 25
7.1 Concept of NAR to support/enable Use Cases . 26
7.2 Reference Points/Interfaces between NAR and Network Elements . 26
7.3 Introduction of a Network Function NAR . 26
8 Conclusions . 27
Annex A: Bibliography . 28
Annex B: Change history . 29
History . 30

ETSI
4 ETSI TR 184 007 V2.2.1 (2008-11)
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 Report (TR) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN).
ETSI
5 ETSI TR 184 007 V2.2.1 (2008-11)
1 Scope
The present document investigates the need to introduce a Naming/Numbering Address Resolution framework into
TISPAN NGN conformant communication networks. To this end the following topics are covered:
• Analysis of the consequences of creating a Naming/Numbering Address Resolution framework.
• Gap Analysis of current TISPAN NGNs specifications in comparison to existing/emerging solutions of NAR
methods.
• Identification of items for standardization as a result of the analysis described in the bullet above.
Furthermore the present document investigates the Naming/Numbering Address Resolution (NAR) in NGNs and
identifies Naming/Numbering Address Resolution (NAR) use cases used in NGN environments.
2 References
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.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably,
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the
method of access to the referenced document and the full network address, with the same punctuation and use of upper
case and lower case letters.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
Not applicable.
2.2 Informative references
The following referenced documents are not essential to the use of the present document but they assist the user with
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including
any amendments) applies.
[i.1] ITU-T Recommendation E.164(2005): "The international public telecommunication numbering
plan".
ETSI
6 ETSI TR 184 007 V2.2.1 (2008-11)
[i.2] ETSI TS 184 002 (V.1.1.1): "Telecommunications and Internet converged Services and Protocols
for Advanced Networking (TISPAN); Identifiers (IDs) for NGN".
[i.3] ETSI ES 282 002: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); PSTN/ISDN Emulation Sub-system (PES); Functional
architecture".
[i.4] IETF RFC 3761: "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)".
[i.5] ETSI TS 123 228: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); IP Multimedia Subsystem (IMS); Stage 2
(3GPP TS 23.228 Release 8)".
[i.6] ITU-T Recommendation Y.2001 (2004): "General overview of NGN".
[i.7] ETSI TR 184 005 (V1.1.1): "Telecommunications and Internet converged Services and Protocols
for Advanced Networking (TISPAN); Types of numbers used in an NGN environment".
[i.8] ETSI TS 124 229: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Internet Protocol (IP) multimedia call control protocol
based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3
(3GPP TS 24.229 Release 8)".
[i.9] ETSI TR 123 979: "Universal Mobile Telecommunications System (UMTS); 3GPP enablers for
Open Mobile Alliance (OMA) Push-to-talk over Cellular (PoC) services; Stage 2
(3GPP TR 23.979 Release 7)".
[i.10] ETSI TS 123 140: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Multimedia Messaging Service (MMS); Functional
description; Stage 2 (3GPP TS 23.140 Release 6)".
[i.11] ETSI TS 123 141:"Universal Mobile Telecommunications System (UMTS); Presence service;
Architecture and functional description; Stage 2 (3GPP TS 23.141 Release 7)".
[i.12] IETF RFC 3966: "The tel URI for Telephone Numbers".
[i.13] IETF RFC 4282: "The Network Access Identifier".
[i.14] ETSI TR 184 003: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Number Portability scenarios in Next Generation
Networks (NGNs)".
[i.15] ETSI EG 284 004 (V1.1.2): "Telecommunications and Internet converged Services and Protocols
for Advanced Networking (TISPAN); Incorporating Universal Communications Identifier (UCI)
support into the specification of Next Generation Networks (NGN)".
[i.16] IETF RFC 5031: "A Uniform Resource Name (URN) for Emergency and Other Well-Known
Services".
[i.17] ETSI TS 129 228: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); IP Multimedia (IM) Subsystem Cx and Dx Interfaces;
Signalling flows and message contents (3GPP TS 29.228 Release 8)".
[i.18] ETSI ES 282 001 (V2.0.0): "Telecommunications and Internet converged Services and Protocols
for Advanced Networking (TISPAN); NGN Functional Architecture".
[i.19] ITU-T Recommendation E.191 (2000): "B-ISDN Addressing".
[i.20] GSMA IR.67: "DNS Guidelines for Operators".
[i.21] IETF RFC 4769: "IANA Registration for an Enumservice Containing Public Switched Telephone
Network (PSTN) Signaling Information".
[i.22] IETF RFC 4967: "Dial String Parameter for the Session Initiation Protocol Uniform Resource
Identifier".
ETSI
7 ETSI TR 184 007 V2.2.1 (2008-11)
[i.23] IETF RFC 4694: "Number Portability Parameters for the tel URI".
[i.24] ETSI TS 182 006: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Stage 2 description
[3GPP TS 23.506 Release 8, modified]".
[i.25] IETF RFC 2822: "Internet Message Format".
3 Definitions and Abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ITU-T Recommendation E.164 [i.1],
TS 184 002 [i.2], TR 184 005 [i.7], ITU-T Recommendation E.191 [i.19] and the following apply:
address: identifier for a specific termination point and used for routing to this termination point
NOTE: From this understanding e-mail address and SIP addresses are no addresses but names due to utilized by
users!
dialling plan : string or combination of decimal digits, symbols, and additional information that defines the method by
which the numbering plan is used
NOTE: A dialling plan includes the use of prefixes, suffixes, and additional information, supplemental to the
numbering plan, required to complete the call.
Domain Name System (DNS): most ubiquitous naming service in the world is the DNS system used on the Internet
and other IP networks
NOTE: DNS returns the numeric IP address for the submitted domain name.
E.164 number: string of decimal digits that satisfies the three characteristics of structure, number length and
uniqueness specified in ITU-T Recommendation E.164
NOTE: The number contains the information necessary to route the call to the end user or to a point where a
service is provided.
identifier: series of digits, characters and symbols used to identify uniquely subscriber(s), user(s), network element(s),
function(s) or network entity(ies) providing services/applications
NOTE 1: Identifiers can be used for registration or authorization. They can be either public to all networks or
private to a specific network (private IDs are normally not disclosed to third parties).
NOTE 2: In 3GPP the term "Identity" or "ID" is typically used instead.
international E.164 number: string of decimal digits that, for a geographic country code, uniquely identifies a
subscriber or a point where a service is provided
NOTE 1: For the case of a global service code, it identifies the subscriber of the service. For Networks, it identifies
a subscriber of the Network. An international E.164 number can act in the "role" of both a name and an
address. Portability is reducing a number's role as an address. Numbers are increasingly acting in the role
of a name only.
The number, which includes the country code and subsequent digits, but not the international prefix,
contains the information necessary to route the call to this termination point on a public network (it may
also contain the supplementary information necessary to forward it on a private network).
NOTE 2: It is sometimes referred to as an "international number", "international public telecommunication
number" or "E.164 number".
name: identifier of an entity (e.g. subscriber, network element) that may be resolved/translated into an address
NOTE: From this understanding e-mail address and SIP addresses are names and used by users!
ETSI
8 ETSI TR 184 007 V2.2.1 (2008-11)
Name number Address Resolution (NAR): terms "address resolution" and "name resolution" are synonymous and are
used in the IP world in different manners:
• In IP networks, there are two types of Address Resolutions defined:
- The first is the conversion from a domain name into an IP address (see DNS).
- The second is from the IP address to the Ethernet Address Resolution - this is not in the scope of the
present document.
• The Name/Number to Address Resolution is queried using names (E.164 numbers) and responds with
addresses (e.g. SIP URIs) associated with that name.
• These functions could be used internal for one operator network or shared between networks.
non-E.164 number: any number, defined inside national E.164 numbering plan, which does not conform to the
structure of international E.164 numbers as defined in ITU-T Recommendation E.164 and is only used and meaningful
in the national dialling plan and is not reachable from abroad
NOTE: An explanation of non-E.164 numbers is in ITU-T Recommendation E.164 [i.1] in clause A.8.
number: string of decimal digits
public identifier: series of digits, characters and symbols used in public networks to uniquely identify subscriber(s),
user(s), network element(s), function(s) or network entity(ies) providing services/applications
routing: in SIP, determination process of a route (which is a series of Route header fields) for delivering a request to
the current name or address that identifies the target of the request
SIP Address-of-Record (AoR): SIP or SIPS URI that points to a domain with a location service that can map the URI
to another URI where the user might be available
NOTE: Typically, the location service is populated through registrations. An AOR is frequently thought of as the
"public address" of the user.
tel URI: representation of an international E.164 number or another number with the context defined (e.g. private
number, short code)
NOTE 1: RFC 3966 [i.12], which defines the use of the tel URI, also uses the term "local number", but uses it in a
totally different way from E.164.
NOTE 2: RFC 3966 [i.12] recognizes:
- "Global number" - which always start with +CC.
- "Local number" - which is anything that is not a "global number".
- Thus what E.164 refers to as national numbers, "local numbers" and short codes (as well as other types
such as private numbers) would all be treated by RFC 3966 [i.12] as "local numbers". In the case of
"local numbers", RFC 3966 [i.12] uses a context qualifier to distinguish the type of number.
- In the context of the present document, the term "local number" will be used in the E.164 sense and
international/national format issues have to be defined in the SIP context.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
3GPP 3rd Generation Partnership Project
AoR Address of Record
AS Application Service
BGCF Border Gateway Control Function
BGCF Breakout Gateway Control Function
BSF Bootstrapping Server Function
ETSI
9 ETSI TR 184 007 V2.2.1 (2008-11)
CC Country Code
ccTLD country code Top Level Domain
NOTE: (e.g.: .fr)
CLI Calling Line Identity
CN Core Network
CP Communication Provider
CPE Customer Premises Equipment
CS Circuit Switched
CS/GPRS Circuit Switched/General Packet Radio Service
CSCF Call Server Control Function
CSCF Call Session Control Function
DNS Domain Name System
ENUM tElephone NUmber Mapping
FFS For Further Study
FQDN Full Qualified Domain Name
GPRS General Packet Radio Service
GRX GPRS Roaming eXchange
GSM Global System for Mobile communication
GSMA GSM Association
GW GateWay
HSS Home Subscriber Server
ICANN Internet Corporation for Assigned Names and Numbers
I-CSCF Interrogating - CSCF
ID IDentifier
IIN Issuer Identifier Number
IM IP Multimedia
IMPI IP Multimedia Private Identity
IMPU IP Multimedia PUblic identity
IMS IP Multimedia Subsystem
IMSI International Mobile Subscriber Identity
IP Internet Protocol
IPX IP Exchange
ISDN Integrated Services Digital Network
ISIM IM Services Identity Module
ISUP ISDN User Part
LDAP Lightweight Directory Access Protocol
LoST Location to Service Translation protocol
MAP Mobile Application Part
MCC Mobile Country Code
MGCF Media Gateway Control Function
MM Multimedia Message
MM4 Multimedia Message 4
MMS Multimedia Messaging Service
MMSC Multimedia Messaging Switching Center
MMSE Multimedia Messaging Service Environment
MNC Mobile Network Code
MSISDN Mobile Station ISDN number
NAI Network Access Identifier
NAPTR Naming Authority PoinTer Record
NAR Naming/Numbering Addressing Resolution
NASS Network Attachment SubSystem
NDC National Destination Code
NGN Next Generation Network
NGN Next Generation Network
NNI Network to Network Interface
NP Number Portability
NRA National Regulatory Authority
OMA Open Mobile Alliance
PBX Private Branch eXchange
P-CSCF Proxy CSCF
ETSI
10 ETSI TR 184 007 V2.2.1 (2008-11)
PDBF Profile Data Base Function
PES PSTN Emulation Subsystem
PLMN Public Land Mobile Network
PoC Push to talk over Cellular
PSI Public Service Identifier
PSTN Public Switched Telephone Network
PUA Personal User Agent
QoS Quality of Service
RACS Resource and Admission Control Subsystem
RAN Radio Access Network
RCPT TO Recipient Pointer to
RFC Request For Comments
S-CSCF Serving CSCF
SGSN Serving GPRS Support Node
SIM Subscriber Identity Module
SIP Session Initiation Protocol
SLF Subscription Locator Function
SMTP Simple Mail Transfer Protocol
SN Subscriber Number
SS7 Signalling System number 7
TCAP Transaction Capabilities Application Part
TDM Time Division Mode
TEL URI Telephony Universal Resource Identifier
TLD Top Level Domain
UA User Agent
UCI Universal Communications Identifier
UE User Equipment
UICC Universal Integrated Circuit Card
UMTS Universal Mobile Telecommunication System
UPSF User Profile Server Function
URI Universal Resource Identifier
URL Universal Resource Locator
URN Uniform Resource Names
USIM UMTS Subscriber Identity Module
VPN Virtual Private Network
WG4 TISPAN Working Group 4
WLAN Wireless Local Area Network
4 Introduction
The present document covers Naming/Numbering Address Resolution use cases, identified gaps in the current standards
and contribute activities how Naming/Numbering Address Resolution (NAR) aspects should be treated in NGN
standardization.
The Naming/Numbering Address Resolution (NAR) provides resolution and translation functions for NGN systems.
NAR represent a set of translation functions associated with handling of dial strings, numbers, names and addresses.
These are necessary to set up calls / sessions. Some of these functions may already reside within existing
entities / subsystems. Analysis of the use cases provides an assessment of where these functions reside and where gaps
in NGN standardization exist.
In light of developments in NGNs with a growing number of physically disjoint but logically correlated identifiers
(Names, Numbers, Addresses) stored and translated in NAR entities a consolidation and co-ordination of these is
needed to prevent further redundancy and possible contradiction and to enable operators to administer and provision
complex and combined services.
ETSI
11 ETSI TR 184 007 V2.2.1 (2008-11)
5 Rationale for the Analysis of Naming Numbering
Address Resolution and of the Basic Structure of a
Naming Numbering Address Resolution Framework
Following is the description of Uses Cases that has been investigated on the base of current NGN specification
document that covers some Naming/Numbering Address Resolution (NAR) aspects.
5.1 Motivation - Use Cases
Use Case 1: PSTN/ISDN Emulation Sub-system (PES)
In ES 282 002 "PSTN/ISDN Emulation Sub-system (PES); Functional architecture" [i.3] the following use case is
described:
"There is a general requirement to find the uri to which sip messages should be sent to effect a connection with the
customer at a dialled number. Whether the original enquiry is made as a tel URI or using any other scheme. Whilst
ENUM appears to be a way of doing this at the level of this requirements document it is used as an indication of the
class of system to which the requirement applies rather than a definitive statement of a system or solution.
The expected information flow is seemingly simple with a request containing a telephone number returning a
response which is the name that will provide an address of the server to which the SIP with encapsulated ISUP
message should be sent to establish the call. It should be anticipated that more complex algorithms are required
since it is not the case that all applications to the PSTN with a single telephone number result in the next telephony
routing hop being to the same telephone exchange, or point code."
Following are the aspects related to NAR that could represent a potential issue:
• No NAR method recommended, only a non specific reference to ENUM.
• No method for the Interconnection use case proposed.
• No recommendation for the reference point between PES and NAR.
Use Case 2: Number Portability for PES
In ES 282 002 [i.3] the following use case is described:
"In complex networks with wholesale and transit provisions the next hop chosen may depend on which person asks,
be it a subscriber or an operator customer. It may also depend on where the question is asked from. A further case
is the inclusion of network routing principles to minimize the transitions between IP and TDM networks. Logically
there is a case for suggesting that a functional replacement for number portability with all call queries should be
used. This would allow the originating network to determine if a call is best addressed to a SIP with encapsulated
ISUP server which will cause routing to the TDM network or to an IP network. The choice will need to be at a
granularity of a single line so that the effect of number portability can be handled through a transition between
TDM and IP networks.
Nothing in this clause is intended to determine how the function is provided or administered only what the
requirements are from the PSTN and in particular during its transition. A further useful facility is to allow the
presence of overload to be communicated before a call is placed. This has the effect of reducing the overload on the
network at the originating edge during mass calling events Information flows.
The numbering database query is a confirmed information flow which provides information that is of use from a
requester located anywhere in a PSTN network. The value of this approach is to allow centralized control over some
aspect of telephony routing and to allow a common NGN approach to number portability.
The query is expected to optionally spawn any appropriate query of the number portability information resulting in
what looks like a single query that returns the next hop information. It is expected the next hop will include a
decision on whether the route taken by the call should be TDM or IP. That decision could be based on where the
call originates or which location it enters the network."
ETSI
12 ETSI TR 184 007 V2.2.1 (2008-11)
Following are the aspects related to NAR that could represent a potential issue:
• No NAR method recommended, only a non specific reference to a "Common NGN approach on NP".
• No recommendation for the reference point between PES and NAR.
Use Case 3: IMS Number Portability (NP)
In TS 123 228 [i.5] the following use case is described:
"4.18.1 Number portability
Number portability (NP) allows a user to retain their E.164 number when changing subscriptions from one network
operator to another. As such, NP applies to TEL URIs and SIP URI with user=phone parameters. NP is subject to
regional requirements and is accomplished through the retrieval of ported data from those data bases. The
specification of these data bases is out of scope of the present document, but the NP data may be accessed through
ENUM/DNS or accessed via existing (PSTN and CS domain) NP databases using the legacy PSTN/CS-domain
protocols, such as TCAP.
Support of NP within a network and the exact means to make the number portability data available to IMS, is
subject to and configured per operator policy. NP is not mandated by this specification on any network operator.
As configured per operator policy, IMS ENUM interfaces can be updated to support handling of the PSTN ENUM
service per RFC 4769 [i.21], which provides a URI containing an E.164 number with NP routing information and
NP dip indicators. The IMS entity receiving NP information as a result of an ENUM/DNS query, the S CSCF as an
example, needs to support, or not remove, NP protocol parameters retrieved as part of ENUM/DNS procedures
contained in this specification. Subsequent network elements used to process the call to the PSTN do not remove the
NP protocol parameters inserted in SIP messaging as part of the NP data retrieval procedure.
NP data can also be made available by means of direct access to PSTN/CS domain NP Databases using the legacy
PSTN/CS-Domain interfaces and protocols. To support this existing interface within the network, the requesting and
subsequent network elements need to support, or not remove, NP protocol parameters within SIP messages that
result from the NP data retrieval procedures. The procedures to retrieve the NP data using the legacy PSTN/CS
domain interfaces are out of scope of this specification.
Alternatively, per operator policy, the BGCF can retrieve NP data as part of the procedures to select an MGCF for
PSTN connection. The interface used at the BGCF to retrieve the NP data is out of scope of this specification.
Alternatively, per operator policy, the MGCF may support legacy interfaces to retrieve number portability data.
NOTE: Although legacy protocols are used to access the number portability database, this does not imply that
the IMS nodes (CSCFs, BGCFs) need to implement such protocols."
Following are the aspects related to NAR that could represent a potential issue:
• No recommendation for the reference point between IMS and NAR.
• Further requirements will also be defined in [i.14]. Currently being progressed in WG4.
Use Case 4: (IMS) Interconnection
In TS 123 228 [i.5] the following use case is described:
When the subscriber provided an E.164 number only, 3GPP foresees an E.164 to SIP URI resolution. If the requested
E.164 number is not served by the originating IMS, Interconnection with other IMS or Interworking with PSTN/ISDN
will be required:
"In the case where the Request-URI of the incoming INVITE request to S-CSCF contains a Tel URI, it has to be
translated to a globally routable SIP-URI before applying it as Request-URI of the outgoing INVITE request. For
this address translation the S-CSCF uses the services of an ENUM-DNS protocol based on to RFC 3761 [i.4].
Database aspects of ENUM are outside the scope of this specification.
The S CSCF shall support the ability to translate the E.164 address contained in a Request-URI in the non-SIP URI
Tel: URI format IETF RFC 3966 [i.12] to a SIP routable SIP URI using an ENUM DNS translation mechanism
based on IETF RFC 3761 [i.4]. If this translation fails, then the session may be routed to the PSTN or appropriate
notification shall be sent to the mobile, depending on network operator configuration."
ETSI
13 ETSI TR 184 007 V2.2.1 (2008-11)
Following is the aspect related to NAR that could represent a potential issue:
• No recommendation for the reference point between IMS and ENUM-DNS.
Use Case 5 Application Server Address Resolution:
In TS 123 228 [i.5] the following use case is described:
"An Application Service (AS) is hosting Public Service IDs (PSI) and may originate requests with the PSI as the
originating party. For such originating requests, the home IMS network shall be capable to perform the following
function:
• If the target identifier is a Tel URI, ENUM translation needs to be performed, and the request shall be routed
based on the translation result.
Routing from the Originating AS hosting the PSI can be performed as follows:
a) The AS may forward the originating request to the destination network without involving an S-CSCF. If this
option is applied where the target identifier is a Tel URI, the AS shall perform an ENUM query and route the
request based on the translation result. ENUM support for an AS is optional; therefore, if an AS does not
support ENUM and the target identifier is a Tel URI, it shall be configured to use b).
b) If the PSI has an S-CSCF assigned, the AS forwards the originating request to this S-CSCF, which then
processes the request as per regular originating S-CSCF procedures (including a possible DNS/ENUM
query)."
Following is the aspect related to NAR that could represent a potential issue:
• No recommendation for the reference point between AS and ENUM-DNS.
Use Case 6: Push to Talk over cellular (PoC)
In TR 123 979 [i.9] the following use case is described:
The 3GPP systems provide the capabilities to support the PoC service architecture as specified in OMA.
It is assumed that the PoC architecture makes use of the following IMS capabilities in the 3GPP system, which is
described in TS 123 228 [i.5] and TS 123 141 [i.11]:
"- Registration;
- IMS routing capabilities, including discovery and address resolution;
- IMS security including authentication and authorization;
- IMS charging;
- SIP compression;
- IMS group management;
- Public service identities;
- Presence Service."
Following are the aspects related to NAR that could represent a potential issue:
• No recommended NAR method.
• No recommendation for the reference point between PoC Server and ENUM-DNS.
ETSI
14 ETSI TR 184 007 V2.2.1 (2008-11)
Use Case 7: MMS Interconnection
In TS 123 140 [i.10] it is stated that both MSISDN (E.164) and NAI/email [i.13] addresses are to be supported in an
MMS environment.
TS 123 140 [i.10] defines two options for translating a dialled MSISDN into the correct MMSC address for a
destination operator. ENUM is identified as the long-term solution for MSISDN to MMSC address mapping, but in the
short term a solution using a MAP query for an IMSI address is defined.
Option 1 short term hybrid solution:
TS 123 140 [i.10]:
"Only if recipient addressing resolution mechanism based on a MAP query is used, the procedures defined in this
clause shall be followed.
For those recipients MSISDN addresses that appear in an MM and belong to an external MMSE, the originator
MMS Relay/Server shall translate (resolve) them to a routable RFC 2822 [i.25] address that shall be used in the
"RCPT TO" SMTP subsequent commands.
Recipient MSISDN addresses resolution procedure:
1. The originator MMS Relay/Server determines that the recipient MSISDN address belongs to an external MMSE.
2. The originator MMS Relay/Server shall interrogate the recipient HLR for the associated IMSI by invoking the
standard GSM-MAP operation SRI_for_SM. This operation should be invoked with the SM-RP-PRI parameter set to
'true'. As an optional feature, to complement the mandatory SRI_for_SM operation, the Relay/Server may also
support the Send_IMSI MAP operation.
3. In case of a successful interrogation the originator MMS Relay/Server shall determine the MCC and MNC and
look up for a matching entry in an IMSI table. The IMSI table shall maintain the associations of MCC + MNC ->
MMSE FQDN. Subsequently the originator MMS Relay/Server shall be able to resolve (e.g. using standard DNS)
the MMSE FQDN to an IP address for establishing the SMTP (MM4) session."
Additional information from a GSMA "DNS Guidelines for Operators" [i.20]:
"One important issue to highlight is that GSMA PRD IR.34 states that all kinds of traffic, including MMS inter-
working traffic, should use the ".gprs" TLD in the GRX network. If the GRX is used as an inter-PLMN network for
MMS, then the following format of FQDN addressing is used for MMS inter-working:
mms.mnc.mcc.gprs
The domain name begins with the prefix of "mms." to help differentiate IP traffic based on the service used. For
example, the recipient should be addressed as:
[phone]/TYPE=[e-mail] with the RCPT TO header inside the SMTP message in
MM4 interface."
Following are the aspects related to NAR that could represent a potential issue:
• The functionality is defined by GSMA in IR67 [i.20].
• No TISPAN equivalent (ongoing work in WG4).
• No TISPAN IPX/network namespace or authority.
Option 2 long term solution:
TS 123 140 [i.10]:
"For those recipients MSISDN addresses that appear in an MM and belong to an external MMSE, the originator
MMS Relay/Server shall translate (resolve) them to a routable RFC 2822 [i.25] address that shall be used in the
"RCPT TO" SMTP subsequent commands.
ETSI
15 ETSI TR 184 007 V2.2.1 (2008-11)
DNS-ENUM recipient MSISDN address resolution procedure:
1. The originator MMS Relay/Server shall ensure that the recipient address (MSISDN) complies with the E.164
address format and includes the ‘+' character. In the case of national or local addressing scheme (e.g. only
operator code followed by a number), the MMS Relay/Server shall convert the national or local number to an E.164
address format…
……
8. The output may result in one of the following cases:
….
e. E.164 number in the numbering plan and MMS NAPTR(s) exist for that number.
……
10. The originator MMS Relay/Server shall resolve the domain part of the "mailbox" of the highest precedence MMS
NAPTR to an IP address using standard DNS according to "Address Resolution and Mail Handling". Specifically,
MX records shall be checked for and, if present, shall be used.
EXAMPLE: The highest precedence URI for MMS is mailto:[phone]/TYPE=[e-mail]
The domain part of the "mailbox" is mms.cosmote.gr and is resolved (e.g. DNS) to 10.10.0.1
11. The resulting IP address together with the recipient RFC 2822 [i.25] address ("mailbox") shall be used by the
originator MMS Relay/Server for routing forward the MM using the protocol described in clause 6.8 to the recipient
MMS Relay/Server."
Following are the aspects related to NAR that could represent a potential issue:
• The functionality is defined by GSMA in IR67 [i.20].
• No TISPAN equivalent (ongoing work in WG4).
• No TISPAN IPX/network namespace or authority.
Use Case 8: Presence Service
In TS 123 141 [i.11] the following use case is described:
"5.3.2 Watcher Presence Proxy
When a Watcher application intends to access some presence information of a presentity, it first needs to contact its
Watcher Presence Proxy which will contact the Presentity Presence Proxy to find the Presence Server containing
this information.
The Watcher Presence Proxy shall provide the following functionality:
- Address resolution and identification of target networks associated with a presentity;
- Authentication of watchers;
- Interworking between presence protocols for watcher requests;
- Generation of accounting information for watcher requests.
A.2.2.1-1 shows an IMS watcher subscribing to presence event notification about an IMS based presentity. The
presentity may either be in the same IM-CN subsystem as the watcher or may be in a different IM-CN subsystem.
The flows for both these cases are the same.
…
ETSI
16 ETSI TR 184 007 V2.2.1 (2008-11)
1. A watcher agent in a UE wishes to watch a presentity's presence information, or certain parts of the presentity's
presence information (defined by the filters included in SubscribePres). To initiate a subscription, the UE sends a
SubscribePres message request containing the presence related events that it wishes to be notified of, together with
an indication of the length of time this periodic subscription should last. The UE sends the SubscribePres
information flow to the proxy (subscriber identity, home networks domain name). The SubscribePres may also
include an indication of the watcher's capability to handle partial notifications.
2. The P-CSCF remembers (from the registration process) the next hop CSCF for this UE. In this case the
SubscribePres is forwarded to the S-CSCF in the home network. In this case, the P-CSCF and the S-CSCF act as a
Watcher Presence Proxy.
3. The S-CSCF is unable to resolve the presence server address of the presentity that the UE is requesting to watch,
and as a result forwards the SubscribePres message to the an I-CSCF offering part of the Presentity Presence Proxy
functionality. The S-CSCF shall examine the home domain of the presentity associated with the request and if the
request is for a presentitiy outside the operator's domain, it determines the external I-CSCF. If the request is for a
presentity in the same domain, the S-CSCF forwards the request to the local I-CSCF.
4. The I-CSCF examines the presentity identity and the home domain identity and employs the services of a name-
address resolution mechanism to determine the HSS address to contact. The I-CSCF shall query the HSS to obtain
the address of the S-CSCF associated with the Presentity. It shall query the HSS via a Query message.
5. The Query Resp message from the HSS provides the name of the S-CSCF associated with the presentity.
6. The I-CSCF, using name of the Presence Server shall determine the address of the S-CSCF through a name-
address resolution mechanism. The SubscribePres message is forwarded to the S-CSCF."
Following are the aspects related to NAR that could represent a potential issue:
• No recommended NAR method.
• No recommendation for the reference point between Presence Server and ENUM-DNS.
Use Case 9: non E.164 Numbers
In TR 184 005 [i.7] the following use case is described:
Treatment of non-E.164 numbers in ETSI NGNs:
"Non-E.164 numbers are defined in the national E.164 numbering plan where the E.164 number of the originator
used as public identifier belongs to. The dialling plan of the originator is therefore defined nationally or in case of
geographic numbers even locally. The interpretation of non-E.164 numbers is therefore dependent on the user
profile and the home network and done either in the originating user agent or by the S-CSCF or the translation
function of the home network.
Since the routing in ETSI NGNs is done by SIP URIs, all non-E.164 numbers must be recognized and translated to
either a Public Service Identity (PSI - e.g. a SIP URI or a tel URI) or a service URN. The mapping can be done
either directly in the S-CSCF or in a special purpose Application Server (AS). Some of these non-E.164 numbers
may also be forwarded to the PSTN, either directly or translated to an E.164 number. The mapping of these
numbers might be dependent of the dialling plan used.
Special case is location-dependent numbers. These numbers are recognized depending on the dialling plan (user
profile), but are routed depending on the location of the UE. See Section 9.9.
The national service numbers fit in principle into the international E.164 numbering plan, but are in some cases
restricted to national use, i.e. they cannot be reached from other countries. In some cases access exists via bi-lateral
agreements, in other cases they may be accessed, but not free-of-charge in the case of free phone numbers.
This raises the question how a mobile UA using his home dialling plan may access these service numbers if visiting
t
...