TIM15001 R2.0 VU TEN I1 Student Guide

Do not delete this graphic elements in here:
5060 IP Call Server (ICS)

Overview
Release 2.0
TIM15001
Issue 1
May 2010
STUDENT GUIDE
All Rights Reserved Alcatel-Lucent 2010
All rights reserved Alcatel-Lucent 2008

Passing on and copying of this document, use and communication of its contents
not permitted without written authorization from Alcatel-Lucent

<COURSEPARTNUMBER> Edition <COURSEEDITION>
Page 1
Technical Support
Technical support hotline
If you have technical questions about running the course,
contact our Technical Support Hotline for help.
Call (800) 438 7911 (within the U.S.A.)

Call +1 (630) 713 5000 (outside the U.S.A.)
Fax +1 (630) 224 3300
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:
The type of equipment on which you are running the courseware

The course number and issue
The specific error messages that you have observed
Any specific conditions that existed at the time the error message occurred.
If all technical support personnel are busy, please leave a message and your call will be
returned by the next business day.
5060 ICS 2.0 Overview

TIM15001

Page 2
Terms of Use and Legal Notices

1. Safety Warning
Both lethal and dangerous voltages may be present within the products used herein. The user is strongly
advised not to wear conductive jewelry while working on the products. Always observe all safety
precautions and do not work on the equipment alone.
The equipment used during this course may be electrostatic sensitive. Please observe correct anti-static
precautions.
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.

TIM15001

Page 3
Terms of Use and Legal Notices [cont.]

3. Copyright
This document contains information that is proprietary to Alcatel-Lucent and may be used for training
purposes only. No other use or transmission of all or any part of this document is permitted without
Alcatel-Lucents written permission, and must include all copyright and other proprietary notices. No
other use or transmission of all or any part of its contents may be used, copied, disclosed or conveyed to
any party in any manner whatsoever without prior written permission from Alcatel-Lucent.
Use or transmission of all or any part of this document in violation of any applicable legislation is hereby
expressly prohibited.
User obtains no rights in the information or in any product, process, technology or trademark which it
includes or describes, and is expressly prohibited from modifying the information or creating derivative
works without the express written consent of Alcatel-Lucent.
All rights reserved Alcatel-Lucent 2008, 2009

TIM15001

Page 4

4. Disclaimer
In no event will Alcatel-Lucent be liable for any direct, indirect, special, incidental or consequential
damages, including lost profits, lost business or lost data, resulting from the use of or reliance upon the
information, whether or not Alcatel-Lucent has been advised of the possibility of such damages.
Mention of non-Alcatel-Lucent products or services is for information purposes only and constitutes
neither an endorsement, nor a recommendation.
This course is intended to train the student about the overall look, feel, and use of Alcatel-Lucent
products. The information contained herein is representational only. In the interest of file size, simplicity,
and compatibility and, in some cases, due to contractual limitations, certain compromises have been
made and therefore some features are not entirely accurate.
Please refer to technical practices supplied by Alcatel-Lucent for current information concerning AlcatelLucent equipment and its operation, or contact your nearest Alcatel-Lucent representative for more
information.
The Alcatel-Lucent products described or used herein are presented for demonstration and training
purposes only. Alcatel-Lucent disclaims any warranties in connection with the products as used and
described in the courses or the related documentation, whether express, implied, or statutory. AlcatelLucent specifically disclaims all implied warranties, including warranties of merchantability, noninfringement and fitness for a particular purpose, or arising from a course of dealing, usage or trade
practice.
Alcatel-Lucent is not responsible for any failures caused by: server errors, misdirected or redirected
transmissions, failed internet connections, interruptions, any computer virus or any other technical
defect, whether human or technical in nature
5

TIM15001

Page 5

5. Governing Law
The products, documentation and information contained herein, as well as these Terms of Use and Legal
Notices are governed by the laws of France, excluding its conflict of law rules. If any provision of these
Terms of Use and Legal Notices, or the application thereof to any person or circumstances, is held invalid
for any reason, unenforceable including, but not limited to, the warranty disclaimers and liability
limitations, then such provision shall be deemed superseded by a valid, enforceable provision that
matches, as closely as possible, the original provision, and the other provisions of these Terms of Use and
Legal Notices shall remain in full force and effect.

TIM15001

Page 6
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)

TIM15001

Page 7
About this Course

5060 IP Call Server (ICS) Overview
This course provides an overview of the 5060 ICS,
which comprises the 5450 IP Session Control/IP
Resource Control (ISC/IRC), 5420 Converged
Telephony Server (CTS) with additional internal
applications that all run on the 5400 LCP
platform.
The intended audience for this course are
customer and Alcatel-Lucent personnel who
require a basic understanding of the 5060 ICS.
The course duration is 1 day.
Release information
Application
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

TIM15001

Page 8
Student Polling
Brief introduction of the participants :
Company?
Job responsibilities?
Experience?

TIM15001

Page 9
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

TIM15001

Page 10
Prerequisite Information
Participants are expected to have basic knowledge of:
Telecom principles
Data communication
IMS concepts
11

TIM15001

Page 11
Blank Page
This page is intentionally left blank
12

TIM15001

Page 12
Applications overview

Page 13
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

TIM15001

Page 14
Module Outline
Applications Overview
Introduction
5060 ICS
5450 ISC
5420 CTS
iHSS
iAGCF
15

TIM15001

Page 15
Blank Page
16

TIM15001
Instructor directive:
Additional information:

Page 16
Introduction
17

TIM15001

Page 17
Applications Overview Introduction

Memory Quiz
18

TIM15001

Page 18

Memory Quiz
19

TIM15001

Page 19

Alcatel-Lucent Applications
5420 Converged
Telephony Server
5450 IP Session
Controller
5450 IP Resource
Controller
20

TIM15001

Page 20

Alcatel-Lucent Applications
5060 IP Call Server
21

TIM15001
This slide shows the application that are included in the 5060 IP Call Server.

Page 21

IMS Model Solution Level
A solution is a selection of platforms and applications.
Attention:
Application = Software that performs one or more functions.
Applications are needed:
On the media and endpoint layer

On the session layer
On the application layer!
22

TIM15001

Page 22

Scenarios
1.
2.
3.
4.
Registration
Session IMS Origination
Session IMS Termination
Session IMS to PSTN
23

TIM15001

Page 23

Registration
1. The UE sends a registration message to
the proxy CSCF.
2. The proxy CSCF requests the IP address
of the interrogating CSCF from the DNS.
6
3. The registration message is forwarded

to the interrogating CSCF.
4. The interrogating CSCF requests the

serving CSCF address from the HSS
5
5. The registration message is forwarded

to the serving CSCF.
6. The serving CSCF gets the subscriber
profile from the HSS, with the
application servers for this subscriber.
3
2
7. Optionally, the application servers get

an indication that the subscriber is
registered.
24

TIM15001

Page 24

Scenario: IMS Origination
1. The UE sends the request to set up a

session to the Proxy CSCF.
2. The Proxy CSCF forwards this request to
the Serving CSCF.
3. The request is routed to the application
servers found in the subscribers profile.
3
4
4. The Serving CSCF requests from the DNS

the address of the Interrogating CSCF of
the terminating party (ENUM
functionality).
After that, the request is forwarded to
the Interrogating CSCF or the Breakout
Gateway Control Function.
25

TIM15001

Page 25

Scenario: IMS Termination
1. The interrogating CSCF gets the
request to set up a session.
2. The interrogating CSCF gets the
address of the serving CSCF from
the HSS.
2
1
3
3. The request is forwarded to the

serving CSCF.
4. The request is routed to the

application servers found in the
subscribers profile.
proxy CSCF.
terminating UE.
Bearer traffic (RTP)

Originator
26

TIM15001

Page 26

Scenario: IMS to PSTN Subscriber
1-3. Identical to the IMS-to-IMS scenario

4.
Serving CSCF requests the address of

the Interrogating CSCF from the DNS
(ENUM functionality). The terminating
subscriber is not an IMS subscriber, so
the DNS does not have an address.
5.
The request is forwarded to the

Breakout Gateway Control Function.
6.
The BGCF routes the call to a media

gateway controller. From there, the
call is set up to the PSTN.
3
4
5
6
Media gateway
Control
1
27
Media gateway

TIM15001

Page 27
PSTN

Scenario: IMS to IMS Subscriber in Different Networks (1)
3
6
9
7
5
5
10
11
28

TIM15001

Page 28

This call flow decision takes place in
the S-CSCF.
29

TIM15001

Page 29

1-4. Identical to the IMS-to-IMS scenario
5.When the S-CSCF-1 does not find additional filter criteria, the S-CSCF-1 performs a
DNS/ENUM lookup to determine the I-CSCF-2. If the I-CSCF-2 is not within the home IMS
network, the S-CSCF-1 verifies if the destination I-CSCF-2 is provisioned in the internetworked domain list:
If the destination I-CSCF-2 is in a domain outside the inter-networked domain, the SCSCF-1 forwards the INVITE to the I-CSCF-2 via an IBCF to perform NAPT, topology
hiding and firewall functions.
If the destination I-CSCF-2 is within the inter-networked domain, the S-CSCF-1
forwards the INVITE directly to the I-CSCF-2 located in the destination network.
6.The I-CSCF-2 sends a query to the HSS to find out the S-CSCF-2 of the terminating
subscriber. The HSS responds with the address of the current S-CSCF-2 for the terminating
subscriber.
7.The I-CSCF-2 forwards the INVITE to the S-CSCF-2.
8.The S-CSCF-2 validates the service profile for the subscriber (for example the SDP Media
Subscription profile) and evaluates the initial filter criteria. In this example the S-CSCF-1
determines that AS-2 must be contacted.
9.The rest of the call scenarios steps are identical to the IMS-to-IMS scenario.
30

TIM15001

Page 30

5450 IP Session Control
5450 ISC:
Handles session signaling

The components are:
Proxy CSCF
Interrogating CSCF
Serving CSCF
Breakout Gateway Control Function
Policy Decision Functional Entity (PDFE)
Interconnection Border Control
Function (IBCF)
31

TIM15001

Page 31

5420 Converged Telephony Server
The 5420 CTS is a Telephony
Application Server (TAS) that
provides:
Supplementary services
Digit Manipulation
32

TIM15001

Page 32

Internal Home Subscriber Server
iHSS :
HSS integrated on the same

hardware platform
Stores profiles with filter criteria for
subscriber
Can be co-located with an
integrated Subscription Location
Function (iSLF)
iHSS
5060 ICS only
33

TIM15001

Page 33

Internal Charging Collection Function
CDRs
iCCF:
CCF integrated on the same

hardware platform
Creates Call Detail Records based on
charging messages from the other
elements.
iCCF
5060 ICS only
34

TIM15001

Page 34
Charging
Messages
CCF

Domain Name Server
Domain Name Server:
The LCP has an internal DNS, to

translate name into IP addresses.
Media gateway
Control
Media gateway
35

TIM15001

Page 35
PSTN

User Data
User data is stored on:
The LCP
5420 CTS TAS database
The HSS
The Web portal (5420 Personal
Communication Manager - PCM)
The voicemail system
36

TIM15001

Page 36
5060 ICS
37

TIM15001

Page 37
Applications Overview - 5060 ICS

What is the 5060 IP Call Server?
The
5060 IP Call Server (ICS) is

introduced to address markets that
need smaller scale and less complex
solutions.
The
5060 ICS integrates core IMS

functions for call-processing and a
Media Gateway Control Function
(MGCF for PSTN interoperating
capabilities.
It
uses common software and

hardware assets, combined in an
integrated architecture to simplify
the solution.
38

TIM15001
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.

Page 38

Architecture
The 5060 ICS consists of:
ICS-SIP
ICS - SIP
shelf, which hosts:
5450 IP Session Control (ISC)

Internal Home Subscriber Server (iHSS)
with integrated Subscription Locator
Function (iSLF)
(iCCF)
5450 IP Resource Control (IRC)
(CTS)
Internal Access Gateway Control
Function (iAGCF)
ISC
CTS
iHSS/iSLF
IRC
iCCF
iAGCF
ATCA
MGCF
shelf, which provide PSTN

interoperating functions.
39

TIM15001
ATCA = Advanced Telecommunications Computing Architecture

The applications that are hosted by the ICS-SIP shelf are the actual topics of this training course and will be
described and explained in the remainder, together with hardware architecture (ATCA) description and an
introduction to OAM&P facilities and management systems.
Note that the ICS Solution comprises the 5060 ICS (SIP shelf plus MGC-X), plus 5420 PCM, plus 5900 MRF,
plus 1310 OMC-P.

Page 39

MGCF Deployment
Depending
on customer needs, the

ICS-SIP shelf can be used in
conjunction with:
MGCF
5020 MGC-8 (proprietary hardware)

5060 MGC-10 (ATCA hardware
5020 MGC-12 (cTCA hardware)
IN
MGC-8
All
the MGC products provide PSTN

interoperating functions for ICSbased solutions:
(MGCF) for controlling media
gateways and interfacing to ISC-SIP
shelf
Office-based Intelligent Network (IN)
services (toll-free calls, local number
portability, and calling name display)
ICS-MGC-10
MGCF
IN
MGCF
IN
ATCA
MGC-12
40

TIM15001
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
(MGW). M2UA is used between the MG and the MGCF.

3. Integrated SG: The SG function (MTP2/3 as well as E1 signaling interface) is integrated with the MGCF shelf
in 5060 ICS.

Page 40

5450 IP Session Control and 5450 IP Resource Control Functions
The 5450 ISC provides the call-processing functions in the IMS session
control layer:
Proxy Call Session Control Function (P-CSCF)
Interrogating CSCF (I-CSCF)
Serving CSCF (S-CSCF)
Emergency CSCF Interrogating CSCF (E-CSCF)
Breakout Gateway Control Function (BGCF)
Interconnection Border Control Function (IBCF)
The 5450 IRC provides the resource management functions in the IMS
session control layer (Policy Decision Function):
Service-based Policy Decision Function (SPDF)
41

TIM15001

Page 41

5420 Converged Telephony Server Functions
The 5420 CTS provides:
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:
Residential supplementary services

Business supplementary services
Regulatory services
Wireless services
Network services
Administrative services
Billing services
Web portal services (optional)
42

TIM15001

Page 42

Internal CCF Functions
The internal CCF:
Provides local CCF capabilities on the ICS-SIP shelf
Builds the CDRs associated with the ICS-SIP shelf (CTS records only)
Supports ASN.1 records and the Bx interface consistent with 3GPP TS

32.225
Supports Q.825 format
43

TIM15001

Page 43

Internal HSS Functions
Specifically designed for the 5060 ICS
IMS compliant; however implements a subset of an external HSS (such as 1440

USDS or 8650 SDM), including:
Identity
Service profile
Location at inter-system level
Subscriber data provisioning through the OMC-P
Supports integrated Subscription Locator Function:

Facilitates larger ICS configurations with a large number of subscribers distributed
among multiple iHSSs
iHSS/iSLF configuration through the OMC-P
Supports Diameter Cx/Dx inteface and Sh interface
44

TIM15001
Sh interface for Service Broker.

The long term benefit of iSLF 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.

Page 44

Integrated SLF Properties
Subscriber data retrieval from the HSS:

If the data is present locally, the iHSS sends normal Cx responses containing that data.
Otherwise, the iHSS will look up the HSS destination data in SLF-specific tables; if
SLF data is found, the iHSS/iSLF will send a Dx redirect response, providing the data
needed by the Cx client to redirect the original request to the appropriate HSS.
An SLF Group comprises of a unique set of subscribers supported by a given

instance of an iSLF database
An SLF Group consists of:

Up to three geographic redundant ICS-SIP shelf pairs (up to six shelves total)
Or up to three non-geographic redundant ICS-SIP shelves
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

TIM15001

Page 45
Applications Overview 5060 ICS

Internal Access Gateway Control Function
The internal Access Gateway Control Function (iAGCF):
Extends the reach of the IMS network to include analog terminals being
served by access gateways (AGWs):
Communicates with one or more AGWs using H.248 signaling.
Provides signaling interworking between H.248 control signaling on the

AGW side, and SIP signaling on the IMS core side.
Appears as a P-CSCF toward the IMS core network.
46

TIM15001
The AGCF is defined by TISPAN standards.

The subscriber data required by the iAGCF is integrated into the existing 5420 CTS Feature Server Database
(FSDB) on a diskfull ATCA blade.

Page 46

ICS Solutions
Solutions that incorporate the 5060 ICS are intended to address the
following:
Fixed Next Generation Networks (NGN), which offers Class 5 PSTN

Emulation Subsystem (PES):
5420 CTS provides telephony services equivalent to existing services
iAGCF supports H.248-based network access gateways for legacy endpoints
(AGW terminating POTS lines; that is, no changes to CPE).
Transformation to IP, which offers end-to-end IP and SIP solution:

Application servers provide premium VoIP services (including end user selfcare web portal)
Broadband access network supports IP access for SIP CPE
Concurrent deployment of both solutions
47

TIM15001
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 Peer via IBCF and 7510
PSTN via MGCF / MGW
Switch also provides a Class 4 capability
IP-PBX trunking
Wholesale transit

Page 47

Fixed NGN Solution
5060 ICS
ICS Solution
5060 ICS
Application
Layer
ICS Reference Architecture
Operations and
Maintenance Center
5100 CMS/5105 VMX
5060 ICS SIP Shelf

iHSS/
iHSS/
iSLF
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

TIM15001

Page 48

Transformation to IP Solution
5060 ICS
ICS Solution
ICS Reference Architecture
5060 ICS
Application
Layer
Operations and
Maintenance Center
5420 PCM
5400 IAS
Web Portal
Presence,XDMS,MIM
5060 ICS SIP Shelf

iHSS/
iHSS/
iSLF
iCCF
5420 CTS
OMCOMC-P
5100 CMS/5105 VMX
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

TIM15001

Page 49
SIP LAG
H.248 LAG

ICS Solution Network Elements
Depending on the solution, the 5060 ICS can interoperate with any of the
following:
Media Gateway (MGW)/Signaling Gateway (SG):
7510/7515/7520 MGW
Interconnect Border Gateway Function (I-BGF) (Class 4 support)

7510 MGW
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

TIM15001

Page 50

ICS Solution Network Elements (Continued)
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)
Network Management System;

1310 OMC-P
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

TIM15001

Page 51

ICS Geographic Redundancy
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.
Both ICS systems serve active subscribers:

A subscriber is assigned to one blade in each ICS system.
The blade assigned in one ICS system will be the active blade and the blade assigned in
the other ICS system will be the protection blade.
A blade within an ICS system can serve as the active blade for some subscribers and
protection blade for other subscribers.
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

TIM15001

Page 52

ICS Geographic Redundancy Scheme
Provisioning
OMC -P
OAM
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
SIP Phone / Soft Phone

Access Node
H.248 AGW
AG
POTS Phones
53

TIM15001

Page 53
SS7
MGCF
PSTN

ICS Geographic Redundancy Recovery Considerations
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

TIM15001

Page 54
5450 ISC
55

TIM15001
For more information about the 5450 ISC, refer to:
The 5400 LCP Technical Description manuals
3GPP 23.218: IP Multimedia (IM) session handling; IM call model; Stage 2
3GPP 23.228: IP Multimedia Subsystem (IMS); Stage 2
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

Page 55
Applications Overview - 5450 ISC

5450 ISC in the IMS Architecture
The 5450 IP Session Control (ISC)
supports:
IMS core functional elements:
S-CSCF
I-CSCF
P-CSCF
BGCF
Additional functional elements:

Access Gateway Control Function
(AGCF)
Emergency CSCF (E-CSCF)
Interconnection Border Control
Function (IBCF)
56

TIM15001

Page 56
5450 ISC
Proxy CSCF
57

TIM15001

Page 57

P-CSCF Properties
Hybrid operation:
Transaction stateful SIP proxy server
B2BUA
Diameter connections:
Rf interface with CCF

Gq interface with SPDF
Rx interface with 3GPP PCRF
Tx interface with 3GPP2 PCRF
e2 interface with CLF
Support for SIP message compression

Support for access security between UE and PCSCF:
Using IPsec
Authentication using IMS AKA
Encryption
Support for multiple Network Interfaces (NIs)

Support for an internal software-based SIP firewall
58

TIM15001
- P-CSCF SIP Header Reduction (provisionable)

The P-CSCF reduces message sizes sent over radio interface between UE and P-CSCF, thus improving performance and removes
information about the network that UE does not need to know, thus reducing exposure of IMS network elements to attacks. When the
P-CSCF receives subsequent messages from the UE, it will restore the affected headers appropriately before forwarding the request
within the IMS network.
Support B2BUA flavor of P-CSCF
This feature defines a B2BUA flavor of the P-CSCF, where the B2BUA functionality applies to INVITE requests and subsequent messages
sent within the dialog established from the INVITE. Standalone requests and other requests to create dialogs continue to receive SIP
proxy treatment. The reason for this is that the B2BUA flavor of P-CSCF is needed to modify SDP message bodies, which are only found
in INVITE related messaging.
P-CSCF and IBCF Support of ALG and TISPAN Gq' Diameter Interface
Gq' Diameter interface to PD-FE to support the following functions:
a) Far-End NAPT traversal and Near-End NAPT control functions
b) Policy decision functions (media authorization and gating)
c) P-CSCF Support of 3GPP Release 7 PCRF Functions
Rx Diameter interface to PD-FE to support the following functions:
a) Policy decision functions (media authorization and gating)
b) Charging correlation (including Rf interface enhancements)
P-CSCF Support of 3GPP2 PCRF Functions
Tx Diameter interface to PD-FE to support policy decision functions (media authorization and gating) as in 10919.68/91.
P-CSCF Support of TISPAN e2 Interface to CLF
TISPAN e2 interface between P-CSCF and the Connectivity session Location and repository Function (CLF) in the TISPAN access network
(Network Attachment Subsystem (NASS) framework):
1. P-CSCF querying CLF via e2 interface during registration to retrieve UE location and other information.
2. P-CSCF passes the location information retreived from CLF in P-Access-Network-Info (PANI) header to other IMS components (e.g. ECSCF) in SIP messages that are applicable to PANI header (per IETF RFC 3455).
3. P-CSCF removes the P-Access-Network-Info header from SIP messages that destinated to the UE before forwarding the SIP messages.
Note that the removal of the PANI header from the SIP messages that go to the peering network is covered by the IBCF.
P-CSCF Overload Control: Handling of a registration storm is as follows. The P-CSCF will respond to an overload of registration requests,
with a 200OK, even though the CSCFs have not successfully registered the UE. By doing this, the P-CSCF can recover from an overload
condition while the UE re-registers, then successfully register the UE request after the overload condition is corrected.
Support for 2 NIS: SIP traffic over the Gm interface (usually considered non-trusted) can be separated from the SIP traffic over the Mw
interface (between CSCFs). The two "external" IP addresses can be of two different IP subnets or of the same IP subnet.
Page 58

P-CSCF Hybrid operation
P-CSCF acts as a hybrid SIP entity:
B2BUA for INVITE dialogs:
Allows for SDP message body to be modified
Required for interaction with PD-FE (resource management)
SIP proxy for everything else
59

TIM15001

Page 59

P-CSCF - Signaling Compression
When IMS is deployed over the access
network where there is limited
bandwidth, Signaling Compression
(SigComp) is used to reduce the size
of the SIP messages.
Characteristics:
Only required for wireless UEs
Can be activated for P-CSCF
Can be activated for each
individually used access network
Support dynamic compression for
messages UE to P-CSCF and P-CSCF
to UE
Compressed
SIP messages
60

TIM15001

Page 60

P-CSCF - Multiple Network Interfaces
P-CSCF can be configured to use two Network Interfaces (NIs) for SIP
communication.
Characteristics:
Each NI is assigned an external IP address
Used to separate non-trusted SIP traffic over the Gm interface (access network)
from the SIP traffic over the Mw interface (between CSCFs).
Two NIs:
Default NI (Mw interface)
Published NI (Gm interface)
The two external IP addresses can be of two different IP subnets or of the same
IP subnet.
61

TIM15001
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.

Page 61

P-CSCF - Internal SIP Firewall
P-CSCF can be configured to use a integrated Security Gateway (iSGW), which
acts as a Signaling Firewall (SFW) in the SIP signaling path between the access
network and the P-CSCF.
Characteristics:
Applies to traffic received on the published Network Interface of SIP ports
Only accepts SIP messages (compressed and uncompressed) and Keep-Alive

messages
Drop all other messages and log the events
Rate limiting can be provisioned per SIP message (method/response).
The general purpose is:

To screen out bad/malicious traffic
To protect against attacks
More details in the Topic Access Border Architecture.
62

TIM15001
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
Anomaly detection to prevent DoS/DDoS attacks such as traffic flooding
Quarantine for the source IP address/port that is detected to be performing a DoS attack.
SIP Security
Malformed SIP message detection Inconsistent headers, DoS/DDos checks, etc.
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
Logging and Reporting for all security checks and events

IPsec security associations (SAs)
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.
Page 62

Knowledge Check
Please answer the following question.
Which of the following services are provided by the Proxy-CSCF?
(more than one answer may apply)
A.
B.
C.
D.
SIP Compression
Apply filter criteria
Store registration data
Support implicit registration.
63

TIM15001

Page 63
5450 ISC
Interrogating CSCF
64

TIM15001

Page 64

I-CSCF Properties
Transaction stateful SIP proxy server
Support of early Authentication procedures
Support of two methods for S-CSCF allocation
Support to convert SIP URI to TEL URL
Support for PSI subdomain
Support of offline session charging :
Support to accept Dx redirect-related information from an SLF rather than the

HSS response

Cx interface with HSS
Dx interface with SLF
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

TIM15001
Listed are the properties besides behavior according to the standards:

UE registration
UE termination
Transit routing
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.

Page 65

I-CSCF Assigns S-CSCF
The I-CSCF supports two methods to assign an S-CSCF.
After the I-CSCF receives a REGISTER message, the I-CSCF queries the HSS to
retrieve the user registration status; the UAA response of the HSS can include:
A
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

TIM15001
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).

Page 66

I-CSCF Support for PSI Subdomain
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

TIM15001

Page 67
5450 ISC
Serving CSCF
68

TIM15001

Page 68

S-CSCF Properties
Cx interface with HSS
Dx interface with SLF
Support of HSS-initiated update of the user profile
Support for various authentication schemes
Support to accept Dx redirect-related information from an SLF rather than the

HSS response
69

TIM15001
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.

Page 69

HSS-initiated Update of User Profile
The S-CSCF supports Diameter Cx PPR
(Push Profile Request) messages from
the HSS when the profile has changed
for a registered subscriber.
70
New profile

TIM15001
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.

Page 70

S-CSCF Registration Authentication
Types of authentication:
Hypertext Transfer Protocol (HTTP) Digest using MD5:

Digest-MD5-Password
Digest-MD5-A1
HTTP digest using AKA:

Digest-AKAv1-MD5
Early IMS Security (GPRS)
NASS-bundled
71

TIM15001
HTTP Digest-based using MD5

Digest-MD5-Password
Non 3GPP IMS compliant UE and non GPRS access
Digest-MD5-A1
HTTP digest using AKA-based
Digest-AKAv1-MD5
3GPP IMS compliant UEs
Early IMS Security (GPRS)
Non 3GPP IMS compliant UEs with GPR access
NASS-bundled
TISPAN compliant
In a wireless network in this context there are 3 types of UEs, with regard to their support of access security functions, are defined:
UE type A: Type A is Third-Generation Partnership Project (3GPP) IMS compliant. This UE supports the access security as specified in 3GPP, TS
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

Page 71

S-CSCF HTTP Digest
Is used to reduce the possibility of spoofed calls in an unsecured network
environment.
The Serving Call Session Control Function (S-CSCF) performs the access
authentication for IMS subscriber User Equipment (UE).
This is for a non-3GPP IMS compliant UEs and provides a non-GPRS access.
These UEs does not support the access security as specified in 3GPP
For this UE, HTTP digest authentication with the Message Digest 5 (MD5)
encryption algorithm will be used for authentication.
72

TIM15001
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.

Page 72

Knowledge Check
Which of the following services are provided by the Serving-CSCF?
(more than one answer may apply)
A.
B.
C.
D.
SIP Compression
Apply filter criteria
Store registration data
Support implicit registration.
73

TIM15001

Page 73
5450 ISC
74

TIM15001

Page 74

Functions of the BGCF:
Select the next hop (BGCF or MGCF),
based on digit pattern, directory
number (DN) and various other
decision criteria
Route SIP requests to the selected
next hop
Support proxy mode
Optionally query the DNS
Report charging information
4
2
5
6
Media gateway
Control
PSTN
1
75
Media gateway

TIM15001
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.
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.

Page 75

BGCF Routing Decisions
Basic routing based on:
Equal access
Calling party DN
Called party DN (default routing)
Enhanced routing based on:
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

TIM15001
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.

Page 76

BGCF Call Logic
After receiving a SIP message, the
route selection algorithm will:
1. Perform Digit Analysis (DA);
wildcards are supported
2. Based on the DA routing decision,
select a target list, which is a
prioritized list of destination URIs
from which the next hop is chosen
3. Forward the message:
Try the highest ranking URI first and

then the next one if a 3xx 6xx
response is received
In the case of equal priorities (loadsharing), use round-robin
mechanism
77

TIM15001
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
the 302 message.

2. A response in the list of Valid Release Codes (FS GUI: IMS > Parameters/Timers > BGCF release codes) will result in
termination of the call using the release code.

3. Any other response results, as the slide indicates, in selecting the next URI from the list.
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.

Page 77

Basic Routing
Basic routing order:
1. Equal access:
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

TIM15001
BGCF Enhancement for Equal Access:

For this type of routing, it is assumed that a CIC value is present in the INVITE request (either presubscribed using CIC parameter or part
of dialed digits preceded by prefix such as 101). The CIC value identifies the selected carrier. In a large IMS network, there might be
more than one MGCFs available for a particular carrier. The MGCFs might be far apart geographically to cover the different areas.
Without knowing the actual locations of the calling and called party, using both the CIC value and the calling DN give a higher
possibility for a minimum routing for the particular carrier, although this is definitely not guaranteed. The call will be routed out of the
existing network and passed to the selected carrier as soon as it is identified as a carrier call. It is desirable to use as little resource as
possible for the existing network, and pass the call to the closest MGCF of the selected carrier. The selected carrier can then determine
how to continue the routing.
In the current architecture, the calling DN is inserted in the P-Asserted- Identity header by either the P-CSCF or S-CSCF. The FS5000 is
the Application Server that determines if a CIC value should be included. If a call is an inter-LATA (Local Access and Transport Area)
or intra-LATA toll type, the CIC value is inserted (if available). Otherwise, the CIC value is not included. If a CIC is included in an
INVITE request, but the call is not able to be routed based on the CIC and the calling DN, the call will be terminated. The call will not
be routed using the non-equal access default routing that uses the called DN to route. This is because when a CIC value is included, the
caller is assuming a specific carrier is used for the call. If the provisioning was not done correctly, this error should be flagged to the
user. The call should not go through successfully with the user assuming the specified carrier was used. The BGCF will trust the CIC
value that is received and only performs the range verification. The CIC is extended for international dialing plan. Unlike the North
American Numbering Plan where there is a prefix (101) and four CIC , the international dialing plan may require different CIC lenghs
in different countries. With this feature, the BGCF allows the number of digits of the CIC as a provisionable value.
Support Selection of MGCF based on Calling Party Number:
Location based/sensitive services such as 8YY calls, N11 (311, 411, etc) call, and Operator calls (0,00) calls typically require the call
to be routed to the service center or operator that is geographically closer to the calling party (does not have to be the operator of the
calling party number's service provider), which requires the BGCF to select the MGCF based on the calling party number to ensure the
call is gone out to the appropriate MGCF. This is especially useful when the MGCFs are geographically distributed.
Routing is extended to accommodate the international market dialing plan. The majority of the pattern checks are removed. The number of
digits for the called party pattern is also extended from three to twelve digits. The calling party number can be obtained from either the
P-Asserted-ID header or From header (if the PAsserted-ID is not available and the using of From header as the calling party flag is
enabled)

Page 78

Introduction to Enhanced Routing Capabilities
Enhanced routing essentially works the same way as basic routing:
Eventually a target list is selected.
However, target list selection can also be based on information that is
provisioned in:
Additional BGCF routing tables
BGCF profiles where the enhanced routing tables are linked
BGCF office-based parameters.
Enhanced routing allows for an advanced routing scheme to determine

the sequence and the priority of the BGCF decision flow.
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

TIM15001
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.

Page 79

BGCF Proxy Mode Routing Based on Route Header
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.
This type of routing can be enabled/disabled by the operator.
80

TIM15001
BGCF Supports Route Header

When proxy mode is enabled, this is the first check in BGCF processing.
Due to the security risk of routing using the Route header, a provisionable flag is used in the BGCF profile to ensure the
operator intentionally wants to honor the Route: header.
This feature enables BGCF to route calls as a SIP proxy using the route header when it receives a request with more than
one route header.
Existing BGCF functionality is to ignore the additional route headers if the call comes in with more than one. This will be
modified, so that BGCF upon receiving more than one route header will remove the first route header (must be the one of
the BGCF itself) and use the route header after that to route the call. A flag will be added to the BGCF profile table,
which will be downloaded with the profile parameters. BGCF call-processing will check for the flag when it detects
multiple route headers and use the available header to route the call. In the routing logic, the first check will be done for
the route header before going on to other options for routing. When this feature is not selected, BGCF upon receiving
multiple route headers will route the call as per existing routing mechanism and will not reject the call as before.
In general, for proxies, the BGCF shall verify the Route header is pointing to the BGCF when there is a single Route head,
and the BGCF shall remove its own URI from the Route header.
When the BGCF receives a request that contains no Route header or a single Route header, the BGCF removes the Route
header (if present) and proceeds with the routing scheme
If proxy mode disabled, the BGCF removes the topmost Route header (if present) and proceeds with the routing scheme
(which may be using the DA table).

Page 80

BGCF Routing Based on Content-Type Header
Special treatment of SIP MESSAGE requests:

Different SIP MESSAGE requests can be routed to different destinations
according to their Content-Type header.
This capability is used to route an SMS (Short Message Service)
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

TIM15001
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).
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.

Page 81

BGCF Routing Based on Content-Type Header - Routing Message Requests
SMSC
No match
in ENUM
SMSC
SMSC
SIP MESSAGE request

may contain various types
of message.
The BGCF can route a SIP MESSAGE

request to different destinations
based on Content-Type header.
82

TIM15001
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.

Page 82

BGCF Routing Based on Location and Local Number
Besides digit strings, the BGCF can analyze certain fields in a SIP message:
The phone-context parameter (and the called DN) for local number
routing
The P-Access-Network-Info (PANI) header (or the From header if PANI

header not available) for location-based routing
The rn parameter (Routing Number) for Local Number Portability
If one of the above parameters/headers is present in a SIP message, a

special target list is selected using tables that are similar to DA Route
Tables.
83

TIM15001
Location Based Routing and Local Number Routing

The geographical location information is determined by the SIP PANI header. In the BGCF Parameters dialog box, when
the Calling Party Identity is set to P-Asserted-ID and From header (default), the calling party will be obtained from
the SIP PANI header and if the PANI header is not available the calling party will be obtained from the From header.
When set to P-Asserted-ID only, the calling party will be obtained from the SIP PANI header, if the PANI header is not
available, the call will be routed using traditional BGCF routing methods. The Called DN pattern can be 1 to 11 digits (no
specific checks), so it is flexible to be used by North American or International Numbering Plan.
The phone-context parameter (refer to RFC3966):
Any digits in a tel URI that do not begin with a + are assumed to be a locally valid but not global valid numbers. Using this
phone number outside the calling area is not permitted and would generate an error announcement, or result in a
misrouted call. Therefore, local numbers need to have the phone-context parameter, which identifies the context (owner)
of the local number and, thus, the scope of the number. This makes the number globally unique. The context can be
represented by a global number or a domain name: the former must contain a valid global number that is owned by the
local number distributor and the latter must contain a valid domain name that is under the authority of the owner
distributing the local numbers. Here are some tel URI examples:
tel: + 358-9-123-45678
A global number.
tel:45678;phone-context = example.com
A local number with a domain context.
tel:45678;phone-context= + 358-9-123
A local number with a global number context.
tel:1234;phone-context=munich.example.com
A phone number (1234) may only be used by a SIP-proxy recognizing
the phone-context (that is, the SIP server knowing what to do within the domain munich.example.com).
tel:1-800-123-4567;phone-context=+1-972
Not all tel URIs are so simple; this phone-context specifies under what
circumstances a phone number can be used and refers to an 800 number valid only for the North American numbers in the
972 calling area. The expression 1-800-123-4567 is called a dial stringsomething used by humans.

Page 83

BGCF Routing Based on Originating Host Class and Subscriber Profile
The next hop is determined by a special target list that is provisioned in

a an originating host profile or subscriber profile.
Allows for extensive digit manipulation based on subscriber data and

Local/Toll analysis.
84

TIM15001
BGCF Routing Enhancements (includes TOD routing)

This type of routing enhancement is targeted to the North American numbering plan. (It was developed initially specially for
Verizon do not mention to students). TOD routing is not customer/US speicifc.
This is an optional feature, an office parameter (in BGCF Parameters) is used to determine if the BGCF routes based on
the profiles.
The originator host class parameter (proprietary) in the request is populated by a previous node, either RTCF or DGCF.
If the host profile does not exist, the BGCF will use the subscriber profile if it exists. The subscriber profile provides
information, such as Carrier ID (CIC), Routing Prefix Digits, Routing table ID, that are used to derive the next hops. In
this release, the limit is 2000 subscriber profiles. This number of subscribers may be grown in a future release.
When the host and subscriber profiles are not found in the configuration data, BGCF perform basic routing.
Remove digits such as 011 (international direct dialed prefix), 01 (international operator assist prefix), or 101 (CIC dialing
prefix).
Add digits such as country code 1.
Add prefix/suffix for the next hop gateway.
Configuration Management and translations not yet covered in OAM&P.

Page 84

BGCF Time-Dependent Routing
Time-dependent routing allows an operator to change routing based on

a time interval:
From start day-of week/time-of-day to end day-of week/time-of-day.
Time-dependent routing can be provisioned in basic DA Route Tables:

When a TOD ID is defined, the next hop is determined by a target list that is
defined in the BGCF Time Of Day table.
Up to 32 time intervals can be defined.
The time of the call is determined by the BGCF local time.
85

TIM15001
BGCF time-dependent routing

When a TOD ID is defined, the next hop is determined by a target list that is defined in the BGCF Time Of Day table
instead of the DA Route Table.
The BGCF routing interval is

Page 85

BGCF Routing Based on SDP Media Type
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

TIM15001
BGCF support for selecting MGCF based on SDP media type

The supported media type includes: "audio", "video", "application", "data", "control", text" and "message. Video has the
highest priority, regardless its position in the m= list in the SDP body.
When this feature is turned on, it is required that at least one of the media types for each provisioned URI shall be checked
for this feature to work properly.

Page 86
Applications Overview 5450 ISC

BGCF Logical Link Status
For each destination, the BGCF may verify the status of the SIP link in
order to avoid routing to an out-of-service link. The logical link status
information is provided by the SIP Link Manager:
LCP functionality that is used by the BGCF
Responsible for heartbeating the SIP links using SIP OPTION messages
Generates alarms for out-of-service URIs/SIP links
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

TIM15001
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.
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.

Page 87
5450 ISC
Emergency CSCF
88

TIM15001

Page 88

Emergency CSCF Properties
The Emergency CSCF (E-CSCF) is a SIP
proxy server that provides IMS support
for emergency call routing of VoIP
emergency sessions.
89

TIM15001

Page 89
5450 ISC
Interconnection Border Control Function
90

TIM15001

Page 90

Network Interconnection in the IMS Architecture
The LCP supports SIP traffic routing across

inter-network boundaries through the
Interconnection Border Control Function
(IBCF), which provides:
Routing of SIP messages between one IMS

network and any designated external
networks
Topology Hiding Inter-network Gateway
(THIG)
Application Level Gateway (ALG)
Quality of Service (QoS) control
Support for roaming
Support of call gapping and code
blocking
Support for SIP message screening
Support of session charging for peering
calls: ACR [Start, Interim, Stop, Event]
91

TIM15001
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.
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.

Page 91

IBCF Routing Infrastructure
When the IMS network is configured with an IBCF, all inter-IMS SIP traffic must
enter the IMS network through an IBCF (entry point) and exit the IMS network
through an IBCF (exit point).
92

TIM15001
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.

Page 92

IBCF Entry Point
Upon receiving an initial request from an external network, the IBCF
(entry point) routes the request to the next hop in the IMS network as
follows:
1.
2.
Route the request to the I-CSCF URI

Route the request to the "Home I-CSCF URI"
93

TIM15001

Page 93

IBCF Exit Point
Requests from the IMS network that are destined to an external network
are routed as follows:
1.
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

TIM15001
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.
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.

Page 94
Blank Page
95

TIM15001

Page 95
5450 ISC
Miscellaneous Properties
96

