Analysis and Optimizations of Presence Generated Traffic for Cellular Networks

2005:021 CIV MASTER'S THESIS

David Henriksson

Luleå University of Technology MSc Programme in Engineering

Department of Computer Science and Electrical Engineering Division of Computer Communication

2005:021 CIV - ISSN: 1402-1617 - ISRN: LTU-EX--05/021--SE Master’s Thesis Analysis and Optimizations of Presence Generated Traﬃc for Cellular Networks

David Henriksson Luleå University of Technology January 28, 2005

Supervisor: Jan Christoﬀersson, Ericsson Research, Luleå Examiner: Pierre Fransson, Luleå University of Technology Department of Computer Science and Electrical Engineering Division of Computer Science and Networking

Abstract

Presence services have grown increasingly popular during the last decade and today there exist several implementations designed for the Internet. When designing a presence service for cellular networks, new aspects regarding limited network resources and compatibility have to be considered. In this master’s thesis, presence traffic generated according to the Push-to-Talk over Cellular presence specification is analyzed. Different presence updating models are compared through simulations and optimizations in the form of limiting unnecessary messages are suggested. The presence impact on WCDMA capacity has also been investigated by comparing the resources needed for presence and Voice over IP generated traffic. The results show that mechanisms for limiting the number of presence messages are needed, either by throttling the number of presence messages sent or by letting the users perform pulls in order to download the information. Without any kind of message limitation mechanism, presence messages could halve the number of Voice over IP users supported within one radio cell. Depending on the intensities of presence signaling, the decrease in the number of supported users can be limited to between 12 and 30 percent by using throttling and 10 to 17 percent using pull.

Acknowledgements

I would like to thank the following people for their support and ideas during the work of this thesis:

– Pierre Fransson, examiner at Luleå University of Technology for his thor- ough review and suggested improvements regarding this report. – my supervisor Jan Christoﬀersson at Ericsson Research for his advice and help during the thesis work. – all employees at Ericsson Research Luleå. – family and friends.

Luleå, January 2005 David Henriksson

Contents

Contents iii

List of Tables v

List of Figures vi

1 Introduction 1 1.1 Background...... 1 1.2 Objectives...... 1 1.3 DocumentOutline ...... 2

2 Background 3 2.1 Presence...... 3 2.2 PresenceInformation...... 3 2.3 Standards...... 4 2.4 PresenceApplicationsandProtocols ...... 5 2.4.1 Jabber...... 5 2.4.2 OSCAR...... 5 2.4.3 WirelessVillage ...... 6 2.4.4 WindowsMessengerandMSNMessenger ...... 6 2.4.5 SIPTheSessionInitiationProtocol ...... 6 2.4.6 Signaling Compression (SigComp) ...... 8

3 Presence Generated Traﬃc and Presence Models 9 3.1 Pull-BasedPresenceServices ...... 9 3.2 Push-BasedPresenceServices ...... 10 3.2.1 Push-Throttle...... 10

4 PoC Presence Speciﬁcation 11 4.1 MessageExchangeinPush-basedModels ...... 11 4.1.1 Registration ...... 12 4.1.2 PresenceEvents ...... 13 4.1.3 Re-Registration...... 13 4.1.4 De-Registration...... 14 4.2 MessageExchangeinPull-basedModel ...... 15

iii 4.2.1 Pull ...... 16

5 Optimizations and Improvements 17 5.1 Re-Registrationsin Push-basedSystems ...... 17 5.2 Re-Registrations in Throttled and Pull-based Systems ...... 17 5.3 De-registrations...... 18 5.4 PullPartialNotifyUpdates ...... 18

6 SIP Presence Simulator 19 6.1 SimulationInputs ...... 19 6.2 SimulationOutputs...... 19 6.3 ProgrammingLanguageEvaluation...... 21 6.4 Principles of Operation and Design of the Simulator ...... 22 6.4.1 SystemOverview...... 22 6.4.2 Operation...... 24 6.4.3 SimulationEvents ...... 24 6.5 VeriﬁcationofSimulatorCorrectness ...... 25

7 Estimating Presence Traffic 27 7.1 TrafficGeneratedinPush ...... 27 7.2 TrafficGeneratedinPush-Throttle ...... 28 7.3 ComparisonofPushandPull ...... 31

8 Capacity Comparison of Presence and VoIP 35 8.1 BriefIntroductiontoWCDMA ...... 35 8.2 TheErlangUnit ...... 36 8.3 Calculations of Presence and VoIP Comparison ...... 37 8.4 ResultsofPresenceVoIPComparison ...... 39

9 Discussion 43 9.1 FutureWork ...... 44

Bibliography 47

A Calculations of Presence Event Intensity 49

B Veriﬁcation of Simulation Results 51

C Presence Erlang Capacity Calculations 53 C.1 FormulasforCapacityCalculations ...... 53 C.2 Erlang Results for High Intensity Calculations...... 56

iv List of Tables

6.1 Overview of the SIP Presence Simulator parameters...... 20

7.1 The benefits gained at different throttling intervals at a group size of 20 users, measured in number of messages per hour and user...... 30 7.2 The benefits gained at different throttling intervals at a group size of 20 users, measured in kilobytes per hour and user. . . . . 30 7.3 The characteristics of the four compared pull models. P.S is short forPartial(Single)Notify...... 31

8.1 The number of Erlangs generated per presence enabled user during registration for downlink channel at group sizes of 5, 10 and 15users...... 39 8.2 Erlangs generated at diﬀerent traﬃc generating phases for group sizesat5,10and15users...... 40 8.3 Theoretical number of concurrent low intensity presence and presence + VoIP users. Values in percentage represents the decrease of users relative to if no presence service was used...... 40 8.4 Theoretical number of concurrent high intensity presence and presence + VoIP users. Values in percentage represents the decrease of users relative to if no presence service was used. . ... 41

A.1 Presence event intensities for state transitions...... 49

B.1 Theoretical and simulated results compared...... 51

C.1 Erlangs generated at diﬀerent traﬃc generating phases for group sizesat5,10and15users...... 56

v List of Figures

2.1 APresenceSIPSession ...... 7

4.1 Traﬃc generating phases in a push presence model with two states. 12 4.2 Messages exchanged during the registration phase...... 12 4.3 Messages exchanged when a presence event occurs, i.e., a presentity updates its presence information...... 13 4.4 Messages exchanged during re-registration...... 14 4.5 Messages exchanged during de-registration...... 14 4.6 Traﬃc generating phases in a pull presence model with two states. 15 4.7 a) Messages exchanged during subscription-less pull. The server interprets this as an un-subscription. b) Messages exchanged during subscription-based pull. The server interprets this as a pre-longingofthesubscription...... 16

6.1 The data structure where simulation data is stored. The number of messages and message sizes for each type and user is stored in a time slot corresponding to the time of the event...... 21 6.2 The figure illustrates how a user moves between the predefined states. The time spent within each state is exponentially distributed with the mean value specified by the simulation inputs. 22 6.3 System Overview of the Presence SIP Simulator...... 23

7.1 Traffic generated in a push-only system. a) Average number of messages per user and hour. b) Average number of kilobytes per userandhour...... 28 7.2 Traffic generated in a throttled push system at the throttling intervals 1, 5, 15 and 30 minutes. The upper most line in each graph is the un-throttled traffic. The left column show the average number of messages per user and hour and the right column showtheaveragenumberofkilobytes...... 29 7.3 The graphs illustrate the intersection value of how often a user can pull the server until the traffic generated exceeds the traffic inthecomparedpushmodel...... 32

vi 7.4 The intersection values for low and medium intensity levels. a) Subscription-based PoC model, b) The optimized subscription- basedOpt.I.model...... 33

8.1 Arriving process and service process used for calculating the num- berofErlangs...... 37 8.2 Messages propagated in uplink and downlink channel during registration. The “200OK” messages are marked with a P, S or N, describing an acknowledgement for a Publish, Subscribe or Notify message...... 38

C.1 Reservation of uplink and downlink channel when receiving push notification...... 53 C.2 Reservation of uplink and downlink channel when receiving throt- tlednotifications...... 54 C.3 Reservation of uplink and downlink channel when receiving pull notifications...... 55

vii

Chapter 1

Introduction

1.1 Background

Presence is a service where users can subscribe to presence information and receive updates of other users’ current state. The state of the user can, depending on the implementation, hold information on whether the user is online or not, current mood or geographical location. Today there exist several presence implementations designed for the Internet but unfortunately, the majority of them are incompatible with each other. When designing a presence service for cellular networks, new aspects regarding limited network resources and compatibility have to be considered. Presence generated traffic introduces new traffic patterns which differs from traffic generated by ordinary phone calls and streaming media applications. The main goal of this master’s thesis is to investigate and estimate the traffic generated by presence services for cellular networks. The thesis work has been conducted at AWARE, Advanced Wireless Algorithm Research, at Ericsson Research in Luleå, Sweden.

1.2 Objectives

The objectives of this master’s thesis are to study the effects that different designs of a presence service for Push to Talk over Cellular (PoC), have on presence generated traffic. This will be acquired by literature studies of both presence applications and standards, followed by modeling and implementation of simulation tools. The presence service impact on WCDMA radio resources should be analyzed and possibilities for optimizations of the presence service are to be investigated.

1 1.3 Document Outline

The thesis is structured in the following way. Section 2 explains the term presence and summarizes present presence applications and protocols. Following this, Section 3 describes three models of how presence information can be propagated to a user. Section 4, summarizes the presence SIP signaling according to the Push-to-Talk over Cellular (PoC) presence specification. A few modifications to the PoC presence specification in order to improve network communication efficiency, is suggested in Section 5. Section 6 explains the SIP Presence simulator, which is implemented in C and Matlab in order to simulate presence traffic. Section 7 presents simulation results of different presence models and Section 8 presents calculations and results of capacity comparisons between presence services and Voice over IP services. Section 9 holds a discussion of the results concluded in this master’s thesis together with suggestions for future work.

2 Chapter 2

Background

This section explains the term presence and what kind of information presence can consist of. Standards for presence are summarized and an overview of current presence applications and protocols is presented.

2.1 Presence

Presence, also known as presence information, is regarded as the willingness and availability to communicate across a set of devices. Presence can be provided to users as a service where a user (watcher) subscribes to presence information regarding other users (presentities). The watcher can subscribe to many presentities and organize them on a buddy-list. Using the buddy-list, the watcher receives the status of the presentities, which could include availability as online, oﬄine and do not disturb. Other presence information that can be included is the presentities geographical location and the person’s mood and preferred communication means.

2.2 Presence Information

Presence can consist of diﬀerent types of information that can be grouped into the following categories.

Usage Information The most basic feature a presence service can oﬀer, is information on whether the presentity is registered to the service or not. The natural states of the presentity are online and oﬄine.

Availability Information The next level of presence is to include availability information i.e., the pos- sibility to reach the presentity with an instant message, phone call etc. The

3 presentity’s status could be busy, away or do not disturb (DND). In a more advanced application, more speciﬁc states would exist. Examples of more speciﬁc states could be Out to Lunch and In Meeting.

Mood Information The presentity can publish her current mood to her friends. By publishing the mood, further messages between the presentity and watchers are encouraged. For example "Why are you sad Anne?". Examples of the mood of the presentity could be happy, angry and sad.

Geographical Information The user could in the simplest case manually edit its whereabouts, which is then sent to the watchers. This could for example be set to at work or at home. Ina more advanced case, the location of the user could be set automatically by the equipment using some kind of positioning system, i.e. GPS or by letting the cellular network calculate the position.

Reachability Presence information could also include the presentity’s supported and prefer- able communication means. The presentity could set priority on which kind of communication it prefers to be contacted by. For example instant message could have the highest priority 1, e-mail priority 5, phone call priority 10 and SMS priority 20.

2.3 Standards

Presence services have been used on the Internet since 1996 when the ﬁrst instant messaging application, ICQ [1] was developed. Presence services have become increasingly popular and today there exists many diﬀerent applications, which together attract millions of users. The applications have however been developed without any concern for standardization and the majority of them are unfortunately incompatible with each other. The Internet Engineering Task Force (IETF) [2] are currently writing standards on instant messaging and presence services. At the time of writing this thesis, there existed three working groups within IETF which dealt with presence and instant messaging.

IMPP - Instant Messaging and Presence Protocol IMPP’s [3] primary work was to define protocols and data formats necessary to build an Internet-scale end-user presence awareness, notification and instant messaging system. Its main task was to determine specific design goals and requirements for such a service. The goal has been reached and the work is now considered finished.

4 XMPP - Extensive Message and Presence Protocol XMPP [4] is a group of protocols for near real-time XML-based instant messaging and presence. The purpose of the XMPP working group is to adapt the XMPP for use as an IETF Instant Messaging and Presence technology. XMPP is also called the Jabber protocol and is further described in the Section 2.4.1.

SIMPLE - SIP for Instant Messaging and Presence Leveraging Ex- tensions This working group focuses on using SIP as the fundamental protocol for instant messaging and presence. The PoC presence speciﬁcation, which will be discussed later in this report, is based on the work of this group. SIMPLE [5] has produced several Request for Comments (RFCs) within the presence area and there are many Internet-drafts submitted for review. This is an active Working Group and the work continues.

2.4 Presence Applications and Protocols

Today there exist several implementations of presence and instant messaging. Most of them are used on the Internet where the network resources are not restricted in the same way as for wireless cellular networks. This section presents some applications and protocols that are used today for instant messaging and presence. The Session Initiation Protocol (SIP) [6], which is fundamental for the presence service described in this report, is summarized at the end of this section.

2.4.1 Jabber Jabber [7] is an instant messaging and presence application built on a set of open source XML streaming protocols. The Jabber protocols have recently been approved as standards by the IETF in the XMPP Working Group documents XMPP Core [8] and XMPP IM [9]. Streaming XML is a technique where instead of sending complete XML documents to the recipient, the document is declared as a stream and will be open during the session. The client and server can send multiple messages to each other within the same XML session, which provides close to real-time communication and minimal overhead. XMPP supports secure communication by means of Transport Layer Security (TLS) in a similar way as for IMAP and POP3 [15].

2.4.2 OSCAR OSCAR is an abbreviation for Open System For Communication in Realtime and is used by America Online Instant Messenger (AIM) [10]. The protocol is, contrary to the name, not an open protocol. OSCAR is a binary protocol and is incompatible with other chat systems as IRC and ICQ. However, America Online

5 bought Mirabilis ICQ and newer versions of ICQ will be using the OSCAR protocol.

2.4.3 Wireless Village Wireless Village (WV) [11] is a mobile Instant Messaging Presence Services (IMPS) initiative jointly founded by Ericsson, Nokia and Motorola. The spec- iﬁcations are based on IETF standards [12, 13] and IMPP CPIM model [14]. WV IMPS is developed for exchanging instant messages and presence information between mobile devices and the protocols are SIP based and designed and optimized for mobile devices and wireless networks. It can run over many transport layers and bearer protocols.

2.4.4 Windows Messenger and MSN Messenger Windows Messenger and MSN Messenger are two instant messaging and presence applications. Windows Messenger comes pre-installed with the Microsoft Windows XP operating system and the application is promoted as a practi- cal business application. MSN Messenger looks almost the same as Windows Messenger but is equipped with more “fun stuﬀ” like playing online games with friends. The Messenger applications were earlier based on the MSNP7 protocol but are now based on SIP and the work of IETFs SIMPLE group.

2.4.5 SIP The Session Initiation Protocol The Session Initiation Protocol (SIP) [6], is an application-level control protocol. The protocol is used for setting up, modifying and terminating sessions between one or more participants. The sessions could be multimedia conferences such as Internet telephone calls, video conferencing, presence or event notiﬁcation. SIP also provides mobility for users by its proxy functions i.e., the users register with a home SIP-server, which takes care of redirecting incoming connections (calls) to a new registered location. A SIP application establishes a session by inviting one or several users to a conference. The proxies redirect the call to the registered location of the users. The protocol then starts negotiations with the other entities regarding communication means i.e., which media protocols to use, voice only, video etc.

SIP provides ﬁve aspects of controlling multimedia sessions.

1. User location: determination of the end system to be used for communication. 2. User capabilities: determination of the media and media parameters to be used.

6 3. User availability: determination of the willingness of the called party to engage in communications. 4. Call setup: "ringing", establishment of call parameters at both called and calling party. 5. Call handling: including transfer and termination of calls.

A SIP Presence Session Figure 2.1 illustrates messages exchanged for a SIP presence session.

Presentity Server Watcher

200 OK

PUBLISH

200 OK

NOTIFY

200 OK

PUBLISH

200 OK NOTIFY

200 OK

Figure 2.1: A Presence SIP Session

As soon as the presentity’s presence device is turned on, it registers with the presence server and the server responds with a 200 OK message, indicating that the server has successfully understood the request. Each successful request is acknowledged with a 200 OK message. If the server or a user does not understand the request, it will return an error message with an error code specifying why the request cannot be handled. When the registration is completed, the presentity sends a PUBLISH message containing its present state, for example online, and information about mood and location. A watcher subscribes to the presentity by sending a SUBSCRIBE message to the presence server. After successful subscription regarding authentication and authorization, the server sends the presentity’s presence information in a NOTIFY message to the watcher. When the presentity changes its status, it

7 sends a new PUBLISH message containing the updated status to the server. Depending on the type of updating model, see Section 3, the server could either directly send an updated NOTIFY message to the watcher or it could wait until the watcher initiates a pull in order to fetch the information.

2.4.6 Signaling Compression (SigComp) IP messages are text-based and tend to be large. Signaling Compression (Sig- Comp) [16] is a solution for compressing application level protocols such as SIP and RTSP. SigComp can be seen as a special layer inserted between the application layer and the transport layer in the OSI protocol stack model. Frequently used terms in the SIP messages are stored in a dictionary, which is used to enhance the compression of the SIP messages sent between the terminal and the SIP proxy. Compression is especially important in wireless networks, since large text-based protocol messages consume a signiﬁcant part of the resources.

8 Chapter 3

Presence Generated Traﬃc and Presence Models

When designing and constructing 3G cellular networks, much of the focus has been on providing higher data rates to support services like video streaming, video calls and other real-time multimedia applications. Presence however, generates traffic with other characteristics than streaming media and has lately become of interest for traffic analysis. As explained above, changes of a presentity’s states would generate traffic that at the presence server is multiplexed to all watchers who are subscribing for that presentity. These messages are compared to streaming media very small and have a large overhead in terms of establishing connections between the wireless devices and base stations. Lim- iting the frequency of these messages would be highly desirable in order to minimize usage of network resources. The presence information updates can be propagated to the watchers through a push- or a pull model. The following sections describe the characteristics of each model and how they are used.

3.1 Pull-Based Presence Services

In a pull-based system, the watcher has to connect to the presence server every time it wants an update about the presentities on the buddy-list. This has to be done on a regular basis in order to keep the locally stored presence information up to date. By polling the presence server for information, there is a trade-off between limiting the presence traffic and keeping the local presence information accurate. In some cases, when you are interested if your boss is back at the office after lunch, it might not be crucial if the information is not updated instantly. It would be acceptable if the presence information updates a few minutes after the boss’ arrival. However, in other scenarios, time might be important and the time interval between pulls has to be small. Pulls could be triggered in more than one way. One solution could be to use a polling timer that triggers the

