ETSI TR 184 007 V2.1.1 (2008-08) Technical Report
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Naming/Numbering Address Resolution (NAR)
2 ETSI TR 184 007 V2.1.1 (2008-08)
Reference DTR/TISPAN-04011-NGN-R2
Keywords addressing, enum, DNS
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, 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.
DECTTM, PLUGTESTSTM, UMTSTM, TIPHONTM, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM 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.1.1 (2008-08)
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...... 10 5.1 Motivation - Use Cases ...... 10 5.2 Steps requiring further Investigation ...... 18 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 ...... 26 Annex A (informative): Bibliography...... 27 History ...... 28
ETSI 4 ETSI TR 184 007 V2.1.1 (2008-08)
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.1.1 (2008-08)
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(02/2005): "The international public telecommunication numbering plan".
ETSI 6 ETSI TR 184 007 V2.1.1 (2008-08)
[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 version 8.4.0 Release 8)".
[i.6] ITU-T Recommendation Y.2001 (12/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 version 8.3.0 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 version 6.2.0 Release 6)".
[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 version 6.9.0 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 version 7.3.0 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 for 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 7)".
[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.1.1 (2008-08)
[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.228 v7.2.0, modified)".
[i.25] IETF RFC 2822: "Internet Message Format".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following 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 [i.1]
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.1.1 (2008-08)
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 [i.1] 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, routing is the process of determination 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 Breakout Gateway Control Function BSF Bootstrapping Server Function CC Country Code
ETSI 9 ETSI TR 184 007 V2.1.1 (2008-08) ccTLD country code Top Level Domain (e.g. .fr) CLI Calling Line Identity CN Core Network CPE Customer Premises Equipment CS Circuit Switched CS/GPRS Circuit Switched/General Packet Radio Service CSCF Call Session Control Function DNS Domain Name System ENUM Telephone Number Mapping FFS For Further Study GPRS General Packet Radio Service GRX GPRS Roaming eXchange GSM Global System for Mobile Communication GSMA GSM Association 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 ISDN Integrated Services Digital Network ISIM IM Services Identity Module LDAP Lightweight Directory Access Protocol LoST Location to Service Translation Protocol MCC Mobile Country Code MGCF Media Gateway Control Function 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 Sub System NDC National Destination Code NGN Next Generation Network NRA National Regulatory Authority PBX Private Branch Exchange P-CSCF Proxy CSCF PDBF Profile Data Base Function PES PSTN Emulation Subsystem PLMN Public Land Mobile Network 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 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 SN Subscriber Number SS7 Signalling System No. 7 TLD Top Level Domain UCI Universal Communications Identifier UE User Equipment
ETSI 10 ETSI TR 184 007 V2.1.1 (2008-08)
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 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.
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 [i.3] "PSTN/ISDN Emulation Sub-system (PES); Functional architecture" 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.
ETSI 11 ETSI TR 184 007 V2.1.1 (2008-08)
• 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."
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, 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.
ETSI 12 ETSI TR 184 007 V2.1.1 (2008-08)
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 TR 184 003 [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. 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 to a SIP routable SIP URI using an ENUM DNS translation mechanism based on IETF RFC 3761. 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."
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 system shall provide the capabilities to support the PoC service architecture as specified in OMA.
ETSI 13 ETSI TR 184 007 V2.1.1 (2008-08)
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.
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 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
ETSI 14 ETSI TR 184 007 V2.1.1 (2008-08)
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:
+358405344455/[email protected] 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 address that shall be used in the "RCPT TO" SMTP subsequent commands.
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:+306971234567/[email protected]
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 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.
ETSI 15 ETSI TR 184 007 V2.1.1 (2008-08)
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.
…
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.
ETSI 16 ETSI TR 184 007 V2.1.1 (2008-08)
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 the country where these service numbers are in use."
Following are the aspects related to NAR that could represent a potential issue:
• No recommended NAR method.
• No recommendation for the reference point between special Application Server/S-CSCF and the address resolution function.
Use case 10: Address Resolution in UCI
In EG 284 004 [i.15] the following use case is described:
"ENUM or DNS may be used to implement the UCI to PUA resolution service. In such cases ENUM/DNS may be considered as instances of the "Resolver" class.
Where ENUM is used as a TISPAN number resolution service, the UCI numeric can be placed as a single entry in a NAPTR record. This entry would contain the URI of the user's PUA and specify the service type as "uci".
EXAMPLE: $ORIGIN 6.6.7.3.6.0.4.8.8.7.4.4.e164.arpa. IN NAPTR 102 10 "u" "uci+E2U" "!^.*$!uci:[email protected]!"
In order to ensure that session establishment to UCI users can be guaranteed from the very earliest phases of the introduction of UCI, it is advised that an additional entry is placed in the NAPTR record using the SIP URI scheme. Apart from the scheme identifier, the content of the URI can be identical to that of the entry using the UCI URI scheme. This ensures that those ENUM clients and SIP clients that are unaware of UCI will be able to successfully establish SIP sessions with a UCI user."
Following are the aspects related to NAR that could represent a potential issue:
• No recommendation for the reference point between PUA Server and ENUM-DNS.
• No definition for the Resource Record Type "uci".
ETSI 17 ETSI TR 184 007 V2.1.1 (2008-08)
Use case 11: Implicit Registration Public to Private Identifier resolution
In TS 123 228 [i.5] the following use case is described:
Description:
The UPSF provides support to AS or BSF for application registration based on public user identifiers (non ISIM authentication). Therefore the UPSF provides a naming/address resolution between public ID (Identifier) and private ID e.g. MSISDN (Mobile Subscriber Integrated Services Digital Network Number) to NAI (Network Access Identifier), also known as "implicit registration".
Following are the aspects related to NAR that could represent a potential issue:
• NAR method is UPSF.
• Reference point is Cx defined in TS 129 228 [i.17].
Use case 12: IMS Interconnection
In ES 282 001 [i.18] the following use case is described:
"7.3.1 SoIx in the NGN Architecture...
As illustrated in Figure 7a, SoIx interconnection is typically characterized by the presence of two types of information exchanged between the two interconnected domains:
• Service-related signalling information, that identifies the end-to-end service that has been requested. For example, in case of IMS-to-IMS SoIx interconnection, this is mapped to SIP signalling on the Ic interface.
• Transport information, that carries the bearer traffic
Service-related signalling Information Service Layer
Transport Information Transport Layer
SoIX NNI
Figure 7a: SoIx Interconnection architecture and NNI"
Following are the aspects related to NAR that could represent a potential issue: • No definition of the Service-related address information that identifies the destination.
• No recommendation for the resolution of target (user) name into target network element identifier and additionally in the case of user provided identifier in the form: user@userdomain.
Use case 13: Roaming; Determination of the address of the home I-CSCF
In IP Multimedia Subsystem [i.5] the following use case is described:
The P-CSCF in the case of registration in the visited network (roaming) provides through a name-address resolution mechanism the address of the home I-CSCF.
"Upon receipt of the register information flow, the P-CSCF shall examine the "home domain name" to discover the entry point to the home network (i.e. the I CSCF). The proxy shall send the Register information flow to the I-CSCF (P-CSCF address/name, Public User Identity, Private User Identity, P-CSCF network identifier, UE IP address). A name-address resolution mechanism is utilized in order to determine the address of the home network from the home domain name. The P-CSCF network identifier is a string that identifies at the home network, the network where the P-CSCF is located (e.g., the P-CSCF network identifier may be the domain name of the P-CSCF network).."
ETSI 18 ETSI TR 184 007 V2.1.1 (2008-08)
Following are the aspects related to NAR that could represent a potential issue:
• NAR method is not defined
Use case 14: User Identifier to HSS (3GPP)/UPSF (TISPAN) resolution
In TS 129 228 [i.17] the following use case is described:
"In the case were the address of the HSS belonging to the user identifier is unknown, a user identifier to HSS resolution is provided by the SLF within administrative domain.
The User Identifier to HSS resolution mechanism enables the I-CSCF, the S-CSCF and the BSF to find the address of the HSS, that holds the subscriber data for a given Public Identity when multiple and separately addressable HSSs have been deployed by the network operator. The resolution mechanism described in [3GPP 23.228] is based on the Subscription Locator Function (SLF). The subscription locator is accessed via the Dx interface. The Dx interface is always used in conjunction with the Cx interface. The Dx interface is based on DIAMETER. Its functionality is implemented by means of the routing mechanism provided by an enhanced Diameter redirect agent, which is able to extract the Public Identity from the received requests."
Following are the aspects related to NAR that could represent a potential issue: • NAR method is SLF.
• Reference point is Dx well defined in [i.17] .
P-CSCF S-CSCF SLF HSS
1. (Mw) SIP REGISTER
2. (Dx) DIAMETER SLF QUERY
3. SLF database lookup
4. (Dx) DIAMETER SLF RESP
5. (Cx) DIAMETER QUERY
Figure 1: Example of a well defined NAR use case user identifier to HSS/UPSF resolution within the domain
5.2 Steps requiring further Investigation
Required step of investigation 1:
Motivation use cases: Which reference point shall be used between recommended NAR entity and requesting entity?
ETSI 19 ETSI TR 184 007 V2.1.1 (2008-08)
Zh Cx HSS Sh Cx
I-CSCF S-CSCF AS BSF
Dx Nn Nn Nx Nn Dh Dx SLF Dz
DNS/ ENUM Cx, Dx, Sh, Dh, Dz, Zh, – DIAMETER Nn - in 3GPP as "out of scope" mentioned Nx - not mentioned yet, but necessary for roaming user Figure 2: Examples of possible NAR entities and possible reference points
Required step of investigation 2:
Motivation use cases: Which NAR method is recommend for the appropriate use case?
Required step of investigation 3:
Motivation use cases: Indicates where the NAR functionality is required?
NAR Applications
Ot her Service Layer User subsystems profiles Cor e IM S NAR NAR PSTN/ISDN NAR Other networks User Equipment User Em u l at i on subsystem
Network Attachment Su b sy st emNAR Resource and Admission Control Su b sy st em
Transport Layer NAR Transfer Functions
Figure 3: Possible location of the NAR in the TISPAN architecture
ETSI 20 ETSI TR 184 007 V2.1.1 (2008-08)
6 Basic Structure of the Naming/Numbering Address Resolution Framework
6.1 NAR Methods - Generic Approach
The basic function of a NAR method is the context aware resolution of a string into a result which is useable by the requestor. The string or its origination itself could be an identifier, name, number or address. The NAR of identifiers like name, number or address requires a NAR architecture that consists in general of the following three parts with the appropriate functions:
• Requestor (e.g. S-CSCF, AS and MMS-Server):
- Build and send the request.
- Receive and handle the response.
• Resolution Protocol (e.g. DNS, Diameter and LDAP):
- Transport of the request and response.
- Resolution entity discovery.
• Resolution Entity (e.g. DNS, HSS/UPSF and SLF):
- Answering the request.
- Authentication and authorization of the requestor.
- Namespace Management.
For the creation and resolution of a request the following components are needed:
• Identifier, Name, Number or Address.
• A NAR method. This is the translation of a string (which may be an identifier, name, number or address) into an alternative name or address.
• Resolution Entity for the name space:
A "Resolution Entity" is an entity which is responsible to manage a particular name space. The authority of a name space can be divided into different sub segments. To achieve one to one mapping a hierarchical distribution of the authoritative responsibility of these sub segments is needed.
• Context:
To map a string to the required information it is necessary to specify a context to which the query applies.
Therefore in summary, a NAR Architecture consists of the three elements Requestor, Resolution Protocol and Resolution Entity and provides in general the functionality to resolve a string from a defined namespace into a context related result.
ETSI 21 ETSI TR 184 007 V2.1.1 (2008-08)
Resolution Requestor Resolution Entity Protocol
Creation of Request Transport Request and Answer Request El ement s: Answer Authentication & St ri ng Authority Resolution Authorization of Requestor Authority Management Namespace Context New Entri es Eval uat i on Resul t Modify Del et e
Figure 4: Generic approach on NAR
6.2 Fundamental Principles and Requirements
ITU-T describes in Y.2001 [i.6] the following Fundamental principles and requirements for name and/or numbering resolution: As a public operation network, the NGN shall meet the following requirements for the name resolution: • Reliability:
The name/number resolution system is directly related to the running of the NGN, so it should have carrier class reliability. It shall have two capabilities in the architecture. First, it should not be a single point of failure. Secondly, it should have excellent load balancing mechanisms. Good configuration and arrangement shall be conducted to meet the capacity requirements during the network planning. • Integrity:
While the name/number resolution system is directly related to the running of the public networks, it must be ensured that the name/number resolution systems will not conflict to each other and that the overall name/number translation databases will have only valid and reliable entries so that the whole system will not be affected in its integrity, especially when distributed systems are used. • Security:
The name/number resolution data are important network data that may directly impact the operation of the network, and they are also sensitive commercial data reflecting the structure and policy of the network operations. Accordingly, the name/number resolution system shall be a special system used only by this network, and certain security measures shall be in place. The security is mainly maintained by the means of user access authentication, data security, data privacy, network data synchronization and fault recovery. • Sovereignty:
While the network and the name/number resolution systems are designed to provide national and global services, it needs to be ensured that the sovereignty of an affected country to govern is not questioned.
ETSI 22 ETSI TR 184 007 V2.1.1 (2008-08)
6.3 NAR Process in TISPAN NGN
Figure 5 describes the overview on Naming/Numbering Address Resolution in NGNs.
Dial String
Process Dialed Digits
Target Name E.164 ( tel URI, SIP URI, URN)
Name/Number to SIP URI Translation
SIP URI Target Routable SIP URI
Route Determination & Selection
Hostname Target Home Operator/CP
Address Resolution
Target Network Element / User IP-Address
Figure 5: Naming/Numbering Address Resolution overview
Therefore in summary:
• "Dial String Processing": the first step is the collection of a dialled string.
• "Name/Number to SIP URI Translation": the target name is translated into a target Routable SIP URI.
• "Route determination & selection": it determines the routing information from the target Routable SIP URI towards the destination gateway (Target Home Operator/CP). The selection of appropriate outbound gateway is done through the target domain or the network element name of the transit network. The route determination can be done through the domain part of SIP URI, such domain part should be coherent with E.164 number that belong to the destination operator/CP.
• "Address Resolution" from domain names (Routable SIP URI) to an IP Addresses should be done by standard DNS means.
Due to describe how Naming/Numbering Address Resolution (NAR) aspects should be treated in NGNs deeper analyses is necessary on details of involved identifiers, components and functions.
ETSI 23 ETSI TR 184 007 V2.1.1 (2008-08)
Figure 6 shows examples of the NAR process involved identifiers components and functions more in detail.
Funct i ons Dial String
E.164 number Process Dialed Digits tel URI URN SIP URI Target Name ( tel URI, SIP URI, URN)
Other DB and translation systems Name/Number to SIP URI Translation Infrastructure ENUM
Target Routable SIP URI
Route Determination DNS
Routing DB Target Home Operator/CP i.e. oubound Gateway Route Selection
IP “Static“ policy DB (i.e. port selection) Target/Transit Network Element
Routable SIP URI
HLR/HSS Address Resolution DNS
Target Network Element/User IP-Address
Figure 6: NAR abstraction in NGNs
Dial String Processing
The first function is the collection and processing of a dial string. For user interfaces where the user enters a sequence of digits to identify a called party or service, these digits are transmitted as dial string to the NGN and. processed to a target name. The user may also enter an alias (e.g. "Fred") and the terminal translates it into a dial string.
When the user enters a dial string (either directly or via an alias) and the terminal translates this into a target name, or when the user enters a target name direct, the dial string processing is skipped and the next function (Name/Number to Address Translation is invoked directly.
The Dial String is transmitted in the Request URI from the terminal to the home network as defined in RFC 4967 [i.22]: sip:nnnnn;[email protected];user=dialstring
The home provider analyses the Dial String according to the phone-context parameter and/or the user profile and translates the Dial String to a target name.
The target name could either be:
a) A tel URI as a global number (an international E.164 number), e.g. tel: +44nnnnnnn to be processed further with I-ENUM in the next step.
ETSI 24 ETSI TR 184 007 V2.1.1 (2008-08)
b) A tel URI as a local number with a phone context to be processes with an AS, e.g. tel: nnnnnn; phone- context=private VPN.
Name/Number to SIP URI Translation
Once the target name has been identified, the next step is the translation of this target name to an address. This processing could be done inside or outside the domain of the caller. The output of the resolution/translation is an address in the form of a SIP URI or tel URI to be contained in the Request-URI.
The SIP URI may either be an Address-of-Record (AoR) in the format:
a) sip:[email protected] or
b) sip:[email protected];user=phone or a SIP URI which contains a domain name which identifies an ingress point to the destination network, in the format
sip:[email protected];user=phone
NOTE: In some networks, the domain part of the AoR may contain sub-domain information related to the structure of the serving CP's network.
The tel URI is an E.164 number, indicating that the end-point can only be reached via the PSTN. In some networks it may contain further information such as a routing number or a NP dip indicator see RFC 4694 [i.23].
The Routable SIP URI is the result of the SIP URI translation.
Route Determination
The next step in the processing of the request is route determination. This process takes the address (SIP URI or tel URI) and from it, determines the routing information towards the target.
Both in case of a Tel URI or SIP URI the result could be the route to a GW to the PSTN, an IMS domain or other NGN.
If the AoR is in the same IMS domain, the S-CSCF (originating) forwards the INVITE to the I-CSCF (SLF/UPSF) to determine the hosting (terminating) S-CSCF of the destination.
If the AoR is in a domain not served by the home IMS, the S-CSCF needs to determine how to route the call towards the target CP possibly via a transit network provider.
Route Selection
Based on the target home domain name and based on the routing policy within the S-CSCF, the S-CSCF needs to find out the function (DNS or Routing DB) to be able to determine the egress element name towards the target domain.
NOTE: If the foreign domain cannot be reached directly, or cannot be accessed, the call needs to be routed via a transit provider or via the PSTN/ISDN. Routing to the PSTN/ISDN is only possible if the target address is given as tel URI or as SIP URI with user=phone.
Address Resolution
The Address Resolution from domain names (network element names) to IP Addresses should be done by standard DNS means.
For instance the address resolution from user names (SIP URI) belonging to the IMS domain into UE IP addresses should be done by standard processes within this IMS domain. (see also e.g.: TS 124 229 [i.8]).
ETSI 25 ETSI TR 184 007 V2.1.1 (2008-08)
7 Gap-Analysis
This clause lists gaps between the current 3GPP/NGN use cases and NAR framework introduced in the present document.
Table 1: Use cases and gaps
Use case Requirement/Resolution Requesting Reference Identified Gap ID to ID entity 1 PES: find a URI on a E.164 URI PES [i.2] Open: NAR method, dialled number reference point between PES and NAR 2 PES: Number E.164 Next hop PES [i.2] Open: Common NGN Portability (NP) routing approach on NP, NAR information method, reference point between PES and NAR 3 IMS Number E.164 SIP URI IMS [i.5] Open: reference point Portability (NP) between IMS and NAR, TCAP protocol in IMS 4 IMS: URI of the Tel URI in the SIP URI S-CSCF [i.5] Well defined in 3GPP incoming INVITE to IMS domain S-CSCF contains a Tel Tel URI not in SIP URI S-CSCF [i.5] No recommendation for the URI the IMS reference point between IMS domain and DNS/ENUM 5 Application server Tel URI SIP URI AS [i.5] No recommendation for the (AS): where the target reference point between AS identifier is a Tel URI and DNS/ENUM 6 Push to talk over FFS [i.5] Open: NAR method, Cellular (PoC) reference point between PoC server and NAR 7.1 MMS MSISDN MCC, MNC MMS [i.10] and [i.20] defined by GSMA in IR67 interconnection (E.164) Relay/Server [i.20], Option1 mms.mnc
ETSI 26 ETSI TR 184 007 V2.1.1 (2008-08)
Use case Requirement/Resolution Requesting Reference Identified Gap ID to ID entity 12: IMS E.164 server name I-CSCF of the [i.19] Resolution of the of the Interconnection number of of the target originating target (user) name into determination of the the target S-CSCF; IP network target network element address of the target Address of identifiers is open S-CSCF the target S-CSCF 13: IMS Roaming NAI server name I-CSCF of the [i.5] Configuration of network determination of the of the home visited element addresses of address of the home S-CSCF; IP network roaming partners in the S-CSCF Address of HSS/UPSF is not practicable the home and also open in the case of S-CSCF non ISIM registration 14: User Identifier to IMSI server name I-CSCF, [i.18] Well defined, BSF asks per HSS/UPSF resolution S-CSCF, AS, Diameter the HSS/UPSF BSF
7.1 Concept of NAR to support/enable Use Cases
• It would be very helpful for NGN developers and operators to find recommendations how to tackle the issue of translation of identifiers in NGNs as a whole.
• A common understanding on Naming, Numbering, and Address Resolution in ETSI TISPAN would provide benefits for NGN operators in interconnection between and also in interworking with other networks and services.
• By introducing the NAR framework the gaps identified through the use cases would to be closed.
7.2 Reference Points/Interfaces between NAR and Network Elements
• The types of protocols to be used between requesting entities and NAR entities are unclear.
• The current state of technologies provides a diversity of possible models and solutions (e.g. UPSF, SLF, DNS, ENUM, AS, etc.) for translation between the various types of identifier.
7.3 Introduction of a Network Function NAR
Through the analysis undertaken and the review of the NAR requirements identified, any remaining gaps can be closed such as:
• The need to define a logical network element in TS 182 006 [i.24].
• The need to describe the impact on the existing NGN NEs and network architecture.
8 Conclusions
Based on the gap analysis from use cases on NAR, the following steps are proposed:
• NAR is introduced as an element within the functional TISPAN architecture.
• Reference points/ Interfaces between NAR and other NGN architecture components should be specified.
• Further work is undertaken to introduce the NAR function within the architecture.
ETSI 27 ETSI TR 184 007 V2.1.1 (2008-08)
Annex A (informative): Bibliography
Draft ITU-T Recommendation E.IDs-DEF (Version November 2007): "Definitions of terms used for identifiers (names, numbers, addresses and other identifiers) in electronic communications networks".
ETSI 28 ETSI TR 184 007 V2.1.1 (2008-08)
History
Document history V2.1.1 August 2008 Publication
ETSI