All

right

s re

serv

ed Analysis of structuring call and non-call services on trial RCS implementation

Issu

ed b

y Is

krat

el;

RCS, VoLTE & beyond Worksop, 10-11 October 2012 Valerij Grašič, Iskratel

Obr

.: 70

-121

d

St t i th li ti lStructuring the application layer

AS1 AS2 AS3

Lessons obtained Analysis of structuring application layerAS1

UE NHSS

AS2 AS3 Analysis of structuring application layer Many service placement possibilitiesStarting point for structuring:

to group the services

UE-1

UE-NHSSS/P/I-CSCF to deploy user base on AS set

Services Characteristics of services I fl f h i

atel

; All

right

s re

serv

ed

UE-2UE-3

Influence of each serviceTraffic and configuration model framework

signaling traffic on S-CSCF and ASParameters to describe, compare,

Issu

ed b

y Is

kra

1

Service placement motivation: to place 5 services to 3 AS

Parameters to describe, compare, evaluate configurationuser habits

More research still need to be done

RCS i l t ti ti th k tRCS implementation options on the market

atel

; All

right

s re

serv

edIs

sued

by

Iskr

a

2

Same AS for more local networks

More AS for local network

RCS AS as part of local network

Analysed services on trial RCS implementationAnalysed services

B i ll (BC)Test bed

Basic call (BC)Use of service OIP/TIP“Basic” signals, PRACK

CDIV (Communication Diversion)

UE: Mercuro, Boghe, sipp CSCF, PS AS (Mobicents), AS, HSS

HP Compaq Intel Core 2 CPU 6300Linux i686 (Linux carrier Grade 4 0) CDIV (Communication Diversion)

Service CFU (Unconditional) CAT (Customized Alerting Tones)IM (Instant messaging)

Linux i686 (Linux carrier Grade 4.0)1.6 GHZ, Pentium 4, 1 GB RAM

CSCF: Iskratel C-IMS

atel

; All

right

s re

serv

ed Page Mode (use of MESSAGE)Presence

Analysed also

Issu

ed b

y Is

kra

3

yRegistration Subscribing

Application layer arhitecture

Application servers on IOT

atel

; All

right

s re

serv

edIs

sued

by

Iskr

a

4

Service placement: deploy of services and user base

We defined these grouping rules:Used configurations (K)Two We defined these grouping rules:

Services on each AS : all services on each AS (K1)part of all services on each AS

Two opposite placements:max (K1) vs. min (K2 K3) (K2, K3, K4)

User base on each AS: all users on each AS (K2, K3)part of all users on each AS (K1 K4)

min (K2, K3) number of services on AS

atel

; All

right

s re

serv

ed

Grouping of servicespart of all users on each AS (K1, K4)

Service groups and subsgroupsmain groups: TAS (MMTel), RCS TAS subgroups: TAS basic, TAS plus

Issu

ed b

y Is

kra

5

g p , pRCS subgroups: RCS IM, RCS Presence

Service placement: triggeringTriggering iFC (Initial Filter Criteria) for each K

Triggering is made on S-CSCFiFC defines AS where to send messages and where services are executed

iFC (Initial Filter Criteria) for each KOne, two or three iFC for each ASThree or four (K2) iFC for each userK0: as TDM (all services in switch exchange)executed

iFC are stored in HSS( g )

atel

; All

right

s re

serv

edIs

sued

by

Iskr

a

6

Analysed services: call based (TAS/MMTel)Call based (TAS) services:Basic call

i h PRACK Call based (TAS) services:Basic call (for K0):

Options: “basic”, PRACKCDIV

with PRACK

Additional 181 (Call Forwarded) from AS to S-CSCF

CATAdditional INVITE from AS to

Basic call

atel

; All

right

s re

serv

ed Additional INVITE from AS to S-CSCF and MRF (Media Resource Function)

Issu

ed b

y Is

kra

7

Analysed services: non-call based (RCS) Non-call (RCS) based services:Presence ( )

IM (Instant messaging)page mode Messages: MESSAGE, 200IM (page mode)

PresenceP (presentity): publish state changes W (watcher): receive state changesMessages from P: PUBLISH 200

(p g )

atel

; All

right

s re

serv

ed Messages from P: PUBLISH, 200Messages to W: NOTIFY, 200

Issu

ed b

y Is

kra

8

Analysed services: non–call (registration,subscribe)

Subscribe:We analysed subscribe for presenceSUBSCRIBE with “Event: presence.winfo” send for own userSUBSCRIBE with “Event: presence” send for each user in Contacts

atel

; All

right

s re

serv

ed

Registration:

Issu

ed b

y Is

kra

9

Registration:Each user must make registrationData are stored in HSS

Analysed services: placement to AS setPlacement of services to AS set:Placement of services Placement of services to AS set:

Each service can be executed on S-CSCF (with AS functionality), on AS for user A side, and on AS for user B side

Placement of services

For example OIP/TIP is executed on AS(A) for A side, then on AS (B) for B sideRegistration and subscribe are executed only on one AS

atel

; All

right

s re

serv

ed

yCAT and CDIV are executed only on user B sideBC and IM can be executed on AS on user A side and on user B side

Issu

ed b

y Is

kra

10

side and on user B side

Analysed services: used signals

Used signals for services:We analysed messages used for servicesMessages were analysed on user (UE), S-CSCF HSS AS d PS (P )CSCF, HSS, AS and PS (Presence server) AS (outside AS)We defined messages, size (bytes) and direction

atel

; All

right

s re

serv

ed Call based services have same messagesSize of messages has a wide range

Issu

ed b

y Is

kra

11

A l d i i l f i l tAnalysed services: signals for service placement

Key findings of the signal analysis ofSignals for service placement

Key findings of the signal analysis of service placement on S-CSCF:Traffic for BC+ is almost more than once bigger as traffic for basic call with no

dditi l tiadditional optionsRegistration and subscribing can have greater impact to traffic than basic callIM in case of two AS has same traffic

atel

; All

right

s re

serv

ed impact as BC in case of S-CSCFTraffic due presence depends on number of W Traffic for call based services (CDIV CAT)

Legend for users:G: group of services (number of iFC) C: number of contacts A b f AS i i t d

Issu

ed b

y Is

kra

12

Traffic for call based services (CDIV, CAT) has similar impact as the traffic for BC

A: number of AS user is registered on BC: number of signals for BCBC+: BC with PRACK and 183AS1: can be AS for side A or side B

A l d i f K1Analysed services: use case for K1

Use case fo K1:For K1: all services are on each ASFor K1: on each AS there is 1/3 of users

Signals for configuration K1

For K1: on each AS there is 1/3 of usersAS(A) and AS(B) together form AS Traffic is given as number of signals due sevices on S-CSCF and AS (for side A and side B)

atel

; All

right

s re

serv

ed Reg, subs: given per userIM, BC: executed for both side A and BCDIV, CAT: executed only on side of user BPresence: executed only on one AS

Issu

ed b

y Is

kra

13

Presence: executed only on one AS

E i ti t d b h kExisting parameters and benchmarksExsisting parameters and benchmarks:

RFC 6076 B i T l h SIP E d TIMS/NGN Bencharking environment

RFC 6076: Basic Telephony SIP End-To-End Performance Metrics

Defined time parametersDefined also ratio, attemps

g

, pRRD: registration delay (REG-200)SRD: session request (INVITE-180)SDD: session disconnect (BYE-200)

atel

; All

right

s re

serv

ed SDT: session duration (200-BYE)ETSI TS 186 008: IMS/NGN Performance Benchmark

Benchmarking of core IMS, no AS

Issu

ed b

y Is

kra

14

Benchmarking of core IMS, no ASPredefined (fixed) set of services

No other parameters or benchmarks defined yet

P d t d b h kProposed parameters and benchmarksProposed time parameters :

Time parameters (defined): RRD, SRD, SDD, SDTTime parameter (defined, to be expanded)

SRDmax: we see that in K3 SRD for

Proposed traffic parameters:Traffic parameters

Traffic on S-CSCFSRDmax: we see that in K3 SRD for users of CDIV and CAT is greater than for users with OIP/TIP only, this fact need to be addressed Th i lid f SDD

Traffic on ASTraffic is defined as number of signalsSIP transaction (e.g. INVITE-180, BYE-200) and SIP dialog (SIP session) are

atel

; All

right

s re

serv

ed The same is valid for SDDTime parameters (used, not defined, to be agreed):

Publishing (PUBLISH-200)

200) and SIP dialog (SIP session) are not comparable and can not easly be be combined with non-call services

Issu

ed b

y Is

kra

15

g ( )Subscribe (SUBSCRIBE-200)Messaging (MESSAGE-200)

P d f k f i l tProposed framework for service placementProposed framework for the service placement:

Based on the analysis we prepared the framework for the service placementData for services

Which services are usedSignals and parameters for services (C P W G A)Signals and parameters for services (C, P, W, G, A)How the service placement is made

Parameters for the configurationTraffic: signals on S-CSCF and AS

atel

; All

right

s re

serv

ed

gTime: session, reg, subs, publishOther: completion ratio,..

Data for users: habits, use of services

Issu

ed b

y Is

kra

16

More detailed research still need to be done for service placementOur plan is to male more tests and simulations for given configurations

Open issues for service placement frameworkQuestions detected at presented analysis:

We have found many interesting completions but some issues are still openedWe have found many interesting completions, but some issues are still openedLack of standardised and agreed parameters and benchmarks

time parameterstraffic parameterspother benchmarks

What parameters to use for traffic comparision? based on BHCA (as in TDM)?

atel

; All

right

s re

serv

ed based on signals for S-CSCF or AS? based for each service separate (due dedicated AS)?

Which metrics and benchmarks still to use for service placement and mutual evaluation?

Issu

ed b

y Is

kra

17

evaluation? Since service silo is more and more actual (with multitude of different services based on SIP and IMS) answers to these questions are becoming more and more interesting