9 presence device to request presence updates every three minutes. But why need to update the presence information every third minute if the watcher keeps the mobile phone in its pocket for 2 hours? To limit the amount of traﬃc, the pulls could be triggered by the watchers actions instead of a timer. For example, when the watcher removes the key-lock for making a call, the pull could be activated and presence information be downloaded. The watcher will then receive the information when he or she needs it.

3.2 Push-Based Presence Services

The push-based system relies on the principle of pushing out updates as soon as a presentity has changed its status. A watcher subscribes to presence information of a group of presentities. After receiving the presentities’ initial presence information, it waits for future presence updates. When the presentity changes its status, it sends an update (PUBLISH) message to the presence server. The server checks which watchers subscribe to information regarding this presentity and forwards NOTIFY messages to all those subscribers/watchers.

3.2.1 Push-Throttle To limit the traffic in the push-based model, throttling of messages could be performed at the presence server. When the server receives updates from the presentities, it will store the updates for an amount of time depending on a throttling interval. The server can then group messages together regarding several presentities and send them to the watcher. Thereby reducing the number of messages being sent. One should have in mind that it is not in all situations that push-based systems induce more traffic than pull-based systems. By shrinking the polling interval, there is a point where the pull-based system will produce more traffic than in push systems. That is, if the watcher is polling the presence server for updates even though no presentity has changed its status, the watcher will generate traffic that would not exist in a push-based system.

10 Chapter 4

PoC Presence Speciﬁcation

This section explains how messages are exchanged between the users and the presence server specified by the Push-to-Talk over Cellular (PoC) Presence specification [17]. The purpose of this section is to make it easier to understand the improvements suggested for the PoC Presence specification in Section 5 and to understand the functionality of the SIP Presence Simulator, discussed in Section 6. To improve readability and to clarify some expressions used in this and the following sections, some definitions regarding the NOTIFY messages sent to the watchers are needed. A Full Notify update is the term used when one or several NOTIFY messages containing presence information of all users on the watcher’s buddy-list are sent to the watcher. A Partial Notify update is used when one or several NOTIFY messages containing only presence information about presentities on the user’s buddy-list that have changed their states since the last pull or throttle. A Single Notify update is a single NOTIFY message holding information of one single presentity. This could also be an empty NOTIFY message including only a NOTIFY header. The header only, is sent to the watcher in the case when the user pulls the server for a presence update but there is no new information to be sent back.

4.1 Message Exchange in Push-based Models

In this section, message transactions between the user and server are explained. In a two state model i.e., a presence service where the user is either registered or unregistered, messages can be generated at four phases illustrated by Figure 4.1. When the user is within the registration, re-registration or de-registration phase, traﬃc will be generated as a consequence of the user’s own actions. For example, when the user turns on its presence device, the device will register to the presence service and set up its subscriptions. In the presence event phase however, traﬃc is triggered due to the fact the presentities on the user’s buddy-list have changed their states. Since the presence model is push, the

11 Presence Event

Registration De−Registration

Re−Registration

Figure 4.1: Traffic generating phases in a push presence model with two states. server will send notifications to the watcher as a reaction to the presentities’ presence events. The traffic generating phases in the push-based model are further described below.

4.1.1 Registration In the ﬁrst stage, registration, the user exchanges messages with the server according to Figure 4.2.

User Server

PUBLISH

200 OK

Full NOTIFY

200 OK

Figure 4.2: Messages exchanged during the registration phase.

When the user changes its status from oﬄine to online, a PUBLISH message containing the new state is sent to the presence server. To be able to subscribe to presence information from other users, a SUBSCRIBE message is sent holding the type of presence information ( e.g., online/oﬄine, mood, geographical information ) to subscribe to and the preferred subscription time. As soon as the server has received these messages, it will check if the subscription time value is valid and send a Full Notify update with presence information about all presentities on the user’s buddy-list. The number of sent NOTIFY messages depends on how much presence information that is sent and how much data

12 each NOTIFY message can carry. There are also 200 OK messages, which are sent in each direction as acknowledgements for successful interpretation of the requests.

4.1.2 Presence Events When the user is registered to the service, it enters the presence event stage, thereby acting as a watcher, and will receive presence notiﬁcations as soon as any presentity on the user’s buddy-list changes its state. Figure 4.3 illustrates the messages exchanged when a presence event occurs.

User Server Watcher

PUBLISH

200 OK NOTIFY

200 OK

Figure 4.3: Messages exchanged when a presence event occurs, i.e., a presentity updates its presence information.

A presentity changing its state will send a PUBLISH message with its updated state. When the PUBLISH message is received at the server, the server will compose a Single NOTIFY message and send that message to all watchers who subscribes to presence information regarding this presentity. If throttling is used, PUBLISH messages from several presentities will be accumulated at the server and cumulative NOTIFY messages (Partial Notify update) will be sent to the watchers when the throttling timer expires.

4.1.3 Re-Registration Re-registrations are necessary in order to inform the server that the user is still connected to the network. The user needs to both re-subscribe to presence information and re-publish its current state.

13 User Server

PUBLISH

200 OK

Full NOTIFY

200 OK

Figure 4.4: Messages exchanged during re-registration.

The messages exchanged during re-subscription and illustrated by Figure 4.4 are the same type of messages as for registration. As soon as the user-initiated messages have been exchanged, the server will in the same manner as for a new registration send one or several notify messages to the user. The NOTIFY messages contain a Full Notify update of all presentities on the user’s buddy- list and a conﬁrmation of the new subscription time. Re-subscription has to be performed periodically, for example once every two hours. If the user has not performed a re-registration at the end of the subscription period, the server will mark the user as unregistered and ﬂush all state information regarding this user.

4.1.4 De-Registration When the user wants to de-register from the presence service, it has to unsubscribe so that no more NOTIFY messages are sent from the server. The user also has to revoke its published state by sending a new PUBLISH message indicating that he or she is no longer online.

User Server

PUBLISH

200 OK

Full NOTIFY

200 OK

Figure 4.5: Messages exchanged during de-registration.

14 To unsubscribe, a SUBSCRIBE message is sent with an expiration value set to zero. This indicates that the user wants to end the subscription. Worth noticing is that according to the PoC speciﬁcation, the server shall respond to an unsubscription with a Full Notify update to the user. This behaviour is further discussed in Section 5.3.

4.2 Message Exchange in Pull-based Model

The stages for a pull-based presence service are almost the same as for the push- based. One of the differences is that the presence event stage has been replaced with a pull stage. Traffic generated from within the pull stage is, as opposed to the presence event stage for push, initiated by the watcher and not by the presentities. This since the watchers will pull the server for presence updates instead of receiving them instantly when a presence event occurs. If no pulls were conducted, no traffic would be generated for the watcher regardless of how many presentities that change their states.

Pull

Registration De−Registration

Re−Registration

Figure 4.6: Traﬃc generating phases in a pull presence model with two states.

The registration phase, exchanges the same messages as described for the push-based model in Section 4.1.1. There is however some diﬀerences in the other phases that depend on the kind of pull system used. The pull system could either be subscription based or non-subscription based. A pull based system with no subscription implies that no SUBSCRIBE message has to be sent during re-registration and de-registration since there is no subscription to maintain. Subscriptions make it possible for the server to keep state information on the registered users. This can be used for Partial Notify updates in combination with pulls and is further explained in Section 5.4. Without subscription, all pulls would result in Full Notify updates, implying that the messages sent will be larger then necessary.

15 4.2.1 Pull A pull is triggered in one of the ways described in Section 3.1. In the subscription- less pull model, illustrated by Figure 4.7a, a pull is accomplished by sending a SUBSCRIBE message with an expire value set to zero. A SUBSCRIBE with an expiration value set to zero will trigger the same mechanisms within the server as for de-registration. The server will respond with a Full Notify update.

User Server User Server

SUBSCRIBE e = 0 SUBSCRIBE e = t

200 OK 200 OK

Full NOTIFY Partial NOTIFY

200 OK 200 OK

( a ) ( b )

Figure 4.7: a) Messages exchanged during subscription-less pull. The server interprets this as an un-subscription. b) Messages exchanged during subscription- based pull. The server interprets this as a pre-longing of the subscription.

Figure 4.7b illustrates the subscription-based pull, which actually is accomplished in combination with throttling. The throttling interval is set to inﬁnity and no PUBLISH messages will be sent to the watcher unless a pull is triggered. The user will send a SUBSCRIBE message with an expiration value identical to the time left of the subscription. Depending on the implementation, this could either result in a Full Notify update as for the subscription-less pull or it could result in a Partial Notify update. The partial update will only contain presence information that has changed since the previous pull.

16 Chapter 5

Optimizations and Improvements

In Section 3, it was explained how to limit presence traffic by using different types of presence update models, i.e. push, push-throttle and pull. This section goes a bit further and focuses on how changes and modifications to the PoC specification summarized in Section 4, could decrease network load. The messages and the interaction between the messages in Section 4.1 and 4.2 are defined by the PoC specification [17]. In order to decrease the amount of traffic in the network, some changes may have to be made to the standards. The improvements that could be made are located within the re-registration and de-registration phases.

5.1 Re-Registrations in Push-based Systems

In a push-based system, there is no need for sending complete presence information (Full Notify) to the subscriber each time it re-registers in order to prolong its subscription. Since the system is push-based, any changes of the presentities’ states would already have been propagated to the watcher and the locally stored presence information would be accurate.

5.2 Re-Registrations in Throttled and Pull-based Systems

According to the PoC speciﬁcation, a Full Notify update has to be sent to the subscriber at re-subscription. When throttling or pulls are used, presence messages are stored at the server as described in Section 3. In contrast to the push-only-model, this means that when a user re-registers, there might be presence information located at the presence server that has not yet been propagated to the user. In this case, it would be enough to send the presence

17 information that has changed since the last NOTIFY messages where received, i.e. a Partial Notify update. Sending a Full Notify of all presentities would be a waste of network capacity. Another option might be not to send any presence information at all to the user during re-registration. Since the throttled messages are frequently sent to the user at each throttling cycle and pulls are triggered due to the actions of the user, the user would still receive the presence update at the next throttling cycle or pull.

5.3 De-registrations

As explained in Section 4.1.4, a user who wants to de-register from the presence service has to send a SUBSCRIBE message to the server with an expires value set to zero. This will according to the standards trigger the server to send a Full Notify update to the user. If the presence model was push-based, the user would already have all presence information regarding its presentities. These messages would therefore not contribute with any new information. It would then be possible to decrease the amount of traffic in the network by not sending any new presence updates to the user at de-registration. There is also another argument for not sending any presence updates at de-registration. The user de- registers from the network since its presence device is turned off. If the device is turned off, the user will not have any use of the information that is downloaded. This is true not only for push-based models but also for pull-based models.

5.4 Pull Partial Notify Updates

Using a subscription-based pull system would enable Partial Notify of messages. When a SUBSCRIBE with expires equal to the time left of the subscription is received by the server, the server will send only presence information about presentities that have changed their states since last pull. Without subscription, the server would not know which presentities that have changed their states since last pull and making Partial Notiﬁes impossible.

18 Chapter 6

SIP Presence Simulator

To visualize the amount of traffic generated by the users and the presence server, simulations have been performed. The requirements of the simulator was to be able to simulate up to 1 000 users who moved in and out of a configurable number of states, e.g. online, offline etc. The purpose of simulating the system is to be able to study the amount of generated traffic based on a number of configuration parameters listed in the next subsection. By varying the parameters, it is possible to investigate how to set up the configuration so that traffic is kept on a reasonable level while in mean time, allowing the users to receive presence information that is not outdated. This section starts with a description of the configurable input parameters for the simulator and how the output data is stored. Following this, a short discussion of the pros and cons of the programming language chosen to simulate presence is given and finally the design and operation is presented.

6.1 Simulation Inputs

The simulator is fed by several input parameters such as the number of users in the system, the different states a user could enter and the intensities used for travelling in and out of these states. The simulator also supports different modes of operation depending on what kind of system that is simulated i.e. a pull- based, push-based or a push-based system with throttling. Some parameters are specific for the system model, for example the throttling interval in the push- based throttling model. Table 6.1 gives a short explanation of the simulation input parameters.

6.2 Simulation Outputs

Data from the simulations are stored in a 3-dimensional matrix, illustrated by Figure 6.1. The dimensions represent message type, simulated user and time. The message-dimension keeps information of how many messages and how large

19 Table 6.1: Overview of the SIP Presence Simulator parameters.

Parameter Description Typical Value SimTime Length of simulation in minutes. Nb_users The number of users to be simulated 1-1000 Group_size_max 30 The amount of users in a user’s buddy-list Group_size_min 5 The granularity of the data that is collected. Stats_slice 5 minutes Data is added together for every time_slice minutes. 1, Push SimType Type of Presence model that should be simulated. 2, Push-Throttle 3, Pull Timer_throttl Throttle timer. Timer_rereg Re-registration timer 120 minutes PresNotify Number of presentities per NOTIFY message 3 PullIntensity Intensity of pull requests per hour 1.18 Initial distribution of users in each state. InitStates Example: [0.2, 0.7, 0.1] 20% state 1 70% state 2 and 10 % state 3. Intensity of transitions between each state per hour Example: [0.0, 1.2 ; 0.5, 0.0] A user moves from state 1 to state 2 SimStates 1.2 times per hours A user moves from state 2 to state 1 0.5 times per hour.

20 NOTIFY # NOTIFY BYTES PUBLISH # PUBLISH BYTES SUBSCRIBE # SUBSCRIBE BYTES DATA MATRIX 200OK up # 200OK up BYTES 200OK down # 200OK down BYTES Time Slot

User

Figure 6.1: The data structure where simulation data is stored. The number of messages and message sizes for each type and user is stored in a time slot corresponding to the time of the event. they were for each message type sent during the simulation. The user-dimension makes it possible to collect data for a specific user and compare traffic generated by different users within the same simulation. The last dimension is divided into time slots. The length of a time slot is a configurable parameter and could be for example one minute. All data of the same type within a time slot is added together.

6.3 Programming Language Evaluation

The programming language chosen for the simulator was Matlab. The language has both its advantages and drawbacks. The biggest advantage is that Matlab is equipped with a large library of built-in functions and scripts, which are usable for collecting and structuring gathered data. Other advantages are the many possibilities to represent the data in form of plots and diagrams. Much of the data processing tools are therefore given, which makes it possible to concentrate on the main task to simulate presence. It is also fairly easy to debug the code and write small test scripts that can verify the correctness of the diﬀerent simulator modules. Choosing Matlab as the platform to simulate presence on also comes with some drawbacks. Compared to a real object-oriented language such as Java, which is an excellent language for writing event-driven simulators, the Matlab programs tend to run slowly. The most CPU-intense calculations of the simulation are the operations aﬀecting the event-queue. To work around this problem, all queue operations such as inserting, deleting and extracting elements from the queue are written in C. This is further described in Section 6.4.

21 6.4 Principles of Operation and Design of the Simulator

The task of the simulator is to simulate users entering and leaving a conﬁgurable number of presence states. The presence states, as illustrated in Figure 6.2, could for example be an oﬄine, an online and an away state.

State

Away

Online

Offline

Time

Figure 6.2: The figure illustrates how a user moves between the predefined states. The time spent within each state is exponentially distributed with the mean value specified by the simulation inputs.

All users have a buddy-list with a number of presentities. The presentities are randomly chosen among the users of the simulated population. A user will during time travel in and out of the presence states and generate traﬃc both for itself and for users who have subscribed to its presence information. The time spent in each state is exponentially distributed with a mean value reﬂecting the average time that a user will spend in that particular state.

6.4.1 System Overview The simulator system consists of four main modules which all interact with each other. The modules are the Main module, the Event Execution module, the Queue Processing module and the Data Collecting module. All modules are written in Matlab script language except the Queue Processing module, which is written in C in order to increase simulation performance.

22 Main Module Execution Module Data Collecting Module Extracts events Executes event from queue and Collects data send to execution

Extract Insert Delete

Queue Interface

Queue Core

C− Implementation

Figure 6.3: System Overview of the Presence SIP Simulator.

The simulator is event-driven and all events that are to be executed within the simulator are called simulation events. Simulator events should not be con- fused with presence events. A presence event is generated when a user changes its current presence information, for example changing its current state to online or updating its geographical location.

The task of the Main module is to initialize the simulator by creating all users and to set their initial presence states and presentity lists. When initialization is done, it will move on to extracting simulation events from the simulator’s event queue. The extracted simulation events are sent to the Execution Module which executes them one by one.

The Execution module examines the type of the simulation event and executes the event according to its type. There are four types of simulation events; State Transition events, Re-registration events, Pull and Throttle events. The actions taken for each type of simulation event are described in Section 6.4.3.

The Data Collection module is accessed by the Execution module in order to register all messages sent between the users and the server. How the data is stored is described in Section 6.2.

The Queue Processing module is the core of the simulator. Matlab is quite slow when it comes to inserting and extracting elements of a dynamical data structure such as the simulator event queue. To reduce this performance penalty, all queue-processing operations have been written in C. The queue only exists in a C-context and is accessed by Matlab through an interface for inserting,

23 extracting and removing simulation events.

6.4.2 Operation When the simulation starts, the simulator enters the initialization phase where it initializes the system to simulate a model according to the specified input parameters. The users are created and their initial states are generated. Each user receives a presentity (buddy)-list, where the size of the list has been chosen uniformly between the configurable minimum and maximum buddy-list size parameters. The first simulation event for each user is inserted into the event queue. Other simulation events such as initial pull/throttle events and initial re-registration events are also generated. When all users and the server have been created, the simulator enters the second phase where it executes the simulation events one at a time. The simulator keeps on executing the events until no more events exist or if the predefined simulation time has been reached.

6.4.3 Simulation Events The simulation events are generated diﬀerently depending on their type and characteristics. As mentioned above, there are four types of simulation events. The State Transition and Pull events are generated according to an intensity parameter. The State Transition intensity parameter represents the mean value of the exponentially distributed time a user will spend in a particular state. The pull intensity parameter represents the average time between pulls. For the simulation event types Throttle and Re-registration, timers are used to generate the events periodically. When a Throttle or Re-registration event has been executed, a new event of the same type is generated and scheduled for execution. The purpose and actions taken for each simulation event is presented in the following paragraphs.

Re-Registration Events

When a user is connected to the presence server, there is a need for refreshing published presence information and subscriptions, in order to inform the presence service that the user is still connected to the network. Refreshing this information is done by sending a new PUBLISH and SUBSCRIBE message to the server. This is solved in the simulator by the Re-registration simulation event. When this event is executed, traﬃc for the PUBLISH and SUBSCRIBE messages are registered in the Data Collecting module and the re-registration timer is reset.

State Transition Events