TIM15001

Page 96

Miscellaneous Properties
Support for implicit registration

Support for registration event notification using SUBSCRIBE and NOTIFY
Support for SDP local policies (P-CSCF)/SDP Media Subscription Policies (S-CSCF)
Support for Bulk Registration
Support for IMS Inter-Networking
Support of Hexadecimal Digits in Request-URI
Support for redirection
Support User Identity to HSS resolution (contact a Subscription Locator
FunctionSLF)
97

TIM15001
CSCF Support for Bulk Registration
ICS Support for SLF
iHSS SLF for ISC in ICS
SLF with external HSS

Page 97

P-CSCF Support for Implicit Registration
Implicit Registration indicates that a single IMS user has the ability to register a
set of Public User Identities (PUIDs) using a single registration.
Deregistration works the same way.
98

TIM15001
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.

Page 98

P-CSCF Support for Implicit Registration (continued)
Implicit registration characteristics:
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

TIM15001
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:
The maximum number of PUIDs per IRS is 10.
At least one of the PUIDs in the IRS is SIP URI.
PUIDs in an IRS can have different profiles.
PUIDs in the IRS can share the same profile.
Registration/deregistration for an IRS must be done using the SIP URI
All PUIDs in an IRS must be served by the same S-CSCF.

Page 99

S-CSCF Support for Implicit Registration
Implicit registration characteristics:
The S-CSCF can register more than

one Public User ID at the same time
The S-CSCF will add an URI in the
P-Associated-URI header in the
200 OK message for each PUID that
should be registered.
100
<PrivateID>IMPI_1@homedomain.com</PrivateID>
<ServiceProfile>
<PublicIdentity>
<Identity>sip:IMPU_1@homedomain.com</Identity>
</PublicIdentity>
<PublicIdentity>
<Identity>sip:IMPU_2@homedomain.com </Identity>
</PublicIdentity>
etc.

TIM15001
The example shows an SAA message from the HSS, indicating that two IMPUs should be inserted and that they
belong to the same IRS.

Page 100

Event Notification Subscriptions
Event notification subscriptions can be
requested by:
UE
P-CSCF
AS
101
SUBSCRIBE
messages

TIM15001
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.
<?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>

Page 101

SDP Policies
SDP policies exists in two variants:

SDP local policy:
Validates the SDP body against authorized bandwidth and codecs for audio and video
media types for all sessions
Supported on both a P-CSCF or an S-CSCF
Can be enforced for a particular Offer/Answer flow
SDP media subscription policy:

Validates the SDP body against authorized bandwidth and codecs for audio and video
media types on a per subscriber basis
Supported on S-CSCF
Applied to sessions initiated by specific subscribers who have an assigned subscribed
media profile (indicated in the service profile of individual subscribers in the HSS)
The SDP media subscription has precedence over the SDP local policy.
SDP policies are always applied first before invoking the PD-FE
102

TIM15001
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.
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.
Page 102

S-CSCF Bulk Registration
Bulk registration allows an AGCF to

register, re-register, or de-register
on behalf of its associated PSTN
subscribers behind the AGWs:
Each AGW is associated with a
Permanent Registration Set (PRSET)
Upon successful registration of an
AGW (Step 6), the HSS downloads
the user profiles of all subscribers in
the PRSET (Step 5)
The S-CSCG registers all PSTN
subscribers behind the AGW as part
of the PRSET
The S-CSCF then performs the 3rdparty registration with the AS.
103
3
1
AGCF
H.248
AGW
AGW

TIM15001
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).
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.

Page 103

Support of Hexadecimal Digits in Request-URI
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
Functional elements that support hexadecimal digit strings include:
P/I/S/E-CSCF
RTCF (integrated in the I-CSCF)
DGCF
BGCF
104

TIM15001
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
support is not required in North American networks)

The DGCF has a specific table for recognizing prefixes in the Request-URI, with action specified to either
remove the prefix or reject the request.
Hexadecimal digits are used in some countries (e.g. Germany and France) as a routing prefix in number
portability scenarios, to route calls to a ported user's current serving network, or (e.g. in Germany) to
support the routing of emergency calls to its destination, based on emergency service routing numbers that
include hexadecimal digits (to prevent unauthorized dialing emergency call center numbers).
Thus, this feature is not meant to cover cases in which ICS users themselves are allowed to dial hexadecimal
digits. In particular, this feature does not impact any access elements such as the iAGCF, or the VGWs
(ISAM-V or Litespan).

Page 104

Redirection Support
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.
Applicable to response codes 301/302/305 (3xx) received for:

Any initial request to start a dialog (including INVITE, SUBSCRIBE, REFER)
Any stand alone request outside of the dialog (including MESSAGE, PUBLISH).
Typically used when the terminating network employs redirection as a load

balancing mechanism.
105

TIM15001
Redirection Support
The description of redirection support behavior is simplified. For the full routing decisions please refer to the customer
documentation (or QDI # 39680, FDS).
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.

Page 105

Redirection Support Example
I-CSCF
with consolidated RTCF
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

TIM15001

Page 106
Network-2

HSS resolution - Single HSS and Multiple HSS
5450 ISC supports two methods to store IMS subscriptions:
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

TIM15001
Single HSS supports geo-redundancy (primary and alternate).

Page 107

HSS resolution - SLF Characteristics
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).
Support to establish Diameter connections to an SLF, acting as:

Diameter redirect agent
Diameter relay agent (proxy mode)
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

TIM15001
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!

Page 108

HSS resolution - SLF/HSS Processing a Query in Distributed IMS
Co-located SLF/HSS (on the right):
1. Query to SLF.
2. SLF performs a look-up on the public
identity and determines that the
request is for the co-located HSS;
SLF forwards request to co-located
HSS.
3. Co-located HSS processes request
and returns a response.
1440 USDS
8650 SDM.
HSS not co-located (on the left):

4. Query to SLF.
5. SLF performs a look-up on the
public identity and determines that
the request is for an non co-located
HSS; SLF returns redirect response
with the address of the HSS.
6. Re-attempt query to that HSS
7. Non co-located HSS processes
request and returns a response.
1440 USDS/8650 SDM.

SLF
HSS
HSS
4
7
6
3
1
Note: 5060 ICS operates in a similar way,

but only supports integrated SLF in iHSS .
I/S-CSCF
109

TIM15001
SLF currently not supported. 5060 ICS will support an integrated SLF (iSLF) in Release 1.2.1 & Later.
TIM15001, refer to Module 6 Charging.)

Page 109

Border Functions - Heartbeat between P-CSCF and S-CSCF
The P-CSCF provides a heartbeat mechanism to keep track of the status of its
associated S-CSCFs and to take recovery action if an S-CSCF is unreachable.
The heartbeat mechanism detects connectivity between P-CSCF and S-CSCF:

May be a direct route between P-CSCF and S-CSCF
May be a route through IBCFs; for example, PCSCF IBCF1 IBCF2 S-CSCF in the
case of roamers with their P-CSCF residing in a visited network
If the S-CSCF heartbeat is enabled, a P-CSCF:

Dynamically maintains a list of target S-CSCFs for each successful UE registration.
Sends a heartbeat request (SIP OPTIONS message) to target S-CSCFs at regular intervals.
Treats a 408 Request Timeout or a 503 Service Unavailable response as a failure.
An S-CSCF is considered unreachable after N consecutive heartbeat failures.

The P-CSCF will treat this as if the S-CSCF had lost its registry (out-of-sync).
The P-CSCF, upon detection of loss of S-CSCF registry, will quickly locate the affected
UEs and take immediate recovery actions to trigger an impacted UE to re-register with
the network.
110

TIM15001
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

Page 110
5450 ISC
User Profile Revisited
111

TIM15001

Page 111

User Profile Overview
Associated with an IMS subscription.

Assigned by the network operator.
Provisioned at the HSS.
Contains at least:
One Private User Identity (PRID)
A single service profile of one or more Public User Identities (PUID)
Supports Implicit Registration Set (IRS).

Supports preference-based routing.
In 3GPP Rel-6 & later:
Multiple PRIDs per IMS subscription
Shared PUIDs
Support of forking.
112

TIM15001
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.
Page 112

Multiple PRIDs and Shared PUIDs
113

TIM15001
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.

Page 113

Shared PUIDs
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

TIM15001

Page 114

Serving-CSCF Service Profile Overview
A service profile consists of:
Zero, one, or more initial Filter Criteria (iFC):

Zero or one Trigger Point:
Boolean expressions of groups of Service Point Triggers (SPTs)
One application server to be contacted if Trigger Point is met
Zero, one, or more shared iFC (SiFC) sets:

One or more iFCs, locally administered and stored at the S-CSCF
115

TIM15001

Page 115

User Profile Information Example
An example of a user profile as stored in the S-CSCF:
Private user ID
<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

TIM15001
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.
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

Page 116

User Profile Information Example (continued)
<Priority>0</Priority>
<TriggerPoint>
<ConditionTypeCNF>0</ConditionTypeCNF>
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<Method>SUBSCRIBE</Method>
</SPT>
<SPT>
<ConditionNegated>1</ConditionNegated>
<Group>0</Group>
<SIPHeader>
<Header>From</Header>
<Content>joe</Content>
</SIPHeader>
</SPT>
</TriggerPoint>
First trigger point
AND within groups, OR

between groups
When the SIP Method
contains SUBSCRIBE
and
<Continued on next slide>
The SIP From

Header field
does not contain joe
117

TIM15001
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.

Page 117

User Profile Information Example (continues)
Then contact this AS
<ApplicationServer>
<ServerName>sip:AS1@homedomain.com</ServerName>
<DefaultHandling>0</DefaultHandling>
</ApplicationServer>
</InitialFilterCriteria>
</ServiceProfile>
</IMSSubscription>
If not successful in
contacting AS, then
continue
118

TIM15001

Page 118

Service Point Triggers
The Service Point Triggers (SPTs) define the filters that the S-CSCF checks:
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

TIM15001
"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.

Page 119

Shared iFC Set
A shared initial Filter Criteria (SiFC) set is a subset of iFCs that may be
shared by several service profiles.
How is it used?
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

TIM15001
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.
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)

Page 120
5450 ISC
iAGCF
121

TIM15001

Page 121

iAGCF - Overview
The Access Gateway Control Function (AGCF) extends the reach of the IMS
network to include analog terminals being served by Access Gateways
(AGWs).
The Access Gateway Control Function (AGCF) is defined by the TISPAN
standards.
122

TIM15001
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.

Page 122

iAGCF - Introduction
Alcatel-Lucent offers the AGCF
combined with Call and Session Control
Functions (CSCF). This AGCF is called
the internal AGCF (iAGCF).
PSTN endpoints are connected to the
IMS through Access Gateways.
Access Gateways are controlled by the
iAGCF through H.248/Megaco signaling.
H.248/Megaco
PSTN
123

TIM15001

Page 123

iAGCF - Access Gateways
An AGW located at the subscriber
residence is called a Residential
Gateway (RGW). The RGW supports
a limited number of endpoints.
The AGW located at the premises of
the network provider supports a
huge number of endpoints. An
example of is the Alcatel-Lucent
7302 ISAM-V.
ISAM-V: Intelligent Service Access

Gateway Manager with Voice
package.
PSTN
124

TIM15001

Page 124

iAGCF - AGW Initialization
When the AGW initializes it contacts
the iAGCF. After the initialization is
complete the endpoints are active
and can be used for call processing.
PSTN
125

TIM15001

Page 125

iAGCF - Functions and Redundancy
Main functions of the iAGCF:
On behalf of the AGW perform a
registration with the Serving CSCF
Call control for AGW endpoints.
Call control makes use of a
subscriber database
AGW control
The iAGCF uses redundant hardware.
The iAGCF can be combined with
other services on the same
hardware.
PSTN
126

TIM15001

Page 126

iAGCF CSCF connectivity
For the endpoints on the AGW the
iAGCF acts as a SIP User Agent (SIP UA).
5420 CTS
The iAGCF appears as a P-CSCF to the

I-CSCF and S-CSCF.
SIP UA
PSTN
127

TIM15001

Page 127

iAGCF - Subscriber Database
FSDB
The iAGCF uses a subscriber database

containing:
Private User Identity (PRID)
Public User Identity (PUID)
Data required for endpoint features
(e.g. hotline)
Endpoint identity:
5420 CTS
Gateway identity
Identity of the port on the gateway
The iAGCF database is integrated with

the Feature Server Database (FSDB).
The iAGCF has a local copy of the
iAGCF subscriber data. This data is
received from the FSDB.
PSTN
128

TIM15001
The subscriber data required by the iAGCF is integrated into the existing 5420 CTS Feature Server Database
(FSDB) on a diskfull ATCA blade.

Page 128

iAGCF - Class 5 Services
The 5420 CTS provides Class 5 services
for the iAGCF subscribers.
129
5420 CTS

TIM15001
TISPAN defines two coupling methods:

Tight Coupling: the application server provides the majority of the Class 5 services. Most of the services are
transparent to the AGCF

Loose Coupling: Next to the application server the AGCF provides part of the Class 5 services.
The current release of the iAGCF supports Tight Coupling only.

Page 129

iAGCF - Registration
The iAGCF uses bulk registration to register all endpoints of an AGW with
the IMS core.
Bulk registration is an Alcatel-Lucent proprietary method.
130

TIM15001
With Bulk Registration the iAGCF sends one SIP registration message for the entire AGW.

Page 130

iAGCF - Call Origination Scenario
1. A subscriber dials a telephone

number
2. The AGW forwards the dialed digits
to the AGCF
3. The AGCF uses the local subscriber
database to compose a SIP INVITE
message on behalf of the originating
subscriber
4. The AGCF sends the SIP INVITE to SCSCF
application server (CTS) found in
the subscriber profile for applying
originating services
6. The S-CSCF sends the SIP INVITE to
the I-CSCF of the terminating party
(or BGCF in case of TDM termination)
A bearer path (RTP stream) is setup
from the AGW.
131
5420 CTS
5
6
4
3

TIM15001
A bearer path is setup from the AGW for the RTP stream

Page 131

iAGCF - Call Termination Scenario
1. The I-CSCF receives a SIP INVITE

2. The I-CSCF retrieves the address of
the S-CSCF from the HSS
3. The request is forwarded to the SCSCF
application server (CTS) found in
the subscriber profile for applying
terminating services
AGCF
6. The AGCF consults the local
subscriber database for the AGW
and endpoint information
7. The AGCF controls the AGW for
termination of the call
A bearer path is setup to the AGW for
the RTP stream
132
5420 CTS
6
4
2
3
5
6

TIM15001

Page 132

iAGCF - Knowledge Check
Please answer the following question:
What functions are performed by the iAGCF?
(More than one answer may be correct.)
A.
B.
C.
D.
E.
Registers the AGWs with the S-CSCF

Basic call handling
Contact the P-CSCF for outgoing calls
Process originating calls from endpoints
Process terminating calls to endpoints
133

TIM15001

Page 133

iAGCF - Knowledge Check
The iAGCF provides all Class 5 services.
This statement is:
A. True
B. False.
134

TIM15001

Page 134
5420 CTS
135

TIM15001

Page 135
Blank Page
136

TIM15001

Page 136
5420 CTS
Functionality
137

TIM15001

Page 137
Applications Overview 5420 CTS

The 5420 CTS in the IMS Architecture
The 5420 CTS is a SIP application
server that functions as a Telephony
Application Server (TAS) providing:
Number normalization
Digit manipulation
Call-processing logic (tight coupling)
Service logic to apply broad
categories of services to the end
users:

Regulatory services
Wireless services
Network services
Billing services
Web portal services (optional)
138

TIM15001
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
the Alcatel-Lucent Compact Switch configured as a Line Access gateway (LAG)).

Digit manipulation involves number normalization (into E.164 format) and number conversion (translation), such
as E911, which is used for Translations during call-processing and routing.

Page 138

Components
5420 CTS
139

TIM15001
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
Flashable and Non-flashable endpoints )

Storage of subscriber data in the feature server database: subscriber party information and supplementary
services (features) information.

Furthermore, when subscribers are provisioned, provisioning data is stored in the HSS and the Lucent
Communication Manager web portal.
The 5420 CTS also controls the media server, because most supplementary services require announcements
and/or tones to be played. The Media Server also provides conferencing service.
Finally, the 5420 CTS generates charging information (Diameter ACR messages) to be used for Accounting
Management.

Page 139

Basic Functions Session Origination
Functions performed by the 5420 CTS
during session origination:
1.
2.
3.
4.
5.
Receive an INVITE message from the

S-CSCF with a private tag indicating
an origination
Query the subscriber database to
obtain the data of the calling party
Apply the appropriate originating
services and/or perform number
normalization
Send an INVITE back to the S-CSCF
with the same private tag
When the transaction is completed,
send charging data
140
2 5420 CTS
3

TIM15001

Page 140

Basic Functions Session Termination
Functions performed by the 5420 CTS
during session termination:
1.
2.
3.
4.
5.
6.
Receive an INVITE message from the

S-CSCF with a private tag indicating
a termination
Query the subscriber database to
obtain the data of the called party
Verify the terminating UE is
registered and check UE state
Apply the appropriate terminating
services
Send an INVITE back to the S-CSCF
with the same private tag
When the transaction is completed,
send charging data
141
2 5420 CTS
3 4
1

TIM15001
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!

Page 141

Media Services
The 5420 CTS requires a Media
Server (MS) to:
Play a specific tone

Play a simple (specific recorded) or
variable announcement
Prompt & collect:
Keypad input
Interactive Voice Response
Provide conference services
An MS acts as a combined Media

Resource Function Controller
(MRFC) / Media Resource Function
Processor (MRFP).
142

TIM15001
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
approximately 8K for each second of announcement duration.

Page 142

Treatment, Tones and Announcements
When service processing performed by the 5420 CTS determines that a
treatment must be applied (treatment event), the 5420 CTS:
Selects a media server to use from a provisioned list of Media Resource

Functions that is stored in the configuration database
Sends a SIP INVITE message to that media server; the message includes
the URL of the announcement file(s) and/or tone file(s) to play, based
on the treatment ID
Audio files storage depends on media server requirements:
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

TIM15001
Media server provisioning in FS GUI: IMS-> Parameters/Timers->5420 CTS->Media Parameters

For AudioCodes, the 5420 CTS stores the audio files in the /tftpboot/annc/eng_us directory on the MI service;
the provisionable eng_us part is the default locale. Locale directories are used to support multiple
languages and country variants The play parameter consists of Play=http://<MI server
FQDN>/tftpboot/annc/eng_us/<file name>
For eMRS, file server parameter is set to MRF and Play=file://<file name>
The Announcement Tool that runs on the MI service can be used to download a copy of the audio files:
Can download from the Alcatel-Lucent Electronic Distribution/Delivery (LED) site (3G-MSC only?)
Can download from the On-Line Customer Support (OLCS) site: www.support.Alcatel-Lucent.com
Can also be used to send a copy of the audio files from the MI service to the eMRS.
A service provider may want to customize announcements, for example to:

Have their own actor record the announcements
Change the wording of the announcements
Record in a different language (the announcements files should be stored in a different local directory from
eng_us)
The customized announcements files can be downloaded using the Announcement Tool as well.

Page 143

Media Server Interoperability
Up to eight media servers in distributed pooled mode:
Round-robin media server selection

More than one 5420 CTS can access a media server
Each 5420 CTS can access any media server
The 5420 CTS acts as a SIP user agent client, opening SIP dialogs in
conjunction with:
NETANN (tone and simple announcement playback; conferencing)

MSCML (multiple and variable announcement playback; prompt &
collect)
Announcement Tool that runs on the 5400 LCP can be used to download
and distribute the initial audio files to media servers.
144

TIM15001
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.
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.

Page 144

The Web Portal
The 5420 PCM (Personal
Communication Manager) can be
assigned as a web portal to provide
converged services for subscribers:
Offers an interface (GUI) to enable

services such as click-to-dial, clickto-conference, etc.
Relays the call-control requests to
the 5420 CTS for processing
Receives status information from the
5420 CTS about calls to/from
directory numbers
145

TIM15001
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

Page 145

Digit Translation
146

TIM15001
The DPE data includes:
Digit tables (new tables specifically designated to the 5420 CTS have been defined):
Feature codes and carrier dial-around codes
Operator assistance codes
Emergency services routing number
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.

Page 146

Non-Flashable Endpoints and Flashable Endpoints
Non-flashable endpoints
Flashable endpoints
Services that are signaled by a hookflash

are applied by the endpoint
Services that are signaled by a hookflash are

applied by the D-TAS component of the 5420
CTS
The other services are applied by the STAS component of the 5420 CTS
The other services are applied by the S-TAS

component of the 5420 CTS
A hookflash event initiates a new INVITE

dialog
Hookflash events are reported to the 5420

CTS with INFO message
Two or more INVITE dialogs can exist

between an endpoint and the 5420 CTS
Only one INVITE dialog can exist between an

endpoint and the 5420 CTS
Set Multiple bearer paths towards an

endpoint may exist
Only one bearer path towards an endpoint

may exist
Advanced endpoint
Simple endpoint or advanced endpoint

(provisioned as simple endpoint
147

TIM15001
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.

Page 147

S-TAS and D-TAS
Non-flashable endpoints
148
Flashable endpoints

TIM15001
Non flashable endpoints

Note that this is a simplified logical diagram: the endpoints are not physically connected to the 5420 CTS. The purpose is just
to show the relationship between the application component (S-TAS = Subscriber TAS and the endpoints.
S-TAS is always in the call (it it the actual TAS)
The provisioningd data in the 5420 CTS for such endpoints must be set to indicate that the endpoint is Non-flashable.
The services that are signaled by a hookflash are often referred to as Multiple-call services, such as mid-call and multi-way
call: Call Hold, Call Transfer, 3-Way Call, and Call Waiting.
Flashable endpoints
The S-TAS is always in the call (it it the actual TAS) and the D-TAS (= Device-specific TAS) comes into play in the case of
flashable endpoints. In general, a D-TAS provides device-dependent services (such as Call Waiting and Call Hold) when
the endpoint itself is not capable of handling them or whenever the design of a specific service can be simplified by using
the D-TAS. In addition, a D-TAS can provide device-dependent services for intelligent devices when it is required that the
network is responsible for handling those services.
Actually, the distinction is between simple endpoints and advanced endpoints. Simple matches the concept of a SIP IAD
with traditional circuit analog POTS phones behind it.. However, many advanced endpoints can operate either way, thus
act as either flashable or non-flashable. The provisioningd data in the 5420 CTS for each endpoint must be set to indicate
whether or not the endpoint is Flashable. If an endpoint can operate either way, the Service Provider must ensure
the value of this field in the 5420 CTS is consistent with the way the endpoint is configured to operate!

Page 148
Applications Overview - 5420 CTS
Session Origination from Non-Flashable Endpoint

The S-CSCF finds a match on a trigger
in the iFC and redirects the INVITE
message to the S-TAS
The S-TAS applies the originating
services and/or performs number
normalization and routes back to the
S-CSCF
Assume the S-CSCF finds no match on
other iFC triggers; so it is done
redirecting to application servers
and forward INVITE message to the
next node
5420 CTS
D-TAS S-TAS
To called party
home network
Advanced endpoint
(non-flashable)
149

TIM15001
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

Page 149
Session Termination to Non-Flashable Endpoint

in the IFC and redirects the INVITE
The S-TAS applies the terminating
services and routes back to the SCSCF
other IFC triggers; so it is done
and forward INVITE message to the
P-CSCF
5420 CTS
D-TAS S-TAS
From calling
party home
network
Advanced endpoint
(non-flashable)
150

TIM15001
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!

Page 150

Session Origination from Flashable Endpoint
message to the D-TAS
The D-TAS applies any multi-call
services and routes to the S-TAS
The S-TAS applies the originating
normalization, and routes back to
the S-CSCF
and forwards INVITE message to the
next node
5420 CTS
D-TAS S-TAS
To called party
home network
Simple endpoint
(flashable)
151

TIM15001
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).

Page 151

Session Termination to Flashable Endpoint
The S-TAS applies the terminating
normalization services, and routes
to the D-TAS
The D-TAS applies any multi-call and
routes back to the S-CSCF
and forwards INVITE message to the
P-CSCF
5420 CTS
D-TAS S-TAS
From calling
party home
network
Simple endpoint
(flashable)
152

TIM15001
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).

Page 152

Knowledge Check
The 5420 CTS plays tones and announcements.
This statement is:
A. True
B. False
153

TIM15001

Page 153

Knowledge Check
Which statements about flashable endpoints are true?
A.
B.
C.
D.
Handles multiple-call services internally

Can be an advanced endpoint, such as a SIP phone
Requires the D-TAS application component of the 5420 CTS
Reports a hookflash event in a SIP INFO message.
154

TIM15001

Page 154
5420 CTS
Services
155

TIM15001

Page 155

Service Categories
The 5420 CTS services can be divided in the following categories:
Other Services
Regulatory services
Wireless services
Network services
Billing services
156

TIM15001
Services can be divided in different categories:

Other services
Regulatory services
Wireless services
Network services
Billing services
The first part of this section gives an overview and description of the regulatory, wireless, network,
administrative and billing services.
The second part of this section will focus on business and residential supplementary services. It will give an
overview of which supplementary services are available and how they are packaged. Also some example
scenarios of supplementary services are given.
More detailed descriptions of the services can be found in the customer documentation:
5420 Converged Telephony Server (CTS) Application User Guide
Part I: The Alcatel-Lucent Converged Telephony Server
Chapter 5. Services
Page 156

Regulatory Services
Regulatory services include:
Carrier selection and carrier pre-selection

Customer originated trace
Emergency service
Government Emergency Telecommunications Service (GETS)
Local number portability
Malicious call trace/nuisance call trace
Multi-Level Precedence end Preemption (MLPP)
Selective nomadic blocking
Non-paying subscriber treatment
Location Number
157

TIM15001

Carrier selection is a way for a subscriber who is connected to the access network to choose a carrier for a specific call. For example, it
makes it possible for the subscriber to choose which carrier to use for a particular international destination.
The following carrier selection types exist:
LATA based carrier selection
Digit analysis based carrier selection
IN Query based carrier selection.
Customer Originated Trace
The Customer Originated Trace (COT) service is a subscriber-invoked service that allows a customer to trace the number of a calling party.
This is often used to determine the origination of harassing or other nuisance calls. There are two parties involved in a COT:
the customer who receives the call and requests the trace
the agency (e.g., a law enforcement agency) that receives the output message containing the trace results.
Emergency service
The emergency service allows users to initiate a call to the appropriate Public Safety Answering Point (PSAP), typically via a nationwide
uniform number. At the PSAP (orcall center), an emergency operator determines the nature of the emergency and dispatches
assistance or makes contact with another agency as appropriate.
The following are examples of nationwide emergency numbers:
911 in the United States
000 in Australia
112 in the European Community
119 in some Asian countries, with special numbers in some countries for police, ambulance or fire.
Mobile and Nomadic subscribers
The emergency calling service provided by 5420 CTS is sufficient for fixed users. Fixed users do not move during calls (mobile users) or
between calls (nomadic users). This service provides functionality beyond what is specified in the National Emergency Number
Associations (NENA) i1 specification. To support nomadic and mobile users, NENA i2 is supported. It provides a separate Emergency
Application Server (EAS) and appropriate external interfaces which conform to the NENA i2 architecture.
GETS is a service mainly for the US market which allows authorized government users to gain access to the network during emergency
situations. The user dials an access number to place a GETS call, which causes the call to complete to one of the inter exchange
networks, where authentication via PIN code and collection of the final routing number are performed. GETS calls are provided with
special treatment to assure a high probability of completion

Page 157

Regulatory Services (continued)
Regulatory services include:

Customer originated trace
Emergency service
Local number portability
Multi-Level Precedence end Preemption (MLPP)
Selective nomadic blocking
Non-paying subscriber treatment
Location Number
158

TIM15001
Local Number Portability

Local Number Portability (LNP) is not provided directly by the 5420 CTS. Other IMS elements, particularly the MGCF are used to support
Local Number Portability.
Malicious call trace/nuisance call trace (NCT) is a public safety service that allows a service provider to identify the origination or
termination of a telephone call. This capability is often used to determine the origination or termination of harassing or other nuisance
calls.
Multi-Level Precedence and Preemption (MLPP)
The Multi-Level Precedence and Preemption MLPP provides prioritized call handling service:
Precedence involves assigning a priority level to a call
Preemption involves the seizing of resources, which are in use by a call of a lower precedence, by a higher level precedence call in the
absence of idle resources. Users in networks that do not support this service will not be affected by this service.
Please not that for this release MLPP is only supported on Alcatel-Lucent CP 1000.
Selective Nomadic Blocking
The Selective Nomadic Blocking service (SNB) provides capabilities that meet a service providers obligation to comply with Federal
Communications Commission (FCC) standards by blocking non-emergency calls for nomadic users. A nomadic user is one who changes
location between (but not during) calls.
Non-Paying Subscriber Treatment
This service deals with announcements for calls originated by non-paying subscribers. With this service, the Service Provider (SP) is able to
keep non-paying subscriber from originating a call or divert a call. This service does not keep a non-paying subscriber from answering a
call. When call origination or call diversion is blocked by this service, the caller hears an announcement.
Location Number
An optional Location Number may be populated in per-subscriber data. When a Location Number is populated, it will be included in a
P-Access-Network-Info header based on ETSI ES 283 003.

Page 158

Wireless Services
Wireless services include:
Dual Mode Service/WiFi Roaming

HSS Shared subscriber data
Femto Base Station Router Interface (FemtoBSR)
159

TIM15001
Dual Mode Service/WiFi Roaming

Dual-mode service allows a user with a dual mode (CDMA/WiFi or GSM/WiFi) handset (cell phone) to roam from a:
WiFi (ITU Q.802.11) network (hotspot or home) to a mobile phone network, or
Mobile phone network to a WiFi network.
This service allows:
End users to perform handover for an active call
Wireless service providers to save air bandwidth and provide better quality of service.
Note This functionality is only supported in the distributed configuration.
HSS Shared subscriber data
HSS shared subscriber data allows the 5420 CTS to read and update information held in the ANSI/CDMA USDS and UMTS
HLR to facilitate feature data sharing for services. The subscriber dynamic data for these basic features is kept in sync
between the 5420 CTS subscriber database and the HSS/HLR. This allows a dual mode CDMA-IMS or UMTS-IMS handset to
behave identically regardless of the access technology.
Femto Base Station Router Interface (FemtoBSR)
A Femto Base Station router (FemtoBSR) device is a short-range wireless base station that can be deployed in homes and
other locations, and enables a non-SIP mobile phone to interact with the IMS network.
The FemtoBSR acts as a cell tower as far as the mobile phone is concerned. The FemtoBSR will interwork wireless
protocols to SIP protocols. The mobile phones attached to the FemtoBSR are not provisioned in any CTS static data. The
CTS discovers the identity of attached mobile phones as originating and terminating INVITE requests are received. The
association of mobile phone to a FemtoBSR call is determined by the To header for terminating INVITE messages, and
the From header for originating INVITE messages.
Although the mobile phones are not provisioned in the CTS, most services will work at the mobile phone level. For
example, when a terminating INVITE arrives associated with a particular mobile phone the CTS needs to determine
whether there is an existing
call on the FemtoBSR associated with that mobile phone in order to properly apply Call Waiting. The current status of
other mobile phones behind the FemtoBSR is not relevant for purposes of Call Waiting.
The FemtoBSR looks like a simple endpoint to the CTS, defined as a Party ID. The FemtoBSR supports a limited set of
services including Call Waiting, Flash Originating, N-Way calling, Call transfer, Dialing Plan, and Calling Line Identity
Page 159

Network Services
Network services include:
Short code translation

Location-based routing
160

TIM15001
Short Code Translation

The Short Code Translation (SCT) service allows mobile subscribers to place calls to users of other VoIP
services using a Uniform Resource Locator (URL) address instead of a directory numbers (DN). This is done
by using the address book function of the mobile handset.
Location Based Routing
The Location Based Routing service 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.
Note Location Based Routing is only supported with the distributed configuration

Page 160

Administrative Services
Administrative services include:
Configurable feature codes

Announcement locale & multi-lingual announcements
Service provider defined CPE profiles
Wildcard Public IDs
161

TIM15001
Configurable feature codes

The configurable feature codes service enables providers to configure per-service activation and deactivation
codes. Subscribers use these codes to activate/deactivate supplementary services.
Announcement Locale & Multi-Lingual Announcements
5420 CTS supports the specification of up to two announcement locales in global and per-subscriber data. The
locale is used to construct the URL of announcement files.
Various assignments are possible, however, the two most typical cases are:
A global locale is assigned and is the default for all subscribers (e.g. the predominant local language).
Selected subscribers may be assigned a different
locale, based on their language preference.
A subscriber is assigned two locales, so that all announcements will be given in two languages. A brief
silence is inserted between the two announcements, composed of 0.5 seconds of comfort noise (tone ID
21)
Service Provider Defined CPE Profiles
Each 5420 CTS subscriber is associated with a Customer Premise Equipment (CPE) Profile. The profile specifies
certain CPE-specific capabilities and SIP message header contents used to access those capabilities. AlcatelLucent provides a set of pre-defined CPE profiles. This section documents all
of the available CPE profile attribute and value settings, along with their behaviors. The service provider may
use the information provided in the section of the 5420 CTS application user guide to design their own CPE
profiles to meet CPE and network requirements not handled by the ALU pre-defined profiles.
Wildcard Public IDs
A Wildcard Public Identifier (PUID) is a short-hand method of designating a range of PUIDs. Wildcard PUIDs are
intended to support registered service for a group of PUIDs such as a registered PBX interface.

Page 161

Billing Services
A CTS Charging profile enables the service provider to control the
generation of billing records.
The following options are available:
INVITE Dialog
SDP in SIP INVITE Dialog
Dial Codes
Incomplete Calls
Inhibit Terminating ACRs
Carrier Id Recording Format
Time Granularity (for AOC and Metering)
The settings in the Charging Profile apply to all Party Ids in the 5420 CTS
162

TIM15001
SDP in SIP INVITE Dialog

This option allows the service provider to determine whether SDP information should be included in the ACR
messages. This option also allows the service provider to select how much of the SDP information should be
included in the ACR messages.
Dial Codes
This option allows a service provider to turn on or turn off the generation of ACR messages when a CTS
supplementary service dial codes is detected.
Incomplete Calls
This option allows a service provider to turn on or turn off the generation of ACR message for incomplete calls.
Inhibit Terminating ACRs
This option allows a service provider to inhibit the transmission of terminating billing records. Terminating
billing may be inhibited to increase system capacity in those cases where terminating billing records are not
needed.
Carrier Id Recording Format
Certain networks may permit the user to select a carrier for their call, either by pre-subscription or call-bycall selection. This option allows a service provider to include per-call carrier information in billing records.
R17: The CTS R6.1 Metering will use the following new parameter in the Charging Profile in the Configuration
database:
Time Granularity: the supported values are one-second (default ) and one-tenth-second.
In additional to adding the Time Granularity parameter, another change of the FSGUI (also OMCP GUI) is to
change the name of ACR Charging Profile into CTS Charging Profile. The reason for the change is that,
since release 6.1, CTS come to have charging parameters for CCR instead of ACR (such as the time
granularity scale) to be added to the configuration database. That means CTS needs a common charging
profile for both ACR and CCR, rather than a charging profile solely for ACR.
Page 162

Supplementary Services and Features
The 5420 CTS provides a wide ranges supplementary services for
residential and business subscribers.
In the 5420 supplementary services are often referred to as features.
Supplementary services are combined into so called feature packages
to keep ordering and engineering simple.
A la carte features (or independent) features are features that are not
part of a feature package, but that can be assigned to a subscriber
in addition to its feature package
163

TIM15001
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.

Page 163

Feature Templates
Feature Package
Feature 1
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

TIM15001
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.

Page 164
5420 CTS
Subscriber Services Scenarios
165

TIM15001

Page 165

Subscriber Services Scenarios - Overview
This subsection gives detailed scenarios of a selection of subscriber
services. The example scenarios are:
Call Waiting
Call Pickup
Simultaneous Ringing
TISPAN Conferencing
166

TIM15001

Page 166
5420 CTS
Subscriber Services Scenarios - Call Waiting
167

TIM15001

Page 167

Services Example: Call Waiting
Call Waiting (CW) is a residential supplementary service:
While a call is in session, a tone is played to a subscriber to indicate a

new incoming call has arrived.
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.
CWT is assigned per PartyID and applies to all associated PUIDs.
168

TIM15001
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.

Page 168

CW Call Flow for Simple Endpoint (1)
UE-1
CTS-1
UE-2
UE-3
VP1: Call exists between UE-1 and UE-2
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

TIM15001
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.

Page 169

UE-1
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 from UE-1)
VP2: Voice path established between UE-1 and UE-3; UE-2 is on hold
170

TIM15001
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.

Page 170

UE-1
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)
I
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

TIM15001
G. The UE-1 subscriber can use the hook flash to toggle between the active and held calls. UE-1 endpoint
report the hook flash to CTS-1 in an INFO request.

H. CTS-1 must now swap the active and held calls sent to UE-1. First, put the call with UE-3 on hold.
I.
UE-3 is now on hold and now CTS-1 must re-establish the bearer path between UE-1 and UE-2.

Page 171
Blank Page
172

TIM15001

Page 172
5420 CTS
Subscriber Services Scenarios - Call Pickup
173

TIM15001

Page 173

Services Example: Call Pickup
Call Waiting (CW) is a business supplementary service:
Call Pickup allows to answer a call that is ringing at another endpoint in

a pre-defined Call Pickup group.
A Call Pickup group consists of:

One Controller
Multiple members.
174

TIM15001
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.

Page 174

Call Pickup Call Flow (1)
CTS-2
applies terminating
services to UE-2
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)
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
3a. CTS-3 puts UE-3 on hold
CANCEL
200 OK (SDP offer, IP address=0.0.0.0)

200 OK CANCEL
487 Request Terminated

ACK (for 487)
175

TIM15001
INVITE (SDP offer)
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.
Page 175

Call Pickup Call Flow (2)
UE-1
CTS-2
applies terminating
services to UE-2
UE-2
CTS-3
applies originating
services to UE-3
UE-3
3c.CTS-3 re-establishes call with UE-3

200 OK (SDP answer from UE-3)
4a.More interaction between the
UE-2 process and UE-3 process
4b.More interaction between the

UE-2 process and UE-3 process
200 OK INVITE (SDP answer from UE-3)

ACK
ACK
Voice path established between UE-1 and UE-3
176

TIM15001
INVITE (SDP offer)
CTS-2 and CTS-3 are (still) the same AS; therefore:

Step 4a: The 200 OK message from UE-3 can be passed internally from CTS-3 and CTS-2 and now finally a 200
OK message is returned to UE-1; however, with the SDP offer from UE-3 instead of UE-2.
Step 4b: The ACK message from UE-1 can be passed internally from CTS-2 and CTS-3 and then forwarded to
UE-3.

Page 176
5420 CTS
Subscriber Services Scenarios - Simultaneous Ringing
177

TIM15001

Page 177

Services Example: Simultaneous Ringing
Simultaneous Ringing (SimRing) is a residential supplementary service:
A set of numbers may be rung simultaneously on call receipt at a

parent number.
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.
SimRing is assigned per PUID.

A service provider can designate a virtual number to have SimRing while all
other PUIDs do not.
178

TIM15001
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.

Page 178

SimRing Call Flow (1)
CTS-2
applies terminating
services to UE-2
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)
3. No terminating services for UE-3
4. The first 180 Ringing is sent to UE-1

180 Ringing (from UE-2, no SDP)

5. First to accept the call
200 OK (for INVITE; SDP answer from UE-3)
179

TIM15001
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.

Page 179

SimRing Call Flow (2)
UE-1
CTS-2
applies terminating
services to UE-2
UE-2
CTS-3
applies originating
services to UE-3
UE-3
6. Received answer; cancel call leg to UE-2

CANCEL
200 OK (for CANCEL)
487 Request Terminated (for INVITE)
ACK (for 487)
7. Establish call with UE-3
reINVITE (original SDP offer from UE-1)
200 OK (for INVITE; SDP answer)
200 OK (for INVITE; SDP answer from UE-1)
Voice path established between UE-1 and UE-3
180

TIM15001
INVITE (SDP offer)
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).

Page 180
5420 CTS
Subscriber Services Scenarios - TISPAN Conference
181

TIM15001

Page 181

Services Example: TISPAN Conference Call
TISPAN conference is a residential supplementary service that allows a 5420 CTS
subscriber to initiate a conference call using the TISPAN conference model:
Networkbased conferencing for advanced endpoints
To create a conference instance, an endpoint reports a hookflash in an initial

SIP INVITE message.
To add or drop a conference participant, the endpoint sends a SIP REFER

message.
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

TIM15001
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.).
Page 182

TISPAN Model Conference Call Information
The INVITE messages and REFER messages convey the following:
The Conference Factory URI, which identifies the conference server

(the 5420 CTS).
Public Conference ID, which is used between the party that controls the
conference and the conference server.
Private Conference ID, which is used between the conference server

