mobile systems m - unibo.itlia.disi.unibo.it/courses/sm1617-info/lucidi/06-discovery(1x).pdf ·...

Discovery and Session – Mobile Systems M 1 1

Mobile Systems M

Alma Mater Studiorum – University of Bologna

CdS Laurea Magistrale (MSc) in

Computer Science Engineering

Mobile Systems M course (8 ECTS) II Term – Academic Year 2016/2017

06 – Service Discovery and Session

Management in Converged Mobile Systems

Instructor: Paolo Bellavista

[email protected]

http://lia.disi.unibo.it/Courses/sm1617-info/

http://lia.disi.unibo.it/Staff/PaoloBellavista/

mailto:[email protected]






Discovery and Session – Mobile Systems M

Agenda for the next few Weeks

Now that some models and solution patterns have been clarified, let’s see how they are applied to some support mechanisms and tools, which can be included in the large definition we gave about mobile middleware

Some central features of mobile middleware:

Data synchronization (SyncML, …)

Resource/service discovery (Jini, SLP, UPnP, …)

Session management (SIP, IMS, …)

Mobile messaging

Event management (OMG DDS, …)

And advanced features such as:

Sharing of info/resources in smart spaces, spontaneous networks, …

Context aggregation&fusion in large-scale Cyber Physical Systems, FuturICT (http://futurict.inn.ac/), …

2


Resource/Service Discovery

Sometimes the term is used in a broad sense to indicate both the “real”

discovery and also the configuration operations needed to access

resources/services, as well as the resource/service requests

themselves

Key support features for any open, dynamic, loosely

coupled, and peer-to-peer system:

Automated configuration

Discovery of resources and services

Resource/service delivery

Main discovery standards and solutions:

Jini, Service Location Protocol (SLP), Universal Plug and Play

(UPnP), …

3


Key Features

Auto-configuration Device have to configure themselves to participate to

offering/requesting resources and services For instance, but not only, configuration of a temporary IP address in the

current locality

Discovery of available resources and services

Who offers resources and services (service provider) has to be able to make advertising of them Of which resources and services

Of how to make invocations, via which interfaces

Clients have to be able to find (local) resources and services

Access to resources and services

Clients have to be able to communicate with service provider, invoke services, transfer input parameters, and possibly receive return results

Also support to authentication and authorization

Relevance of achieving good reliability and scalability

4


Jini (Sun Microsystem, now Apache River)

Service Broker

Service Provider

Java Service

Object

Service

Attributes

Client

Java Service

Proxy Object

Java Service

Proxy Object

Service

Attributes

Registration

Lookup

5


Most relevant discovery solution for the Java world

Service provider dynamically discovers one or more

lookup services (broker)

Service provider registers a resource/service object

(modeled as Java object) and its attributes to the broker

Client requests a service, typically by specifying

attributes of the looked-for service; one instance of object

to simplify resource/service access moves to client at runtime

Lookup service can notify registered clients when

there is state change for their resources and services

Client interacts with discovered resource/service via

obtained Java object

Apache River

6


Reliability Management in River

Possible failures (and not only, see versioning) are managed through lease mechanism River assigns resources to clients with lease of given time

duration (less or equal to what requested by client)

Once terminated the lease interval, client has to re-fresh lease in order to continue accessing the resource/service

Also lookup registration is made with lease: therefore, all leases have an expiration deadline, for any user, in the case of “long” service provider fault

River supports redundancy at the infrastructure level and resiliency against faults Possible to deploy several lookup services in the same

network

Service providers can register their proxy objects in multiple lookup services

Also usage within transactions and automated rollback when lease expires

7


Scalability in Apache River

Scalability realized via dynamic organization in

“communities” or “federations”

Groups of River resources/services can aggregate into a

community, typically the one of local services registered at least

in a local lookup service

Different communities can be linked together in larger groups

through lookup service

One community registers itself at other communities by

registering its own lookup service

How to manage the nesting of lookup services?

8


Service Proxy Object

in River is Dynamic

If compared with more traditional solutions for resource/service access, anyway retrieved dynamically via intermediate stubs and skeletons:

River overcomes limitations of stub/skeleton creation at compile-time, which is for example typical of RPC

River allow to clients to obtain service provider stubs at provisioning time

RPS stubs are similar to service proxy object that the River server dynamically loads in the lookup service

Service proxy object allows clients to use the discovered service with NO a priori knowledge of its implementation details

9


Service Location Protocol (SLP)

SLP is the standard

approach of Internet

Engineering Task

Force (IETF) for

resource/service

discovery

Basic idea: SLP makes

resources/services

visible through URL

registration at

intermediate agents

User

Agent (UA)

Service

Agent (SA)

Service

Service

Agent (SA)

Service

Directory

Agent (DA)

Application

10

RFC 2608 - Service Location Protocol, Version 2

RFC 2609 - Service Templates and Service Schemes

RFC 2614 - An API for Service Location Protocol

http://www.openslp.org/doc/rfc/rfc2608.txt




SLP is based on 3 Types of Agents

Agents as entities capable of SLP message processing

Service agent

Performs broadcast (usually periodic) of advertisement messages

about its resources/services (associations with URLs)

Directory agent (optional)

Performs caching of advertisement messages as a centralized

repository

Processes discovery queries received from user/service agents by

returning back the URLs that match

User agent

To discover resources/services at the client side

Also efficient usage of multicast to service agent groups

Standard specification is relatively rich and flexible, but industry-mature

implementations not so widespread (OpenSLP, Sun SLP, Xerox printers, …)

11


Universal Plug-and-Play (UPnP)

Standard specification started by Microsoft (at the beginning,

an internal proprietary solution)

Primary goal: to enable advertisement, discovery, and

control of networked devices, services, consumer

electronics in typically domestic ad hoc envs (see the

current exploitation in media centers, tvs, hi-fi devices, …)

UPnP uses, as underlying technologies:

UDP or TCP/IP

HTTP

XML/HTML and SOAP

12


Via UPnP a device can:

Dynamically join a network, by obtaining an IP address that is locally valid

Making visible its capabilities, by need and on-demand

Discover the presence and capabilities of other devices

Dynamically leave a network

UPnP supports:

Automated IP configuration

Discovery of resources and services

Description of resources/services based on XML

Service control based on SOAP

Event management (via Generic Eventing and Notification Architecture - GENA)

Presentation in HTML/XML

13

Universal Plug-and-Play (UPnP)


IP Addressing in UPnP

By delving into finer technical details:

UPnP uses Auto IP (the real protocol part for auto-

configuration) to enable devices to connect to the

network with NO need of explicit administration

When a device connects to a network, it tries to obtain

an IP address from a DHCP server, if available

If no DHCP server is available, an IP address is

automatically claimed from a fixed reserved range

for usage ONLY at local network

An IP address from the link-local address range is selected

randomly (169.254.0.0/16 for IPv4)

Request sent via Address Resolution Protocol (ARP) to check

whether other devices have already picked up that address

14


Service Discovery in UPnP

UPnP exploits the Simple Service Discovery Protocol

(SSDP) as discovery protocol based on usage of

dedicated multicast address (239.255.255.250 on port 1900

via UDP)

Device

Control

Point

URL of

Device

Description

File

ssdp:discover Device

Control

Point

ssdp:alive

(URL)

15


Service Discovery in UPnP

Device (e.g., UPnP-compliant projector) multicasts an

advertisement message (ssdp:alive) to exhibit its

services to active control points (e.g., tablets or home

gateways)

Control point can perform multicast of search

messages (ssdp:discover)

Any device that receives a multicast message may

reply with a unicast response message

The URL of XML Device Description File is returned

back to the control point

16


UPnP Architecture and Protocol Stack

17

Usage of

HTTP over

UDP, either

multicast

(HTTPMU)

or unicast

(HTTPU)


Description of Device and

its Services in UPnP

UPnP uses XML to describe resources and services

(standardization effort for interoperable representation)

Advertisement message includes a URL related to the

XML device description file

Device description file describes the capabilities of the device for

which advertisement is done

Control point can dynamically obtain the device description file via

HTTP and process it

Any device can offer one or more resources/services

<service> element includes

Service type and service ID

Service URL for invocation via SOAP

URL for event subscription to enable notifications

An additional file (Service Description File) for any offered

service, with more specific and detailed descriptions

18


Device Description File

for a Projector

<?xml version="1.0" ?>

<root xmlns="urn:schemas-upnp-org:device-1-0">

<device>

<deviceType>urn:schemas-upnp-org:device:projector:1</deviceType>

<UDN>uuid:UPnP-Projector</UDN>

<serviceList>

<service>

<serviceType>urn:schemas-upnp-org:service:control:1</serviceType>

<serviceId>urn:upnp-org:serviceId:control</serviceId>

<controlURL>isapictl.dll?control</controlURL>

<eventSubURL>isapictl.dll?control</eventSubURL>

<SCPDURL>projector-scpd.xml</SCPDURL>

</service>

</serviceList>

</device>

</root>

Service Description File

for a possible “projector

control” service

projector-desc.xml

19

http://ip-address/lab5_projector/projector-desc.xml

http://www.jini.org/

http://www.ietf.org/html.charters/svrloc-charter.html


Service Control in UPnP

The XML-based service description file (e.g., “projector

control”) contains:

Action list with the operations that may be invoked on the

service

Service state table including all exposed state variables (and

their data type)

To invoke a given service control for which a device has

previously performed advertisement, control point

sends a SOAP message to the URL specified for that

service

Control point can access and update state variables in the

table

Service performs the requested control action and

returns the result via SOAP message

20


Service Description File for

a Service of Projector Control

<?xml version="1.0" ?>

<scpd xmlns="urn:schemas-upnp-org:service-1-0">

<actionList>

<action>

<name>SetPower</name>

<argumentList>

<argument>

<name>Power</name>

<relatedStateVariable>Power</relatedStateVariable>

<direction>in</direction>

</argument>

</argumentList>

</action>

… Other actions …

</actionList>

projector-scpd.xml

21

http://www.upnp.org/

http://www.upnp.org/resources/documents.asp

http://www.intel.com/technology/UPnP/






…

<serviceStateTable>

<stateVariable sendEvents="yes">

<name>Power</name>

<dataType>Boolean</dataType>

<defaultValue>0</defaultValue>

</stateVariable>

<stateVariable sendEvents="yes">

<name>File</name>

<dataType>string</dataType>

<defaultValue>default.ppt</defaultValue>

</stateVariable>

… Other state variables …

</serviceStateTable>

</scpd>

22

Service Description File for

a Service of Projector Control


Event Subscription in UPnP

Control point may register itself for receiving

notification events generated by advertised services

when state variables are modified

Subscription URL included in device description file

Messages that implement the notified event are expressed in XML

and formatted according to the General Event Notification

Architecture (GENA) standard; they include the modified state

variables that caused event generation

For example, projector service can notify events towards control point when one of the following situations occur: Page up/down (change of pageNumber variable)

Power on/off

Files – change in ppt file list

File – change in ppt file currently with ongoing presentation

UPnP does NOT allow subscription of control points to single state variables; control point has to dynamically determine which state variable has been changed and has generated notification event

23


UPnP Presentation is based on HTTP

Device may advertise a “presentation” URL for user

interface describing service access via Web:

Download Web page from URL and visualization at browser

Possibility for users to control the device

Possibility to visualize device state

Given the usage of XML for data definition and exchange, UPnP

potentially enables employment by a large set of resource-

limited devices: also automated XML transformations

(reductions) based on XSLT

Most UPnP implementations support only presentation based on

HTML, slow transition towards XML

24


UPnP Architectue and

Bridging Possibilities

25


Details on

Service-Control Point Interaction

1. Control point sends SSDP search

request

2. Device replies with unicast UDP

NOTIFY, which contains the URL of

XML file with device description

3. Control point requests XML

description document via HTTP

4. Web server included in the device

replies to request and returns XML

document

5. To automatically receive notifications

of changes at device, control point

can register itself to the services of

interest via HTTP

Control

point

Device

1. M-SEARCH

(multicast)

2. NOTIFY (UDP

unicast)

3. HTTP GET

description.xml

4. HTTP

Response

5. HTTP

SUBSCRIBE

6. HTTP

Response (SID)

7. HTTP M-

POST (SOAP)

8. HTTP (SOAP

response)

9. Notify (GENA

unicast)

26


6. Device replies with registration ACK

and returns unique Subscription

Identifier (SID)

7. Control point can command the

execution of operations at device,

with possible modification of state

variables

URL to send control requests

included in the XML document

with device description

Control point sends SOAP

request over HTTP

Control

point

Device

1. M-SEARCH

(multicast)

2. NOTIFY (UDP

unicast)

3. HTTP GET

description.xml

4. HTTP

Response

5. HTTP

SUBSCRIBE

6. HTTP

Response (SID)

7. HTTP M-

POST (SOAP)

8. HTTP (SOAP

response)

9. Notify (GENA

unicast)

27

Details on



8. Device possibly changes state variables and returns response as a SOAP message

9. Device can notify clients of the occurred state change, either stemming from invoked actions (as in the case of 8) or generated by implicit modifications at device

Device performs notifications via unicast NOTIFY messages over HTTP

Control

point

Device

1. M-SEARCH

(multicast)

2. NOTIFY (UDP

unicast)

3. HTTP GET

description.xml

4. HTTP

Response

5. HTTP

SUBSCRIBE

6. HTTP

Response (SID)

7. HTTP POST

(SOAP)

8. HTTP (SOAP

response)

9. Notify (GENA

unicast)

28

Details on



By Summarizing…

UPnP Middleware Features

Service Discovery

Support designed for peer-to-peer environments without

hierarchical structuring

Adaptability

IP addresses are dynamically allocated

State modifications are made available via event notification

No support (yet) for service routing/selection based on client

location

Transparent support to communication

Exploitation of Internet standards

No support to multi-hop ad-hoc communications

Data Transformation

Possible data transformation from standard XML format to

proprietary formats that may be control-point-specific (e.g.,

proprietary Microsoft ones)

29


Additional Useful Links

about UPnP

S. Helal, “Standards for Service Discovery and Delivery,” IEEE

Pervasive Computing, Vol. 1, No. 3, pp. 95-100, July-Sept. 2002

Jini Forum, at http://www.jini.org/

Service Location Protocol Working Group (svrloc), at


UPnP Forum, at http://www.upnp.org/

UPnP Forum, “Universal Plug and Play Device Architecture,” at


Intel, “UPnP Technology,” at http://www.intel.com/technology/UPnP/

30







http://www.intel.com/technology/UPnP/

Discovery and Session – Mobile Systems M 31

Exercise on UPnP (1)

To design and implement a small application that uses UPnP to

discover the availability of file multimedia files offered in a locality

To try to respect, as much as possible, the design architectural choice of

out-of-band multimedia communication (direct between end

points) wrt discovery

Situation close to realistic scenario where UPnP is used as solution for configuration,

discovery, and service access in home-oriented networks, in particular for media

servers, rendering devices, data sources, control points, … (see the approach

supported by Digital Living Network Alliance – DLNA - http://www.dlna.org/)

Please refer to docs and development tools, largely available in the

community, such as:

Microsoft, “Using the UPnP Control Point API”,

http://msdn.microsoft.com/en-us/library/ms898948.aspx

Cling - Java/Android UPnP library and tools (Java sw stack compliant with

UPnP), http://teleal.org/projects/cling/

CyberLink (Java/Android),

http://www.cybergarage.org/twiki/bin/view/Main/CyberLinkForJava

http://www.dlna.org/




http://teleal.org/projects/cling/

http://www.cybergarage.org/twiki/bin/view/Main/CyberLinkForJava


Exercise on UPnP (2)

Other reference development tools and management instruments, widely

adopted in the developers’ community:

Reference tool for testing; it offers media servers, media renderers,

spies, controllers, ... useful to test and validate applications; it also

offers a C# stack to create UPnP devices and services

http://opentools.homeip.net/dev-tools-for-upnp

Coherence (for development in Python)

http://coherence.beebits.net/

BRisa, for both Python (UPnP 1.0) and qt (UPnP 1.1), specifically

designed for the Maemo platform

https://garage.maemo.org/projects/brisa

As usual, the exercise could be a starting seed for a possible

further project activity…








http://coherence.beebits.net/

https://garage.maemo.org/projects/brisa


Alternatively,

Solution based on Apache River

To design and implement a small application that uses Apache River to

discover the availability of multimedia files offered in a locality

To try to respect, as much as possible, the design architectural choice of

out-of-band multimedia communication (direct between end points)

wrt discovery

In this case, please refer to docs and development tools available at:

River home page - http://river.apache.org/

River Starter Kit - http://river.apache.org/user-guide-basic-river-

services.html

StartNow project - http://java.net/projects/startnow/

http://river.apache.org/

http://river.apache.org/user-guide-basic-river-services.html









http://java.net/projects/startnow/


Session Management

We already duscussed several times about the relevance

of session management

What exactly do we intend for session?

Which exact additional complexities when managing

sessions in mobile systems?

You already know several related techniques, e.g., integrated with the

Web, to maintain session state

Also in mobile environments, wide multiplicity of

techniques and technologies to make session state

available notwithstanding mobility of users, terminals, resources

and services at runtime

Here we will concentrate on session management for 4G converging

systems based on IP Multimedia Subsystem (IMS)

34


Mobile multimedia services

offered by third parties, such as

Internet service providers (e.g., weather forecast, news, …)

Service Provisioning Scenarios

in 4G/5G Converging Networks

Mobile multimedia

services offered by

telco operators (e.g., VoIP, IPTV, …)

Core IP network to provide basic services:

QoS-enabled data transport, mobility, AAA, …

Platform for service

provisioning: overlay all-IP

for service access and

integration (e.g., IMS)

IEEE 802.11

(WiFi) Bluetooth

3G and WiMAX

Wireless access networks are strongly differentiated and heterogeneous

35


IP-based

network

Wi-Fi Hotspot Wi-Fi Hotspot

Cellular 3G

Network and Service Management in 4G:

Wide Usage of Proxy-based Approaches

IMS

IP Multimedia Subsystem

based on SIP (Session Initiation Protocol)

New protocols and

active infrastructures

based on proxies for

session management

36


Session Initiation Protocol (SIP)

SIP defines a signaling framework and associated protocols and messages to set any possible type of session (it works at the OSI session level)

Very open and general purpose

Includes several core facilities for mobility management, session initialization, session termination, session transfer, …

Does NOT include some basic services anyway of central relevance (e.g., AAA, resource reservation/allocation, …)

SIP is NOT a protocol for data/media transmission

Other protocols are specifically suited to this goal: Real-time Transport

Protocol (RTP), RTP Control Protocol (RTCP), Real Time Streaming

Protocol (RTSP),…

Examples of “classical usage” of SIP

To establish, configure, and terminate a voice call over VoIP

Instant messaging and presence service: SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE)

Session transfer and call re-direction

37


SIP: some History and

Primary Goals

Proposed around 1995 (principal investigator: Henning Schulzrinne,

Columbia University), in the context of research activities on Multi-party

Multimedia Session Control

Submitted for evaluation to Internet Engineering Task Force (IETF) in 1996,

then developed by the SIP Working Group

Published in 1999 as IETF RFC 2543; selected by 3GPP as the reference

standard in 2000; further version (only additional minor modifications came

later) in 2002 - RFC 3261

Primary goals: User location: to determine end systems to currently involve at runtime

User capability: to determine which media to use and with which

configuration settings

User availability: to determine availability of called parties to participate to

a call

Call setup: "ringing“ and negotiation of call parameters between calling

and callee

Call handling: management, including call transfer and termination

38


SIP in a Single Slide

SIP core signaling

HTTP-like protocol based on exchange of text messages and on

the exploitation of email-like SIP identifiers (SIP addresses)

Client/server protocol (request/response)

Standardized messages for session control

INVITE, REGISTER, OK, ACK, BYE, …

SIP framework is based on proxy usage. Primary entities:

User agent: end point that can operate either as client or server on

behalf of its user

User Agent Client: it creates new SIP requests

User Agent Server: it generates replies to SIP requests

Dialog: peer-to-peer relationship between two user agents,

established with dedicated and specific methods

Proxy server: application-level router

Redirect server: it forwards clients to alternative servers

Registrar: it keeps track of users 39


Formatting SIP Messages

Formatting is simple and text based

Starting first line (Request Line or Status Line)

Message type (method type + URI in request messages, response code in response messages)

Protocol version

Headers Fields to transfer message attributes

Also on multiple lines, fields may appear several times and duplicated (robustness principle, as in HTTP); simply multiple values separated by commas

Body (content) To describe the session to be started

Or to include “opaque” data, text or binary oriented

40


Proxy Server Proxy Server

User Agent Alice User Agent Bob

5. INVITE

To:sip:[email protected]

6. 100 Trying

11. 180 Ringing

14. 200 OK

16. 180 ACK

Media (RTP)

2. 1

00

Try

ing

12

. 1

80

Rin

gin

g

15

. O

K

13

. 20

0 O

K

10

. 10

0 R

ing

ing

9. IN

VIT

E

sip

:bo

b@

test.c

om

DNS

Server

Location

Service

41

SIP addresssing

Determination of

SIP Server

Sending SIP

requests: SIP

Transactions

SIP methods

SIP responses

Successive

requests and

responses within

a dialog

Simple Example of SIP Usage


CALLER PROXY A CALLEE PROXY B

(1) INVITE

(4) ACK

(6) 200 OK

Media session (e.g., based on RTP, NO SIP)

(2) RINGING

(3) 200 OK

(5) BYE

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;

branch=z9hG4bK776asdhds

Max-Forwards: 70

To: Bob <sip:[email protected]>

From: Alice <sip:[email protected]>;

tag=1928301774

Call-ID:

[email protected]

CSeq: 314159 INVITE

Contact: <sip:[email protected]>

Content-Type: application/sdp

Content-Length: 142

… SDP description …

Start line: • request line (in requests) • status line (in responses)

Header: several fields included

Message body (optional): e.g., SDP

description to negotiate audio/video

formats or codecs

42



CALLER PROXY A CALLEE PROXY B

(1) INVITE

(4) ACK

(6) 200 OK

(2) RINGING

(3) 200 OK

(5) BYE

Media session (e.g., based on RTP, NO SIP)

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;

branch=z9hG4bK776asdhds

Max-Forwards: 70

To: Bob <sip:[email protected]>

From: Alice <sip:[email protected]>;

tag=1928301774

Call-ID:

[email protected]

CSeq: 314159 INVITE

Contact: <sip:[email protected]>

Content-Type: application/sdp

Content-Length: 142

… SDP description …

Start line: • request line (in requests) • status line (in responses)

Header: several fields included

Message body (optional): e.g., SDP

description to negotiate audio/video

formats or codecs

43



Relevant Evolution Step in 3G:

IP Multimedia Subsystem (IMS)

IP Multimedia Subsystem as support infrastructure for provisioning

multimedia services over integrated converging networks with

differentiated characteristics (fixed and mobile):

Instant Messaging, multimedia sharing, Push-To-Talk, gaming, video

conference, …

Standard that is widely accepted and largely used in mature

industrial environments

SIP usage as the protocol for setup and configuration of

multimedia sessions over IP-based networks

SIP as signaling protocol for:

Localizing a user given her SIP Universal Resource Identifier (URI), e.g., sip:[email protected]

Session configuration and negotiation of its parameters

Architecture strongly and highly based on proxy utilization

44


DNS1


in a Single Slide

Visited network 1

P-CSCF

Home Network 1 Home Network 2

Visited network 2

P-CSCF

AS AS

S-CSCF S-CSCF

I-CSCF I-CSCF

HSS HSS

Mobile

Node

(MN)

Corresp.

Node

(CN)

DATA FLOW

DNS2

45


DNS1


in a Single Slide

Visited network 1

P-CSCF


Visited network 2

P-CSCF

AS AS

S-CSCF S-CSCF

I-CSCF I-CSCF

HSS HSS

Mobile

Node

(MN)

Corresp.

Node

(CN)

DATA FLOW

Signaling functions

Authentication functions

DNS2

46


DNS1


in a Single Slide

Visited network 1

P-CSCF


Visited network 2

P-CSCF

AS AS

S-CSCF S-CSCF

I-CSCF I-CSCF

HSS HSS

Mobile

Node

(MN)

Corresp.

Node

(CN)

DATA FLOW Application Server (AS)

Functions/entities to extend

and integrate the usual

IMS Signaling

Authentication functions

DNS2

47

Architecture based on proxies

It works at the OSI session level

Protocols: SIP (+ Diameter)

Common set of functions to simplify

multimedia service deployment

in highly heterogeneous

wireless environments


IMS Functional Entities:

DNS and HSS

Domain Name System (DNS): Standard naming service for the Internet

Used by IMS to solve IP addresses for all types of CSCFs and ASs

It may be also employed for load balancing purposes (but only at low frequencies of DNS queries)

Home Subscriber Server (HSS): It works for persistent storage of user subscription info, e.g.,

authentication data and preference profiles (usage of standard DBMS)

An IMS network may include one or more HSS

Subscriber Location Function (SLF) to associate users to specific HSS

48



Proxy-CSCF

Proxy-Call Session Control Function (P-CSCF):

First contact point to the IMS network, both in the visited domain and in the home domain

It plays the role of SIP outbound/inbound proxy (all requests from/to IMS terminals pass through this proxy)

Primary features of P-CSCF:

Forwarding of SIP requests in the appropriate direction (towards terminals or IMS network)

Other functions, such as for:

Security

Generation of charging info (tariffs/fares and invoices)

Message compression and de-compression

49



Interrogating-CSCF

Interrogating-Call Session Control Function (I-CSCF): SIP proxy at the borders of the home administration domain

It may be present in multiple instances within the same network to the purpose of scalability and fault tolerance

Registered in DNS (also multiple instances)

Stateless server for SIP re-direction

Primary I-CSCF functions: Interaction with HSS to determine which S-CSCF is associated with a

client (usage of the Diameter protocol)

Re-direction and routing of incoming SIP requests towards S-CSCF

It can even be used to dynamically select least loaded S-CSCF

50



Serving-CSCF

Serving-Call Session Control Function (S-CSCF): Always positioned in the home domain

SIP proxy + SIP registrar with possibility to work on session control

Primary features of S-CSCF: Binding between IP address (terminal location) and SIP user

address

Interaction with application server to create so-called value added services (additional features wrt basic SIP signaling)

Translation services (phone number/SIP URI)

Message routing (via so-called IMS filtering criteria)

it can be used to statically split incoming traffic depending on user identity/profile

51



Application Server

Application Server (AS):

Hosts and executes services

Communicates via SIP: expensive

Each interposed AS generates 2 messages (processed+ACK) for each message traversing it

Complex coordination for stateful and distributed ASs

Different types of AS for different environments, integrated scenarios, and functionality

SIP AS: adoption of SIP signaling, services can work only in SIP environments

Other types: Open Service Architecture – Service Capability Server (OSA/SCS), IP Multimedia Service Switching Function (IM-SSF), …

52


Scalability in IMS:

What is Easily Possible

Visited network 1

P-CSCF


Visited network 2

P-CSCF

AS AS

S-CSCF S-CSCF

I-CSCF I-CSCF

HSS HSS

Mobile

Node

(MN)

Corresp.

Node

(CN)

DATA FLOW

DNS1 DNS2

1.

4.

5.

6.

7.

8. 2. MN “in call”

3.

I-CSCF required

on registration

load-balancing

53


Scalability in IMS:

What is Easily Possible

Visited network 1

P-CSCF


Visited network 2

P-CSCF

AS AS

S-CSCF S-CSCF

I-CSCF I-CSCF

HSS HSS

Mobile

Node

(MN)

Corresp.

Node

(CN)

DATA FLOW

DNS1 DNS2

1.

4.

5.

6.

7.

8. 2. MN “in call”

3.

I-CSCF required

on registration

load-balancing

54


Single host (local) optimizations with/without (or with minimal) coordination: Selective message dropping

Compression of SIP messages and techniques for partial parsing

Stateful vs stateless SIP proxies

Intra-domain load balancing : Monitoring and dynamic load balancing operations at

the infrastructure level

AS coordination protocols at service level (also ad-hoc optimized protocols that are NON-IMS-compliant)

Inter-domain protocol optimizations: To limit traffic between different domains

Service-level message processing at borders (edges) of IMS domains

Scalability in IMS: A few (Partial) Solutions

55

Towards usage of ELASTIC cloud support for IMS

mobile systems m - unibo.itlia.disi.unibo.it/courses/sm1617-info/lucidi/06-discovery(1x).pdf ·...

Documents