analysis of structuring call and non-call services on trial rcs
TRANSCRIPT
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