and the Media Resource Function (MRF).
Conference Focus, which is the SIP UA that is addressed by a

conference URI (the 5420 CTS) with tag isfocus; it identifies a
conference.
183

TIM15001

Page 183

TISPAN Model Conference Call Scenario
A typical conference call scenario is performed as follows:
A conference controlling party (A) initiates a 2-way call (say A-B call).
The party A puts the A-B call on hold.
The party A then requests a conference bridge (INVITE message with
the conference factory URI).
The party A requests party B to be joined the conference (REFER
message with Public Conference ID, the invited party and the
Replaces information).
The party A puts the conference on hold.
The party A initiates another 2-way call (say A-C call).
The party A then put A-C call on hold (go back to the conference call).
The party A REFER party C to the conference.
184

TIM15001
Party A has Conference calling service assigned.

Note that the requests are directed to the CTS.
For simplicity, joining messages that involve UE-C are not shown in the call flow (next pages).

Page 184

TISPAN Model Conference Call Flow (1)
UE-A creates conference and connects itself to MRF
UE-A
CTS
MRF
UE-B
UE-C
VP1:Voice path exists between UE-A and UE-B

1. User of UE-A (controller)
initiates conference
INVITE (Conf-URI, SDP offer from UE-A)
2. Set up TISPAN model conference:
Create Public Conference ID=X
Create Private Conference ID=Y
Create dialog between UE-A and MRF.
INVITE (ID=Y, SDP offer from UE-A)
200 OK (for INVITE; SDP answer from MRF)
3. Relay 200 OK to controller
and ACK back to MRF
200 OK (isfocus tag,
ID=X, SDP answer from MRF)
ACK (for 200 OK)
VP2: Voice path between UE-A and MRF
185

TIM15001
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

Page 185

UE-A invites existing party to conference X
UE-A
CTS
MRF
UE-B
UE-C
REFER (ID=X, Refer-To:UE-B, Replaces=A-B)

202 Accepted
4. Perform connection procedure:
- Inform controller to terminate subscription.
- Retrieve Private Conference ID Y
- Create dialog between MRF and invited party.
NOTIFY (termination)
200 OK
INVITE (ID=Y, no SDP)
200 OK (SDP answer from MRF)
reINVITE (SDP offer from MRF)
200 OK (SDP answer from UE-B)
ACK
VP3: Voice path between UE-B and MRF
BYE
5. In a similar manner UE-C is added to conference X
VP4: Voice path between UE-C and MRF
186

TIM15001
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.
Page 186

UE-A requests to drop an existing participant
UE-A
CTS
MRF
UE-B
UE-C
REFER (ID=X, Refer-To:UE-C, method=BYE)

202 Accepted
6. Perform disconnection procedure:
- Inform controller to terminate subscription.
- Retrieve Private Conference ID Y
- Tear down dialog between MRF and dropped party.
NOTIFY (termination)
200 OK
BYE (ID=Y)
200 OK
BYE
200 OK
187

TIM15001
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.

Page 187
Blank Page
188

TIM15001

Page 188

Services Appendix Residential Feature Packages
Silver residential feature package
Anonymous Call Rejection
Automatic Call Back
Automatic Recall Bearer-Based
Call Forwarding
Call Barring
Outgoing Call Barring
Call Blocking Incoming
Call Blocking Incoming Intl
Call Completion to Busy Subscriber
Call Deflection
Call Forwarding Busy (CFB)
Call Forwarding Default (CFD)
Call Forwarding No Answer (CFNA)
Call Forwarding Provisioned Forwarded DN Screening
Call Forwarding Simultaneous Limit Increase
Call Forwarding Unregistered (CFU)
Call Forward to Voice Mail (CFVM)
Call Forwarding Level of Control
Call Forwarding No Answer timer control via DTMF
Call Forwarding Local
Call Hold Consultation
Call Transfer Blind
Call Transfer from Three-Way
Call Transfer with Consultation
Call Waiting Call Waiting With
Caller ID
Call Waiting with Distinctive Ringing
Calling Line ID Presentation (CLIP)
Calling Line ID Restriction (CLIR)
Calling Line ID Restriction Override (CLIRO)
Calling Name Identification Presentation (CNIP)
Calling Name Identification Restriction (CNIR)
Cancel Call Waiting Mid Call Cancel
Call Waiting Per Call
Cancel Call Waiting Persistent
189
Cancel Call Waiting Mid Call Cancel

Call Waiting Per Call
Cancel Call Waiting Persistent
Carrier Selection
TISPAN Conference Calling
Conference Calling (6 party max)
Connected Line Identification Presentation
Connected Line Identification Restriction
Connected Line Identification Restriction
Override
Customer Originated Trace
Customized Announcements
Device Extension
Dial Code Feature Status Interrogation
Do Not Disturb (DND)
Dual Mode Service
Hotline/Warmline Service
Inhibition of Incoming Forwarded
Calls Intercept Referral Service
Local Number Portability Message
Waiting Indicator
Multiple Directory Number (MDN)
Nuisance Call Trace
Remote Access Service Reminder Call
Ring-Back when Free (intra-switch) Selective
Call Acceptance (SCA)
Selective Call Forwarding (SCF) Selective
Call Rejection (SCR)
Selective Distinctive Alerting
Service Suspension
Shared HSS Data
Simultaneous Ringing (One Number)
Speed Dialing (1-digit and 2-digit)
Star Code Access to Voicemail
Web Portal

TIM15001
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

Page 189

Services Appendix Business Service Packages
Core business service package
Contains all of the features in the silver residential packages and the following features:
Directed Call Pick-up
Directed Call Pick-up Barge-In
Private Dialing Plan Extension Presentation
Flexible Calling Line ID/ Group ID Delivery
Mobile Extension (Virtual Office)
Multi-Line Hunt Groups (Sequential, Circular, Uniform)
Multi-Line Hunt Group No hunt member
Organizational Support
Private Dialing Plan
Sequential Ringing
Package and the following features:

Account Codes
Authorization Codes
Basic Auto Attendant (via the PCM)
Call Park (Hard Hold)/ Retrieve
Call Pick-up
Closed User Group
Closed User Group Enhancements
Closed User Group Call Limits
Direct Dial to Voicemail Directed
Call Park/ Retrieve
Premium business service package

Contains all of the features in the core business service packages and the following features:
Music on Hold
Time of Day/Day of Week Capabilities (via the PCM)
Personal Ring-back Tones

User Control of Call Barring
The following A la Carte services are not of any feature package:

Attendant Console
Large Call Limit (PBX Support)
Multi-Line Hunt Group Queuing
Trial Service AIN Trigger
Trial Service - Short Code Translation
190
Deluxe Auto Attendant

Location Based Services
Selective Nomadic Blocking for 911
Trial Service Shared Number

TIM15001
The US Military Package contains the following features:

Account Codes
Codes
Authorization
Call Barring
Call Forwarding Always (CFA)
Call Forwarding Busy (CFB)
Call Forwarding Local
Call Forwarding No Answer (CFNA)

(CFU)
Call Forwarding Unregistered
Call Forwarding to Voice Mail (CFVM)
Call Park, Call Retrieve/Directed
Call Park, Call Retrieve

Pickup/Directed Call Pickup
Call
Calling Line ID Presentation (CLIP)

(CLIR)
Calling Line ID Restriction
Calling Line ID Restriction Override (CLIRO)
Calling Name Presentation
Closed User Group

Do not Disturb Flexible
Calling Line ID/ Group ID Delivery
Hotline/Warmline
Message Waiting Indicator

Preemption (MLPP)
MultiLevel Precedence and
Multi-Line Hunt Group

Plan (PDP)
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
Location Based Services
Page 190
Selective Nomadic Blocking for 911
Blank Page
191

TIM15001

Page 191
iHSS/iSLF
192

TIM15001

Page 192
Applications Overview - iHSS

iHSS in the IMS Network
In the 5060 ICS the HSS
function is performed by
the iHSS.
193

TIM15001
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.

Page 193

Architecture
194

TIM15001
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
is used (based on top of TCP/IP)

The HSS is provisioned via the XML interface.

Page 194

Main Functions
i
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

TIM15001
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,
the HSS will provide this information to the I-CSCF)

Cancellation of S-CSCF (performed due to change in subscription of the user)
Store information in the user profile
Give information to the S-CSCF (address, name, and user profile) when needed (during registration or to
handle termination to an unregistered user).

Cx/Diameter commands and their direction:
User-Authorization-Request (UAR) I-CSCF -> HSS
User-Authorization-Answer (UAA) HSS -> I-CSCF
Multimedia-Authentication-Request (MAR) S-CSCF -> HSS
Multimedia-Authentication-Answer (MAA) HSS -> S-CSCF
Server-Assignment-Request (SAR) S-CSCF -> HSS
Server-Assignment-Answer (SAA) HSS -> S-CSCF
Location-Info-Request (LIR) I-CSCF -> HSS
Location-Info-Answer (LIA) HSS -> I-CSCF
Push Profile Request (PPR) I-CSCF -> HSS
Push Profile Answer (PPA) HSS -> I-CSCF
Registration Termination Request (RTR) I-CSCF -> HSS
Registration Termination Answer (RTA) HSS -> I-CSCF
The slide only states the most important

functions and the
associated
messages.
<COURSEPARTNUMBER>
Edition
<COURSEEDITION>
Page 195

Database Structure
Per subscriber
Global
1-n
1-n
196
1-n

TIM15001
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).
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.

Page 196

Database Structure - Private ID
PridUser
Private ID user name, without
domain
PrivPassword
Password for registration
PublicId
A maximum of 10 associated public
IDs (into PublicId profile)
PrivateId
PridUser
PrivPassword
PublicId
PublicId
PublicId
..
197

TIM15001
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).

Page 197

Database Structure - Public User ID
PuidUser
PUID phone number, without domain
AssocPrivateId
Associated internal private ID index
containing this public ID
Authorized
Is this PUID authorized to register?
Barring
Barring indication sent to S-CSCF
ImplRegSet
Implicit registration set number
ServiceProfileNumber
Index to a service profile associated
with this PUID.
198
PublicId
PuidUser
AssocPrivateId
Authorized
Barring
ImplRegSet

TIM15001
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.

Page 198

Database Structure - Service Profile
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
ServiceProfileName
ServerCapNumber
GlobalIFCNumber
GlobalIFCNumber
GlobalIFCNumber
..

TIM15001
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
associated with this service profile.

Page 199

Database Structure Global iFC
GlobalIFCNumber
Internal global IFC index
GlobalIFCName
Description of this global IFC
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

TIM15001
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).

Page 200

Database Structure The Full Picture
201

TIM15001
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.

Page 201

Example: I-CSCF Requests S-CSCF from HSS
UAA
Associated S-SCSF
UAR
Public ID
202

TIM15001

Page 202

Knowledge Check
The iHSS is provisioned via a Cx interface.
This statement is:
A. True
B. False
203

TIM15001

Page 203

Knowledge Check
Which of the following tasks are performed by the iHSS?
(more than one may apply)
A.
B.
C.
D.
Handle SIP messages

Provide filter criteria
Provide supplementary services
Store charging data
204

TIM15001

Page 204
Blank Page
205

TIM15001

Page 205
iSLF
206

TIM15001

Page 206
Applications Overview - iSLF

Subscription Locator Function Recap
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

TIM15001
When receiving responses to certain Cx requests (e.g. User-Authorization-Request, Location-Info-Request), the

I-CSCF will now support the inclusion of the Redirect-Host AVP in the corresponding responses, prompting
the I-CSCF to re-send the Cx request to the iHSS identified in that AVP. The I-CSCF will also include a PUser-Database, with the contents of that AVP, in the corresponding SIP requests (e.g. REGISTER, INVITE) it
sends to the S-CSCF. It should be noted that neither the I-CSCF nor the S-CSCF (described in the following
row) will support caching of the iHSS identity in the Redirect-Host AVP received from the iSLF.
The S-CSCF will also support the receipt of the Redirect-Host AVP in the responses to the Cx queries it
supports. In addition, however, the S-CSCF will support the ability to send its Cx requests based on the
presence of a P-User-Database header included in a previously received SIP request (e.g. REGISTER, INVITE).
In ICS scenarios, the I-CSCF will generally provide S-CSCF with the subscriber's iHSS identity in a P-UserDatabase header.
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. (still to be checked out)

Page 207

SLF in the 5060 ICS
An integrated Subscription Locator Function (iSLF) is added to the iHSS as an

extension that facilitates a centralized subscriber lookup function.
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:
Each ICS-SIP shelf is administratively assigned an SLF Group Member number.
Members of the group can also be designated as SLF-hosting.
The iSLF subscriber database contains records to locate the iHSS for all
subscribers provisioned on all ICS-SIP shelves in the SLF Group:
Up to 3 non geo-redundant ICS shelves, or

Up to 3 geo-redundant ICS-SIP shelf pairs (that is, up to 6 ICS shelves total).
SLF-hosting ICS-SIP shelf contains an iSLF subscriber database (others do not).

Only up to two SLF-hosting ICS-SIP shelves in the SLF group may be configured.
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

TIM15001
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).

Page 208

ICS SLF group configuration with 3 geo-redundant pairs of ICS shelves
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

TIM15001
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).

Page 209

Scenario Example - The role of an iSLF during Registration
5060 ICS #3
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

TIM15001
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).

Page 210

Scenario Example - The role of an iSLF during inter-ICS-SIP shelf call
ICS Shelf #2
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
2. Location-Info-Request (puid: +ics-user@domain1)

3. Location-Info-Answer (redirect-host=iHSS #4)
4. Location-Info-Request (puid: +ics-user@domain1)
5. Location-Info-Answer (s-cscf name)
6. INVITE(R:URI: +ics-user@domain1, Route: s-cscf name; P-User-Database=iHSS #4)
211

TIM15001
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.

Page 211
Module Summary
This lesson covered the following topics:
A recap of the IMS model and scenarios

The 5060 ICS and the associated applications:
5450 ISC
5450 IRC
5420 CTS
iHSS
iAGCF
212

TIM15001

Page 212
References
For more detailed information on these subjects refer to the system documentation.
IP Call Server Solution Technical Description
Alcatel-Lucent 5400 LCP System Guide
5420 Converged Telephony Server (CTS) Product Description
5450 IP Session Control (ISC) Application User Guide
Network Elements in the ICS Solution

Alcatel-Lucent 5400 LCP functions
5420 CTS functions
Signaling and session handling
5420 CTS End User Services
IP Session Control functions

Required Services
Network Services
5450 IP Resource Control (IRC) Application User Guide

Required Services
Network Services
213

TIM15001

Page 213
Blank Page
214

TIM15001

Page 214
End of Module
Application overview
215

TIM15001

Page 215
Network Architectures

Page 216
Module Objectives
After you have successfully completed this module you will be able to
describe the end-to-end network architectures required to support:
The border solution offerings

VoIP emergency services
Business trunking
217

TIM15001

Page 217
Module Outline
2. Network Architectures
Border Architecture
Business Trunking
218

TIM15001

Page 218
Blank Page
219

TIM15001

Page 219
Border Architecture
220

TIM15001

Page 220
Border Architecture
Description
221

TIM15001

Page 221
Network Architectures - Border Architecture

Introduction
An IMS network can communicate with other IMS or SIP networks outside
the IMS domain of an operator to establish calls and provide services.
The Border Architecture addresses the concerns to secure the
boundaries of an IMS core network of an operator; specific boundaries
are the access border and interconnect/peering border.
222

TIM15001
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.

Page 222

Terminology
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
The Interconnect/Peering Border is the boundary between the

networks of two different operators; examples include:
IP-to-IP interconnect connections (peering/wholesaling)
Traditional IP-to-TDM interconnect (interworking of an MGCF)
Border Control is a set of techniques for conditioning and adapting SIP

signaling and RTP media at boundaries of the IMS core network:
Signaling Border Control provided by IMS SIP Session Control, as mandated by
Standards
Media Border Control hosted on bearer gateways
223

TIM15001
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

Page 223

Decomposed Border Control
The border architecture supports a decomposed border control, which is
functionality distributed across multiple functional elements:
The P-CSCF protects the network from signaling attacks at the access
border.
Supports integrated Security Gateway (that is, SIP signaling firewall function)
The IBCF is inserted into the SIP signaling path to protect the network
from signaling attacks at the peering border.
The PD-FE (SPDF/PCRF) is responsible for ensuring that a user or

external network does not exceed the agreed limitations.
The BGF (Border Gateway Function) controls IP-IP bearer connections

between external networks and the internal core network to block
malicious bearer packets from the external network.
C-BGF (Core BGF) in the Access Border
I-BGF (Interconnect BGF) in the Interconnect/Peering Border
224

TIM15001
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.

Page 224

Deployment Model with Decomposed Border Control
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

TIM15001
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.

Page 225

Access Border
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)

TIM15001
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.

Page 226

interconnect/peering Border
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)

TIM15001

Page 227

Firewall Requirements
Firewall protection is needed at the border points.
A firewall must manage:

L2/L3 firewall functions: Provide bearer protection at transport layer (TCP,
UDP) and IP layer
SIP signaling firewall functions: Provide protection to the 5450 ISC/IRC by
screening out messages that should not be sent to the 5450 ISC/IRC and by
protecting against Denial of Service (DoS) attacks
In the access border architecture the integrated Security Gateway

(iSGW), is used instead of an external firewall:
SIP signaling firewall integrated in the P-CSCF
L2/L3 firewall is still required as a separate entity
228

TIM15001
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.

Page 228

Router Requirements
Edge Routers must be configured at the IP core network edge to route
traffic from the access and IP peering networks, based on IP addresses.
The Edge Routers will be configured to send:
Signaling traffic to SIP Signaling Firewall (SFW) for P-CSCF and IBCF IP
addresses, where SFW is chosen based on the source and/or destination
IP addresses from the transport layer.
If there are multiple SFW (either separate hardware or virtual SFW) to choose
from, then source IP address will factor into Edge Router configuration to
select SFW.
The SFW will then forward the SIP message to the appropriate 5450 ISC
component (P-CSCF or IBCF) using the destination IP address from the
transport layer (for P-CSCF and Integrated SIP Firewall the destination IP
address is shared for P-CSCF and SFW).
Bearer traffic to ALU 7510 MGW (C-BGF or I-BGF) for the bearer IP
addresses, for example the media.
229

TIM15001
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.

Page 229

Solutions
Based on the border architecture, Alcatel-Lucent offers two solutions:
Access and Interconnect Border Solution
Transit Class 4 Solution
Functional Element
Access and Interconnect

Border Solution
Transit Class 4 Solution
Typical Product Selection

P-CSCF
5450 ISC
N/A
IBCF
MGC-8 or 5450 ISC
MGC-8 or 5450 ISC
PD-FE
C-BGF
I-BGF
5450 IRC (SPDF/PCRF)

7510 MGW
7510 MGW
5450 IRC (SPDF)

N/A
7510 MGW
SIP Signaling Firewall 5450 ISC (iSGW)
Fortinet Fortigate-5000 Series
L2/L3 Firewall
230


TIM15001
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.
Peering Border Control is not needed, because:
MGCF/SG and MGWs are trusted IMS functional elements.
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.

Page 230
Blank Page
231

TIM15001

Page 231
Session Border Architecture
Border Functions
232

TIM15001

Page 232
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
Signaling firewall functions

Media firewall functions
Topology hiding
Header removal
5450 5450 7510 SFW

ISC
IRC BGW
(1)
Far-end NAT traversal (for access networks)

Near-end NAT
Dynamic open/close media pinholes per session
Bandwidth reservation and allocation per session
Traffic policing of down/uplink traffic
QoS marking per session
Multiple VLANs
QoS statistics
IPv4 to IPv6 interworking
Optimal media path
Media over TCP
Geo-redundancy
Overlap IP
Keep firewall pinhole open (registration suppression)
SIP message screening
Emergency Calls
Note 1: Access Border Architecture only
233

TIM15001
Signaling Firewall Functions:

DoS/DDoS Attack Protection
SIP method throttling
Malformed SIP attack
IPsec
Note: Signaling Firewall Functions in 5450 ISC Access Border Architecture only (Security Gateway integrated in
P-CSF)
Media Firewall Functions:
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
Policing of down/uplink traffic

Page 233
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
Signaling firewall functions

Media firewall functions
Topology hiding
Header removal
5450 5450 7510 SFW

ISC
IRC BGW
Far-end NAT traversal (for access networks)

Near-end NAT
Dynamic open/close media pinholes per session
Bandwidth reservation and allocation per session
Traffic policing of down/uplink traffic
QoS marking per session
Multiple VLANs
QoS statistics
IPv4 to IPv6 interworking
Optimal media path
Media over TCP
Geo-redundancy
Overlap IP
Keep firewall pinhole open (registration suppression)
SIP message screening
Emergency Calls
234

