Download V1.0.0 vom 15.10.2014

Unterarbeitskreis Signalisierung
Specification
of the
NGN-Interconnection Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Verabschiedet in der 150. Tagung des AKNN am 14.10.2014
Herausgegeben vom Arbeitskreis für technische und betriebliche Fragen der
Nummerierung und Netzzusammenschaltung (AKNN)
Erarbeitet vom Unterarbeitskreis Signalisierung (UAK-S)
Editor:
Stefan Krämer
DB Netz AG
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
E-Mail:
[email protected]
Seite 1 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
0 Content
0
Content ..................................................................................................................................... 2
1
History ....................................................................................................................................... 6
2
Foreword ................................................................................................................................... 7
3
Scope........................................................................................................................................ 7
4
References ............................................................................................................................... 8
4.1 References (normative) ...................................................................................................................... 8
4.1.1
Basic References ....................................................................................................................... 8
4.1.1.1
Architecture ....................................................................................................................... 8
4.1.1.2
Protocols ........................................................................................................................... 8
4.1.1.3
Numbering and Addressing .............................................................................................. 9
4.1.1.4
Simulation Services........................................................................................................... 9
4.1.1.5
Emulation Services ......................................................................................................... 10
4.1.1.6
Emergency Calls ............................................................................................................. 11
4.2 References (informative) .................................................................................................................. 11
4.2.1
Architecture .............................................................................................................................. 12
4.3 National References ......................................................................................................................... 12
5
Definitions and Abbreviations ................................................................................................. 13
5.1 Definitions..................................................................................................................................... 13
5.1.1
Nature of SIP ........................................................................................................................... 13
5.1.1.1
SIP................................................................................................................................... 13
5.1.1.2
IC-SIP(m) ........................................................................................................................ 13
5.1.1.3
IC-SIP(o) ......................................................................................................................... 13
5.1.1.4
SIP(n/a) ........................................................................................................................... 14
5.1.2
Reference Points of Interfaces ................................................................................................ 14
5.1.3
Trust Domain and Topology Hiding ......................................................................................... 14
5.1.4
P-Asserted-Identity .................................................................................................................. 14
5.2 Abbreviations ............................................................................................................................... 14
6
Architecture............................................................................................................................. 14
6.1
6.2
7
Ic-Interface ................................................................................................................................... 15
Iz-Interface ................................................................................................................................... 15
Numbering and Addressing at the Ic-Interface ....................................................................... 16
7.1 Format of SIP URIs .......................................................................................................................... 16
7.1.1
Global Number Format ............................................................................................................ 16
7.1.2
SIP Request URI ..................................................................................................................... 16
7.1.2.1
Number Portability ...................................................................................................... 16
7.1.2.2
Emergency Calls (Notruf) ........................................................................................... 17
7.1.2.2.1 PSAP in PSTN Technology ....................................................................................... 17
7.1.2.2.2 PSAP in NGN Technology ......................................................................................... 17
7.1.2.3
Harmonised Numbers for Harmonised Services of Social Value (Harmonisierte
Dienste von sozialem Wert) ......................................................................................................... 18
7.1.2.4
Authority Bureau Call (Einheitlicher Behördenruf) ...................................................... 18
7.1.2.5
Directory Enquiries (Auskunft) .................................................................................... 19
7.1.2.6
Tollfree Callback Service for Directory Enquiries (Entgeltfreie Rückrufnummer für
Vermittlungsdienste) .................................................................................................................... 19
7.1.2.7
International Freephone Services ............................................................................... 19
7.1.2.8
International Service Numbers ................................................................................... 19
7.1.2.9
Test numbers for Carrier Selection Calls.................................................................... 20
7.1.3
P-Asserted-Identity Header Field............................................................................................. 20
7.1.4
From Header Field ................................................................................................................... 20
7.1.5
To Header Field ....................................................................................................................... 20
7.1.6
History-Info Header Field ......................................................................................................... 20
7.2 Routing of SIP Requests .................................................................................................................. 20
7.2.1
Scenario 1: Termination........................................................................................................... 21
7.2.2
Scenario 2a: Determination of the Destination Network is not possible in the A-Domain ....... 22
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 2 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
7.2.3
Scenario 2b: Determination of the Destination Network is possible in the A-Domain, but there
is no Traffic Relation to the Destination Domain ................................................................................... 23
7.3 Charged / Non Charged Telephone Traffic ...................................................................................... 24
7.4 Mobile Service Prefix (Mobilfunkservicevorwahl) ............................................................................. 24
7.4.1
Introduction .............................................................................................................................. 24
7.4.2
Definition .................................................................................................................................. 24
7.4.3
Transmission............................................................................................................................ 24
7.5 Service Calls handed over from International Carriers .................................................................... 25
8
Ic-Profile Endorsement for ETSI TISPAN TS 124 503 ........................................................... 26
8.1
8.2
8.3
8.4
8.4.1
8.4.2
8.4.3
8.4.4
9
Global Modifications ..................................................................................................................... 26
Modifications ETSI TS 124 503 V8.3.0 ........................................................................................ 26
Modifications to 3GPP TS 24.229 ................................................................................................ 29
Profiling of ETSI TS 124 503 / 3GPP TS 24.229 ANNEX A ........................................................ 41
Supported Methods on the Ic-Interface ................................................................................... 41
Supported Status-Codes on the Ic-Interface ........................................................................... 42
Support of SIP Header on the Ic-Interface .............................................................................. 45
Supported SDP Types ............................................................................................................. 48
Simulation Services Supported for NGN-Voice-Interconnection ............................................ 51
9.1 Supported Services on the Interconnection Interface ...................................................................... 51
9.2 Description of Services ..................................................................................................................... 52
9.2.1
CDIV ........................................................................................................................................ 52
9.2.2
OIP/OIR ................................................................................................................................... 52
9.2.3
TIP/TIR..................................................................................................................................... 52
9.2.4
HOLD ....................................................................................................................................... 52
9.2.5
ACR&CB .................................................................................................................................. 52
9.2.6
ECT .......................................................................................................................................... 52
9.2.7
CONF ....................................................................................................................................... 52
9.2.8
CUG ......................................................................................................................................... 52
9.2.9
MWI.......................................................................................................................................... 52
9.2.10 MCID ........................................................................................................................................ 52
9.2.11 Call Completion........................................................................................................................ 52
9.2.12 CW ........................................................................................................................................... 53
9.2.13 UUS ......................................................................................................................................... 53
9.2.14 Emergency Calls (Notruf) ........................................................................................................ 53
10
Bearer Aspects .................................................................................................................. 54
10.1
Bearer Services ............................................................................................................................ 54
10.2
Bearer Control .............................................................................................................................. 54
10.2.1 Through Connection of the Media Path (speech/data transmission) ...................................... 54
10.2.1.1 General Remarks ........................................................................................................ 54
10.2.1.2 Scenarios described ................................................................................................... 55
10.2.1.2.1 Remarks and Symbols used .................................................................................... 55
10.2.1.2.2 Scenario 1: Connection Set-up to User Equipment B, which is Not Trusted
concerning Early Media................................................................................................................ 56
10.2.1.2.3 Scenario 2: Connection Set-up to User Equipment B, which is Trusted concerning
Early Media ................................................................................................................................. 57
10.2.1.2.4 Scenario 3: Connection Set-up with Tones/Announcements from the Transit-/
Destination Network ..................................................................................................................... 58
10.2.1.2.5 Scenario 4: Originator has an Early Media Dialogue with an IVR in the Transit-/
Destination Network ..................................................................................................................... 59
10.2.1.3 Description of the Procedures .................................................................................... 59
10.2.1.3.1 Actions required at the Origination Network ............................................................ 60
10.2.1.3.2 Actions required at an Intermediate National Network (Transit) .............................. 61
10.2.1.3.3 Actions required at the Termination Network........................................................... 63
10.2.1.3.4 Overview of the Media Handling in the Relevant Network Types ............................ 65
10.2.2 MIME Type Handling ............................................................................................................... 66
10.3
Tones and Announcements ......................................................................................................... 67
10.3.1 Actions required at the Origination Network ............................................................................ 67
10.3.2 Actions required at an Intermediate National Network (Transit).............................................. 67
10.3.3 Actions required at the Terminating Network .......................................................................... 67
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 3 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
10.3.4 Media Clipping ......................................................................................................................... 67
10.4
Codecs ......................................................................................................................................... 67
10.5
IP Version, IP Header Interworking and Fragmentation .............................................................. 67
11
Forward Address Signalling............................................................................................... 68
11.1
11.2
11.3
12
Variant 1: En Bloc Forward Address Signalling only ................................................................... 68
Variant 2: Multiple Invite Method in Combination with En Bloc Forward Address Signalling ...... 68
Remarks about the Usage of both Variants in Interconnection Scenarios .................................. 68
Charging Aspects .............................................................................................................. 70
12.1
12.2
12.3
Begin of Charging ........................................................................................................................ 70
End of Charging ........................................................................................................................... 70
SIP Support of Charging .............................................................................................................. 70
13
Roaming ............................................................................................................................ 70
14
Emergency Calls ............................................................................................................... 70
14.1
Requirements for Emergency Calls ............................................................................................. 70
14.2
Number Format ............................................................................................................................ 71
14.3
Transmission of Additional Information ........................................................................................ 71
14.3.1 SIP UUI Header Field .............................................................................................................. 71
14.3.1.1 General ....................................................................................................................... 72
14.3.1.2 Civic Location ............................................................................................................. 72
14.3.1.3 Geographic Location................................................................................................... 73
14.3.2 SIP Geolocation Header Field ................................................................................................. 73
14.3.2.1 General ....................................................................................................................... 73
14.3.2.2 Civic Location ............................................................................................................. 74
14.3.2.3 Geographic Location................................................................................................... 75
14.3.2.3.1 Point ......................................................................................................................... 75
14.3.2.3.2 Ellipse ....................................................................................................................... 76
14.3.2.3.3 Polygon .................................................................................................................... 77
14.3.2.3.4 Arc Band .................................................................................................................. 78
14.3.2.3.5 Description of radio cell ............................................................................................ 80
14.3.2.3.6 Mobile Radio Cell identification ................................................................................ 80
14.3.2.3.7 Confidence ............................................................................................................... 81
14.4
Exemplary Encoding ................................................................................................................ 81
14.4.1 Civic Location........................................................................................................................... 81
14.4.2 Ellipsoid Arc/Arc Band ............................................................................................................. 83
14.5
Emergency Calls for Voice Service Provider ........................................................................... 85
Annex A
A.1
A.2
Address Formats (informative) .................................................................................. 86
Number Portability........................................................................................................................ 86
Emergency Calls .......................................................................................................................... 86
Annex B
SIP/SDP MIME Type Signalling on the Ic-Interface (informative) .............................. 87
Annex C
Forward Address Signalling (informative) .................................................................. 90
C.1
General......................................................................................................................................... 90
C.2
Overlap Signalling Methods ......................................................................................................... 90
C.2.1
In-dialogue Method .................................................................................................................. 90
C.2.2
Multiple-INVITE Method........................................................................................................... 90
C.2.2.1
General ........................................................................................................................... 90
C.3
Routing Impacts ........................................................................................................................... 90
C.3.1
General .................................................................................................................................... 90
C.3.2
Deterministic Routing ............................................................................................................... 90
C.3.3
Digit Collection ......................................................................................................................... 90
Annex D
Calling Party’s Category (normative) ......................................................................... 92
Annex E
Nationally Ported International Service Numbers (informative) ................................. 94
Annex F
Abbreviations and Terms ........................................................................................... 95
F.1
F.2
Abbreviations .................................................................................................................................... 95
Terms................................................................................................................................................ 97
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 4 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Annex G
Das Mandat des UAK Signalisierung (informative).................................................... 98
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 5 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
1 History
Version
0.0.1
Date
10.03.2008
0.0.1
0.0.1
16.04.2008
19.05.2008
0.0.2
0.0.3
05.06.2008
04.08.2008
0.0.4
0.0.5
0.0.6
16.09.2008
21.10.2008
16.03.2009
0.0.7
0.0.8
0.0.9
24.08.2009
09.12.2009
26.03.2010
0.0.10
0.0.11
20.04.2010
19.08.2010
0.0.12
10.01.2011
0.0.13
22.02.2011
0.0.14
06.09.2011
0.0.15
20.10.2011
0.0.16
20.02.2012
0.0.17
0.0.18
22.03.2012
15.05.2012
0.0.19
16.08.2012
0.1.0
31.12.2012
0.1.1
05.02.2014
0.1.2
26.02.2014
0.1.3
0.1.4
0.2.0
1.0.0
07.05.2014
26.08.2014
27.08.2014
15.10.2014
Comments
First version based on the T-Com (TE33) Technische Richtlinie 163TR 25
(Draft), Version 1.0.2 / 10th September 2007
89. UAK-S: Mandatory SDP lines marked yellow in chapter 8.2.5
Results of the 90. UAK-S worked in:
- working document WD-90-1 added as informative annex B
- changes in chapter 4 resulting from WD-90-2 added
AKNN mandate added in chapter 3
First UAK-S internal distributed version
Document changed during 91. UAK-S meeting on 20th May 2008
Chapter 2, 3 and 5.1.1 modified during 92. UAK-S meeting added to the
document
Document changed during 94. UAK-S meeting on 16th September 2008
Document changed during 95. UAK-S meeting on 21th October 2008
Document changed during 99. UAK-S meeting on 12th February 2009
and during editorial meeting on 11th March 2009
Changed during editorial meeting on 24th August 2009
Contributions of the UAK-S meetings 103. – 107. added
Telekom proposals for references (document 109.2) and MIME bodies
(chapter Annex B) added
Telekom´s proposal completed, editorial changes
Changes of 110th and 111th meeting added, chapter 8.4 deleted, three
options for different formats added
Changes of 112th meeting added, results of editor meeting on 20th
December 2010 and of 114. UAK-S added
Results of editor meeting on 14th February 2011 and of 115. UAK-S
added; tables 8-1, 8-4, 8-5, 8-6, 8-7, 8-8 updated according to document
UAKS_115_8_Telekom, number format of option 1 completed
(UAKS_115_21_Telekom)
Results of 130. AKNN and of UAK-S editor sessions on 11th March and
29th August 2011 added, (simulation services, references and new
address option 4 added)
Agreed review results of 120. UAK-S and results of editor session on 19th
October added, (e.g. address option 3 deleted, In-dialog Overlap
Signalling method deleted)
Agreed review results of 121. and 122. UAK-S added, proposal for
chapter 10.2.1 and 10.3 added
Received review comments discussed in 123. UAK-S and added
Results of 124. and 125. UAK-S added, options concerning encryption of
history info header added.
Results of 136. AKNN meeting added in chapter 8.4.1 (reference [66]
changed to “draft-ietf-sipcore-rfc4244bis-08.txt” and Note added).
Agreed version of 128. UAK-S meeting on 20th December 2012 in
Nürnberg. Identical in content to previous version.
Results of editor meeting on 16th December 2013 and of 134. UAK-S on
17th December 2013 added.
Changes of version 0.1.1 accepted. Agreed contributions of 135th UAK-S
on 18th February 2014 in Berlin added and marked.
Results of 136th UAK-S meeting added.
Results of 137th UAK-S meeting added.
Agreed version of 137th UAK-S meeting on 26th August 2014 in Hannover
Agreed version of 150th AKNN meeting on 14th October 2014 in Hannover
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 6 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
2 Foreword
This technical specification defines the Interconnection Interface between NGN Service Providers for the
service Voice over NGN (VoNGN) and has been produced by subworkinggroup UAK-S of AKNN.
The present document may refer to technical specifications or reports of 3GPP identities, UMTS identities,
GSM identities, ETSI identities, ITU-T identities or IETF identities. These should be interpreted as being
references to the corresponding deliverables.
3 Scope
This document provides the specification for Network-Network-Interfaces (NNI) between Next Generation
Networks (NGN) of NGN Service Providers.
For the services defined in the AKNN document “Konzept für die Zusammenschaltung von Next Generation
Networks” [[52]] this specification provides in detail the requirements for the service layer interface
(Ic-Interface) and as far as needed, requirements for the transport layer interface (Iz-Interface).
IP Multimedia Subsystem (IMS) architecture, as described in [[2]], is basically used for this specification.
The NNI (Ic) reference point for this document is described as profile definition of TISPAN, 3GPP and IETF
standards.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 7 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
4 References
The present document is based on TISPAN Release 2 specifications for NGN (see: [[1]]).
If features of higher releases or other standardization bodies are needed, this will be mentioned explicitly.
[[1]]
Draft ETSI WI 00005 V0.4.8 (2010-04):
Telecommunications and Internet converged Services and Protocols for Advanced Networking
(TISPAN); Release 2 Definition
(not yet published)
download: ftp://docbox.etsi.org/TISPAN/Open/NGN_LATEST_DRAFTS/RELEASE2/
Editorial note:
The internal references in this specification are noted in double brackets [[x]]. The format of imported
reference lists in chapter 8 are not changed and noted in single brackets [y].
4.1 References (normative)
The following references apply in case bilateral agreements exist to support the corresponding
functionalities.
4.1.1 Basic References
4.1.1.1 Architecture
[[2]]
ETSI TS 123 517 V8.0.0 (2007-12): Digital cellular telecommunication system (Phase 2+);
Universal Mobile Telecommunication System (UMTS); Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN); IP Multimedia
Subsystem (IMS); Functional Architecture
(3GPP TS 23.517 version 8.0.0 Release 8)
4.1.1.2 Protocols
Within the framework of interconnection between NGNs, the specification ETSI ES 283 003 is applicable as
Call Control Protocol for the NGN service VoNGN:
[[3]]
ETSI TS 124 503 V8.3.0 (2009-01):
Digital cellular telecommunication system (Phase 2+); Universal Mobile Telecommunication
System (UMTS); LTE;TISPAN;
IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session
Description Protocol (SDP) Stage 3 [3GPP TS 24.229 (Release 7), modified]
(3GPP TS 24.503 version 8.3.0 Release 8)
For handling of overlap signalling in IBCF Annex N and related Chapter 4.9.2 of [[4]] are applicable.
For handling of the rn-Parameter chapters 5.3.2.1, 5.4.3.2, 5.5.1 and 5.6.2 of [[4]] are applicable.
[[4]]
3GPP TS 24.229 (V9.6.0) (2010-12):
"3rd Generation Partnership Project; Technical Specification Group
Core Network and Terminals; IP multimedia call control protocol based on Session Initiation
Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 9)"
[[5]]
IETF RFC 791 (September 1981): Internet Protocol
[[6]]
IETF RFC 2460 (December 1998): Internet Protocol, Version 6 (IPv6) Specification
[[7]]
IETF RFC 4040 (April 2005): RTP Payload Format for a 64 kbit/s Transparent Call
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 8 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
[[8]]
IETF RFC 4694 (October 2006): Number Portability Parameters for the "tel" URI
[[9]]
IETF RFC 5009 (September 2007): Private header (P-Header) extension to the Session
Initiation Protocol (SIP) for authorization of Early Media
[[10]]
ITU-T Recommendation V.152 (November 2004): Procedures for supporting Voice-Band Data
over IP Networks
[[11]]
ITU-T Recommendation T.38 (September 2010, pre-published):
Group 3 facsimile communication over IP networks
Procedures for real-time
Further references for profiling: see chapter 8
4.1.1.3 Numbering and Addressing
[[12]]
ETSI TR 184 003 V3.1.1 (2010-06):
Portability of telephone numbers between operators for Next Generation Networks (NGN)
[[13]]
ETSI TS 184 011 V3.1.1 (2011-02):
Requirements and usage of E.164 numbers in NGN and NGCN
4.1.1.4 Simulation Services
The following Simulation Services are applicable on the interconnection Interface:
[[14]]
ETSI TS 183 008 V2.8.0 (2008-06):
Telecommunications and Internet converged Services and Protocols for Advanced Networking
(TISPAN); PSTN/ISDN simulation services; Terminating Identification Presentation (TIP) and
Terminating Identification Restriction (TIR); Protocol specification
[[15]]
ETSI TS 183 007 V2.0.0 (2008-06):
Telecommunications and Internet converged Services and Protocols for Advanced Networking
(TISPAN); PSTN/ISDN simulation services; Originating Identification Presentation (OIP) and
Originating Identification Restriction (OIR); Protocol specification
[[16]]
ETSI TS 183 004 V2.5.0 (2008-06):
Telecommunications and Internet converged Services and Protocols for Advanced Networking
(TISPAN); PSTN/ISDN simulation services: Communication Diversion (CDIV); Protocol
specification
[[17]]
ETSI TS 183 011 V 2.0.0 (2008-06):
Telecommunications and Internet converged Services and Protocols for Advanced Networking
(TISPAN); PSTN/ISDN simulation services: Anonymous Communication Rejection (ACR) and
Communication Barring (CB); Protocol specification NGN
[[18]]
ETSI TS 183 010 V2.0.0 (2008-06):
Telecommunications and Internet converged Services and Protocols for Advanced Networking
(TISPAN);NGN Signalling Control Protocol; Communication HOLD (HOLD) PSTN/ISDN
simulation services; Protocol specification
[[19]]
ETSI TS 183 005 V2.6.0 (2008-06):
Telecommunications and Internet converged Services and Protocols for Advanced Networking
(TISPAN); PSTN/ISDN simulation services: Conference (CONF); Protocol specification
[[20]]
ETSI TS 183 054 V2.2.0 (2008-06):
Telecommunications and Internet converged Services and Protocols for Advanced Networking
(TISPAN); PSTN/ISDN simulation services; Protocol specification Closed User Group (CUG)
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 9 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
[[21]]
ETSI TS 183 042 V2.1.1 (2009-01):
Telecommunications and Internet converged Services and Protocols for Advanced Networking
(TISPAN);PSTN/ISDN Simulation Services; Completion of Communications to Busy Subscriber
(CCBS), Completion of Communications by No Reply (CCNR);Protocol Specification
[[22]]
ETSI TS 183 058 V2.1.0 (2008-06):
Telecommunications and Internet Converged Services and Protocols for Advanced Networking
(TISPAN);SIP Transfer of IP Multimedia Service Tariff Information; Protocol specification
(“SIP-Charging")
[[23]]
ETSI TS 183 015 V2.1.1 (2009-04):
Telecommunications and Internet converged Services and Protocols for Advanced Networking
(TISPAN);NGN Signalling Control Protocol; Communication Waiting (CW) PSTN/ISDN
simulation services
[[24]]
ETSI TS 183 029 V2.6.0 (2008-06):
Telecommunications and Internet converged Services and Protocols for Advanced Networking
(TISPAN); PSTN/ISDN simulation services: Explicit Communication Transfer (ECT);
Protocol specification
[[25]]
ETSI TS 183 016 V2.6.0 (2008-06):
Telecommunications and Internet converged Services and Protocols for Advanced Networking
(TISPAN); PSTN/ISDN simulation services; Malicious Communication Identification (MCID);
Protocol specification
[[26]]
ETSI TS 183 006 V2.0.0 (2008-06):
Telecommunications and Internet converged Services and Protocols for Advanced Networking
(TISPAN);PSTN/ISDN simulation services; Message Waiting Indication (MWI);
Protocol specification
[[27]]
ETSI TS 124 628 V8.2.0 (2009-01):
Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications
System (UMTS); LTE; Common Basic Communication procedures using IP Multimedia (IM)
Core Network (CN) subsystem; Protocol specification
(3GPP TS 24.628 version 8.2.0 Release 8)
Note:
[[28]]
Note:
Currently there exists no separate specification for UUS.
ETSI TS 124 642 V10.3.0 (2011-06):
Digital cellular telecommunications system (Phase 2+);
Universal Mobile Telecommunications System (UMTS);
LTE;
Completion of Communications to Busy Subscriber (CCBS) and Completion of Communications
by No Reply (CCNR) using IP Multimedia (IM)Core Network (CN) subsystem;
Protocol Specification (3GPP TS 24.642 version 10.3.0 Release 10)
[[28]] is only applicable for the handling of CCNL.
4.1.1.5 Emulation Services
The support of the emulation services will be achieved by the support of the related content types in the
MIME-bodies (see Annex B).
[[29]]
IETF RFC 3204 (December 2001): MIME media types for ISUP and QSIG
Objects
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 10 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
[[30]]
ETSI TS 183 043 V2.3.1 (2009-03): Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN); IMS - based PSTN/ISDN Emulation; Stage 3
specification
[[31]]
IETF draft-ietf-bliss-call-completion-10 (May 2011): Call Completion for Session Initiation
Protocol (SIP)
[[32]]
IETF RFC 3863 (August 2004): Presence Information Data Format (PIDF)
4.1.1.6 Emergency Calls
[[33]]
IETF Draft draft-ietf-ecrit-additional-data-11: “Additional Data related to an Emergency Call” –
July 2013
[[34]]
ITU-T Recommendation Q.763: “Signalling System No. 7 – ISDN user part formats and codes” –
December 1999
[[35]]
ITU-T Recommendation Q.931: “Digital subscriber Signalling System No. 1 – Network layer” –
May 1998
[[36]]
IETF RFC 5139: “Revised Civic Location Format for Presence Information Data Format Location
Object (PIDF-LO)” – February 2008
[[37]]
IETF RFC 5491: “GEOPRIV Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations” – March 2009
[[38]]
3GPP TS 23.032 V11.0.0 (2012-09): “3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; Universal Geographical Area Description
(GAD) (Release 11)”
[[39]]
3GPP TS 23.003 V11.5.0 (2013-03): “3rd Generation Partnership Project; Technical
Specification Group Core Network and Terminals; Numbering, addressing and identification
(Release 11)”
[[40]]
OGC 06-142r1 V1.0 (2007-04-10): “Open Geospatial Consortium Inc; GML 3.1.1 PIDF-LO
Shape Application Schema for use by the Internet Engineering Task Force (IETF)”
[[41]]
IETF Draft draft-thomson-geopriv-confidence-03: “Expressing Confidence in a Location Object”
– October 2010
[[42]]
IETF Draft draft-thomson-geopriv-uncertainty-07: “Representation of Uncertainty and
Confidence in PIDF-LO” – March 2012
4.2 References (informative)
References mentioned in this document (informative):
[[43]]
3GPP TS 24.229 V7.9.0 (2007-09):
3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals;
IP multimedia call control protocol based on Session Initiation Protocol (SIP)
and Session Description Protocol (SDP); Stage 3
(Release 7)
[[44]]
3GPP TS 24.229 V9.6.0 (2010-12):
3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals;
IP multimedia call control protocol based on Session Initiation Protocol (SIP)
and Session Description Protocol (SDP); Stage 3
(Release 9)
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 11 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
[[45]]
3GPP TS 29.165 V9.6.0 (2011-03):
3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals;
Inter-IMS Network to Network Interface;
(Release 9)
[[46]]
3GPP TS 29.162 V8.4.0 (2010-09):
3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals;
Interworking between the IM CN subsystem and IP networks
(Release 8)
[[47]]
3GPP TS 29.163 V8.24.0 (2013-12):
3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals;
Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit
Switched (CS) networks
(Release 8)
[[48]]
ETSI TS 183 047 V2.2.0 (2008-06):
Telecommunications and Internet converged Services and Protocols for Advanced Networking
(TISPAN); PSTN/ISDN simulation services; Protocol specification AoC
(“UNI-Interface”)
[[49]]
ETSI TS 129 527 V8.3.0 (2009-04): Digital cellular telecommunication system (Phase 2+);
Universal Mobile Telecommunication System (UMTS); TISPAN;
[Endorsement of the SIP-ISUP interworking between the IP Multimedia (IM) Core Network (CN)
subsystem and Circuit Switched (CS) networks [3GPP TS 29.163 (Release 7), modified ]
(3GPP TS 29.527 version 8.3.0 Release 8)
Note:
This reference is used for identifying the PSTN MIME-body.
4.2.1 Architecture
[[50]]
ETSI ES 282 001 V2.0.0 (2008-03):
Telecommunications and Internet converged Services
and Protocols for Advanced Networking (TISPAN);
NGN Functional Architecture
[[51]]
ETSI ES 282 010 V2.0.6 (2008-04):
Telecommunications and Internet converged Services
and Protocols for Advanced Networking (TISPAN); Charging management
[Endorsement of 3GPP TS 32.240 Release 7, 3GPP TS 32.260 Release 7, 3GPP TS 32.297
Release 7, 3GPP TS 32.298 Release 7 and 3GPP TS 32.299 Release 7 modified]
4.3 National References
[[52]]
AKNN UAK-NGN: Konzept für die Zusammenschaltung von Next Generation Networks,
V2.0.0, 31.03.2009
[[53]]
Bundesnetzagentur(BNetzA): Technische Richtlinie Notruf (TR-Notruf), Version 1.0 – June 2011
[[54]]
Vfg Nr. 14/2013 der Bundesnetzagentur: § 108 Telekommunikationsgesetz (TKG) in Verbindung
mit § 7 Absatz 7 Verordnung über Notrufverbindungen (NotrufV); hier: Erweiterung der
Standortbeschreibungsformen in der Technische Richtlinie Notrufverbindungen (TR Notruf) –
April 2013
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 12 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
5 Definitions and Abbreviations
5.1 Definitions
5.1.1 Nature of SIP
SIP is basically used to exchange signalling information on the UNI and NNI and among them. This
document considers only SIP Signalling Information that is exchanged on the NNI. Please refer to following
Figure 5-1. The NNI is the Ic-Interface per ETSI TISPAN ES 282 001 as outlined in section 6 of this
document.
NGN
network
A
ETSI
TISPAN
NGN Rel. 2
SIP
SIP (n/a)
SIP (n/a)
IC-SIP (o)
IC-SIP (o)
IC-SIP
IC-SIP (m)
IC-SIP (m)
NGN
network
B
ETSI
TISPAN
NGN Rel. 2
SIP
NGN-InterconnectionInterface (Ic, NNI)
n/a not applicable
o
optional
m
mandatory
.
Figure 5-1: SIP at the NNI between NGN providers
5.1.1.1 SIP
See reference [[3]]
For the purpose of this specification standard SIP is divided up in SIP that is relevant for interconnection
(IC- SIP (m) /IC-SIP (o)) between NGN operators / service providers and SIP that is (currently) not used on
the Ic-Interface (SIP (n/a)).
5.1.1.2 IC-SIP(m)
IC-SIP(m) := Interconnection-SIP (mandatory)
This is the basic set of methods, status codes and headers that must be supported by every NGN operator
on the Ic-Interface. The mandatory methods can be found in Table 8-5, the mandatory status codes are
listed in Table 8-6 and the mandatory headers are detailed in Table 8-7.
5.1.1.3 IC-SIP(o)
IC-SIP(o) := Interconnection-SIP (optional)
These are methods, status codes and headers that may additionally be supported on the Ic-Interface by
NGN operators on basis of mutual agreements. The optional methods can be found in Table 8-5, the
optional status codes are listed in Table 8-6 and the optional headers are detailed in Table 8-7.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 13 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
5.1.1.4 SIP(n/a)
SIP(n/a) := SIP (not applicable)
These are methods, status codes and headers that are currently not supported on the Ic-Interface by NGN
operators. They may however be used inside the NGN of an NGN service provider/operator. The not
applicable methods can be found in Table 8-5, the not used status codes are listed in Table 8-6 and the not
applicable headers are detailed in Table 8-7.
5.1.2 Reference Points of Interfaces
For the purposes of the present document the following reference points apply:
Ic
Reference Point between IBCF of different NGN domains
Iz
Reference Point between I-BGF of different NGN domains
5.1.3 Trust Domain and Topology Hiding
The interconnected networks as described in this document are seen as “Trust domain” as described
in [[3]], chapter 4.4.
Therefore based on bilateral contracts it shall be possible to exchange sensitive headers (P-Headers)
between interconnection partners. In a destination network it shall be guaranteed by the operator that terms
and conditions of privacy values shall be followed in correspondence to [33] and [34].
The use of Topology Hiding (THIG) is optional and is dependent on network policies.
However THIG and Trust Domain are independent features.
5.1.4 P-Asserted-Identity
The transmission of a trusted identity in form of a calling party number in the SIP header field P-AssertedIdentity among interconnection partners is mandatory. The originating network shall ensure that the
subscriber’s information in the P-Asserted Identity (user part and host portion) are verified, screened and
hence can uniquely be assigned to a certain subscriber. The P-Asserted-Identity Header shall be set up by
the originating network operator and shall be transmitted transparently through the networks.
For calls originating from a circuit switched network, the P-Asserted-Identity Header is set up in general
from the interworking network.
Note: For calls originating from Circuit Switched Networks carrying no or an incomplete CLI (see [[47]],
Table 12 ) or for international calls, a P-Asserted-Identity SIP Header Field needs not necessarily be
present.
For the format of a P-Asserted-Identity Header, please refer to sub-clause 7.1.3.
Note: In the future case of a roaming mobile customer, the domain of the P-Asserted-Identity Header
needs not necessarily match the domain of the originating network operator (VPLMN).
5.2 Abbreviations
see: [[3]] resp. [[4]], subclause 3.2
6 Architecture
For the service VoNGN it is assumed that the interconnection carriers are using the IP Multimedia
Subsystem (IMS) as Control Subsystem as described in [[50]], chapter 7.2.2 figure 7.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 14 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Iw
Ib
Service Cont rol Subsyst ems
IWF
IBCF
IBCF
Ic
Service Layer
To/From
ot her
IP net works
Transport Layer
Transport cont rol
Transport processing
I-BGF
Iz
Figure 6-1: NGN Interconnection, see [[50]], chapter 7.2.2, figure 7
The Iw-Interface and the IWF are not part of this specification.
6.1 Ic-Interface
The Ic-Interface shall be used for interconnection with other VoNGN operators at the service layer level.
6.2 Iz-Interface
The Iz-Interface shall be used for interconnection with other VoNGN operators at the transport layer level.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 15 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
7 Numbering and Addressing at the Ic-Interface
7.1 Format of SIP URIs
For the purpose of interconnection the URI format of a SIP URI shall be used. The userpart is formatted as
specified within RFC 3966 (reference [22]).
The SIP URI is marked with "user = phone".
The "alias format" for SIP URI is not allowed at the NNI (Ic).
Notes:
1)
2)
3)
4)
Currently the "alias format" for a SIP-URI is not supported
The following formats can occur in combination (e.g. ported international service number)
The set up of telephone numbers shall be done in accordance with regulatory requirements.
DNS forward lookups for the SIP URI’s <hostportion> (e.g. operator.de) do not have to be
supported by the domain owner (e.g. operator.de).
Editorial remark: In the following examples blanks are included due to a better readability.
7.1.1 Global Number Format
The global-number format as specified in chapter 5.1.4 of RFC 3966 [22] for a SIP URI using
E.164-numbers is defined as follows:
sip: +<CC> <NDC> <SN> @ <hostportion>; user=phone
with:
CC:
NDC:
SN:
Country Code
National Destination Code
Subscriber Number
Example:
sip: +49 30 12345678 @ operator.de; user=phone
7.1.2 SIP Request URI
For a SIP Request URI, the global number format according to clause 7.1.1 shall be used.
However, for certain call scenarios as described in the following sub-clauses the transmission of additional
routing information is necessary.
To route calls including additional information like hexadecimal digits (e.g. calls to PSAPs or ported
destinations) the use of the rn-Parameter [[8]] is mandatory, since the use of hexadecimal digits in the
Request-URI using the Global Number Format is not allowed.
Being a TEL-URI parameter the rn-parameter shall be used before the "@" in the user part of a
Request-URI (see also Annex A of this specification).
If an rn-Parameter is available in a SIP Request URI, its evaluation shall take precedence in the user part.
7.1.2.1 Number Portability
For a call with a ported destination (“Export Fall”), the following form shall be used:
sip: +<CC> <NDC> <SN> [;npdi] ;rn = +<CC> D<xyz> <NDC> <SN> @
<hostportion>; user = phone
The parameter npdi denotes that a check of the porting in the LNP database has already been done. The
porting identifier (Portierungskennung) D<xyz> denotes the target network operator.
The set up of the npdi parameter is optional but if received it shall be analysed.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 16 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
The +<CC>, <NDC>, <SN> in the Request-URI and in the rn TEL-URI parameter are of equal value.
Example:
sip: +49 6151 1234567 [;npdi] ;rn = +49 D123 6151 1234567 @ operator.de;
user = phone
7.1.2.2 Emergency Calls (Notruf)
This chapter describes the number format of an emergency call (Notruf) dependent on the technology
(NGN and PSTN, respectively) of the Public Safety Answering Point (Notrufabfragestelle, PSAP) and gives
an example in each case.
For the transmission of information accompanying the emergency call, please refer to clause 14.
7.1.2.2.1
PSAP in PSTN Technology
On the NNI the following format is required for emergency calls to a PSTN PSAP:
sip: +<CC> <VLN> <NDC> <x(y)>; rn = + <CC> <NDC> CC<x(y)> @ <host portion>;
user=phone
For the so called directory number (the part of the Request-URI before the (rn-)Parameter(s)), the
normalized PSAP encoding into global number format with stripped hex-CC and added routing number
(“Verkehrslenkungsnummer”, VLN) (0)1982 between CC and NDC shall be used. Please note also the
difference between the abbreviation <CC> denoting the country code and the hexdigits CC in the encoding
of the PSAP.
The use of the rn-Parameter is necessary, since the encoding of the PSAP contains hexadecimal digits.
An exemplary SIP Request URI is shown below:
sip: +49 1982 911 21; rn = +49 911 CC21 @ telekom.de; user=phone
Please note that the VLN (0)1982 has not yet been assigned by the BNetzA. As an interim solution until the
VLN has finally been allocated, the <VLN> in the directory number could also be omitted.
7.1.2.2.2
PSAP in NGN Technology
On the NNI the following format is required for emergency calls to an NGN PSAP:
sip: +<CC> <VLN> <NCbnetza> @ <host portion>; user=phone
The number NCbnetza will be assigned by BNetzA in conjunction with the coding of the destination PSAP
access line. Also, due to limitations in the existing PSTN technology, the length of such a PSAP number
(VLN and NCbnetza) may be 12 digits (including the leading “0”) at the most. This is to ensure that an
NGN PSAP can also be reached from PSTN customers. For the time being the length of NCbnetza is thus
limited to 7 digits.
Note: After the last ISDN switch has been shut down, the length restriction of twelve digits does not apply
anymore and the format of an NGN PSAP routing number could be revised.
The routing number (“Verkehrslenkungsnummer”, VLN) (0)1982 shall be used between Country Code and
NCbetza. Please note that the VLN (0)1982 has not yet been assigned by the BNetzA.
Note:
Details will be provided in TR Notruf (section covering the “Notrufanschlüsse in IP Technik”)
An exemplary SIP Request URI is shown below:
sip: +49 1982 4711815 @ telekom.de; user=phone
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 17 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
7.1.2.3 Harmonised Numbers for Harmonised Services of Social Value
(Harmonisierte Dienste von sozialem Wert)
The so called Harmonised Services of Social Value (HDSW) are called party numbers of the format
116xyz. On the interconnection interface the part xyz of the called number 116xyz has to be preceded by
the routing prefix (0)1987.
sip: +<CC> 1987 <xyz> @ <hostportion>; user = phone
Example:
For a call to a service to get a lost bank or credit card locked (dialled number 116116) the interconnection
format looks like:
sip: +49 1987 116 @ operator.de; user = phone
7.1.2.4 Authority Bureau Call (Einheitlicher Behördenruf)
The so called authority bureau call (Einheitlicher Behördenruf) 115 is a nationwide established service
number where the citizen’s questions with civic topics are answered.
According to BNetzA directive 38/2010, the authority bureau call was changed to a geographic destination.
Hence the global number format according to chapter 7.1.1 with 115 as subscriber number shall be used.
sip: +<CC> <NDC> 115 @ <hostportion>; user = phone
Example:
sip: +49 911 115 @ operator.de; user = phone
However, for calls originating from mobile networks, a different format including location information can
also be used. For this location information, three alternatives are suggested: NDC (ONKZ) coding,
“Allgemeiner Gemeindeschlüssel” (AGS) coding or emergency coding. These alternatives are distinguished
by a special indicator digit. For these cases the following formats shall be used:
NDC or AGS coding:
sip: +<CC> 1986 115 <y> <xxxxxxx> @ <hostportion>; user = phone
with:
y:
xxxxxxx:
Indicator Digit (0 or 1: AGS coding, 2: NDC Coding)
AGS or 3 digit NDC
Example:
sip: +49 1986 115 0 9564000 @ operator.de; user = phone
Emergency Coding:
sip: +<CC> 1986 115; rn = +<CC> 1986 115 <y> <xxxxxxx> @ <hostportion>;
user = phone
with:
y:
xxxxxxx:
Note:
Indicator Digit (3: Emergency Coding)
Emergency Coding including Hexadecimal Digits
The additional rn-Parameter is necessary since the emergency coding contains hexadecimal digits.
Example:
sip: +49 1986 115; rn = +49 1986 115 3 911CC21 @ operator.de; user = phone
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 18 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
7.1.2.5 Directory Enquiries (Auskunft)
The Directory Enquiries (“Auskunft”) is designed as follows: 118(0)xy.
The part <(0)xy> of the called number has to be preceded by the routing prefix (0)1989. The following
format shall be used:
sip: +<CC> 1989 (0)<xy> @ <hostportion>; user = phone
Example:
sip: +49 1989 33 @ operator.de; user = phone
7.1.2.6 Tollfree Callback Service for Directory Enquiries (Entgeltfreie
Rückrufnummer für Vermittlungsdienste)
The Tollfree Callback Service for Directory Enquiries (“Entgeltfreie Rückrufnummer für Vermittlungsdienste”) is designed as follows: 0118(0)xy
According to BNetzA directive 53/2011, the Tollfree Callback Service for Directory Enquiries is introduced
to the national networks. From the view of originating network operators it shall be handled in same manner
as the freephone services are handled.
sip: +49 118 (0) xy @ <hostportion>; user = phone
Example:
sip: +49 118 10 @ operator.de; user = phone
For this procedure the CDIV service according to [[16]] shall be used. Additionally the `From´ header can
be set to the number of the toll free callback service.
7.1.2.7 International Freephone Services
For the International Freephone Service (IFS) the following format shall be used:
sip: +<CC> 1988 <xy>[*z] @ <hostportion>; user = phone
Please note that additional digits *z will follow the carrier code <xy> based on bilateral agreements.
Example:
sip: +49 1988 23 54321 @ operator.de; user = phone
7.1.2.8 International Service Numbers
International service numbers (e.g. +800, +808) shall be transmitted in the following format:
sip: + <International Service Number> @ <host portion>; user = phone
This format is required in order to distinguish between International service numbers and National service
numbers.
An exemplary SIP Request URI is shown below:
sip: +800 12345678 @ operator.de; user=phone
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 19 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
7.1.2.9 Test numbers for Carrier Selection Calls
The test numbers to identify the selected carrier are allocated as follows:
(0)310: Test of Carrier Selection for long distant calls
and
(0)311: Test of Carrier Selection for short distant calls
These numbers shall be transmitted in the following format:
sip: +<CC> <Carrier Selection Test number> @ tariff.<host portion>; user=phone
including the special tariff subdomain according to sub-clause 7.3.
An exemplary SIP Request URI is shown below:
sip: +49 310 @ tariff.operator.de; user=phone
7.1.3 P-Asserted-Identity Header Field
Only Domain Names shall be used for the host portion of the P-Asserted-Identity Header Field. The user
part of the P-Asserted-Identity Header Field shall be set up as a Global Number Format as defined in
clause 7.1.1.
Optionally, a display name can also be set into the P-Asserted-Identity Header Field.
An exemplary P-Asserted-Identity Header Field is shown below:
P-Asserted-Identity: “Hans Mustermann” <sip:+49 911 1234567 @ operator.de;
user=phone>
7.1.4 From Header Field
In general, the From Header Field is screened by the originating party’s network operator and hence
carries a Global Number Format as defined in clause 7.1.1.
If the special “no screening” arrangement is used, the originating party’s network operator forwards the
From Header Field as originally set up by the end customer. Thus, the From Header Field needs not
necessarily carry a Global Number Format in this case. However, the end customer may only set up a
number he has been allocated. In this case, a trusted number set up by the originating network operator in
the P-Asserted-Identity Header Field according to clause 7.1.3 shall be transmitted alongside the From
Header Field.
7.1.5 To Header Field
No requirements are made regarding the format of the To-Header Field.
7.1.6 History-Info Header Field
For the SIP History-Info Header Field, a Global Number Format as defined in clause 7.1.1 shall be used.
7.2 Routing of SIP Requests
The domain name of the target network shall in any case be set up correctly according to RFC 3261 and
ETSI TR 184 003.
The use of host portion dependent routing is based on bilateral agreements.
In any case the transit is based on bilateral agreements.
Note:
The following call scenarios only depict exemplary codings.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 20 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
7.2.1 Scenario 1: Termination
Subscriber A is sending a call attempt to Home Network A. During the NP database dip in Home Network A
for the number dialled by Subscriber A the B-Domain was determined as Home Network of Subscriber B.
A direct interconnect between A-Domain and B-Domain exists in this scenario.
B-Domain
A-Domain
Home network B sub
Home network A-sub
+498948124812@b-domain
+493047114711@a-domain
DB
DB
B-sub
A-sub
Request-Line:
Invite sip:+498948124812@b-domain; user=phone
From: “Name“<sip: +493047114711@a-domain; user=phone>
P-Asserted-Identity: “+493047114711“ <sip:+493047114711@a-domain; user=phone>
To: < sip:+498948124812@a-domain; user=phone >
Remark: Only the Request URI will be used for the routing.
Figure 7-1: Scenario 1: Termination
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 21 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
7.2.2 Scenario 2a: Determination of the Destination Network is not
possible in the A-Domain
In case of transit situations, where based on bilateral agreements the transiting network will perform a
number portability query to determine the FQDN of the destination, the originating network will use the
domain name of this transit network to set up the request (scenario 2a).
A-Domain
B-Domain
Home Network A-sub
+493047114711@a-domain
Home Network B-sub
P-Domain *1
DB
+498948124812@b-domain
DB
DB
B-sub
A-sub
Request-Line:
Request-Line:
Invite sip:+498948124812@p-domain; user=phone
Invite sip:+498948124812@b-domain; user=phone
From: “Name“<sip: +493047114711@a-domain; user=phone>
From: “Name“<sip: +493047114711@a-domain; user=phone
P-Asserted-Identity: “+493047114711 “
P-Asserted-Identity: “+493047114711 “
<sip:+493047114711@a-domain; user=phone>
To: < sip:+498948124812@a-domain; user=phone >
<sip:+493047114711@a-domain; user=phone>
To: < sip:+498948124812@a-domain; user=phone >
Remark: Only the Request URI will be used for the routing.
*1 The P-Domain determines the home network of the B-Subscriber with a database query. There exist bi-/trilaterale
agreements beween A-, P- and B-domain concerning the transfer of these connections.
Figure 7-2: Scenario 2a: Determination of the Destination Network is not possible in the A-Domain
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 22 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
7.2.3 Scenario 2b: Determination of the Destination Network is
possible in the A-Domain, but there is no Traffic Relation
to the Destination Domain
P-Domain is receiving a call attempt from A-Domain directed to B-Domain in order to transmit this request
based on Hostportion Dependent Routing.
During the NP database dip in Home Network A for the Number dialled by Subscriber A the B-Domain was
determined as Home Network of Subscriber B. A direct interconnect between A-Domain and B-Domain
does not exist in this transit scenario. Based on bilateral agreements A-Domain is using P-Domain as
transit in order to reach B-Domain.
A-Domain *1
Home Network A-sub
+493047114711@a-domain
B-Domain
Home Network B-sub
P-Domain *1
DB
+498948124812@b-domain
DB
DB
B-sub
A-sub
Request-Line:
Request-Line:
Invite sip:+498948124812@b-domain; user=phone
Invite sip:+498948124812@b-domain; user=phone
From: “Name“<sip: +493047114711@a-domain; user=phone>
From: “Name“<sip: +493047114711@a-domain; user=phone
P-Asserted-Identity: “+493047114711 “
P-Asserted-Identity: “+493047114711 “
<sip:+493047114711@a-domain; user=phone>
To: < sip:+498948124812@a-domain; user=phone >
<sip:+493047114711@a-domain; user=phone>
To: < sip:+498948124812@a-domain; user=phone >
*1 The P-Domain determines the home network of the B-Subscriber with a database query.
There exist bi-/trilateral agreements beween A-, P- and B-Domain concerning the transfer of these connections.
Figure 7-3: Scenario 2b: Determination of the Destination Network is possible in the A-Domain, but there is
no Traffic Relation to the Destination Domain
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 23 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
7.3 Charged / Non Charged Telephone Traffic
There is a need to distinguish between charged and non charged traffic. Charged traffic means that a
connection is charged by the originating network carrier (TNB). Non charged traffic means that a
connection has to be charged by the selected carrier (VNB).
For non charged traffic, an additional marking “tariff.” in the beginning of the host portion of the
SIP Request URI shall be used. An exemplary SIP Request URI is shown below:
sip: + 49 911 1234567 @ tariff.operator.de; user = phone
For charged traffic, no marking shall be used, e.g.
sip: +49 911 1234567 @ operator.de; user=phone
This additional marking shall only be used for carrier selection traffic. Value added services will not be
marked, since they can be distinguished by the number range.
7.4 Mobile Service Prefix (Mobilfunkservicevorwahl)
This chapter describes the handling of the Mobile Service Prefix (Mobilfunkservicevorwahl) using a
P-Germany-Tariff header.
7.4.1 Introduction
When a number of the prefix range 0900 is dialled from a mobile network, additional tariff information is
forwarded to the VNB/SP in the PSTN. This tariff information is realised using the Mobile service prefix and
begins with the prefix C1C and is followed by two digits (tt), which include the current tariff information.
Hence such a number is of the structure:
(0) C1C tt 900 xxxxxx
This information shall also be kept for calls transported via an NGN. Therefore, a P-Germany-Tariff header
as defined in chapter 7.4.2 shall be used to transmit this information as part of an INVITE method.
7.4.2 Definition
Syntax Notation in accordance to ABNF:
P-Germany-Tariff = "P-Germany-Tariff" HCOLON
tariff
tariff = tariff-tag „=“ tariff-value
tariff-tag = „tariff“
tariff-value = 2*2 DIGIT
An exemplary SIP INVITE Request is shown below:
INVITE SIP: +49 900 [email protected]; user=phone SIP/2.0
…
P-Germany-Tariff: tariff=23
…
7.4.3 Transmission
When received in a SIP INVITE request, the P-Germany-Tariff header shall be transmitted transparently
through the networks and shall not be discarded.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 24 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
7.5 Service Calls handed over from International Carriers
To indicate that calls to certain service numbers were originally handed over at an international gateway,
the P-Germany-Tariff header field as defined in sub-clause 7.4.2 may be used. In this case the tariff-value
(“tariff cluster”) shall be set to 99.
Note: The tariff cluster 99 is not used for the Mobile Service Prefix.
An exemplary SIP INVITE Request is shown below:
INVITE SIP: +49 180 [email protected]; user=phone SIP/2.0
…
P-Germany-Tariff: tariff=99
…
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 25 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
8 Ic-Profile Endorsement for ETSI TISPAN TS 124 503
This section provides the endorsement of ETSI TISPAN TS 124 503 [[3]]. This chapter describes
modifications to reflect the supported functionalities and e.g. methods and headers applicable for the Ic
interface.
As long as no modification of the base specification 3GPP TS 24.229 [[43]] was carried out by the ETSI
endorsement TS 124 503 [[3]], the base specification [[43]] is valid with the modifications described in
chapter 8.3 of this specification.
The conditions e.g. A.x of the following tables can also be found in [[43]].
8.1 Global Modifications
The meaning of indication of the following tables is shown in Table 8-1.
Table 8-1: Meaning of Indication in the last column
Indication
Meaning
n/a
not applicable; not supported
m
mandatory; supported by sending and receiving
o
optional; may be supported based on bilateral agreements
x
prohibited/excluded; it is not allowed to use the capability
i
irrelevant; outside the scope of this specification
c<integer>
conditional; the requirement on the capability depends on the support of other
items. <integer> is the identifier of the conditional expression.
p<integer>
prerequisite
In general the base specifications defined in clause 4 are valid. An “m” in the last column of Table 8-2 to
Table 8-4 does not necessarily mean that the entire reference is valid.
8.2 Modifications ETSI TS 124 503 V8.3.0
Table 8-2: Modified Table 1 in chapter 2.1 of ETSI TS 124 503 [[3]]
References in 3GPP TS 24.229
Replaced references by ETSI TS 124 503
[2] 3GPP TS 23.002: "Network
architecture".
Relevant for UAK-S
NGN Ic Interface
ETSI ES 282 007: "Telecommunications and
Internet converged Services and Protocols for
Advanced Networking (TISPAN); IP Multimedia
Subsystem (IMS); Functional architecture" (note 1)
m
ETSI ES 282 001: "Telecommunications and
Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN Functional
Architecture Release 2" (note 1)
m
[4A] 3GPP TS 23.107: "Quality of
(note 2)
Service (QoS) concept and architecture".
n/a
[4B] 3GPP TS 23.167: "IP Multimedia
Subsystem (IMS) emergency session;
Stage 2".
ETSI TS 182 009: 'Telecommunications and
Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN
Architecture to support emergency communication
from citizen to authority' (note 1)
(note 2)
n/a
[5] 3GPP TS 23.218: "IP Multimedia
(IM) Session Handling; IM call model".
(note 2)
n/a
[6] 3GPP TS 23.221: "Architectural
requirements".
(note 2)
n/a
[4C] 3GPP TS 23.122: "Non-AccessStratum (NAS) functions related to
Mobile Station (MS) in idle mode".
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
n/a
Seite 26 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
References in 3GPP TS 24.229
Replaced references by ETSI TS 124 503
Relevant for UAK-S
NGN Ic Interface
[7] 3GPP TS 23.228: "IP multimedia
subsystem; Stage 2".
ETSI TS 182 006: "Telecommunications and
Internet converged Services and Protocols for
Advanced Networking (TISPAN); IP Multimedia
Subsystem (IMS); Stage 2 description"
m
[8] 3GPP TS 24.141: "Presence service
using the IP Multimedia (IM) Core
Network (CN) subsystem; Stage 3".
ETSI ES 283 030: "Telecommunications and
Internet converged Services and Protocols for
Advanced Networking (TISPAN); Presence Service
Capability; Protocol Specification [3GPP TS
24.141 V7.0.0, modified and OMA-TSPresence_SIMPLE-V1_0, modified]" (note 1)
n/a
[10] 3GPP TS 26.235: "Packet switched
conversational multimedia applications;
Default codecs".
ETSI TS 181 005: "Telecommunications and
Internet converged Services and Protocols for
Advanced Networking (TISPAN); Services and
Capabilities Requirements' (note 1)
n/a
[10A] 3GPP TS 27.060: "Mobile Station (note 2)
(MS) supporting Packet Switched
Services".
n/a
[11A] 3GPP TS 29.162: "Interworking
between the IM CN subsystem and IP
networks".
ETSI TS 183 021: "Telecommunications and
Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN Release 1;
Endorsement of 3GPP TS 29.162 Interworking
between IM CN Sub-system and IP networks"
(note 1)
c1
ETSI ES 283 027: 'Telecommunications and
Internet converged Services and Protocols for
Advanced Networking (TISPAN); Endorsement of
the SIP-ISUP Interworking between the IP
Multimedia (IM) Core Network (CN) subsystem
and Circuit Switched (CS) networks [3GPP TS
29.163 (Release 7), modified]' (note 1)
[14] 3GPP TS 29.228: "IP Multimedia
ETSI TS 183 033: "Telecommunications and
(IM) Subsystem Cx and Dx Interfaces;
Internet converged Services and Protocols for
Signalling flows and message contents". Advanced Networking (TISPAN); IP Multimedia;
Diameter based protocol for the interfaces between
the Call Session Control Function and the User
Profile Server Function/Subscription Locator
Function; Signalling flows and protocol details
[3GPP TS 29.228 V6.8.0 and 3GPP TS 29.229
V6.6.0, modified]" (note 1)
[15] 3GPP TS 29.229: "Cx and Dx
ETSI TS 183 033: "Telecommunications and
Interfaces based on the Diameter
Internet converged Services and Protocols for
protocol, Protocol details".
Advanced Networking (TISPAN); IP Multimedia;
Diameter based protocol for the interfaces between
the Call Session Control Function and the User
Profile Server Function/Subscription Locator
Function; Signalling flows and protocol details
[3GPP TS 29.228 V6.8.0 and 3GPP TS 29.229
V6.6.0, modified]" (note 1)
[16] 3GPP TS 32.240:
ETSI ES 282 010: "Telecommunications and
"Telecommunication management;
Internet Converged Services and Protocols for
Charging management; Charging
Advanced Networking (TISPAN); Charging
architecture and principles".
(Endorsement of 3GPP TS 32.240 Release 7, 3GPP
TS 32.260 Release 7, 3GPP TS 32.297 Release 7,
3GPP TS 32.298 Release 7 and 3GPP TS 32.299
Release 7 modified)" (note 1)
m
[11B] 3GPP TS 29.163: "Interworking
between the IP Multimedia (IM) Core
Network (CN) subsystem and Circuit
Switched (CS) networks".
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
n/a
n/a
n/a
Seite 27 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Replaced references by ETSI TS 124 503
Relevant for UAK-S
NGN Ic Interface
[17] 3GPP TS 32.260:
"Telecommunication management;
Charging management; IP Multimedia
Subsystem (IMS) charging".
ETSI ES 282 010: "Telecommunications and
Internet Converged Services and Protocols for
Advanced Networking (TISPAN); Charging
[Endorsement of 3GPP TS 32.240 Release 7, 3GPP
TS 32.260 Release 7, 3GPP TS 32.297 Release 7,
3GPP TS 32.298 Release 7 and 3GPP TS 32.299
Release 7modified]" (note 1)
n/a
[19] 3GPP TS 33.203: "Access security
for IP based services".
(note 2)
n/a
References in 3GPP TS 24.229
[67] draft-rosenberg-sipping-acr-code-00 IETF RFC 5079 (December 2007): "Rejecting
(November 2005): "Rejecting
Anonymous Requests in the Session Initiation
Anonymous Requests in the Session
Protocol (SIP)".
Initiation Protocol (SIP)".
o
[68] draft-jennings-sip-voicemail-uri-05
(November 2005): "Session Initiation
Protocol (SIP) URIs for Applications
such as Voicemail and Interactive Voice
Response (IVR)".
[69] draft-ietf-ecrit-service-urn-06
(March 2007): "A Uniform Resource
Name (URN) for Services".
[79] draft-ietf-rohc-sigcomp-sip-07
(July 2007): "Applying Signaling
Compression (SigComp) to the Session
Initiation Protocol (SIP)".
o
IETF RFC 4458: "Session Initiation Protocol (SIP)
URIs for Applications such as Voicemail and
Interactive Voice Response (IVR)" (note 1)
RFC 5031 (January 2008): "A Uniform Resource
Name (URN) for Services".
n/a
RFC 5049 (December 2007): "Applying Signaling
Compression (SigComp) to the Session Initiation
Protocol (SIP)".
n/a
[85] 3GPP2 C.S0005-D (March 2004):
"Upper Layer (Layer 3) Signalling
Standard for cdma2000 Standards for
Spread Spectrum Systems".
(note 2)
n/a
[86] 3GPP2 C.S0024-A v1.0 (April
2004): "cdma2000 High Rate Packet
Data Air Interface Standard".
(note 2)
n/a
[87] ITU-T Recommendation J.112,
"Transmission Systems for Interactive
Cable Television Services"
(note 2)
n/a
[88] PacketCable Release 2 Technical
Report, PacketCable™ Architecture
Framework Technical Report, PKT-TRARCH-FRM.
(note 2)
n/a
[89] draft-ietf-sip-location-conveyance08 (July 2007): "Session Initiation
Protocol Location Conveyance".
draft-ietf-sip-location-conveyance-10
(February 2008): "Location Conveyance for the
Session Initiation Protocol".
c2
[91] draft-ietf-ecrit-requirements-13
(March 2007): "Requirements for
Emergency Context Resolution with
Internet Technologies".
RFC 5012 (January 2008): "Requirements for
Emergency Context Resolution with Internet
Technologies".
n/a
[119] draft-garcia-simple-presencedictionary-06 (August 2007): "The
Presence-Specific Static Dictionary for
Signaling Compression (Sigcomp)".
RFC 5112 (January 2008): "The Presence-Specific
Static Dictionary for Signaling Compression
(Sigcomp)".
n/a
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 28 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
References in 3GPP TS 24.229
note 1:
note 2:
c1:
c2:
Replaced references by ETSI TS 124 503
Relevant for UAK-S
NGN Ic Interface
The reference in the first column is replaced by the document listed on the right
column. This replacement is applicable to all occurrences of the reference
throughout the present endorsement.
The reference in the first column contains 3GPP or 3GPP2 or cable specific
requirements and is not generally applicable to the present endorsement.
See chapter 10.5
See Table 8-4
8.3 Modifications to 3GPP TS 24.229
Table 8-3: Modified Chapter 2 References of 3GPP TS 24.229 [[43]]
Relevant for UAK-S
NGN Ic Interface
Reference Reference Document
umber
3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
n/a
3GPP TS 22.101: "Service aspects; Service principles".
n/a
[2]
3GPP TS 23.002: "Network architecture".
c1
[3]
3GPP TS 23.003: "Numbering, addressing and identification".
o
[4]
3GPP TS 23.060: "General Packet Radio Service (GPRS); Service
description; Stage 2".
n/a
[4A]
3GPP TS 23.107: "Quality of Service (QoS) concept and architecture".
c1
[4B]
3GPP TS 23.167: "IP Multimedia Subsystem (IMS) emergency sessions".
c1
[4C]
3GPP TS 23.122: "Non-Access-Stratum (NAS) functions related to
Mobile Station (MS) in idle mode".
c1
[5]
3GPP TS 23.218: "IP Multimedia (IM) Session Handling; IM call model".
c1
[6]
3GPP TS 23.221: "Architectural requirements".
c1
[7]
3GPP TS 23.228: "IP multimedia subsystem; Stage 2".
c1
3GPP TS 23.234: "3GPP system to Wireless Local Area Network
(WLAN) interworking; System description".
n/a
3GPP TS 24.008: "Mobile radio interface layer 3 specification; Core
Network protocols; Stage 3".
n/a
[8A]
3GPP TS 24.141: "Presence service using the IP Multimedia (IM) Core
Network (CN) subsystem; Stage 3".
c1
[8B]
3GPP TS 24.147: "Conferencing using the IP Multimedia (IM) Core
Network (CN) subsystem; Stage 3".
n/a
[1]
[1A]
[7A]
[8]
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 29 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Relevant for UAK-S
NGN Ic Interface
Reference Reference Document
umber
n/a
[8C]
3GPP TS 24.234: "3GPP System to Wireless Local Area Network
(WLAN) interworking; User Equipment (UE) to network protocols; Stage
3".
[8D]
Void.
[8E]
3GPP TS 24.279: "Combining Circuit Switched (CS) and IP Multimedia
Subsystem (IMS) services, stage 3, Release 7".
n/a
[8F]
3GPP TS 24.247: "Messaging service using the IP Multimedia (IM) Core
Network (CN) subsystem; Stage 3".
n/a
[8G]
3GPP TS 24.167: "3GPP IMS Management Object (MO); Stage 3".
n/a
3GPP TS 25.304: "UE Procedures in Idle Mode and Procedures for Cell
Reselection in Connected Mode".
n/a
[9A]
3GPP TS 25.331: "Radio Resource Control (RRC); Protocol
Specification".
n/a
[10]
3GPP TS 26.235: "Packet switched conversational multimedia
applications; Default codecs".
c1
[10A]
3GPP TS 27.060: "Mobile Station (MS) supporting Packet Switched
Services".
c1
[11]
3GPP TS 29.061: "Interworking between the Public Land Mobile
Network (PLMN) supporting Packet Based Services and Packet Data
Networks (PDN)".
n/a
[11A]
3GPP TS 29.162: "Interworking between the IM CN subsystem and IP
networks".
c1
[11B]
3GPP TS 29.163: "Interworking between the IP Multimedia (IM) Core
Network (CN) subsystem and Circuit Switched (CS) networks".
c1
[11C]
3GPP TS 29.161: "Interworking between the Public Land Mobile
Network (PLMN) supporting Packet Based Services with Wireless Local
Access and Packet Data Networks (PDN)"
n/a
[12]
3GPP TS 29.207 Release 6: "Policy control over Go interface".
n/a
[13]
Void.
[9]
[13A]
3GPP TS 29.209 Release 6: "Policy control over Gq interface".
n/a
[13B]
3GPP TS 29.212: "Policy and Charging Control over Gx reference point".
n/a
[13C]
3GPP TS 29.213: "Policy and charging control signalling flows and
Quality of Service (QoS) parameter mapping".
n/a
[13D]
3GPP TS 29.214: "Policy and Charging Control over Rx reference point".
n/a
[14]
3GPP TS 29.228: "IP Multimedia (IM) Subsystem Cx and Dx Interfaces;
Signalling flows and message contents".
c1
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 30 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Relevant for UAK-S
NGN Ic Interface
Reference Reference Document
umber
[15]
3GPP TS 29.229: "Cx and Dx Interfaces based on the Diameter protocol,
Protocol details".
c1
[16]
3GPP TS 32.240: "Telecommunication management; Charging
management; Charging architecture and principles".
c1
[17]
3GPP TS 32.260: "Telecommunication management; Charging
management; IP Multimedia Subsystem (IMS) charging".
c1
[18]
3GPP TS 33.102: "3G Security; Security architecture".
n/a
[19]
3GPP TS 33.203: "Access security for IP based services".
c1
3GPP TS 33.210: "IP Network Layer Security".
n/a
[20]
3GPP TS 44.018: "Mobile radio interface layer 3 specification, Radio
Resource Control Protocol".
n/a
[20A]
RFC 2401 (November 1998): "Security Architecture for the Internet
Protocol".
n/a
[20B]
RFC 1594 (March 1994): "FYI on Questions and Answers to Commonly
asked "New Internet User" Questions".
n/a
[20C]
Void.
[20D]
Void.
[20E]
RFC 2462 (November 1998): "IPv6 Address Autoconfiguration".
n/a
[20F]
RFC 2132 (March 1997): "DHCP Options and BOOTP Vendor
Extensions".
n/a
[21]
RFC 2617 (June 1999): "HTTP Authentication: Basic and Digest Access
Authentication".
n/a
[22]
RFC 3966 (December 2004): "The tel URI for Telephone Numbers".
c2
[23]
RFC 2833 (May 2000): "RTP Payload for DTMF Digits, Telephony
Tones and Telephony Signals".
m
[24]
RFC 3761 (April 2004): "The E.164 to Uniform Resource Identifiers
(URI) Dynamic Delegation Discovery System (DDDS) Application
(ENUM)".
n/a
[25]
RFC 2976 (October 2000): "The SIP INFO method".
c3
RFC 3041 (January 2001): "Privacy Extensions for Stateless Address
Autoconfiguration in IPv6".
n/a
[26]
RFC 3261 (June 2002): "SIP: Session Initiation Protocol".
m
[27]
RFC 3262 (June 2002): "Reliability of provisional responses in Session
Initiation Protocol (SIP)".
o
[19A]
[25A]
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 31 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Relevant for UAK-S
NGN Ic Interface
Reference Reference Document
umber
[27A]
RFC 3263 (June 2002): " Session Initiation Protocol (SIP): Locating SIP
Servers".
n/a
[27B]
RFC 3264 (June 2002): "An Offer/Answer Model with Session
Description Protocol (SDP)".
m
[28]
RFC 3265 (June 2002): "Session Initiation Protocol (SIP) Specific Event
Notification".
n/a
[28A]
RFC 3267 (June 2002): "Real-Time Transport Protocol (RTP) Payload
Format and File Storage Format for the Adaptive Multi-Rate (AMR) and
Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs".
o
[29]
RFC 3311 (September 2002): "The Session Initiation Protocol (SIP)
UPDATE method".
m
[30]
RFC 3312 (October 2002): "Integration of resource management and
Session Initiation Protocol (SIP)".
o
[31]
RFC 3313 (January 2003): "Private Session Initiation Protocol (SIP)
Extensions for Media Authorization".
n/a
[32]
RFC 3320 (March 2002): "Signaling Compression (SigComp)".
n/a
[33]
RFC 3323 (November 2002): "A Privacy Mechanism for the Session
Initiation Protocol (SIP)".
m
[34]
RFC 3325 (November 2002): "Private Extensions to the Session Initiation
Protocol (SIP) for Network Asserted Identity within Trusted Networks".
m
RFC 3326 (December 2002): "The Reason Header Field for the Session
Initiation Protocol (SIP)".
m
RFC 3327 (December 2002): "Session Initiation Protocol Extension
Header Field for Registering Non-Adjacent Contacts".
n/a
[35A]
RFC 3361 (August 2002): "Dynamic Host Configuration Protocol
(DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers".
n/a
[36]
RFC 3515 (April 2003): "The Session Initiation Protocol (SIP) REFER
method".
n/a
[37]
RFC 3420 (November 2002): "Internet Media Type message/sipfrag".
n/a
[38]
RFC 3608 (October 2003): "Session Initiation Protocol (SIP) Extension
Header Field for Service Route Discovery During Registration".
n/a
[39]
RFC 4566 (June 2006): "SDP: Session Description Protocol".
m
[40]
RFC 3315 (July 2003): "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)".
n/a
RFC 2131 (March 1997): "Dynamic host configuration protocol".
n/a
RFC 3319 (July 2003): "Dynamic Host Configuration Protocol (DHCPv6)
n/a
[34A]
[35]
[40A]
[41]
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 32 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Relevant for UAK-S
NGN Ic Interface
Reference Reference Document
umber
Options for Session Initiation Protocol (SIP) Servers".
[42]
RFC 3485 (February 2003): "The Session Initiation Protocol (SIP) and
Session Description Protocol (SDP) static dictionary for Signaling
Compression (SigComp)".
n/a
[43]
RFC 3680 (March 2004): "A Session Initiation Protocol (SIP) Event
Package for Registrations".
n/a
[44]
Void.
[45]
Void.
[46]
Void.
[47]
Void.
[48]
RFC 3329 (January 2003): "Security Mechanism Agreement for the
Session Initiation Protocol (SIP)".
n/a
[49]
RFC 3310 (September 2002): "Hypertext Transfer Protocol (HTTP)
Digest Authentication Using Authentication and Key Agreement (AKA)".
n/a
[50]
RFC 3428 (December 2002): "Session Initiation Protocol (SIP) Extension
for Instant Messaging".
n/a
[51]
Void.
[52]
draft-drage-sipping-rfc3455bis-13 (January 2014): "Private Header (PHeader) Extensions to the Session Initiation Protocol (SIP) for the 3rdGeneration Partnership Project (3GPP)".
[53]
RFC 3388 (December 2002): "Grouping of Media Lines in Session
Description Protocol".
n/a
[54]
RFC 3524 (April 2003): "Mapping of Media Streams to Resource
Reservation Flows".
n/a
[55]
RFC 3486 (February 2003): "Compressing the Session Initiation Protocol
(SIP)".
n/a
[56]
RFC 3556 (July 2003): "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth".
o
o
n/a
[56A]
RFC 3581 (August 2003): "An Extension to the Session Initiation
Protocol (SIP) for Symmetric Response Routing".
[56B]
RFC 3841 (August 2004): "Caller Preferences for the Session Initiation
Protocol (SIP)".
o
[56C]
RFC 3646 (December 2003): "DNS Configuration options for Dynamic
Host Configuration Protocol for IPv6 (DHCPv6)".
n/a
ITU-T Recommendation E.164: "The international public
telecommunication numbering plan".
m
[57]
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 33 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Relevant for UAK-S
NGN Ic Interface
Reference Reference Document
umber
o
[58]
RFC 4028 (April 2005): "Session Timers in the Session Initiation Protocol
(SIP)".
[59]
RFC 3892 (September 2004): "The Session Initiation Protocol (SIP)
Referred-By Mechanism".
n/a
[60]
RFC 3891 (September 2004): "The Session Inititation Protocol (SIP)
"Replaces" Header".
n/a
[61]
RFC 3911 (October 2004): "The Session Inititation Protocol (SIP) "Join"
Header".
n/a
[62]
RFC 3840 (August 2004): "Indicating User Agent Capabilities in the
Session Initiation Protocol (SIP)"
n/a
[63]
RFC 3861 (August 2004): "Address Resolution for Instant Messaging and
Presence".
n/a
RFC 3948 (January 2005): "UDP Encapsulation of IPsec ESP Packets".
n/a
[64]
RFC 4032 (March 2005): "Update to the Session Initiation Protocol (SIP)
Preconditions Framework".
n/a
[65]
RFC 3842 (August 2004) "A Message Summary and Message Waiting
Indication Event Package for the Session Initiation Protocol (SIP)"
o
[65A]
RFC 4077 (May 2005): "A Negative Acknowledgement Mechanism for
Signaling Compression".
n/a
[66]
RFC 7044 (February 2014): "An Extension to the Session Initiation
Protocol (SIP) for Request History Information".
Note 1:
The history information header shall not be discarded.
Note 2:
This reference shall only be used for CDIV; all other features are ffs.
m
[67]
draft-ietf-sip-acr-code-05 (July 2007): "Rejecting Anonymous Requests in
the Session Initiation Protocol (SIP)".Editor's note: The above document
cannot be formally referenced until it is published as an RFC.
c1
[68]
RFC 4458 (January 2006): "Session Initiation Protocol (SIP) URIs for
Applications such as Voicemail and Interactive Voice Response (IVR)".
c1
[69]
draft-ietf-ecrit-service-urn-06 (March 2007): "A Uniform Resource Name
(URN) for Services".Editor's note: The above document cannot be
formally referenced until it is published as an RFC.
c1
[70]
RFC 3903 (October 2004): "An Event State Publication Extension to the
Session Initiation Protocol (SIP)".
o
[71]
Void.
[72]
RFC 3857 (August 2004): "A Watcher Information Event Template
Package for the Session Initiation Protocol (SIP)".
[63A]
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
n/a
Seite 34 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Relevant for UAK-S
NGN Ic Interface
Reference Reference Document
umber
[73]
[74]
RFC 3856 (August 2004): "A Presence Event Package for the Session
Initiation Protocol (SIP)".
o
[74A]
RFC 3603 (October 2003): "Private Session Initiation Protocol (SIP)
Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed
Call Signaling Architecture".
n/a
RFC 4662 (August 2006): "A Session Initiation Protocol (SIP) Event
Notification Extension for Resource Lists".
n/a
[77]
draft-ietf-sipping-config-framework-12 (May 2007): "A Framework for
Session Initiation Protocol User Agent Profile Delivery".
Editor's note: The above document cannot be formally referenced until it
is published as an RFC.
n/a
[78]
RFC 4575 (August 2006): "A Session Initiation Protocol (SIP) Event
Package for Conference State".
c5
[79]
draft-ietf-rohc-sigcomp-sip-07 (July 2007): "Applying Signaling
Compression (SigComp) to the Session Initiation Protocol (SIP)".Editor's
note: The above document cannot be formally referenced until it is
published as an RFC.
c1
[80]
RFC 3825 (July 2004): "Dynamic Host Configuration Protocol Option for
Coordinate-based Location Configuration Information".
n/a
[81]
Void.
[82]
RFC 4457 (April 2006): "The Session Initiation Protocol (SIP) P-UserDatabase Private-Header (P-header)".
n/a
[83]
RFC 4145 (September 2005): "TCP-Based Media Transport in the Session
Description Protocol (SDP)".
n/a
[84]
RFC 4320 (January 2006): "Actions Addressing Identified Issues with the
Session Initiation Protocol's (SIP) Non-INVITE Transaction".
n/a
[85]
3GPP2 C.S0005-D (March 2004): "Upper Layer (Layer 3) Signaling
Standard for cdma2000 Standards for Spread Spectrum Systems".
c1
[86]
3GPP2 C.S0024-A v1.0 (April 2004): "cdma2000 High Rate Packet Data
Air Interface Standard".
c1
[87]
ITU-T Recommendation J.112, "Transmission Systems for Interactive
Cable Television Services"
c1
[88]
PacketCable Release 2 Technical Report, PacketCable™ Architecture
Framework Technical Report, PKT-TR-ARCH-FRM.
c1
[89]
draft-ietf-sip-location-conveyance-08 (July 2007): "Session Initiation
Protocol Location Conveyance".Editor's note: The above document
c1
[75]
[76]
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 35 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Relevant for UAK-S
NGN Ic Interface
Reference Reference Document
umber
cannot be formally referenced until it is published as an RFC.
[90]
RFC 4119 (December 2005) "A Presence-based GEOPRIV Location
Object Format".
m
[91]
draft-ietf-ecrit-requirements-13 (March 2007): "Requirements for
Emergency Context Resolution with Internet Technologies".Editor's note:
The above document cannot be formally referenced until it is published as
an RFC.
c1
[92]
draft-ietf-sip-outbound-10 (July 2007): "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)".Editor's note: The
above document cannot be formally referenced until it is published as an
RFC.
c3
[93]
draft-ietf-sip-gruu-14 (June 2007): "Obtaining and Using Globally
Routable User Agent (UA) URIs (GRUU) in the Session Initiation
Protocol (SIP)".
Editor's note: The above document cannot be formally referenced until it
is published as an RFC.
n/a
[94]
draft-ietf-sipping-gruu-reg-event-08 (October 2006): "Reg Event Package
Extension for GRUUs".
Editor's note: The above document cannot be formally referenced until it
is published as an RFC.
n/a
[95]
draft-mahy-iptel-cpc-04 (August 2006): "CPC tel URI". Editor's note: The
above document cannot be formally referenced until it is published as an
RFC.
c3
[96]
RFC 4168 (October 2005): "The Stream Control Transmission Protocol
(SCTP) as a Transport for the Session Initiation Protocol (SIP)".
n/a
[97]
draft-camarillo-sipping-profile-key-02 (June 2007): "The Session
Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header)".
[98]
ETSI ES 283 035: "Telecommunications and Internet Converged Services
and Protocols for Advanced Networks (TISPAN); Network Attachment
Sub-System (NASS); e2 interface based on the DIAMETER protocol".
n/a
[99]
draft-ietf-mmusic-ice-17 (July 2007): "Interactive Connectivity
Establishment (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols".
Editor's note: The above document cannot be formally referenced until it
is published as an RFC.
n/a
[100]
draft-ietf-behave-rfc3489bis-09 (August 2007): "Session Traversal
Utilities for (NAT) (STUN)".
Editor's note: The above document cannot be formally referenced until it
is published as an RFC.
o
[101]
draft-ietf-behave-turn-04 (July 2007): "Traversal Using Relays around
NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT
(STUN)".
Editor's note: The above document cannot be formally referenced until it
n/a
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
o
Seite 36 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Relevant for UAK-S
NGN Ic Interface
Reference Reference Document
umber
is published as an RFC.
[102]
draft-ietf-sip-ice-option-tag-02 (June 2007): "Indicating Support for
Interactive Connectivity Establishment (ICE) in the Session Initiation
Protocol (SIP)".
Editor's note: The above document cannot be formally referenced until it
is published as an RFC.
n/a
[103]
RFC 4967 (July 2007): "Dial String Parameter for the Session Initiation
Protocol Uniform Resource Identifier".
n/a
[104]
draft-ietf-sip-uri-list-message-01: "Multiple-Recipient MESSAGE
Requests in the Session Initiation Protocol (SIP)".
Editor's note: The above document cannot be formally referenced until it
is published as an RFC.
o
[105]
draft-ietf-sip-multiple-refer-01: "Referring to Multiple Resources in the
Session Initiation Protocol (SIP)".
Editor's note: The above document cannot be formally referenced until it
is published as an RFC.
n/a
[106]
draft-ietf-sip-uri-list-conferencing-01: "Conference Establishment Using
Request-Contained Lists in the Session Initiation Protocol (SIP)".
Editor's note: The above document cannot be formally referenced until it
is published as an RFC.
n/a
[107]
draft-ietf-sip-uri-list-subscribe-01: "Subscriptions to Request-Contained
Resource Lists in the Session Initiation Protocol (SIP)".
Editor's note: The above document cannot be formally referenced until it
is published as an RFC.
n/a
[108]
RFC 4583 (November 2006): "Session Description Protocol (SDP)
Format for Binary Floor Control Protocol (BFCP) Streams".
n/a
[109]
draft-ejzak-sipping-p-em-auth-04 (June 2007): "Private Header (PHeader) Extension to the Session Initiation Protocol (SIP) for
Authorization of Early Media".
Editor's note: The above document cannot be formally referenced until it
is published as an RFC.
c3
[110]
RFC 4354 (January 2006): "A Session Initiation Protocol (SIP) Event
Package and Data Format for Various Settings in Support for the Push-toTalk over Cellular (PoC) Service".
n/a
[111]
draft-allen-sipping-poc-p-answer-state-header-05 (March 2007): "The PAnswer-State Header Extension to the Session Initiation Protocol for the
Open Mobile Alliance Push to talk over Cellular".
Editor's note: The above document cannot be formally referenced until it
is published as an RFC.
n/a
[112]
Void
c3
[113]
Void.
[114]
Void.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 37 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Relevant for UAK-S
NGN Ic Interface
Reference Reference Document
umber
[115]
Void.
[116]
Void
c3
[117]
draft-ietf-sip-fork-loop-fix-05 (March 2007): "Addressing an
Amplification Vulnerability in Session Initiation Protocol (SIP) Forking
Proxies
c3
[118]
RFC 4896 (June 2007): "Signaling Compression (SigComp) Corrections
and Clarifications".
n/a
[119]
draft-garcia-simple-presence-dictionary-06 (August 2007): "The
Presence-Specific Static Dictionary for Signaling Compression
(Sigcomp)".Editor's note: The above document cannot be formally
referenced until it is published as an RFC.
c1
[120]
draft-rosenberg-sip-app-media-tag-01 (July 2007): "A Session Initiation
Protocol (SIP) Media Feature Tag for MIME Application Sub-Types".
Editor's note: The above document cannot be formally referenced until it
is published as an RFC.
m
[121]
draft-drage-sipping-service-identification-01 (July 2007): "A Session
Initiation Protocol (SIP) Extension for the Identification of Services".
Editor's note: The above document cannot be formally referenced until it
is published as an RFC.
o
c1:
c2:
c3:
c4:
c5:
see Table 8-2
The rules defined in chapter 7 are valid.
see Table 8-4
IF Table 8-5/24 OR Table 8-5/12 THEN o ELSE n/a (SUBSCRIBE, NOTIFY
Request)
IF Table 9-1/5 THEN m ELSE o (CONF)
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 38 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Additionally, the following References of 3GPP TS 24.229 [[44]] (Release 9) are required:
Table 8-4: Parts of modified Chapter 2 References of 3GPP TS 24.229 [[43]](Release 9)
Relevant for UAK-S
NGN Ic Interface
Reference Reference Document
umber
[25]
RFC 6086 (January 2011): " Session Initiation Protocol (SIP) INFO
Method and Package Framework".
o
[89]
RFC 6442 (December 2011): "Location Conveyance for the Session
Initiation Protocol"
m
[92]
RFC 5626 (October 2009): "Managing Client Initiated Connections in the
Session Initiation Protocol (SIP)".
n/a
[95]
draft-patel-dispatch-cpc-oli-parameter-03 (June 2010): "Uniform
Resource Identifier (URI) Parameters for indicating the Calling Party's
Category and Originating Line Information".
Editor's note: The above document cannot be formally referenced until it
is published as an RFC.
(Note 1)
m
[109]
RFC 5009 (September 2009): “Private Header (P-Header) Extension to
the Session Initiation Protocol (SIP) for Authorization of Early Media“
(Note 2)
o
[112]
RFC 4694 (October 2006): "Number Portability Parameters for the 'tel'
URI", see reference list in document [[4]]
c1
[116]
RFC 4412 (February 2006): "Communications Resource Priority for the
Session Initiation Protocol (SIP)".
o
[117]
RFC 5393 (December 2008): "Addressing an Amplification Vulnerability
in Session Initiation Protocol (SIP) Forking Proxies".
m
[125]
RFC 5360 (October 2008): "A Framework for Consent-Based
Communications in the Session Initiation Protocol (SIP)".
n/a
[126]
draft-ietf-cuss-sip-uui-10 (April 2013): "A Mechanism for Transporting
User to User Call Control Information in SIP".
m
[126A]
draft-ietf-cuss-sip-uui-isdn-04 (May 2012): “Interworking ISDN Call
Control User Information with SIP”
m
[133]
RFC 5502 (April 2009): "The SIP P-Served-User Private-Header (PHeader) for the 3GPP IP Multimedia (IM) Core Network (CN)
Subsystem".
n/a
[134]
draft-vanelburg-sipping-private-network-indication-02 (July 2008): "The
Session Initiation Protocol (SIP) P-Private-Network-Indication PrivateHeader (P-Header)".
Editor's note: The above document cannot be formally referenced until it
is published as an RFC.
n/a
[140]
draft-dawes-sipping-debug-02 (February 2010): "Private Extension to the
Session Initiation Protocol (SIP) for Debugging".
Editor's note: The above document cannot be formally referenced until it
is published as an RFC.
n/a
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 39 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Relevant for UAK-S
NGN Ic Interface
Reference Reference Document
umber
[158]
RFC 5373 (November 2008): "Requesting Answering Modes for the
Session Initiation Protocol (SIP)".
n/a
[162]
draft-kaplan-dispatch-session-id-00 (December 2009): "A Session
Identifier for the Session Initiation Protocol (SIP)".
Editor's note: The above document cannot be formally referenced until it
is published as an RFC.
n/a
[173]
RFC 4488 (May 2006): "Suppression of Session Initiation Protocol (SIP)
REFER Method Implicit Subscription".
n/a
c1:
only rn as global-rn and npdi parameters according to chapter 7 shall be used.
Note 1: See also Annex D.
Note 2: Usage according to clause 10.2.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 40 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
8.4 Profiling of ETSI TS 124 503 / 3GPP TS 24.229 ANNEX A
The IBCF is used as B2BUA and therefore for the profiling of TS 124 503 [[3]] / TS 24.229 [[43]] only the
role of a UA as shown in [[4]], Table A.2 is valid.
8.4.1 Supported Methods on the Ic-Interface
A Method Request (e.g. INVITE request) is the Method itself.
A Method Response is the Response (e.g. 1xx) sent as a result of a Request.
The following SIP Methods shall be supported on the NNI:
The following table is an endorsement of [[43]], Table A.5 in chapter A.2.1.3
Table 8-5: Supported Methods
Item
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
c1:
c2:
PDU
Reference in
[[43]]
Sending
ACK request
[26] 13
m
BYE request
[26] 15.1
m
BYE response
[26] 15.1
m
CANCEL request
[26] 9
m
CANCEL response
[26] 9
m
INFO request
[26] 13
c2
INFO response
[26] 13
c2
INVITE request
[26] 13
m
INVITE response
[26] 13
m
MESSAGE request
[50] 4
n/a
MESSAGE response
[50] 4
n/a
NOTIFY request
[28] 7.1.2
c1
NOTIFY response
[28] 7.1.2
c1
OPTIONS request
[26] 11
o
OPTIONS response
[26] 11
o
PRACK request
[27] 6
o
PRACK response
[27] 6
o
PUBLISH request
[70] 6
c1
PUBLISH response
[70] 5
c1
REFER request
[36] 2
n/a
REFER response
[36] 2
n/a
REGISTER request
[26] 10
n/a
REGISTER response
[26] 10
n/a
SUBSCRIBE request
[28] 7.1.1
c1
SUBSCRIBE response
[28] 7.1.1
c1
UPDATE request
[29] 5
m
UPDATE response
[29] 5
m
other requests
n/a
other response
o
IF Table 9-1/3 OR Table 9-1/5 OR Table 9-1/8 OR Table 9-1/11
THEN m, ELSE n/a (CCBS & CCNR, CONF, ECT, MWI)
IF Table 9-1/13 THEN m, ELSE n/a (SIP support of charging)
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
NNI
Receiving
m
m
m
m
m
c2
c2
m
m
n/a
n/a
c1
c1
o
o
o
o
c1
c1
n/a
n/a
n/a
n/a
c1
c1
m
m
n/a
o
Seite 41 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
8.4.2 Supported Status-Codes on the Ic-Interface
The following status-codes shall be supported on the NNI:
This table is based on [[43]], Table A.6
Table 8-6: Supported Status-Codes
Item
101
1
2
3
4
5
102
6
7
103
8
9
10
11
12
104
13
14
15
16
17
18
19
20
21
22
22A
23
24
25
26
27
Status-Code
1xx response
100 (Trying)
180 (Ringing)
181 (Call Is Being
Forwarded)
182 (Queued)
183 (Session Progress)
2xx response
200 (OK)
202 (Accepted)
3xx response
300 (Multiple Choices)
301 (Moved
Permanently)
302 (Moved
Temporarily)
305 (Use Proxy)
380 (Alternative Service)
4xx response
400 (Bad Request)
401 (Unauthorized)
402 (Payment Required)
403 (Forbidden)
404 (Not Found)
405 (Method Not
Allowed)
406 (Not Acceptable)
407 (Proxy
Authentication Required)
408 (Request Timeout)
410 (Gone)
412 (Conditional
Request Failed)
413 (Request Entity Too
Large)
414 (Request-URI Too
Large)
415 (Unsupported Media
Type)
416 (Unsupported URI
Scheme)
420 (Bad Extension)
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
[26] 21.1
[26] 21.1.1
[26] 21.1.2
[26] 21.1.3
Sending – Status
RFC
Profile NNI
p21
p21
c21
m
c2
m
c2
m
Receiving – Status
RFC
Profile NNI
p21
p21
c11
m
c1
m
c1
m
[26] 21.1.4
[26] 21.1.5
[26] 21.2
[26] 21.2.1
[28] 7.3.1
[26] 21.3
[26] 21.3.1
[26] 21.3.2
c2
c1
p22
m
c3
p23
m
m
m
m
p22
m
n/a
p23
n/a
n/a
c1
c1
p22
m
c3
p23
m
m
m
m
p22
m
n/a
p23
c22
c22
[26] 21.3.3
m
n/a
m
c22
[26] 21.3.4
[26] 21.3.5
[26] 21.4
[26] 21.4.1
[26] 21.4.2
[26] 21.4.3
[26] 21.4.4
[26] 21.4.5
[26] 21.4.6
m
m
p24
m
o
n/a
m
m
m
n/a
n/a
p24
m
n/a
n/a
m
m
m
m
m
p24
m
m
n/a
m
m
m
c22
c22
p24
m
m (Note 2)
c23 (Note 1)
m
m
m
[26] 21.4.7
[26] 21.4.8
m
o
m
n/a
m
m
m
c23 (Note 2)
[26] 21.4.9
[26] 21.4.10
[70] 11.2.1
c2
m
c20
m
m
o
m
m
c20
m
m
o
[26] 21.4.11
m
m
m
m
[26] 21.4.12
m
m
m
m
[26] 21.4.13
m
m
m
m
[26] 21.4.14
m
m
m
m
[26] 21.4.15
m
m
m
m
Ref. in [[43]]
Seite 42 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Item
28
28A
29
29A
29B
30
31
32
33
34
35
36
37
38
39
40
41
41A
105
42
43
44
45
46
47
48
49
106
50
51
52
53
Status-Code
421 (Extension
Required)
422 (Session Interval
Too Small)
423 (Interval Too Brief)
429 (Provide Referrer
Identity)
433 (Anonymity
Disallowed)
480 (Temporarily
Unavailable)
481 (Call/Transaction
Does Not Exist)
482 (Loop Detected)
483 (Too Many Hops)
484 (Address
Incomplete)
485 (Ambiguous)
486 (Busy Here)
487 (Request
Terminated)
488 (Not Acceptable
Here)
489 (Bad Event)
491 (Request Pending)
493 (Undecipherable)
494 (Security Agreement
Required)
5xx response
500 (Internal Server
Error)
501 (Not Implemented)
502 (Bad Gateway)
503 (Service
Unavailable)
504 (Server Time-out)
505 (Version not
supported)
513 (Message Too
Large)
580 (Precondition
Failure)
6xx response
600 (Busy Everywhere)
603 (Decline)
604 (Does Not Exist
Anywhere)
606 (Not Acceptable)
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
[26] 21.4.16
Sending – Status
RFC
Profile NNI
o
o
Receiving – Status
RFC
Profile NNI
i
i
[58] 6
c7
o
c7
o
[26] 21.4.17
[59] 5
c4
c8
m
n/a
m
c9
m
n/a
[67] 5
c14
o
c14
o
[26] 21.4.18
m
m
m
m
[26] 21.4.19
m
m
m
m
[26] 21.4.20
[26] 21.4.21
[26] 21.4.22
m
m
o
m
m
m
m
m
m
m
m
m
[26] 21.4.23
[26] 21.4.24
[26] 21.4.25
o
m
m
m
m
m
m
m
m
m
m
m
[26] 21.4.26
m
m
m
m
[28] 7.3.2
[26] 21.4.27
[26] 21.4.28
[48] 2
c3
m
m
c5
n/a
m
m
n/a
c3
m
m
c6
n/a
m
m
n/a
[26] 21.5
[26] 21.5.1
p25
m
p25
m
p25
m
p25
m
[26] 21.5.2
[26] 21.5.3
[26] 21.5.4
m
o
m
m
m
m
m
m
m
m
m
m
[26] 21.5.5
[26] 21.5.6
m
m
m
m
m
m
m
m
[26] 21.5.7
m
m
m
m
[30] 8
o
o
o
o
[26] 21.6
[26] 21.6.1
[26] 21.6.2
[26] 21.6.3
p26
m
c10
m
p26
m
m
m
p26
m
m
m
p26
m
m
m
[26] 21.6.4
m
m
m
m
Ref. in [[43]]
Seite 43 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Item
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
c12:
c13:
c14:
c20:
c21:
c22:
c23:
p21:
p22:
p23:
p24:
p25:
p26:
Sending – Status
Receiving – Status
RFC
Profile NNI
RFC
Profile NNI
IF A.5/9 THEN m ELSE n/a - - INVITE response.
IF A.5/9 THEN o ELSE n/a - - INVITE response.
IF A.4/20 THEN m ELSE n/a - - SIP specific event notification extension.
IF A.5/19 OR A.5/21 THEN m ELSE n/a - - REGISTER response or SUBSCRIBE
response.
IF A.4/37 AND A.4/2 THEN m ELSE n/a - - security mechanism agreement for the session
initiation protocol and registrar.
IF A.4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation
protocol.
IF A.4/42 AND (A.5/9 OR A.5/23) THEN m ELSE n/a - - the SIP session timer AND
(INVITE response OR UPDATE response).
IF A.4/43 AND A.5/17 THEN o ELSE n/a - - the SIP Referred-By mechanism and REFER
response.
IF A.4/43 AND A.5/17 THEN m ELSE n/a - - the SIP Referred-By mechanism and REFER
response.
IF A.4/44 THEN m ELSE o - - the Session Inititation Protocol (SIP) "Replaces" header.
IF A.5/9 THE m ELSE n/a - - INVITE response.
IF A.3/4 THEN m ELSE o - - S-CSCF.
IF A.3/1 OR A.3/2 OR A.3/4 THEN m ELSE o - - UE, P-CSCF, S-CSCF.
IF ACR THEN m ELSE o - - rejecting anonymous requests in the session initiation
protocol.
IF A.4/41 THEN m ELSE n/a - - an event state publication extension to the session
initiation protocol.
IF A.5/9 OR A.5/9B or A.5/13 OR A.5/15B OR A.5/17 OR A.5/19 OR A.5/21 THEN o ELSE
n/a - - INVITE response or MESSAGE response or OPTIONS response or PUBLISH
response or REFER response or REGISTER response or SUBSCRIBE response.
IF received then sent 480 at the outgoing interface
IF received then sent 403 at the outgoing interface
Status-Code
Ref. in [[43]]
A.6/2 OR A.6/3 OR A.6/4 OR A.6/5 - - 1xx response.
A.6/6 OR A.6/7 - - 2xx response.
A.6/8 OR A.6/9 OR A.6/10 OR A.6/11 OR A.6/12 OR A.6/13 - - 3xx response.
A.6/14 OR A.6/15 OR A.6/16 OR A.6/17 OR A.6/18 OR A.6/19 OR A.6/20 OR A.6/21 OR
A.6/22 OR A.6/22A OR A.6/23 OR A.6/24 OR A.6/25 OR A.6/26 OR A.6/27 OR A.6/28 OR
A.6/28A OR A.6/29 OR A.6/29A OR A.6/29B OR A.6/30 OR A.6/31 OR A.6/32 OR A.6/33
OR A.6/34 OR A.6/35 OR A.6/36 OR A.6/436 OR A.6/38 OR A.6/39 OR A.6/40 OR A.6/41
OR A.6/41A. - 4xx response.
A.6/42 OR A.6/43 OR A.6/44 OR A.6/45 OR A.6/46 OR A.6/47 OR A.6/48 OR A.6/49 - 5xx response
A.6/50 OR A.6/51 OR A.6/52 OR A.6/53 - - 6xx response.
Conditions c1-c21 and p21-p26 taken from ES 283 003
Note 1:
Note 2:
This Response is within SIP for future use defined.
These Responses are sent in cases for Registration. Registration in another domain than
the home domain is not allowed. Therefore a re INVITE can not be expected.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 44 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
8.4.3 Support of SIP Header on the Ic-Interface
The following SIP Headers shall be supported on the NNI. This table is based on [[44]], Table A.1.
Table 8-7: Supported Headers
Item
1
2
3
4
4a
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
22a
23
23a
23b
23c
24
24a
25
26
26a
27
28
29
30
31
32
32a
Header
Accept
Accept-Contact
Accept-Encoding
Accept-Language
Accept-Resource-Priority
Alert-Info
Allow
Allow-Events
Authentication-Info
Authorization
Call-ID
Call-Info
Contact
Content-Disposition
Content-Encoding
Content-Language
Content-Length
Content-Type
CSeq
Date
Error-Info
Event
Expires
Flow-Timer
From
Geolocation
Geolocation-Error
Geolocation-Routing
History-Info
Info-Package
In-Reply-To
Join
Max-Breadth
Max-Forwards
MIME-Version
Min-Expires
Min-SE
Organization
P-Access-Network-Info
P-Answer-state
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
NNI
Reference
[26] 20.1
[56B] 9.2
[26] 20.2
[26] 20.3
[116] 3.2
[26] 20.4
[26] 20.5, 5.1
[28] 7.2.2
[26] 20.6
[26] 20.7
[26] 20.8
[26] 20.9
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.18
[28] 7.2.1
[26] 20.19
[92] 10
[26] 20.20
[89] 4.1
[89] 4.4
[89] 4.2
[66] 4.1
[25] 4
[26] 20.21
[61] 7.1
[117] 5.8
[26] 20.22
[26] 20.24
[26] 20.23
[58] 5
[26] 20.25
[52] 4.4
[111] 7.1
Sending
o
n/a
n/a
n/a
o
c1
m
n/a
n/a
n/a
m
c2
m
c7
n/a
n/a
m
m
m
n/a
n/a
c6
o
n/a
m
m
n/a
n/a
m
o
n/a
n/a
n/a
m
o
n/a
o
n/a
n/a
n/a
Receiving
o
n/a
n/a
n/a
o
c1
m
n/a
n/a
n/a
m
c2
m
c7
n/a
n/a
m
m
m
n/a
n/a
c6
o
n/a
m
m
n/a
n/a
m
o
n/a
n/a
n/a
m
o
n/a
o
o
n/a
n/a
Seite 45 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Item
33
33a
33b
34
35
36
36a
37
37z
38
39
39a
39b
39c
39d
39e
40
40a
40b
41
41a
42
43
44
45
46
47
48
48a
49
49a
49b
50
51
52
53
54
55
55a
56
57
58
58a
59
60
Header
Reference
P-Asserted-Identity
P-Asserted-Service
P-Associated-URI
P-Called-Party-ID
P-Charging-Function-Addresses
P-Charging-Vector
P-Debug-Id
P-Early-Media
P-Germany-Tariff
P-Media-Authorization
P-Preferred-Identity
P-Preferred-Service
P-Private-Network-Indication
P-Profile-Key
P-Served-User
P-User-Database
P-Visited-Network-ID
Path
Permission-Missing
Priority
Priv-Answer-Mode
Privacy
Proxy-Authenticate
Proxy-Authorization
Proxy-Require
RAck
Reason
Record-Route
Recv-Info
Referred-By
Refer-Sub
Refer-To
Reject-Contact
Replaces
Reply-To
Request-Disposition
Require
Retry-After
Resource-Priority
Route
RSeq
Security-Client
Security-Server
Security-Verify
Server
[34] 9.1
[121] 4.1
[52] 4.1
[52] 4.2
[52] 4.5
[52] 4.6
[140] 13.1
[109] 9
see chapter 7.4
[31] 5.1
[34] 9.2
[121] 4.2
[134] 8
[97] 5
[133] 6
[82] 4
[52] 4.3
[35] 4
[125] 5.9.3
[26] 20.26
[158] 2
[33] 4.2
[26] 20.27
[26] 20.28
[26] 20.29
[27] 7.2
[34A] 2
[26] 20.30
[25] 5
[59] 3
[173] 4
[36] 2.1
[56B] 9.2
[60] 6.1
[26] 20.31
[56B] 9.1
[26] 20.32
[26] 20.33
[116] 3.1
[26] 20.34
[27] 7.1
[48] 2.2
[48] 2.2
[48] 2.2
[26] 20.35
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
NNI
Sending
m
n/a
n/a
n/a
n/a
o(Note 2)
n/a
o (Note 1)
o
n/a
n/a
o
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
m
n/a
n/a
n/a
o
m
o
o
c3
n/a
n/a
n/a
c4
n/a
n/a
o
o
o
o
o
n/a
n/a
n/a
n/a
Receiving
m
n/a
n/a
n/a
n/a
o(Note 2)
n/a
o(Note 1)
o
n/a
n/a
o
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
m
n/a
n/a
n/a
o
m
o
o
c3
n/a
n/a
n/a
c4
n/a
n/a
o
o
o
o
o
n/a
n/a
n/a
n/a
Seite 46 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Item
Header
Reference
NNI
Sending
Receiving
60a
Service-Route
[38] 5
n/a
n/a
60b
Session-ID
[162] 6.2
n/a
n/a
61
Session-Expires
[58] 4
o
o
62
SIP-Etag
[70] 11.3.1
n/a
n/a
63
SIP-If-Match
[70] 11.3.2
n/a
n/a
64
Subject
[26] 20.36
n/a
n/a
65
Subscription-State
[28] 7.2.3
c5
c5
66
Supported
[26] 20.37
o
o
67
Timestamp
[26] 20.38
o
o
68
To
[26] 20.39
m
m
68a
Trigger-Consent
[125] 5.11.2
n/a
n/a
69
Unsupported
[26] 20.40
o
o
70
User-Agent
[26] 20.41
o
o
70a
User-to-User
[126] 4.1
m
m
71
Via
[26] 20.42
m
m
72
Warning
[26] 20.43
o
o
73
WWW-Authenticate
[26] 20.44
n/a
n/a
c1: IF Table 9-1/7 THEN m ELSE o (CW)
c2: IF Table 9-1/3 THEN m ELSE n/a (CCxx)
c3: IF Table 9-1/5 OR Table 9-1/8 THEN m ELSE n/a (CONF, ECT)
c4: IF Table 9-1/8 THEN m ELSE n/a (ECT)
c5: IF Table 8-4/12 THEN m ELSE n/a (NOTIFY request)
c6: IF Table 9-1/5 THEN m ELSE n/a (CONF)
c7: IF Table 10-1/4 OR Table 10-1/5 OR Table 10-1/6 THEN m ELSE IF Table 10-1/2 OR Table
10-1/3 THEN o ELSE n/a (MIME Types)
Note 1: see chapter 10.2: A transit network shall forward a P-Early-Media header as received.
Note 2: The usage of this parameter requires multilateral agreeements. This will be clarified in a
later version of this specification.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 47 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
8.4.4 Supported SDP Types
Table 8-8 and Table 8-9 are based on [[43]], table A.318 and A.319, respectively. The modifications reflect
the support of SDP types at the Ic– Interface as described within this document.
Table 8-8: SDP Types
Item
Type
1
2
Sending - Status
RFC
Profile NNI
Session level description
[39] 5.1
m
m
[39] 5.2
m
m
Ref. in
[[43]]
Receiving – Status
RFC
Profile NNI
v= (protocol version)
m
m
o= (owner/creator and
m
m
session identifier)
3
s= (session name)
[39] 5.3
m
m
m
m
4
i= (session information)
[39] 5.4
o
o
m
o
5
u= (URI of description)
[39] 5.5
o
n/a
o
n/a
6
e= (email address)
[39] 5.6
o
n/a
o
n/a
7
p= (phone number)
[39] 5.6
o
n/a
o
n/a
8
c= (connection
[39] 5.7
c5
o
m
m
information)
9
b= (bandwidth
[39] 5.8
o
o (NOTE 1)
m
m
information)
Time description (one or more per description)
10
t= (time the session is
[39] 5.9
m
m (NOTE 2) m
m
active)
11
r= (zero or more repeat
[39] 5.10
o
n/a
o
n/a
times)
Session level description (continued)
12
z= (time zone
[39] 5.11
o
n/a
o
n/a
adjustments)
13
k= (encryption key)
[39] 5.12
x
n/a
n/a
n/a
14
a= (zero or more
[39] 5.13
o
o
m
m
session attribute lines)
Media description (zero or more per description)
15
m= (media name and
[39] 5.14
o
o
m
m
transport address)
16
i= (media title)
[39] 5.4
o
n/a
o
n/a
17
c= (connection
[39] 5.7
c1
c1
c1
c1
information)
18
b= (bandwidth
[39] 5.8
o
o (NOTE 1)
o
o
information)
19
k= (encryption key)
[39] 5.12
x
n/a
n/a
n/a
20
a= (zero or more media
[39] 5.13
o
o
m
m
attribute lines)
c1:
IF A.318/15 THEN m ELSE n/a.
c5:
IF A.318/17 THEN o ELSE m - - "c=" contained in all media description.
NOTE 1:
For "video" and "audio" media types that utilise RTP/RTCP, it shall be specified. For
other media types, it may be specified.
NOTE 2:
Shall be set to 00. IF CONF is used than other values can appear but this is out of
scope of this specification.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 48 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Prerequisite table line Table 8-8/14 OR table line Table 8-8/20 - - a= (if at least one “a=” attribute exists )
Table 8-9: Media Attribute Lines (a=)
Item
Type
1
2
3
category (a=cat)
keywords (a=keywds)
name and version of
tool (a=tool)
packet time (a=ptime)
maximum packet time
(a=maxptime)
receive-only mode
(a=recvonly)
send and receive mode
(a=sendrecv)
send-only mode
(a=sendonly)
Inactive mode
(a=inactive)
whiteboard orientation
(a=orient)
conference type
(a=type)
character set
(a=charset)
language tag
(a=sdplang)
language tag (a=lang)
frame rate
(a=framerate)
quality (a=quality)
format specific
parameters (a=fmtp)
rtpmap attribute
(a=rtpmap)
current-status attribute
(a=curr)
desired-status attribute
(a=des)
confirm-status attribute
(a=conf)
media stream
identification attribute
(a=mid)
group attribute
(a=group)
setup attribute
(a=setup)
connection attribute
(a=connection)
4
5
6
7
8
8A
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Ref. in
[[43]]
Sending - Status
Receiving - Status
RFC
c8
c8
c8
Profile NNI
c8
c8
c8
c9
c9
c9
Profile NNI
c9
c9
c9
[39] 6
[39] 6,
[28A] 8
[39] 6
c10
c10
c10
c10
c11
c11
c11
c11
o
o
m
m
[39] 6
o
o
m
m
[39] 6
o
o
m
m
[39] 6
o
o
m
m
[39] 6
c10
c10
c11
c11
[39] 6
c8
c8
c9
c9
[39] 6
c8
c8
c9
c9
[39] 6
o
o
m
m
[39] 6
[39] 6
o
c10
o
c10
m
c11
m
c11
[39] 6
[39] 6
c10
c10
c10
c10
c11
c11
c11
c11
[39] 6
c10
c10
c11
c11
[30] 4
c1
n/a
c2
c2
[30] 4
c1
n/a
c2
c2
[30] 4
c1
n/a
c2
c2
[53] 3
c3
n/a
c4
n/a
[53] 4
c5
n/a
c6
n/a
[83] 4
c7
n/a
c7
n/a
[83] 5
c7
n/a
c7
n/a
[39] 6
[39] 6
[39] 6
RFC
Seite 49 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
IF A.317/22 AND A.318/20 THEN o ELSE n/a - - integration of resource management and
SIP, media level attribute name "a=".
IF A.317/22 AND A.318/20 THEN m ELSE n/a - - integration of resource management and
SIP, media level attribute name "a=".
IF A.317/23 AND A.318/20 THEN o ELSE n/a - - integration of resource management and
SIP, media level attribute name "a=".
IF A.317/23 AND A.318/20 THEN m ELSE n/a - - integration of resource management and
SIP, media level attribute name "a=".
IF A.317/24 AND A.318/20 THEN o ELSE n/a - - integration of resource management and
SIP, media level attribute name "a=".
IF A.317/24 AND A.318/20 THEN m ELSE n/a - - integration of resource management and
SIP, media level attribute name "a=".
IF A.317/26 AND A.318/20 THEN m ELSE n/a - - integration of resource management and
SIP, media level attribute name "a=".
IF A.318/14 THEN o ELSE x - - session level attribute name "a=".
IF A.318/14 THEN m ELSE n/a - - session level attribute name "a=".
IF A.318/20 THEN o ELSE x - - media level attribute name "a=".
IF A.318/20 THEN m ELSE n/a - - media level attribute name "a=".
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 50 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
9 Simulation Services Supported for NGN-VoiceInterconnection
9.1 Supported Services on the Interconnection Interface
Support of Simulation Services on the NNI means that the related signalling information is transported
transparently via the Ic interface. This is done for the simulation services listed in the table below.
Table 9-1: Simulation Services
Item
Simulation Services
Support at NNI
1
ACR & CB
Anonymous Communication Rejection &
Communication Barring
2
AoC
Advice of Charge (Note)
3
CCBS &
CCNR
Completion of Communications to Busy
Subscriber & Completion of Communications by
No Reply
o
4
CDIV
Communication Diversion
o
5
CONF
Conference
o
6
CUG
Closed User Group
o
7
CW
Communication Waiting
o
8
ECT
Explicit Communication Transfer
o
9
HOLD
Communication Hold
o
10
MCID
Malicious Communication Identification
11
MWI
Message Waiting Indication
o
12
OIP & OIR
Originating Identification Presentation &
Originating Identification Restriction
m
13
SIPCharging
SIP Transfer of IP Multimedia Service Tariff
Information
c1
14
TIP & TIR
Terminating Identification Presentation &
Originating Identification Restriction
o
Note:
c1:
o
n/a
n/a
AoC (2) is only applicable at the UNI. To transmit charging information
on the NNI, the support of SIP-Charging (13) is necessary.
see chapter 12.3
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 51 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
9.2 Description of Services
For the Simulation Services the references in chapter 4.1.1.4 apply.
9.2.1 CDIV
The maximum of 5 diversions is allowed.
Indication of an originating user is optional.
The elements caused by the CDIVN service are not supported on the NNI.
The “Diversion” header shall not be used.
9.2.2 OIP/OIR
No special requirements beyond that defined within chapter 8 on the NNI needed.
9.2.3 TIP/TIR
No special requirements beyond that defined within clause 8 on the NNI needed.
9.2.4 HOLD
No special requirements beyond that defined within chapter 8 on the NNI needed.
9.2.5 ACR&CB
No special requirements beyond that defined within chapter 8 on the NNI needed.
9.2.6 ECT
The Interworking of the REFER Request to an INVITE shall be done by the serving network operator.
See chapter 4.7.2.9.7 of ETSI TS 124 628 [[27]] for details.
9.2.7 CONF
The Interworking of the REFER Request to an INVITE shall be done by the serving network operator.
See chapter 4.7.2.9.7 of ETSI TS 124 628 [[27]] for details.
The event package “conference” and the Event header shall be supported
9.2.8 CUG
No special requirements beyond that defined within chapter 8 and 10.2.2 on the NNI needed.
9.2.9 MWI
The event package name "message-summary" in the SUBSCRIBE and NOTIFY request shall be
supported.
9.2.10 MCID
MCID is not applicable on the Ic interface (see also chapter 5.1.4).
9.2.11 Call Completion
The event package name "call-completion" and the Call-Info header field with a purpose parameter set to
'call-completion' and the m parameter set to "BS" or “NR” or “NL” shall be supported.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 52 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Note: Since Call Completion on Not Logged-In (CCNL) is a 3GPP Release 10 feature, the support of
[[28]] is mandatory for using CCNL.
9.2.12 CW
No special requirements beyond that defined within clause 8 on the NNI needed.
9.2.13 UUS
UUS is not a simulation service. The standardisation work is still ongoing.
9.2.14 Emergency Calls (Notruf)
The transmission of information accompanying the emergency call (e.g. emergency caller location, supplier
recognition) is for further study.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 53 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
10 Bearer Aspects
10.1 Bearer Services
Fax and Modem transmission via G.711a shall be supported as default setting.
Two optional alternatives are proposed:
(i)
T.38: MIME Type: image (RFC 3362) using UDPTL (only for Fax)
(ii) V.152 in transparent mode
10.2 Bearer Control
10.2.1 Through Connection of the Media Path (speech/data
transmission)
10.2.1.1 General Remarks
The following chapters describe the establishment of the transmission path with respect to the offer/answer
procedure and the early-media handling. The usage of the P-Early-Media header is an option. All
statements made regarding P-Early-Media header are conform to [[9]]. Although the through connection is
done based on local policies it is described for the purpose of clarifying the relation between charging and
establishing the transmission path.
Please consider that the originating and terminating network discard the P-Early-Media header received
from the not trusted user equipment.
If the destination network sends an SDP information with 18x this network or a trusted UE connected to it is
responsible to play appropriate tones or announcements.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 54 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
10.2.1.2 Scenarios described
10.2.1.2.1
Remarks and Symbols used
The B-subscriber is trusted concerning early media := the early media in backward direction is already
available in the early dialogue in the destination network.
The B-subscriber is not trusted concerning early media := the early media in backward direction is not
available in the early dialogue in the destination network.
Scenario 4 is only successful if the P-Early-Media header is supported across all involved networks.
Scenario 4 (bidirectional media channel before 200 OK available in the originating network) applies only if
this was explicitly covered by a contract which was approved by the originating operator.
Figure 10-1: Symbols used
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 55 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
10.2.1.2.2 Scenario 1: Connection Set-up to User Equipment B, which is
Not Trusted concerning Early Media
Figure 10-2: Scenario 1: Connection set-up to user equipment B, which is not trusted concerning early
media
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 56 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
10.2.1.2.3 Scenario 2: Connection Set-up to User Equipment B, which is
Trusted concerning Early Media
Figure 10-3: Scenario 2: Connection set-up to user equipment B, which is trusted concerning early media
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 57 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
10.2.1.2.4 Scenario 3: Connection Set-up with Tones/Announcements from
the Transit-/ Destination Network
Figure 10-4: Scenario 3: Connection set-up with tones/announcements from the transit-/destination
network
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 58 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
10.2.1.2.5 Scenario 4: Originator has an Early Media Dialogue with an IVR
in the Transit-/ Destination Network
User
Equipment A
Originating Node
(P-CSCF/C-BGF, A-BGF)
Transit Node
(IBCF/I-BGF)
Transit-/TerminatingNode
IVR
INVITE: user B SIP/2.0
SDP
TRYING
INVITE: user B SIP/2.0
P-Early-Media: supported
SDP
INVITE: user B SIP/2.0
P-Early-Media: supported
SDP
INVITE: user B SIP/2.0
P-Early-Media: supported
SDP
18x yyyyy
P-Early-Media: sendrecv
SDP
18x yyyyy
P-Early-Media: sendrecv
SDP
18x yyyyy
P-Early-Media: sendrecv
SDP
18x yyyyy
P-Early-Media: sendrecv
SDP
Optional
200 OK
200 OK
200 OK
200 OK
The blue marked signalling events are optional informations
Figure 10-5: Scenario 4: Originator has an early media dialogue with an IVR in the transit-/destination
network
10.2.1.3 Description of the Procedures
Early media is a speech/data transmission in the early dialogue. It is not desirable that unauthorized early
media is gated to the user equipments.
The user equipment in the originating and terminating network is responsible for the “offer/answer
exchange” and therefore for the establishment of the media path.
Consequently the user equipment establishes the media path by offer/answer exchange. Independent of
the offer/answer exchange the network(s) controls this media path and connects through the media path as
recommended in this clause below.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 59 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
10.2.1.3.1
Actions required at the Origination Network
Three scenarios in the originating network are possible according to the standards:
• The offer is available in the initial INVITE; the answer is available in a provisional response.
• The offer is available in the initial INVITE; the answer is available in the 200 OK final response.
• The offer is available in the 200 OK final response; the answer is available in the ACK.
Within the scope of this specification, the third bullet item is not desired. That means that the SDP answer
should be available at least in the 200 OK INVITE.
As a basic requirement the through-connection of the media path shall be completed in backward and
forward direction between the networks as soon as an SDP answer is available based on the information
delivered, the originating network has no knowledge whether early media is authorized or not
(see Figure 10-6 case A).
The transmission path is completed in the forward and backward direction between the user equipment in
the originating and destination network on receipt of a 200 OK to the INVITE request from the destination
network (see Figure 10-6 case E).
If media are modified with subsequent SDP offer-answer exchanges during the call establishment or while
the call is confirmed, any updates of the transmission path required to support the adjusted media should
be performed when the new SDP offer-answer exchange is completed.
If the originating network supports the early media authorization according to the requirements in
RFC 5009:
• A P-Early-Media header is present in the initial INVITE request set to ‘supported’
• When a P-Early-Media header is received in a provisional response, the early media is authorized
according to the value of the received P-Early-Media header towards the user equipment (see Figure
10-6 case B, C and D).The through connection in forward direction shall be completed based on
bilateral agreements
If early media authorization according to the requirements in RFC 5009 is not supported, the originating
network has to trust the early media handling in the terminating network and the transmission path is
controlled only with the information received in the SDP towards the user equipment (see Figure 10-6
case A and case E).
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 60 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Figure 10-6: Signalling events and media handling in the originating network.
10.2.1.3.2
Actions required at an Intermediate National Network (Transit)
The establishment of the transmission path in forward and backward direction is completed via the transit
network as soon as an SDP answer is available.
If the intermediate national network supports the procedures of RFC 5009 it can selectively open or close
the media gate(s) corresponding to an authorized early media as indicated in the P-Early-Media header.
The intermediate national network sends a P-Early-Media header as received.
If media are modified with subsequent SDP offer-answer exchanges during the call establishment or while
the call is ongoing, any updates of the transmission path required to support the adjusted media should be
performed when the new SDP offer-answer exchange is completed
If Tones and Announcements are applicable the MRF sends an SDP that contains an ‘a’ attribute set to
‘sendonly’ and
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 61 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
if the destination network receives a P-Early-Media header set to ‘supported’ in the initial INVITE request
and if the early media authorization according to the requirements in RFC 5009 is supported, a
P-Early-Media header is present in the 18x provisional response set to ‘sendonly’ (see Figure 10-7 case B).
Media path enabled
IBCF
I-BGF
INVITE: user B SIP/2.0
P-Early-Media: supported
SDP
18x yyyyyy
P-Early-Media: xxx
SDP
IBCF
I-BGF
INVITE: user B SIP/2.0
P-Early-Media: supported
SDP
18x yyyyyy
P-Early-Media: xxx
SDP
Media path disabled
INVITE: user B SIP/2.0
P-Early-Media: supported
SDP
18x yyyyyy
P-Early-Media: xxx
SDP
Media in forward direction
Media in forward direction
Media in forward direction
Media in backward direction
Media in backward direction
Media in backward direction
CASE A
Announ.
18x yyyyyy
P-Early-Media: sendonly
SDP
18x yyyyyy
P-Early-Media: sendonly
SDP
Media in forward direction
Media in forward direction
Media in backward direction
Media in backward direction
CASE B
IVR
18x yyyyyy
P-Early-Media: sendrecv
SDP
18x yyyyyy
P-Early-Media: sendrecv
SDP
Media in forward direction
Media in forward direction
Media in backward direction
Media in backward direction
CASE C
The blue marked events are applicable if RFC 5009 is supported in the originating or terminating network
Figure 10-7: Signalling events and media handling in the intermediate national network
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 62 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
10.2.1.3.3
Actions required at the Termination Network
Since the terminating network has the knowledge based on local policies whether early media in forward or
backward direction is authorized it is responsible whether the media stream in the early dialogue is allowed
and is gated from/to the terminating user equipment.
The scenarios for the “offer/answer exchange” as described in clause 10.2.1.3.1 are also applicable in this
section.
The establishment of the transmission path in the early dialogue is suppressed towards the called party.
Based on local policies if the destination user is trusted regarding early media, the through-connection of
the media path will be completed in the backward direction as soon as an SDP answer from the SIP user
equipment at the called party’s side is available.
If the destination network receives a P-Early-Media header set to ‘supported’ in the initial INVITE request
and if the early media authorization according to the requirements in RFC 5009 is supported, a P-EarlyMedia header is present in the 18x provisional response set to ‘sendonly’ (see Figure 10-8 case B).
Based on local policies if the destination user is not trusted regarding early media, the through-connection
of the media path is suppressed towards the calling party user equipment (see Figure 10-8 case A).
If the destination network receives a P-Early-Media header set to ‘supported’ in the initial INVITE request
and if the early media authorization according to the requirements in RFC 5009 is supported, a P-EarlyMedia header is present in the 18x provisional response set to ‘inactive’.
When the called party answers with a 200 OK INVITE, the destination network shall connect through the
transmission path to the terminating user in forward and backward direction and the ringing tone is
removed if applicable. A 200 OK to the preceding exchange is sent (see Figure 10-7 case A and case B).
If media are modified with subsequent SDP offer-answer exchanges during the call establishment or while
the call is ongoing, any updates of the transmission path required to support the adjusted media should be
performed when the new SDP offer-answer exchange is completed.
If Tones and Announcements are applicable the MRF sends an SDP that contains an ‘a’ attribute set to
‘sendonly’ and
if the destination network receives a P-Early-Media header in the initial INVITE request set to ‘supported’
and if the early media authorization according to the requirements in RFC 5009 is supported, a
P-Early-Media header is present in the 18x provisional response set to ‘sendonly’ (see Figure 10-8 case C).
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 63 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
IBCF
P-CSCF
I-BGF
INVITE: user B SIP/2.0
P-Early-Media:supported
SDP
18x yyyyy
P-Early-Media: inactive
SDP
Media in forward direction
Media in backward direction
200 OK INVITE
Media in forward direction
Media in backward direction
UE-B
Non trusted
C-BGF
A-BGF
INVITE: user B SIP/2.0
P-Early-Media:supported
SDP
INVITE: user B SIP/2.0
SDP
18x yyyyy
SDP
18x yyyyy
P-Early-Media: inactive
SDP
CASE A
Media in forward direction
Media in backward direction
200 OK INVITE
200 OK INVITE
Media in forward direction
Media in backward direction
UE-B
trusted
18x yyyyy
P-Early-Media: sendonly
SDP
Media in forward direction
Media in backward direction
200 OK INVITE
Media in forward direction
Media in backward direction
18x yyyyy
SDP
18x yyyyy
P-Early-Media: sendonly
SDP
CASE B
Media in forward direction
Media in backward direction
200 OK INVITE
200 OK INVITE
Media in forward direction
Media in backward direction
Announ.
18x yyyyy
P-Early-Media: sendonly
SDP
Media in forward direction
Media in backward direction
18x yyyyy
P-Early-Media: sendonly
SDP
CASE C
Media in forward direction
Media in backward direction
Media path enabled
Media path disabled
IVR
18x yyyyy
18x yyyyy
P-Early-Media: sendrecv
SDP
Media in forward direction
Media in backward direction
CASE D
P-Early-Media: sendrecv
SDP
Media in forward direction
Media in backward direction
The blue marked events are applicable if RFC 5009 is supported in the originating or terminating network
Figure 10-8: Signalling events and media handling in the terminating network
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 64 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
10.2.1.3.4
Overview of the Media Handling in the Relevant Network Types
The figure below gives an overview of the media handling in the originating, transit and terminating network.
Figure 10-9: Signalling events and media handling in the originating, transit and terminating network
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 65 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
10.2.2 MIME Type Handling
For the Ic interface it is necessary to define the various SIP message bodies amongst SIP functionalities
(e.g. methods, header, parameter, numbering formats) in order to reach a minimum interoperability at the
Ic-interface between two IBCF or B2BUA.
The IBCF shall support following content types in SIP:
Table 10-1: MIME Type Handling
Item
Content Type
Ref.
Usage
1
application/SDP
[39]
SDP
m
2
application/ISUP
[[29]]
Encapsulating of ISUP in MIME
bodies
o
3
multipart/mixed
[[29]]
Transport of multiple, different
MIME types in a MIME body
m
4
application/vnd.etsi.pstn+xml
[[44]]
Transport of PSTN/ISDN
information
o
5
application/x-session-info
[[30]]
Digit for Overlap
o
6
application/vnd.etsi.sci+xml
[[22]]
SIP support of charging information
c1
7
application/simple-messagesummary+xml
[65]
Transport of MWI information
c2
8
message/sipfrag
[37]
SUBCRIBE/NOTIFY mechanism
c3
9
application/vnd.etsi.cug+xml
[[20]]
Transport of CUG information
c4
10
application/call-completion
[[31]]
Transport of CCBS and CCNR
information
c5
11
application/pidf+xml
[[32]]
Transport of CCBS and CCNR
information
m
12
application/conferenceinfo+xml
[78]
Transport of CONF information
c6
13
application/emergencyCall.Pr
oviderInfo+xml
[[33]]
Transport of additional data for
emergency calls
m
c1:
c2:
c3:
c4:
c5:
c6:
Support at NNI
IF Table 9-1/13 THEN m ELSE o (SIP-Charging)
IF Table 9-1/11 THEN m ELSE o (MWI)
IF Table 8-5/24 OR Table 8-5/12 THEN o ELSE n/a (SUBSCRIBE, NOTIFY
Request)
IF Table 9-1/6 THEN m ELSE o (CUG)
IF Table 9-1/3 THEN m ELSE o (CCxx)
IF Table 9-1/5 THEN m ELSE o (CONF)
According to [[43]], chapter 5.10.6.3 the IBCF can screen the SIP message body and handle it according to
network policies.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 66 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
10.3 Tones and Announcements
10.3.1 Actions required at the Origination Network
If the originating network receives an 18x with SDP then it has to connect the backward path. However, if
the originating network receives a P-Early-Media-header indicating that inband information is available and
the early media authorization according the requirements in RFC 5009 is supported, it shall rather throughconnect the bearer in backward direction.
10.3.2 Actions required at an Intermediate National Network (Transit)
The intermediate network shall pass tones and announcements in backward and forward direction once the
bearer is through-connected. Please refer also to clause 10.2.1.3.2.
10.3.3 Actions required at the Terminating Network
If the terminating network sends an 18x with SDP then it has to send a ring back tone or early media to the
originating network. The terminating network may insert tones and announcements in backward or forward
direction as applicable once the early media is authorized.
If it inserts tones and announcements, it may provide a P-Early-Media-header indicating that inband
information is available in SIP signalling towards the originating network and if the early media
authorization according to the requirements in RFC 5009 is supported. Please refer to clause 10.2.1.3.3.
10.3.4 Media Clipping
Media Clipping can occur in certain scenarios. However, no feasible solution has been standardised yet.
10.4 Codecs
A successful setup to all targets is guaranteed only in that case, when at least the G.711a-Codec with a
packet-size of 20 ms is included in the SDP-offer. This does not necessarily apply for ISDN data services,
where the negotiation of clearmode channel according to RFC 4040 [[7]] is sufficient and precondition for a
successful connection.
10.5 IP Version, IP Header Interworking and Fragmentation
Version 4 or 6 of the internet protocol is used for NGN interconnection according to
AKNN concept paper [[52]]. The interworking shall be done according to [[46]].
Fragmentation of VoIP (RTP) packets is not supported on the NNI.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 67 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
11 Forward Address Signalling
There is no consensus about a single dialling procedure to be used in Germany. Amongst the
Forward Address Signalling methods, the following two variants are preferred: The en bloc forward
signalling (see chapter 11.1) and the Multiple Invite Overlap Signalling method in combination with en bloc
forward address signalling (see chapter 11.2). The choice of using one of these procedures over the Icinterface will be basis for bilateral agreements.
11.1 Variant 1: En Bloc Forward Address Signalling only
En bloc procedure shall be used.
11.2 Variant 2: Multiple Invite Method in Combination with En Bloc
Forward Address Signalling
As long as subscribers are using overlap signalling, there is a need for a solution to deal with this scenario
within SIP networks.
If all addressable numbers would have a length known by the originating network, overlap-to-en-bloc
conversion would solve this scenario.
With respect to e.g. private branch exchanges (PBX) with extended dial-in range, the overlap-to-en-bloc
conversion would lead to a post dial delay, because the originating network does not know the end of
dialling until the last interdigit timer interval timed out.
The Multiple Invite method according to annex C.2.2 shall be used. Please note that this procedure also
includes the en bloc procedure.
11.3 Remarks about the Usage of both Variants in Interconnection
Scenarios
In case that a transit network allows as a receiving entity to use the Multiple Invite method and has to
terminate such call attempts towards a network allowing the en bloc forward signalling only this transit
network has to perform an overlap-to-en bloc conversion function as described in [[4]] chapter 4.9.3 ff and
annex N.3.
Please be aware that this also applies to possible cases of several transit networks. The conversion shall
be applied by the last network in the chain supporting the Multiple Invite method.
Also, in case of a direct interconnection between two operators using different dialling procedures, the
overlap-to-en bloc conversion shall be performed by the network supporting the Multiple Invite method, i.e.
the originating network.
The basic problem to be solved by this procedure is the determination of the end of dialling. Two
possibilities are described by 3GPP: First based on the knowledge of the dialling plan and second based
on a timer supervision. To use the knowledge of the dialling plan only the (last) transit network operator or
(depending on the exact interconnection scenario) the originating network operator needs to have full
information about the length of all valid subscriber numbers to be received including PBX numbers. In case
the timer solution is selected to determine the end of dialling the preconditions described in [[4]] have to be
met.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 68 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
This includes the following scenario:
Figure 11-1: Example: Conversion from Multiple Invite method to En Bloc method
Please be aware that the network performing the overlap-to-en bloc conversion has to be capable of
receiving several parallel INVITE methods with the same Call-ID and From header but different CSeq IDs
for the same call attempt. Also the routing of these parallel INVITE methods has to be ensured via the
same network entities (Case: message 3 and 4)!
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 69 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
12 Charging Aspects
12.1 Begin of Charging
When the originating network receives a 200 OK indicating the requested session establishment has been
completed, the transmission path shall be connected through in both directions. If the originating network is
the network controlling charging, charging shall begin if applicable.
The ACK method shall not be used for the determination of the begin of charging.
12.2 End of Charging
When the originating network receives a BYE indicating that the established session has to be released,
the transmission path shall be released in both directions. If the originating network is the network
controlling charging, charging shall be terminated, if applicable.
12.3 SIP Support of Charging
See [[51]]
To support Advice of Charge for destinations in offline charging the SIP Transfer of IP Multimedia Service
Tariff Information [[22]] shall be supported to convey tariff information provided by a Charge Determination
Point via network boundaries.
13 Roaming
Currently Roaming of SIP-subscribers in fixed public networks is not supported.
14 Emergency Calls
The TR-Notruf [[53]] has been published in June 2011. For mobile networks, an extended location
description [[54]] was released from BNetzA in April 2013. These documents contain several new
requirements for emergency calls, which are briefly summarized in sub-clause 14.1.
Depending on the respective technology (PSTN or NGN) of the Public Safety Answering Point (PSAP), a
different encoding for the number format as well as for the additional information is used.
The respective number format is clause 14.2; the transmission of the additional information is described in
clause 14.3. Exemplary encodings can be found in clause 14.4. Finally, emergency calls for Voice Service
Providers (VSP) are described in clause 14.5.
Please note that the specification process has to be finished until the first PSAP will be migrated to NGN
technology.
14.1 Requirements for Emergency Calls
Emergency calls shall be routed to the corresponding PSAP which is dependent on the origin of the
emergency call. This origin is a geographical area which is identified by the official municipal identifier for
emergency calls (“Amtlicher Gemeindeschlüssel Notruf“, AGS_N).
Furthermore, additional information has to be transmitted to the PSAP for an emergency call. This
additional information contains the actual location of the emergency caller, which can either be transmitted
as civic location, as geographic location or, for mobile networks, as a geographic area where the caller
actually camps respectively and a Service Provider ID. Until a separate Service Provider ID has been
allocated, the porting identifier (Dxyz) has to be used instead.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 70 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
14.2 Number Format
For emergency calls to a PSTN PSAP, the format is described in sub-clause 7.1.2.2.1. For emergency calls
to an NGN PSAP, the format is described in sub-clause 7.1.2.2.2.
14.3 Transmission of Additional Information
The originating network operator shall set up the additional information and transit network operator shall
transmit the additional information transparently.
The additional information can be transported in a SIP Geolocation Header Field
PIDF-LO xml body as described in sub-clause 14.3.2 and/or in a SIP User-to-User Header
described in sub-clause 14.3.1 using the same address format (e.g. civic location)
SIP User-to-User Header field as for the network provided SIP Geolocation Header Field
PIDF-LO.
including
Field as
for the
including
Possible scenarios how the additional information can be transmitted from an originating network operator
(oTNB) to the PSAP dependent on the respective technologies of both the oTNB and the PSAP (i.e. PSTN
or NGN, respectively) are described in the following Table 14-1.
Table 14-1: Scenarios for the transmission of additional information (informative)
PSAP
PSTN
NGN
PSTN
UUI parameter (Note1)
UUI header (Note1)
NGN (Note2)
Geolocation including PIDF-LO
UUI header
Geolocation including PIDF-LO
UUI header
oTNB
Note1: According to clause 8.1.3.3 of TR-Notruf [[53]], for circuit switched telephone
lines connected via ISDN switching equipment, no location
information needs to be set up until the end of its operating time.
Note2: It is allowed to transmit only the PIDF format in case that a service provider
takes care of providing the necessary information in the appropriate format to
the PSAP.
The additional information in the (network provided) SIP Geolocation Header Field including
PIDF-LO xml body is seen as master information.
Exemplary encodings for a civic and a geographic location are both shown in sub-clause 14.4.
14.3.1 SIP UUI Header Field
The necessary UUI encoding is specified by Annex N3 of TR-Notruf [[53]] and is extended for mobile
networks in [[54]]. Even though the UUI SIP Header Field could carry more characters, the maximum
number of characters defined by Annex N3 of TR-Notruf [[53]] shall not be exceeded, even if a truncation of
an address might be necessary.
In order to transport this information in SIP, the respective bits shall be concatenated in hexadecimal
encoding and set into the User-to-User SIP Header Field. According to clause 9 of
draft-ietf-cuss-sip-uui-isdn-04 [126A], the protocol discriminator is used as the first octet of the User-to-User
1
SIP Header field. Both the parameter name and the length indicator will subsequently be added by the
MGC into the ISUP UUI container (see clause 7.4.21.1.2 of 3GPP TS 29.163). The “encoding”-Parameter
can optionally be set to “hex”. Even though this parameter is not present, the encoding must be assumed
1
Number of octets to follow the length indicator (not counting the length indicator itself)
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 71 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
as the default for this package (see draft-ietf-cuss-sip-uui-isdn-04 [126A]), which is “hex”. The same holds
for the “purpose”-Parameter, where interworking with the ISDN UUI Service must be assumed if missing,
i.e. purpose=isdn-uui is the default value.
14.3.1.1 General
The actual location information can either be transmitted as civic (see sub-clause 14.3.1.2) or geographic
location (see sub-clause 0). A differentiation between these two formats is achieved by a descriptor in
Octet 6.
The following parameters according to Table 14-2
information for both a geographic and a civic location.
have to be transmitted alongside the location
Table 14-2: General UUI Information Elements
Content
Data-Type
Value Range
Octets
Sub-clause in
[[53]]
N3-A.1
User-user information
Binary
0010 0000
1
element identifier
(Note 1)
Length of user-user contents Binary
6-32
2
N3-A.2
Protocol discriminator
Binary
3
N3-A.3
Provider ID
Hexadecimal
4 characters
4 to 5
N3-A.4
Description of location
Hexadecimal
2 characters
6
N3-A.5
information
Note 1: In ISUP, the ‘parameter name’ is coded with H’20, i.e. binary 0010 0000 according to Table
5 of ITU-T Q.763 [[34]]. On a DSS1 interface, the encoding of this parameter is H’7E, i.e.
binary 0111 1110 according to Figure 4-36 of ITU-T Q.931 [[35]].
Please note that according to sub-clause 3.6.1 of ITU-T Recommendation Q.763 [[34]] only the body of the
User-to-User information parameter (i.e. protocol discriminator and user-information field) are coded
identically to ITU Recommendation Q.931 [[35]].
For further details, please refer to the respective sub-clauses of Annex N3 of TR-Notruf [[53]] as indicated
in the last column.
14.3.1.2 Civic Location
A civic location contains a street name (at most the first 21 characters), a house number and the postcode.
Optionally, a house number suffix can also be transmitted. The encoding is described in Table 14-3.
Table 14-3: UUI Encoding of a Civic Location
Sub-clause in
[[53]]
N3-A.6.2.3
Content
Data-Type
Value Range
Octets
Street name
ASCII
House number
Decimal
13 to 33
(max.)
10 to 11
N3-A.6.2.2
House number suffix
Postcode
ASCII
Decimal
up to 21
characters
4 digits
0–9
1 character
5 digits
0–9
12
7 to 9
N3-A.6.2.1
The 7 bit ASCII character shall be mapped into bits 1 to 7 of the octet. Bit 8 of the octet (MSB) shall be set
to “0”.
For further details, please refer to the respective sub-clauses of Annex N3 of TR-Notruf [[53]] as indicated
in the last column.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 72 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
14.3.1.3 Geographic Location
Different geographic location formats are defined in Table 14-4.
Table 14-4: UUI Encoding of a Geographic Location
Geographic Location Format
Ellipsoid Point
Ellipsoid Point with Uncertainty Ellipse
Polygon
Ellipsoid Arc
Reference coordinates
Coverage area and Description of radio cell
Octets
Sub-clause in
7 to 12
7 to 16
7 to 31
7 to 18
7 to 12
7 to 18
[[53]] N3-A.6.1.1
[[53]] N3-A.6.1.2
[[53]] N3-A.6.1.3
[[53]] N3-A.6.1.4
[[54]] N3-A.6.4.2
[[54]] N3-A.6.4.1
For further details, please refer to the respective sub-clauses of Annex N3 of TR-Notruf [[53]] or
Vfg Nr. 14/2013 [[54]] as indicated in the last column.
For information on how to code the respective location elements to transmit them in the respective SIP UUI
Header Field (or, later on, in the ISUP UUI container), please refer to clause 6 of 3GPP TS 23.032 [[38]].
14.3.2 SIP Geolocation Header Field
The SIP Geolocation Header field is defined in RFC 6442 [89]. RFC 4119 [90] defines so called Presence
Information Data Format – Location Objects (PIDF-LO) which are used by RFC 6442 [89]. Further
PIDF-LO types are defined by RFC 5139 [[36]]. General information on how to constrain, represent and
interpret locations in a PIDF-LO are described in RFC 5491 [[37]].
Multiple location objects shall be supported.
14.3.2.1 General
The actual location information can either be transmitted as civic (see sub-clause 14.3.2.2) or geographic
location (see sub-clause 0).
The service provider ID according to Table 14-5 shall be transmitted alongside the location information for
both a geographic and a civic location.
Table 14-5: Service Provider ID
Content
Service Provider ID
Data-Type
Hexadecimal
Value Range
4 characters
Reference
[[53]]
The IETF Draft draft-ietf-ecrit-additional-data-11 [[33]] shall be used to transmit the service provider ID.
Table 14-6: Additional Data Parameters
Parameter
Anbieterkennung/Portierungskennung
Data Provider (=”BNetzA”)
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
SIP (Additional Data)
ProviderID
DataProviderString
ProviderIDSeries
TypeOfProviderID
ContactURI
Seite 73 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
The PIDF-LO types “tuple”, “device” und “person” shall be used according to
Table 14-7.
Table 14-7: Usage of PIDF-LO types
PIDF-LO type
Description
tuple
used for location information determined and sent by the
network
device
used for location information determined and sent by the
end device
person
used for location information entered by the user and sent
by the end device
c1:
IF location information is sent from end device THEN m ELSE n/a
Support
m
c1
c1
If the PIDF-LO types “device” or “person” are present in a SIP message, they shall also be forwarded
transparently.
14.3.2.2 Civic Location
A civic location transmitted in the SIP Geolocation Header can contain more information as defined for the
User-to-User container in ISUP (see sub-clause 14.3.1). For the emergency call originating network
provider, the only mandatory location information elements for a civic location are Country, A1 (State) and
A3 (Town Name). However, any further location information needed to fully describe the civic location shall
also be transmitted in the corresponding PIDF-LO Element. The encoding is described in Table 14-8 and is
based on RFC 4119 [90] and RFC 5139 [[36]].
Table 14-8: PIDF-LO Encoding of a Civic Location
PIDF-LO
Content
Example
Element
Land nach ISO 3166
DE
Country
Bundesland
HE
A1
Landkreisname
Darmstadt
A2
Gemeindename
Darmstadt
A3
Ortsteilname
A4
Amtlicher Gemeindeschlüssel Notruf
06 4 11 000a
A5
(AGS N)
Straßenname ohne
HeinrichA6
Zusatz
HertzZusatz zu Straßenname Str.
STS
Data-Type
UTF-8 string
UTF-8 string
UTF-8 string
UTF-8 string
UTF-8 string
c1
UTF-8 string
c1
UTF-8 string
Hausnummer
3
Integer
HNS
Hausnummer Zusatz
-7
UTF-8 string
FLR
UNIT
ROOM
BLD
LMK
LOC
c1:
Postleitzahl
64295
Parametertype
m
m
c1
m
c1
UTF-8 string
HNO
PC
Value
Range
“DE”
Integer
c1
4 digits
0–9
c1
c1
5 digits
0–9
c1
Stockwerk
4
UTF-8 string
c1
Einheit
D1
UTF-8 string
c1
Raumnummer
4.D1.14
UTF-8 string
c1
Gebäude
UTF-8 string
c1
Name des
Deutsche
UTF-8 string
c1
Unternehmens
Telekom
Zusätzliche
TZ RheinUTF-8 string
c1
Informationen
Main
IF appropriate data for the respective PIDF-LO Element is needed to fully describe
the civic location, THEN m, ELSE n/a
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 74 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
14.3.2.3 Geographic Location
The SIP Geolocation Header Field can also be used to transmit a geographic location. Therefore, the
Geography Markup Language (GML), which is an application of XML, is used. According to Annex I4 of
TR-Notruf [[53]], the following different geographic location formats as defined in Table 14-9 may be used.
Table 14-9: Encoding of a Geographic Location
Geographic Location Format
Reference clause / annex in
RFC 5491 [[37]]
TR-Notruf [[53]]
RFC 5491 [[37]]
This document
Point
Geographische Koordinate
5.2.1
14.3.2.3.1
Ellipse
Geographische Koordinate mit
Unsicherheitsellipse
5.2.4
14.3.2.3.2
Polygon
Polygon
5.2.2
14.3.2.3.3
Arc Band
Gebiet mittels Kreisringsegment
5.2.5
14.3.2.3.4
n/a
Beschreibung der Funkzelle
n/a
14.3.2.3.5
A description and an encoding example for each of these different formats are given in the following subclauses. Requirements on how to transmit a Mobile Radio Cell Identification and a Confidence value (which
can both be used independently of the actual geographic location format) can be found in sub-clauses
14.3.2.3.6 and 14.3.2.3.7. Please note that these descriptions and examples are in accordance with
3GPP TS 23.032 [[39]] and OGC 06-142r1 [[40]].
14.3.2.3.1
Point
14.3.2.3.1.1
Description
The description of a point is that of a point on the surface of the ellipsoid, and consists of a latitude and a
longitude. In practice, such a description can be used to refer to a point on the Earth’s surface, or close to
the Earth’s surface, with the same longitude and latitude. In order to transmit the height of a point, the
altitude may additionally be given as description.
Figure 14-1 illustrates a point on the surface of the ellipsoid and its coordinates.
Figure 14-1: Description of a point as two coordinates
The latitude is the angle between the equatorial plane and the perpendicular to the plane tangent to the
ellipsoid surface at the point. Positive latitudes correspond to the North hemisphere. The longitude is the
angle between the half-plane determined by the Greenwich meridian and the half-plane defined by the
point and the polar axis, measured eastward.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 75 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
14.3.2.3.1.2
Exemplary Encoding
A point may be specified using either ETRS89 (latitude, longitude) or ETRS89 (latitude, longitude, altitude).
This is shown in the following examples:
<gml:Point srsName="urn:ogc:def:crs:EPSG::4258"
xmlns:gml="http://www.opengis.net/gml">
<gml:pos>-34.407 150.883</gml:pos>
</gml:Point>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4937"
xmlns:gml="http://www.opengis.net/gml">
<gml:pos>-34.407 150.883 24.8</gml:pos>
</gml:Point>
14.3.2.3.2
Ellipse
14.3.2.3.2.2
Description
The ellipse is characterised by the coordinates of a point (the origin), distances r1 and r2 and an angle of
orientation A. It describes formally the set of points on the ellipsoid which fall within or on the boundary of
an ellipse with semi-major axis of length r1 oriented at angle A (0 to 180°) measure clockwise from north
and semi-minor axis of length r2, the distances being the geodesic distance over the ellipsoid, i.e., the
minimum length of a path staying on the ellipsoid and joining the two points, as shown in Figure 14-2.
As for the point, this can be used to indicate points on the Earth’s surface, or near the Earth’s surface, of
same latitude and longitude. The confidence level with which the position of a target entity is included
within this set of points is also included with this shape.
The typical use of this shape is to indicate a point when its position is known only with a limited accuracy,
but the geometrical contributions to uncertainty can be quantified.
North
angle, A
semi-major
axis, r1
semi-minor
axis, r2
Figure 14-2: Description of an Ellipse
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 76 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
14.3.2.3.2.2
Exemplary Encoding
The following example shows an ellipse.
<gs:Ellipse srsName="urn:ogc:def:crs:EPSG::4937"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml">
<gml:pos>
42.5463 -73.2512 26.3
</gml:pos>
<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
7.7156
</gs:semiMajorAxis>
<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
3.31
</gs:semiMinorAxis>
<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
142
</gs:orientation>
</gs:Ellipse>
14.3.2.3.3
Polygon
14.3.2.3.3.1
Description
A polygon is an arbitrary shape described by an ordered series of points (in the example pictured in Figure
14-3, A to E).
The minimum number of points allowed is 3, and the maximum number of points allowed is 15. The points
shall be connected in the order that they are given. A connecting line is defined as the line over the
ellipsoid joining the two points and of minimum distance (geodesic). The last point is connected to the first.
The list of points shall respect a number of conditions:
• a connecting line shall not cross another connecting line;
• two successive points must not be diametrically opposed on the ellipsoid.
The described area is situated to the right of the lines with the downward direction being toward the Earth’s
centre and the forward direction being from a point to the next.
C
B
E
A
D
Figure 14-3: Description of a Polygon
Note:
This definition does not permit connecting lines greater than roughly 20 000 km. If such a need arises, the
polygon can be described by adding an intermediate point.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 77 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
14.3.2.3.3.2
Exemplary Encoding
The following example shows a polygon that is specified using EPSG 4258 and the gml:pos element.
No altitude is included in this example, indicating that altitude is unknown.
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4258"
xmlns:gml="http://www.opengis.net/gml">
<gml:exterior>
<gml:LinearRing>
<gml:pos>42.556844 -73.248157</gml:pos>
<gml:pos>42.549631 -73.237283</gml:pos>
<gml:pos>42.539087 -73.240328</gml:pos>
<gml:pos>42.535756 -73.254242</gml:pos>
<gml:pos>42.542969 -73.265115</gml:pos>
<gml:pos>42.553513 -73.262075</gml:pos>
<gml:pos>42.556844 -73.248157</gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
The following alternative example shows the same polygon with a constant altitude included that is
specified using EPSG 4937 and the gml:posList element.
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4937"
xmlns:gml="http://www.opengis.net/gml">
<gml:exterior>
<gml:LinearRing>
<gml:posList>
42.556844 -73.248157 36.6
42.549631 -73.237283 36.6
42.539087 -73.240328 36.6
42.535756 -73.254242 36.6
42.542969 -73.265115 36.6
42.553513 -73.262075 36.6
42.556844 -73.248157 36.6
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
The gml:posList element is interpreted as a list with the dimension of the CRS indicating how many
values are required for each point.
14.3.2.3.4
Arc Band
14.3.2.3.4.1
Description
An arc band is a shape characterised by the coordinates of a point o (the origin), inner radius r1
2
(gs:innerRadius), uncertainty radius r2 (gs:outerRadius), both radii being geodesic distances over the
surface of the ellipsoid, the offset angle θ (gs:startAngle) between the first defining radius of the arc band
and North, and the included angle β (gs:openingAngle) being the angle between the first and second
defining radii. The offset angle is within the range of 0° to 359,999b° while the included angle is within the
range from 0,000b1° to 360°. This is to be able to describe a full circle, 0° to 360°.
2
Thus the outer radius is r1+r2.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 78 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
North
Point (o)
θ
β
r1
r2
Figure 14-4: Description of an Arc Band
This shape definition can also be used to describe a sector (inner radius equal to zero), a circle (included
angle equal to 360°) and other circular shaped areas.
14.3.2.3.4.2
Exemplary Encoding
The following example includes an arc band shape. This Arc Band starts at 266 degrees and has a
120 degree opening; therefore, the end of the Arc Band is at a 26 degree bearing.
<gs:ArcBand srsName="urn:ogc:def:crs:EPSG::4258"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml">
<gml:pos>
42.5463 -73.2512
</gml:pos>
<gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001">
1661.55
</gs:innerRadius>
<gs:outerRadius uom="urn:ogc:def:uom:EPSG::9001">
2215.4
</gs:outerRadius>
<gs:startAngle uom="urn:ogc:def:uom:EPSG::9102">
266
</gs:startAngle>
<gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102">
120
</gs:openingAngle>
</gs:ArcBand>
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 79 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
14.3.2.3.5
Description of radio cell
A radio cell can either be geographically described as:
• balance point of the area of the radio cell (see sub-clause 14.3.2.3.5.1)
or as
• unique description of the radio cell (see clause 14.3.2.3.6).
14.3.2.3.5.1
Balance Point of the Area of the Radio Cell
The balance point of the area of the radio cell can be described using the latitude and longitude of the
geographic coordinates of the balance point of the coverage area. The description of the dimension of the
radio cell can be realized using an ellipse referring to the balance point of the radio cell according to
clause 14.3.2.3.2.
14.3.2.3.6
Mobile Radio Cell identification
The following statements are in accordance with 3GPP TS 23.003 [[39]].
The Location Area Identification (LAI) is composed of the following elements:
• A Mobile Country Code (MCC) identifies the country in which the PLMN is located. The value of the
MCC is the same as the three digit MCC contained in international mobile subscriber identity
(IMSI);
• a Mobile Network Code (MNC) is a code identifying the PLMN in that country. The MNC takes the
same value as the two or three digit MNC contained in IMSI;
Note: In Germany, the MNC is only a two digit code. According to Annex N3-A6.3.3.1 of
TR-Notruf [[53]], the third digit is hard coded as hexadecimal F and
• a Location Area Code (LAC) is a fixed length code (of 2 octets) identifying a location area within a
PLMN. This part of the location area identification can be coded using a full hexadecimal
representation except for the following reserved hexadecimal values 0000 and FFFE.
The BSS and cell within the BSS are identified within a location area or routeing area by adding a Cell
Identity (CI) to the location area identification, as shown in the following Figure 14-5. The CI is of fixed
length with 2 octets and it can be coded using a full hexadecimal representation.
The Cell Global Identification (CGI) is the concatenation of the LAI and the CI. The Cell Identity shall be
unique within a location area.
MCC
MNC
CI
LAC
Location Area Identification
Cell Global Identification (CGI)
Figure 14-5: Cell Global Identification
The CGI is transmitted in a hexadecimal representation as Additional Code (ADDCODE) as a civicAddress
in the PIDF-LO alongside a(n) (additional) Location Element (LOC) set to "Mobilfunkzelle" as shown in the
following example:
<cl:civicAddress xml:lang="de">
<cl:LOC>Mobilfunkzelle</cl:LOC>
<cl:ADDCODE>26201F1080939A</cl:ADDCODE>
</cl:civicAddress>
The Location Element (LOC) indicates that this PIDF-LO is the identifier of a mobile radio cell.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 80 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
14.3.2.3.7
Confidence
According to draft-thomson-geopriv-confidence-03 [[41]], the confidence is transmitted as separate element
within the location-info of the PIDF-LO. The confidence element expresses the confidence in the
associated location information as a percentage and optionally includes an attribute that indicates the
shape of the probability density function (PDF) of the associated region of uncertainty. Three values are
possible for the shape of this PDF: unknown, normal and rectangular.
Further details on how to obtain or ascertain uncertainty and confidence can be found in draft-thomsongeopriv-uncertainty-07 [[42]].
An exemplary encoding for a confidence of 75% which follows a normal distribution is shown below for a
circular shape:
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4258">
<gml:pos>42.5463 -73.2512</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
850.24
</gs:radius>
</gs:Circle>
<con:confidence pdf="normal">75</con:confidence>
</gp:location-info>
14.4 Exemplary Encoding
14.4.1 Civic Location
This sub-clause contains an exemplary encoding of excerpts of a SIP Message including SDP with location
information for the civic location
• Bundesland: Hessen
• Landkreis: Darmstadt
• Gemeinde: Darmstadt
• Amtlicher Gemeindeschlüssel Notruf: 06411000a
• Straße: Heinrich-Hertz-Str.
• Hausnummer: 3-7
• Postleitzahl: 64295
• Stockwerk: 4
• Einheit: E2
• Raum: 4.E2.04
• Name des Unternehmens: Deutsche Telekom
• Zusätzliche Informationen: TZ Rhein-Main
for the transmission in the both the SIP UUI Header Field and the SIP Geolocation Header Field including
the PIDF-LO format
and the Service Provider ID
• Service Provider ID: D150
for the transmission as additional-data, respectively.
INVITE sip:[email protected]; user=phone SIP/2.0
Via: SIP/2.0/TCP 1.2.3.4:5060;branch=z9hG4bKfe07342047384
Max-Forwards: 65
To: <sip:[email protected]:5060;user=phone>
From: <sip:[email protected];user=phone>;tag=a3096f28
Call-ID: [email protected]
Call-Info: <cid:[email protected]>;purpose=emergencyCallData
Geolocation: <cid:[email protected]>
P-Asserted-Identity: <sip:[email protected];user=phone>
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 81 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Content-Type: multipart/mixed; boundary=boundary1
User-to-User: 001D05304692F5F3FFFF4865696E726963682D486572747A2D5374722E;
encoding=hex; purpose=isdn-uui
--boundary1
Content-Type: application/sdp
m=audio 35564 RTP/AVP 9 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
--boundary1
Content-Type: application/pidf+xml
Content-ID: <[email protected]>
<?xml version="1.0" encoding="UTF-8"?>
<presence
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
entity="pres:[email protected]">
<tuple id="abcd123456">
<status>
<gp:geopriv>
<gp:location-info>
<cl:civicAddress xml:lang="de">
<cl:country>DE</cl:country>
<cl:A1>HE</cl:A1>
<cl:A2>Darmstadt</cl:A2>
<cl:A3>Darmstadt</cl:A3>
<cl:A5>06411000a</cl:A5>
<cl:A6>Heinrich-Hertz-</cl:A6>
<cl:STS>Str.</cl:STS>
<cl:HNO>3</cl:HNO>
<cl:HNS>-7</cl:HNS>
<cl:PC>64295</cl:PC>
<cl:FLR>4</cl:FLR>
<cl:UNIT>E2</cl:UNIT>
<cl:ROOM>4.E2.04</cl:ROOM>
<cl:LMK>Deutsche Telekom</cl:LMK>
<cl:LOC>TZ Rhein-Main</cl:LOC>
</cl:civicAddress>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>yes</gp:retransmission-allowed>
<gp:retention-expiry>2013-08-31T12:00:00Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2013-08-01T12:00:00Z</timestamp>
</tuple>
</presence>
--boundary1
Content-Type: application/emergencyCall.ProviderInfo+xml
Content-ID: <[email protected]>
<?xml version="1.0" encoding="UTF-8"?>
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 82 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
<emergencyCall.ProviderInfo
xmlns="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo">
<DataProviderString>Telekom</DataProviderString>
<ProviderID>D150</ProviderID>
<contactURI>sip:[email protected];user=phone</contactURI>
<ProviderIDSeries>BNetzA</ProviderIDSeries>
</emergencyCall.ProviderInfo>
--boundary1-Note 1:
The two parameters “encoding” and “purpose” in the SIP UUI Header Field are optional and need not
necessarily be present (see sub-clause 14.3.1.1 as well as [126] and [126A]). Both the parameter name
and the length indicator (which would be 201D for the example above) are not transmitted in the
SIP User-to-User Header Field and will subsequently be added by the MGC into the ISUP UUI container.
14.4.2 Ellipsoid Arc/Arc Band
This sub-clause contains an exemplary encoding of excerpts of a SIP Message including SDP with location
information as a geographic location as an Ellipsoid Arc for the radio tower Darmstadt-Weiterstadt
• Description of Location Information: 75 (Ellipsoid arc)
• Latitude: 49° 53’ 48’’
• Longitude: 08° 37’ 22’’
3
• Inner radius: r1=0m (N = 0)
• Uncertainty radius: r2=2005m (K = 56 (Hexadecimal 0x38))3
• Offset angle: θ = 328° (N=164 (Hexadecimal 0xA4); 328° ≤ θ ≤ 330°)3
• Included angle: β = 64° (N=32 (Hexadecimal 0x20); 64° ≤ β ≤ 66°)3
• Confidence: 100% requested (Hexadecimal 0x64) 3
• Mobile Country Code (MCC): 262 (Germany)
• Mobile Network Code (MNC): 01F (Telekom Deutschland)
• Location Area Code (LAC): 4224 (Hexadecimal 0x1080)
• Cell Identity (CI): 37786 (Hexadecimal 0x939A)
for the transmission in the both the SIP UUI Header Field and the SIP Geolocation Header Field including
PIDF-LO format
and the Service Provider ID
• Service Provider ID: D124
for the transmission as additional-data, respectively.
INVITE sip:[email protected]; user=phone SIP/2.0
Via: SIP/2.0/TCP 1.2.3.4:5060;branch=z9hG4bKfe07342047384
Max-Forwards: 65
To: <sip:[email protected]:5060;user=phone>
From: <sip:[email protected];user=phone>;tag=a3096f28
Call-ID: [email protected]
Call-Info: <cid:[email protected]>;purpose=emergencyCallData
Geolocation: <cid:[email protected]>
P-Asserted-Identity: <sip:[email protected];user=phone>
Content-Type: multipart/mixed; boundary=boundary1
User-to-User: 001D4275943584807322000038A420640062F210010839A9; encoding=hex;
purpose=isdn-uui
--boundary1
Content-Type: application/sdp
m=audio 49120 RTP/AVP 97 8 101
3
For information on how to convert the actual location values into the values in brackets and v.v., please
refer to clause 6 of 3GPP TS 23.032.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 83 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-change-capability=2
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
--boundary1
Content-Type: application/pidf+xml
Content-ID: <[email protected]>
<?xml version="1.0" encoding="UTF-8"?>
<presence
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
entity="pres:[email protected]">
<tuple id="arcband">
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gs:ArcBand srsName="urn:ogc:def:crs:EPSG::4326"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml">
<gml:pos>
49.8967 8.6228
</gml:pos>
<gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001">
0
</gs:innerRadius>
<gs:outerRadius uom="urn:ogc:def:uom:EPSG::9001">
2005
</gs:outerRadius>
<gs:startAngle uom="urn:ogc:def:uom:EPSG::9102">
328
</gs:startAngle>
<gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102">
64
</gs:openingAngle>
</gs:ArcBand>
</gml:location>
<con:confidence>100</con:confidence>
<cl:civicAddress xml:lang="de">
<cl:LOC>Mobilfunkzelle</cl:LOC>
<cl:ADDCODE>26201F1080939A</cl:ADDCODE>
</cl:civicAddress>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>yes</gp:retransmission-allowed>
<gp:retention-expiry>2013-08-31T12:00:00Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2013-08-01T12:00:00Z</timestamp>
</tuple>
</presence>
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 84 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
--boundary1
Content-Type: application/emergencyCall.ProviderInfo+xml
Content-ID: <[email protected]>
<?xml version="1.0" encoding="UTF-8"?>
<emergencyCall.ProviderInfo
xmlns="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo">
<DataProviderString>Telekom Deutschland</DataProviderString>
<ProviderID>D124</ProviderID>
<contactURI>sip:[email protected];user=phone</contactURI>
<ProviderIDSeries>BNetzA</ProviderIDSeries>
</emergencyCall.ProviderInfo>
--boundary1-Note 1:
The two parameters “encoding” and “purpose” in the SIP UUI Header Field are optional and need not
necessarily be present (see sub-clause 14.3.1.1 as well as [126] and [126A]). Both the parameter name
and the length indicator (which would be 2018 for the example above) are not transmitted in the SIP Userto-User Header Field and will subsequently be added by the MGC into the ISUP UUI container.
14.5 Emergency Calls for Voice Service Provider
This topic is ffs.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 85 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Annex A Address Formats (informative)
A.1 Number Portability
Settings:
B: 0911 7654321
Ported to Provider B with
Porting Identifier D987
A: 06151 1234567
Provider A
DB
INVITE sip: +49 911 7654321; npdi; rn = +49 D987 911 7654321
7654321 @ provider_b.de; user = phone
From: <sip: +49 6151 1234567 @ provider_a.de; user = phone>
To: <sip: +49 911 7654321 @ provider_a.de; user = phone>
P-Asserted-Identity: <sip: +49 6151 1234567 @ provider_a.de;
provider_a.de; user = phone>
…
Provider B
DB
A
B
Figure A-1: Number Portability with Routing Number
A.2 Emergency Calls
Settings:
PSAP
06151CC23
A: 06151 1234567
Provider A
DB
INVITE sip: +49 1984 6151 23; rn = +49 6151 CC23 @
provider_b.de; user = phone
From: <sip: +49 6151 1234567 @ provider_a.de; user =
phone>
To: <sip: 110 @ provider_a.de; user = phone>
P-Asserted-Identity: <sip: +49 6151 1234567 @
provider_a.de; user = phone>
…
A
Provider B
DB
B
Figure A-2: Emergency Call with Routing Number
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 86 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Annex B SIP/SDP MIME Type Signalling on the Ic-Interface
(informative)
Scope:
This chapter depicts some exemplary coding regarding SIP/SDP MIME Type Signalling at the
Ic-Interface.
For VoIP applications the following top level media types and subtypes are used
1.) Content-Type application/SDP is used according to [[51]] for SDP.
Example:
Content-Type: application/sdp
Content-Length: 154
v=0
o=alice 2890844526 2890844526 IN IP4 client.a.example.com
s=c=IN IP4 client.a.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
2. ) Content-Type application/ISUP is used according to [[29]] for encapsulation of ISUP in
MIME bodies.
Example:
Content-Type: application/ISUP; version=nxv3;
base=etsi121
Content-Disposition: signal; handling=optional
01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00
3.) Content-Type multipart/mixed is used according to [[29]] for the transport of multiple
different MIME bodies in a SIP message.
Example:
Content-Type: multipart/mixed; boundary=unique-boundary-1
MIME-Version: 1.0
--unique-boundary-1
Content-Type: application/SDP; charset=ISO-10646
v=0
o=jpeterson 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP seminar
c=IN IP4 MG122.level3.com
t= 2873397496 2873404696
m=audio 9092 RTP/AVP 0 3 4
--unique-boundary-1
Content-Type: application/ISUP; version=nxv3;
base=etsi121
Content-Disposition: signal; handling=optional
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 87 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00
--unique-boundary-1—
4.) Content-Type application/vnd.etsi.pstn+xml is used according to [[44]] for the transport of
PSTN/ISDN information.
Example:
Content-type: application/vnd.etsi.pstn+xml
Content-Disposition: signal; handling=optional
<?xml version="1.0" encoding="utf-8"?>
<tns:PSTN xmlns:tns="http://uri.etsi.org/ngn/params/xml/simservs/pstn"
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
<tns:BearerCapability>
<tns:BCoctet3>
<tns:CodingStandard>00</tns:CodingStandard>
<tns:InformationTransferCabability>
00000
</tns:InformationTransferCabability>
</tns:BCoctet3>
<tns:BCoctet4>
<tns:TransferMode>00</tns:TransferMode>
<tns:InformationTransferRate>10000</tns:InformationTransferRate>
</tns:BCoctet4>
<tns:BCoctet5>
<tns:Layer1Identification>01</tns:Layer1Identification>
<tns:UserInfoLayer1Protocol>10000</tns:UserInfoLayer1Protocol>
</tns:BCoctet5>
</tns:BearerCapability>
</tns:PSTN>
5.) Content-Type application/vnd.etsi.sci+xml is used according to [[22]] in a 183 Session
Progress or INFO Request to transmit tariff information on the Ic-Interface
Example:
Content-type: application/vnd.etsi.sci+xml
<?xml version="1.0" encoding="utf-8"?>
<tns:messageType xmlns:tns="http://uri.etsi.org/ngn/params/xml/simservs/sci"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<tns:crgt>
<tns:chargingControlIndicators>
<tns:immediateChangeOfActuallyAppliedTariff>
1
</tns:immediateChangeOfActuallyAppliedTariff>
</tns:chargingControlIndicators>
<tns:chargingTariff>
<tns:tariffCurrency>
<tns:currentTariffCurrency>
<tns:communicationChargeSequenceCurrency>
<tns:currencyFactorScale>
<tns:currencyFactor>27</tns:currencyFactor>
<tns:currencyScale>-7</tns:currencyScale>
</tns:currencyFactorScale>
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 88 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
<tns:tariffDuration>0</tns:tariffDuration>
<tns:subTariffControl>1</tns:subTariffControl>
<tns:tariffControlIndicators>
0
</tns:tariffControlIndicators>
</tns:communicationChargeSequenceCurrency>
</tns:currentTariffCurrency>
</tns:tariffCurrency>
</tns:chargingTariff>
<tns:originationIdentification>
<tns:networkIdentification>028207021F7F</tns:networkIdentification>
<tns:referenceID>4711</tns:referenceID>
</tns:originationIdentification>
<tns:currency>EUR</tns:currency>
</tns:crgt>
</tns:messageType>
6.) Content-Type application/vnd.etsi.cug+xml is used according to [[20]] in an initial INVITE
to exchange CUG data
Example
Content-type: application/vnd.etsi.cug+xml
<?xml version="1.0" encoding="utf-8"?>
<simservs
xmlns= http://uri.etsi.org/ngn/params/xml/simservs/xcapu
xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:ocp="urn:oma:xml:xdm:common-policy">
<cug>
<networkIndicator>0940</networkIndicator>
<cugInterlockBinaryCode>4711</cugInterlockBinaryCode>
<cugCommunicationIndicator>11</cugCommunicationIndicator>
</cug>
</simservs>
According to [[43]], chapter 5.10.6.3 the IBCF can screen the SIP message body and modify it
appropriately.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 89 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Annex C Forward Address Signalling (informative)
C.1 General
This subclause explains the overlap signalling impacts on the core entities of the IM CN subsystem.
The support of overlap signalling and each of the overlap signalling method within the IM CN subsystem
are optional and is dependent on the network policy.
Only one overlap signalling method shall be used within one IM CN subsystem.
C.2 Overlap Signalling Methods
C.2.1 In-dialogue Method
not applicable
C.2.2 Multiple-INVITE Method
C.2.2.1 General
The multiple-INVITE method uses INVITE requests with the same Call ID and From header in order to
transport digits (as specified in 3GPP TS 29.163 [11B]).
C.3 Routing Impacts
C.3.1 General
If overlap signalling is supported, the IM CN subsystem needs to be configured in such a manner that
erroneous routing of INVITE requests with incomplete numbers towards others entities than the
corresponding INVITE requests with full numbers is avoided, for instance towards a default destination for
unknown numbers such as a PSTN. Possibly impacted nodes include the S-CSCF for the UE-originated
case, the transit routing function, the I-CSCF, and application servers.
A misrouting can be avoided by configuring the entity sending overlap signalling in such a manner that it
will send the first INVITE request with a sufficient number of digits to find a suitable entry in the translation
database. If ENUM is used, the ENUM database in a typical deployment contains sufficient information
about the first digits, as required to identify the destination IP domain. Therefore, ENUM is able to handle
incomplete numbers in such deployments. As another alternative, the routing entity can reject calls with
unknown numbers with a 404 (Not Found) response, using entries in the routing database to identify calls
towards the PSTN. The S-CSCF for the UE-originated case could also forward calls with unknown numbers
to the BGCF, if the BGCF is configured to reject calls to unknown destinations with a 404 (Not Found)
response.
C.3.2 Deterministic Routing
If the multiple-INVITE method is used for overlap signalling, if an entity receives an INVITE request outside
an existing dialogue with the same Call ID and From header as a previous INVITE request during a certain
period of time, the entity shall route the new INVITE request to the same next hop as the previous INVITE
request.
Note: INVITE requests with the same Call ID and From header fields received in sequence during a
certain period of time belong to the same call. The routing towards the same next hop could be achieved by
an appropriately configured database or by the entity comparing the Call ID and From header fields of each
INVITE request outside an existing dialogue with Call IDs and tag From header field parameters of
previous INVITE requests. If the entity compares the Call ID and From header, it stores the information
about received Call ID and From headers at least for a time in the order of call setup times. If paths have
been established at registration time, deterministic routing will be automatic for entities on these paths.
C.3.3 Digit Collection
Entities performing routing decisions may require additional digits for a decision where to route an
INVITE request. These entities may interact with a routing database to reach this decision.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 90 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
If no suitable entry in a database is found for the digits received in an INVITE request, an entity can reject
the INVITE request with a 404 (Not Found) or 484 (Address Incomplete) response. This method of digit
collection can be performed by a SIP proxy and is suitable both for the in-dialogue and multiple-INVITE
overlap signalling methods. Replying with a 404 (Not Found) response avoids the need to keep apart
incomplete and unknown numbers. The 484 (Address Incomplete) response requires the recognition of
incomplete numbers.
Note: An HSS does not support the recognition of incomplete numbers. A routing database being queried
by ENUM also does not support the recognition of incomplete numbers.
As an alternative for the in-dialogue method, the digit collection function described in annex N.2 may be
invoked. It shall be performed by an entity acting as a B2BUA. The digit collection function requires the
ability to recognise incomplete number.
Only the clause 4.9 and ANNEX N of [[4]] is applicable for the current specification.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 91 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Annex D Calling Party’s Category (normative)
This annex describes the “cpc” URI parameter for use in SIP requests and is based on [95].
D.1 Introduction
In ISUP, a cpc parameter is defined which characterizes the station at which a call was originated and
carries other information which can describe the originating party. For example if a call is originated from a
payphone a call can be handled in a specific way. When telephone numbers are contained in URIs, e.g. in
tel URI or equivalent SIP URI it may be necessary to transmit any cpc associated to that telephone
number. Such a method is described in this annex (see the IETF Draft given above for further details).
It is an option to set up the CPC parameter.
D.2 Definition
The Calling Party’s Category is represented as URI parameter for the tel URI scheme and SIP URI
representation of telephone numbers. The ABNF syntax is as follows and extends the formal syntax for the
tel URI as specified in RFC 3966:
par
cpc
cpc-tag
cpc-value
genvalue
=/ cpc
= cpc-tag “=” cpc-value
= “cpc”
= “ordinary” / “test” / “operator” / “payphone” /
“unknown” / “mobile-hplmn” / “mobile-vplmn” / genvalue
= 1*(alphanum / “-” / “.”)
The semantics of these Calling Party’s Category values are described below:
ordinary:
The caller has been identified, and has no special features.
test:
This is a test call that has been originated as part of a maintenance procedure.
operator:
The call was generated by an operator position.
payphone:
The calling station is a payphone.
unknown:
The CPC could not be ascertained.
mobile-hplmn: The call was generated by a mobile device in its home PLMN.
mobile-vplmn: The call was generated by a mobile device in a visited PLMN.
The detection of a public phone as A-party can only be done using the cpc parameter in the
P-Asserted-Identity Header of an Invite-message.
D.3 Transmission
When received in a SIP request, the cpc parameter shall be transmitted transparently through the network
and shall not be discarded.
D.4 Interworking
The SIP/ISUP interworking of the cpc parameter shall be done as described in 3GPP TS 29.163, Annex C.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 92 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
D.5 Example
One example for the use of the cpc parameter is the following:
Public
phone
(booth)
NGN
Service
Provider
Figure D-1: Example for the use of the cpc parameter
Invite sip: +49 800 1234567 @ operator.de; user=phone
P-Asserted-Identity: <sip:+493087654321; cpc=payphone@a-domain;
user=phone>
To: < sip: +49 800 1234567@a-domain; user=phone>
From: “Name“<sip: +493087654321@a-domain; user=phone>
….
Consider that the A-party calls a freephone number (0800 or 00800) from a payphone. It is possible to
charge an additional fee (the payphone access charge, PAC) besides the delivery fee, which has to be paid
by the service provider (B-party), if the call originated from a payphone. This PAC is charged as an
additional fee per minute and is booked to the split second.
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 93 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Annex E Nationally Ported International Service Numbers
(informative)
To distinguish ported International Service Numbers (see chapter 7.1.2.8) from ported National Service
Numbers, the following format
sip: +<International Service Number> [;npdi] ;rn=+49 D<xyz> 0 <International
Service Number> @ <host portion>; user=phone
including an additional “0” in the rn-Parameter between Porting Identifier D<xyz> and International Service
Number shall be used for ported International Service Numbers.
An exemplary SIP Request URI is shown below:
sip:+80012345678;npdi;[email protected];user=phone
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Seite 94 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Annex F Abbreviations and Terms
F.1 Abbreviations
Abbreviation
Explanation
A-BGF
Access-Border Gateway Function, definition: see C-BGF:
ABNF
Augmented Backus–Naur Form
ACR
Anonymous Communication Rejection
AGS
Allgemeiner Gemeindeschlüssel
B2BUA
Back to Back User Agent
BNetzA
Bundesnetzagentur
BSS
Base Station Subsystem
C-BGF
Core-Border Gateway Function
CAT
Customised Alerting Tone
CB
Communication Barring
CCNL
Call Completion on Not Logged-In
CDIV
Call Diversion Service
CGI
Cell Global Identification
CI
Cell Identity
CRS
Customised Ringing Tone
CSCF
Call Session Control Function
CUG
Closed User Group
ECT
Explicit Communication Transfer
ENUM
E.164 Number Mapping
ffs
for further study
GML
Geographic Markup Language
HDSW
Harmonised Services of Social Value (z.B. Sperrnotruf)
HSS
Home Subscriber Service
I-BGF
Interconnect Border Gateway Function
IBCF
Interconnect Border Control Function
IC
Interconnection
Ic
Reference Point between IBCF of two networks (Referenzpunkt zwischen
IBCF zweier Netze)
IMSI
International Mobile Subscriber Identity
Iz
Reference Point between I-BGF of two networks (Referenzpunkt
zwischen I-BGF zweier Netze)
IVR
Interactive Voice Response System
Iw
Reference Point between Interworking function and other networks
(Referenzpunkt zwischen Interworkingfunktion und anderen IP-Netzen)
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.1014
Source
[[3]]
[[2]]
[[2]]
Seite 95 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
LAC
Location Area Code
LAI
Location Area Identification
MCC
Mobile Country Code
MGC
Media Gateway Controller
MNC
Mobile Network Code
MCID
Malicious Communication Identification
MIME
Multipurpose Internet Mail Extensions
MRF
Multimedia Resource Function
MSB
Most Significant Bit
MSV
Mobilfunk Service Vorwahl
MWI
Message Waiting Indication
NDC
National Destination Code
NGCN
Next Generation Corporate Networks
NGN
Next Generation Networks
NNI
Network Network Interface
OIP
Originating Identification Presentation
OIR
Originating Identification Restriction
ONKZ
Ortsnetzkennzahl (NDC)
oTNB
originating Network Provider (Ursprungsteilnehmernetzbetreiber)
P-CSCF
Proxy CSCF
PAC
Payphone Access Charge
PSAP
Public Safety Answering Point (Notrufabfragestelle)
RTCP
RealTime Control Protocol
SDP
Session Description Protocol
SIP
Session Initiation Protocol
THIG
Topology Hiding Inter-network Gateway
TIP
Terminating Identification Presentation
TIR
Originating Identification Restriction
UA
User Agent
URI
Uniform Resource Identifier
UUS
User to User Signalling
VLN
Verkehrslenkungsnummer (routing prefix)
VoNGN
Voice over Next Generation Networks
VPLMN
Visited PLMN
VSP
Voice Service Provider
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
TS
23.228
Seite 96 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
F.2 Terms
Term
Definition
UAK-S: NGN Ic Interface
Ausgabestand: V1.0.0 vom 15.10.2014
Source
Seite 97 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx
Annex G Das Mandat des UAK Signalisierung (informative)
UAK-S:
S: NGN Ic Interface
Ausgabestand: V
V1.0.0 vom 15.10.2014
.2014
Seite 98 von 98
Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx