Issued by Iskratel; All rights reserved
Obr.: 70-121d
Analysis of structuring call and non-call
services on trial RCS implementation
RCS, VoLTE & beyond Worksop, 10-11 October 2012
Valerij Grašič, Iskratel
St
Structuring
t i the
th application
li ti layer
l
Lessons obtained
AS1
AS2
Š
Š
Š
AS3
HSS
UE N
UE-N
S/P/I-CSCF
Š
Issued by Iskra
atel; All rights reserved
UE-1
UE-3
UE-2
Service placement motivation:
to place 5 services to 3 AS
Š
Š
Analysis of structuring application layer
Many service placement possibilities
Starting point for structuring:
Š to group the services
Š to deploy user base on AS set
Services
Š Characteristics of services
Š Influence
I fl
off each
h service
i
Traffic and configuration model framework
Š signaling traffic on S-CSCF and AS
Š Parameters to describe, compare,
evaluate configuration
Š user habits
More research still need to be done
1
Issued by Iskra
atel; All rights reserved
RCS iimplementation
l
t ti options
ti
on the
th market
k t
Same AS for more
local networks
More AS for
local network
RCS AS as part
of local network
2
Analysed services on trial RCS implementation
Test bed
Š
Š
Issued by Iskra
atel; All rights reserved
Š
UE: Mercuro, Boghe, sipp
CSCF, PS AS (Mobicents), AS, HSS
Š HP Compaq Intel Core 2 CPU 6300
Š Linux i686 (Linux carrier Grade 4.0)
4 0)
Š 1.6 GHZ, Pentium 4, 1 GB RAM
CSCF: Iskratel C-IMS
Analysed services
Š
Š
Š
Š
Š
Basic
B
i call
ll (BC)
Š Use of service OIP/TIP
Š “Basic” signals, PRACK
CDIV (Communication Diversion)
Š Service CFU (Unconditional)
CAT (Customized Alerting Tones)
IM (Instant messaging)
Š Page Mode (use of MESSAGE)
Presence
Analysed
y
also
Š
Š
Registration
Subscribing
3
Application layer arhitecture
Issued by Iskra
atel; All rights reserved
Application servers on IOT
4
Service placement: deploy of services and user base
Issued by Iskra
atel; All rights reserved
Used configurations (K)
Grouping of services
We defined these grouping rules:
Two
opposite
Š Services on each AS :
placements:
Š all services on each AS (K1)
max (K1) vs.
Š part of all services on each AS
min (K2
(K2, K3)
(K2, K3, K4)
number of
Š User base on each AS:
services
Š all users on each AS (K2, K3)
on AS
Š part of all users on each AS (K1
(K1, K4)
Š Service groups and subsgroups
Š main groups: TAS (MMTel), RCS
g
p TAS basic,, TAS plus
p
Š TAS subgroups:
Š
RCS subgroups: RCS IM, RCS
Presence
5
Service placement: triggering
Triggering
Š
Š
iFC (Initial Filter Criteria) for each K
Š
Š
Š
One, two or three iFC for each AS
Three or four (K2) iFC for each user
g )
K0: as TDM ((all services in switch exchange)
Issued by Iskra
atel; All rights reserved
Š
Triggering is made on S-CSCF
iFC defines AS where to send
messages and where services are
executed
iFC are stored in HSS
6
Analysed services: call based (TAS/MMTel)
Basic call
with
i h PRACK
Call based (TAS) services:
Š
Š
Basic call
Issued by Iskra
atel; All rights reserved
Š
Basic call (for K0):
Š Options: “basic”, PRACK
CDIV
Š Additional 181 (Call Forwarded)
from AS to S-CSCF
CAT
Š Additional INVITE from AS to
S-CSCF and MRF (Media
Resource Function)
7
Analysed services: non-call based (RCS)
Presence
Non-call ((RCS)) based services:
Š
Issued by Iskra
atel; All rights reserved
IM (p
(page
g mode))
Š
IM (Instant messaging)
Š page mode
Š Messages: MESSAGE, 200
Presence
Š P (presentity): publish state changes
Š W (watcher): receive state changes
Š Messages from P: PUBLISH,
PUBLISH 200
Š Messages to W: NOTIFY, 200
8
Analysed services: non–call (registration,subscribe)
Subscribe:
Š
Š
Issued by Iskra
atel; All rights reserved
Š
We analysed subscribe for presence
SUBSCRIBE with “Event:
presence.winfo” send for own user
SUBSCRIBE with “Event: presence”
send for each user in Contacts
Registration:
Š
Š
Each user must make registration
Data are stored in HSS
9
Analysed services: placement to AS set
Placement of services
Placement of services to AS set:
Š
Š
Issued by Iskra
atel; All rights reserved
Š
Š
Š
Each service can be executed on S-CSCF
(with AS functionality), on AS for user A
side, and on AS for user B side
For example OIP/TIP is executed on AS(A)
for A side, then on AS (B) for B side
Registration and subscribe are executed
y on one AS
only
CAT and CDIV are executed only on user B
side
BC and IM can be executed on AS on user A
side and on user B side
10
Analysed services: used signals
Used signals for services:
Š
Š
Issued by Iskra
atel; All rights reserved
Š
Š
Š
We analysed messages used for services
Messages were analysed on user (UE), SCSCF HSS,
CSCF,
HSS AS and
d PS (Presence
(P
server))
AS (outside AS)
We defined messages, size (bytes) and
direction
Call based services have same messages
Size of messages has a wide range
11
A l
Analysed
d services:
i
signals
i
l for
f service
i placement
l
t
Key findings of the signal analysis of
service placement on S-CSCF:
Š
Issued by Iskra
atel; All rights reserved
Š
Š
Š
Š
Traffic for BC+ is almost more than once
bigger as traffic for basic call with no
additional
dditi
l options
ti
Registration and subscribing can have
greater impact to traffic than basic call
IM in case of two AS has same traffic
impact as BC in case of S-CSCF
Traffic due presence depends on number
of W
Traffic for call based services (CDIV
(CDIV, CAT)
has similar impact as the traffic for BC
Signals for service placement
Legend for users:
Š
G: group of services (number of iFC)
Š
C: number of contacts
Š
A number
A:
b off AS user iis registered
i t
d on
Š
BC: number of signals for BC
Š
BC+: BC with PRACK and 183
Š
AS1: can be AS for side A or side B
12
A l
Analysed
d services:
i
use case for
f K1
Issued by Iskra
atel; All rights reserved
Signals for configuration K1
Use case fo K1:
Š
Š
Š
Š
Š
Š
Š
Š
For K1: all services are on each AS
For K1: on each AS there is 1/3 of users
AS(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)
Reg, subs: given per user
IM, BC: executed for both side A and B
CDIV, CAT: executed only on side of user B
Presence: executed only on one AS
13
E i ti parameters
Existing
t
and
d benchmarks
b
h
k
Exsisting parameters and benchmarks:
Issued by Iskra
atel; All rights reserved
Š
Š
Š
RFC 6076:
6076 Basic
B i Telephony
T l h
SIP End-ToE dT
End Performance Metrics
Š Defined time parameters
p
Š Defined also ratio,, attemps
Š RRD: registration delay (REG-200)
Š SRD: session request (INVITE-180)
Š SDD: session disconnect (BYE-200)
Š SDT: session duration (200-BYE)
ETSI TS 186 008: IMS/NGN Performance
Benchmark
Š Benchmarking of core IMS, no AS
Š Predefined (fixed) set of services
No other parameters or benchmarks
defined yet
IMS/NGN Bencharking
g environment
14
P
Proposed
d parameters
t
and
d benchmarks
b
h
k
Proposed time parameters :
Š
Issued by Iskra
atel; All rights reserved
Š
Š
Time parameters (defined): RRD, SRD,
SDD, SDT
Time parameter (defined, to be expanded)
Š SRDmax: 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
Š The
Th same is
i valid
lid ffor SDD
Time parameters (used, not defined, to be
agreed):
g (PUBLISH-200)
(
)
Š Publishing
Š Subscribe (SUBSCRIBE-200)
Š Messaging (MESSAGE-200)
Proposed traffic parameters:
Š
Š
Š
Traffic parameters
Š Traffic on S-CSCF
Š Traffic on AS
Traffic is defined as number of signals
SIP transaction (e.g. INVITE-180, BYE200) and SIP dialog (SIP session) are
not comparable and can not easly be
be combined with non-call services
15
P
Proposed
d framework
f
k for
f service
i placement
l
t
Proposed framework for the service placement:
Š
Š
Issued by Iskra
atel; All rights reserved
Š
Š
Š
Š
Based on the analysis we prepared the framework for the service placement
Data for services
Š Which services are used
Š Signals and parameters for services (C
(C, P
P, W
W, G
G, A)
Š How the service placement is made
Parameters for the configuration
g
on S-CSCF and AS
Š Traffic: signals
Š Time: session, reg, subs, publish
Š Other: completion ratio,..
Data for users: habits, use of services
More detailed research still need to be done for service placement
Our plan is to male more tests and simulations for given configurations
16
Open issues for service placement framework
Questions detected at presented analysis:
Š
Š
Issued by Iskra
atel; All rights reserved
Š
Š
Š
We have found many interesting completions
completions, but some issues are still opened
Lack of standardised and agreed parameters and benchmarks
Š time parameters
p
Š traffic parameters
Š other benchmarks
What parameters to use for traffic comparision?
Š based on BHCA (as in TDM)?
Š 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?
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
17