A state transition event is triggered within the simulator when a user changes its current state. In the simplest model, which contains only two states, online and oﬄine, the state transitions coincide with registration to and de-registration

24 from the presence service. Registrations and de-registrations are special cases of transition events since during these simulation events, subscriptions have to be set up and torn down in order to guarantee that information inserted into the data module is only registered for registered users. Depending on the simulation model, push, pull or push-throttle, the messages are registered diﬀerently in the Data Collection module. If push is used, messages are registered without delay for all registered watchers who have subscribed to presence information regarding the presentity that changed its state. If the model simulated is pull or push-throttle, the traﬃc caused by the presence event is registered temporary in another data structure until a watcher executes a Pull or Throttle simulation event.

Pull and Throttling Events

The pull and throttling events are only used in the simulator if the presence model is pull or push-throttle. In the pull model, the events are generated according to the pull intensity parameter. This parameter reﬂects the case mentioned in Section 3.1, when a pull is triggered as a reaction to the users actions. In push-throttling, the events are instead generated according to a throttling timer. The actions taken when a pull or throttling event occurs are almost the same in both models. The simulator investigates if there have been any state transitions, concerning the watcher who executes this simulation event, since the last pull or throttle event. If there is, messages for both performing the pull and for the downloading presence information are registered in the data collection module. The main diﬀerence between a pull and a throttling event is that in the push-throttle model, no messages for making a pull are registered.

6.5 Veriﬁcation of Simulator Correctness

To verify that the simulator produces reasonable outputs, the outputs have been compared to theoretical calculations based on presence models made by [21]. An example of the results of the comparison can be found in Appendix B.

Chapter 7

Estimating Presence Traﬃc

This section presents the results from simulations performed in order to estimate the traffic generated by different presence models. Focus has been on comparing pull and push by investigating how much more efficient pull is over push. Simulations have also been performed to investigate push-throttle. Traffic generated by a presence service depends on many parameters. Some of them are; how many people are using the service, how often do they change their states, how many people are included on their buddy-lists etc. It would not be possible to investigate all possibilities but to get an idea of the amount of traffic generated by different parameters, three intensity levels have been used.

– Low Intensity (0.52) – online and offline – Medium Intensity (0.84) – online, offline and away – High Intensity (3.3) – online, offline, away and telephone The intensity levels have different amount of states in which a user can move in and out of. By adding more states to a level, the users will change states more often. The number written after each intensity level represents the total presence event intensity i.e., the average number of state transitions a user does per hour. The calculations of the intensities can be found in Appendix A.

7.1 Traﬃc Generated in Push

Figure 7.1 illustrates the traﬃc generated in a push-based system without throttling. The graphs show the number of messages and the amount of data generated with respect to the number of users on a watchers buddy-list.

27 Traffic Measured in Number of Messages Traffic Measured in Bytes

400 160

Low 350 Medium 140 High

300 120

250 100

200 80

150 60

100 40 Number of kilobytes per Hour for Each User Number of Messages per Hour for Each User

50 20

0 0 0 20 40 60 0 20 40 60

Group Size Group Size

( a ) ( b )

Figure 7.1: Traﬃc generated in a push-only system. a) Average number of messages per user and hour. b) Average number of kilobytes per user and hour.

Since no mechanism is used in order to limit the amount of messages sent, the traffic increases rapidly when the size of a user’s buddy-list increases. The increase of traffic that is generated by adding an away state (medium level) is small in comparison to adding an on phone state (high level). The high increase of traffic generated by an on phone state is explained by the fact that phone calls happen more often than a user enters an away state. The fact that the time spent in a phone call is often very short also increases the traffic.

7.2 Traﬃc Generated in Push-Throttle

Simulations have been performed to illustrate the effects of throttling to a push- based presence system. The order of decrease in the amount of traffic depends on how long the chosen throttling interval is. If the chosen throttling interval was zero minutes, the messages would be un-throttled. On the other hand, if the interval were infinite, no presence updates at all would propagate to the user. Hence there is a trade off between lessen the number of presence notification messages and the ability to have updated accurate information at the watcher. To visualize the impact of different throttling intervals, four throttling intervals have been used in Figure 7.2. The intervals are 1 minute, 5 minutes, 15 minutes and 30 minutes. The left column of graphs in Figure 7.2 represents the average number of messages a user will receive and send for low, medium and high intensity levels. The right column represents the traffic measured in kilobytes for each of the intensity levels. Within each graph, the amount of traffic generated for the specified throttling intervals are represented. As a reference, the number of messages and kilobytes for un-throttled messages are also shown.

28 Throttling Low Intensity Throttling Low Intensity 80 40 Un−throttled 1 min 60 5 min 30 15 min 30 min 40 20

20 10

0 kB per User and Hour 0 0 20 40 60 0 20 40 60

Messages per User and Hour Group Size Group Size Throttling Medium Intensity Throttling Medium Intensity 150 50 40 100 30 20 50 10

0 kB per User and Hour 0 0 20 40 60 0 20 40 60 Messages per User and Hour Group Size Group Size Throttling High Intensity Throttling High Intensity 400 200

300 150

200 100

100 50

0 kB per User and Hour 0 0 20 40 60 0 20 40 60

Messages per User and Hour Group Size Group Size

Figure 7.2: Traﬃc generated in a throttled push system at the throttling intervals 1, 5, 15 and 30 minutes. The upper most line in each graph is the un-throttled traﬃc. The left column show the average number of messages per user and hour and the right column show the average number of kilobytes.

From the graphs it is possible to see that even for throttled messages, group sizes and intensity levels have a great impact on the generated traffic. Not too surprisingly, the largest traffic decrease is achieved for high intensity of presence events. For low presence event rates, the effects of throttling are almost negligible and the throttling interval has to be large in order to lessen the amount

29 of traffic. Table 7.1 shows, for the three defined intensity levels, the benefits gained at a user group of 20 users.

Table 7.1: The beneﬁts gained at diﬀerent throttling intervals at a group size of 20 users, measured in number of messages per hour and user.

Throttling Low Intensity Medium Intensity High Intensity Interval Level Level Level (Minutes) (# Messages) (# Messages) (# Messages) Un-throttled 26 (0%) 37 (0%) 132 (0%) 1 24 (-7.7%) 34 (-8.1%) 83 (-37.1%) 5 19 (-26.9%) 25 (-32.4%) 48 (-63.6%) 15 15 (-42.3%) 18 (-51.4%) 36 (-72.7%) 30 14 (-46.2%) 16 (-56.8%) 28 (-78.8%)

For high intensity rates, it is possible to decrease the number of messages by almost 40% with a throttling interval as small as 1 minute. To achieve the same relative reduction of messages in the low intensity simulation, the throttling interval has to be between 10-15 minutes.

When comparing the reduction of the traffic measured in kilobytes, the relative improvements are smaller but the same pattern of larger benefits in a high intensity than a low intensity simulation remains. Table 7.2 shows the effect of throttling measured in kilobytes.

Table 7.2: The beneﬁts gained at diﬀerent throttling intervals at a group size of 20 users, measured in kilobytes per hour and user.

Throttling Low Intensity Medium Intensity High Intensity Interval Level Level Level (Minutes) [kB] [kB] [kB] Un-throttled 12.1 (0%) 16.6 (0%) 56.6 (0%) 1 11.7 (-3.3%) 16.0 (-3.6%) 42.5 (-24.9%) 5 10.2 (-15.7%) 13.3 (-17.4%) 29.9 (-47.2%) 15 8.8 (-27.3%) 11.2 (-32.5%) 22.5 (-60.2%) 30 8.1 (-31.4%) 10.1 (-39.2%) 17.5 (-69.1%)

The improvements measured in kilobytes are smaller since even though fewer messages have to be sent, the messages grow larger. The reduction in kilobytes depends on that several presence messages can share a NOTIFY header when they are combined into larger NOTIFY messages. There are also fewer 200 OK messages sent as a response to the NOTIFY messages which also reduces the

30 traﬃc.

7.3 Comparison of Push and Pull

This subsection presents a comparison of a push-based system and four pull- based systems. The four pull systems used are based on the modifications suggested for the PoC presence specification in Section 4. Table 7.3 shows for the four pull models, their characteristics and the message types exchanged at each of the phases as defined in Section 4.2. For example, in the subscription-based standard model (PoC), PUBLISH, SUBSCRIBE and Full NOTIFY update messages are sent at registration, re-registration and de-registration. When a pull is triggered, a SUBSCRIBE message is sent and as reply, Partial NOTIFY messages are sent to the watcher.

Table 7.3: The characteristics of the four compared pull models. P.S is short for Partial (Single) Notify.

Design MSG Reg Pull Re-Reg De-Reg Subscription-less Publish x x x (Standard) Subscribe x x Notify Full Full Subscription-based Publish x x x PoC Subscribe x x x x (Standard) Notify Full P.S Full Full Subscription-based Publish x x x Opt. I Subscribe x x x x (Not standard) Notify Full P.S P.S P.S Subscription-based Publish x x x Opt. II Subscribe x x x x (Not Standard) Notify Full P.S Single Single

The first design is when pull is used without subscription and according to standards. The only SUBSCRIBE messages sent are for initial update at registration and for requesting presence updates when a pull is triggered. The rest of the designs are subscription based. The second one is the design specified by the PoC specification and uses Full Notify messages at re-registration and de-registration. The third one is referred to as Opt. I. and uses Partial updates instead of Full updates at re- and de-registration. The last one, Opt. II, is an ideal case with no updates at all at re-registration and de-registration. In a pull-based system, where pulls are triggered according to a user’s actions, it is interesting to know when pull is favorable compared to push. That is, how often can a user pull the server for presence information until the generated

31 traffic exceeds the traffic that would have been generated in a push-system? To answer this question, the simulation results of the four compared pull-designs are presented in Figure 7.3. The graphs show for different groups sizes, the intersection value when the pull-system generates the same amount of traffic as the comparable push system. As long as the number of pulls are kept below each curve or line, the pull system will generate less traffic than the push- system. The three intensity levels low, medium and high are represented within each graph. The push based system used as reference is slightly optimized with Partial updates at re-registration and de-registration.

Subscription−less Subscription−based (standard) PoC (standard) 10 100

8 80

6 60

4 40 Pulls per Hour Pulls per Hour 2 20

0 0 0 20 40 60 0 20 40 60 Group Size Group Size Low ( a ) Medium ( b ) High Subscription−based Subscription−based Opt. I.(not standard) Opt. II. (not standard) 100 100

80 80

60 60

40 40 Pulls per Hour Pulls per Hour 20 20

0 0 0 20 40 60 0 20 40 60 Group Size Group Size ( c ) ( d )

Figure 7.3: The graphs illustrate the intersection value of how often a user can pull the server until the traﬃc generated exceeds the traﬃc in the compared push model.

Figure 7.3a is the result of a subscription-less model. Since no subscriptions are maintained, Full Notify updates have to be sent to the user every time it performs a pull. This implies that presence information for all presentities on the watcher’s buddy-list will be downloaded even if the status of the presentities has not changed since last pull. That is why the value of intersection will stabilize at a certain value when the group size increases. Figure 7.3b represents the result of the subscription-based pull-system that is according to the PoC speciﬁcation.

32 Figure 7.3c are the results of the Opt. I, design, where the Full Notify updates at re-registration and de-registration have been replaced with Partial updates as suggested in Section 5. Figure 7.3d is the results of the last model Opt. II, where no NOTIFY messages are sent at de-registration and re-registration. When investigating the traffic for the three subscription-based models, the differences are almost not noticeable for high intensity simulations. The reason for this is that the suggested improvements are located within phases that do not directly affect the number of pulls performed. The suggested improvements are located within the re-registration phase, which occurs periodically approximately once every two hours, much less frequent than the presence updates. In reality, it is likely that the number of pulls performed per hour will be kept on a reasonable level since they are manually initiated by the user. The improvements suggested will therefore have a larger impact. Figure 7.4 below, shows the PoC standard subscription-based model and the optimized Opt. I. model for low and medium intensity levels. The differences between the Opt. I. and Opt. II models are negligible.

Susbcription−based PoC Subscription−based Opt. I.

15 20

15 10

10 Pulls per Hour Pulls per Hour

0 0 10 20 30 40 50 60 10 20 30 40 50 60 Group Size Group Size

( a ) ( b )

Figure 7.4: The intersection values for low and medium intensity levels. a) Subscription-based PoC model, b) The optimized subscription-based Opt. I. model.