TIM15001
Signaling Firewall Functions:

SIP method throttling
Malformed SIP attack
IPsec
Media Firewall Functions:

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
Policing of down/uplink traffic

Page 234
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

TIM15001
SQM = Service Quality Manager (For VoIP/IMS or IPTV)

If you need to explain QoS statistics details.
When enabled, QoS statistics processing is performed as follows:
1. During call termination, the SPDF requests and receives per call QoS statistics from the BGF in the H.248 Subtract
command.
2. The SPDF receives the QoS statistics in the H.248 Subtract Reply message returned from the BGF.
3. The SPDF generates a Diameter ACR(Event) message with QoS statistics information.
4. The SPDF sends out the ACR(Event) message to the CCF over the Diameter Rf interface.
5. A network management component (for example, 8920 SQM) pulls the statistics from the CCF and presents the
statistics information.
The 7510 Media gateway (acting as C-BGF or I-BGF) must have QoS Statistics enabled and selected H.248 packages E.11
Network and E.12 RTP. The QoS statistics are collected through H.248 E.11 and E.12 by BGC at bearer termination or
bearer release.
H.248 E.11 Network Package provides the following statistics:
Duration duration in milliseconds
Octets sent
Octets received
H.248 E.12 RTP package provides the following statistics:
Packets sent
Packets received
Packet loss percentage as defined in RFC 1889
Inter-packet jitter as defined in RFC 1889
Average packet latency (per RCF 1889)

Page 235
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
IPv4-based or IPv6-based peering networks to interconnect with the IMS core,

whether it is IPv4-based, or IPv6-based
236

TIM15001
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.

Page 236
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

TIM15001
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.
Page 237
Border Functions - IPv4 to IPv6 Interworking Example Scenario 1
Scenario: UE-to-UE inter-network call

orig UE-A is IPv6, orig core is IPv4, term core is IPv6, term UE-B is IPv4
5450 (IPv4)
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

TIM15001
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

Page 238
Scenario: Legacy phone-to-UE intra-network call
Assumes that all IMS core supports SDP IPv6 media

5450 (IPv6)
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

TIM15001
Originating iAGCF checks config flag for media interworking


Page 239
Scenario: PSTN-to-UE call

MGCF is IPv4, term core is IPv6, term UE is IPv4
(IPv4)
MGCF
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

TIM15001
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
No work needed to support IW for intra domain and inter domain.

Page 240
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.
This function is implemented in the Application Layer Gateway (ALG).

Media path optimization (BGW bypass) needs to take the condition(s) into
consideration when NAT is invoked; for example, IPv4 to IPv6 interworking
Assumption: All the medias in one SDP message have the same bearer path and will go
through same BGW sequence.
241

TIM15001
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)

Page 241
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

TIM15001

Page 242
R1
BGW
D
R4
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:
Add specified SIP message information

Remove specified SIP message information
Modify specified SIP message information
Reject or drop messages
SIP message screening can be enabled on the P-CSCF and the IBCF.
Each P-CSCF or IBCF instance can be configured with a Filter Set:
A Filter Set defines how particular SIP messages must be manipulated.

A Filter Set applies to all SIP messages that arrive from an access/peeing network
before they are sent to a border element.
A Filter Set applies to all SIP messages that are received from a border element before
they are forwarded to an access/peeing network.
No Filter Set is needed for instances that do not need SIP message screening capability.
243

TIM15001
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.

Page 243
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
Each border element can apply different

Filter Sets, depending on the needs of its
associated external network.
244
VoIP peering
network
IP PBX

TIM15001
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.

Page 244
Border Functions - SIP Message Screening Operations
Examples of basic message screening operations include:
Reject or discard a SIP request
Discard a response
Modify a SIP request or a response:
Remove or Add Headers/Parameters

Modify Header/Parameter content
Move Parameters (from one header to another)
Remove body attachments
Manipulate list headers (such as P- headers):

Delete, modify, change order, add list headers
Delete parameter from or add parameter to the list headers
Apply to one or more occurrence of a list header
245

TIM15001

Page 245
Border Functions - SIP Message Screening Example 1
Original SIP message
Modified SIP message
INVITE sip:+16300000001@gl21-dev1.lucentlab.com SIP/2.0

Via: SIP/2.0/UDP x.x.x.x:7772;branch=z9hG4bK551223
P-Asserted-Identity: <sip:+16300000000@gl21-dev1.lucentlab.com>
Max-Forwards: 70
To: <sip:+16300000001@gl21-dev1.lucentlab.com>
From: <sip:+16300000000@gl21-dev1.lucentlab.com>;tag=806795
Call-ID: 820@x.x.x.x-7772
CSeq: 2 INVITE
Contact: <sip:x.x.x.x:7772>
Supported: 100rel,timer
Session-Expires: 600
Content-Type: application/sdp
Content-Length: 113
X-DataHeader: cic=281;tg=192
INVITE sip:+16300000001;cic=281@gl21-dev1.lucentlab.com SIP/2.0

Via: SIP/2.0/UDP x.x.x.x:7772;received=x.x.x.x;branch=z9hG4bK51591
Max-Forwards: 70
To: <sip:+16300000001@gl21-dev1.lucentlab.com>
From: <sip:+16300000000@gl21-dev1.lucentlab.com>;tag=806795
Call-ID: 820@x.x.x.x-7772
CSeq: 2 INVITE
Contact: <sip:x.x.x.x:7772>
Supported: 100rel,timer
Session-Expires: 600
Content-Type: application/sdp
Content-Length: 113
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
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

TIM15001
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.)

Page 246
Border Functions - SIP Message Screening Example 2
Original SIP Message
Modified SIP Message
MESSAGE sip:boromir@example.com SIP/2.0

From: <sip:gandalf@nwt.com>;tag=34589882
To: <sip:boromir@example.com>
Call-ID: 9242892442211117@nwt.com
CSeq: 388 MESSAGE
Accept: message/external-body
Content-Type: message/external-body;
access-type=URL;
URL="http://www.uptonogood.com/games/justforfun/killer";
expiration="Sat, 20 Jun 2002 12:00:00 GMT;
size=2031
Content-Length: ...
MESSAGE sip:boromir@example.com SIP/2.0

From: <sip:gandalf@nwt.com>;tag=34589882
To: <sip:boromir@example.com>
Call-ID: 9242892442211117@nwt.com
CSeq: 388 MESSAGE
X-BADURI:"http://www.uptonogood.com/games/justforfun/killer"
Accept: message/external-body
Content-Type: message/external-body;
access-type=URL;
URL="http://www.uptonogood.com/games/justforfun/killer";
expiration="Sat, 20 Jun 2002 12:00:00 GMT;
size=2031
Content-Length: ...
247

TIM15001
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 )

Page 247
248

TIM15001

Page 248
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

TIM15001

Page 249
VoIP Emergency Services - E-CSCF in 3GPP/TISPAN Solution
In the 3GPP/TISPAN solution, the E-CSCF provides the following
Emergency services functions:
Receive an emergency session request from the P-CSCF.
Query a Location Routing Function (LRF) for the appropriate routing

information or PSAP destination based on the location of the endpoint.
Route the call to the correct PSAP:

Via an IP network
Via the PSTN (BGCF/MGCF)
Send charging data upon receipt of SIP responses.
The E-CSCF and the P-CSCF are always located in the same network.
250

TIM15001

Page 250
VoIP Emergency Services - P-CSCF in 3GPP/TISPAN Solution
In the 3GPP/TISPAN solution, the P-CSCF provides the following
Detect an emergency session origination request by screening an

emergency identifiers list
Reject or allow emergency session requests from unregistered users.
Query the CLF for a location identifier.
Select an E-CSCF in the same network (next-hop URI) to handle the

emergency session request.
Support default handling (for example, when a next-hop URI does not
respond, or when origination is from an unregistered PUID) .
251

TIM15001
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.
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.

Page 251
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:
Obtain emergency routing information:

Support of NENA i2 v2 interface, in order to perform a VPC query
HSS query (non-standard solution for fixed IMS subscribers only).
Modify the SIP INVITE message

Forward modified INVITE to next hop (BGCF to route to PSAP in PSTN)
Default routing, if the INVITE with ESRN route attempt fails
Send charging data upon receipt of SIP responses
Alternately, support of NENA i2 v6 interface, in order to forward the
emergency request to the next hop, which is an emergency peering
network where a VCP is queried to locate the correct PSAP in PSTN.
252

TIM15001
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.
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.

Page 252
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

TIM15001
The ICID parameter (if present) is in the P-Charging-Vector header.

Note: only ACR (EVENT) messages are sent.
Refer to SRD-5878, Section 4.2.7 Charging Events.

Page 253
VoIP Emergency Services The Problem
IMS
ESRN 1, based on
Subscriber location
Emergency number
(911 or 112)
Emergency
Emergency
Center 1
Center 2
254

TIM15001

Page 254
VoIP Emergency Services - Functions
VoIP Emergency services must address the following:
Identify an emergency call.

Determine the location of the caller.
Map the location information to routing information.
Route the emergency call to the correct PSAP (Public Safety Answering
Point = emergency center) based on registered location of the caller .
255

TIM15001
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.

Page 255
VoIP Emergency Services - Routing of the Emergency Call
The mapping data is stored in a database in some external network
Each operator maintains its own database
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

TIM15001

Page 256
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)
For nomadic or mobile subscribers: ESRN based on subscriber location,

whereby the location information translation into ESRN is performed by
a VoIP Positioning Center (VPC), which is contacted:
Directly by E-CSCF (NENA i2 v2 interface) or
Indirectly by a emergency peering network (NENA i2 v6 interface).
257

TIM15001
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.

Page 257
VoIP Emergency Services - Determine the VoIP Endpoint Location
It is important that an emergency call is always routed to the Public

Safety Answering Point (PSAP) that is serving the subscribers physical
location.
Because automatic endpoint positioning is not (yet) supported, it is the

responsibility of the calling party to update the provider when the
location changes.
To determine the location of an endpoint is very much dependent on

the access network; examples include:
The network may have the capability to determine the location of the VoIP
endpoint
The endpoint may have the capability to determine its own location from a
location information server such as a Connectivity session Location and
repository Function (CLF).
258

TIM15001
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.

Page 258
VoIP Emergency Services - 5450 ISC Solutions
The 5450 ISC supports the following Emergency services solutions:
Compliant with TISPAN/3GPP standards:

Provides IMS support for IP-based emergency call routing for VoIP originating
emergency sessions to a PSAP.
Location information may be included in the INVITE message from the
endpoint.
Compliant with National Emergency Number Association (NENA) i2

standard:
Provides IMS support for emergency call routing for VoIP terminating
emergency sessions to a legacy circuit-based emergency network.
259

TIM15001
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.
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).

Page 259
VoIP Emergency Services - 3GPP/TISPAN Solution Architecture
260

TIM15001
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
the LRF to retrieve location information for the Emergency Session.

If required, the E-CSCF requests the LRF to validate the location information if included by the UE.
E-CSCF determines or queries the LRF for the proper routing information/PSAP destination.
Subject to national requirements, the E-CSCF may send the contents of the P-asserted ID or UE identification to the LRF.
Based on local policy, the E-CSCF may route the emergency IMS call to ECS (Emergency Call Server) for further call process.
The LRF is a network element that will be provided by a third party vendor and is needed in order for an end-to-end IMS emergency
network solution. Some of the key functionalities of the LRF are:
The LRF is responsible for retrieving the location information of the UE that has initiated an IMS emergency session.
The LRF may interact with a separate Routing Determining Function (RDF) or contain an integrated RDF in order to obtain the routing
information. The routing information is used by the E-CSCF for routing the emergency request. The LRF might also interact with
location servers in order to obtain location information.

Page 260
VoIP Emergency Services - 3GPP/TISPAN Solution Scenario
261

TIM15001
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

Page 261
VoIP Emergency Services - E-CSCF in 3GPP/TISPAN Solution
In the 3GPP/TISPAN solution, the E-CSCF provides the following
Receive an emergency session request from the P-CSCF.
Query a Location Routing Function (LRF) for the appropriate routing

information or PSAP destination based on the location of the endpoint.
Route the call to the correct PSAP:

Via an IP network
Via the PSTN (BGCF/MGCF)
Send charging data upon receipt of SIP responses.
The E-CSCF and the P-CSCF are always located in the same network.
262

TIM15001

Page 262
VoIP Emergency Services - P-CSCF in 3GPP/TISPAN Solution
In the 3GPP/TISPAN solution, the P-CSCF provides the following
Detect an emergency session origination request by screening an

emergency identifiers list
Reject or allow emergency session requests from unregistered users.
Query the CLF for a location identifier.
Select an E-CSCF in the same network (next-hop URI) to handle the

emergency session request.
Support default handling (for example, when a next-hop URI does not
respond, or when origination is from an unregistered PUID) .
263

TIM15001
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.
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.

Page 263
VoIP Emergency Services - CLF in 3GPP/TISPAN Solution
The P-CSCF supports the TISPAN e2 interface to the Connectivity

session Location and repository Function (CLF).
The CLF is in the TISPAN Network Attachment Subsystem (NASS)

framework.
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

TIM15001
The assumption is that the CLF functional entity resides on the formal Alcatel platform SRB 5430.

Page 264
VoIP Emergency Services - LRF in 3GPP/TISPAN Solution
The E-CSCF supports the interface to the Location Routing Function

(LRF).
If location information is not included in the emergency request or

additional location information is required, the E-CSCF may request the
LRF to retrieve location information for the Emergency Session.
If required, the E-CSCF requests the LRF to validate the location

information if included by the UE.
The E-CSCF queries the LRF for the proper routing information/PSAP
destination based on the location of the endpoint.
265

TIM15001

Page 265
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.
A URN (Uniform Resource Name) is used to identify a resource, such as

an E-CSCF, which provides Emergency services.
URN syntax: urn:<NID>:<NSS>
NID = Namespace Identifier, which determines the syntactic interpretation

of the NSS. (service)
NSS = Namespace Identifier, which determines the type of service (sos)
Example:
If a call with incoming message "INVITE sip:911@domain" is identified as an

emergency call by the P-CSCF, the outgoing message could be
"INVITE urn:service:sos.police or "INVITE urn:service:sos.fire
which is routed to the E-CSCF.
266

TIM15001
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.
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

Page 266
VoIP Emergency Services - NENA i2 Solution Architecture
267

TIM15001
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).

Page 267
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:
Obtain emergency routing information:

Support of NENA i2 v2 interface, in order to perform a VPC query
HSS query (non-standard solution for fixed IMS subscribers only).
Modify the SIP INVITE message

Forward modified INVITE to next hop (BGCF to route to PSAP in PSTN)
Default routing, if the INVITE with ESRN route attempt fails
Send charging data upon receipt of SIP responses
Alternately, support of NENA i2 v6 interface, in order to forward the
emergency request to the next hop, which is an emergency peering
network where a VCP is queried to locate the correct PSAP in PSTN.
268

TIM15001
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.

Page 268
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

TIM15001
LIR/LIA = Location Information Request / Answer (Diameter Cx messages)

Page 269
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

TIM15001
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
available in IMS 5.1.

Page 270
VoIP Emergency Services - HSS Method
If the provisioned routing method is

ECSF-HSS:
The E-CSCF queries the HSS over
the Diameter Sh interface to
retrieve the per subscriber ESRN.
The E-CSCF replaces the RequestURI value with the ESRN and
forwards the INVITE message.
The next hop routes to the PSAP
that serves the geographic location
of the caller.
271

TIM15001
The routing method is provisioned in the FS GUI (IMS->IMS Tables->Emergency Application

Services Profile screen, Emergency Session Routing Method = ECSF-HSS
UDR/UDA = User Data Request /Answer
This is an alternative method if fixed subscribers only in the IMS network (that is, not applicable
for nomadic and mobile endpoints.)
.

Page 271
VoIP Emergency Services - VPC Method
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
The E-CSCF queries the VPC using the

NENA i2 V2 interface to retrieve the ESRN.
The E-CSCF replaces the Request-URI
value with the ESRN and forwards the
INVITE message.
The next hop routes to the Public Safety
Answering Point (PSAP) that serves the
geographic location of the caller.
272

TIM15001
The routing method is provisioned in the FS GUI (IMS->IMS Tables->Emergency Aplication

Services Profile screen, Emergency Session Routing Method = VPC
NENA = National Emergency Number Association
The NENA i2 V2 interface is an XML interface, to a VPC to determine the location-based route
to the correct emergency center (PSAP).
The E-CSCF is a sequential stateful SIP proxy server.
From Release 6.1.5 onward, the IEAS/E-CSCF can take the MAC address from the P-AccessNetwork-Info header. This must be provisioned on the IEAS/ECSF profile.
Feature 12203.9 WI 76.511: Enhancement, implemented in IMS 6.1.2, provides for provisioning
a Redundant Voice Positioning Center (VPC) for the IMS Emergency Application Server
(IEAS) component of the IMS network. In case the primary VPC does not respond to ESRN
request, EAS/E-CSCF will query a redundant VPC when the Redundant VPC feature is turned
on. If even the redundant VPC doesnt return the ESRN, the default ESRN provisioned on the
GUI will be used (Default Routing).
The E-CSCF will use the Location Information Element (LIE) as a key to query the VPC if VPC
query is selected. The VPC will then return the ESRN and forwards it to BGCF or next Hop.
The E-CSCF records itself as a record-route.

Page 272
VoIP Emergency Services - Peering Network
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

TIM15001
The routing method is provisioned in the FS GUI (IMS->IMS Tables->Emergency Apllication

Services Profile screen, Emergency Session Routing Method = VPC-V6
The E-CSCF does not need to remain in the call setup path.
Two implementations:
V6 over SIP
V6 over ISUP
E-CSCF Functions when using the V6 interface:
Set the Request-URI to a SIP URI with the user field set to the value from the "DefaultRoute
for v6" field

The host name set to the "Next Hop (provisioned in the FS GUI)
The "user=phone parameter appended
Proprietary "emergency" parameter appended
Send the INVITE with DefaultRoute to the next hop.
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.

Page 273
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

TIM15001
The decisions must be provisioned in the FS GUI, IMS ECSCF Profile: Next Hop Id and EAS
Default Route
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.

Page 274
VoIP Emergency Services - Pseudo-EAS
If the provisioned routing method in

the S-CSCF is HSS:
Based on the iFC, the S-CSCF
contacts the pseudo-EAS.
The pEAS queries the HSS over the
Diameter Cx interface to retrieve the
per subscriber ESRN (ServiceInfo).
The pEAS replaces the Request-URI
value with the ESRN and forwards the
INVITE message.
The next hop routes to the PSAP that
serves the geographic location of the
caller.
275

TIM15001
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.
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.

Page 275
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

TIM15001
The ICID parameter (if present) is in the P-Charging-Vector header.

Note: only ACR (EVENT) messages are sent.

Page 276
Knowledge Check
The E-CSCF terminates VoIP emergency sessions?
This statement is:
A. True
B. False
277

TIM15001

Page 277
Knowledge Check
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

TIM15001

Page 278
Blank Page
279

TIM15001

Page 279
Architectures
Business Trunking
280

TIM15001
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-Network-Interface (NNI) model maps to the interconnect/peering border architecture

Page 280
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)
5060 IP Call Server
281

TIM15001
Alcatel-Lucent Business Trunking solutions

ALU Business Trunking is the ability to connect communication sessions (both media and signaling traffic) between a
Private Branch eXchange (PBX) and a Service Providers NGN/IMS network. The PBXs reside in the customer premise
network, but can be managed either by the enterprise customer or by the IMS service provider. The primary focus of the
ALU IMS Business Trunking solution is to provide public SIP trunking to SIP IP-PBXs. However, the solution does not
preclude other types of PBXs to be connected to the IMS. For non-SIP IP-PBXs, such as H.323 and ISDN PRA/PRI PBXs, an
Interworking Function (IWF) is required that performs protocol interworking between H.323 or ISDN PRI/PRA signaling
and SIP.
Applicable PBXs:
SIP IP-PBX that supports SIP registration
SIP IP-PBX that does not support SIP registration; S/BC performs SIP REGISTER
H.323 IP-PBX can be supported with this solution, but an InterWorking Function (IWF) between H.323 and SIP is required.
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
Page 281
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

TIM15001
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.

Page 282
PBX Support - Wildcard PUID
Allows a contiguous range of iDNs to be represented by a single 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.
In an Implicit Registration Set each wildcard PUID counts as one PUID.
Supported in both the external HSS (USDS) and the internal HSS (iHSS in the ICSSIP shelf).
Most efficient in terms of number of provisioning processes.

Instead of provisioning each individual iDN in the IMS nodes (for instance, HSS and
ENUM database), only the wildcard PUIDs (representing iDN ranges) need to be
provisioned.
283

TIM15001
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.

Page 283
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
Implicit Registration Set

TIM15001

Page 284
Profile
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

TIM15001
Example 1:
+1630979!....!
Note that the wildcarded portion is enclosed in a ! pair
Example 2 : +1630!...!1234 is NOT acceptable.

Example 3: Internally the HSS may store the URI as a tel URL, but it is not necessary to provision. The tel
is prepended when sending the messages with wildcard PUIDs.
Example 5-1: [2-7] means 2, 3, 4, 5, 6 and 7
Example 6:
The wildcard PUID matches 6 distinct PUIDs.
+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:
At least one distinct PUID is contained in an IRS
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)

Page 285
PBX Support - Registration-Based Solution Architecture
struc-IMS-reference-arch_full.PNG
SIP/H.323
PRI/PRA
IP-PBX
ISDN-PBX
286

TIM15001
Proposed in 3GPP as the way to handle PBXs.

S/BC (Acme Packet) may be required to:
Convert H.323 signaling to SIP (H.323 IP-PBX)
Register on behalf of the IP-PBX PUID
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.

Page 286
PBX Support - Registration-Based Solution (= UNI Mode)
Connectivity on access side through the User-Network Interface (UNI):

Corresponds to the access network border architecture
PBX connects to P-CSCF
Calls to and from an IP-PBX over the Gm reference point
Calls to and from an ISDN-PBX require MGCF for ISDN signaling conversion
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

TIM15001
The Registration Based Solution is usually referred to as UNI mode.

The Gm reference point is the 3GPP interface between IMS endpoints and the P-CSCF.
ISDN PBX can be supported with this solution, but requires MGCF to perform TDM-IP Interworking Function
(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.
Solution requires support of wildcard PUIDs that represent the DNs of the PBX endpoints. In the ENUM
database and the HSS (external USDS or iHSS in the 5060 ICS), only the wildcard representation of the PBX
endpoint DNs need to be provisioned (wildcard PUID explained elsewhere).
PBX is treated as an untrusted entity by IMS. In this case, the normal IMS UNI procedures apply. For example,
if a P-Asserted-Identity is received from an untrusted PBX, it will be discarded by the IMS edge server. The
P-CSCF will assert the calling party identity by matching the calling party identity from the P-PreferredIdentity or the From header with a registered identity. (PBX treated as a trusted entity is NOT supported;
this model is NOT defined in 3GPP IMS standards).
It is highly recommended to secure the signaling link between the PBX in the enterprise network and the IMS.
The SIP Connect recommends the use of TLS to secure the signaling communication link. Since TLS is not yet
available, it is recommended to secure the signaling link using IPsec. In the IMS network, the IPsec will be
terminated at the FW.
Provisioning in the feature server determines if all PBX subscribers have the same feature set or not.

Page 287
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:
Each PBX is provisioned with one or more distinct pbxPUIDs.

At least one pbxPUID must be in SIP URI format, which will be used to perform PBX
registration (typically the GDN).
It is assumed that the PBX domain is one of the IMS home domains.
Each PBX is provisioned with one or more wildcard PUIDs.

The wildcard PUIDs represent the ranges of DID/DOD numbers owned by PBX
Individual iDN PUID for DID/DOD extensions also supported.
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

TIM15001
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-
SIP signaling to SIP) can perform SIP registration:
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).
Three variations of PBX registration are supported:

