Aggregation Efficacy in IMS Presence-based Resource List

makeshiftklipInternet και Εφαρμογές Web

31 Οκτ 2013 (πριν από 3 χρόνια και 9 μήνες)

81 εμφανίσεις











CoE

Industry Seminar August 2008






Aggregation Efficacy in IMS

Presence
-
based Resource List
Servers


The IMS


The IMS and Presence


Presence Architecture


Role of the Resource List Server


RLS Functions in the IMS


RLS Operational States


Inefficiencies in IMS and IETF Presence


RLS Aggregation Methods


Experimental Verification of RLS Performance


Verification of RLS Aggregation


Conclusion


Questions and Answers


Presence is a status indicator conveying the ability or willingness of
a party to communicate


Offers an indication of
user

availability, rather than only the
connection

availability of PSTN (i.e. a dial tone)


Often implemented in fragmentary, proprietary non
-
interoperable
standards in the internet


IMS Presence is based on RFCs for operation and formatting, but
follows the IMS signalling pathways from terminal to core


Resource List Server is a core network proxy, aggregating XML
-
encoded presence from the Presence Server (PS) to Presence User
Agents (PUAs)



The RLS is an IMS Core
-
based Presence Application Server


Maintains Resource Lists of
presentities

and their watchers


Aggregates the presence information from Presence Servers to
subscribing PUAs


Reduces data processing and packet overhead at the PUA


Moves repetitive SIP signalling to
presentities

to the bandwidth
-
rich core network, away from the PUA


General operational specifications covered in IETF and 3GPP
standards


Watcher SUBSCRIBE with a Resource List Server




Each subscription to RLS exists in one of two operational states


Initialisation and Steady
-
State


Initialisation:


Device log
-
in, or initial access to service


Phone/device turned on, or becomes default presence device


Of short duration, but high volume of traffic


All subscribed presence/watcher information is sent rapidly to
PUA




Steady
-
state:


Stabilisation of traffic volumes, following on from the
initialisation state


Normal, long
-
term operational state for subscriptions


Steady, random distribution of NOTIFY arrivals


NOTIFY messages generated by changes in subscribed
presentity

or watcher information



Traffic Volume Curve for Subscription Life
-
time

Traffic Volume

Time

Initialisation

Steady
-
state


IMS uses SIP for signaling


a human
-
readable application
-
layer
protocol based on the HTTP request
-
and
-
response model


High network stack layer allows greater interoperability across
devices and architectures


Text
-
based SIP headers are bulky and inefficient in terms of
information encoding efficiency


Presence information is encoded in XML


Hierarchical and fully extensible data encoding format


High readability leads to a low encoding efficiency


Results in high level of data redundancy


Inefficient use of limited access
-
network bandwidth, for an add
-
on
service


<?xml version="1.0" encoding="UTF
-
8"?>

<presence
xmlns
="
urn:ietf:params:xml:ns:pidf
"


xmlns:im
="
urn:ietf:params:xml:ns:pidf:im
"


xmlns:myex
="http://id.example.com/presence/"


entity="
pres:someone@example.com
">


<
tuple

id="bs35r9">


<status>


<basic>open</basic>


<
im:im
>busy</
im:im
>


<
myex:location
>home</
myex:location
>


</status>


<contact priority="0.8">
im:someone@mobilecarrier.net
</contact>


<note
xml:lang
="en">Don't Disturb Please!</note>


<note
xml:lang
="
fr
">Ne
derangez

pas, s'il vous plait</note>


<timestamp>2001
-
10
-
27T16:49:29Z</timestamp>


</
tuple
>


<
tuple

id="eg92n8">


<status>


<basic>open</basic>


</status>


<contact priority="1.0">mailto:someone@example.com</contact>


</
tuple
>


<note>I'll be in Tokyo next week</note>

</presence>






[2]





Aggregation methods should reduce message frequency and
overhead, while ensuring
timeous

delivery


May be individually suited to a specific subscription operational
state


Time, Quantity, MTU or Selective Updating methods available


Time
-
based: Aggregate after x seconds/minutes


Initialisation: very large amounts of data transmitted,
periodically


ineffective and inefficient


Better suited to a steady
-
state subscription


Quantity
-
based: Aggregate after x updates


Suitable for both subscription states


Issue of timeliness for steady
-
state subscriptions




MTU
-
based: Aggregate when the payload + overhead reaches the
MTU of the access network


Maximum payload/overhead efficiency, but timeliness
questions for
steady
-
state

subscriptions


User
-
preferences can also be accommodated:


Selective Updates: Only specific
presentities

or presence
information changes generate updates sent to the PUA


Can be used conjunction with time
-
based aggregation


Combinations of methods likely to give best performance under
most conditions


particularly if dynamic


Correct choice of parameters for methods imperative


Polling may obtain presence information “once
-
off”, either through
the RLS, or bypassing it.



This work is to perform an experimental verification of the known
concepts which led to the definition and specification of the RLS in
literature


The performance of a RLS under varied operational conditions is
not known, and likely to vary considerably:


Large x values in steady
-
state quantity aggregation can
negatively affect
timeous

delivery


Small x values in steady
-
state time aggregation result in many
updates, diminishing aggregation effectiveness


Large x values
in initialisation
-
state time aggregation can
entirely negate the operational benefits of RLS


Empirical testing of developed RLS will provide data and insight
into the RLS performance issues raised



Simulations were performed to validate the initial concept


Presented is a scenario of time
-
based aggregation on a
stabilised
,
steady
-
state RLS subscription.


Aggregation parameter of 5s between PUA NOTIFY updates


Resource list split in two, with each group having a different
level of activity:


15% had 0.01 probability of updating per second


85% had 0.0001 probability of updating per second


Simulation had duration of 1000s


Simulation repeated, with resource list size increased each
iteration, from 1 to 100
presentities



Presence is a basic network service with great potential as an
application in the IMS


The data representation of presence information, and SIP signalling
for presence is very bandwidth intensive


The RLS moves most presence traffic from the bandwidth
-
restricted
access network to the bandwidth
-
provisioned IMS core


The effectiveness of RLS aggregation techniques depend on the
subscription state, load, and aggregation parameters


The RLS can reduce the presence traffic to the PUA considerably
when applied correctly





Thank you for your time


Questions and Comments?








[1]
G. Camarillo and M. A. Garcia
-
Martin,
The 3G IP Multimedia Sub
-
system (IMS)
-

Merging the Internet and the Cellular Worlds
, Ch 17, pp. 323

328.


John Wiley and Sons, Ltd, 2
nd

Ed., 2006.


[2] H. Sugano, S. Fujimoto,
G.Klyne
,
A.Bateman
,
W.Carr

and J. Peterson, “
RFC 3863,
Presence Information Data Format (PIDF)
,” 2004