Chapter 8

Capacity Comparison of Presence and VoIP

In the previous sections, it has been shown how many messages and how much traffic that is generated by different types of presence services. However, in order to estimate how much of the radio resources a presence service requires, presence has been put in proportion to the Voice over IP (VoIP) packet-switched service. VoIP sessions use the same protocol for initiating communications as presence, namely the SIP protocol. To better understand the comparisons and the results, the next subsection gives a brief introduction of the radio technology Wideband Code Division Multiple Access (WCDMA). The Erlang unit, a unit used for calculating traffic load in telecommunication systems is also presented.

8.1 Brief Introduction to WCDMA

WCDMA is a radio technology used for the third generation mobile communication system (3G). When a mobile device wants to send data via the base station, a radio access bearer is set up with a dedicated channel providing a specific bandwidth. Depending on the WCDMA release and implementation, different bit rates are available. Typical bit rates are 16, 32, 64 and 128 kbps. In the calculations used for the comparison of presence and VoIP, the bandwidth is assumed to be 16kbps which should be close to optimal for VoIP. That is, using dedicated bearers with higher bandwidths is a waste of resources. If all resources within one cell i.e., the area covered by a single base station, were dedicated to 16kbps channels, the theoretical total number of channels can be calculated by M 1 < 1, (8.1) SF i=1 i X where M is the number of channels and SF is the Spreading Factor. All data sent within a channel has to be coded with a specific code in order to distinguish the

35 data transmitted in that channel from the other channels. The number of codes are limited and depends on the total capacity of the cell. The spreading factor is a term used for specifying how large the code has to be in order to provide a specific bandwidth. To achieve a bandwidth of 16kbps, a spreading factor of 128 is needed. According to Formula 8.1, the theoretical total number of concurrent 16kbps channels are therefore 128 channels. In practice only about 60% of the channels are used for user data. The other 40% are reserved by the network operator for system management operations e.g., session handover between base stations. The amount of resources which are reserved by the network operator is a configurable parameter and can be tweaked in order to improve network capacity. For more details of WCDMA networks see [20]. If a message of 1kB is to be sent over a 16kbps channel, the time for trans- mitting the message would be 0.5s. However, there is some overhead that has to be included in order to set up the dedicated channel prior to sending the message and to tear it down after the message has been sent. There is also a small configurable delay of 1s until the channel is torn down. This delay is called release timer and the purpose of the delay is to keep the channel reserved if subsequent messages are to be sent. The setup and tear down times are assumed to be 0.7s and 0.5s+1s=1.5s. This gives a total time of 2.7s for sending a message of 1kB. All other delays such as processing times in proxies etc. are neglected. The propagation times calculated in the following comparisons are basically made as described above with a few exceptions which are mentioned in Section 8.3.

8.2 The Erlang Unit

An Erlang, is a unit for measuring traﬃc load within telecommunication systems. The unit represents the quotient of the intensity of arriving events and the intensity of the time for serving these events, which are described by ﬁgure 8.1.

36 Time between Duration calls of a call 1 / λ 1 / λ

1 / µ 1 / µ 1 / µ

Erlang ρ = λ / µ

Figure 8.1: Arriving process and service process used for calculating the number of Erlangs.

Imagine a user receiving and making phone calls at some average rate. The average time between each phone call (arriving process) is 1/λ hours and the duration of each call (service process) is 1/µ hours. The number of Erlangs generated by that user is then λ/µ Erlangs. If the serving rate equals the arriving rate, the user will generate 1 Erlang, which indicates that all resources for that channel are occupied. 1 Erlang can also be achieved if two channels were used to 50% or four channels were used to 25% etc. The total amount of resources for a speciﬁc number of channels within one cell can be retrieved from an Erlang table [18]. To retrieve the number of Erlangs, one has to specify a blocking probability. The blocking probability is the probability that all resources are occupied at the moment when a user wishes to make a call. So, assuming that the total number of usable 16kbps channels within one cell is 0.6∗128 = 76 channels, then according to the Erlang table, a blocking percentage of 2% implies that a cell can support up to 64.857 Erlangs. The underlying assumption is that the arriving and serving processes are exponentially distributed. However, according to [19], the results are valid also for other distributions.

8.3 Calculations of Presence and VoIP Compar- ison

Calculations for VoIP generated traffic have already been performed by [21] and the conclusion is that VoIP traffic generates approximately 16mE per user. In 1 this case, a phone call is expected to occur once every 1 2 hour and the average length of the call is about 90s. This implies that the theoretical total number of VoIP users within one cell is 4053. The calculations for presence-generated traffic measured in Erlangs are described in this subsection. The uplink channel

37 is not code limited in the same way as the downlink channel so we are only considering the downlink channel in the following capacity estimations. The results in this section are based on the intensities deﬁned in Section 7 for group sizes of 5, 10 and 15 users. The calculations are made for each of the phases explained in Section 4, namely registration, re-registration, receiving of presence event, receiving of throttled messages, pull messages and de-registration. The calculations for the registration phase are presented here and the formulas describing the other phases can be found in Appendix C.1. To calculate the serving process during registration, one has to know the time it takes to transfer each message and the setup, release delay and tear down times. The sum of the release delay and tear down time in the following sections are for simplicity referred to as tear down time.

Channel Publish Subscribe 200OK 200 OK Channel Setup N N Down UPLINK t Channel Channel 200OK 200OK Notify Notify Down Setup P S DOWNLINK t Setup, Tear down time Propagation time for sending message Idle time. Waiting for message

Figure 8.2: Messages propagated in uplink and downlink channel during registration. The “200OK” messages are marked with a P, S or N, describing an acknowledgement for a Publish, Subscribe or Notify message.

The traﬃc is divided into messages sent from the user to the server (uplink) and from the server to the user (downlink). Figure 8.2 illustrates the messages sent both uplink and downlink during registration. The ﬁgure shows the current state of the link, whether it is being set up or tore down, sending data or is idling. The number and sizes of the NOTIFY messages depends on the group sizes since each NOTIFY message can hold information of up to three presentities. The formula for the uplink channel is given by

′ ′ ′ ′ tup = tsetup +tpublish +tsetup +t200p+tsubscribe +t200s +n∗(tnotify +t200N )+tdown, (8.2) where prime terms represents idle time when no information is sent on this channel. The factor n depends on how many NOTIFY messages that is to be sent. The 200OK messages are marked with a P, S or N, indicating an acknowledgement for a PUBLISH, SUBSCRIBE or NOTIFY message. The

38 formula for downlink is

′ ′ tdown = tsetup +t200p +tsubscribe +t200s +n∗tnotify +(n−1)∗t200N +tdown. (8.3)

