Professional Documents
Culture Documents
STUDENT GUIDE
Technical Support
Technical support hotline
If you have technical questions about running the course,
contact our Technical Support Hotline for help.
Hotline tips
If you do call or fax the hotline numbers, be prepared to identify the following information,
which will enable the hotline personnel to help you in the most efficient manner:
If all technical support personnel are busy, please leave a message and your call will be
returned by the next business day.
2. Trade Marks
Alcatel-Lucent and MainStreet are trademarks of Alcatel-Lucent.
All other trademarks, service marks and logos (Marks) are the property of their respective holders,
including Alcatel-Lucent. Users are not permitted to use these Marks without the prior consent of AlcatelLucent or such third party owning the Mark. The absence of a Mark identifier is not a representation that
a particular product or service name is not a Mark.
Alcatel-Lucent assumes no responsibility for the accuracy of the information presented herein, which may
be subject to change without notice.
Course Outline
0. Introduction
Course outline
About This Course
Course objectives
1. Applications Overview
Introduction
5060 ICS
5450 ISC
5450 IRC
5420 CTS
iHSS/iSLF
iAGCF
2. Network Architectures
Border Architecture
VoIP Emergency Services
Business Trunking
Lawful Intercept/CALEA
3. Performing OAM&P
Introduction
User Interfaces
Element Manager
4. Customer Documentation
Available Platform Documents
Available Application Documents
Digit codes of manuals
5. Hardware Overview
Advanced Telecommunications Computing
Architecture (ATCA)
Applications on the ATCA Platform
ATCA Hardware
6. Charging
iCCF
ACR Buffering Function
Metering Service (iCRF)
All Rights Reserved Alcatel-Lucent 2010
Release
5060 ICS
R2.0
5450 ISC
20.0
5420 CTS
R7.0
5400 LCP
R20.17
Remark
Welcome
Bienvenue
Bienvenidos
Willkommen
Benvenuti
Bem-vindo
Welkom
ATCA
All Rights Reserved Alcatel-Lucent 2010
Student Polling
Brief introduction of the participants :
Company?
Job responsibilities?
Experience?
Course Objectives
Upon completion of this course, you should be able to:
State the purpose of the 5060 ICS in the Alcatel-Lucent IMS solution.
Describe the functions of the applications with which the 5060 ICS is
equipped.
List the hardware components that support the 5060 ICS.
Identify the 5060 ICS documents in which specific OAM&P topics are covered.
10
Prerequisite Information
Participants are expected to have basic knowledge of:
Telecom principles
Data communication
IMS concepts
11
Blank Page
12
Applications overview
Module Objectives
After you have successfully completed this module you will be able to:
Describe the difference between function, application, platform and solution.
Match the applications that run on the 5400 LCP with the IMS Model
14
Module Outline
Applications Overview
Introduction
5060 ICS
5450 ISC
5420 CTS
iHSS
iAGCF
15
Blank Page
16
Instructor directive:
Additional information:
Applications Overview
Introduction
17
18
19
5420 Converged
Telephony Server
5450 IP Session
Controller
5450 IP Resource
Controller
20
21
This slide shows the application that are included in the 5060 IP Call Server.
22
Registration
Session IMS Origination
Session IMS Termination
Session IMS to PSTN
23
3
2
24
3
4
25
2
1
3
5.
6.
3
4
5
6
Media gateway
Control
1
Bearer traffic (RTP)
27
Media gateway
PSTN
3
6
9
7
5
5
10
11
Bearer traffic (RTP)
28
29
30
31
Supplementary services
Digit Manipulation
32
iHSS
5060 ICS only
33
iCCF:
iCCF
5060 ICS only
34
Charging
Messages
CCF
Media gateway
Control
Media gateway
35
PSTN
The LCP
5420 CTS TAS database
The HSS
The Web portal (5420 Personal
Communication Manager - PCM)
The voicemail system
36
Applications Overview
5060 ICS
37
The
It
38
ICS is the ALU product name for the new Integrated IMS solution offer to address Fixed NGN Class5 and
Transformation to IP solutions in a compact configuration. The primary strategy behind the ICS solution is to
address these two important customer market segments with the same software and hardware asset base.
The Fixed Next Generation Network (NGN) market segment is based primarily on softswitch technology. In this
segment, ICS can be positioned as a replacement to the Alcatel-Lucent 5020 MGC-10 and 5020 MGC-12
based Class 5 offerings which are expected to reach end-of-life during 2008. Many customers are interested in
replacing their existing Class 5 switches for cost reduction reasons, and possibly to begin migrating toward an
IP-based solution in order to deploy new revenue generating services.
ICS can also be positioned to address the IP transformation market segment where customers wish to migrate
toward an end-to-end IP and SIP solution. Some of these customers may not be interested in an IMS solution,
and others may be interested in an IMS solution, but do not need a distributed highly scalable solution like that
provided by the existing Alcatel-Lucent Distributed IMS solution. Alcatel-Lucent currently offers the Compact
IMS solution to address this market segment. The 5060 ICS will be offered in lieu of the Compact IMS solution
starting in release ICS 1.0.
The Fixed NGN offer is targeted at replacing Class 5 offices supporting, for example, existing POTS lines. Such
subscribers are not expected to need any special applications (e.g., 5420 PCM) as a result of the migration.
The IP Transformation offer provides more functionality to subscribers based on additional IMS applications
that are offered. Note that a given ICS deployment may support both Fixed NGN and IP Transformation
subscribers concurrently.
ICS - SIP
ISC
CTS
iHSS/iSLF
IRC
iCCF
iAGCF
ATCA
MGCF
39
MGCF
IN
MGC-8
All
ICS-MGC-10
MGCF
IN
MGCF
IN
ATCA
MGC-12
40
MGC can also include a Signaling Gateway function, for interfacing to the SS7 network:
1. Standalone Signaling Gateway: A SG/STP is deployed that supports the SS7 terminations to the network.
M3UA is used as the protocol between the SG and the MGCF in 5060 ICS.
2. Remote SS7 Terminations: The E1 signaling terminations are on the Media Gateway
in 5060 ICS.
41
Number normalization
Carrier selection
Digit manipulation
Call-processing logic (tight coupling)
Service logic to apply broad categories of services to the end users and
the network operators:
42
Builds the CDRs associated with the ICS-SIP shelf (CTS records only)
43
44
One or two ICS-SIP shelves in an SLF Group may be configured with an iSLF
database (referred to as iSLF-hosting ICS).
The two iSLF-hosting ICS shelves may be in a geographic redundant pair (from an ICS
perspective) or two non-geographic redundant shelves.
The iSLFs are not treated as a geographic redundant pair, but rather as load shared
45
Extends the reach of the IMS network to include analog terminals being
served by access gateways (AGWs):
46
47
NGN (ITU-T definition): A packet-based network able to provide telecommunication services and able to make
use of multiple broadband, QoS enabled transport technologies and in which service-related functions are
independent from underlying transport-related technologies. It offers unrestricted access by users to different
service providers. It supports generalized mobility which will allow consistent and ubiquitous provision of
services to users.
Fixed NGN additional aspect:
Support for TDM PBX and IP-PBX
Network interconnection
IP-PBX trunking
Wholesale transit
5060 ICS
ICS Solution
5060 ICS
Application
Layer
Operations and
Maintenance Center
iCCF
5420 CTS
Unified Messaging
OMCOMC-P
XMC
Residential Services
iCRF
5450 ISC
Session
Control
Layer
S-CSCF
Transit
P-CSCF
E-CSCF
BGCF
MRFC
MRFP
IBCF
iAGCF
1357 ULIS
5900 MRF
I-CSCF
IMC
LIG
IP/MPLS Network
5450 IRC
MGCF Shelf
7510 MGW
MGCMGC-X
MGCF
Media and
End Point
Layer
I-BGF
Fortinet
6850
OmniSwitch
Peer
IP Network
SFW
751x MGW
Peer
IMS Network
SGW
IMSIMS-MGW
SS7
PSTN/
PLMN
PRA PBX
48
H.248 LAG
5060 ICS
ICS Solution
5060 ICS
Application
Layer
Operations and
Maintenance Center
5420 PCM
5400 IAS
Web Portal
Presence,XDMS,MIM
iCCF
5420 CTS
OMCOMC-P
IP Centrex &
Residential Services
iCRF
XMC
Unified Messaging
5450 ISC
I-CSCF
P-CSCF
E-CSCF
1357 ULIS
5900 MRF
Transit
S-CSCF
MRFC
Session
Control
Layer
MRFP
IMC
LIG
BGCF
IP/MPLS Network
IBCF
iAGCF
5450 IRC
MGCF Shelf
MGCMGC-X
7510 MGW
MGCF
Media and
End Point
Layer
7510 MGW
A-BGF
6850
OmniSwitch
I-BGF
Fortinet
Peer
IP Network
SFW
751x MGW
Peer
IMS Network
SGW
IMSIMS-MGW
SS7
PSTN/
PLMN
49
PRA PBX
Residential
Business IP
IP PBX
SIP LAG
H.248 LAG
Access gateway
TDM (PSTN emulation)ISAM portfolio: Voice Gateway (VGW), Access
Gateway (AGW)
IP (Broadband)xDSL access elements
Core Border Gateway Function (7510 MGW), Residential Gateway (RG)
Media Server:
5900 MRF
50
Application Servers:
5400 IMS Application Server (IAS), providing Presence, XML Document
Management Services (XDMS) and Multimedia Instant Messenger (MIM)
5100 CMS, providing Unified Messaging
Web Portal:
5420 Personal Communication Manager (PCM)
External DNS/ENUM
Software Firewall:
Fortinet, providing SIP signaling security (ALG functionality)
Switch:
6850 OmniSwitch, providing Layer 3 connectivity between the SIP shelf, the
MGC, and the network of the service provider.
51
Two ICS systems (5060 ICS-SIP shelves) on different sites are designated as a
geographic redundant pair that operates in an Active/Active redundancy
scheme.
If the MGCF sends SIP INVITE messages for calls to an endpoint to the wrong site,
the protection ICS system sends back an error response, and the MGCF then
sends the SIP INVITE message to the other site.
The 1310 OMC-P populates the 5420 CTS database, iAGCF database, and the
iHSS in both ICS systems for each subscriber.
52
C ORE
SS7
IP C all Server
SS7 links
7510 MG
PSTN
MGW
H.248
Session
Manager
CORE
SS7 links
IP C all Server
iCCF
iCCF
S -CS CF
Session
Manager
S -CS CF
7510 MG
MGW
H.248
I-CS CF
iHSS
iHSS
I-CS CF
5020 MGC-x
P -CS CF
iAGCF
iAGCF
P -CS CF
MGCF
5020 MGC-x
MGCF
BGCF
BGCF
SGF
SGF
CT S
F S DB
F S DB
CT S
MGCF
Ac c ess Network
POTS Phones
53
SS7
MGCF
PSTN
The FSDB server handles the synchronization of its dynamic data between the
ICS systems.
The iHSS (iFC) contains the primary CTS and protection CTS for a subscriber. No
registration data is copied between the ICS systems.
A quarantine bit is defined in the iHSS. If the quarantine bit is not set for the
active CTS, the iHSS will not allow a subscriber to register on the protection ICS
system.
When an ICS system fails, the OMC-P puts the failed CTS on the quarantine list.
Endpoints affected by the failed ICS system register with the protection ICS
system, and the MGC sends SIP INVITE messages for calls to these subscribers
from PSTN endpoints to the protection ICS system.
When the failed ICS system is restored to service, its databases are
resynchronized with the 5420 CTS database, iAGCF database, and the iHSS in
the active ICS system.
54
Applications Overview
5450 ISC
55
Additional information:
For more information about the 5450 ISC, refer to:
3GPP 24.229: Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP)
and Session Description Protocol (SDP); Stage 3
3GPP 29.228: IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signaling flows and message contents
S-CSCF
I-CSCF
P-CSCF
BGCF
56
Applications Overview
5450 ISC
Proxy CSCF
57
Hybrid operation:
Transaction stateful SIP proxy server
B2BUA
Diameter connections:
58
59
60
The two external IP addresses can be of two different IP subnets or of the same
IP subnet.
61
When a P-CSCF SIPia port is created with 2 NIs enabled, the IP address assigned to the default NI will be
published in both the internal LCP DNS system and the external visible LCP DNS system, using the
"networkside FQDN. The IP address assigned to the publish NI will be published in the external visible
LCP DNS system, using the "ue-side" FQDN.
62
The integrated Security Gateway can be provisioned in both 5060 ICS and distributed IMS (ATCA only).
The iSGW supports IPv4 and IPv6 addresses, but is not required to perform NAT or ALG function to convert between formats (IPv4/IPv6) or
between public/private IP addresses.
The configuration of the Edge Routers (or access network itself) ensures that correct SFW is in the path for specific P-CSCF (typically iSGW)
or IBCF (Fortinet only) instances.
The following firewall functions currently supported:
DoS/DDoS Detection, Prevention, Logging and Alarming
Quarantine for the source IP address/port that is detected to be performing a DoS attack.
SIP Security
Per SIP method message rate limiting (Refer to iSGW provisioning in OAM&P)
Security Scanning
Vulnerability tested using such tools as Nessus, ISS, Codenomicon and other commercial protocol fuzzers/mutaters
IPsec for access networks terminate in the SFW that connect to the P-CSCF (i.e. iSGW).
The SFW supports all IPsec key exchange, encryption/decryption, integrity protection, etc as specified in IETF and 3GPP standards
Apply policies per access network, where policies are applied based on layer 3 source and destination IP addresses.
Future: Starting with R20.0, the integrated Security Gateway (iSGW) as part of the Secure External Access Lockout (SEAL) architecture.
The existing references to Security Gateway are not changed, but are equivalent to ISG. Since there is already an ALU product known as
ISG (Intelligent Service Gateway), any externally visible information for SEAL should not use ISG to avoid confusion. Instead, integrated
Security Gateway(iSGW should be used because that is the name that was used externally starting with R18 and would be confusing to
change it.
All Rights Reserved Alcatel-Lucent 2007
<COURSEPARTNUMBER> Edition <COURSEEDITION>
Page 62
SIP Compression
Apply filter criteria
Store registration data
Support implicit registration.
63
Applications Overview
5450 ISC
Interrogating CSCF
64
Diameter connections:
ACR [Start, Stop, Event]; including ACR [Event] for INVITE requests that fail
Forward the ICID received in the incoming message or; if no ICID, create an ICID
65
The Dx interface is similar to the Cx Diameter interface defined in the same 3GPP TS specifications, and it
shares the same DIAMETER application identifier, command codes, and request AVPs. Likewise, the Dh
interface is similar to the Sh Diameter interface. This feature will use the existing Cx and Sh interfaces, and
add three additional redirect-related Diameter base protocol response AVPs specifically to support the
Dx/Dh interfaces. As a result, the CSCF/AS can send the same Cx/Sh messages to an SLF as to an HSS but
must be prepared to accept the new redirect-related AVPs if the response comes from an SLF rather than an
HSS.
valid server name (SIP URI of an S-CSCF)The I-CSCF replaces the Request-URI
of the received REGISTER message with this SIP URI.
This method is used in the 5060 ICS.
capability listThe I-CSCF selects an S-CSCF that fulfils the capabilities (using
a round-robin mechanism) and replaces the Request-URI of the received
REGISTER message with this SIP URI.
This method is used in the distributed IMS.
66
The I-CSCF uses S-CSCF Server-Capabilities (configuration data) to match with per subscriber server
capabilities (received from the HSS) when selecting an S-CSCF during registration. The I-CSCF includes the
Server Capabilities AVP, populated with the S-CSCF Server-Capability in ACR messages sent from the I-CSCF
to the CCF over the Rf interface.
The HSS query is a User-Authorization-Request (UAR) message A User-Authorization-Answer (UAA) message is
returned by the HSS.
Each Private User ID may be provisioned with either server capability data (0-5 mandatory capability data
and/or 0-5 optional capability data) or server name data (0-2 S-CSCF names).
If the R-URI is a Public Service Identity (PSI), the I-CSCF can route to an
Application Server for termination using DNS.
I-CSCF uses a provisioned list that contains a set of PSI subdomains that are
supported on the LCP.
When the I-CSCF receives a request that is destined to a PSI, before querying
the HSS, the I-CSCF will compare the received domain name of the PSI with its
supported domain names:
If one match is found, the I-CSCF will try to resolve the PSI to the IP address of the
actual destination AS hosting the PSI by using DNS mechanism, and forward the
requests directly to the AS.
If no matching is found or DNS query fails, the I-CSCF will continue to query HSS as
usual.
67
Applications Overview
5450 ISC
Serving CSCF
68
Diameter connections:
Rf interface with CCF
Cx interface with HSS
Dx interface with SLF
69
SLF Support
The Dx interface is similar to the Cx Diameter interface defined in the same 3GPP TS specifications, and it
shares the same DIAMETER application identifier, command codes, and request AVPs. Likewise, the Dh
interface is similar to the Sh Diameter interface. This feature will use the existing Cx and Sh interfaces, and
add three additional redirect-related Diameter base protocol response AVPs specifically to support the
Dx/Dh interfaces. As a result, the CSCF/AS can send the same Cx/Sh messages to an SLF as to an HSS but
must be prepared to accept the new redirect-related AVPs if the response comes from an SLF rather than an
HSS.
70
New profile
The HSS can send a PPR (Push Profile Request) when, for example, the user profile has been updated.
An example of a change to the user profile is a change to the public IDs barring indication.
The other HSS-initiated update scenario is RTR/RTA (HSS-initiated de-registration). One example would be that
a change in implicit registration set membership could require a public ID to be de-registered in the current SCSCF.
NASS-bundled
71
33.203, RFC 3329 and 3GPP, RFC 3310. It supports IPsec between UE and the Proxy Call Session Control Function (P-CSCF) and authentication using
IMS Authentication Key Agreement (AKA). (Type A may also support SIP compression).
UE type B: Type B is non-3GPP IMS compliant and provides a non-GPRS access. These UE does not support the access security as specified in
3GPP, TS 33.203. For this UE, HTTP digest authentication with the Message Digest 5 (MD5) encryption algorithm will be used for authentication.
(Type B may also support SIP compression).
UE type C: Type C is non-3GPP IMS compliant and provides GPRS access. This UE supports the Early-IMS-Security as specified in 3GPP, TR
33.978.(No additional SIP level authentication is performed).
In the S-CSCF a nonce-aging mechanism is installed to allow the last successful authentication nonce to be reused.
This way, an UE can use the nonce for subsequent SIP requests
This is to save an additional, of the round-trip of the challenge/response.
This will improve the performance, in particular session-setup delay
72
HTTP: Hypertext Transfer Protocol (HTTP) digest authentication, is an authentication method, which is used to reduce the possibility of
spoofed calls in an unsecured network environment. The current implementation supports digest authentication on INVITE using MD5
(integrity encryption) algorithm.
Information on Hypertext Transfer Protocol (HTTP) digest authentication, an authentication method, which is used to reduce the
possibility of spoofed calls in an unsecured network environment (for example from nomadic users or users in an unsecured wireless
local area network (LAN) home network). The Serving Call Session Control Function (S-CSCF) performs the access authentication for
IMS subscriber User Equipment (UE).
To determine whether a UE requires challenging is based on several factors:
The algorithm to determine which INVITE to challenge, based on the provisioned fraction
To challenge only UE-originated INVITE
No challenge for INVITEs associated with bindings marked as integ_protected, as these UE used IPsec for protection
Data in binding indicates the incoming UE was challenged before and challenge failed
Support the challenge only on UEs, where the auth_type entry in the binding is CX_DIGEST_MD5.
Scenario
When an INVITE is to be challenged, an expiration timer is started as waiting for the INVITE request with authentication response.
Upon receiving the INVITE request with awaited HTTP digest authentication response before the timer expires, the S-CSCF authenticates
the response successfully before the normal call processing continues.
In the case where an INVITE is challenged and the validation of the authentication response fails, an entry in the user data is set to
indicate that the last authentication challenge failed and needs to be challenged if the same UE retries a call and rejects the call with a
403 Forbidden message.
The entry in the user data is also set when the timer has expired.
The percentage value for INVITE requests to be challenged are provisionable on the FS GUI.
SIP Compression
Apply filter criteria
Store registration data
Support implicit registration.
73
Applications Overview
5450 ISC
Breakout Gateway Control Function
74
4
2
5
6
Media gateway
Control
PSTN
1
Bearer traffic (RTP)
75
Media gateway
This way of routing using digit strings etc. is traditionally in the PSTN referred to as translations, which is described in detail (including
the decision criteria) in the OAM&P training course, Chapters Configuration Management and Translations.
The final routing is typically addressed to a CS network.
Additional information:
SIP request can be directly routed to the BGCF.
If the Bypass ENUM Query in CIC Present field is set and the Request-URI contains a CIC parameter the S-CSCF routes the request
to the BGCF.
If the SIP request does not contain a phone number (no CIC parameter in the Request-URI) then an ENUM query is performed and the
result is used to route the SIP request.
If the ENUM Query when Digits in SIP URI field on the S-CSCF profile is set, then the S-CSCF performs an ENUM query for the UE
originated request.
This query only happens when the SIP URI in the Request-URI has digits in the user part.
If this capability is not selected, the S-CSCF performs an ENUM query when the SIP URI in the Request-URI has the user=phone
parameter.
Note: The ENUM query only happens when one of the following conditions are met:
The host part of the SIP URI is owned by the S-CSCF
The field: ENUM Query for All Domains is set to yes
There are several possible sources of parameters that may be inserted into the Request-URI.
1. the originating UE itself
2. an AGCF (for POTS lines)
3. a session border controller
4. an Application Server
However, the most likely case and the one that for sure happens is 4) Application Server inserts parameters based on per subscriber
information that it has provisioned. For example, the 5420 CTS telephony application server does this.
Equal access
Calling party DN
Called party DN (default routing)
Route header
Content-type header
Location, local number, and Local Number Portability (LNP)
Originating host class and subscriber profile
Time-of-day/day-of-the-week
SDP media type.
76
Default routing is based on the incomings calls destination address (i.e. called party telephone number within a tel URL or
the user portion of the Request URI (sip: URI). This type of routing does not differentiate MGCFs that are from different
network carriers. One or more MGCFs can be used to reach the called party. When a cic is not included in the INVITE
request, this default routing method is used.
The enhancements provide the operator with a means to optimize the bearer path.
77
E.164 numbers are complete telephone numbers, +, country code, national destination code, subscriber number. For
example + 1 630 9791234.
The slide simplifies here, the actual situation regarding 3xx 6xx responses is more complicated:
1. A 302 redirect response is treated as it should, that means the Invite is rerouted using the URI in the contact header of
If a 3xx 6xx response is received and no more alternatives are available on the next hop list, the 3xx 6xx reason is
forwarded to the originating UA.
If the BGCF receives a SIP request that does not result in the creation of a Next Hop List list (containing at least one
Constructed URI), the BGCF shall return a final 404 not found response to the source.
If a Carrier Identification Code (CIC) is present, the BGCF will search the DA
Route Table for this CIC and route the call based on the combination of the
CIC and the calling DN.
If routing fails, the call is terminated.
2. Calling DN:
If a CIC is not present, the BGCF will search the DA Route Table for a
provisioned called party pattern that matches the called DN and route the
call based on the combination of the matched called DN and the calling DN.
Applies to location-based sensitive services, such as 8YY, N11, and operator
assistance.
3. Called DN:
Otherwise default routing where the BGCF will search the DA Route Table
for a provisioned digit string that matches the called DN and route the call
based on matched called DN.
78
Examples are:
Route header is used if BGCF proxy mode is enabled.
The Content-type header can be examined in order to route a SIP
MESSAGE request to an SMS center.
If a CIC is present, the call is routed based on the CIC information
without any other analysis.
79
This slide and the following slides provide just a brief introduction and a high-level overview of the various routing
enhancements. Details will be described in the OAM&P training courses, Configuration Management and Translations.
Refer to the slide earlier where the enhancements were listed.
In proxy mode, the BGCF routes a SIP request according to the basic
general routing rules described in RFC 3261:
When the BGCF receives a request that contains more than one Route header,
the BGCF removes the topmost Route header and uses the next one to
forward the request and no change is made to the Request-URI.
This effectively means that the BGCF skips the routing procedure and does
not use digit analysis tables or any other tables and target list selection.
If the next hop specified in the Route header is not available (out of service
or lock state), the BGCF returns a 500 Internal Server Error.
80
The BGCF searches the BGCF SIP Content-Type table for each incoming
SIP MESSAGE request in order to determine the action:
Route using a special target list that defines a set of message centers
Perform basic routing
Reject with 403 Forbidden.
81
The BGCF can treat a SIP MESSAGE request differently from other kinds of SIP request (such as INVITE and OPTION).
SIP MESSAGE requests can be delivered to different SMS centres based on Content-Type header.
Other types of messages could be :
IM (Instant Message)
USSD (Unstructured Supplementary Service Data).
Additional information:
When the BGCF SIP Content-Type table is not provisioned or no entry in the table, the BGCF treats this capability as
being turned off, the SIP MESSAGE request will be routed by existing call logic.
SMSC
No match
in ENUM
SMSC
SMSC
The normal BGCF routing is explained in other slides. Now well concentrate on some specific options.
Stress the SIP MESSAGE being the name of the method used for SMS, not just any message.
The Request URI will contain a URI of the SMSC, so normal routing on digits would also be possible. This new feature
provides the routing mechanism if you want to use different SMSCs for different types of content.
This feature enhances the BGCF routing capabilities to route SIP MESSAGE to different SMS center based on ContentType. Currently, if the ENUM/DNS query on the destination digit of a SIP MESSAGE request fails, the S-CSCF or RTCF
sends the request to the BGCF, and BGCF will route the request according to the called and calling number of the request.
With this feature, for SIP MESSAGE request, BGCF can route based on Content-Type, so different content type can be
routed to different SMS center. This feature can also be used by other kinds of SIP MESSAGE traffic, such as Instant
Message (IM) and Unstructured Supplementary Services Data (USSD), to route the request to different destinations
depending on its Content-Type.
The new table SIP content type table is used for this purpose. If the table is configured, the BGCF will use it to route SIP
MESSAGE methods, based on content type.
It maps content-type and content subtype to a target URI list.
The phone-context parameter (and the called DN) for local number
routing
83
84
85
For each target URI, the operator must provision one or more media
types according to the associated capability of the next hop.
The BGCF can select the next hop based on the SDP media types
indicated in the SDP "m=" lines in the incoming INVITE message.
86
Responsible for heartbeating the SIP links using SIP OPTION messages
Displays the heartbeat information and status of the links in the MI GUI:
Only SIP links with heartbeat enabled or in the locked state will be displayed
The Provisioning GUI will be the primary means of provisioning heartbeat and
administrative state
Configuration of the alarm thresholds for SIP links is done from the MI-Agent.
87
The SLM will use the OPTIONS method to perform heartbeating on this destination URI. When a destination is out of
service, calls will not be routed to the destination. If a call can not be routed to a SIP destination URI. BGCF will use an
alternative destination URI provisioned in the BGCF target list.
Prior to this feature, the BGCF routes the calls without knowing the link status of the next hop. The BGCF waited for a
timeout before retry a different route. This may result in long delay in the setup time. To improve this, the BGCF verifies
the status of the link in order to avoid routing to an out of service link.
BGCF will not keep track of the URI status on a continuous basis but will query for the status when it needs to route the call
using the URI. If the SLM returns a result of not routable because of unreachable URI or because it is disabled, BGCF
will go to the next provisioned URI for routing. If all Next Hop URIs are not routable then BGCF will return a 503
Service Unavailable response.
If BGCF receives a failure code on a routing attempt using an URI and the response code received is 408 or 503, then it will
report back to the SLM for notifying it of the failure.
Additional information:
The configuration of the alarm thresholds for Sip Link Sets is carried out in the MI GUI. The user selects the Sip Link
Configuration node from the tree panel and then enters the desired threshold on the form. The thresholds are expressed as
the percentage of unavailable links at which SipLinkSetUnavailable alarm will fire.
Applications Overview
5450 ISC
Emergency CSCF
88
89
Applications Overview
5450 ISC
Interconnection Border Control Function
90
91
This feature allows an IMS network to communicate with other IMS networks outside a service providers IMS home network to establish
calls and to support services via a new IMS component called an Interconnection Border Control Function (IBCF). The service providers
IMS home network contains network elements needed to provide IP Multi-Media Services (X-CSCFs, BGCFs, MGCFs, etc.) that are
reachable by inter-networking with other IMS network elements located within other IMS networks or SIP servers. The IBCF may reside
between a CSCF entity and any other entity with a SIP interface.
The 3GPP Release 7 TS24.229 and TISPAN standards describe all inter.networked SIP messages traverse through the new IBCF IMS
component.
Additional information:
An IBCF provides functions such as:
Topology Hiding Inter-network Gateway (THIG) (Concealing SIP headers that reveal topology information from being routed in SIP
messages to another operators domain);
For SIP messages being routed by the IBCF to an external network, SIP headers that reveal topology information (Via, Record-Route,
etc) are removed and stored before routing the message to the next hop in external network
For SIP messages received by the IBCF from an external network, SIP headers previously stored for topology hiding are restored in the
message before routing the request to the IMS network.
Support of Application Level Gateway (ALG) and TISPAN Gq' Diameter Interface:
Network Address and/or Port Translation (NAPT) control
Translation of IP addresses contained in SIP headers
IP protocol version translation for interworking between IPv4 and IPv6 - future release
Quality of Service (QoS) control.
Screening of signaling information based on source and destination of messages: e.g. removal of P-headers from traffic exchanged with
other domains.
Support of IMS Roaming scenario requires modification in IBCF Proxy State machine to support Register request.
Support of call gapping (allowing 1 call every N seconds) and code blocking (blocking X% of calls) on the IBCF is a new feature in IMS 8.0.
The offline charging provided by the IBCF supports the Rf interface for session charging messages ACR [Start/Interim/Stop/Event] so
that the call duration can be noted for the peering calls. Note: ACR version id must be 7.x.x.
Also this feature will support the generation of ACR event for cases when the IBCF generates SIP error responses (4xx/5xx/6xx) for
INVITE. (Prior to R18, only the ACR (Event) message, which is simply a notice that the peering call took place.
Peering call is when an UE originated call or incoming call from another network that gets routed to a peer network, rather than
delivered to the PSTN or an IMS subscriber. For the case of incoming call from another network getting sent to peering network, this is
also known as a transit call.
Furthermore, the IBCF provides support of provisioning, exchange and recording of the Inter-Operator Identifier (IOI) Type 2 and Type 3
parameters (.orig-ioi., .term-ioi.) in SIP messages and through accounting requests.
Currently IBCF is in hybrid model. B2B IBCF is used to process the INVITE dialog related SIP message. Proxy IBCF is used to process the nonINVITE dialog related SIP message.
92
IBCF (entry point) must determine where to route the incoming call: 1, 2, or 3 (dotted lines). See explanation
on next slide.
When the outgoing call must be routed to an external network, the function that was processing the message,
queries a table to determine which IBCF (exit point) is the next hop (dashed lines). See explanation on
second next slide.
93
2.
The IMS nodes DGCF, RTCF, BGCF, or S-CSCF route the request based
on a table, which maps the domain in the Request-URI of an external
network to a particular IBCF
The IBCF (exit point) routes the request by performing a NAPTR query
using the host portion of the Request-URI.
94
The table is the Domain Routing Table (IMS->IMS Tables->IMS->General), which is autonomously populated
with SCDT data when it is created. This table is also used by the IBCF to determine inter-network domains.
Additional information:
The BGCF, DGCF, RTCF, and S-CSCF are modified to support requirements for next hop routing determination
using the Domain Routing Table. Essentially all egress routing for the named IMS components must evaluate
the destination domain and determine whether it is inter-networked, or external. When this determination
is made each IMS component must construct the next hop Route header appropriately to proxy the SIP
message to the correct network element.
At the network-level DNS server a network operator must construct NAPTR resource records (RR) to recognize
and return targets for each served domain. From an LCP perspective only NAPTR RRs are required because
each LCP is autonomously configured to respond to any received SRV query requesting information on the
domain that it serves (_sip._tcp.ibcf.domain-, _sip.udp.ibcf.domain-) and return URIs identifying IBCF
access points.
Blank Page
95
Applications Overview
5450 ISC
Miscellaneous Properties
96
97
Additional information:
CSCF Support for Bulk Registration
ICS Support for SLF
iHSS SLF for ISC in ICS
SLF with external HSS
98
When the IMS Public User identities (IMPUs) are marked in the same IRS, the HSS will include all these IMPUs in
the SAA message to the S-CSCF.
Eaxmple from 29.228 appendix C:
<PrivateID>IMPI1@homedomain.com</PrivateID>
<ServiceProfile>
<PublicIdentity>
<BarringIndication>1</BarringIndication>
<Identity> sip:IMPU1@homedomain.com </Identity>
</PublicIdentity>
<PublicIdentity>
<Identity> sip:IMPU2@homedomain.com </Identity>
</PublicIdentity>
<InitialFilterCriteria>
etc.
Additional information:
The S-CSCF will add a P-AssociatedURI for each URI that should be
registered in the 200 OK message
The P-CSCF will also store all PAssociated-URIs as registered.
Insert
P-Associated URI
Register
P-Associated URI
99
Additional information:
When an individual PUID is registered by an IMS user it is considered an explicit registration.
Implicit Registration indicates a single IMS user has the ability to register a set of Public User Identities (PUIDs)
using a single registration.
A single registration of a PUID registers all members of the set of PUIDs the explicitly registered PUID is
associated with. Deregistration works the same way. The set of related PUIDs is referred to as the Implicit
Registration Set (IRS). IRS considerations include:
100
<PrivateID>IMPI_1@homedomain.com</PrivateID>
<ServiceProfile>
<PublicIdentity>
<BarringIndication>1</BarringIndication>
<Identity>sip:IMPU_1@homedomain.com</Identity>
</PublicIdentity>
<PublicIdentity>
<BarringIndication>0</BarringIndication>
<Identity>sip:IMPU_2@homedomain.com </Identity>
</PublicIdentity>
<InitialFilterCriteria>
etc.
The example shows an SAA message from the HSS, indicating that two IMPUs should be inserted and that they
belong to the same IRS.
101
SUBSCRIBE
messages
Note that three parties can subscribe for notification. The UE and the P-CSCF are always allowed to subscribe
to event notifications for the UE (itself). Third-party registrations from the AS are only allowed for the
Application Servers that are mentioned in the filter criteria of the UE (this is according to the specs =>
24.229 5.4.2.1.1). In the coming releases this probably will be changed, allowing more ASs to perform a
third-party registration.
Event notification = a message when the subscriber status of one or more of the IMPUs is changed.
Additional information:
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
version="0" state="full">
<registration aor="sip:user1_public1@home1.net" id="as9"
state="active">
<contact id="76" state="active" event="registered">
<uri>sip:[5555::aaa:bbb:ccc:ddd]</uri>
</contact>
</registration>
<registration aor="sip:user1_public2@home1.net" id="as10"
state="active">
<contact id="86" state="active" event="created">
<uri>sip:[5555::aaa:bbb:ccc:ddd]</uri>
</contact>
</registration>
</reginfo>
The SDP media subscription has precedence over the SDP local policy.
SDP policies are always applied first before invoking the PD-FE
102
SDP local policy give the operators the ability to do the following:
1. Define network maximum bandwidth and list of acceptable and unacceptable codecs.
2. Determine if the SDP policy should be enforced for a particular Offer/Answer flow (user initiated SDP offer,
user initiated SDP answer, network initiated SDP offer, and network initiated SDP Answer).
3. Check the user provided bandwidth in the SDP offer/answer is consistent with the user preferred list of codecs.
The local SDP profile allows the operator to specify bandwidth limits per codec. It can be associated with a PCSCF or an S-CSCF.
The SDP media subscription policy allows:
1. The S-CSCF to perform media stream authorization on per subscription basis.
2. The operators to provision the media types, codecs, bandwidth, and the associated parameters for SDP
validation. The policy attributes could be expanded in the future based on customer requests.
3. The HSS provides an index stored in the service profile that points to a subscribed media profile that
identifies the set of SDP parameters that a subscriber is allowed to request.
4. Invoke the SDP Media Subscription Validation when the S-CSCF receives SIP message containing SDP from
the served user, no matter its SDP offer or answer.
An SDP media subscription profile has session policy and media component policy. S-CSCF will check the
session description part in the received SDP against the session policy, and media description part against the
media component policy. If validation fails, return 488 Not Acceptable Here
The S-CSCF and P-CSCF can include the contents of the SDP offer/answer in the Account Request (ACR)
messages sent from the S-CSCF or P-CSCF to the CCF over the Rf interface.
Additional information:
When processing SIP messages with SDP, the SDP local policies (if provisioned) should always be performed first
before invoking PD-FE for media authorization and/or gating, or ALG for modifying SDP.
All Rights Reserved Alcatel-Lucent 2007
<COURSEPARTNUMBER> Edition <COURSEEDITION>
Page 102
103
3
1
AGCF
H.248
AGW
AGW
In R14 IMS6.1.5, FID 10919.110 WI 76.638, CSCF Support for Bulk Registration, will support bulk registration using a
Permanent Registration Set (PRSET). This means when an Access Gateway (AGW) to which PSTN users are connected
establishes a connection to the AGCF (via H.248), the AGCF will perform SIP registration for the AGW. Each AGW is
associated with a PRSET, which is provisioned to contain all the PSTN users behind the AGW. Upon successful
registration of AGW, all the PSTN users behind the AGW will be registered as part of the PRSET. A PRSET may contain up
to several thousands of users.
Review comment from Loh Chang, dated 9/3/2007: AGCF SIP registration messages don't proxy through Proxy-CSCF. It
talked to Interrogating CSCF directly. Thus message 1 between AGCF and Proxy CSCF should be removed.
The Cx interface has been modified to include new Mass User-Data AVP and Last-PPR AVP in Push Profile Request/Answer
(M-PPR/PPA). The mass user data download procedure is used for the HSS to download user profiles associated with a
PRSET to the S-CSCF. This procedure is triggered by a successful gateway registration. The gateway PUID has a one-toone relation to the PRSET. Note that the HSS initiates the request and the S-CSCF responds with the answer (see the
direction of the red arrows in Step 7).
Additional information:
Terminology and Definitions
Permanent Registration Set (PRSET) - a logical grouping of both gateway PUID/PRID and end users behind a gateway. A
PRSET is identified by a Virtual Private User Identity (VirtualPRID) and a PRSET-Type. It consists of one gateway
(identified by the gwPUID/gwPRID) and one or multiple (up to thousands) end users that are connected to the gateway.
Gateway Public User Identity (gwPUID) and Gateway Private User Identity (gwPRID) - identifies a gateway, which has
one-to-one mapping with a PRSET. When a gateway identified by the gwPUID/gwPRID is explicitly registered, the HSS
will download the PRSET user data to S-CSCF and as a result the end users behind the gateway will be registered. The
gwPRID will be provisioned with "No-Authentication" and gwPUID registration will not be authenticated. The gwPUID
should be provisioned as "barred" with no associated PUIDs.
End user (or endpoint) PUID and PRID (epPUID/epPRID) - identify users belong to a PRSET. Once registered (as a result
of M-PPR), they are treated as a registered IMS user, unless specifies otherwise in the requirements.
Mass user profile download (M-PPR) - refers to an enhancement to the 3GPP standard Cx Push-Profile- Request/PushProfile-Answer (PPR/PPA) procedure. The M-PPR procedure is used by the HSS to download PRSET user data (including
user identities, service profiles, charging information, etc.). Each M-PPR message is a standard PPR message that
contains one or more Mass-User-Data AVPs.
The distributed IMS solution and the ICS solution support Tel URL and SIP URI
with digit strings that consist of hexadecimal characters:
Decimal (numeric) digits 0-9
Hex digits A-F (case-insensitive)
Typically inserted as a routing prefix and NOT supported in dialed digit string
P/I/S/E-CSCF
RTCF (integrated in the I-CSCF)
DGCF
BGCF
104
The Alcatel-Lucent IMS functions that support hexadecimal digit strings include:
5450 ISC: I/S/E-CSCF, BGCF, DGCF, RTCF
5420 CTS
ENUM server
MGCF-10 and MGCF-12 (MGC-8 is not required to support hexadecimal digits, because hexadecimal digit
Redirection support enables the I-CSCF and the originating S-CSCF to act on
redirection responses from other networks:
Route-Direct: Replace the R-URI with Contact header with highest priority.
Evaluate-Route: I-CSCF routes based on the Address Resolution method;
S-CSCF routes based on ENUM query response.
Standard behavior would be to proxy response back to the originator.
105
Redirection Support
Instructor directive:
The description of redirection support behavior is simplified. For the full routing decisions please refer to the customer
documentation (or QDI # 39680, FDS).
Additional information:
Redirection support does not apply to terminating S-CSCF for redirection responses from UE. Similarly, the I-CSCF does
not act on 3xx response from UE. However, the feature does apply to terminating S-CSCF if AS causes change to
Request-URI and originating routing is performed by the terminating S-CSCF (like call forwarding).
The BGCF also supports processing 3xx responses. (Refer to the Topic BGCF.)
Potentially, this mechanism could also be used in a number portability scheme when the next hop network provides a new
contact due to the user changing service providers.
The Action for 301/302/305 Redirection Response behavior of the S-CSCF and the I-CSCF must be provisioned. Note that
the IMS standards mention that S-CSCF should only act upon 305 response, but this feature will apply to 301, 302 and
305 responses
Note: As with most features, no separate feature provisioning details required in the OAM&P courseware. Refer to OAM&P
CM for provisioning the S-CSCF profile and the I-CSCF profile
To be included in the IMS Charging module:
For feature interaction with GWF, if the IMS-GWF was included in signaling path for origination processing, then it will be
given the 3xx response prior to the S-CSCF acting the 3xx to send modified INVITE request with new Request-URI having
value from 3xx response. The modified INVITE request will be sent through the IMS-GWF again to get the proper rating
applied for online charging.
To be included in the future LI/CALEA module:
For feature interaction with CALEA, if lawful intercept was applied to the original SIP request, then the 3xx will cause the
old LI trigger to be removed and a new LI trigger will be set when the S-CSCF sends the modified SIP request.
S-CSCF
Network-1
INVITE
I-CSCF performs ENUM query with
associated CdPN and routes according to the
ENUM response to terminating Network-1
INVITE
Network-1 returns 3xx redirection message
3xx
I-CSCF acts on 3xx according to the provisioning
(Route-Direct or Evaluate-Route), determines the
new route and sends the INVITE to Network-2
INVITE
106
Network-2
Single HSS:
Subscriber data is stored in one HSS
I-CSCF/S-CSCF and E-CSCF can query the HSS directly over the Diameter Cx interface or
Sh interface
Segmented HSS:
Multiple HSSs each store a subset of the subscriber data
The address of the HSS that is associated with a specific public identity (PUID or PSI) is
not known.
I-CSCF/S-CSCF or E-CSCF must first query a Subscription Locator Function (SLF) over
the Diameter Dx interface or Dh interface.
The SLF performs user identity to target HSS resolution.
Stand-alone SLF returns redirection information and I-CSCF/S-CSCF or E-CSCF must
retransmit the message to the HSS instance address that was returned from the SLF.
Co-located SLF/HSS returns the final Cx/Sh answer to the originating I-CSCF/S-CSCF or
E-CSCF if the subscriber data is in the co-located HSS; otherwise redirection
information (like a stand-alone SLF).
Redirection process to the correct HSS upon every registration
107
No caching of the redirection HSS addresses that are returned from the SLF
The I-CSCF passes the redirection information that was received from an SLF to
the S-CSCF (or AS if R-URI is a PSI):
Only one primary destination (SIP limitation)
The S-CSCF or AS can directly query the appropriate HSS (and skip the SLF).
The SLF may be provisioned to return a primary and a secondary HSS address
(FQDN) to support redundant HSS arrangements; in this case, if a request to the
primary HSS address fails, the request may be re-attempted to the secondary
HSS address.
108
I-CSCF will pass HSS redirect information to the S-CSCF in P-User-Database header (with the HSS address(es))
in REGISTER and INVITE messages such that S-CSCF can always communicate directly with the appropriate
HSS.
To improve the scalability of SLFs in the 3GPP IMS by reducing the amount of traffic the SLF of a network
needs to handle, additionally the I-CSCF shall pass HSS address that is handling the user that generated the
request to the selected S-CSCF so that the S-CSCF can communicates directly with the appropriate HSS
without additional query to SLF. A new SIP header P-User-Database header will be used to carry the HSS
address information in SIP request messages sent from I-CSCF to S-CSCF.
The DIAMETER_REDIRECT_INDICATION Result-Code AVP in the Diameter answer message will be used by the
ISC to determine whether the Diameter answer is from the Diameter redirect host (that is, the SLF) or from
the final destination server (that is, the HSS).
Larry Newmans issue (to be resolved): Clarify when the "one primary destination restriction applies -- if the
SLF returns primary/alternate HSS destinations and the I-CSCF relays SLF data to the S-CSCF, and the S-CSCF
finds that the primary HSS is not reachable, what happens. I (LN) think the CSCF team should provide input
on this!
HSS
HSS
4
7
6
3
1
I/S-CSCF
109
SLF currently not supported. 5060 ICS will support an integrated SLF (iSLF) in Release 1.2.1 & Later.
TIM15001, refer to Module 6 Charging.)
110
LSM R18.0, FID 10919.195/WI 76.981: Heartbeat between border element P-CSCF and core element S-CSCF
This feature provides a heartbeat mechanism using SIP OPTIONS for P-CSCF to keep track S-CSCF status. The
list of target S-CSCFs is built dynamically at the P-CSCF upon successful UE registration (200 OK response to
REGISTER message). The S-CSCF status, based on its response to heartbeat requests, is maintained at the PCSCF. If a target SCSCF is determined to have lost its registry or is suspected to have lost its registry, the PCSCF will take immediate recovery actions (when possible) that aim to trigger an impacted UE to re-register
with the same or a new S-CSCF. This feature is controlled (enabled/disabled) by a provision flag in P-CSCF
profile.
The S-CSCF status is reachable (initial ) or unreachable.
Any other response than 408 Request Timeout or 503 Service Unavailable is considered as a success response
for this feature.
This feature is most useful when the P-CSCF and the S-CSCF are not co-resident on the same IMS server. The
heartbeat between P-CSCF and S-CSCF is not applicable to the 5060 ICS configuration because the P-CSCF
and S-CSCF are located on the same IMS Server.
Only one of the recovery mechanisms (some of which are mutually exclusive) should be used and in following
order (whichever one is applicable):
a) Either one of the Keep Alive mechanisms (SRD-CSCF-3108 or 3109);
b) Registration suppression;
c) Send NOTIFY to UE.
The P-CSCF needs to spread "marking" all UEs as "impacted" over some time period, for example, 10 minutes,
to avoid potential registration storm from impacted UE (especially for UEs that have keep-alive enabled.)
As of ICS 1.2.1 also Heartbeat between iAGCF and S-CSCF. (very similar mechanism with minor difference
concerning recovery procedure
Applications Overview
5450 ISC
User Profile Revisited
111
112
The IMS subscription, its associated PRIDs and PUIDs need to be provisioned at HSS.
At each UE, a PRID (=IMPI stored on the ISIM ) and at least one PUID need to be provisioned and securely stored.
A PRID is typically associated with a User Equipment (UE) or a device. (For instance, the PRID needs to be securely stored in ISIM
application, if ISIM is used for access IMS.) The term PRID, device and UE are often used interchangeably.
A service profile is a collection of user-specific information that is permanently stored in the HSS, which is transferred from the HSS to an
assigned S-CSCF on user registration or on a terminating initial request for an unregistered user. It consists of three parts:
Public Identification (one or more PUIDs)
Core Network Service Authorization
Initial Filter Criteria.
Multiple service profiles allows different treatment for different public user identities
One or more PUIDs can be assigned by the home network operator to an IMS subscriber and PUIDs are used for requesting
communications to other users. At least one public user identity needs to be securely stored or provisioned at each UE.
A shared PUID may be registered at a given time from multiple UEs that use different PRIDs and with different contact addresses.
However, one PUID can register only one contact per UE.
Preference-based routing means different registrations can be differentiated by means of the private user identity and the used IP address.
Caller preference allows a caller to indicate the preferences to the IMS core how he/she wishes the call to be handled. Caller preference
consists of caller feature preference and caller request preference. Currently only feature preference is supported (e.g., a call should or
should not fork or a call should or should not be directed to a video capable device).
In 3GPP Rel-6:
Sequential forking means that different items of UE are contacted one by one: for example, the S-CSCF first sends the request to UE #2
and, if Joe fails to respond, within a certain time limit the S-CSCF then tries to reach Joe through UE #1.
Parallel forking means that different items of UE are contacted at the same time: for example, when two items of UE are ringing, Joe
can decide which UE to use for the incoming session; however, in the end the session can only be connected to a single item of UE.
All Rights Reserved Alcatel-Lucent 2007
<COURSEPARTNUMBER> Edition <COURSEEDITION>
Page 112
113
The figure shows an example of the relationship of Multiple PRIDs and shared PUIDs. In this example, PUID 3 and PUID 4
are shared PUIDs by all PRIDs in the same subscription.
It is possible that different UEs of the same IMS subscription may register its PUIDs through the same P-CSCF or different
P-CSCFs.
One or more PUID(s) can be shared across the multiple PRIDs within the same
IMS subscription.
A shared PUID can be registered at a given time from multiple UEs that use
different PRIDs and with different contact addresses.
114
115
<IMSSubscription>
<PrivateID>IMPI_1@homedomain.com</PrivateID>
<ServiceProfile>
<PublicIdentity>
<Identity> sip:IMPU_2@homedomain.com </Identity>
</PublicIdentity>
<Continued on next slide>
1 10 Public user IDs
116
As a result of this feature the S-CSCF has the capability to evaluate a set of Filter Criteria to invoke the
Application Servers based on the information associated with each Filter Criteria. A new
ProfilePartIndicator attribute is provided in the subscriber profile by the HSS towards the S-CSCF:
Possible values REGISTERED and UNREGISTERED, indicating if the iFC is a part of the registered or
unregistered user profile. If ProfilePartIndicator is missing from the iFC, the iFC is considered to be relevant
to both the registered and unregistered parts of the user profile, i.e. belongs to the common part of the
user profile.
Additional information:
3GPP: IP Multimedia (IM) Subsystem Cx and Dx interfaces;
Signalling flows and message contents
(3GPP TS 29.228 version 5.6.0 Release 5)
IMPI = IMS Private User Identity
IMPU = IMS Public User Identity
117
Additional information:
The "first trigger point" is first because
of the priority value (lowest numeric value => highest priority)
not because it is the first in order of appearance.
See 3GPP29.228 or 3GPP2 X.S0013-00500 V2.0 appendix B and C.
<ApplicationServer>
<ServerName>sip:AS1@homedomain.com</ServerName>
<DefaultHandling>0</DefaultHandling>
</ApplicationServer>
</InitialFilterCriteria>
</ServiceProfile>
</IMSSubscription>
If not successful in
contacting AS, then
continue
118
Request URI
SIP method
SIP header, with attribute:
HeaderPresence or absence of any SIP header
ContentValue of the SIP header (if required)
Session Case, indicating whether the filter should be used by the S-CSCF
handling:
Originating
Terminating for a registered end user
Terminating for an unregistered end user
119
Additional information:
"Session Case" is the "Direction of the SIP request" (originating, terminating registered, or terminating
unregistered), according to 3GPP2 X.S0013-005-0 v2.0. and 3GPP TS 29.228.
Option to apply regular expression matching to SIP headers for filter criteria
Based on configuration flag, allows for regular expressions to be used for determining a match on the SIP
headers themselves in SPT (current implementation applies regular expression matching on the content of
the SIP header, but not the header). This allows for checking content specified in a single SPT against
multiple SIP headers.
In the SAA message, the HSS downloads unique identifiers of SiFC sets
to the S-CSCF.
The S-CSCF maps the downloaded identifiers onto the SiFC sets that are
stored in a locally administered database.
If SiFC is not enabled on the S-CSCF, the HSS downloads the iFCs of the
required set explicitly.
120
This Feature is to provide the Shared Initial Filter Criteria (SiFC) as per 3GPP Release 6 specifications to
reduce the memory needs on S-CSCF and Cx link capacity.
Basically, this is an HSS capability; if the HSS does not support SiFC sets, no special default behaviour is
required for the S-CSCF.
Additional information:
Note there is a potential inconsistency issue with the two separate local databases in the HSS and the SCSCF that contain the filter criteria information.
To support SiFC, the network operator needs to provision SiFC sets, iFCs on both HSS and S-CSCF and is
responsible for data consistence. Such provisioning is actually beyond the scope of this course, but some
high-level information included here:
Refer to QDI # 29856:
In order to keep data consistent, e5450 ISC is used to provision SiFC related data to HSS and S-CSCF. When
configuring, e5450 ISC sends an XML-formatted config file to OMC-CN and then it is passed to the CNFG
server via the MI server (using SSH port forwarding function).
In S-CSCF, there is a flag to indicate if SiFC feature is enabled. If this capability is supported by both HSS and
S-CSCF and SiFC set ID(s) is included in SAA or PPR message, S-CSCF will explode the SiFC set(s) into normal
iFCs, these iFCs are stored with explicit downloaded iFCs (if there are any), so the existing GSP (Global
Service Profile, IMR 825408) mechani5450 ISC can be used without change.
The following FS GUI provisioning is required: In NGSS Parameters/Timers, select the Enable checkbox for the
Shared Initial Filter Criteria parameter. (default Disable)
Applications Overview
5450 ISC
iAGCF
121
122
In terms of the TISPAN architecture for an IMS-based PSTN/ISDN Emulation Subsystem (PES) (ETSI TS 182 012),
the AGCFs role is analogous to that of a SIP-based Voice over IP Gateway (VGW) since it appears as UE from
the perspective of the IMS Core Network (CN). However, iAGCF interfaces with H.248 gateways (ISAM) and
its operation does not fully comply with TISPAN PES specifications for VGW operation; e.g., TISPANs
approach for using SIP to implement hookflash-based services is not supported.
PSTN
123
PSTN
125
PSTN
126
5420 CTS
SIP UA
PSTN
127
5420 CTS
Gateway identity
Identity of the port on the gateway
The subscriber data required by the iAGCF is integrated into the existing 5420 CTS Feature Server Database
(FSDB) on a diskfull ATCA blade.
129
5420 CTS
130
With Bulk Registration the iAGCF sends one SIP registration message for the entire AGW.
131
5420 CTS
5
6
4
3
A bearer path is setup from the AGW for the RTP stream
132
5420 CTS
6
4
2
3
5
6
A.
B.
C.
D.
E.
133
134
Applications Overview
5420 CTS
135
Blank Page
136
Applications Overview
5420 CTS
Functionality
137
Number normalization
Digit manipulation
Call-processing logic (tight coupling)
Service logic to apply broad
categories of services to the end
users:
138
The 5420 CTS provides supplementary services for subscribers using the following endpoints:
SIP phone, which includes both hardphones and softphones
POTS phones attached to for instance an Integrated Access Device (IAD) or AnyMedia LAG (and in the future
5420 CTS
139
Additional information:
The 5420 CTS is an Alcatel-Lucent Telephony Application Server that provides:
SIP Back-to-Back User Agent capabilities
Call control: basic telephony capabilities, such as maintaining the half-call view, digit analysis, number
normalization (E.164)
Supplementary services provided by two separate TAS components (will be discussed later in this lesson; see
2.
3.
4.
5.
140
2 5420 CTS
3
2.
3.
4.
5.
6.
141
2 5420 CTS
3 4
1
Additional information:
Check the state of the terminating UE: for example to determine if busy or idle.
Note that the terminating services depend on the dialed number!
142
If custom announcements and/or tones are to be used, they should have the following format:
The file name must end in .wav, and use .wav formatting as described next.
The encoding format should be g.711 mu-law (or A-law). Use the same encoding format as used by existing
system announcements (which are mu-law as stored on LED, but for sites that have converted system
announcements to A-law, then custom announcements for those sites should also use A-law).
The samples should be 8-bits per sample, 8000 samples per second, single channel. This results in file sizes of
5900 MRF: the audio files must be downloaded and stored locally
AudioCodes: the audio files are stored on the 5400 LCP (which provides
an HTTP web server to transfer the sound files)
Provisioning determines whether the 5420 CTS constructs the request URI
to play the file locally or from the MI service.
143
eng_us)
The customized announcements files can be downloaded using the Announcement Tool as well.
The 5420 CTS acts as a SIP user agent client, opening SIP dialogs in
conjunction with:
Announcement Tool that runs on the 5400 LCP can be used to download
and distribute the initial audio files to media servers.
144
Messages flowing through the S-CSCF are prescribed by the IMS architecture. However, only the direct signaling
connection from the 5420 CTS to the MS is supported and the 5420 CTS does not support a dialog that is
initiated by the media server.
The 5420 CTS expects that when a 200 OK from the media server is received after having processed a incoming
SIP INVITE, this means that it process the request without encountering any errors in either parsing the
message received or allocating the necessary resource to honor the request.
Additional information:
If the first selection attempt fails for any reason other than any retransmission time out, the 5420 CTS shall send
same request to the next MRF in the list.
A call that required multiple dialogs (e.g. conference call) with MRF shall use the same MRF for all dialogs. After
setup a call leg successfully with one MRF, it shall never switch to another MRF although a later call leg may
fail from the selected MRF.
There are two types of announcements to be supported: simple announcements (single audio file) and complex
announcement (multiple audio files or variable announcements ).
The NETANN protocol will be used for:
Request to play simple announcements (within the SIP request URI for the simple announcement
Request to play tones
Request to perform conferences.
The MSCML protocol will be used for:
Request to play the complex announcements (extensions-payload-in SIP INFO messages)
Prompt & collect.
145
When provisioning a subscriber, data is also stored in the database of the Lucent CM.
LCM can interact with voicemail systems:
Display Message Waiting Status
Allow user to retrieve voicemail messages using their computer
Additional information:
146
Additional information:
The DPE data includes:
Digit tables (new tables specifically designated to the 5420 CTS have been defined):
Direct dialed call translations; a digit table that is configured with the appropriate digit deletion and prefixing
rules to convert any valid number dialed by this subscriber into E.164 number format
Multiple dialing plan tables (the table ID is needed because the switch can support multiple dialing plans)
Per-subscriber dialing plan assignment.
One result of the DPE is to determine the call type, such as Valid local number, National number, International
number, Directory assistance, Toll-free number, and Emergency number.
The Location Based Routing service (distributed configuration only) This allows a special code to be dialed
that uses the knowledge of the subscribers location in order to translate the special code to the appropriate
local number for that physical location.
Example: A subscriber enters *PIZZA on their telephone keypad. The Location Based Routing service interprets
this special code based on entries in the Special Code Table as provisioned by the system administrator. The
special code is routed to the appropriate local number based on a provisioned geographic identifier, such as zip
code.
Non-flashable endpoints
Flashable endpoints
The other services are applied by the STAS component of the 5420 CTS
Advanced endpoint
147
Additional information:
Non-flashable endpoints are capable of providing multiple-call services themselves.
The 5420 CTS is able to operate with endpoints that provide local support of multiple calls as well as endpoints
that do not. However, some potential 5420 CTS customers have dictated that simple endpoints be used for
the majority of (if not all) subscribers, where all customer-dialed flash events are processed at the network
level. Therefore, the advanced endpoints are provisioned as simple endpoints.
As far as service behavior is concerned, if it is NOT a flashable endpoint, then 3-way call, call hold, and call
waiting are done in the endpoint, not by the 5420 CTS. The exception to this is that even advanced SIP
endpoints (not flashable) can use the web portal for click-to-conference and then it is done by the 5420 CTS.
For flashable endpoints, call hold, call transfer, 3-way call, and call waiting appear to work much like an
analog phone, even for a flashable SIP phone.
For more information, refer to QDI # 27720 (5420 CTS requirements), Section 4.5 SIP Endpoints and QDI #
27645 (NGFS Software Architecture), Page 61-71.
Flashable endpoints are endpoints that require D-TAS support in order to provide all services, besides the
functions of the S-TAS; non-flashable endpoints endpoints do not require D-TAS support, because those
endpoints are capable of providing certain services (such as multiple-call services) themselves.
The 5420 CTS is able to operate with endpoints that support local support of multiple calls as well as endpoints
that do not. However, some potential 5420 CTS customers have dictated that simple endpoints be used for
the majority of (if not all) subscribers, where all customer-dialed hookflash events are processed at the
network level. Therefore, the advanced endpoints are provisioned as simple endpoints.
Flashable endpoints signal hookflash via INFO messages and the 5420 CTS interprets and controls the bearer
path. Another difference is that flashable endpoints will always have a single bearer path to the phone, while
SIP phones not operating as flashable can have multiple bearer paths. As far as service behavior is
concerned, if it is NOT a flashable endpoint, then 3-way call, call hold, and call waiting are done in the
endpoint, not by the 5420 CTS. The exception to this is that even advanced SIP endpoints (not flashable)
can use the web portal for click-to-conference and then it is done by the 5420 CTS. For flashable endpoints,
call hold, call transfer, 3-way call, and call waiting appear to work much like an analog phone, even for a
flashable SIP phone.
For more information, refer to QDI # 27720 (5420 CTS requirements), Section 4.5 SIP Endpoints and QDI #
27645 (NGFS Software Architecture), Page 61-71.
148
Flashable endpoints
5420 CTS
D-TAS S-TAS
To called party
home network
Advanced endpoint
(non-flashable)
149
SIP subscribers who use a non-flashable endpoint only require the S-TAS functions
Note that the flow of the arrows reads from left-to-right and that the arrows are in line!
The Initial Filter Criteria that are used depend on the type of registration service profile:
Origination from or termination to SIP subscriber
Termination to a POTS subscriber attached to an IAD or AnyMedia LAG
Origination from or ringback termination to a POTS subscriber attached to an IAD or AnyMedia LAG.
Ask the students how the S-TAS decides the type of services.
Answer: This is based on the private tag that the S-CSCF includes in the INVITE message
Additional information:
5420 CTS
D-TAS S-TAS
From calling
party home
network
Advanced endpoint
(non-flashable)
150
SIP subscribers who use a non-flashable endpoint only require the S-TAS functions.
Note that the flow of the arrows reads from right-to-left and that the arrows are in line!
Additional information:
5420 CTS
D-TAS S-TAS
To called party
home network
Simple endpoint
(flashable)
151
Instructor directive:
SIP subscribers who use a flashable endpoint require both D-TAS and S-TAS functions.
Note that the flow of the arrows reads from left-to-right and that the arrows are in line!
Note also that there is no separate trigger for the S-TAS. A separate trigger will be an option in R3.
Of course the POTS phone should be connected through an IAD (not shown for simplicity).
Additional information:
5420 CTS
D-TAS S-TAS
From calling
party home
network
Simple endpoint
(flashable)
152
SIP subscribers who use a flashable endpoint require both D-TAS and S-TAS functions.
Note that now the S-TAS and the D-TAS are in the session in reverse order.
Of course the POTS phone should be connected through an IAD (not shown for simplicity).
Additional information:
153
154
Applications Overview
5420 CTS
Services
155
156
Chapter 5. Services
All Rights Reserved Alcatel-Lucent 2007
<COURSEPARTNUMBER> Edition <COURSEEDITION>
Page 156
157
158
159
160
161
162
163
With each 5420 CTS release, additional features are added. To keep the engineering and the ordering of the
5420 CTS simple, CTS provides access to features in packages or bundles.
Each 5420 CTS subscriber is assigned a feature package and the service provider has the option to make all of
the features in the package, or just a subset, available to that subscriber. Different 5420 CTS subscribers
can be assigned different feature packages.
5420 CTS engineering allows the flexibility to support many different feature packages on the same 5420 CTS,
however, each individual subscriber cannot be assigned more than one feature package.
As 5420 CTS supports new features in future releases, these new features may be added to existing feature
packages, or new feature packages may be created supporting these new features. When new features are
added to existing feature packages, these features automatically become available for the service provider
to assign to subscribers that already have the feature package.
In addition to feature packages, 5420 CTS also supports Ala Carte features. Ala Carte features are features
that can be assigned to a subscriber in addition to those available in the subscribers assigned feature
package. An example of an ala Carte feature is Attendant Console.
Feature template 1
Feature 2
Feature 3
Feature 4
Subscriber b
Subscriber c
Feature template 2
Subscriber d
Subscriber e
Feature 5
Feature 6
Subscriber a
Feature template 3
Subscriber f
Feature 7
Subscriber g
Feature 8
Subscriber h
Feature 9
Subscriber i
Subscriber j
164
An operator can create feature templates in order to simplify subscriber feature provisioning.
A feature template can hold a number of features from a feature package.
In stead of assigning the each feature individually to a subscriber, the operator can simply assign a feature
template to that subsricriber.
Applications Overview
5420 CTS
165
Call Waiting
Call Pickup
Simultaneous Ringing
TISPAN Conferencing
166
Applications Overview
5420 CTS
167
The subscriber can use the hook flash to put the call in session on hold
and answer the new call.
The subscriber uses the hook flash again to hang-up on the third party
and return to the original call.
168
Call Waiting - Terminating (CWT) notifies a customer of an incoming call while another call is already
established. The service allows a customer to put the present call on hold and establish a connection with
the new caller. CWT is a terminating service that does not impact call origination.
Call Waiting can be performed as a network-level feature (for flashable endpoints), or can be provided within
the endpoint itself (with advanced endpoints). In both cases, the 5420 CTS maintains subscriber data that
dictate the maximum number of simultaneous call appearances. For 5420 CTS- supported call waiting, the
maximum will be two call appearances.
CWT is assigned per PartyID and applies to all associated PUIDs.
With non- flashable (advanced endpoints), it is the responsibility of the endpoint to supply the call waiting
tone and interpret an appropriate user action (e.g. flash) as a request to answer the second call and place
the first call on hold. Likewise, the endpoint will also interpret additional flashes as requests to toggle the
active and held calls; the 5420 CTS will not be aware that the active and held calls have been exchanged.
With flashable endpoints, Call Waiting is supported within the 5420 CTS. The 5420 CTS will monitor the
number of call appearances and will inform the endpoint when a second call request has been received.
The endpoint will play the call waiting tone and will report a flash by sending a SIP INFO message to the
5420 CTS. After receiving an INFO message with flash indication, the 5420 CTS will put the first call on hold
and will connect the new caller to the endpoint. Additional INFO requests (to report additional flashes) will
instruct the 5420 CTS to toggle the active and held calls.
CTS-1
UE-2
UE-3
A
INVITE (SDP offer)
180 Ringing (no SDP)
B
INFO (play call waiting tone X)
C
200 OK INFO
INFO (flash)
200 OK INFO
D
INFO (cancel tone)
200 OK INFO
169
This scenario depicts a Call Waiting scenario involving a simple endpoint. The 5420 CTS will instruct the
endpoint to play a call waiting tone when a second call request arrives, and the endpoint will report
subscriber-dialed hook flash back to the 5420 CTS.
(Although not specifically shown, Filter Criteria specify that the 5420 CTS is application server for originating
(calling) number and the terminating (called) number.)
A. This scenario begins at a point where a call exists between UE-1 and UE-2, and UE-3 attempts to place a
call to UE-1. UE-1 is a simple endpoint.
B. CTS-1 detects that an active call exists between UE-1 and UE-2 and it determines that UE-1 has activated
Call Waiting. CTS-1 must instruct UE-1 to inject a call waiting tone. If the subscriber also has Distinctive
Call Waiting Tones feature, CTS-1 must be able to specify WHICH call waiting tone should be injected.
C. The simple endpoint UE-1 must be able to interpret INFO request and inject appropriate call waiting tone.
In addition, UE-1 reports user-dialed hook flash to CTS-1.
D. The call waiting tone must no longer be played to UE-1; either the endpoint is smart enough to turn off the
tone when the flash was detected, or CTS-1 will have to send an INFO message with a cancel tone
request. The worst case scenario is that the CTS-1 will have to send INFO, so that is shown.
The SIP INFO method is described in RFC 2976, and is used to transmit mid-call event notifications and midcall instructions between an 5420 CTS and endpoints for the following reasons:
Simple SIP endpoint sends INFO with an indication that the user has pressed the hook flash.
CTS sends INFO to simple SIP endpoint with an instruction to provide call waiting tone to the user.
CTS sends INFO to simple SIP endpoint with an instruction to cancel the call waiting tone.
CTS sends INFO to MRF with MSCML instructions to play announcements or perform prompt and collect
procedure.
MRF sends INFO to CTS to report status and/or transmit digits collected from the user.
CTS-1
UE-2
UE-3
E
reINVITE (SDP offer with new session ID,
no media lines, and IP address=0.0.0.0)
200 OK INVITE (SDP answer)
ACK (for 200 OK INVITE)
F
reINVITE (SDP offer from UE-3)
200 OK INVITE (SDP answer)
ACK (for 200 OK INVITE)
200 OK INVITE (SDP answer from UE-1)
ACK (for 200 OK INVITE)
VP2: Voice path established between UE-1 and UE-3; UE-2 is on hold
170
CTS-1 must now swap the active and held calls sent to UE-1. First, put the current call on hold.
CTS-1 sends a SIP reINVITE to UE-2 with an IP address of 0.0.0.0 (which is normally used to prevent
endpoints from attempting to establish RTP streams to a caller).
F. UE-2 is now on hold and CTS-1 must establish the bearer path between UE-1 and UE-3.
E.
CTS-1
CTS-2
UE-2
CTS-3
UE-3
G
INFO (flash)
200 OK INFO
H
reINVITE (no SDP)
200 OK INVITE (SDP offer)
reINVITE (use offer received from
UE-1, IP address=0.0.0.0)
200 OK INVITE (SDP answer)
ACK (for 200 OK INVITE)
I
reINVITE (SDP offer from UE-1)
200 OK INVITE (SDP answer)
ACK (for 200 OK INVITE)
ACK (for 200 OK INVITE, with SDP answer from UE-2)
VP3: Voice path re-established between UE-1 and UE-2; UE-3 is on hold
171
G. The UE-1 subscriber can use the hook flash to toggle between the active and held calls. UE-1 endpoint
UE-3 is now on hold and now CTS-1 must re-establish the bearer path between UE-1 and UE-2.
Blank Page
172
Applications Overview
5420 CTS
173
174
An enhancement is Directed Call Pickup, where a call that is ringing at another endpoint in another predefined Call Pickup group can be answered when:
The Directed Group feature has been assigned and
The Directed Pickup options have been enabled.
Important Call Pickup characteristics:
Call Pickup Groups comprise sets of PUIDs, not Party IDs, so that only a subset of calls to an endpoint are
subject to Call Pickup. (Imagine an endpoint that has a personal PUID and a business PUID, where calls
dialed with the business PUID are in the Pickup Group, but calls dialed with the personal PUID should not be
picked up).
The PUID of the ringing phone and the PUID of the endpoint invoking Call Pickup must both be members of the
same Call Pickup group defined in CTS database.
Ringback INVITE messages sent to an endpoint (e.g. Click-to-Dial, Ring Back when Free, Call Park Reanswer
timer expires, etc.) are not eligible to be picked up.
Pickup Groups do not span CTSs, so both the called UE and the UE that picks up the call must be served by the
same CTS.
If more than one call is eligible to be picked up, the call that has been ringing the longest will be picked up.
The FS 5000 must keep track of the order in which INVITE messages have been sent to the members of a Call
Pickup group, so that the longest ringing call can always be identified.
Call Pickup can be invoked by dialing the service access code in an initial INVITE, or can be invoked as a
midcall service by flashing during an active call and dialing the Pickup service access code following the
midcall prompt.
If a ringing call is answered by somebody else before the Call Pickup feature can grab the call, the use who
invoked Call Pickup will hear an announcement (which may just be the reorder tone) if there are no eligible
calls to pickup.
UE-1
UE-2
CTS-3
applies originating
services to UE-3
UE-3
1. User of UE-1
calls UE-2
INVITE (SDP offer from UE-1)
180 Ringing (no SDP)
2. User of UE-3 decides to pick up the call
INVITE (URI = *240 + SDP offer)
CTS-2 and CTS-3 are really the same AS
and share information
3b. CTS-2 terminates call attempt to UE-2
CANCEL
175
In this example, CTS-2 serving UE-2 is acting as a terminating AS, while CTS-3 serving UE-3 is acting as an
originating AS, so separate CTSs have been shown. In this call flow, UE-1 is not served by an CTS. In order
to simply this call flow, CSCF entities are not shown. In reality, there will be I-CSCFs, S-CSCFs, and P-CSCFs
involved with the call flow.
In the call scenario :
UE-2 and UE-3 are in the same Pickup Group.
A user hears a nearby ringing phone and decides to answer it by dialing the Call Pickup service access code.
Thus, Call Pickup is invoked by dialing the service access code in an initial INVITE.
Step 2: The user of UE-3 hears the ringing call at UE-2, and decides to pick up the call by dialing the Call
Pickup service access code (for example *240).
Step 3: When CTS-3 receives an INVITE with a Request-URI that contains the Call Pickup service access code,
CTS-3 verifies that the PUID that sent the INVITE has been assigned the Call Pickup service, and CTS-2
verifies that a ringing call eligible to be picked up exists*. CTS-2 and CTS-3 are really the same AS, and
information must be shared between the terminating process handling the call to UE-2 and the incoming
process handling the Pickup request from UE-3; since UE-2 is in the same Pickup Group as UE-3, the AS will
let the invoking party (UE-3) answer the ringing call.
We now have a case where two INVITE requests have been received with SDP offers (the call from UE-1,
and the call from UE-3), but an end-to-end offer/answer exchange is still required.
Step 3a: CTS-3 generates a 200 OK with on-hold SDP answer for the INVITE from UE-3, immediately
followed by Step 3c, a reINVITE with the offer from UE-1.
Step 3b: At the same time, CTS-2 generates a CANCEL to UE-2 to terminate the pending request.
* As long as CTS-2 has not received a final INVITE response, the call is eligible to be picked up.
All Rights Reserved Alcatel-Lucent 2007
<COURSEPARTNUMBER> Edition <COURSEEDITION>
Page 175
CTS-2
applies terminating
services to UE-2
UE-2
CTS-3
applies originating
services to UE-3
UE-3
176
Applications Overview
5420 CTS
177
A SimRing parent number can have up to nine children and call requests
are sent to all ten numbers when an incoming call is received.
The first endpoint that answers will be connected to the caller and all
other call attempts are cancelled immediately.
178
The Simultaneous Ringing feature allows a subscriber to supply a set of numbers that are all called
simultaneously when a parent number is dialed.
Simultaneous Ringing is assigned on a PUID basis, so a service provider can designate a virtual number to have
Sim Ring while all other PUIDs do not. A Sim Ring parent number can have up to 9 children, and call requests
will be sent to all 10 numbers when an incoming call is received.
Each of the simultaneous calls to numbers in the simultaneous ringing set are treated as a call origination from
the parent, and are subject to standard originating call restriction checks for calls that originate from the party
that has subscribed to the simultaneous ringing feature.
If the caller used the CLIR feature, then calling number and name info will not be included in any of the call
attempts to the set of terminating numbers.
The first endpoint that answers will be connected to the caller and all other call attempts will be cancelled
immediately.
If the call is not answered and the Sim Ring parent number has CF No Answer, the call will be forwarded.
The original caller will be billed for the call to the dialed number, and the Sim Ring subscriber may be billed for the
call from the 5420 CTS to the endpoint that answered (i.e. if the answering phone is an international number,
the Sim Ring subscriber may be billed for an international call from the parent number to the international
terminating number just as if the parent number had been forwarded to the international number).
The subscriber must use the Web Portal to add/delete/modify the set of numbers to be called when the
Simultaneous Ringing feature is active. However, the subscriber may activate and deactivate the Sim Ring
feature using either the Web Portal or dialed codes.
In Release 2, the Sim Ring feature is enhanced to allow more than one simultaneous invocation; and to allow a
Distinctive Ring field to be provisioned for each Child DN, used to provide distinctive ringing treatment when a
Sim Ring call is placed to the Child.
UE-1
CTS-3
applies originating
services to UE-3
UE-2
UE-3
1. User of UE-1
calls UE-2
INVITE (SDP offer from UE-1)
2. Retrieve list of destinations (UE-2, UE-3)
and terminate the call to all destinations.
INVITE (SDP offer from UE-1, IP address=0.0.0.0)
INVITE (SDP offer from UE-1, IP address=0.0.0.0)
3. No terminating services for UE-3
180 Ringing (no SDP)
179
In order to simply this call flow, CSCF entities are not shown and neither is CTS-1 (assume no originating
services for UE-1). In reality, there will be I-CSCFs, S-CSCFs, and P-CSCFs involved with the call flow. (The
complete call flow includes 67 messages!)
With the Simultaneous Ringing feature, a subscriber defines a set of destination numbers that should all ring
simultaneously when a parent number is dialed. Note that he parent may be a virtual number that does
not actually terminate on a phone.
Step 2: CTS-2 determines that this number (of the called party) subscribes to the simultaneous ringing service
and obtains the list of destination numbers from the subscribers data record (in this example UE-2 and UE3). CTS-2 now generates calls to each of the numbers on the list. In order to prevent multiple endpoints
from attempting to establish RTP streams to the caller, and to reduce the number of unnecessary packets,
the SDP body that is sent to each endpoint includes the media attributes that were received in the SDP
offer from UE-1, but the IP address is set to 0.0.0.0.
Step 3: Each termination attempt (to each simultaneously ringing phone) will result in terminating services
checks in the AS. (For example, each leg could use call forwarding.) In this example, assume no
terminating services to be applied to UE-3.
Step 4: As soon as the first 180 Ringing message is received from one of the terminating legs, a 180 Ringing
will be sent to the originating party.
Step 5: Assume UE-3 is the first one where the call is answered.
CTS-2
applies terminating
services to UE-2
UE-2
CTS-3
applies originating
services to UE-3
UE-3
180
Step 6: We have received a call answer, so all other call legs must be cancelled.
487 Request Terminated can be sent by a UA that has received a CANCEL request for a pending INVITE
request.
The 200 OK is sent to acknowledge the CANCEL.
The 487 is sent in response to the initial INVITE after Step 2.
Now that we have found an answering party, NGFS-2 needs to use ReINVITE to establish a complete end-toend bearer stream between UE-1 and UE-3 (right now, UE-3 does not have UE-1s correct IP address). So, a
reINVITE will be sent to UE-3, but this time well use the complete SDP offer that we received from UE-1
(in the original INVITE).
Applications Overview
5420 CTS
181
Limitations:
Only the conference controlling party can invite another user to the conference via the
SIP REFER.
Before the conference controlling party can invite another party to the conference
(using SIP REFER), the invited party must have a confirmed dialog (answered call) with
the controlling party.
182
In ETSI TS 183 043, TISPAN has defined a SIP signaling interface. A device that supports TISPAN methods reports a userdialed hookflash to the 5420 CTS in an INVITE request in a new dialog, rather than by sending an INFO request within a
previously-established INVITE dialog. The Request-URI in the INVITE will contain a unique value to indicate that the
INVITE is reporting a detected flash event. The TISPAN standards do not specify the value that must be used, and the
CTS can be configured to use any string value. Data in the CPE device itself and in the CTS must be configured to use
the same string (for example LucentTISPANFlashRequest) in the user part of the Request-URI when a user-dialed
hookflash has been detected. To indicate that the Request-URI is to create a conference instance, the CTS uses the
default user part ALU_CONF in the Conference-URI.
The SIP REFER method is described in RFC 3515, and is used as a way for an IP endpoint to instruct another endpoint to
generate an INVITE toward a third endpoint. Many SIP Phones and SIP IADs use the REFER method during call transfer
scenarios. SIP REFER requests will only be sent by endpoints that have integrated logic supporting call transfer features.
Since REFER is normally used to manipulate more than one current dialog, REFER will not be accepted from simple
endpoints, because they only know about 1 dialog to the CTS and cannot specify the Call-ID of another dialog.
The Public Conference ID is a unique identifier for a TISPAN conference, and it is used between the conference controlling
party and the conference server (CTS). If there is a B2BUA between the controlling party and the conference server, the
public ID is just between the CTS and the B2BUA. A B2BUA will replace the SIP contact header of the received 200 OK
with its own contact header, and save the received SIP contact header to replace the Request URI of a subsequent
request (e.g. REFER).
The Conference Focus is a SIP user agent that is addressed by a conference URI (with tag isfocus) and identifies a
conference. The focus maintains a SIP signaling relationship with each participant in the conference. In the CTS
implementation the CTS is the conference focus.
Conference Focus is the SIP user agent that is addressed by a conference URI, with tag isfocus and identifies a
conference. The focus maintains a SIP signaling relationship with each participant in the conference. In the CTS
implementation the CTS is the conference focus.
Alternatively, the CTS supports the conference call service (with up to 6 parties) by reporting a hook flash using a SIP INFO
message or TISPAN INFO message, or by Click to Conference. This approach is fine with traditional analog phones
(simple endpoints) for users who do not have intelligent CPE or whose advanced endpoint is provisioned as flashable.
The TISPAN conference method is not applicable to a simple endpoint. If a simple endpoint sends an INVITE message
with the conference URI, the CTS will reject the request. (Treatment ID 315: You are not allowed to create a
conference. Please contact your service provider.).
All Rights Reserved Alcatel-Lucent 2007
<COURSEPARTNUMBER> Edition <COURSEEDITION>
Page 182
Public Conference ID, which is used between the party that controls the
conference and the conference server.
183
184
CTS
MRF
UE-B
UE-C
185
This call flow describes a scenario where a voice path is established between UE-A and UE-B (VP 1). However,
a voice path may exist or may not exist.
The subscriber A with N-way conference service can send an initial INVITE with the conference factory URI to
create a public conference ID regardless of whether there is an in-progress call or not. After the
conference ID is created, the CTS will request MRF to provide a conference circuit via the INVITE with SDP
offer. Once the MRF confirms the SDP, the CTS relays the SDP answer back to the conference controller
through 200 OK including the public conference ID in the contact header. After receiving ACK from the
controller, the CTS relays the ACK to the MRF. Now the conference controller and the MRF have
established the bearer path.
Step1 : UE-A is provisioned to send ALU_CONF in the user part of the R-URI (Conference Factory URI).
This initial INVITE request to create a conference instance is not counted against the call limits assigned to
the subscriber.
An example of the message: INVITE sip: ALU_CONF@fs5000.home1.com SIP/2.0
Step 2: When the Request-URI is recognized as a TISPAN conference request, the CTS validates that the Party
ID has been assigned with the N-way conference service.
(If the check fails, the CTS plays an announcement through treatment ID 315. After announcement is
played, the SIP BYE message is sent to the caller to tear down the session if the session is still up.)
CTS sends an INVITE with the Private Conference ID using NETANN.
Step 3: Contact header of a 200 OK response to the INVITE must contain the conference ID. Example:
Contact: sip:conf-idX@fs5000.home1.com:5060; isfocus
CTS
MRF
UE-B
UE-C
186
To invite a party that is already in a confirmed dialog with the controlling party, the controlling party must
send the REFER method with Refer-To header to the FS5000 (conference focus). The Refer-To header
contains the invited party and the Replaces information (the call id, From-tag and To-tag of the existing
dialog between the controlling party and the party to be invited). At first, the CTS sends INVITE without
SDP to the MRF. After getting SDP offer from the MRF, the CTS will send the re-INVITE with the new SDP
offer from the MRF to the invited party based on the Refer-To header and the Replaces header (within the
Refer-To). Once UE-B joins the conference successfully, the CTS will send BYE to the UE-A to release the
old dialog between the UEA and the UE-B. Note that the existing participant must in a stable call state
(the call is answered). Otherwise, the CTS will reject the REFER.
Example: REFER sip:conf-idX@fs5000.home1.com; isfocus SIP/2.0
The Replaces information points to the dialog A-B. The CTS can use this dialog to find the UE-B.
It is assumed that the dialog associated with Refer-to DN is answered but in hold state.
As defined in RFC 3515, a REFER request initiates an implied subscription and requires that NOTIFY requests
be sent by the REFER recipient to report status of the REFER request and to terminate the subscription
when the request has been completed.
UE-A, UE-B, and UE-C are now joined in a basic conference via the MRF. Because NETANN was used to
establish the conference, no announcements or prompt & collect actions can be performed. If the MRF is
enhanced to support MSCML for conferencing, then individual legs could be muted, hear specific
announcements, and receive prompt & collect requests.
The SIP NOTIFY method is described in RFC 3265, and is used to report the occurrence of a subscribed event.
Normally, a SIP SUBSCRIBE is sent by a subscriber to request a target to monitor for specific events. When
the event is detected, a SIP NOTIFY is generated. There are some situations where a NOTIFY may be used
when no explicit subscription exists; there is overhead associated with installing and maintaining
subscriptions, and some services use an implict subscription philosophy (for example REFER) where both
the UAC and UAS understand that a subscription is always active without the need to actively manage the
subscription. Unsollicited NOTIFYs (where no prior SUBSCRIBE had been received) are also sent from the FS
5000 to the SIP endpoints to report VMS status change.
All Rights Reserved Alcatel-Lucent 2007
<COURSEPARTNUMBER> Edition <COURSEEDITION>
Page 186
CTS
MRF
UE-B
UE-C
187
To drop a conference participant, the controlling party sends a REFER method containing Refer-To with the
party to be dropped and method setting to BYE. If the Refer-To header includes the conference URI, the
CTS will remove all conference participants from the conference.
Blank Page
188
189
The Silver Residential Plus Package contains all the features in the Silver Residential package and an
equivalent number of Personal Communication Manager (PCM) Web Portal licenses.
The Gold Residential Package contains all of the features in the Silver Residential Package, and the following
features:
Basic Auto-Attendant (via the PCM)
Music on Hold
Personal Ring-back Tones
Time of Day/Day of Week Capabilities (via the PCM)
User Control of Call Barring
190
Authorization
Call Barring
Call Forwarding Always (CFA)
Call Forwarding Busy (CFB)
Call
Hotline/Warmline
Private Dialing
Service Suspension
Note: The US Military package can only be assigned to authorized US government users.
The following Ala Carte services are not of any feature package:
Attendant Console
Large Call Limit (PBX Support)
Multi Line Hunt Group Queuing
Deluxe
All Rights Reserved Alcatel-Lucent
2007Auto Attendant
<COURSEPARTNUMBER> Edition <COURSEEDITION>
Location Based Services
Page 190
Blank Page
191
Applications Overview
iHSS/iSLF
192
193
Additional information
The Alcatel-Lucent product name of the HSS on the Lucent CP 1000 is iHSS, also called Internal HSS or HSSLite, but these are unofficial names.
194
Additional information
The Home Subscriber Server (HSS) is the master database containing the subscription-related information to
support the network entities that handle calls/sessions.
On the 5060 ICS and the LCP 1000 (Control Platform Compact Model) the HSS function is provided by the iHSS.
The iHSS database is a DataBlitz database on the DB Server. The DB server is one of the servers running on
the combined OAM&P host.
The following interfaces are used for information transfer and provisioning:
HSS communicates with the S-CSCF and I-CSCF via the Cx interface. The Cx variant of the Diameter protocol
iHSS functions:
1. Store subscription data
2. Provide status info, Serving CSCF
association, authentication
information, etc.
3. Authenticate public/private
memberships
4. Retrieve subscriber profile
information
5. Retrieve location information
195
Additional information
The HSS provides the following functions:
Provide filter criteria to S-CSCF (indicating which SIP requests should be directed to which Application Server)
Provide S-CSCF address to the I-CSCF (the I-CSCF will assign an S-CSCF to the UE during IMS registration,
Per subscriber
Global
1-n
1-n
196
1-n
This is a simple representation of a iHSS database structure. More details in the following slides.
There can be up to 10 Public Ids, and up to 20 Global IFCs.
Emphasize the difference between HSS
per-subscriber" data (private/public IDs, passwords, customization data) and
"global" data (service profiles, IFCs, app server and S-CSCF names, template files, etc).
Additional information
Logically, the data flows down from the Private ID; but physically, data is organized primarily by Public ID, as that
is all an INVITE will include. For registration purposes, it must also be easy to cross-check a Private ID and a
Public ID (when given both). And it must be possible to locate all the Public IDs associated with a given Private
ID, for HSS de-registrations.
The HSS database provides the following data:
Private user ID
Public user ID
Password
Initial filter criteria.
PrivateId
PridUser
PrivPassword
PublicId
PublicId
PublicId
..
197
Additional information
The PrivateId contains a user name and a password that is used for registration of an endpoint. The PrivateId
can be associated with up to 10 PublicId records.
Private ID profile:
PridUser Private ID user name, without domain
PrivPassword Password for registration
PublicId Array of up to 10 associated internal public ID indices (into PublicId profile) (unused entries are 0).
PublicId
PuidUser
AssocPrivateId
Authorized
Barring
ImplRegSet
ServiceProfileNumber
Additional information
Contains PublicId data associated with a PrivateId record. The PublicId contains the telephone number of the
endpoint, barring and authorization data regarding registration, the implicit registration set number, and
the service profile number. A PrivateId may contain up to 10 PublicIds.
Public ID profile:
PuidUser Public ID phone number, without domain
AssocPrivateId -- Associated internal private ID index containing this public ID
Authorized -- Is this public ID authorized to register?
Barring -- Barring indication sent to S-CSCF
ImplRegSet -- Implicit registration set number
ServiceProfileNumber -- Index to a service profile associated with this public ID.
ServiceProfileNumber
Internal service profile index
ServiceProfile
ServiceProfileName
Description of this service profile
ServerCapNumber
Index to an S-CSCF name associated
with this service profile
GlobalIFCNumber
Up to 20 indices pointing to Global
IFCs that contain "global" IFC
information associated with this
service profile.
199
ServiceProfileNumber
ServiceProfileName
ServerCapNumber
GlobalIFCNumber
GlobalIFCNumber
GlobalIFCNumber
..
Additional information
Contains Service Profile records containing the Server Capability (S-CSCF) and a list of up to 20 GlobalIFCs. It
is referenced by the PublicId record.
Service profile:
ServiceProfileNumber -- Internal service profile index
ServiceProfileName -- Index to a comment string describing this service profile (or 0 if not used)
ServerCapNumber -- Index to an S-CSCF name associated with this service profile. The parameter name
refers to S-CSCF capabilities, but this is not supported on the compact platform.
GlobalIFCNumber -- Array of up to 20 indices pointing to GlobalIFCs, which contain "global" IFC information
GlobalIFC
AppServer
Application server name
RegApplicability
Does this IFC apply to registered,
unregistered, or both users?
DefaultHandling
What to do if the application server does
not respond
RelativePriority
IFC relative priority
ServiceInfoString
Info string passed to the AS when the
conditions in this IFC are met
TemplateIdx
Index to the IFC trigger point template
200
GlobalIFCNumber
GlobalIFCName
AppServer
RegApplicability
DefaultHandling
RelativePriority
ServiceInfoString
TemplateIdx
Additional information
The table name and the first two parameters might be confusing: indicate that it is globalifc, not globallfc
Global Initial Filter Criteria (IFC) point to the Trigger Point Template Files used to form the filter criteria that
contain the name of the Application Server that is accessed if the criteria are met and an optional Service
Info String that is passed to the Application Server when the criteria are met. The GlobalIFCs are referenced
by the Service Profiles.
Global (common) portion of IFC data (including associated Application Server name and linkage to IFC
template):
GlobalIFCNumber -- Internal global IFC index
GlobalIFCName -- Index to a comment string describing this global IFC (or 0 if not used)
AppServer -- Application Server name
RegApplicability -- Registration applicability (does this IFC apply to registered users, unregistered, or both?)
DefaultHandling -- What to do if the Application Server does not respond (session continued, session
terminated)
RelativePriority -- IFC relative priority
ServiceInfoString -- Index to a "service info" string associated with this global IFC. The service info string is
passed to the application server when the conditions described by this IFC are met. Note that per-PUID perIFC service info strings can also be defined -- that data resides in the PublicIdCustomization relation.
TemplateIdx -- Index to the Template File Name record (the IFC trigger point template relation).
201
Instructor directive
This is the complete representation of a iHSS database structure and the related parameters.
Mention and explain a little bit about the four, not previously mentioned, relations:
ServerCapability - S-CSCF server capabilities
PublicIdCustomization - Public ID customization data to customize filter criteria used by designated Public
Ids, by providing per-Public ID Service Info Strings and Template File Parameters
ServiceInfoString - The service info string is passed to the Application Server when the conditions described
by its associated global IFC are met (for a specific PUID you could for example enter the IMSI of the UE down
here)
TemplateFile - Linkage from global IFC to trigger point template files.
UAA
Associated S-SCSF
UAR
Public ID
202
203
204
Blank Page
205
Applications Overview
iSLF
206
Two configurations:
Stand-alone SLF returns redirection information and I-CSCF/S-CSCF or E-CSCF must
retransmit the message to the HSS instance address that was returned from the SLF.
Co-located SLF/HSS returns the final Cx/Sh answer to the originating I-CSCF/S-CSCF or
E-CSCF if the subscriber data is in the co-located HSS; otherwise redirection
information (like a stand-alone SLF).
No caching of the redirection HSS addresses that are returned from the SLF
The I-CSCF passes the redirection information that was received from an SLF to
the S-CSCF (or AS if R-URI is a PSI):
Only one primary destination (SIP limitation)
The S-CSCF or AS can directly query the appropriate HSS (and skip the SLF).
207
The iSLF only supports the redirection procedure (does not proxy Cx requests to
other iHSSs.
Multiple ICS-SIP shelves are administratively grouped into a logical SLF Group:
The iSLF subscriber database contains records to locate the iHSS for all
subscribers provisioned on all ICS-SIP shelves in the SLF Group:
Records include reference to the Primary iHSS and, if a duplex subscriber, the georedundant iHSS.
Key is the Private User ID or the Public User ID of the subscriber.
208
The long term benefit of SLF functionality will be to allow a potentially large number of ICS subscribers,
spread over a number of ICS shelves (each shelf with its own iHSS), to be supported, without the need to
support complex routing schemes to deliver calls or other SIP requests to a given subscriber.
A total of up to 1.8 M ICS subscribers may be supported in a given SLF group.
It is expected that the 5450 ISC elements in each ICS shelf (whether it be from an ICS shelf provisioned with
an iSLF or not) will be configured to send its initial Cx/Dx queries to one of the two iSLFs supporting the SLF
group.
Note: In the future, an enhancement may be implemented to allow every ICS shelf in an SLF group to be
configured with an iSLF. Such an enhancement could allow larger SLF groups to be supported by ICS.)
Larry Newmans comment, dated 27/1/2010:
either private or public ID can be used as a key to access the iSLF data (when handling a Diameter query).
ICS #1
CTS
ICS #2
I-CSCF
I-CSCF
iSLF/
iHSS
S-CSCF
CTS
iSLF/
iHSS
S-CSCF
P-CSCF
P-CSCF
Geo-redundant Pair
ICS #3
CTS
I-CSCF
iHSS
S-CSCF
P-CSCF
S-CSCF
iHSS
P-CSCF
Geo-redundant Pair
209
I-CSCF
I-CSCF
I-CSCF
iHSS
ICS #6
CTS
ICS #5
CTS
ICS #4
CTS
S-CSCF
iHSS
P-CSCF
S-CSCF
P-CSCF
Geo-redundant Pair
In the 5060 ICS implementation, the iSLF will be implemented together with the iHSS. In general, when a Cx query is
received by the iSLF/iHSS (either from an I-CSCF or an S-CSCF), if the Cx query pertains to a subscriber that is being
supported by the local iHSS, the iSLF/iHSS will respond with the requested information. If the subscriber is not
supported by the local iHSS, but the iSLF data is provisioned with the identity of the subscriber's iHSS, the iSLF/iHSS will
provide a response that includes the identity of an iHSS to which the query should be redirected. Note: The label "Dx" is
sometimes used in relation to the interface to an SLF. However, the Dx interface does not define requests that are
different from those defined for the Cx interface. For that reason, the label Cx is generally used in association with the
queries to the iSLF/iHSS.
After having performed the iSLF and iHSS queries, when redirecting SIP requests (e.g. REGISTER, INVITE) to an S-CSCF
serving a particular user, an I-CSCF will support the inclusion of a P-User-Database header that includes the redirecthost obtained from the SLF. This information will enable an S-CSCF to perform any needed Cx queries directly to the
corresponding iHSS.
iSLF assumptions:
The iSLF will only be required to support Dx queries (corresponding to the Cx queries from CSCFs), but not Dh queries
(corresponding to Sh queries from an AS). (Dh support in the future.)
An ICS shelf may or may not be configured in an SLF group. However, any new deployment of ICS, in ICS 1.2.1 will be
required to be configured as part of an SLF group.
The iSLF is always configured with all the subscribers on its SLF group
The OMC-P can configure multiple SLF groups.
An SLF group may be composed of up to 3 geo-redundant ICS shelf pairs or up to 3 non-geo-redundant ICS shelves.
Initially, it will not be possible to support the conversion of a non-iSLF ICS shelf (with subscribers already provisioned on
it) to an iSLF-supported ICS shelf. This will be supported in the future. The growth from one iSLF-supported ICS shelf to
two iSLF-supported ICS shelves (in the same SLF group) would be supported, however. In such cases, the two ICS shelves
may be configured as a geo-redundant pair or as non-georedundant ICS shelves. Growth of additional ICS shelves or shelf
pairs to the SLF group (although without iSLFs configured on them) would be supported, up to the limit of 3 nongeoredundant ICS shelves or up to 3 georedundant ICS shelf pairs.
No impacts are expected from a lawful intercept perspective. Each ICS shelf in an SLF group will interface separately to
the LIG (via the X1 and X2 interfaces).
5060 ICS #1
CTS
I-CSCF
CTS
S-CSCF
iHSS
#3
iSLF/ iHSS
#1
4
3
2
S-CSCF
I-CSCF
1
1. REGISTER(puid)
iAGCF/
iAGCF/
P-CSCF
2. User-Auth-Request (puid)
3. User-Auth-Answer (redirect-host=iHSS #3)
4. User-Auth-Request (puid)
5. User-Auth-Answer
6. REGISTER(s-cscf, P-User-Database=iHSS #3)
210
The figure illustrates how iSLFs affect registration scenarios. The initial Cx request from the I-CSCF is directed
to an iSLF in the SLF group (located on a different ICS shelf as the I-CSCF's), and the iSLF provides the I-CSCF
with the identity of the registering user's iHSS (which, in the example, happens to be on the same ICS shelf
as the I-CSCF).
ICS Shelf #4
CTS
I-CSCF
ICS Shelf #3
CTS
iSLF/ iHSS
#2
S-CSCF
iHSS #3
6
6
iHSS #4
4
S-CSCF
2
I-CSCF
1. INVITE(R-URI: +ics-user@domain1) (after CTS invocation)
iAGCF/
P-CSCF
211
Benefits of using an iSLF can be obtained in a call made from a subscriber on one ICS shelf to a subscriber on a
second ICS shelf. In such cases, the terminating INVITE may be handled by any I-CSCF. The I-CSCF can locate
the terminating subscriber's iHSS via the query to the iSLF. In the specific example, the I-CSCF is located in
the an ICS shelf that does not have an iSLF, and the terminating subscriber's iHSS is on an ICS shelf different
from the I-CSCF's ICS shelf and also different from the iSLF's ICS shelf.
With respect to the handling of an incoming call from the PSTN, when multiple ICS shelves are involved, the
MGCF need not be provisioned with sufficient routing information to deliver an INVITE to the specific ICS
shelf containing the terminating subscriber's iHSS. In ICS configurations supporting the iSLF, the MGCF can
send the INVITE to an I-CSCF on any ICS. The I-CSCF can then locate the appropriate iHSS, even if on a
different shelf, via information from the iSLF.
Applications Overview
Module Summary
This lesson covered the following topics:
5450 ISC
5450 IRC
5420 CTS
iHSS
iAGCF
212
Applications Overview
References
For more detailed information on these subjects refer to the system documentation.
213
Blank Page
214
End of Module
Application overview
215
Network Architectures
Module Objectives
After you have successfully completed this module you will be able to
describe the end-to-end network architectures required to support:
217
Module Outline
2. Network Architectures
Border Architecture
VoIP Emergency Services
Business Trunking
Lawful Intercept/CALEA
218
Blank Page
219
Network Architectures
Border Architecture
220
Network Architectures
Border Architecture
Description
221
222
Customer-specific customizations or deviations from the generic border architectures are not covered. Some
products that are not described here, may be needed to support a specific customer configuration.
Conversely, some products described here may not be needed to support a specific customer configuration.
Such customization is subject to a business review process on a case-by-case basis. Furthermore, the details
for specific access networks are out of scope.
The Access Border is the boundary between the IMS core network of an
operator and the UEs of end users that are attached to an access
network; examples include:
Wireline access network
Wireless access network
223
Network elements are needed at the Access Border to protect the network from malicious users. Without this protection,
users could disrupt the network by sending invalid IP messages to internal network elements, or steal service by sending
bearer packets through the network that exceed their subscribed bandwidth.
Note: Access Border control is not needed for the C5 PES Solution since AGWs and VGWs are trusted network devices with
only narrowband, twisted-pair access at the customer premises.
Network elements are needed at the Peering Border to protect the network of each service provider from the other
service providers.
The interconnection between IMS/SIP networks can be:
Through designated border control, or
Directly with external IMS/SIP elements when no border control is designated
Alcatel-Lucent strives after eliminating third-party products. In general, a border control function can be one of the
following:
Inter-Connection Border Control Function (IBCF)
Typically an ALU IBCF is used, with lead implementation in the MGC-8, although the 5450 ISC IBCF is still supported. The
MGC-8 is now the Reference IBCF, but does not currently support IPv6 - The 5450 IBCF does support IPv6, but is
moved to the ready architecture. If it is necessary to have an IBCF that support IPv6, the 5450 will need to be used.
For obvious reasons, this module will provide some details regarding the IBCF in the 5450 ISC. For the MGC-8 IBCF, refer
to specific product information/training.
Session Border Controller (SBC)
The use of SBC is limited to interconnecting IP-PBX (see Business Trunking Solution).
Service Broker (SB)
Firewall
Firewall typically provided by the third-party Fortinet firewall. In the Access Border, the SIP firewall functionality is
replaced by an SIP security integrated firewall (iSGW) in the P-CSCF in R18.28 (ICS 1.2.1/IMS 8.3/IMS 7.6). The L2/L3
firewall functionality may still be provided by the third-party Fortinet firewall.
Or some other specialized network element
The IBCF is inserted into the SIP signaling path to protect the network
from signaling attacks at the peering border.
224
In an Integrated Border Architecture, a single network element provides all the border control functionality
(signaling, bearer, and policy); typically a Session Border Controller (S/BC). The decomposed model has
several advantages, such as improved scalability and flexibility, lower cost, and compliance to standards.
The distributed/decomposed solution for access and peer IP network connectivity with the 5450 ISC, 5450 IRC,
7510 MGW, 5020 MGC-8 and 5020 MGC-12 products replaces the previous standalone, monolithic approach
using the Acme Packets SB/C.
In the standards architectures the Border Gateway Function (BGF) is defined. In this module BGW and BGF are
considered interchangeable terms.
Over the last several years, ETSI TISPAN and ITU-T have done significant work in developing a border solution
which solves the inherent problems of SBC and provides for vendor interoperability. Other standards bodies
such as 3GPP and 3GPP2 have used this model in their own efforts. 3GPP2 standards for Policy are merged
with 3GPP standards starting with 3GPP Rel-8. These standards bodies addressed the problem by splitting a
traditional SBC into logical components and providing external interfaces to other network elements.
Alcatel-Lucent border architectures are based on the ETSI TISPAN and 3GPP models. Alcatel-Lucent border
solution is aligned with the ITU-T RACF architecture framework. It can be adapted upon customer requests.
The TISPAN NGN Resource and Admission Control Subsystem (RACS) is responsible for elements of policy
control, resource reservation and admission control. It also provides support for border gateway services
including NAT traversal and gate control. At the center of TISPAN NGN RACS architecture is the Servicebased Policy Decision Function (SPDF).
The SPDF functionally is not equivalent to the ITU-T PD-FE entity as the SPDF provides the AF with a single
point of contact to the access transport and IP core.
Alcatel-Lucent border solution supports 3GPP 29.214 R7 Rx interface. Interoperability testing with PCRF will
be done as needed based on customer requests.
Peer
Network
Circuit
Switched
Access
Network
IBCF
C-BGF
IMS Access
Wireline
Network
Geographic
Redundant
Sites
IBCF
Peer
Network
I-BGF
SPDF
IMS
Core
P-CSCF
C-BGF
I-BGF
Geographic
Redundant
Sites
SPDF
Peer
Network
SPDF
IP Enabled
Circuit Switch
P-CSCF
I-BGF
Core Network
SPDF
C-BGF
P-CSCF
Geographic
Redundant
Sites
PCRF
P-CSCF
PCRF
GGSN
GGSN
IMS Access
Wireless
Network
225
Separate border elements limit (or even eliminate) the need for S/BCs. Some of the problems inherent in the
integrated and monolithic SBC include:
Integrates both control and bearer:
o Control and bearer scale differently
o Requires signaling & bearer to be routed to same point in network
o Consumes budgets for both conversational delay and network capital
Solution does not interact with other network elements
o Not aware of network resources
o Service control limited to SIP
o No end-to-end coordination, breaks capabilities such as encryption, IPSec, etc.
o Duplication of Next Generation VoIP and IMS capabilities
Application servers forced to have end-to-end knowledge and be network aware, thereby complicating
service creation plus increasing development time and cost.
With much of the SBC functionality being proprietary and interoperability becoming a concern, TISPAN
standard work groups have tried to address the problem by splitting most of the features above into
standard functions. These functions are supported in functional elements within the TISPAN NGN Release 1
network architecture for fixed networks (e.g. xDSL wireless broadband).
Access border solution/architecture provides 3GPP and TISPAN P-CSCF, SPDF and C-BGF functions.
Interconnect/peering border solution/architecture provides 3GPP and TISPAN IBCF, SPDF and I-BGF functions.
For NGN opportunities, the same Alcatel-Lucent peering solution can be positioned to be the IP and/or TDM
peering solution to protect the NGN network.
The IBCF assigned for handling incoming traffic from a peering network/enterprise network should be
configured based on if the network is considered trusted or untrusted (e.g. retain/remove P-headers and
privacy header handling). The presence of an IPsec SA indicates the connection is secure, so determining if
a network is trusted could be based on the presence of an IPsec SA. Similarly, the use of dedicated physical
connections would indicate that a peer network is trusted. The IBCF will apply policies configured for each
peering/enterprise network.
IMS Core
Access
Network 1
(VLAN 100)
L2/L3
L2/L3
FW
FW
IMS
client
5450
5450 ISC/IRC
ISC/IRC
P-CSCF-1
& iSGW
P-CSCF-2
& iSGW
SPDF-1
SPDF-2
7510
7510 MGW
MGW
Access
Network 2
(VLAN 200)
IMS
client
226
FW
&
NAT
C-BGF
(NAT)
C-BGF
(NAT)
The BGF is a packet-to-packet gateway for user plane media traffic. The BGF performs both policy
enforcement functions and NAT functions under the control of the SPDF at either the access edge of the
service provider IP core (C-BGF) or at the network peering edge of the service provider IP core (I-BGF). The
BGF provides the following functions:
Open/close gates
Packet marking
Resource allocation (per flow)
Network Address Translation (NAT)
Hosted NAT traversal
Policing of uplink/downlink traffic
Usage metering
IPv4-IPv6 media interworking
Note: the 7510 MGW may be configured for both roles of I-BGF and C-BGF in one chassis.
In IMS R7.0, the ALU IMS architecture supports the TISPAN Release 1 defined RACS subsystems for deployment
by network operators in the fixed access and interconnect network. In this architecture the:
Fortinet performs the role of a signaling firewall
ALU 5450 ISC performs the role of the P-CSCF
ALU 5450 ISC, 5020 MGC-8, 5060 MGC-10, or 5020 MGC-12 performs the role of the IBCF
ALU 5450 IRC performs the role of SPDF or PCRF
ALU 7510 MGW performs the role of the C/I-BGF
The 5060 MGC-10 will not be tested as an IBCF in the IMS 7.0 reference architecture, so it can only be used in
NGN Class 4 networks for this function.
IMS Core
Peering
Network
IMS
IMS
client
client
5450
5450 ISC/IRC
ISC/IRC
FW,
FW,
SIP-ALG
SIP-ALG
&
&
NAT
NAT
IBCF-1
SFW
SFW
IBCF-2
SPDF-1
SPDF-2
7510
7510 MGW
MGW
Enterprise
Network
IMS
IMS
client
client
227
FW,
FW,
SIP-ALG
SIP-ALG
&
&
NAT
NAT
I-BGF
(NAT)
I-BGF
(NAT)
228
The screening of messages includes the lower layer signaling to ensuring proper routing and screening of
protocols to only send SIP, ICMP and keep-alive messages to the 5450 ISC/IRC. The DoS protections also
include the lower layer signaling protection and the SIP layer protection. At the SIP layer, the operator can
specify policies to limit the rate of SIP messages that may pass through the firewall. Typically, the policy
allows for rules to be defined, such as sizes and types of messages to be allowed. Also, rules may specify a
rate at which SIP messages may be allowed through the firewall, on a granularity of SIP method, which can
then be associated with each source IP address and/or port.
Note: The 5450 ISC/IRC based architecture prior to IMS 8.3/7.6: The external signaling firewall for SIP
application layer protection was provided by Fortinet Fortogate. The Fortinet FW also provides the lower
layer L2/L3 firewall functions.
See http://docs.forticare.com/fgt_ims.html for the support documents for the Fortinet FW.
The implementation of the iSGW results in less cost and smaller footprint (i.e. number of boxes). The iSGW
resides on the LCP on the same ATCA chassis as is used for the 5450 ISC, 5450 IRC and 5060 ICS. It would be
used in conjunction with the IMS access network border architecture instead of having an external SIP
firewall.
A L2/L3 firewall is still required as a separate entity. First, L2/L3 firewall should be configured to only allow
traffic from specified IP addresses / subnets to be sent to the 5450 ISC/IRC (5060 ICS). This prevents traffic
from anywhere but the expected access networks from being sent to the 5450 ISC/IRC (5060 ICS). Second,
L2/L3 firewall should be configured to provide protection against DoS attacks from transport layers (e.g.
UDP, TCP and including ICMP). Note that it is expected that the L2/L3 firewall is much less expensive than
the combined SIP & L2/L3 SFW. The L2/L3 FW could even be merged with another component , for example
a Router. It is assumed that the routers and L2/L3 firewall in front of the 5450 ISC 145 are providing
protection against ICMP attacks. The ICMP processing follows a different processing path and is assumed to
not pass through the iSGW.
Bearer traffic to ALU 7510 MGW (C-BGF or I-BGF) for the bearer IP
addresses, for example the media.
229
For ICMP traffic, it is assumed that the routers and L2/L3 firewall in front of the 5450 ISC are providing
protection against ICMP attacks. The ICMP processing follows a different processing path and is assumed to
not pass through the integrated SIP firewall. Similarly, it assumed that the routers and L2/L3 firewall in
front of the 5450 ISC are providing protection against UDP, TCP and SCTP attacks.
The SFW is part of the iSGW on the P-CSCF.
Destination IP address for P-CSCF or IBCF was determined from DNS Query response by entity sending request
to the Edge Router.
Note: It is also possible that the access network has segregated the signaling and bearer traffic prior to reaching the edge
routers. For example, a DSLAM may do this for DSL access.
The configuration of the Edge Routers (or access network itself) ensures that correct SFW is
in the path for specific P-CSCF (typically iSGW) or IBCF (Fortinet only) instances.
5450 ISC
N/A
IBCF
PD-FE
C-BGF
I-BGF
L2/L3 Firewall
230
The details of the ALU solutions are beyond the scope of this training. However, the Business Trunking
solution has been added as a separate topic in this module.
This topic describes features relative to the SPDF in the 5450 IRC. The A-RACF is supported on the AlcatelLucent 5750 Subscriber Service Controller (SSC) and not in the scope of this topic.
The official IBCF is on the MGC-8. However, the ICS-based IBCF is still available and can be positioned
occasionally for various reasons to be determined by the project team/system architect. This module
described Border Architecture with ICS-based IBCF. MGC-8 training is provided separately.
The Session Border Architecture does not apply to the Class 5 PSTN Emulation Subsystem (PES) and Consumer
VoIP/Multi-Media Solutions:
Access Border Control is not needed, because:
For the C5 PES Solution, AGWs and VGWs are trusted network devices with only narrowband, twisted-pair
access at the customer premises.
For the CVoIP/MM Solution, Soft-clients, Hard-phones, and Residential Gateways (RGs) are trusted
network devices with SIP-based broadband wireline access at the customer premises.
Firewall typically provided by the third-party Fortinet firewall. In the Access Border, the SIP signaling firewall
functionality is replaced by an SIP security integrated firewall (iSGW ) in the P-CSCF in R18.28 (ICS 1.2.1/IMS
8.3/IMS 7.6). The L2/L3 firewall functionality will still be provided by the third-party Fortinet firewall.
Blank Page
231
Network Architectures
Session Border Architecture
Border Functions
232
Network Architectures
Border Functions and Border Element Roles
Border Function
Security
Resource &
Admission Control
(based on TISPAN
RACS framework)
Note:
Functions require
all the border
elements in the
merged field.
Miscellaneous
(1)
233
Note: Signaling Firewall Functions in 5450 ISC Access Border Architecture only (Security Gateway integrated in
P-CSF)
Media Firewall Functions:
DoS/DDoS Attack Protection
Media Policing
The BGF (7510 Border Gateway) is a packet-to-packet gateway for user plane media traffic. The BGF perfroms
both policy enforcement functions and NAT functions under the control of BGC. The following are the
services provided by this capability:
Open/close gates
Packet marking
Resource allocation (per flow)
Network Address Translation (NAT)
Hosted NAT traversal
Policing of down/uplink traffic
Network Architectures
Border Functions and Border Element Roles
Border Function
Security
Resource &
Admission Control
(based on TISPAN
RACS framework)
Note:
Functions require
all the border
elements in the
merged field.
Miscellaneous
234
The BGF (7510 Border Gateway) is a packet-to-packet gateway for user plane media traffic. The BGF perfroms
both policy enforcement functions and NAT functions under the control of BGC. The following are the
services provided by this capability:
Open/close gates
Packet marking
Resource allocation (per flow)
Network Address Translation (NAT)
Hosted NAT traversal
Policing of down/uplink traffic
Network Architectures
Border Functions - QoS Statistics
5450 ISC/IRC can provide bearer level QoS statistical information to service
providers for per session Key Performance Indicator (KPI) and PM counts:
To correlate the QoS statistics with the IMS call data (CDR), the P-CSCF or the IBCF
passes the IMS Charging Identifier (ICID) to the SPDF.
During call termination, the SPDF collects the session QoS statistics from the BGF.
The SPDF sends an ACR(Event) message over the Diameter Rf interface to report the
QoS statistics to the CCF.
A network management component (for example, 8920 SQM) pulls the QoS statistics
from the CCF and presents the statistical information.
The QoS statistical information contains network statistics and RTP statistics.
235
Network Architectures
Border Functions - IPv4 to IPv6 Interworking
IPv4 to IPv6 interworking is provided at the boundaries of the IMS core network
and allows for:
IPv4 and IPv6 UEs to work with the IMS core, whether it is IPv4-based, or IPv6based
IPv4 and IPv6 UEs to communicate with each other through the IMS core
IPv4 and IPv6 UEs to exchange media through the media and endpoint layer
236
Interworking of Media between IPv4 and IPv6 Networks is implemented in LSM_18.0 delivery (applicable to ICS
1.2 and IMS 8.X). This feature is only supported on the ATCA platform. It may work on CPBS, but it is not
guaranteed. Customers with mixed hardware (cPSB and ATCA) will need to set the IMS core flag to IPv4.
This feature provides the functionality to interwork the bearer between IPv4 and IPv6 networks. Therefore if
the access side media is IPv6 and network side media is IPv4 then a Border Gateway (C-BGF or I-BGF) can be
used to interwork the media between the two address spaces.
LCP/IMS core supports both IPv4 and IPv6, which means that the following interactions can occur at the
boundaries: IPv4-IPv4, IPv4-IPv6, IPv6-IPv4 and IPv6-IPv6.
IPv4/IPv6 support in the IMS core:
IP addresses in the diameter message may be either IPv4 or IPv6.
IP flows may be either IPv4 flows or IPv6 flows; that is, source and destination addresses of a flow is either
both IPv4 or both IPv6. [IP Flow: A unidirectional flow of IP packets with the same source IP address and
port number and the same destination IP address and port number and the same transport protocol (refer
to 3GPP TS 29.214)]
Diameter connection to the PD-FE may be either IPv4 or IPv6.
Network Architectures
Border Functions - IPv4 to IPv6 Interworking Gateway
The 5450 ISC/IRC and the 7510 Border Gateway are acting as an IPv6/IPv4
Interworking Gateway:
The Application Layer Gateway (ALG) in the iAGCF, P-CSCF, and IBCF supports
the IPv4 to IPv6 media interworking function.
Based on the IP version of the IMS core network, the ALG translates the
received address to the core IP version.
The ALG allows for the insertion of a BGF to perform media interworking
controlled by an SPDF.
Peering Border
Access Border
SIP Signaling
IPv4
Interworking
and
5450 ISC
P-CSCF/
AGCF
5450 ISC
IBCF
IMS Core
5450 IRC
SPDF
IPv6 UEs
IPv4 or IPv6
SIP Signaling
Interworking
5450 IRC
SPDF
IPv4
and
IPv6
Peering
SIP Media
Interworking
7510
BGW
237
7510
BGW
SIP Media
Interworking
Networks
BGF insertion through the following Diameter path: ALG SPDF BGC BGF. (Not shown: H.248 Device Server
(refer to CM in OAMP) acts as BGC.)
The assumption is that BGF interworking will be provided on top of existing mechanism that must be in place
in order to include the 7510 Border Gateway in the media path, i.e. Near-end NAPT must be set in the
SBLP profile used by the P-CSCF, etc.
H.248 communication between the 5450 ISC/IRC and the 7510 Border Gateway is over an IPv4 connection,
which will carry IPv6 addressing in the application signaling.
For example, for IPv6 to IPv4 interworking the BGC (H.248 DS) will pass the IPv6 address in the H.248
Local/Remote Descriptor for the access side and IPv4 address for the core side:
Access/Peering side - Add command c=IN IP6 $
Core side Add command c=IN IP4 $
IPv4 to IPv6 Interworking depends on the following 7510 BGW Feature: Dual stack support on the 7510
(Release 7510R32-PRS94 for IMS 8.3/7.6 and ICS 1.2)
7510 BGF will support dual stack with V6 and V4 addresses and therefore IPv4 as well as IPv6 packets can be
transmitted/received on the same physical interface concurrently. Dual stack on the 7510 BGF is supported
on PIM2 cards only.
The capability will support setting up of a context with an ephemeral termination within IPv4 and IPv6 realm
to perform IP version translation. Thus interworking between an IPv4 and IPv6 termination of an H.248contrlled IP-to-IP context is supported. IPv4 and IPv6 addresses can be assigned on one interface. VLAN
tagging is supported for the IPv6 packets.
The BGF maps the realm to VLAN. A given VLAN can support v4 only and v4/v6 traffic. Up to 512 Realms with
unique VLAN ID each, are supported to connect packet networks to the BGF. IP realms can be assigned to a
unique Gigabit Ethernet interface or can be distributed over multiple Gigabit.
All Rights Reserved Alcatel-Lucent 2007
<COURSEPARTNUMBER> Edition <COURSEEDITION>
Page 237
Network Architectures
Border Functions - IPv4 to IPv6 Interworking Example Scenario 1
SDP
(IPv4)
S-CSCF
IBCF
5450 (IPv6)
SDP
(IPv6)
SDP
(IPv6)
I-CSCF
IBCF
SDP
(IPv6)
SDP
(IPv4)
P-CSCF
S-CSCF
SDP
(IPv6)
P-CSCF
diameter
diameter
SDP
(IPv6)
SPDF
SPDF
SPDF
H.248
H.248
C-BGF
I-BGF
Bearer Path
C-BGF
UE-A
238
SDP
(IPv4)
UE-B
All Rights Reserved Alcatel-Lucent 2010
Additional information:
Originating and Terminating PCSCF( iAGCF/IBCF) can control its own Border Gateway.
IPv6 published NI should be used between the IBCFs. This also requires coordination of the originating core
IBCF profile Remote Network IP Version with the originating core IBCF address resolution of the terminating
core IBCF FQDN.
Originating P-CSCF checks config flag for media interworking
The IBCF in the originating core checks Remote Network IP Version flag for media interworking.
Terminating P-CSCF checks registration data for media interworking
Network Architectures
Border Functions - IPv4 to IPv6 Interworking Example Scenario 2
5450 (IPv6)
SDP
(IPv4)
S-CSCF
iAGCF
S-CSCF
I-CSCF
SIP
(IPv4)
diameter
SDP
(IPv4)
SDP
(IPv4)
SDP
(IPv4)
SDP
(IPv4)
SPDF
C-BGF
diameter
SPDF
H.248
AGW
P-CSCF
SDP
(IPv4)
H.248
Bearer Path
C-BGF
UE-B
UE-A
239
Network Architectures
Border Functions - IPv4 to IPv6 Interworking Example Scenario 3
5450 (IPv6)
SDP
(IPv6)
SDP
(IPv6)
IAM
I-CSCF
IBCF
SDP
(IPv6)
S-CSCF
SDP
(IPv6)
P-CSCF
diameter
SPDF
H.248
Bearer Path
240
SPDF
SDP
(IPv4)
H.248
MGW
I-BGF
C-BGF
MGCF interworking with a different IP version than the core is supported with the MGCF is in a different realm,
i,e. through IBCF. But MGCF must have the same version when in the same realm compared with core
network.
IPv4 published NI should be used between the MGCF and IBCF.
IBCF in Terminating Core checks config flag for media interworking
Terminating P-CSCF checks registration data for media interworking
No work needed to support IW for intra domain and inter domain.
Network Architectures
Border Functions - Optimal Media Path
Each Border Gateway (BGW) likely increases the latency in the media path due
to BGW processing time. The cumulative effects of multiple BGWs may lead to
unacceptably long end-to-end bearer path delay for a multimedia session.
Optimal Media Path is the border function to bypass unnecessary BGWs in the
media path during SIP/SDP call session establishment to reduce media path
delay:
Remove the unnecessary BGWs during call processing if the same realm could be found
in the signaling session setup phase.
An IP realm identifies when one network entity is reachable from another through a
fully connected common IP address space.
241
The IP Multimedia Subsystem (IMS) and other SIP networks have the option to deploy border gateways
between the IP realms defined by each network. Within an IP realm every endpoint is reachable from any
other endpoint using a common address space. Each BGW typically provides a firewall or Network Address
Port Translator (NAPT) to limit access to endpoints within a realm. An Application Layer Gateway (ALG)
controls each BGW to allocate new IP addresses and ports as necessary for each SDP media line and updates
the SDP connection and port information in each forwarded SDP offer and answer to effectively insert the
BGW into the end-to-end multimedia session path.
IP realm: Represents a fully interconnected IP address space (with ALG/BGs) and has a unique name.
Published Realm: defines the access/External side realm. (Access realm was renamed as Published realm.) It
will be the incoming realm received in the last added Visited-Realm if the previous ALG supports the BGW
bypass function. (Published Realm Name = Border Gateway Realm URI)
Core Realm: defines the core/Internal side realm; the Core Realm is the outgoing realm at a given ALG when
an SDP message comes from the external network/access side.
When the ALG receives an SDP offer from a UE or another ALG, it first determines the next IP realm for the
outgoing side of the media path. ALG examines the previously visited IP realms embedded in the received
SIP offer. If the next outgoing realm matches any of the visited-realm instances in the SDP offer, ALG can
bypass one or more BGWs, including itself. There are four cases depending on the matching between
visited-realm in incoming SDP offer and realm value which can be accessed by ALG :
Bypass the controlled BGW and one or more prior BGWs
Bypass the controlled BGW
Bypass prior BGWs
Bypass no BGWs (no match)
Network Architectures
Border Functions Border Gateway Bypass Example
ALG C detects that the incoming realm of BGW A matches the next realm of BGW
C. Therefore ALG C:
1. Removes the realm information of BGW B
2. Skips its own BGW C
3. Populates the IP address and port number in the c-line and the m-line of the
SDP body with the IP address and port number received by BGW A
As the result, BGW B and BGW C are bypassed.
Note: Rx represents IP Realms
SIP
signaling
R1
ALG
A
BGW
A
ALG
B
R2
R2
BGW
B
ALG
C
R3
R3
BGW
C
ALG
D
R1
Bearer
242
R1
BGW
D
R4
Network Architectures
Border Functions - SIP Message Screening
SIP message screening provides a means for an IMS network operator to program
their IMS network to manipulate SIP messages that are being exchanged
between their IMS network and external networks.
SIP message screening is applied after the Security Gateway has performed its
tasks as an additional mechanism to define rules based on the content of the
message in order to:
SIP message screening can be enabled on the P-CSCF and the IBCF.
243
Additional information:
This feature eliminates the need of an S/BC to perform this capability.
WARNINGS
A SIP Filter is stateless and any modifications made by the SIP Filter are permanent.
A SIP Filter is applied to the intended message as written by the user; this can be both beneficial and
harmful.
It is the responsibility of the user to understand the SIP protocol when modifying the SIP message, thus not
breaking the protocol (RFC 3261).
SIP screening is not part of the border element; that is, P-CSCF/IBCF does not control this functionality.
The filters introduced by SIP Screening provide an operator with a great deal of flexibility. This flexibility, if
not properly used, can introduce potentially serious breakages so must be used carefully. To help with the
usage of filters, two tools are provided for this feature in the SIP Screening CLI on the CNFG host:
SIP Screening Message Trace, is a mechanism to allow the operator to see a step by step break down of the
modifications a filter set has on a SIP message for a specified UE.
SIP Screening Test Message, provides the ability to send in an operator created, SIP message directly to SIP
screening, bypassing normal call processing, to see what affect a filter set has on a message without making
the filter set live to traffic.
Network Architectures
Border Functions - SIP Message Screening Architecture
IMS peering
network
Access
network
A
Access
network
B
Signaling
firewall
5450 ISC
IBCF-1
P-CSCF A
IBCF-2
P-CSCF B
IBCF-3
Signaling
firewall
Enterprise
network
IBCF-4
244
VoIP peering
network
IP PBX
The architecture assumption is that SIP traffic exchanged with a particular host/network will be handled by a
specific P-CSCF or IBCF instance. The signaling firewall or routers must be configured to route incoming SIP
traffic to the appropriate P-CSCF or IBCF instance.
IPsec is used for SIP traffic exchanged with the external networks in the right.
Network Architectures
Border Functions - SIP Message Screening Operations
Examples of basic message screening operations include:
Discard a response
245
Network Architectures
Border Functions - SIP Message Screening Example 1
Original SIP message
v=0
o=- 621019833 819968676 IN IP4 x.x.x.x
s=c=IN IP4 x.x.x.x
t=0 0
m=audio 5006 RTP/AVP 8 3 0
246
In this example:
The CIC is retrieved from a user header; in this example user header X-DataHeader: cic=281;tg=192
The CIC is checked if the CIC parameter contains a value of 281
The CIC is added to the content to the R-URI
The user header (X-DataHeader: cic=281;tg=192) is deleted.
Another example:
you can modify the R-URI of incoming traffic to route traffic from a specific number range to another local
policy and save the original URI in a new header. (For instance, numbers ranging from 17134882000 to
1713488000 are routed to 178134880000.)
Network Architectures
Border Functions - SIP Message Screening Example 2
Original SIP Message
247
In this example:
If header Content-Type: message/external-body , extract the URL from the Content-Type header and add
this URL to a new user header X-BADURL.
Another example:
A message can be rejected by either the Content Type or Content Length. You can write a filter to reject
(return 403 Forbidden response) if MESSAGE request message contains header Content-Type:
message/external-body from a specific URL (URL="http://xyz.com/games )
Network Architectures
VoIP Emergency Services
248
Network Architectures
VoIP Emergency Services in the IMS Network
The Emergency CSCF (E-CSCF) is a SIP
proxy server that provides IMS support
for emergency call routing of VoIP
emergency sessions.
249
Network Architectures
VoIP Emergency Services - E-CSCF in 3GPP/TISPAN Solution
In the 3GPP/TISPAN solution, the E-CSCF provides the following
Emergency services functions:
The E-CSCF and the P-CSCF are always located in the same network.
250
Network Architectures
VoIP Emergency Services - P-CSCF in 3GPP/TISPAN Solution
In the 3GPP/TISPAN solution, the P-CSCF provides the following
Emergency services functions:
Support default handling (for example, when a next-hop URI does not
respond, or when origination is from an unregistered PUID) .
251
The support for emergency session origination from unregistered PUID can be provisioned.
The selected E-CSCF to route to (the next-hop URI) can be provisioned.
P-CSCF checks the validity of the caller Tel URI if provided by the UE and shall provide the Tel URI in the session
establishment request if it is aware about the Tel URI associated with the emergency Public User Identifier.
Additional information
With respect to determining location information, different access networks will have different methods of location
determination. The E-CSCF can accept location information from the PIDF-LO attachment or information from the PAccess-Network-Info header. As we approach different customers, there will be different format of location that is being
used and thus the P-CSCF and the ECSCF will be updated accordingly.
Network Architectures
VoIP Emergency Services - E-CSCF in the NENA i2 Solution
In the NENA i2 solution, the E-CSCF is invoked as for a terminating Public
Service Identity (PSI) and provides the following functions:
252
The E-CSCF is the standards-compliant replacement of the I-EAS. In the ECSCF profile (prior to IMS7.0/R15, the IEAS
profile) a flag is added to set this mode. If the flag is not set the E-CSCF behaves exactly like the former I-EAS (including
support for HSS query), which is described in the slides that follow.
Of course the Public Safety Answering Point (PSAP) that is contacted, requires location information about the calling party.
That IS handled according to the requirements, but beyond the scope of this lesson. However, detailed information in
SRD-5878.
The SIP INVITE message is modified as follows:
The Request-URI value is replaced with an ESRN
The value of the P-Asserted-Identity is replaced with the Emergency Services Query Key (ESQK) if received from the
VPC
When replacing a SIP header, the entire header is replaced. No parameters from the original header are carried forward
since they may no longer be relevant.
Additional information
Support of NENA i2 v2 interface: An XML interface to a VoIP Positioning Center (VPC) to determine the location-based
route to the correct emergency center.
Support of NENA i2 v6 interface: A SIP interface whereby all emergency call are routed to an emergency peering network;
the emergency peering network will take care of routing the emergency call to the correct emergency center.
Support of non-standard solutions: The ESRN is provisioned in the IMS domain per subscriber:
Stored in the HSS and queried by the E-CSCF
Stored in the HSS and queried by the pseudo-EAS function in the S-CSCF
Defined in the FS 5000 numbering plan to invoke an emergency call.
Network Architectures
VoIP Emergency Services - E-CSCF Charging
Accounting characteristics:
Save the IMS Charging Identifier (ICID) that is in the incoming INVITE message
Insert the ICID in all outgoing messages
Depending on the state and the type of transaction, send ACR (EVENT)
messages to the CCF
253
Network Architectures
VoIP Emergency Services The Problem
IMS
ESRN 1, based on
Subscriber location
Emergency number
(911 or 112)
Emergency
Emergency
Center 1
Center 2
254
Network Architectures
VoIP Emergency Services - Functions
VoIP Emergency services must address the following:
255
Additional information
Automatic location determination is not mandated at this time. If a subscriber moves their VoIP unit to a new location, the
subscriber is responsible for notifying the service provider of the new location. Similar regulation applies to other
countries (than NAR). However, there is an expectation that FCC will require "automatic location update"
some time in the near future.
Network Architectures
VoIP Emergency Services - Routing of the Emergency Call
Each customer database may have its own protocol for interfacing with
this database; the currently supported solutions are:
NENA i2 V2 interface: An XML interface to a VoIP Positioning Center (VPC) to
determine the location based route to the correct emergency center (PSAP).
NENA i2 V6 interface: A SIP interface whereby all emergency calls are routed
to an emergency peering network, which takes care of routing the emergency
call to the correct PSAP.
256
Network Architectures
VoIP Emergency Services - ESRN Retrieval Methods
For subscribers with a fixed location: one ESRN per subscriber, which
can be stored in:
5420 CTS (TAS)
HSS:
Queried by the E-CSCF
Queried by the pseudo-EAS (Emergency Application Server)
257
Additional information:
The current NENA i2 architecture depends on having the endpoint include its position information in the INVITE message
sent to IMS to initiate the emergency call. When an emergency call is made by a VoIP endpoint, an INVITE is sent to the
P-CSCF and S-CSCF assigned to the calling user. If the Request-URI contains a SIP URI with user=phone parameter or
contains a TEL URL, then S-CSCF performs ENUM query to determine how to route called digits, which would normally
be an E.164 number but could also be an emergency number. In the case of an emergency number, the ENUM/DNS
server will be provisioned to return a NAPTR RR with a SIP URI containing a host name that will resolve to the I-CSCF
and a user part containing the rest of the PSI associated with the EAS. This SIP URI is placed in the Request-URI and the
INVITE forwarded to the I-CSCF. If the received value in the Request-URI was not an E.164 number (e.g.,
sos@service_provider.net), the ENUM/DNS query would not be performed and the INVITE would be routed to the ICSCF indicated by the host name. Once the I-CSCF receives the INVITE, it queries the HSS to obtain the registration
status of the called party and the assigned S-CSCF, and in this case, the message that is returned indicates the EAS in the
server name AVP (Attribute Value Pair) instead of S-CSCF. The ICSCF thus routes the INVITE message to the EAS.
If any AS's should not be executed during an emergency session, the initial Filter Criteria (iFC) has to be configured to
recognize the emergency session and not invoke the AS. An example of a possible AS that may not be allowed during an
emergency session is a Telephone AS that may allow unwanted supplementary services such as call hold and 3-way
calling. The iFC for the unwanted AS needs to identify the emergency session by evaluating the To header in the SIP
INVITE for all the possible TEL URLs and SIP URIs that may initiate an emergency session.
Network Architectures
VoIP Emergency Services - Determine the VoIP Endpoint Location
258
It is expected that each of the access network will have its own mechanism of location determination.
In some case, the network might have the capability to determine the location of the endpoint for some access network. In
other case, the UE is expected to have the ability to get its own location from a Location Information Server (LIS) and
transmit its location as part of an INVITE, if the session is associated with an emergency call. Therefore, the location
determination functionality is very much dependent on the access network and is independent of the IMS network.
Note: how to determine location information (i.e. automatic location determination) for the various accessed network is still
being discussed in the industry. As well, there might be various mechanism of location determination for a given access
network and thus each customer might use different mechanism for a given access network.
Network Architectures
VoIP Emergency Services - 5450 ISC Solutions
The 5450 ISC supports the following Emergency services solutions:
259
VoIP calling is no longer an emerging technology. VoIP is now becoming commonly deployed to consumers and businesses.
Along with being used by the general public comes the need to support emergency calls. Although within the United
States, the FCC has mandated support for emergency calls for circuit based wireline and mobile calls, there has not been a
mandate to support VoIP emergency calls until now. The FCC has published a Notice of Proposed Rule Making (NPRM)
on E911 Requirements for IP-Enabled Service Providers (WC Docket Nos. 04-36, 05-196), to require VoIP emergency
calls to be routed to the correct emergency center based on the callers registered fixed location. Automatic location
determination is not mandated at this time. If a subscriber moves their VoIP unit to a new location, the subscriber is
responsible for notifying their service provider of their new location.
Currently, the "NENA Standards for VoIP/Packet Migration i2 Solutions specification is approved and is used for the IMS
initial emergency call routing offer. The basic 3GPP (TS 23.167) and TISPAN (TS 182 009) emergency architecture
solution is also supported. As more of the standards become available, the Lucent IMS solution will evolve to support
them.
Additional information
The TISPAN/3GPP/PacketCable solution is introduced to support IP based emergency calls origination. ETSI TISPAN is
defined for fixed broadband networks, 3GPP is associated with wireless networks and PacketCable for packet cable
network. TISPAN, PacketCable and 3GPP2 are expected to follow the same architecture solution as 3GPP.
TISPAN = Telecommunications and Internet converged Services and Protocols for Advanced Networking.
Emergency center is often referred to as Public Safety Answering Point (PSAP).
Network Architectures
VoIP Emergency Services - 3GPP/TISPAN Solution Architecture
260
The E-CSCF is the standards-compliant replacement of the I-EAS. In the ECSCF profile (prior to IMS7.0/R15, the IEAS profile) a flag is
added to set this mode. If the flag is not set the E-CSCF behaves exactly like the former I-EAS (including support for HSS query),
which is described later.
In the case the UE is roaming, the mutual network is the visited network.
CLF query:
For registered users, the P-CSCF would query the CLF at registration time. For unregistered users, the P-CSCF would query the CLF at
call time. The UE performs the IMS registration by sending REGISTER message to the PCSCF. The P-CSCF queries the CLF for the
location information. The CLF returns the location information to the P-CSCF and this location information is cached by the P-CSCF.
Note that the location information is inserted by the P-CSCF in the P-Access-Network-Info (PANI) header of the INVITE that is sent to
the E-CSCF.
LRF query:
If location information is not included in the emergency request or additional location information is required, the E-CSCF may request
Network Architectures
VoIP Emergency Services - 3GPP/TISPAN Solution Scenario
261
Additional information
If the caller is:
Registered, the P-CSCF queried the CLF for location information during registration.
Unregistered, the P-CSCF may query the CLF for location information during origination, if provisioned to do so.
The location information from the CLF UDA response will be saved in P-CSCF registry. This location information will
then be populated in P-Access-Network-Info header of most of the SIP messages going towards the IMS core.
The P-CSCF identifies emergency calls for originating sessions only based on the value of the Request URI (for example
911, 112, etc.).
Once the call is routed to the E-CSCF, the E-CSCF would normally consult with the LRF (or possibly another separate
network entity such as VPC, or some sort of database) to get a routing number to the PSAP. This is based on the
Emergency Host URI for the emergency session that you must provision in the P-CSCF profile. (Which typically is the
BGCF that E-CSCF-1 or E-CSCF-2 must forward to.) If more than one external emergency URI is needed, a PseudoNAPTR record should be provisioned.
However, emergency calls can also be routed over the Intrado emergency peering network (using the v6 interface). The
Intrado emergency will determine the correct the PSAP and perform the appropriate routing. Refer to
http://www.intrado.com
Network Architectures
VoIP Emergency Services - E-CSCF in 3GPP/TISPAN Solution
In the 3GPP/TISPAN solution, the E-CSCF provides the following
Emergency services functions:
The E-CSCF and the P-CSCF are always located in the same network.
262
Network Architectures
VoIP Emergency Services - P-CSCF in 3GPP/TISPAN Solution
In the 3GPP/TISPAN solution, the P-CSCF provides the following
Emergency services functions:
Support default handling (for example, when a next-hop URI does not
respond, or when origination is from an unregistered PUID) .
263
The support for emergency session origination from unregistered PUID can be provisioned.
The selected E-CSCF to route to (the next-hop URI) can be provisioned.
P-CSCF checks the validity of the caller Tel URI if provided by the UE and shall provide the Tel URI in the session
establishment request if it is aware about the Tel URI associated with the emergency Public User Identifier.
Additional information
With respect to determining location information, different access networks will have different methods of location
determination. The E-CSCF can accept location information from the PIDF-LO attachment or information from the PAccess-Network-Info header. As we approach different customers, there will be different format of location that is being
used and thus the P-CSCF and the ECSCF will be updated accordingly.
Network Architectures
VoIP Emergency Services - CLF in 3GPP/TISPAN Solution
The P-CSCF:
Queries the CLF during registration or during origination of unregistered PUID
to retrieve UE location information.
Passes the location information retrieved from the CLF in the P-AccessNetwork-Info (PANI) header to other IMS components (such as the E-CSCF) in
SIP messages that are applicable to PANI header
Removes the PANI header from SIP messages that are destined to the UE
before forwarding the SIP messages.
264
Additional information
The assumption is that the CLF functional entity resides on the formal Alcatel platform SRB 5430.
Network Architectures
VoIP Emergency Services - LRF in 3GPP/TISPAN Solution
The E-CSCF queries the LRF for the proper routing information/PSAP
destination based on the location of the endpoint.
265
Network Architectures
VoIP Emergency Services - URN Request URI
When Emergency services are provided in the TISPAN/3GPP solution, the
P-CSCF inserts a URN in the Request-URI of the outgoing INVITE
message to route to an E-CSCF.
Example:
266
In IMS7.0 time frame, the new URN request URI, such as urn:service:sos, is only sent from P-CSCF and to E-CSCF. If
other nodes received this new URI, it may reject the call.
In the future the following example could be added in the slide above:
A call with incoming "INVITE urn:service:sos.police" would be identified as emergency call by the P-CSCF and the
outgoing message would be "INVITE urn:service:sos.police , which is routed to E-CSCF. Note in this case, the R-URI
as received from the UE is passed unchanged to the "Emergency Host URI". This is needed in order to allow the ECSCF to perform the additional translation to map to the correct emergency center i.e. urn:service:sos.police would be
mapped to the Police URI and potentially urn:service:sos.fire would be mapped to the Fire URI.
Additional information
About URN (from Wikipedia):
A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that uses the urn scheme, and does not imply
availability of the identified resource. Both URNs (names) and URLs (locators) are URIs, and a particular URI may be a
name and a locator at the same time. See RFC 2141 ("URN Syntax").
URLs for locating or finding resources
URNs are used for identification.
Uniform Resource Names (URNs) are intended to serve as persistent, location-independent resource identifiers and are
designed to make it easy to map other namespaces (that share the properties of URNs) into URN-space. Therefore, the
URN syntax provides a means to encode character data in a form that can be sent in existing protocols, transcribed on
most keyboards, etc. A URN is like a person's name, while a URL is like their street address. The URN defines
something's identity, while the URL provides a method for finding something. Essentially, "what" vs. "where".
Service URN is a particular type of URN UR, characterized with the Namespace Identifier of service
Network Architectures
VoIP Emergency Services - NENA i2 Solution Architecture
267
Additional information
Normal terminating session handling: The INVITE message eventually arrives at the I-CSCF, which queries the HSS as
usual. However, because the emergency number is a PSI (Public Service Identity) instead of a PUID, the HSS query
returns an AS URI instead of a terminating S-CSCF. The applicable AS (that is, the E-CSCFwhich used to be the IEAS) provides the required service, determined by provisioning the Emergency Session Routing Method parameter in
the E-CSCF profile:
1. VPC-V2: Query a VCP over the NENA i2 v2 interface.
2. VPC-V6: Forward the emergency request to a emergency peering network, which will query a VCP.
3. ECSF-HSS: Query the HSS over the Sh interface (non-standard/pre-standard solution).
Then using the retrieved ESRN forward the emergency request to the next hop in order to route to the correct PSAP in the
PSTN (In case 1 or 3 the next hop is typically the BGCF).
Network Architectures
VoIP Emergency Services - E-CSCF in the NENA i2 Solution
In the NENA i2 solution, the E-CSCF is invoked as for a terminating Public
Service Identity (PSI) and provides the following functions:
268
Additional information
Support of NENA i2 v2 interface: An XML interface to a VoIP Positioning Center (VPC) to determine the location-based
route to the correct emergency center.
Support of NENA i2 v6 interface: A SIP interface whereby all emergency call are routed to an emergency peering network;
the emergency peering network will take care of routing the emergency call to the correct emergency center.
Support of non-standard solutions: The ESRN is provisioned in the IMS domain per subscriber:
Stored in the HSS and queried by the E-CSCF
Stored in the HSS and queried by the pseudo-EAS function in the S-CSCF
Defined in the FS 5000 numbering plan to invoke an emergency call.
Network Architectures
VoIP Emergency Services - PSI-Based Routing to the E-CSCF
The I-CSCF queries the HSS with an
Emergency SIP URI to determine the
registration state of the terminating
party.
All possible Emergency SIP URIs must
have a Public Service Identity (PSI)
entry pointing to the E-CSCF;
Therefore, the HSS responds with
indication to contact the E-CSCF.
The I-CSCF forwards the INVITE
message to the E-CSCF.
269
Network Architectures
VoIP Emergency Services - NENA i2 Solution Routing Methods
Based on its provisioning, the E-CSCF can use the following routing
methods :
1. Query the HSS over the Sh interface in the E-CSCF.
2. Query the VoIP Positioning Center (VPC) over the NENA i2 V2 interface.
3. Forward the INVITE message over a V6 interface to a Peering Emergency
Services Partner, where a VPC is queried
Alternately, the S-CSCF can be provisioned to query the HSS over the Cx
interface (pseudo-EAS).
270
Additional information
The pseudo EAS is also referred to as the E911 E-AS-Lite, which was introduced in IMS 3.1,
feature 12203.2 for SBC CVOIP offer.
(The original IMS 5.0 plan was to remove this method, however, the customer would like to keep
it. As a result, the E-CSCF will continue to support the three methods to obtain ESRN. Now the
plan is not to remove this method for the time being. As a result, it it still supported in IMS
7.0/R15.)
Comment from Vickie Kolka, dated Jan 18, 2007: IMS 6.0 is done, and this method was not
removed.
Comment from Thomas Nian, dated Jan 18, 2007: Describe in which release for each routing
method method to get ESRN:
a0. pseudo EAS (SCSF to get ESRN from HSS via CX interface) is available in IMS3.1.
a. VPC (via V2 interface) is available in IMS 4.0
b. EAS-HSS (get ESRN from HSS via SH interface) is available in IMS4.1
c. V6 (send the emergency call to a VPC via V6 interface, and VPC will route the call) is
Network Architectures
VoIP Emergency Services - HSS Method
271
Network Architectures
VoIP Emergency Services - VPC Method
If the provisioned routing method is
VPC-V2:
The E-CSCF takes the location information
from the INVITE. This can be:
A PIDF-LO (Presence Identify Data Format Location Objects) body
The MAC address in the P-Access-NetworkInfo header
272
Network Architectures
VoIP Emergency Services - Peering Network
If the provisioned routing method is
VPC-V6:
The E-CSCF unconditionally proxies the
call to the Emergency Peering Network,
based on the provisioned next hop
identity over V6 interface.
The routing proxy & redirect server
queries the VPC (over V2 interface) to
locate the assigned ESGW.
The routing proxy & redirect server
routes to the ESGW, which contacts
the PSAP that serves the geographic
location of the caller.
273
Additional information
In IMS6.0, after the E-AS sent an emergency call to a VPC (using V6 interface), the E-AS takes
no further action. If the route failed during the first try, the emergency call was dropped. To
provide a safe-guard, a default route for v6 interface is implemented in IMS 7.0. The E-CSCF
will route an emergency call to the default route for v6 (using V6 interface) when the first route
to Default Route / Primary Route for V6 (using V6 interface) failed. A new field, Default
Route for V6, is added in the GUI.
Network Architectures
VoIP Emergency Services - E-CSCF Routing to Next Hop
When the Request URI has been
replaced by an ESRN, the next hop
routing decision is one of the following:
BGCF (scenario may involve the BGCF
in another network)
MGCF (if no BGCF functionality is
required)
Default BGCF (if the INVITE with ESRN
route attempt fails)
274
The decisions must be provisioned in the FS GUI, IMS ECSCF Profile: Next Hop Id and EAS
Default Route
Additional information:
Route from the E-CSCF directly to the MGCF (skipping the BGCF) will not be promoted since it
is believed that most service providers will have their trunks to the emergency services network
distributed across multiple MGWs so the BGCF will be needed. The E-CSCF is able to bypass
the BGCF and route directly from the EAS to the MGCF (however, this is a Test-Only feature):
If none of the functionality of the BGCF is needed in a given service provider's IMS
configuration. This may be in the case of a very small deployment where only a single MGW is
used.
To optimize the call setup. This can be done by setting the E-CSCF "Next Hop" to an MGCF
address instead of a BGCF address. However, it will not be promoted since it is believed that
most service providers will have their trunks to the emergency services network distributed
across multiple MGWs so the BGCF will be needed.
Network Architectures
VoIP Emergency Services - Pseudo-EAS
275
The routing method is provisioned in the FS GUI (IMS->IMS Tables->S-CSCF Profile screen,
Emergency Session Routing Method = HSS (the other option is None), indicating that the SCSCF (actually the pseudo EAS function) is allowed to perform the query to the HSS for the
ESRN. The S-CSCF shall only substitute the "generic emergency number" with the ESRN if the
"ESRM field" is set to "HSS" and the filter criteria is met (i.e. the called number matches any
one of the iFC generic emergency numbers).
The pseudo EAS is part of the S-CSCF. Since this service depends on a static ESRN, it is only
available for fixed subscribers (that is, not applicable for nomadic and mobile endpoints). If
subscribers move, they must notify the service provider to register their new location.
When an emergency number is detected in the Request URI (tel:911 or 112), it is replaced by an
ESRN (eg tel: +16305551212) and the proprietary parameter emergency is added to the
header of the INVITE Request-URI.
Additional information
The pAS name provided in the iFC is a reserved string for the S-CSCF to take a special action and
perform a local function call to the pEAS instead of routing the request to a specified AS. The
pAS would only be invoked on IMS UE originations when the called number matches any one
of the iFC generic emergency numbers.
Network Architectures
VoIP Emergency Services - E-CSCF Charging
Accounting characteristics:
Save the IMS Charging Identifier (ICID) that is in the incoming INVITE message
Insert the ICID in all outgoing messages
Depending on the state and the type of transaction, send ACR (EVENT)
messages to the CCF
276
Network Architectures
Knowledge Check
Please answer the following question.
The E-CSCF terminates VoIP emergency sessions?
This statement is:
A. True
B. False
277
Network Architectures
Knowledge Check
Please answer the following question.
Where can the ESRN be stored?
(More than one answer may apply)
A.
B.
C.
D.
E.
In the HSS
In the I-CSCF
In the E-CSCF
In the S-CSCF
In a VoIP Positioning Center (VPC)
278
Blank Page
279
Architectures
Business Trunking
280
Both access networks and interconnect/peering networks, describe a generic IMS client. However, in both
cases it is also possible that the IMS client is actually a PBX that provides a connection point for many
clients (either SIP based or other protocol that PBX converts to SIP). Typically this would generally
represent an enterprise.
There are two modes of PBX interactions that correspond to the two types of borders:
User-Network-Interface (UNI) model maps to the access network border architecture
Network Architectures
PBX Support - Introduction
Supported PBX types:
IP-PBX, SIP-based
IP-PBX, H.323-based through H.323/SIP capable S/BC
ISDN-PBX, PRA/PRI-based
Access modes:
Registration-based
Corresponds to TISPAN defined Subscription Based Business Trunking
Nonregistration-based
Corresponds to TISPAN defined Peering Based Business Trunking
Solutions:
Distributed IMS
IMS R7.X (cPSB hardware platform)
IMS R8.X (ATCA hardware platform)
281
S/BC can be used to perform the IWF and S/BC can be configured to perform IMS registration on behalf of the PBX (S/BC
in this case is not required to support wildcarded PUID)
ISDN PBX can be supported with this solution, but requires MGCF to perform IWF between ISDN signaling and SIP. IMS
registration on behalf of PBX is also required. This function can either be supported by MGCF or on a separate entity.
Typically the following features are needed from the IMS network
Call Origination from PBX line
Call termination to PBX line, DDI
LI possible on calls from/to PBX, through general LI components
Subscriber behind PBX can trigger Emergency services in IMS and
Access to Legal services, shorts numbers, Directory calls, Free phones
Number portability on number ranges
Telephony Features: CF (on global level), OCB, CLI
Charging: in core, but distinction between private and off-net calls
All Rights Reserved Alcatel-Lucent 2007
<COURSEPARTNUMBER> Edition <COURSEEDITION>
Page 281
Network Architectures
PBX Support - PBX Identities
pbxPrID: The Private User Identity that is assigned to a PBX for PBX registration
and authentication
pbxPUID: an IMS PUID that is associated with a distinct Group Directory Number
(GDN) of a PBX:
Must be a globally routable E.164 number
One or more GDNs can be assigned and provisioned in HSS for each PBX
iDN PUID: an IMS PUID that is associated with a distinct individual Directory
Number (iDN) of a PBX subscriber with DID/DOD capability:
Must be a globally routable E.164 number
One or more iDNs assigned and provisioned in HSS for each PBX subscriber
iDNs can be provisioned in the HSS as a wildcard PUID to simplify the provisioning and
registration processes
wildcard PUID: an IMS PUID that is associated with multiple PBX subscribers
Only implicit registration
NOT used by PBX subscribers for origination or termination of a session
282
DID: Direct Inward Dialing allows a PBX user to directly receive calls originating external to the PBX without
the intervention of an attendant.
DOD: Direct Outward Dialing allows a PBX user to directly originate a call to a destination external to the PBX
without the intervention of an attendant.
PBX suscribers without DID/DOD capabilities are not directly addressable from the IMS, thus do not have
corresponding IMS PUIDs. These users can still originate or receive calls to/from users outside the PBX
through PBX attendant-assisted calls. From the IMS perspective, these calls are to/from the attendant and
use a GDN (for instance, the pbxPUID) for call origination and termination.
The pbxPUID and the iDN PUIDs can be represented in SIP URI (with parameter user=phone) or tel URL format.
SIP-PBX (and SIP phones) to be addressed in generic SIP URI format (e.g., sip:user@host;uri-parameters).
However, the wildcard PUID is restricted to E.164 numbers only.
Network Architectures
PBX Support - Wildcard PUID
Allows call origination and call termination from/to PBX subscribers, whose
numbers are within the range of a registered wildcard PUID.
If no match against a iDN PUID is found during HSS LIR processing, the HSS will search
for a matching wildcard PUID.
Supported in both the external HSS (USDS) and the internal HSS (iHSS in the ICSSIP shelf).
283
Assumption: PBX is usually allocated with one or more contiguous DN ranges, which can be represented by
wildcard PUIDs.
Once the PBX is registered along with a number of wildcard PUIDs encompassing all the IP-PBX endpoints,
any of the endpoints will be able to originate a call or terminate a call. The P-CSCF or S-CSCF will take
care of matching the endpoint number to the wildcard PUID.
Network Architectures
PBX Support - PBX Subscription
Up to 32 PUIDs in the IRS
PBX
Subscription
pbxPrID:
+16307138000@pbx1.imsdomain
Auth-Scheme: HTTP Digest MD5
Password:xxxxx
pbxPUID:
PUID=sip:+16307138000@
pbx1.imsdomain;user=phone
Service
wildcard PUID1:
PUID=tel:+1630224 ![1-9]{4}!
wildcard PUID2:
PUID=tel:+1630979 !....!
Data at HSS
284
Profile
Network Architectures
PBX Support - Wildcard PUID Syntax
1. The wildcard portion of the PUID is delimited by a ! pair.
2. The delimited portion must be at the end of the PUID.
3. Wildcard PUIDs are URI-scheme independent; that is, only sequences of digits
0-9 and an optional leading + can be represented by a wildcard PUID
4. Within delimiters the only valid characters are: decimal digits, . , [ , ] , - , *
5. Number ranges may be specified in two formats:
Format 1: [n-m] means all digits from n to m inclusive
Format 2: . (period) means a single digit in the range from 0 to 9.
6. Within the delimited wildcard, a single digit n is supported.
7. Within the delimited wildcard, * (asterisk) is supported to denote repetition
of the last expression and the asterisk must be the last character within the
wildcard delimiters.
8. It is not allowed to insert a range that overlaps with another range.
285
Example 1:
+1630979!....!
+1630979!.4..!
Example 7-1: +1630979001!.*! is permissible, because the asterisk applies to the immediately preceding
expression.
Example 7-2: +1630979001![2-8]*! is not permissible because [2-8] does not mean any digit between 2
and 8.
HSS will implement syntax checking at provisioning time based on the above rules wherever necessary:
A newly introduced wildcard PUID does not overlap with an existing one (this will be necessary to prevent
the possibility of having multiple match of a given PUID with wildcard PUIDs, which would make it
impossible to determine whether a certain PUID belongs to one PBX or another)
Note, though, that wildcard PUIDs can overlap with distinct PUID (at run time during a search, distinct
PUIDs will be searched first and, if none is found, then wildcard PUIDs are searched)
Network Architectures
PBX Support - Registration-Based Solution Architecture
struc-IMS-reference-arch_full.PNG
SIP/H.323
PRI/PRA
IP-PBX
ISDN-PBX
286
S/BC (such as Acme Packet Net-Net Session Director) can be used to perform the H.323-to-SIP InterWorking
Function (IWF) and S/BC can be configured to perform IMS registration on behalf of the PBX (S/BC in this
case is not required to support wildcarded PUID).
This solution addresses the demand from operators to be able to connect their enterprise customers to an IMS
network. In order to do this they need the ability to register all the IP-PBX endpoints in the IMS network so
that origination and termination is supported for each endpoint. It is not necessary though to support IMS
services on a per endpoint basis for all endpoints. It is sufficient to allow some of the endpoints to have
their own services while the rest all receive the same treatment. The wildcard PUID approach addresses
these operator requirements using the Gm interface.
Network Architectures
PBX Support - Registration-Based Solution (= UNI Mode)
Registration:
Required for each PBX and the DID/DOD numbers owned by the PBX (using wildcard
PUIDs)
Each registration is authenticated using HTTP Digest MD5
Services:
PBX is treated as an untrusted entity by IMS
All the services that are offered to IMS subscribers are available to PBX users
Service invocation is based on service profile, which can be provisioned in the HSS on a
per PBX basis, or on per iDN basis
Solution also allows PBXs to provide services directly to its endpoints without involving
the IMS
287
Network Architectures
PBX Support - UNI Mode PBX Registration
For PBXs connecting to the IMS through the UNI, both a pbxPUID and the iDN PUIDs
must be registered before services can be provided by the IMS:
The pbxPUIDs and iDNs PUIDs (individual and wildcard) are grouped into an
Implicit Registration Set (IRS).
IRS supports up to 32 PUIDs.
After successful explicit pbxPUID registration, the iDN ranges are implicitly registered.
Most efficient in terms of number of registrations (1 registration per PBX).
288
For PBX registration with the IMS, the PBX needs to discovery the P-CSCF to send the SIP REGISTER to. It is
assumed that the P-CSCF FQDN is provisioned in the PBX. The PBX should be able to perform DNS to resolve
the P-CSCF FQDN to one or multiple IP addresses.
Depending on the type of PBX and its capability, following operations are supported:
For a SIP PBX that supports SIP Registration, the PBX can perform registration with the IMS.
For a SIP PBX that does NOT support SIP Registration, S/BC can be used to perform registration with IMS on
behalf of the SIP PBX. (Alternatively, the ALU NNI mode can be used to connect SIP PBX to IMS.)
For a non-SIP PBX, the SIP-GW (which may includes the IWF that performs protocol translation between non-
In the case of H.323 PBX, S/BC can be used to perform the IWF; in addition, S/BC can also perform SIP
registration with IMS on behalf of the H.323 PBX.
In the case of IDSN PBX, a MGCF can be used to perform the IWF; although not a recommended
configuration, if needed, either the MGCF or S/BC can be used to perform SIP registration. (The
recommended configuration is to use NNI Mode for ISDN PBX).
reduced, still not very efficient with provisioning; with the maximum size of the IRS of 32, only
recommended for small PBX (not shown)
Wildcarded registration (Recommended, see slide).
Network Architectures
PBX Support - UNI Mode Origination from IP-PBX
1. IP-PBX endpoint sends an INVITE message, which includes:
2. The P-CSCF tries to find a match between the DID number and the registered
wildcard PUIDs.
3. P-CSCF forwards the INVITE message to the S-CSCF; message includes:
4. The S-CSCF uses the wildcard PUID to find the matching iFC.
5. S-CSCF sends the INVITE message to the 5420 CTS; message includes:
6. The 5420 CTS uses the wildcard PUID to determine the services to be applied
to the originating call.
7. The 5420 CTS sends back the INVITE message to the S-CSCF for onward routing.
289
When an IP-PBX endpoint originates a call (INVITE) it includes the called party number in the Request-URI and
the To: header and its own direct inward dialing (DID) number in the From: header and P-Preferred-ID
header. The P-CSCF tries and find a match between the URI in the P-Preferred-Id and the registered
wildcard PUIDs.
Assuming a match is found the P-CSCF asserts the identity by adding a P-Asserted-Id with a Tel URL set to the
received P-Preferred-Id. It also adds a P-Profile-Key header. This header shall have a normalized Tel URL
version of the matching wildcard PUID (the first distinct PUID within the range specified by the wildcard
PUID) and the actual matching wildcard PUID in an extension parameter. The reason for including the
normalized version is that the Tel URL scheme as defined in RFC 3966 does not support the wildcard regular
expression characters. Thus all headers with a component defined as a Tel URL shall have a normalized
version of the wildcard PUID and an extension parameter: ;wcard-range=wildcard PUID without the
scheme added. When the screening is complete the P-Preferred-Id is removed from the INVITE before it is
sent to the S-CSCF indicated by the service profile of the wildcard PUID. The wildcard PUID may have its
own service profile or it may share the service profile of the IP-PBX PUID.
The S-CSCF uses the wildcard PUID in the P-Profile-Key to find the matching initial filter criteria (iFC).
Assuming that the iFC indicates the services of the CTS the INVITE is sent to the CTS including the PAsserted-Id set to the original DID and the P-Profile-Key including the normalized wildcard PUID and the raw
wildcard PUID. The CTS uses the wildcard PUID received in the P-Profile-Key to determine the services to be
applied to the originating call. The normalized PUID is ignored by the CTS. Since the solution itself does not
require that the wildcard PUIDs have their own services the wildcard PUIDs will inherit the services defined
for their IP-PBX PUID. Once the CTS has provided the necessary originating services and assuming the call
may proceed the INVITE is sent back to the S-CSCF for onward routing.
Network Architectures
PBX Support - Termination to IP-PBX (UNI Mode)
1. An INVITE message arrives at the I-CSCF with a Request-URI set to the DID
number of an IP-PBX endpoint.
2. The I-CSCF queries the HSS (LIR).
3. The HSS tries to find a match between the DID number and a wildcard PUID in
order to return the S-CSCF (LIA).
4. The I-CSCF forwards the INVITE message to the indicated S-CSCF.
5. The S-CSCF uses the DID number to find a match with a wildcard PUID.
6. The S-CSCF uses the wildcard PUID to find the matching iFC.
7. S-CSCF sends the INVITE message to the 5420 CTS; message includes:
8. The 5420 CTS uses the wildcard PUID to determine the services to be applied
to the originating call.
9. The 5420 CTS sends back the INVITE message to the S-CSCF for routing to the
P-CSCF and IP-PBX.
290
Network Architectures
PBX Support Nonregistration-Based Solution Architecture
struc-IMS-reference-arch_full.PNG
SIP/H.323
IP-PBX
291
PRI/PRA
ISDN-PBX
All Rights Reserved Alcatel-Lucent 2010
This solution aligns with emerging 3GPP R8 IMS Centralized Services (ICS) concepts.
S/BC (Acme Packet) may be required to convert H.323 signaling to SIP (H.323 IP-PBX).
Network Architectures
PBX Support Nonregistration-Based Solution (= NNI Mode)
Services:
PBX can be treated as either trusted or untrusted entity by IMS
Services that are offered to IMS subscribers may be available to PBX users
Service invocation is based on unregistered service profile, which can be provisioned in
the HSS on a per PBX basis, or on per iDN basis (wildcard PUID provision can be used)
iDNs must be provisioned in the ENUM database
In a true transit routing case, the IMS does not provide additional services through an
IMS AS
Solution also allows PBXs to provide services directly to its endpoints without involving
the IMS
292
Network Architectures
PBX Support - Transit Routing (NNI Mode)
Incoming traffic enters the IMS at the IBCF (IP-PBX) or MGCF (ISDN-PBX) and is
routed to the Transit Function.
If the IMS offers terminating services to the PBX endpoints, the RTCF
component in the TF routes terminating PBX calls to the IMS.
The domain name for IP-PBX users must be part of IMS domain.
Or, if ENUM look-up and IMS service will be performed by the same operator, routing to
IMS will be based on E.164 number.
Else, the RTCF component in the TF makes routing decisions based on ENUM
query/response and SIP routing principles.
Additional routing capabilities are provided by BGCF and MGCF.
293
The Transit Function is the consolidated I-CSCF/RTCF (also referred to as the I-CSCF with integrated RTCF or ICSCF+). The I-CSCF+, using ENUM, will determine if the originating party is indeed an IMS subscriber. If the
calling party is an IMS subscriber, I-CSCF+ performs a Cx LIR/LIA query to find the S-CSCF name (or assign
one if not registered) and routes this traffic to the IMS core to apply originating services.
The RTCF is responsible for routing IP-PBX originated calls. The RTCF must be configured to perform CgPN
ENUM provisioning. Otherwise, IP-PBX terminated calls require an AS to re-target requests to the IP-PBX, in
which case filter criteria must be provisioned to bring in the necessary AS.
IP-PBX subscribers do not perform IMS registration. IP-PBX calls are offered IMS unregistered subscriber
service.
Authentication of non-REGISTER requests must be disabled. Subscriber authentication is performed by the
IP-PBX.
IP-PBX extension numbers must be provisioned in the ENUM DB to provide a SIP URI for each extension. The
SIP URI can contain an indicator to identify the extension as an IMS subscriber.
Extension numbers must be provisioned in the HSS for origination or termination service.
If an AS is needed for IP-PBX terminations, filter criteria must be provisioned to bring in the necessary AS.
Network Architectures
PBX Support - Origination from IP-PBX (NNI Mode)
IP-PBX1
ENUM
(Vital QIP)
1. INVITE tel:+1425-765-4321
Route sip:ibcf@imsdomain
P-A-I: tel:+1630-123-4567
(Optional)
3. ENUM query for CgPN
& response: e2u+sip with
sip:user@pbx1.imsdomain
I-BCF
2. Forward to RCF/DF
HSS
5. INVITE
Route: sip:scscf@imsdomain;orig
AS
7. unreg
service
S-CSCFo
6. SAR/SAA
In the case of call origination from PBX user, RCF will trigger Cx query for calling party based on provisioned
value per origination host (i.e., PBX). Upon successful Cx query, RCF will route the request to S-CSCF for
unregistered origination processing.
Network Architectures
PBX Support - Origination from IP-PBX Steps (NNI Mode)
RTCF
Converts the originating SIP URI to tel URL (if applicable).
Performs Cx query (LIR/LIA) for calling party directory number based on provisioned
value per origination host (for example, PBX).
295
In the scenarios the legacy PBX is not considered. Just IP-PBX examples.
If the RTCF is provisioned to perform the conversion of the CgPN before the Cx query this avoids double
provisioning in HSS.
Cx query: LIR/LIA
Network Architectures
PBX Support - Termination to IP-PBX (NNI Mode)
1. INVITE tel:+1630-123-4567
Route sip:ibcf@imsdomain
I-BCF
2. INVITE tel:+1630-123-4567
ENUM
(Vital QIP)
(Optional)
3. ENUM query for CdPN
& response: e2u+sip with
sip:user@pbx1.imsdomain
AS
5. INVITE sip:+16301234567@pbx1.imsdomain
Route: sip:scscf@imsdomain;
7. unreg
service
S-CSCFt
AS
HSS
6. SAR/SAA
9. INVITE sip:+16301234567@pbx1.net
(change R-URI domain Route: sip:scscf@imsdomain;
name of PBX)
8. unreg service
I-BCF
IP-PBX1
296
In the case of call terminate on IP-PBX, if the host portion of the R-URI is not within the IMS home domain,
that is to say that the IP-PBX does not reside in the home network, the S-CSCF will route the INVITE to the
IBCF provisioned in the domain routing table. The IBCF routes the request based on the R-URI using DNS.
When the host portion is within the IMS home network and the user portion falls within a range of numbers
specified by the filter criteria, the request is routed to the specified CTS (normal unregistered handling).
The CTS will identify the IP-PBX serving the unregistered subscriber and modifies the host portion of the RURI and sends the request back to the SCSCF for on-going routing through the IBCF.
Network Architectures
PBX Support - Termination to IP PBX Steps (NNI Mode)
The termination request may be directed to the IBCF/RTCF; RTCF queries the
HSS and routes to the terminating S-CSCF.
S-CSCF inspects the host portion of the R-URI, determines that the target is
not within the home domain and routes the request to IBCF.
297
The terminating request can also enter at the I-CSCF, which will then query the HSS and route to the
terminating S-CSCF.
For security reasons, calls that terminate to an IP-PBX must be routed through the exit IBCF/BGW. This
requires the IP-PBX domain name (host part in R-URI) to be outside the home domains of the operator.
However, for providing terminating services to IP-PBX subscribers, they must belong to one of the IMS home
domains of the operator.
Therefore, for call termination to an IP-PBX user, the request must be re-targeted by an AS before the call is
sent to the IP-PBX after IMS service invocation: an AS must be capable to rewrite the host part in the R-URI
such that the IP-PBX domain name does not belong to one of the home domains (anymore). Consequently
the S-CSCF routes the call to the IBCF/BGW, which will then route the call to the IP-PBX by executing
NAPTR/SRV DNS query. (An external DNS server is required to support IP PBXs using the transit method of
communicating to the 5450 ISC and are outside of the home domain.)
Architectures
Lawful Intercept/CALEA
298
Both access networks and interconnect/peering networks, describe a generic IMS client. However, in both
cases it is also possible that the IMS client is actually a PBX that provides a connection point for many
clients (either SIP based or other protocol that PBX converts to SIP). Typically this would generally
represent an enterprise.
There are two modes of PBX interactions that correspond to the two types of borders:
User-Network-Interface (UNI) model maps to the access network border architecture
Network Architectures
Lawful Intercept Architecture
The Unified Lawful Interception Suite (1357 ULIS) supports the interfaces with
the Law Enforcement Agency (LEA)
1357 IMC (Interception Management Center) is used for the provisioning of the target
database with information that is received from the LEA.
1357 LIG (Lawful Intercept Gateway) forwards the LI data to the LEA.
5450 ISC:
Maintains the target database provisioned by the 1357 IMC
Generates Call Identifying Information (CII) related to SIP sessions involving each target.
Invokes the 5900 MRF, when necessary, for intercepting the Call Content (CC) (media)
associated with sessions involving each target.
5900 MRF
Is inserted in the middle of the media streams for the targets.
Replicates Call Content of the session.
Routes the Call Content to the 1357 LIG (a pool of 1357 LIGs can be provisioned).
299
In the 5450 ISC, in each IMS service both the P-CSCF and the S-CSCF service component can query the target
database and can send CII encapsulated in SIP messages to the 1357 LIG.
The target database is provisioned by the 1357 IMC in the CNFG server and downloaded and locally stored on
each IMS service that requires LI:
The list of targets for Lawful Interception
The mode of interception (Call Identifying Information (CII), or both CII and Call Content (CC).
Network Architectures
Lawful Intercept SORM Support
-
(SORM) is the System for Operative Investigative
Activities, which is a lawful intercept specification that is used in the Russian
Federation.
SORM is based on the base lawful intercept architecture (ETSI TS 201 671).
SORM adds that calls are intercepted if the called PUID in the R-URI of an initial
INVITE message matches an incomplete number (a digit pattern that only
partially specifies a directory number):
Incomplete numbers are provisioned in the B-list in the target database.
The B-List consists of up to 1024 digit patterns, where each pattern can be from 4 to
18 digits in length.
The digit patterns are compared to the called number digit by digit starting with the
first digit of the pattern and called number.
300
-
Pronounce: Sistema Operativno-Rozysknykh Meropriyatij
SORM LI is different in that base LI is is matching on fully defined PUIDs (either Tel URLs or SIP URIs in the RURI) associated with ISC subscribers themselves, which are provisioned in the A-list in the target database.
Network Architectures
References
For more detailed information on these subjects refer to the system
documentation.
Functions
Signaling and session handling
Required Services
Network Services
301
Blank Page
302
End of Module
Network Architectures
303
Performing OAM&P
Module Objectives
After you have successfully completed this module you will be able to:
Match the application and task with the appropriate element manager.
305
Module Outline
Performing OAM&P
Introduction
User Interfaces
Element Manager
306
Blank Page
307
Performing OAM&P
Introduction
308
309
310
Configuration
Configuration
Configuration
Fault
Performance
Performance
Security
Management
Northbound NMS/OSS
OMC-P
CM/FM/PM
GUI
MI server
CNFG server
CM/FM/
PM/AM
MI GUI
Prov. GUI
CLI
Applications
5400 LCP
311
Configuration Management : Infrastructure provisioning (5420 CTS and 5450 ISC) is provided by the OMC-P
with a manual GUI or using XML (SOAP) from a Service Activation OSS. In addition subscriber provisioning is
carried out using the provisioning GUI of the OMC-P. The other applications (FS 25000 and NC) are
provisioned using the FS GUI, which is supported by the CNFG service. The provisioning data is transferred to
the CNFG service to be stored in the configuration database
Fault Management: SNMP traps from the applications (and the LCM) are collected by the CNFG service,
transferred to the MI-Agent and presented by the OMC-P.
Performance Management : Performance data of the LCP is collected by the CNFG service, transferred to the
MI-Agent (on the MI service) and presented by the OMC-P and reported to the OSS (if applicable).
Accounting Management: Charging information of each application is sent to the CCF where it is collected and
correlated per IMS function. (Accounting Request messages in accordance with the Diameter protocol).
SurePay CCF provides standard Rf (ASN.1 CDR) to the billing mediation server.
Security Management: Not shown, because it is a function within each separate element manager mainly to
administer the users who are permitted access to the various management systems.
Additional information:
The students may be aware of the FS GUI; if so, point out that the FS GUI is not supposed to be use for
provisioning! Just to view the configuration database for troubleshooting purposes. Note that also the MI-Agent
GUI can be used to view the alarms and the performance data of the LCP that is under control.
The applications on the 5060 ICS are:
5450 ISC
5450 IRC
5420 CTS
iAGCF
GUI = Graphical User Interface run on a maintenance terminal (for example a laptop with the appropriate
software).
Performing OAM&P
User Interfaces
312
Menu bar
313
Toolbar
Normally, the FS GUI is started using the cut-trough in the MI GUI. The FS GUI is a SoftSwitchGUI.exe package
that runs on the maintenance terminal. (Must first be downloaded from the CNFG service).
When the FS GUI (Native EMS) is launched, the top GUI is all that appears. (Normally at the top of the screen.)
The other screens appear when you click one of the tool buttons.
The toolbar make available the most commonly used provisioning windows. Many more windows through the
menus in the menu bar.
314
When the Native EMS is launched, the top GUI is all that appears. (Normally at the top of the screen.) The
other screens appear when you click one of the tool buttons.
The toolbar make available the most commonly used provisioning windows. Many more windows through the
menus in the menu bar.
Select from the FS GUI task bar the required view.
Menu bar
Toolbar
Tree view
Map view
Alarm
Summary
view
Status bar
315
Additional information:
The MI GUI is a web-based interface. On the maintenance terminal start Internet Explorer and in the
address bar type: http://<IP address>:9090
316
Select Fault Management form the tree view, Alarms, and the Alarm window will open. Double click an alarm
and a window will open with the alarm details.
317
318
Cut-through is used for example to set up an FTP session or a Telnet session with an individual service in the
LCP or a media gateway. The CLI appears in a new window.
Typically, FTP or Telnet applies to a physical card (right-click the card in the MI GUI to display the context
menu). Currently, the only GUI that you can invoke is the FS GUI: right-click the virtual CNFG service in the
MI GUI.
Right-click a service
A context menu appears
319
320
Menu bar
Toolbar
Status tab
Status pane
Resize tool
321
The OMC-P is the main ems for the Lucent CP-CM solution. The OMC-P client software should be downloaded
from the OMC-P server. The OMC-P software is formerly knows as Telica Plexview.
The various functions of the OMC-P can be accessed via different ways, menu bar, short keys, clickable items,
right mouse button
Additional information:
OMC-P: The Operations & Maintenance Center - Plus (OMC-P) provides provisioning support for the FS 5000,
subscriber data and dialing plan and optionally the Lucent Session Manager.
322
Select a network element, select view form the Action pull down menu. The configuration window will open.
323
Select a network element, double-click Subscriber Database, double-click Subscriber Party, search by AID subscriber list appears.
Right-click one of the subscriber parties, and then click view (ses screen capture) to view the subscriber info;
in the screen capture on the right, the Features tab is selected.
Here you can assign the supplementary services and the dialing plan tables.
Additional information:
Note that the subscriber data that is provisioned here, is stored in the subscriber database of the FS 5000
(FSDB service), in the web portal (LCM), and the (local) HSS.
Performing OAM&P
Element Managers
324
325
326
Additional information:
Cut-trough is typically used for for low-level configuration management and operational tasks
327
5420 CTS
5450 ISC
5450 IRC
FM
OMC-P
MI GUI
OMC-P
MI GUI
OMC-P
MI GUI
CM
OMC-P
Prov. GUI
OMC-P
Prov. GUI
OMC-P
Prov. GUI
Subscriber data
OMC-P
PM
OMC-P
MI GUI
OMC-P
MI GUI
OMC-P
MI GUI
328
Performing OAM&P
Knowledge Check
Please answer the following question:
Which tasks are performed using the OMC-P?
(More than one answer may apply)
A.
B.
C.
D.
E.
Fault management
Configuration management
Accounting management
Performance management
Security management.
329
Performing OAM&P
Knowledge Check
Please answer the following question:
Which tasks are performed using the MI : (More than one answer may
apply)
A.
B.
C.
D.
E.
Fault management
Configuration management
Accounting management
Performance management
Security management.
330
Performing OAM&P
Module Summary
This module covered the following topics:
331
Performing OAM&P
References
For more detailed information on these subjects refer to the system documentation.
332
End of Module
Performing OAM&P
333
Customer Documentation
Customer Documentation
Module Objectives
After you have successfully completed this module you will be able to:
Match a task, description, concepts with the correct customer manual.
335
Module outline
Customer Documentation
Available Platform Documents
Available Application Documents
Digit codes of manuals
336
Customer Documentation
Available Platform manuals
337
Customer Documentation
Platform Documentation 5400 LCP
Manual Name
Alarm Dictionary
Alarm Management
Configuration Database Interface Specification and Object Descriptions
Configuration management
Hardware Corrective Maintenance
Hardware Description
Hardware Preventive Maintenance
Log Management
Observation Counters dictionary
Performance management
Security Management
Software Corrective Maintenance
Software Preventive Maintenance
System Guide
User Interface
338
Manual Number
270-702-021
270-702-020
275-900-379
270-702-014
270-702-023
270-702-012
270-702-025
270-702-018
270-702-017
270-702-016
270-702-015
270-702-022
270-702-024
270-702-011
270-702-021
Configuration Database: Give a background on the use of the XML interface on the Configuration database
provided by the 5400 LCP.
Feature Server Database: The purpose of this Information Product (IP) is to:
Describe the conceptual background of the FS5000 database XML interface
Provide attribute information such as: the names of the XML tags, a short description of the attribute ,
and the allowed values or range.
Customer Documentation
Application Manuals
Manual Number
5420 Converged Telephony Server (CTS) Application User Guide
275-900-366
5420 Converged Telephony Server (CTS) Feature Packaging
275-900-368
5420 Converged Telephony Server (CTS) Feature Server Database Interface 270-900-992
Manual Name
Specification
339
275-900-367
275-900-362
275-900-361
270-310-101
270-310-100
Configuration Database: Give a background on the use of the XML interface on the Configuration database
provided by the 5400 LCP.
Feature Server Database: The purpose of this Information Product (IP) is to:
Describe the conceptual background of the FS5000 database XML interface
Provide attribute information such as: the names of the XML tags, a short description of the attribute ,
and the allowed values or range.
Customer Documentation
HTML Version
340
The 5400 LCP library can be accessed from the Management Interface Agent (MI-Agent) using the Help
contents button.
The MI refers to the hardware platform. From the MI, for the underlying systems the documentation can be
found.
On the library the LCP manuals can be retrieved in HTML for easy viewing and pdf to view or print.
The documents are stored on the MI and accessed via the MI-Agent.
Sub pages are also available for third party manuals of the different common elements.
Important is to always start with using the LCP doc (html or pdf).
It is for un-experienced users strongly advised to only start using the referenced manuals when the LCP
manuals refer to it. This to prevent of using the wrong procedures in the referenced manuals (these are
used also for applications outside).
It is also possible the customer has his own server containing the Lucent documentation. Refer to the local
customer procedures to access the documentation.
Customer Documentation
HTML Version
Libraries
Content
From the manual set overview, select the html version of a manual. A internet browser will open with the
selected manual.
Customer Documentation
HTML On-line Search Function
All
books search
342
Search, comparable to the search from the book, here the default is to search all books. This can be changed
using the Options button. The help button shows hints and tricks to search.
Library is referring to the main documentation overview page.
Book map is referring to the content page of the IP.
Comments links to an web page on www.Lucent.com to give comments.
Glossary is referring to the Glossary of the IP.
Index is referring to the Index of the IP.
Customer Documentation
PDF Version
Libraries
343
Content
From the manual set overview, select the pfd version of a manual. Acrobat reader will open the manual.
Customer Documentation
Knowledge Check
Please answer the following question:
Name the document that describes the alarm clearance procedures:
A.
B.
C.
D.
344
Customer Documentation
OMC-P Documentation
345
To access the OMC-P documentation: Open a browser, navigate to the Lucent web page, login, click on the
Customer support button and select from the pull down menu, Documentation and downloads.
Customer Documentation
Module Summary
This lesson covered the following topics:
346
End of Module
Documentation
347
Hardware Overview
Module Objectives
After you have successfully completed this module you will be able to:
Describe Advanced Telecommunications Computing Architecture (ATCA)
List the Hardware Components that the ATCA platform is made out up of
List applications running on the ATCA platform
349
Module outline
Hardware Overview
Advanced Telecommunications
Computing Architecture (ATCA)
Applications on the ATCA
Platform
ATCA Hardware
350
Blank Page
351
Hardware Overview
352
353
Front View
354
Zone 3 Connector:
between Blade and RTM
Zone 2 Connector:
to other Blades
Zone 1 Connector:
48V DC and Shelf
Management
Mid Plane
Front
Rear
355
metallic test,
ringing generator
Hardware addressing.
Zone 2:
Keying alignment
Synch. Clocks
Update Channels
Fabric Interface
Base Interface
Zone 3
Is not defined in the ATCA platform and can be defined as needed for a Rear Transition Module (RTM).
Hardware Overview
356
357
Hardware Overview
ATCA Hardware
358
ATCA Shelfs
Heigth: 1800 mm
(2 ATCA Shelfs)
359
Cabinet dimensions:
Width : 485 mm (19)
Depth : 600 mm
Heigth: 2100 mm
(3 ATCA Shelfs)
Configurations will support one, two or three shelves per cabinet depending on capacity needed.
The cabinet on the slide is a single ALU Common Look & Feel cabinet.
The Power and Distribution Unit is at the top of the cabinet, providing reduntant -48V power and alarms.
14 slot rack-mount
Shelf Management
Card slots
360
Shelf
Dimensions
Width:
19 = 485 mm
He
The shelf holds the circuit boards and consists of:
Guide Rails
ESD discharge clips
alignment/keying
handle interface
face plate mounting hardware
EMC gasketing
mid-plane
The shelf construction materials and design details are not defined by PICMG 3.0, only the front board and shelf
dimensions are defined.
Mid-plane
The number of front board accommodated by the mid-plane is 14 for the Alcatel-Lucent shelf.
The mid-plane has mounting holes for a mid-plane support bar and mounting holes for an alignment/keying mechanism
that is located above the Zone 2 connectors.
The mid-plane distributes power, metallic test bus, ring generator bus, and low-level Shelf Management signals through
the Zone 1 connectors.
All Rights Reserved Alcatel-Lucent 2007
<COURSEPARTNUMBER>
Edition
<COURSEEDITION>
The Base Interface, Fabric Interface, Update
Channel Interface,
and
Synchronization Clock Interface signals are
Page 360
distributed through the Zone 2 connector.
First 2 diskful
processor/
application cards
(nodes)
Always in first 2
slots
Dual Shelf
Management
Cards
The diskfull blades are used for functions that require storage space, MI, CNFG, CDR, FSDB and FLR
The diskless blades are used for function that do not require storage, IMS FS5000, CS, SS7, H.248 and SB
Card position guidelines:
Due to the fact that the mid-plane has a dual star configuration, two slot positions have to be made dedicated.
The slot positions 7 and 8 are dedicated for the switch cards.
All other position can be filled as desired.
Each slot position can maximal dissipate 200 Watt.
Good practice is that diskfull blades are place at slot position 1 and 2, diskless blades in the remaining slot positions.
For a good air flow and cooling, empty slot position must be closed with a filler (NBFILL), at the rear side at an empty RTM
positions also a filler has to be inserted (NAFILL).
processor
Actual
Hardware
6 1000Base T Ethernet
links
362
HDD, USB
IDE flash
TFTP
Diskless:
OAM
5450
ISC
5450
IRC
5420
CTS
Server
Management Interface
Configuration Server
Feature
Server Database
iAGCF
iHSS
iCCF
363
The diskfull blades are used for functions that require storage space, MI, CNFG, CDR, FSDB and FLR
The diskless blades are used for function that do not require storage, IMS FS5000, CS, SS7, H.248 and SB
AMC types:
Hard
disk:
73 GB
147 GB
Interface:
364
There is a range of AMC cards, at the moment Alcatel-Lucent only uses the disk and Interface cards.
The AMC cards are used in fixed configuration and are not field replaceable.
AMC types
Hard disk:
73 GB
147 GB
4 1000Base T Ethernet
links
Debug USB port
Debug Fast Ethernet port
365
multi-shelf configurations)
1x 10GE interface connected to the Fabric Interface on front panel (for daisy-chaining between switches in
multi-shelf configurations)
1x 10/100/1000Base-T interface connected to the on-board CPU.
Active/Standby
366
Power OK
Debug Fast Ethernet port
Hot Swap
Fuses
Circuit breakers
Power Bus A
Circuit Breakers
Power Bus B
7 LED
Alarm panel
367
CTS
Management Interface
ISC
iAGCF
368
369
Hardware Overview
Module Summary
This lesson covered the following topics:
370
End of Module
Hardware Overview
371
Charging
Module Objectives
After you have successfully completed this module you will be able to:
Describe the role of the internal Charging Collection Function (iCCF)
Describe the role of the integrated Charge Rate function (iCRF) for the
purpose of the metering service (5060 ICS only)
373
Module Outline
Charging
iCCF (5060 ICS only)
ACR Buffering Function (5060
ICS only)
Metering Service (5060 ICS only)
374
Blank Page
375
Charging
iCCF
376
Charging - iCCF
Functions
The internal CCF performs the
following functions:
Collects
Correlates
Generates
Stores
Transfers
center.
377
Charging - iCCF
Charging Collection
The iCCF only collects ACR
messages from the 5420 CTS.
378
Interface to iCCF
- The Rf interface between the IMS nodes and the CCF using the base Diameter transport protocol. Or, to be
more specific: similar to Cx, Rf uses an intermediate process (rfAppl) for these
connections. The NGSS cards have TCP connections to the rfAppl process, which
has Rf/Diameter (on top of TCP) connections to the iCCF.
Additional info
ACR = ACcounting Request
IMPORTANT!
In the 3GPP specs the MGCF also sends charging information to the CCF.
However the MGCF does not send charging information to the iCCF. Instead, the MGCF transfers its records
directly to the billing center.
More detail about where the files reside, how long theyre kept, etc. will be a subject in the OAM&P course
and can be found in the documentation.
Charging - iCCF
Example of Charging Collection
For each SIP dialog, the 5420 CTS is
triggered to collect accounting data at
particular events (for example, the initial
INVITE message)
The accounting data is sent in an ACR
message over the Diameter Rf interface to
the iCCF
379
Additional info
Correlation of ACR messages:
Upon receiving the ACR [START] message, the CDR Correlator will start collecting billing data for a new CDR.
It will create a CDR information structure for this particular SIP dialog based upon the session ID in the Rf
Diameter header.
If an ACR [INTERIM] message is received with a matching ID, its information will be added to or
used to update the existing CDR information.
If the message was sent to the iCCF due to a change in media (session modification procedure), a partial CDR
will be generated with the new data and the original CDR info will be sent to the formatter. This is true for
any interim message.
When an ACR [STOP] message with a matching ID is received, the CDR-Info correlation will be
Completed and the CDR-Info structure is moved to the CDR formatter to create the ASN.1 format.
If an ACR [EVENT] message is received, a new CDR is generated, and the CDR info structure is directly moved
to the CDR formatter.
Because the ACR [EVENT] does not contain session-related data, no correlation is done.
The ICID (IMS charging identifier) is used by the billing center to correlate CDRs from different sources.
Charging - iCCF
Interface to Billing Center
The iCCF can communicate with an
external billing center using the:
Bi Interface
For CDR log file transfer to Billing
Center
GDI
For CDR log file transfer to BTS.
380
There are two scenarios to transfer the CDR records to a billing center.
1. If Bellcore AMA format (BAF) is NOT required by the operator: The records can be pulled or pushed by the
Blank Page
381
Charging
382
Charging - ABF
ACR Buffering Function
5420 CTS supports an ACR Buffering Function (ABF).
ACR messages are stored on the 5400 LCP when all of the CCFs are down or too
busy:
An additional backup diameter interface is supported to send ACRs to a designated
local CCF blade when the primary/secondary diameter connections are not available.
This avoids overflow of the ACR buffer of the CTS Rf client and this way
prevents loss of billing information
Designated Diameter ABF interface supports 3GPP Version 5 and Version 7 ACR
messages.
383
When the 5420 CTS is not able to deliver the ACR messages (e.g. diameter too busy, CDF is down, etc.) and
the CTS ACR message buffer is 90% full, the 5420 CTS ACR messages will be stored on disk files. Only the
ACR files for the CTS are shown, although all the network elements must support the ACR file storage *. The
disk files will be retrieved by a CDF (or any other element used by the service provider) using the SFTP PULL
protocol. The basic platform supported SFTP will be used to retrieve the ACR files, and there is no any new
requirement for this feature to enhance the SFTP protocol. If the client initiates a FTP PULL instead of SFTP
PULL, the iCCF will not reject the request. It is expected that a new IeCCF or network element different
from the current primary and secondary CCF will be used to retrieve the ACR files.
Although the ABF should support both IPv4 and IPv6 ideally, initially, only the external IPv6 will be supported
and tested for the Rf diameter interface and IPV4 will be supported for the SFTP PULL. To support IPV6
SFTP PULL, new development is required by the LCP platform.
Note that local CCF is also referred to as the CCF Lite and in the 5060 ICS it is called internal CCF (iCCF).
Charging - ABF
Architecture
Prim
f
CR/R
ary A
IeCCF
CGF
CDF
IeCCF
CGF
5420 CTS
Sec
LCP Complex
ACR
/
Rf
BMD
ABFACR Rf
ABF
Receiver
(iCCF)
384
ond
ary
SFTP Pull
ACR Files
BMD
Currently, each IMS node (e.g. CTS) will be provisioned with two connections (Primary and Secondary). The
new feature 12517.17 will add a third connection (ABF interface as backup). If the primary connection is
down, the secondary will be used to deliver the ACR messages. If both primary and secondary connections
are not able to handle the traffic and the memory is reaching threshold, the ACR messages will be sent to
the ABF connection. The feature 12517.17 will check the criteria to determine whether ACR messages
should be sent to the ABF Rf connection. The relationship between the CTS and ABF is configurable (e.g. N
to M).
The basic platform supported SFTP will be used to retrieve the ACR files
Blank Page
385
Charging
Metering Service
386
In the 5060 ICS Solution, the Converged Telephony Server (5420 CTS) can
provide charge rate information that pertains to a particular call for the
purpose of metering service.
387
The integrated Charge Rate Function (iCRF) determines the charge rate at the
request of a CTS.
The charge rate information that the iCRF returns to the requesting CTS
generally consists of the charge rate associated with:
The setup of the call
The duration of the call (units per time interval).
388
The iCRF is implemented as a function call of CTS. The iCRF receives the following parameters from CTS:
Calling party address
Called party address (including carrier id code)
Indication of whether this is an initial request associated with the call or a request update.
Call Type
The iCRF uses these parameters and provisioned configuration data stored locally in CTS memory to determine
the appropriate charging rate, and then populates the charging rate-related parameters that are returned in
the response to the CTS request for charge rate information.
The interface between the CTS and the iCRF is an internal (non-signaling based) interface that is used to
obtain charge-related information from the iCRF for a given call
5450 ISC
389
iCRF
5420 CTS
Serving
CSCF
2
Internal
AGCF
Proxy
CSCF
AGW
VGW
3
Payphones
Interface requirements:
P1 interface (H.248-based interface between iAGCF and AGW), must support H.248.26 (automatic metering
047 TISPAN AoC and ETSI TS 183 043 TISPAN PES for supporting charge rate related information.
The CTS uses an internal (non-signaling based) interface to obtain charge-related information from the iCRF
5420 CTS
iCRF
Next hop
180 Ringing
ACK
When timer expires, CTS sends
another request to the iCRF.
iCRF function call
Charge rate in CCA return parameter
INFO (metering-XML)
390
Content-Length: 500
Content-Type: application/metering+xml; version=v2.1.3;
Content-Disposition: render; handling=optional;
Metering XML body
If there is already other content body, the CTS will generate a multipart/mixed MIME body containing two
sub-parts:
Content-Length: 436
Content-Type: multipart/mixed; boundary=unique-boundary-1
MIME-Version: 1.0
--unique-boundary-1
Content-Type: application/SDP; charset=ISO-10646
SDP body
--unique-boundary-1
Content-Type: application/vnd.etsi.aoc+xml; version=v2.4.0;
Content-Disposition: render; handling=optional
Metering XML body
--unique-boundary-1
391
Charging
Module Summary
This module covered the following topics:
iCCF
iCRF and metering service
392
End of Module
Charging
393
A
AAA
AB
ACB
ACC
ACG
ACR
AKA
ALCP
ALMRS
ALNC
ALNG
ALSM
AMADNS
AR
AS
ASDA
ATCA
ATA
AUTN
AVP
AXAS
B
B2BUA
BAF
BER
BER
BGCF
BMD
BS
BTS
C
CCF
CDR
CDR
CD-ROM
CF
CFB
CFNA
CFNR
CFV
CH
CK
CK
CLF
395
CLI
CLIP
CLIR
CLIRO
CMM
CNFG
CNIP
CNIR
CPI
cPSB
CPU
CS
CSCF
CT
CWT
D
DB
DN
DNS
DS
DTAS
DVD
DataBase
Directory Number
Domain Name System
Device Server
Device Telephony Application Server
Digital Versatile Disk
E
E-CSCF
ESC
ESGW
ESP
ESP
ESRN
F
FCAPS
FLIP
FQDN
FRU
FS
FS 5000
FTP
G
GB
GDI
GROW
GSM
GUI
GUL
GigaByte
Generating system to Data server Interface
GROWth state
Global System for Mobile communications
Graphical User Interface
Generic URI Label
I
iAGCF
iCCF
iHSS
IAD
IAM
ICID
I-CSCF
IK
IM
IM
IMPI
IMS
IMSI
IP
IPDC
IPMB
IPMI
IPSec
IRS
ISC
ISDN
ISIM
IWF
J
K
L
LAG
LAG
LCML
LM
LMT
LRF
LSS
M
MAA
MAP
MAR
MB
MGCF
MGCP
MGW
MI
Multimedia-Authentication-Answer
Mobile Application Part
Multimedia-Authentication-Request
MegaByte
Media Gateway Control Function
Media Gateway Control Protocol
Media GateWay
Management Interface
396
MMPI
MRFC
MRFP
MSRP
MTP
N
NANPA
NAPTR
NASS
NE
NEL
NENA
NID
NGSS
NML
NMS
NSS
NTP
NTP
O
OAM&P
OLC
OMC-CN
OMC-P
OOS
OPER
OSA
OSS
P
PANI
PBX
PC
PC
PCI
PCM
P-CSCF
PDF
PICMG
PLMN
pMGW
P-NAPTR
PPA
PPR
PS
PSAP
PSI
PSTN
PUID
P-Access-Network-Info
Private Branch eXchange
Point Code
Personal Computer
Peripheral Component Interconnect
Pulse Code Modulation
Proxy Call Session Control Function
Policy Decision Function
PCI Industrial Computer Manufacturers Group
Public Land Mobile Network
PSTN Media Gateway
Pseudo-Naming Authority Pointer
Push-Profile-Answer
Push-Profile-Request
Presence Server
Public Safety Answering Point
Public Service Identity
Public Switched Telephone Network
Public User IDentity
Quality of Service
R
RAM
RAND
RAS
RCC
REL
REM
RES
RPC
RPC
RRQ
RTA
RTP
RTR
S
S/BC
SA
SAA
SAC
SAC
SAR
SB
SCIM
SCP
S-CSCF
S-DHLR
SDP
SigComp
SIM
SIP
SM
SMC
SMDI
SNE
SNEL
SNMP
SPT
SS7
SSDAM
SSP
SSP
SSP
STAS
STM
SubDB
397
T
TAS
TCP
TDM
TISPAN
TMN
TS
TS
U
UA
UDP
UE
uMGW
UMTS
UNEQ
URI
URN
USIM
UTC
UMTS
User Agent
User Datagram Protocol
User Equipment
UTRAN Media Gateway
Universal Mobile Telecommunications System
UNEQuipped
Uniform Resource Identifier
Uniform Resource Name
UMTS Subscriber Identity Module
Universal Time Coordinated
UTRAN
Terrestrial Radio Access Network
V
VC
VC
VM
VMS
VoIP
VPC
Virtual Cluster
Video Conferencing
Virtual Machine
Voice Mail System
Voice over Internet Protocol
Voip Positioning Center
W
WiFi
Wireless Fidelity
X
XML
XRES
Y
Z
Blank Page
398