Individual registration (explicit registration): For large PBX very inefficient with respect to the number of
registrations and individual provisioning in the HSS (not shown).

Implicit registration (or sometimes referred to Group Registration): Number of explicit registrations is
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).

Page 288
PBX Support - UNI Mode Origination from IP-PBX
1. IP-PBX endpoint sends an INVITE message, which includes:
The called party number (in the Request-URI)

Its own DID number.
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:
The DID number

The matching wildcard PUID.
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:
The DID number

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

TIM15001
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.

Page 289
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:
The DID number

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

TIM15001
HSS: either external or internal.

Page 290
PBX Support Nonregistration-Based Solution Architecture
struc-IMS-reference-arch_full.PNG
SIP/H.323
IP-PBX
291
PRI/PRA
ISDN-PBX

TIM15001
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).

Page 291
PBX Support Nonregistration-Based Solution (= NNI Mode)
Connectivity on peering side through Network-Network Interface (NNI):

Corresponds to the peering network border architecture
PBX connects to Transit Function (TF)
Calls to and from the IP-PBX through the IBCF
Calls to and from an ISDN-PBX require MGCF for ISDN signaling conversion
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

TIM15001
The Non-Registration Based Solution is usually referred to as NNI mode.

IP-PBX connects to the IBCF over SIPconnect, which is a standard under SIP Forum pushed by SoftSwitch and
IP-PBX vendors. The SIPconnect Technical Recommendation is a standards-based approach for direct IP
interoperability between IP PBXs and VoIP service provider networks.
(http://www.sipforum.org/content/view/274/228/ )
IP-PBX performs endpoint authentication.
ISDN PBX can be supported with this solution, but requires MGCF to perform TDM-IP Interworking Function
(IWF) between ISDN signaling and SIP.
It is highly recommended that IPsec is enabled between an IP-PBX in an enterprise network and the IMS.
Non-registration based mode corresponds loosely to the TISPAN defined Peering Based Business Trunking. Note
that the TISPAN Peering mode implies simple peering or transit routing; the ALU non-registration based
business trunking solution can also offer services for PBX uses using IMS unregistered service profile
invocation capability.
Provisioning in the feature server determines if all PBX subscribers have the same feature set or not.
One limitation of NNI mode is that services that have dependency on registration status can not be offered.

Page 292
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

TIM15001
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
routing in the RTCF profile or Originating-Hosts table.

IP-PBX terminated call can be routed by the S-CSCF if the the IP-PBX is outside the IMS network with explicit
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.

Page 293
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
Per orig-host, RTCF

trigger Cx for CgPN
2. Forward to RCF/DF
RTCFo/ 4. Cx query for CgPN & response

DGCFo
HSS
5. INVITE
Route: sip:scscf@imsdomain;orig
AS
7. unreg
service
S-CSCFo
6. SAR/SAA
Standard termination procedure

294

TIM15001
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.

Page 294
PBX Support - Origination from IP-PBX Steps (NNI Mode)
IP-PBX sends an INVITE (for call origination) to an IBCF.
IBCF directs originating request to RTCF.
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).
Upon successful Cx query, RTCF routes to originating S-CSCF for unregistered

origination service invocation.
S-CSCF contacts AS for unregistered originating services.
Proceed with standard termination procedure.
295

TIM15001
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

Page 295
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
RTCFt/ 4. Cx query for CdPN & response

DGCFt
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

TIM15001
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.

Page 296
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 contacts AS for unregistered terminating services.

AS:
Applies unregistered terminating services (if applicable).

Changes domain name to re-target request to PBX (that is, rewrite R-URI with a
domain name that is owned by the PBX).
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.
IBCF terminates the request to the IP-PBX, based on the R-URI.
297

TIM15001
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.)

Page 297
Architectures
298

TIM15001
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-Network-Interface (NNI) model maps to the interconnect/peering border architecture

See FDD-7349 Business Trunking Solutions for more information on PBX connections.

Page 298
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

TIM15001
A target is a subscriber subject to LI monitoring.
Call Identifying Information (CII) a.k.a. Intercept Related Information (IRI)

Reviewer question: Which is preferred?
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).
The taget intercept mode can be:

CII only, or
CII and CC.

Page 299
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

TIM15001
-
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.

Page 300
References
For more detailed information on these subjects refer to the system
documentation.
LCP Technical Description

Required Control Platform Services
5450 IP Session Control (ISC) Application User Guide

Required Services
Network Services
iAGCF
5450 IP Resource Control (IRC) Application User Guide
Functions
Required Services
Network Services
301

TIM15001

Page 301
Blank Page
302

TIM15001

Page 302
End of Module
303

TIM15001

Page 303
Performing OAM&P

Page 304
Module Objectives
Match the application and task with the appropriate element manager.
305

TIM15001

Page 305
Module Outline
Performing OAM&P
Introduction
User Interfaces
Element Manager
306

TIM15001

Page 306
Blank Page
307

TIM15001

Page 307
Performing OAM&P
Introduction
308

TIM15001

Page 308
Performing OAM&P - Introduction

OAM&P Tasks
OAM&P tasks are carried
out in the OAM&P domain.
309

TIM15001

Page 309

Examples of FCAPS Tasks
Provision platform infrastructure

Provision subscriber data
Provision system data
Respond to system alarms
Manage measurement jobs
Collect operational data
Administer user accounts
310
Configuration
Configuration
Configuration
Fault
Performance
Performance
Security
Management
Common FCAPS tasks include:

TIM15001
Respond to system alarms in order to solve system problems and/or to do troubleshooting.

Collect operational data in order to collect statistical information and traffic measurements.
Administer user accounts refers to the maintenance personnel who must have access on the the management
systems. Put separately to indicate it is not really a task that maintenance personnel would perform, but
more a person in the network administration.
Accounting management is NOT addressed in this lesson, because there are hardly any tasks to be performed
by the maintenance personnel besides initial provisioning (which is actually CM). However, if any question
are asked, the CDR service may be involved, because it can collect and correlate the charging info for IMS
nodes to be sent to the CCF. In the case of the Compact Model, the CDR service also supports the local CCF
function, which creates ASN.1 CDR to be sent to a billing system.

Page 310

Element Managers
Management tasks are carried out
using:
1310 OMC-P (Operations &

Maintenance Center-Plus) through
its private GUI
MI server through the MI GUI
CNFG server through the
Provisioning GUI (formerly known as
the FS GUI).
Command Line Interface (CLI)
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

TIM15001
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.
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).

Page 311
Performing OAM&P
User Interfaces
312

TIM15001

Page 312
Performing OAM&P - User Interfaces

Provisioning GUI
Menu bar
313
Toolbar

TIM15001
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.

Page 313

Provisioning GUI (continued)
314

TIM15001
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.

Page 314

MI GUI
Menu bar
Toolbar
Tree view
Map view
Alarm
Summary
view
Status bar
315

TIM15001
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

Page 315

MI GUI Fault Management
316

TIM15001
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.

Page 316

MI GUI Performance Management
317

TIM15001

Page 317

MI GUI Cut-through
The MI GUI has the capability to invoke:
A Telnet session to open a command line interface (CLI)

An FTP session to enable file transfer
The Provisioning GUI (aka the FS GUI) on the CNFG server.
318

TIM15001
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.

Page 318

MI GUI Cut-trough: Telnet to Host
Right-click a service
A context menu appears
319

TIM15001

Page 319

MI GUI Cut-trough: Provisioning GUI
Right-click the CNFG
service
A context menu appears;

click Provisioning GUI
The Provisioning GUI

is invoked
320

TIM15001
Provisioning GUI = Native EMS = FS GUI

Screenshots are not the correct ones, need to be replaced. For Lucent CP CM no cut trough to FS GUI possible
Select from the MI-Agent, the virtual CNFG service, right click the element and select Native EMS from the
pull down menu. The FS GUI will open.

Page 320

1310 OMC-P GUI
Menu bar
Toolbar
Status tab
Status pane
Resize tool
321

TIM15001
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
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.

Page 321

1310 OMC-P GUI CM Managed Object Provisioning
322

TIM15001
Select a network element, select view form the Action pull down menu. The configuration window will open.

Page 322

1310 OMC-P GUI CM - Subscriber Provisioning
323

TIM15001
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.
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.

Page 323
Performing OAM&P
Element Managers
324

TIM15001

Page 324
Performing OAM&P - Element Managers

CNFG Server Characteristics
Key characteristics are:
Used to perform CM for the provisioning of the LCP infrastructure

(except for the 5420 CTS subscriber data)
Collects and stores alarms and events from the LCP applications and
sends them to the MI server
Collects traffic measurements from the LCP applications and sends
them to the MI server
User interface is the Provisioning GUI; the software consists of:
GUI server residing on the CNFG server and
GUI clients residing on multiple maintenance terminals
Resides on a redundant card pair.
325

TIM15001

Page 325

MI Server Characteristics
Provides the primary point of contact to perform FM and PM locally for

an LCP
Deployed for each LCP
Resides on a redundant card pair in the LCP
User interface is the web-enabled MI GUI executed on multiple
maintenance terminals
Cut-through to the Provisioning GUI and command line interfaces of the
administrative processor on the cards in the LCP
Provides a single interface to northbound systems.
326

TIM15001
Cut-trough is typically used for for low-level configuration management and operational tasks

Page 326

1310 OMC-P Characteristics
Provides the primary interface for and FM and PM (fault and

measurements reporting, if no other management system is in place),
and CM (infrastructure provisioning)
In addition, also supports subscriber provisioning for the 5420 CTS, the
5420 Personal Communications Manager, and the iHSS
Provides a web-based client-server GUI architecture
Supports standard northbound interfaces.
327

TIM15001
5420 CTS provisioning is carried out by running the base_cfg.sh script.

Page 327

Summary
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

TIM15001

Page 328
Performing OAM&P
Knowledge Check
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

TIM15001

Page 329
Performing OAM&P
Knowledge Check
Which tasks are performed using the MI : (More than one answer may
apply)
A.
B.
C.
D.
E.
Fault management
Accounting management
Security management.
330

TIM15001

Page 330
Performing OAM&P
Module Summary
This module covered the following topics:
The OAM&P tasks

Element Managers
User Interfaces
331

TIM15001

Page 331
Performing OAM&P
References
For more detailed information on these subjects refer to the system documentation.
5400 LCP User Interface

5400 User Interfaces and CLI
MI GUI
Provisioning GUI
IP Call server Solution Operations, Administration, Maintenance & Provisioning OAM&P
332

TIM15001

Page 332
End of Module
Performing OAM&P
333

TIM15001

Page 333
Customer Documentation

Page 334
Module Objectives
Match a task, description, concepts with the correct customer manual.
335

TIM15001

Page 335
Module outline
Available Application Documents
Digit codes of manuals
336

TIM15001

Page 336
Available Platform manuals
The Customer Documentation set consists of a great number of manual. It

can be divided into:
Platform documentation
Application documentation
337

TIM15001
Available documentation on the MI-Agent:

SP, TD and Configuration DB XML Specification currently not available

Page 337
Platform Documentation 5400 LCP
Manual Name
Alarm Dictionary
Alarm Management
Configuration Database Interface Specification and Object Descriptions
Hardware Corrective Maintenance
Hardware Description
Hardware Preventive Maintenance
Log Management
Observation Counters dictionary
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

TIM15001

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.

Page 338
Application Manuals
Manual Number
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
5420 Converged Telephony Server (CTS) Product Description

5450 IP Resource Control Application User Guide
5450 IP Session Control Application User Guide
IP Call server Solution Operations, Administration, Maintenance &
Provisioning
IP Call Server Solution Technical Description
339
275-900-367
275-900-362
275-900-361
270-310-101
270-310-100

TIM15001

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.

Page 339
HTML Version
340

TIM15001
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.

Page 340
HTML Version
Solution and version
Libraries
Content
Fast access buttons for:

Search, Library, Book Map,
Comments and Glossary
341

TIM15001
From the manual set overview, select the html version of a manual. A internet browser will open with the
selected manual.

Page 341
HTML On-line Search Function
Search for NGSS
All
books search
342

TIM15001
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.

Page 342
PDF Version
Solution and version
Libraries
343
Content

TIM15001
From the manual set overview, select the pfd version of a manual. Acrobat reader will open the manual.

Page 343
Knowledge Check
Name the document that describes the alarm clearance procedures:
A.
B.
C.
D.
Command Line Interface

Object Description
User Interface
Operation, Administration, Maintenance and Procedures
344

TIM15001

Page 344
OMC-P Documentation
345

TIM15001
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.

Page 345
Module Summary

Available Applications Documents
Digit Codes of manuals
346

TIM15001

Page 346
End of Module
Documentation
347

TIM15001

Page 347
Hardware Overview

Page 348
Module Objectives
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

TIM15001

Page 349
Module outline
Hardware Overview
Advanced Telecommunications
Computing Architecture (ATCA)
Applications on the ATCA
Platform
ATCA Hardware
350

TIM15001

Page 350
Blank Page
351

TIM15001

Page 351
Hardware Overview
Advanced Telecommunications Computing

Architecture (ATCA)
352

TIM15001

Page 352
Hardware Overview ATCA

Specifications
Advanced Telecommunications
Computing Architecture (ATCA or
Advanced TCA) is an open
architecture.
ATCA is designed to meet requirements
of operators, to provide them with
next generation of communication
equipment.
The specifications include:
Latest trends in high speed
interconnect technologies
Next generation processors
Improved Reliability, Availability and
Serviceability (RAS).
353

TIM15001
Advanced Telecommunications Computing Architecture.

At the end of 2001 a group of industrials known as PCI Industrial Computer Manufacturing Group (PCIMG)
defined an open standard, known as
Advanced Telecommunications Computing Architecture (ATCA or AdvancedTCA).
More than 450 companies are participating in the PCIMG.
ATCA is a set of standards special designed for telecommunications.
One of the main goals is to eliminate proprietary communications ports specifications.
ATCA is defined to meet requirements for the next generation of "carrier grade" communications equipment,

Page 353

Physical Description
The ATCA Shelf:
14 Slots for Blades
Open interface to rear
2 dedicated Slots for shelf

management facilities
Front View
354

TIM15001
Front view of the ATCA Shelf

For the 19 cabinet a total of 14 slots for Blades
Open interface to the rear hardware providers are free to define this interface.

Page 354

ATCA Connector Zones
Side view
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

TIM15001
The architecture is divided in three zones.

The mid-plane provide interconnections between the circuit boards, and the management card, and has two
zones:
Zone 1:
Redundant -48V dual power feed
metallic test,
ringing generator
Management system connections
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).

Page 355
Hardware Overview
356

TIM15001

Page 356
Hardware Overview - Applications on the ATCA Platform

LCP Applications
ATCA hardware platform hosts the 5400 LCP (Linux Control Platform)
software platform, which provides the following applications:
5450 ISC (IP Session Control)
5450 IRC (IP Recourse Control)
5420 CTS (Converged Telephony Server)
357

TIM15001
Alcatel-Lucent develops IMS application on the ATCA platform

5400 ALCP:
This only states the applications that run on the ATCA platform, other lesson cover in-depth information of
the applications.
5420 ISC:
The IMS core functions that run on the ATCA platform: S-CSCF, I-CSCF, P-CSCF, E-CSCF and BGCF
Additional functions: PDFE, DCF, RCF and IBCF.
5420 IRC:
Quality of Service, Resource Control, Charging Correlation, Flow-based Charging, Network address translation
and Network Port Translation, Firewall Control and Gating Control
5450 CTS:
TAS, Providing Supplementary Services and Digit Manipulation
The 5060 ICS (IP Communications Server) is a one shelf version.

The 5060 ICS supports up to 400k subscribers in a single shelf, with up to 1-1.5M subscribers planned for in the
next releases.
The following applications are in the 5060 ICS:
IMS Core, AGCF and MGCF
Page 357
Hardware Overview
ATCA Hardware
358

TIM15001

Page 358
Hardware Overview - ATCA Hardware

Cabinet Layout
Power Distribution Unit

(PDU)
ATCA Shelfs
Heigth: 1800 mm
(2 ATCA Shelfs)
359
Cabinet dimensions:
Width : 485 mm (19)
Depth : 600 mm
Heigth: 2100 mm
(3 ATCA Shelfs)

TIM15001
The cabinet is 19, 600mm depth cabinet, with two heights:

1800mm able to host up to 2 ATCA shelves.
2100mm able to host up to 3 ATCA shelves.
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.

Page 359

Shelf Hardware
Upper fan tray
14 slot rack-mount
Shelf Management
Card slots
Lower fan tray
360

TIM15001
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.
<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.

5400 LCP Field Replaceable Units - Shelf Card Positions
2 x 6 slots for
processor/application
cards (nodes)
First 2 diskful
processor/
application cards
(nodes)
Always in first 2
slots
Dual Shelf
Management
Cards
Dedicated ethernet switch

cards (hubs)
361

TIM15001
ATCA blades can be Processors, Switches, AMC carriers.

At the rear a Rear Transition Module can be placed, for additional connections.
Minimum configuration one shelf consist of:
Two blades with disks
Two blades without disks.
Two switch cards
Two 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).

Page 361

Processor/Application card (node)
2 AMC slots
for PCI Express and
Storage
Processor Blade (NBRZxx):

Single
processor
Actual
processor blade to host