The sizes of the message types have been estimated to 800B for PUBLISH, 400B for 200OKP , 600B for SUBSCRIBE, 400B for 200OKS, 350B for NOTIFY header and another 350B for each presentity within that NOTIFY message and 150B for 200OKN . With a bit rate of 16kbps and channel setup and tear down times of 0,7s and 1.5s, the total time the uplink channel is reserved is 5.38s, 6,75s and 7,88s depending on a buddy-list size of 5, 10 and 15 users. The downlink channel is reserved for 4.23s, 5.65s, and 6.80s. The serving process µ can now be determined on per hour basis and for a user group of 5 users, 1 µ = 4.23s ≈ 851. (8.4) 3600s The next step is to determine the arriving process λ i.e., how often registrations occur. Registrations are assumed to occur at a frequency of 2.27 registrations per hour. This number is scaled by a factor 0.08, since only 8% of the users are assumed to be unregistered. The other 92% of the users are already registered to the service and does not perform any initial registrations at this time. The Erlangs generated during registration for a user group of 5 users is given by λ 0.08 ∗ 2.27 ρ = = ≈ 0.21 mE (8.5) µ 851 and the result for diﬀerent group sizes are presented in Table 8.1 .

Table 8.1: The number of Erlangs generated per presence enabled user during registration for downlink channel at group sizes of 5, 10 and 15 users.

Group Size 5 10 15 Downlink Channel 0.21 mE 0.29 mE 0.34 mE

8.4 Results of Presence VoIP Comparison

This subsection presents the results of the presence and VoIP capacity calculations. Table 8.2 summarizes the number of Erlangs generated in the diﬀerent phases for the downlink channel. The traﬃc has been calculated for group sizes of 5, 10 and 15 users and at the end of the table, the total sum for push-only, push-throttle with 10 minutes interval and pull at a rate of 1.18 pulls per hour are presented. The presented results in Table 8.2 are based on the low intensity level. Results for the high intensity level can be found in Appendix C.2

39 Table 8.2: Erlangs generated at diﬀerent traﬃc generating phases for group sizes at 5, 10 and 15 users.

Traﬃc Generating Phase Downlink [mE] Group Size 5 10 15 Registration 0.21 0.29 0.34 Re-Registration 0.52 0.70 0.84 Push Update 1.7 3.4 5.1 Push Throttling Update (10 minutes) 1.3 2.3 3.0 Pull Update (51 minutes) 0.9 1.0 1.1 De-Registration 0.22 0.29 0.35 Total Sum per User in Push 2.7 4.7 6.6 Total Sum per User in Throttle 2.3 3.6 4.5 Total Sum per User in Pull 1.9 2.3 2.7

Table 8.2 shows in accordance with the results from Section 7 that the majority of traffic is generated when the information updates (NOTIFY messages), are sent to the watcher. By using throttling, less network resources are needed and this is further limited by using pulls. The total sum for the different models can be compared to the VoIP generated traffic, where each user gives rise to 16mE. To get a more concrete image of VoIP and presence capacity, the total theoretical number of users that can be supported within one cell is calculated. Table 8.3 shows the number of presence users supported in one cell for push- only, push-throttle and pull for different group sizes and at the low intensity level. The table also shows the total number of users if they use both VoIP and presence services. Table 8.4 shows the results for the high intensity level.

Table 8.3: Theoretical number of concurrent low intensity presence and presence + VoIP users. Values in percentage represents the decrease of users relative to if no presence service was used.

Notiﬁcation Method Group Size 5 10 15 # VoIP Users Only 4053 # Push Users Only 24462 13897 9792 # Push + VoIP Users 3477 (-14.2%) 3138 (-22.6%) 2867 (-29.3%) # Throttle Users Only 28158 18234 14428 # Throttle + VoIP Users 3543 (-12.6%) 3316 (-18.2%) 3164 (-21.9%) # Pull Users Only 35116 28508 24430 # Pull + VoIP Users 3634 (-10.3%) 3549 (-12.4%) 3477 (-14.2%)

40 Table 8.4: Theoretical number of concurrent high intensity presence and presence + VoIP users. Values in percentage represents the decrease of users relative to if no presence service was used.

Notiﬁcation Method Group Size 5 10 15 # VoIP Users Only 4053 # Push Users Only 5570 2863 1930 # Push + VoIP Users 2346 (-42.1%) 1678 (-58.6%) 1308 (-67.7%) # Throttle Users Only 13675 9895 8191 # Throttle + VoIP Users 3127 (-22.8%) 2876 (-29.0%) 2712 (-33.1%) # Pull Users Only 32378 24872 19792 # Pull + VoIP Users 3603 (-11.1%) 3485 (-14.0%) 3364 (-17.0%)

The total number of users supported within one cell, which only uses VoIP and no presence service, has been calculated to 4053 users. The results show that using push or throttling, the number of supported VoIP and presence users decreases rapidly with increasing presence event intensity and group size. For pull, which is the notiﬁcation method that generates the least network traﬃc, the number of supported users decreases with about 10-17%.

Chapter 9

Discussion

Traffic generated by presence services depends mostly on the number of states a user can enter and the sizes of the users’ buddy-lists. The types of states, e.g., online, on phone etc, have also some impact on the traffic since some states are more likely to be used than others. For example switching between the online and offline states occurs much less frequent than entering an on phone state which could automatically be entered each time the user receives or makes a phone call. In reality, adding more states to the service might not give influence to higher amounts of network traffic. The reason for this is that a person is not interested in manually changing his or her state all the time. It would be too tiring. The traffic analysis in this report has been concentrated on traffic generated by availability information, e.g, online, offline, and away type of information. A more mature presence service would however include other types of information, see Section 2.2. Presence information that would induce really high amounts of traffic are events that are generated without any kind of human intervention. An example could be a GPS device, publishing the current position of presentity every 20 meters it moves. This might look harmless but if the presentity travels by car, it will start sending PUBLISH messages at a rate of more than 20 messages per second. This would correspond to a presence event intensity of 72 000 presence events per hour. Even though the sizes of the messages generated by presence services seem to be small, the high frequency of the them have a great impact on wireless networks. Pulls and throttling have been shown to be effective solutions to limit the frequency of these messages. Limiting the frequency of the messages sent is important since sending small bursts of traffic consumes an overhead in terms of setting up and tearing down the radio bearers. This overhead is often quite large in comparison to the presence message that is to be sent and efficiency is gained by combining several messages together. The first releases of the PoC Presence service will only support two availability states, registered and not registered. The improvements made by throttling these messages are small but as the presence service grows with more states and information types, throttling or pulls will be required.

43 The capacity calculations in Section 8 have shown that a presence service will use up much of the network resources that could have been used for VoIP traffic. In reality, this is not entirely true since VoIP and presence traffic will be using different priority levels, where VoIP calls have higher priority. The results of the calculations are still interesting in order to give an estimation of the resources needed by presence. As explained in Section 7, the traffic generated by the presence service depends on many parameters. The results presented in this thesis are based on just a few of those parameters. By performing capacity calculations on other values of throttling intervals, presence event intensities and pull intervals, might yield other results. The capacity calculations presented in this report are based on the assumption that 92% of the users are registered. The reason for this was to produce a scenario of a really busy working day. Normally the number of registered users might be lower and give rise to less presence traffic. The improvements gained from the modifications of the PoC Presence specification suggested in section 5 do not yield the same decrease in network load as tweaking of the pull and throttling parameters would give. This depends on the presence updates generated with high intensity of presence events tend to occur more frequently than messages generated due to re- and de-registrations. How- ever, if the frequency of notifications could be kept on a reasonable level using a pull-based presence service, the effects of removing the Full Notify messages at re- and de-registration would be more noticeable. By adjusting WCDMA network parameters it would be possible to further increase the efficiency in use of network resources. Efficiency can be gained by decreasing the overhead in form of setting up the radio bearers. Adjusting the release timer so that the channel is occupied during smaller time intervals would be beneficial in order to support more presence users. As explained in this report, several types and characteristics of presence information exist. Because of this, different presence notification methods depending on the information type might be useful. A watcher would for example want to subscribe to changes of a presentity’s availability through push notifications while receiving positioning information through performing pulls.

9.1 Future Work

A SIP transaction has to be completed and acknowledged with a 200 OK message or an error code, before a new transaction can be initiated. A consequence of this is that a channel will be reserved to a user even though the user cannot send any data. This issue appears for example during registration, which is illustrated by Figure 8.2. The watcher sets up a channel and sends the PUBLISH message. The watcher then has to wait approximately 1s until the server has set up the downlink channel and sent back the 200 OK message. The watcher is not allowed to send the SUBSCRIBE message until he or she have received the acknowledgement for the previous transaction. Further studies could examine the consequences of allowing multiple unacknowledged transactions in order to

44 optimize usage of radio resources. Throttling and pull have shown to be effective solutions on how to limit the number of messages sent from the server to the watchers. More dynamic updating models can be used in order to limit the amount of traffic when presence information updates are not needed. For example, presence updates can be stopped from being sent to the watcher if the watcher enters a state where he or she does not want to or need to receive presence updates. This could be used if a watcher enters some kind of away or do not disturb state. The messages could be throttled at the server until the watcher enters a new state where notifications are allowed. This could of course be achieved if the user un-subscribes before entering the specific state where the notifications are not allowed. It would however be more efficient if the server recognizes these states and temporarily stopped forwarding any notifications to the watcher. Inves- tigations could be made in order to evaluate the efficiency gained by using a dynamic updating model in push- and throttle-based systems.

Bibliography

[1] Mirabilis ICQ, http://www.mirabilis.com, (January 2005) [2] Internet Engineering Task Force IETF, http://www.ietf.org, (January 2005) [3] IMPP IETF (Concluded) Working Group http://www.ietf.org/ html.charters/OLD/impp-charter.html (January 2005) [4] XMPP IETF (Concluded) Working Group http://www.ietf.org/ html.charters/OLD/xmpp-charter.html (January 2005) [5] SIMPLE IETF Working Group http://www.ietf.org/ html.charters/simple- charter.html (January 2005) [6] Rosenberg J. et al. “SIP: Session Initiating Protocol”, Request for Com- ments RFC 3261, Internet Engineering Task Force, June 2002. [7] Jabber - Open Instant Messaging and Presence, http://www.jabber.org/, (January 2005) [8] Saint-Andre P. “Extensible Messaging and Presence Protocol (XMPP): Core”, Request for Comments RFC 3920, Internet Engineering Task Force, October 2004 [9] Saint-Andre P. “Extensible Messaging and Presence Protocol (XMPP): In- stant Messaging and Presence”, Request for Comments RFC 3921, Internet Engineering Task Force, October 2004. [10] America Online Instant Messenger, http://www.aim.com, (January 2005) [11] Open Mobile Alliance - Wireless Village, http://www.openmobilealliance.org/tech/aﬃliates/wv/wvindex.html, (January 2005) [12] Day M. et al. “A Model for Presence and Instant Messaging”, Request For Comments RFC 2778, Internet Engineering Task Force, February 2000. [13] Day M. et al. “Instant Messaging / Presence Protocol Requirements”, Re- quest For Comments RFC 2779, Internet Engineering Task Force, February 2000.

47 [14] Petersson J. “Common Proﬁle for Instant Messaging (CPIM)”, Request For Comments RFC 3860, Internet Engineering Task Force, August 2004. [15] Newman C. “Using TLS with IMAP, POP3 and ACAP”, Request for Com- ments RFC 2595, Internet Engineering Task Force, June 1999. [16] Price R. et al. “Signaling Compression (SigComp)”, Request for Comments RFC 3320, Internet Engineering Task Force, January 2003. [17] Ericsson, Motorola, Nokia, Siemens. "Push-to-Talk over Cellular (PoC); Presence Service Speciﬁcation v2.0.7", (May 2004) [18] Leijon H. “Extract from the Table of the Erlang Loss Formula”, Re- trieved January 12, 2005 from WWW: http//www.itu.int/itudoc/itu- d/dept/psp/ssb/planitu/plandoc/erlang.html [19] Körner U. “M/M/m * upptagetsystem, Erlang” In Köteori och tillför- litlighetsteori applicerat på telekommunikations- och datorsystem. 1997, Tredje upplagan. Pp. 211-218. Lund: Studentlitteratur. (ISBN: 91-44- 00480-X) [20] Holma H. and Toskala A. “WCDMA for UMTS; Radio Access for Third Generation Mobile Communications”, 2001 Revised Edition, Chichester, John Wiley & Sons, ISBN 0471486876.

Personal Communication

[21] Jan Christoﬀersson, Ericsson Research.

48 Appendix A

Calculations of Presence Event Intensity

The intensities can be interpreted as a number of events per hour. However, it can also be seen as the average time until an event occurs through the relation

Average time until event =1/Intensity. (A.1)

For example, an intensity of 0.5 events per hour corresponds to an average time until an event occurs of 2 hours. Table A.1 shows the numbers used for calculating the intensities used for comparing diﬀerent presence models.

Table A.1: Presence event intensities for state transitions. Average time Transition Intensity until event

Freg 35 min 1.73 Fdereg 3h 16 min 0.306 Faway 3h 0.33 Faway−online 1h 1.0 Fphone 30 min 2.0 Fphone−online 3 min 20

A user is expected to receive a phone call every 30 minutes and the call is expected to be three minutes long. The user will also enter the away state once every third hour and stay in that state for approximately one hour.

49 Preg Probability of being in registered state Pnreg Probability of being in not registered state Paway Probability of being in away state Pphone Probability of being in phone state Freg Intensity of registration Fdereg Intensity of de-registration Faway Intensity of changing from online to away Faway−online Intensity of changing from away to online Fphone Intensity of changing from online to on phone Fphone−online Intensity of changing from on phone to online The average number of presence events per user and hour (intensity) for the three intensity levels low, medium and high is given by

FP.E low = Pnreg ∗ Freg + Preg ∗ Fdereg. (A.2)

FP.E med = Pnreg ∗ Freg + Preg ∗ (Fdereg + Faway)+ Paway ∗ Faway−online. (A.3)

FP.E high = Pnreg∗Freg+Preg∗(Fdereg+Faway+Fphone)+Paway∗Faway−online+Pphone∗Fphone−online. (A.4) The probabilities for being in each state are based on the assumption that the system has reached steady state.

50 Appendix B

Veriﬁcation of Simulation Results

The formula used for calculating the average number of messages per user and hour is given by

Nmsg = Pnreg ∗Freg ∗(4+2NG/3)+Preg ∗(FP.E ∗NG ∗2+Fdereg ∗(4+2NG/3)). (B.1) Note that messages sent due to re-registrations are not included in the formula. Table B.1 shows the results of some the the simulations made in order to verify that the simulation outputs are reasonable.

Table B.1: Theoretical and simulated results compared.

Simulated Result Calculated Result Intensity of Group Size Number of Number of Presence Events Messages Messages 0.37 5 6.7 6.6 0.37 10 11.8 11.7 0.37 15 15.7 15.9 1.0 5 16.6 16.5 1.0 10 28.6 28.9 1.0 15 39.7 39.5 1.5 5 24.6 24.8 1.5 10 43.8 43.5 1.5 15 59.0 59.2

Appendix C

Presence Erlang Capacity Calculations

C.1 Formulas for Capacity Calculations

Receiving of Presence Updates Using Push

Channel 200OK Channel Setup P Down UPLINK t Channel Notify Channel Setup Down

DOWNLINK t Setup, Tear down time Propagation time for sending message Idle time. Waiting for message

Figure C.1: Reservation of uplink and downlink channel when receiving push notiﬁcation.

tuplink = tsetup + t200N + tdown (C.1)

tdownlink = tsetup + tnotify + tdown (C.2)

53 Receiving of Presence Update Using Throttle

Channel 200OK 200OK Channel Setup N N Down

UPLINK t

Channel Notify Notify Channel Setup Down DOWNLINK t Setup, Tear down time Propagation time for sending message Idle time. Waiting for message

Figure C.2: Reservation of uplink and downlink channel when receiving throttled notiﬁcations.

It is not possible to use a formula like C.1 or C.2 for calculating average time a channel is reserved when receiving throttled presence updates at a speciﬁc throttling interval. The following formulas are needed to solve that problem. First, one has to know the probability P that one presentity has changed its state during the throttle interval 1/fthrottle. fP.E is the presence event intensity. f P = P.E (C.3) fP.E + fthrottle The average time the downlink channel is occupied is given by

NG 8 ∗ 350 k + k + 150 k − 1 t = Bin(N ,P,k) ∗ 3 3 + t ∗ (1 + h(k − 3)) + t , downlink G bit rate setup down k=1 ! X (C.4) where the probability that 1 to k presentities have changed their states since last throttle is given by,

N − Bin(N ,P,k)= G ∗ P k ∗ (1 − P )NG k. (C.5) G k 0 : n ≤ 0 h(n)= (C.6) 1 : n> 0 Formula C.4 is a weighted sum of the number of presentities that have changed their states since that last throttle event and the time that is required for sending the messages. The ﬁrst term in the numerator represents the total

54 size of the NOTIFY messages and the second term represents the size of the 200 OK messages. The set up time, tsetup is multiplied by 2 if more than one notify messages are sent. This since the downlink channel has to be reserved while the uplink channel is set up. The reason for this is that a 200OK messages has to be received by the server before sending another NOTIFY message. See Figure C.2.

Receiving of Presence Updates Using Pull

Channel Subscribe 200 OK 200 OK Channel Setup N N Down UPLINK t

Channel 200OK Notify Notify Channel Setup S Down

DOWNLINK t Setup, Tear down time Propagation time for sending message Idle time. Waiting for message

Figure C.3: Reservation of uplink and downlink channel when receiving pull notiﬁcations.

The formulas for calculating channel reservation times for pull is similar to the throttling formula with a few modiﬁcations. The downlink reservation time is given by

NG 8 ∗ (400 + pullNotifySize(k)+ ackSize(k)) t = Bin(N ,P,k) ∗ + t + t , downlink G bit rate setup down k=0 X (C.7)

350 : k =0 pullNotifySize(k)= , (C.8) 350 ∗ k + k : k =06 3 0 : k ≤ 3 ackSize = . (C.9) 350 ∗ k − 1 : k> 3 3 Formula C.8 shows that a single Notify message is sent even if no presentity has changed its state since the last pull. Formula C.9 indicates that before sending a second (or more) NOTIFY message, the downlink channel is reserved while waiting for receiving an uplink acknowledgement.

55 C.2 Erlang Results for High Intensity Calcula- tions.

Table C.1: Erlangs generated at diﬀerent traﬃc generating phases for group sizes at 5, 10 and 15 users.

Traﬃc Generating Phase Downlink [mE] Group Size 5 10 15 Registration 0.21 0.29 0.34 Re-Registration 0.52 0.70 0.84 Push Update 10.7 21.4 32.1 Push Throttling Update (10 minutes) 3.8 5.3 6.4 Pull Update (51 minutes) 1.0 1.3 1.7 De-Registration 0.22 0.29 0.35 Total Sum per User in Push 11.6 22.7 33.6 Total Sum per User in Throttle 4.7 6.6 7.9 Total Sum per User in Pull 2.0 2.6 3.2