the LCP services.
Hardware
variant depends on the

blades function:
6 1000Base T Ethernet
links
Diskfull - equipped with 2

additional hard disk cards in AMC
(Advanced Mezzanine Card) slots
Diskless no additional hard disk
cards
Debug USB port
Hot Swap
362

TIM15001
ATCA Single Board Computer blade (NBRZxx)

For the single board computer blades (NBRZxx) the xx is used for specific configurations, like single or dual
hard disk and the amount of memory.
Consisting of the following hardware:
One Dual core processor 32/64-bit operation,
Up to 8GB memory
2x 1GigE ports to CPU
USB2.0
RS-232 console port for debugging, via mini-USB
boot options
HDD, USB
IDE flash
TFTP
Embedded 1GigE switch:

Full 1GigE connectivity to backplane, 1GigE to each AMC slot, 2x 1GigE to CPU, 4x 1GigE external

Page 362

Processor/Application Card (Node) Functions
Diskfull:
Diskless:
OAM
5450
ISC
5450
IRC
5420
CTS
Server
Management Interface
Configuration Server
Feature
Server Database
CTS subscriber data

iAGCF subscriber Database
iAGCF
iHSS
iCCF
363

TIM15001
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

Page 363

AMC Types
AMC types:
Hard
disk:
73 GB
147 GB
Interface:
4-port E1/T1/J1 for front panel access on Blade

8-port E1/T1/J1 for rear panel access on RTM
364

TIM15001
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
When a blade has a HD then this blade is called diskful blade

When a Blade has no HD then this Blade is called diskless blade
Interface:
4-port E1/T1/J1 for front panel access on Blade
8-port E1/T1/J1 for rear panel access on RTM

Page 364

Ethernet Switch Blade (Hub)
2 AMC Slots
for PCI Express and
Storage
Switch Blade (NBMASW1):
Internal Data Fabric Switch

interconnects blades in the shelf
Uses 12 x 2 1Gigabit Ethernet

interfaces (2 GigE links per slot)
4 1000Base T Ethernet
links
Debug USB port
Debug Fast Ethernet port
10GE electrical interface
365

TIM15001
ATCA switch blade (NBMASW1)

Ethernet Hubs for internal communications, consisting of the following hardware:
Single Board Computer in Switch-Only mode (NBMASW1), fixed position slot 7 and 8
1x Dual Core Intel T7400 processor running at 2.16GHz with 1GB of memory
Dual star Ethernet switching fabric with 24x Gigabit Ethernet interfaces providing the fabric interface to 12
Blades with 2x GigE links per slot.

4x 1000Base-T Ethernet links to the Base Interface on front panel
1x 10GE interface connected to the Base Interface on front panel (for daisy-chaining between switches in
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.

Page 365

Shelf Management Controller
Shelf management card
(NBSHMC):
Active/Standby
Redundant pair of cards share

1 slot in ACT/STBY
SNMP communication to/from
Blade over Ethernet
Low level card
communications via
redundant I2C Buses
Monitors presence and health
of all Blades and chassis
elements
Monitors environment of
chassis (temperature, fans,
voltage, etc.).
366
Power OK
Debug Fast Ethernet port
Debug IC and RS232
Fast Ethernet status
Hot Swap

TIM15001
ATCA shelf manager card (NBSHMC)

The shelf management controllers are positioned in the shelf management slot and are numbered 1 on the top
to 2 on the Bottom.
The shelf manager monitors and controls the blades and the Units on the blade.
When a sensor detects an event it reports the problem. The shelf manager can take action and report the
problem to an element or network manager.
One of the actions the management controller can take, could be change the rotation speed of the fans, or
more drastic such as powering off a blade.

Page 366

Power Distribution Unit
Fuses
Circuit breakers
Power Bus A
Circuit Breakers
Power Bus B
7 LED
Alarm panel
367

TIM15001
The PDU is placed in top of the cabinet.

Providing redundant -48V power to the shelf's in the cabinet.
To power an ATCA shelf two circuit breakers are used A power bus and B power bus.
The circuit breaker can range from 10 to 80 Ampere depending of the load.
To connect additional equipment in the cabinet there are 2 X 5 fuses range from 1 to 15 Ampere.
An included alarm card (RALARMAA) can present:
6 system alarms (critical, major and minor, each audible and visible)
2x 48V loop external alarms 48V supervision
6 LEDs on the PDU face-plate for critical, major and minor alarms
ACO and 48VA/48VB presence

Page 367

Knowledge Check
Which of the following functions run on a diskless blade?
(More than one answer may be correct.)
A.
B.
C.
D.
CTS
ISC
iAGCF
368

TIM15001

Page 368

Knowledge Check
The Switch Cards are always located in the first two slots.
This statement is:
A. True
B. False
369

TIM15001

Page 369
Hardware Overview
Module Summary
Advanced Telecommunications Computing Architecture

Cabinet and shelf
Shelf components
Functions and their location
370

TIM15001

Page 370
End of Module
Hardware Overview
371

TIM15001

Page 371
Charging

Page 372
Module Objectives
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

TIM15001

Page 373
Module Outline
Charging
iCCF (5060 ICS only)
ACR Buffering Function (5060
ICS only)
Metering Service (5060 ICS only)
374

TIM15001

Page 374
Blank Page
375

TIM15001

Page 375
Charging
iCCF
376

TIM15001

Page 376
Charging - iCCF
Functions
The internal CCF performs the
following functions:
Collects
Accounting Request (ACR)

messages containing charging
information from the 5420 CTS
Correlates
the ACR messages
Generates
ASN.1-formatted IMS CDRs
Stores
the CDRs on the internal disk
Transfers
center.
the CDR files to a billing
377

TIM15001
The iCCF only supports offline charging.

Additional info:
Offline Charging Interfaces
- Charging information is mainly collected after the session
- A user typically receives a bill on a monthly basis
For more information on correlation of ACR messages refer to slide Example of charging collection.

Page 377
Charging - iCCF
Charging Collection
The iCCF only collects ACR
messages from the 5420 CTS.
378

TIM15001
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.

Page 378
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
The iCCF returns an ACA message to the

5420 CTS
The iCCF processes the ACR messages for
the whole SIP dialog
The iCCF creates ASN.1-formatted CDRs,
which are stored in log files on disk.
The log files CDR are transferred to a
billing center at regular intervals.
379

TIM15001
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.

Page 379
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

TIM15001
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
billing center via the Bi Interface.

2. If Bellcore AMA format (BAF) IS required by the operator: The records can be pushed to the BTS via the
Generating System to Data Server Interface (GDI)

The BTS converts the records to BAF and transfers them to the Billing Center via AMADNS. AMADNS =
Automatic Message Accounting Data Networking System
In both cases ASN.1 CDR format, using Basic Encoding Rules (BER), is used.
Additional info
If the operator wants to use GDI,on the CDR system configuration screen GDI selection must be set to yes.

Page 380
Blank Page
381

TIM15001

Page 381
Charging
ACR Buffering Function (ABF)
382

TIM15001

Page 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

TIM15001
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).

Page 383
Charging - ABF
Architecture
Prim
f
CR/R
ary A
Billing Mediation Device

(BMD)
CDF
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
IeCCF or other Element
BMD

TIM15001
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

Page 384
Blank Page
385

TIM15001

Page 385
Charging
Metering Service
386

TIM15001

Page 386
Charging - Metering Service

Introduction to Metering Service
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.
Metering service is supported to payphones in the following 5060 ICS

configurations:
POTS lines connected to an H.248-based AGW controlled by an iAGCF
POTS lines connected to a SIP-based VGW.
When the metering service is assigned to a subscriber, charge rate information

is provided:
At call establishment (in 200 OK response message on initial INVITE request).
During a call, if the charge rate is changed (in INFO request message).
387

TIM15001

Page 387

Integrated Charge Rate Function
The integrated Charge Rate Function (iCRF) determines the charge rate at the
request of a CTS.
The iCRF is implemented as an internal function of the CTS.
The iCRF maintains an internal non-signaling based interface.
The charge rate is based on:
Diameter-like with Ro interface primitives CCR/CCA (Credit Control Request/Answer)
The identity of the originating user (call type)

The call destination
Rate category of the user (usually associated with the rate area)
Dialed digits
Time dependencies (Day of the Week/Time of Day/exception days)
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

TIM15001
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

Page 388

Metering Service Architecture
1. The CTS requests the charge rate from

the iCRF for a particular call from a
payphone.
2. The CTS provides the charge rate
information to an AGCF/AGW or a VGW
that interfaces to payphones.
5450 ISC
3. Based on the provided charge rate

information, the AGW or VGW generates
pulses and bursts to the payphone.
Notes:
a) The H.248 interface must support
H.248.26 automatic metering package.
b) The SIP interfaces must be enhanced for
supporting charge rate-related
information.
389
iCRF
5420 CTS
Serving
CSCF
2
Internal
AGCF
Proxy
CSCF
AGW
VGW
3
Payphones

TIM15001
Interface requirements:
P1 interface (H.248-based interface between iAGCF and AGW), must support H.248.26 (automatic metering
package) for controlling generation of metering pulses.

SIP interfaces (ISC to AS, Mw to iAGCF, and Gm to P-CSCF) with enhancements defined in both ETSI TS 183
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
for a given call.

Page 389

Message Flow for charge rate-based Metering service for payphone
iAGCF/AGW
Or
VGW
5420 CTS
iCRF
Next hop
Call set-up request received from payphone

INVITE (SDP offer)
iCRF function call
INVITE (SDP offer)
Charge rate in CCA return parameter
180 Ringing
180 Ringing
200 OK INVITE (multipart MIME)

Initiates pulse metering to payphone
ACK
ACK
When timer expires, CTS sends
another request to the iCRF.
iCRF function call
Charge rate in CCA return parameter
INFO (metering-XML)
Update pulse metering to payphone

200 OK INFO
390

TIM15001
The Metering-XML may be included in the 200 OK message or INFO message.

If the 200 OK message already contains a SDP body, the Metering service will convert the body into a multipart MIME body,
with both the existing SDP body (the content will not be changed by Metering service) and Metering XML body included.
Once the call is confirmed, any further Metering XML will be transported through INFO messages. Since the INFO message
is special for the Metering-XML, only an XML body is included in the message.
The format of the single body and multipart body is shown as follows:
If there is no other content in the body:
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

Page 390

Metering Service Limitations
Applies only to call originations by ICS subscribers.
Only sessions initiated by an initial SIP INVITE request.

Any other standalone transaction will not trigger the metering service.
No support for charging information generated by external elements

(for example PSTN).
Only supports the generation of metering pulses to convey the charge

rate information to POTS payphones; no generation of display
information.
391

TIM15001
Generation of display information would be applicable to advice of charge (AoC).

Page 391
Charging
Module Summary
This module covered the following topics:
iCCF
iCRF and metering service
392

TIM15001

Page 392
End of Module
Charging
393

TIM15001

Page 393
Abbreviations and Acronyms

Page 394

#
3GPP
3GPP2
5450 ISC
5450 IRC
5420 CTS
Third-Generation Partnership Project

Third-Generation Partnership Project 2
5450 IP Session Control
5450 IP Resource Control
A
AAA
AB
ACB
ACC
ACG
ACR
AKA
ALCP
ALMRS
ALNC
ALNG
ALSM
AMADNS
AR
AS
ASDA
ATCA
ATA
AUTN
AVP
AXAS
Authentication, Authorization, Accounting

Alarm Board
Automatic Call Back
Automatic Call Control
Automatic Code Gapping
ACcounting Request
Authentication and Key Agreement
Alcatel-Lucent Control Platform
Alcatel-Lucent Multimedia Resource Server
Alcatel-Lucent Network Controller
Alcatel-Lucent Network Gateway
Alcatel-Lucent Session Manager
Automatic Message Accounting Data Networking System
Automatic Recall
Application Server
Application Server Database Access
Advanced Telecommunications Computing Architecture
Analog Telephone Adapter
AUThenticatioN
Attribute Value Pair
Address eXchange Application Server
B
B2BUA
BAF
BER
BER
BGCF
BMD
BS
BTS
Back-to-Back User Agent

Bellcore AMA Format
Basic Encoding Rules
Bit Error Rate
Billing Mediation Platform
Billing System
Billing and Traffic System
C
CCF
CDR
CDR
CD-ROM
CF
CFB
CFNA
CFNR
CFV
CH
CK
CK
CLF
Charging Collection Function

Charging Data Record
Call Detail Record
Compact Disk - Read Only Memory
Call Forwarding
Call Forwarding on Busy
Call Forwarding No Answer
Call Forwarding No Reply
Call Forwarding Variable
Call Hold
Cyphering Key
Confidentiality Key
Connectivity Session Location and Repository Function
395
CLI
CLIP
CLIR
CLIRO
CMM
CNFG
CNIP
CNIR
CPI
cPSB
CPU
CS
CSCF
CT
CWT
Command Line Interface

Calling Line Identification Presentation
Calling Line Identification Restriction
Calling Line Identification Restriction Override
Chassis Management Module
CoNFiGuration Host
Calling Name Identification Presentation
Calling Name Identification Restriction
Component Performance Indicator
compact PCI Packet Switched Backplane
Central Processing Unit
Call Server
Call Session Control Function
Call Transfer
Call WaiTing
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
Emergency Call Session Control Function

Ethernet Switch Card
Emergency Services Gateway
Encapsulating Security Payload
External Security Password
Emergency Service Routing Number
F
FCAPS
FLIP
FQDN
FRU
FS
FS 5000
FTP
Fault, Configuration, Accounting,

Performance, Security management
FLoating IP address
Fully Qualified Domain Name
Field Replaceable Unit
Feature Server
Feature Server 5000
File Transfer Protocol
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

TIM15001

Page 395

H
HOAS
HSS
HandOver Application Server

Home Subscriber Server
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
Internal Access Gateway Control Function

Internal Home Subscriber Server
Integrated Access Device
Initial Address Message
IMS Charging IDentifier
Interrogating Call Session Control Function
Integrity Key
IP Multimedia
Instant Messaging
IP Multimedia Private Identity
IP Multimedia Subsystem
International Mobile Subscriber Identity
Internet Protocol
Internet Protocol Device Control
Intelligent Platform Management Bus
Intelligent Platform Management Interface
Internet Protocol Security
Implicit Registration Set
IP multimedia Service Control
Integrated Services Digital Network
IMS Subscriber Identity Module
InterWorking Function
J
K
L
LAG
LAG
LCML
LM
LMT
LRF
LSS
Link Aggregation Group

Line Access Gateway
LSS Configuration Markup Language
Local Monitor
Local Maintenance Terminal
Location Routing Function
Lucent SoftSwitch
M
MAA
MAP
MAR
MB
MGCF
MGCP
MGW
MI
Multimedia-Authentication-Answer
Mobile Application Part
Multimedia-Authentication-Request
MegaByte
Media Gateway Control Protocol
Media GateWay
396
MMPI
MRFC
MRFP
MSRP
MTP
Machine-to-Machine Provisioning Interface

Multimedia Resource Function Controller
Media Resource Function Processor
Message Session Relay Protocol
Message Transfer Part
N
NANPA
NAPTR
NASS
NE
NEL
NENA
NID
NGSS
NML
NMS
NSS
NTP
NTP
North-American Numbering Plan Administrator

Naming Authority PoinTeR
Network Attachment Subsystem
Network Element
Network Element Layer
National Emergency Number Association
Namespace Identifier
Next-Generation SIP Server
Network Management Layer
Network Management System
Namspace Specify String
Network Time Protocol
Non-Trouble clearing Procedure
O
OAM&P
OLC
OMC-CN
OMC-P
OOS
OPER
OSA
OSS
Operations, Administration, Maintenance & Provisioning

OverLoad Control
Operations Maintenance Center - Core Network
Operation and Maintenance Center-Plexview
Out Of Service
OPERational
Open Service Architecture
Operations Support System
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

TIM15001

Page 396

Q
QoS
Quality of Service
R
RAM
RAND
RAS
RCC
REL
REM
RES
RPC
RPC
RRQ
RTA
RTP
RTR
Random Access Memory

RANDom challenge
Remote Access Server
Reliable Cluster Computing
Release message
Redundancy Manager
RESponse
Ring Peripheral Controller
Remote Procedure Call
Registration ReQuest message
Registration-Termination-Answer
Real-time Transport Protocol
Registration-Termination-Request
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
Session Border Controller

Security Association
Server-Assignment -Answer
Shelf Alarm Card
Synchronous-to-Asynchronous Converter
Server-Assignment-Request
Service Broker
Service Capability Interaction Manager
Service Control Point
Serving Call Session Control Function
Super Distributed Home Location Register
Session Description Protocol
Signaling Compression
Software Installation Manager
Session Initiation Protocol
Session Manager
Shelf Management Card
Simplified Message Desk Interface
Sub-Network Element
Sub-Network Element Layer
Simple Network Management Protocol
Service Point Trigger
Signaling System No 7
SoftSwitch Data Access Manager
Service Switching Point
Softswitch Server Platform
System Status Panel
Subscriber Telephony Application Server
Synchronous Transport Mode
Subscriber DataBase
397
T
TAS
TCP
TDM
TISPAN
TMN
TS
TS
U
UA
UDP
UE
uMGW
UMTS
UNEQ
URI
URN
USIM
UTC
Telephony Application Server

Transmission Control Protocol
Time Division Multiplexing
Telecmmunications and Internet converged Services and
Protocolfor Advanced Networking
Telecommunication Management Network
Technical Specification
Terminal Server
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
Extensible Markup Language

eXpected authentication RESponse
Y
Z

TIM15001

Page 397
Blank Page
398

TIM15001

Page 398
All rights reserved Alcatel-Lucent 2007

Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent
Page 399

TIM15001 R2.0 VU TEN I1 Student Guide

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

TIM15001 R2.0 VU TEN I1 Student Guide

Hochgeladen von

Copyright:

Verfügbare Formate

Do not delete this graphic elements in here:

5060 IP Call Server (ICS)

All Rights Reserved Alcatel-Lucent 2010

All rights reserved Alcatel-Lucent 2008

All Rights Reserved Alcatel-Lucent 2007

Call (800) 438 7911 (within the U.S.A.)

The type of equipment on which you are running the courseware

All Rights Reserved Alcatel-Lucent 2010

5060 ICS 2.0 Overview

All Rights Reserved Alcatel-Lucent 2007

Terms of Use and Legal Notices

All Rights Reserved Alcatel-Lucent 2010

5060 ICS 2.0 Overview

All Rights Reserved Alcatel-Lucent 2007

Terms of Use and Legal Notices [cont.]

All Rights Reserved Alcatel-Lucent 2010

5060 ICS 2.0 Overview

All Rights Reserved Alcatel-Lucent 2007

Terms of Use and Legal Notices [cont.]

All Rights Reserved Alcatel-Lucent 2010

5060 ICS 2.0 Overview

All Rights Reserved Alcatel-Lucent 2007

Terms of Use and Legal Notices [cont.]

All Rights Reserved Alcatel-Lucent 2010

5060 ICS 2.0 Overview

All Rights Reserved Alcatel-Lucent 2007

5060 ICS 2.0 Overview

All Rights Reserved Alcatel-Lucent 2007

About this Course

5060 ICS 2.0 Overview

All Rights Reserved Alcatel-Lucent 2007

All Rights Reserved Alcatel-Lucent 2010

5060 ICS 2.0 Overview

All Rights Reserved Alcatel-Lucent 2007

All Rights Reserved Alcatel-Lucent 2010

5060 ICS 2.0 Overview

All Rights Reserved Alcatel-Lucent 2007

All Rights Reserved Alcatel-Lucent 2010

5060 ICS 2.0 Overview

All Rights Reserved Alcatel-Lucent 2007

This page is intentionally left blank

All Rights Reserved Alcatel-Lucent 2010

5060 ICS 2.0 Overview

All Rights Reserved Alcatel-Lucent 2007

Do not delete this graphic elements in here:

All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2007

All Rights Reserved Alcatel-Lucent 2010

5060 ICS 2.0 Overview

All Rights Reserved Alcatel-Lucent 2007

All Rights Reserved Alcatel-Lucent 2010

5060 ICS 2.0 Overview

All Rights Reserved Alcatel-Lucent 2007

This page is intentionally left blank

All Rights Reserved Alcatel-Lucent 2010

5060 ICS 2.0 Overview

All Rights Reserved Alcatel-Lucent 2007

All Rights Reserved Alcatel-Lucent 2010

5060 ICS 2.0 Overview

All Rights Reserved Alcatel-Lucent 2007

Applications Overview Introduction

All Rights Reserved Alcatel-Lucent 2010

5060 ICS 2.0 Overview

All Rights Reserved Alcatel-Lucent 2007