Mobile-to-Mobile Multi-user Chat Service
Content
Mobile-to-Mobile Multi-user Chat Service
framework for Operator networks
*Muzzamil Aziz, Sharique Javaid, Matthias Jarke
Chair of Communication and Distributed Systems
RWTH Aachen University
Ahornstr. 55, D-52056 Aachen, Germany
Email: [email protected]
Abstract-In past few years, the concept of mobile servers
has emerged dramatically. That means the mobile nodes have
now gained such extraordinary processing powers and storage
capacities that they can actively play a role of service delivery
platforms in the service oriented paradigms. Recently, a concept
of Mobile Application Servers (Mob-ASs) has been introduced
by the research community in order to promote M2M (Mobile
to-Mobile) service networks over the telecom operator networks.
Such joint-venture of IT and Telco systems will bring a plethora
of new M2M applications in the market.
This paper presents the design and evaluation of an M2M chat
service framework for an existing Mobile Server Platform (MSP).
The existing MSP has the capacity to register itself as a Mobile
Application Server (Mob-AS) and a Mobile Application Client
(Mob-AC) in the operator's IMS (IP Multimedia Subsystem)
network. Featuring the MSP with the chat service framework
will facilitate the mobile users to exchange short and long text
messages and multimedia files over the operator network without
using any third-party services.
I.
INTRODUCTION
M2M service networks are the networks where mobile
nodes are required to collaborate and disseminate information
in a service oriented fashion. More precisely, these are the
networks of mobile nodes where each member node is able
to request or provide web services to other member nodes
in the network. The network nodes, however, are not limited
to consumer handheld devices only, such as smart phones
or PDAs, but the similar concept could be applied to home
appliances and enterprise gadgets used in home automation,
smart metering, vehicle telematics and eHealth applications
etc.
With the ongoing advancement in IT and Telco systems,
research communities now-a-days are investigating in finding
out an efficient way to publish M2M services in the operator's
telecom network. Due to resource constrained nature of mobile
networks, a big challenge in this regard is to maintain a good
QoS level in the complete end-to-end session of a service.
Network over-provisioning is possible, though it is not an
economical solution. Hence, there is a need to investigate a
sophisticated way of guaranteeing a certain level of QoS for
a given session according to the resources available in the
network.
A concept of IMS - Mobile Application Server has been
recently introduced by the research community [1]. The moti
vation came after a 3GPP initiative to bring the IP Multimedia
Subsystem (lMS) as a service layer standard in the LTE
mobile systems. With its full utilization, the IMS facilitates the
mobile operators to host multimedia services on their network
and ensure guaranteed QoS to the end users. Therefore, the
introduction of mobile application servers for the operator IMS
network has opened up a plethora of M2M applications in the
market.
The paper proposes a M2M chat service framework for an
existing IMS - Mobile Server Platform (MSP). The 3GPP
standards for pager mode Instant Messaging and session
based Instant Messaging are followed to introduce M2M text
messaging and M2M file sharing. Section II gives an overview
of IMS architecture whereas Section III presents the design
of an existing MSP. Section IV provides a comprehensive
design and implementation of M2M chat service based on the
existing framework. Finally, section V discusses an extensive
evaluation of proposed framework from the perspective of
processing latency and transfer rates of multimedia data.
II. IMS -
Fig. 1.
ApPLICATION
S ERV ER S
3GPP IP Multimedia Subsystem
Figure 1 depicts the architectural view of IMS ecosystem.
The given architecture is divided into three different layers
[2]: Transport layer, IMS Core and Service Layer. The IMS
978-1-4799-3824-7/14/$31.00 ©2014 IEEE
standard does not specify the IMS architecture as a collection
of nodes but functions. Therefore, it is a choice of a vendor
to define single or multiple nodes for the implementation of a
single function. The IMS is an access agnostic network, which
means the so-called IMS Core is accessible by any consumer
device connected via WLAN, ADSL or packet data network.
Such a consumer device capable of communicating with IMS
Core is typically referred to as an IMS terminal. The transport
layer facilitates an IMS terminal to make and receive calls to
and from PSTN network or any other circuit-switched network
using PSTN/CS gateway as shown in figure.
The main function of IMS Core is to perform user authoriza
tion and control signaling information between IMS terminals
and Application Servers. The Application Servers (ASs) are
the entities responsible for hosting and executing services in
the IMS network. Depending on the application types, the
ASs are categorized in three different types [3]: SIP AS, open
service architecture (OSA) AS and CAMEL AS. Again, the
IMS standard does not specify the internal architecture of an
AS rather lists some general functional requirements that an
AS must fulfill. However, some software designs [4] have been
presented by the research communities based on the state-of
the-art APIs and technologies targeted mainly for enterprise
solutions.
The CSCF is the most essential part of the IMS Core.
A CSCF can be one of the three different types: P
CSCF (Proxy-CSCF), I-CSCF (Interrogating-CSCF), S-CSCF
(Serving-CSCF). A CSCF is the first contact point of an IMS
terminal in the IMS network. Some other important compo
nents of IMS Core are: MRFs (Media Resource Functions),
user databases, called HSSs (Home Subscriber Servers) and
Subscriber Location Functions (SLFs).
III. IMS -
MOBILE ApPLICATION SERVERS
This section gives an overview of an existing Mobile Server
Platform (MSP) as shown in figure 2. The MSP is comprised
of the IMS mobile application client (MobAC) and the IMS
mobile application server (MobAS). Similar to SIP ASs in the
IMS network, the MobAS is a mobile based SIP application
server capable of hosting and executing multimedia services.
A. Application Server Processing
The Application Server part of MSP is able to process
both short term and long term service requests. The short
term service requests are handled by synchronous service
invocation mechanism whereas long term requests are handled
by asynchronous service invocation mechanism. Each service
in the MSP is identified by a unique Restful-URI, which is
embedded in the SIP messages by the Application Client.
The SIP Listener separates the Restful-URI string from
the service request and parses it to extract the target ser
vice information such as service name, request method and
resource method. The parsed information is then utilized
by SIP Listener to form a Request Object and identify the
service type such as synchronous or asynchronous. It is worth
mentioning here that although the service type can also be
identified by simply knowing the SIP method name, such
as, SIP MESSAGE corresponds to synchronous request and
SIP INVITE corresponds to asynchronous, but this approach
is avoided in order to keep compliance with basic REST
architecture introduced in [5].
Synchronous Service Invocation: In case the synchronous
service request identified by SIP Listener, the Request Object
is passed to the Deployment Interface through SAP Manager
which is responsible to look up and invocation of target
service. The Deployment Interface maintains a list of all
available services along with their corresponding objects as a
key-value mapping. Therefore, it looks up the corresponding
service object in its service inventory and uses it to invoke
target service.
Asynchronous Service Invocation: An asynchronous ser
vice is initiated and executed as a thread, which is the
primary difference between the synchronous and asynchronous
services. The asynchronous service is made a thread because
that enables it to be controlled and monitored and to be in
variable states during the course of execution [5]. In case
of asynchronous service request, before parsing and making
Request Object the SIP Listener first checks whether the
request message contains an SDP offer, extracts the media
information and verifies the availability of the target service.
This is to note that the SDP offer is used in the SIP INVITE
request in order to negotiate over streaming media parameters
between two parties before the actual media transmission
starts.
Considering the SDP offer is valid and accepted by the SIP
Listener, the Request Object is passed to ASAP Handler which
invokes Service Factory to create a new Service Instance for
the target service. At this stage, a 200 OK message is sent
to the AC that releases the AC from the blocked state. With
this message the AS also provides two important IDs to the
AS: a request Call-ID for reference to the upcoming final
acknowledgement from the AC and the EPR for newly created
Service Instance for future conununication with the service.
Thus, after sending 200 OK message the control is given
to the Deployment Interface finally along with the Request
Object and Service Instance parameters for target service
invocation. In contrast to synchronous service invocation, after
inventory look up the Deployment Interface forms a service
thread, save it in database against the Call-ID and wait for the
acknowledgement of the last 200 Ok message from the AC.
Consequently, when the acknowledgement message arrives at
Request Handler, the Deployment Interface is notified along
with the Call-ID which in return starts the corresponding
service thread.
IV. M2M C H AT
SERVICE
This section explains that how a MSP is utilized to create
an M2M chat session over the operator IMS network. Imagine
a chat messaging session between two mobile users, Bob and
Alice, as shown in figure 3. Both users exchange a couple of
short SIP messages until Bob wants Alice to send her picture.
Alice picks a picture from the picture gallery and presses Ok
Application
Client
IMS Core
A. Text Messaging
SYNCHRONOUS REST
ASYNCHRONOUS REST
1------------------------�
P n
M�d!: ,!!
__________
Fig. 2.
!.., __________I
Mobile Server Platform
to send. In response to OK, the Alice's MSP sends a short
SIP message to Bob's MSP in order to have its permission to
receive an image file. After receiving a 200 OK message from
Bob's MSP, Alice MSP creates a SIP INVITE session with
Bob's MSP and the actual image transfer starts.
Based on the above chat scenario, the communication
between two end users can be categorized in two different
forms: Short term messages such as text messaging and long
term messages such as multimedia file sharing. The following
section describes these two forms in detail.
As indicated in section III that a MSP supports two different
types of service invocation mechanisms i.e., Synchronous
and Asynchronous. The text messaging form of M2M chat
service is implemented by synchronous invocation mechanism
of MSP. Therefore, in case of any SIP Message received by
the MSP, a synchronous service is invoked which receives this
message and sends a 200 OK message in response. In gen
eral, any kind of SIP request that follows a request-response
approach can be implemented by synchronous mechanism of
MSP.
Figure 4 depicts that how a SIP Message request goes from
one MSP to another over the operator IMS network. Whenever
a SIP Message reaches an IMS network, two major opera
tions are performed by the network entities. First, a diameter
request-response operation is performed by I-CSCF in order
to verify the subscription of the mobile user. The verification
is done by HSS database. The second major operation that is
performed by S-CSCF is called Initial Filter Criteria (IFC)
evaluation. The IFC evaluation is done in order to locate
the respective application server responsible for handling the
coming service request. The IFC is the grouping between a
Trigger Point (the logical expression matching a message) and
an Application Server. The absence of a Trigger Point in an
Initial Filter Criteria indicates that the message should always
be forwarded to the respective Application Server.
MobileS'l'nl'
Platform 2
MobileSen-er
Platform 1
Alice
Bob
SIP �le.ssage
: "Hi, )-our pic ?"
SIP j\le..ssage
: "Do you acc.ept ?"
11-""''''--->11'""00''''"
1<--"''---1
""' 1 ;>
L\lservice
2000K
2000K
SIP Th"\UE
lOOOK
Connection setup
r--'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-.-._._._._._._._.
Pa<kft
•
•
Pa<kftn
SIP BYE
1000K
Fig. 3.
M2M Chat application scenario
Fig. 4.
SIP MESSAGE Flow
B. Multimedia File Transfer
The file transfer form of M2M chat service is implemented
by asynchronous invocation mechanism of MSP. In contrast
to a SIP MESSAGE request, SIP INVITE request is used
to create a particular session for a multimedia data transfer.
A three way handshaking is performed between sender and
receiver in order to create a multimedia session. Therefore,
in case of a SIP INVITE request the MSP sends a 200 OK
response to sender and waits for an ACK before it invokes an
asynchronous service.
Figure 5 depicts that how a SIP INVITE request goes from
one MSP to another over the operator IMS network. A SIP
INVITE request reaches to application server in a similar
way as SIP MESSAGE request. However, after receiving an
INVITE request, the MSP completes a three way handshaking
procedure. It is important to note here that the actual multime
dia transfer is done via MSRP protocol, which is a standard
for session based Instant Messaging introduced by 3GPP.
MSRP d93kswow SEND
To-Path:msrp://[email protected]:9097/asa06sdkht;tcp
From-Path:msrp://[email protected]:7654/iau39soe2843z;tc
Message-ID:fk3tv7ip3tji
Byte-Range:1-750/169453
Content-Type: message/cpim
To:Coco
<sip:[email protected]>
From:i5Server
<sip:[email protected]>
Content-Type: text/plain
ABCD
-------d93kswow+
S-CSCF
l00Tr\'in�
l00Try!!!.s...
I.tSP
l
II A
( pplicationS�lVer) 1
Dia��7Rq
(
�
L
( A
I )
�
Evaluation
y I L\1 service
1-NV
I
g;;lli
TE
I
IOOTr,,;n
180Rin;'! n
Fig. 5.
TABLE I
SAMPLE MSRP MESSAGE CHUNK GENERATED
180Rinin�
�
SIP INVITE Row
MRSP Implementation: The MSRP is a protocol used
in the framework to transfer multimedia data in session
based 1M as per the standards defined by the 3GPP for IMS
ecosystem. MSRP defines two types of request or method: 1)
SEND Request 2) Report Request
SEND requests are used to deliver a message to the other
party. A message could be a complete message or a part
(chunk) of a complete message. A REPORT request reports
on the status of a previously sent message. A typical
MSRP request contains an MSRP URI, which is used
to identify a session of instant messages at a particular
MSRP device, as well as to identify an MSRP relay in
general. Table I shows a sample MSRP SEND request.
Here msrp:[email protected]:9097asa06sdkht;tcp is
an example URI, where:
•
msrp is the scheme, it can also be msrps
•
sharique-server.ericsson.com is the domain
•
9097 is the port where it want to get the requests on the
IP of the above domain
•
asa06sdkhto is the session identifier
•
tcp is the transport.
Several open-source libraries for implementation of the
MSRP were found. But no proper documentation or tutorial
was available on the use of these MSRP libraries. Therefore
it was decided to develop the required MSRP functionalities,
from scratch. Hence MSRP protocol was implemented as
per the standards defined in the MSRP standards defined by
the IETF [6]. The following functionalities were implemented:
•
Converting the byte array of data to small chunks of fixed
size.
•
Adding MSRP headers to the chunks depending on the
chunk number
•
The chunk information included if the chunk is the last
one or not.
•
MSRP parser was implemented.
Base64 encoding / file chunks: In order to send the file
data over the network, the file is converted to a byte array for
processing. The byte array is divided into chunks and Base64
encoding is applied on each chunk. The Base64 is an encoding
scheme that represents the binary data in an ASCII string
format. It is done by translation into radix-64 representation.
Base64 scheme is more popular in cases when the binary data
needs be stored and transferred over the media designed to deal
with textual data [7]. By fixing the chunk size the complete
byte array is divided into n chunks. n
filesize/chunksize +
1 Keeping the chunk size equal to 720 bytes, the byte array
divided into 'n' number of smaller byte arrays. Then MSRP
headers are added to each chunk. The MSRP header contains
the information like message ID, session ID, content-type, byte
range out of the total bytes to be sent and the information
whether this is the last chunk or more chunks are to follow.
After the successful chunking of the data into n number of
MSRP chunks, the service is informed that the chunks are
ready to be transferred.
=
V.
PERFORMANCE EVALUATIONS
The performance evaluation of the proposed framework has
been extensively carried out in order to study the processing
latencies during the session establishment and multimedia
transfer phase. The testbed environment is consisted of two
android phones and one server machine. The configuration of
the test bed is as follows:
Android phones acting as MAS framework
Model: HTC Legend
Platform: Android 2.2
Camera: 5-megapixel color camera with auto focus and flash
Memory: ROM: 512MB RAM: 384MB
CPU Speed: 600MHz
Latencies at different processes
1 200
IMS testbed
Ericsson Service Development Studio is used as IMS testbed.
It comes as an Eclipse plug-in. It was running on the machine
with the following specifications.
System Manufacturer: Acer
Model: Aspire 5551G
Processor: AMD Phenom II, X3 Mobile Processor
Speed: 2.1 GHz
Memory: RAM: 4GB
Operating System: Genuine Windows 7 Home Premium
64-bit.
1000
800
I
.�
600
�
:s
40 0
200
0
A. Session Establishment Latencies
Tc
Processing latencies at Application Client (Tc)
Processing latencies at Application Server (Ts)
Processing latencies at IMS Proxies (Tp)
Network latencies Tn
Fig. 7.
The different multimedia types such as text, image and
audio files of different sizes were tested to evaluate multimedia
transfer times. All the files types except the text files were
encoded using Base 64 encoding scheme. Figure 8 shows
image files of different sizes, before and after encoding. The
blue bars indicate the number of bytes before encoding and
the red bard indicate the number of bytes after encoding. After
encoding the byte size increases by about 36 %.
1200
i\[obi&eSfn"rr
Platform !
[
Application
Server(AS11
Application
Oient(Ac,,1
T e
Cl
T e....
C2
Fig. 6.
Il'''VITE
�
ACK ->
Tnl
Tn4
Tn5
CSCF
l
8TPI
TP2C
<-200 OK
8TP3
Application
Oienl(AC:z1
!
�
�
Il'I;,iJTE ->
<-100 OK
8 TSI
Effects on file sizes by Base64 encoding
1000
Appl ication
ServerlAS21
Tn2
Tn3
Session establishment latencies
B. Multimedia transfer Latencies
The average time computed for session negotiations is about
l.8 seconds. So, the actual media transfer start after l.8
seconds of the initial service request. Figure 7 depicts the
individual times computed at each stage. It is noteworthy that
the processing time at IMS proxy is very less, whereas most
of the time is consumed by the application server in order to
perform service invocation and response generation.
MobileSrn-u
Platform 1
800
600
400
•
200
•
II
•
ACK ->
8m
Classification of processing latencies in session establishment phase
Fig. 8.
•
original
•
encoded
I
�II I
Average increase
Tn6
Tn
Ts
Latency Categorv
Figure 6 shows a three way hand-shaking process to
complete a session establishment phase of an asynchronous
service. The processing latencies in this phase are computed
at four different stages:
1.
2.
3.
4.
Tp
10
11
12
.. 36 "
File size after base64 encoding
The transfer rates for different image files are calculated
and plotted in figure 9. It is observed that the file transfer rate
starts with a reasonable value of around 26 kB/s for smaller
files but keeps decreasing gradually with increase of file size.
Transfer speeds for Text files of different sizes
This is because of the fact that slow processing of the chunks
at the android device slows down the file transfer speed.
45
File size vs transfer rate
30
35
30
,---
25
:::
!
�
•
�
20
15
10
\
1---\-----------
"....
1--�
..
-------�------���-��----------------------.,...,
20
15
1\
\.
\
\
\
"-..
10
100
------
200
300
400
�
500
600
File Size (kB)
200
600
400
800
1200
1000
Fig. 11.
Encoded file size (k6)
Transfer rate of image files of different sizes
Fig. 9.
Similarly, the file transfer times were also calculated for
audio and text files of variable sizes as shown in figures 10
and 11. It is observed that the transfer rate increases rapidly,
if the chunks received at the client side are not processed and
stored.
The variable processing times increase with the increase
of the file size. The media file is broken down into MSRP
chunks of fixed sizes and transferred over the TCP link. All the
received TCP segments are stored and added in the previous
received segments. In case of bigger files, the received string
becomes quite large. The memory heap size allocated to the
android application is exceeded. The additional memory is
allocated to the application on runtime and this produces
delays in the file transfer. A new data chunk is not processed
unless a previous chunk is stored successfully. In this case, the
bottleneck is the processing speed and memory size and not
the network speed as compared to the high end servers with
high processing powers and huge memory sizes.
40
35
30
25
20
Transfer rates for audio files of different sizes
�
'"
'----....
15
--
10
100
200
300
400
500
.....
600
700
file Size IkB)
Fig. 10.
Transfer rate of audio files of different sizes
VI.
SUMMARY
Telecom operators today are more interested in business
systems that enable them to apply multiple charging policies
over their network based on the user subscriptions and service
Transfer rate of text files of different sizes
profiles. The system must ensure QoS provisioning of high
profile multimedia services such as Push-To-Talk, video con
ferencing and multiparty gaming over the operator network.
Keeping such demand by mobile users and network operators
in view, 3GPP introduced the concept of IMS to guarantee
QoS of multimedia applications over the operator network.
By extending an existing IMS-MSP, the paper introduces a
M2M multiuser chat service framework for mobile operator
networks. The design and implementation of text messaging
and multimedia file sharing is explained in detail. The per
formance evaluation of the proposed framework is extensively
conducted in perspective of processing latency and transfer of
multimedia data.
REFERENCES
[1] M. Aziz and M. Jarke, "Mobile-to-mobile multimedia service provision
ing in the ims using rest-based mobile services," International Journal
of Computer and Communication Engineering (lJCCE), 2013, Vol. 2(4):
455-459 ISSN: 2010-3743, July 2013.
[2] The Architecture and Benefits of IMS, White Paper by Dialogic
Corporation Canada. [Online]. Available: http://www.dialogic.com!
medialproducts/docs/whitepapers/II297- ims-arch-benefits-wp.pdf
[3] H. Khalifi and J. Gregoer, "Ims application servers roles, requirements,
and implementation technologies," IEEE Internet Computing magazine,
June 2008.
[4] H. Khalifi and J. Gregoir, "Ims for enterprises," IEEE Communication
magazines, July 2007.
[5] F. Aijaz, S. Z. Ali, M. A. Chaudhary, and B. Walke, "Enabling high
performance mobile web services provisioning," Published in Proceedings
of the 2009 IEEE 70th Vehicular Technology Conference Fall, p. 6,
Anchorage, Alaska-USA, ISBN: 978-1-4244-2515-0, December.
[6] B. Campbell, R. Mahy, and C. Jennings, "The Message Session Relay
Protocol (MSRP)," http://tools.ietf.org/html/rfc4975, September 2007.
[7] S. Josefsson, "The Basel6, Base32, and Base64 Data Encodings," http:
//tools.ietf.org/html/rfc4648, October 2006.
framework for Operator networks
*Muzzamil Aziz, Sharique Javaid, Matthias Jarke
Chair of Communication and Distributed Systems
RWTH Aachen University
Ahornstr. 55, D-52056 Aachen, Germany
Email: [email protected]
Abstract-In past few years, the concept of mobile servers
has emerged dramatically. That means the mobile nodes have
now gained such extraordinary processing powers and storage
capacities that they can actively play a role of service delivery
platforms in the service oriented paradigms. Recently, a concept
of Mobile Application Servers (Mob-ASs) has been introduced
by the research community in order to promote M2M (Mobile
to-Mobile) service networks over the telecom operator networks.
Such joint-venture of IT and Telco systems will bring a plethora
of new M2M applications in the market.
This paper presents the design and evaluation of an M2M chat
service framework for an existing Mobile Server Platform (MSP).
The existing MSP has the capacity to register itself as a Mobile
Application Server (Mob-AS) and a Mobile Application Client
(Mob-AC) in the operator's IMS (IP Multimedia Subsystem)
network. Featuring the MSP with the chat service framework
will facilitate the mobile users to exchange short and long text
messages and multimedia files over the operator network without
using any third-party services.
I.
INTRODUCTION
M2M service networks are the networks where mobile
nodes are required to collaborate and disseminate information
in a service oriented fashion. More precisely, these are the
networks of mobile nodes where each member node is able
to request or provide web services to other member nodes
in the network. The network nodes, however, are not limited
to consumer handheld devices only, such as smart phones
or PDAs, but the similar concept could be applied to home
appliances and enterprise gadgets used in home automation,
smart metering, vehicle telematics and eHealth applications
etc.
With the ongoing advancement in IT and Telco systems,
research communities now-a-days are investigating in finding
out an efficient way to publish M2M services in the operator's
telecom network. Due to resource constrained nature of mobile
networks, a big challenge in this regard is to maintain a good
QoS level in the complete end-to-end session of a service.
Network over-provisioning is possible, though it is not an
economical solution. Hence, there is a need to investigate a
sophisticated way of guaranteeing a certain level of QoS for
a given session according to the resources available in the
network.
A concept of IMS - Mobile Application Server has been
recently introduced by the research community [1]. The moti
vation came after a 3GPP initiative to bring the IP Multimedia
Subsystem (lMS) as a service layer standard in the LTE
mobile systems. With its full utilization, the IMS facilitates the
mobile operators to host multimedia services on their network
and ensure guaranteed QoS to the end users. Therefore, the
introduction of mobile application servers for the operator IMS
network has opened up a plethora of M2M applications in the
market.
The paper proposes a M2M chat service framework for an
existing IMS - Mobile Server Platform (MSP). The 3GPP
standards for pager mode Instant Messaging and session
based Instant Messaging are followed to introduce M2M text
messaging and M2M file sharing. Section II gives an overview
of IMS architecture whereas Section III presents the design
of an existing MSP. Section IV provides a comprehensive
design and implementation of M2M chat service based on the
existing framework. Finally, section V discusses an extensive
evaluation of proposed framework from the perspective of
processing latency and transfer rates of multimedia data.
II. IMS -
Fig. 1.
ApPLICATION
S ERV ER S
3GPP IP Multimedia Subsystem
Figure 1 depicts the architectural view of IMS ecosystem.
The given architecture is divided into three different layers
[2]: Transport layer, IMS Core and Service Layer. The IMS
978-1-4799-3824-7/14/$31.00 ©2014 IEEE
standard does not specify the IMS architecture as a collection
of nodes but functions. Therefore, it is a choice of a vendor
to define single or multiple nodes for the implementation of a
single function. The IMS is an access agnostic network, which
means the so-called IMS Core is accessible by any consumer
device connected via WLAN, ADSL or packet data network.
Such a consumer device capable of communicating with IMS
Core is typically referred to as an IMS terminal. The transport
layer facilitates an IMS terminal to make and receive calls to
and from PSTN network or any other circuit-switched network
using PSTN/CS gateway as shown in figure.
The main function of IMS Core is to perform user authoriza
tion and control signaling information between IMS terminals
and Application Servers. The Application Servers (ASs) are
the entities responsible for hosting and executing services in
the IMS network. Depending on the application types, the
ASs are categorized in three different types [3]: SIP AS, open
service architecture (OSA) AS and CAMEL AS. Again, the
IMS standard does not specify the internal architecture of an
AS rather lists some general functional requirements that an
AS must fulfill. However, some software designs [4] have been
presented by the research communities based on the state-of
the-art APIs and technologies targeted mainly for enterprise
solutions.
The CSCF is the most essential part of the IMS Core.
A CSCF can be one of the three different types: P
CSCF (Proxy-CSCF), I-CSCF (Interrogating-CSCF), S-CSCF
(Serving-CSCF). A CSCF is the first contact point of an IMS
terminal in the IMS network. Some other important compo
nents of IMS Core are: MRFs (Media Resource Functions),
user databases, called HSSs (Home Subscriber Servers) and
Subscriber Location Functions (SLFs).
III. IMS -
MOBILE ApPLICATION SERVERS
This section gives an overview of an existing Mobile Server
Platform (MSP) as shown in figure 2. The MSP is comprised
of the IMS mobile application client (MobAC) and the IMS
mobile application server (MobAS). Similar to SIP ASs in the
IMS network, the MobAS is a mobile based SIP application
server capable of hosting and executing multimedia services.
A. Application Server Processing
The Application Server part of MSP is able to process
both short term and long term service requests. The short
term service requests are handled by synchronous service
invocation mechanism whereas long term requests are handled
by asynchronous service invocation mechanism. Each service
in the MSP is identified by a unique Restful-URI, which is
embedded in the SIP messages by the Application Client.
The SIP Listener separates the Restful-URI string from
the service request and parses it to extract the target ser
vice information such as service name, request method and
resource method. The parsed information is then utilized
by SIP Listener to form a Request Object and identify the
service type such as synchronous or asynchronous. It is worth
mentioning here that although the service type can also be
identified by simply knowing the SIP method name, such
as, SIP MESSAGE corresponds to synchronous request and
SIP INVITE corresponds to asynchronous, but this approach
is avoided in order to keep compliance with basic REST
architecture introduced in [5].
Synchronous Service Invocation: In case the synchronous
service request identified by SIP Listener, the Request Object
is passed to the Deployment Interface through SAP Manager
which is responsible to look up and invocation of target
service. The Deployment Interface maintains a list of all
available services along with their corresponding objects as a
key-value mapping. Therefore, it looks up the corresponding
service object in its service inventory and uses it to invoke
target service.
Asynchronous Service Invocation: An asynchronous ser
vice is initiated and executed as a thread, which is the
primary difference between the synchronous and asynchronous
services. The asynchronous service is made a thread because
that enables it to be controlled and monitored and to be in
variable states during the course of execution [5]. In case
of asynchronous service request, before parsing and making
Request Object the SIP Listener first checks whether the
request message contains an SDP offer, extracts the media
information and verifies the availability of the target service.
This is to note that the SDP offer is used in the SIP INVITE
request in order to negotiate over streaming media parameters
between two parties before the actual media transmission
starts.
Considering the SDP offer is valid and accepted by the SIP
Listener, the Request Object is passed to ASAP Handler which
invokes Service Factory to create a new Service Instance for
the target service. At this stage, a 200 OK message is sent
to the AC that releases the AC from the blocked state. With
this message the AS also provides two important IDs to the
AS: a request Call-ID for reference to the upcoming final
acknowledgement from the AC and the EPR for newly created
Service Instance for future conununication with the service.
Thus, after sending 200 OK message the control is given
to the Deployment Interface finally along with the Request
Object and Service Instance parameters for target service
invocation. In contrast to synchronous service invocation, after
inventory look up the Deployment Interface forms a service
thread, save it in database against the Call-ID and wait for the
acknowledgement of the last 200 Ok message from the AC.
Consequently, when the acknowledgement message arrives at
Request Handler, the Deployment Interface is notified along
with the Call-ID which in return starts the corresponding
service thread.
IV. M2M C H AT
SERVICE
This section explains that how a MSP is utilized to create
an M2M chat session over the operator IMS network. Imagine
a chat messaging session between two mobile users, Bob and
Alice, as shown in figure 3. Both users exchange a couple of
short SIP messages until Bob wants Alice to send her picture.
Alice picks a picture from the picture gallery and presses Ok
Application
Client
IMS Core
A. Text Messaging
SYNCHRONOUS REST
ASYNCHRONOUS REST
1------------------------�
P n
M�d!: ,!!
__________
Fig. 2.
!.., __________I
Mobile Server Platform
to send. In response to OK, the Alice's MSP sends a short
SIP message to Bob's MSP in order to have its permission to
receive an image file. After receiving a 200 OK message from
Bob's MSP, Alice MSP creates a SIP INVITE session with
Bob's MSP and the actual image transfer starts.
Based on the above chat scenario, the communication
between two end users can be categorized in two different
forms: Short term messages such as text messaging and long
term messages such as multimedia file sharing. The following
section describes these two forms in detail.
As indicated in section III that a MSP supports two different
types of service invocation mechanisms i.e., Synchronous
and Asynchronous. The text messaging form of M2M chat
service is implemented by synchronous invocation mechanism
of MSP. Therefore, in case of any SIP Message received by
the MSP, a synchronous service is invoked which receives this
message and sends a 200 OK message in response. In gen
eral, any kind of SIP request that follows a request-response
approach can be implemented by synchronous mechanism of
MSP.
Figure 4 depicts that how a SIP Message request goes from
one MSP to another over the operator IMS network. Whenever
a SIP Message reaches an IMS network, two major opera
tions are performed by the network entities. First, a diameter
request-response operation is performed by I-CSCF in order
to verify the subscription of the mobile user. The verification
is done by HSS database. The second major operation that is
performed by S-CSCF is called Initial Filter Criteria (IFC)
evaluation. The IFC evaluation is done in order to locate
the respective application server responsible for handling the
coming service request. The IFC is the grouping between a
Trigger Point (the logical expression matching a message) and
an Application Server. The absence of a Trigger Point in an
Initial Filter Criteria indicates that the message should always
be forwarded to the respective Application Server.
MobileS'l'nl'
Platform 2
MobileSen-er
Platform 1
Alice
Bob
SIP �le.ssage
: "Hi, )-our pic ?"
SIP j\le..ssage
: "Do you acc.ept ?"
11-""''''--->11'""00''''"
1<--"''---1
""' 1 ;>
L\lservice
2000K
2000K
SIP Th"\UE
lOOOK
Connection setup
r--'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-'-.-._._._._._._._.
Pa<kft
•
•
Pa<kftn
SIP BYE
1000K
Fig. 3.
M2M Chat application scenario
Fig. 4.
SIP MESSAGE Flow
B. Multimedia File Transfer
The file transfer form of M2M chat service is implemented
by asynchronous invocation mechanism of MSP. In contrast
to a SIP MESSAGE request, SIP INVITE request is used
to create a particular session for a multimedia data transfer.
A three way handshaking is performed between sender and
receiver in order to create a multimedia session. Therefore,
in case of a SIP INVITE request the MSP sends a 200 OK
response to sender and waits for an ACK before it invokes an
asynchronous service.
Figure 5 depicts that how a SIP INVITE request goes from
one MSP to another over the operator IMS network. A SIP
INVITE request reaches to application server in a similar
way as SIP MESSAGE request. However, after receiving an
INVITE request, the MSP completes a three way handshaking
procedure. It is important to note here that the actual multime
dia transfer is done via MSRP protocol, which is a standard
for session based Instant Messaging introduced by 3GPP.
MSRP d93kswow SEND
To-Path:msrp://[email protected]:9097/asa06sdkht;tcp
From-Path:msrp://[email protected]:7654/iau39soe2843z;tc
Message-ID:fk3tv7ip3tji
Byte-Range:1-750/169453
Content-Type: message/cpim
To:Coco
<sip:[email protected]>
From:i5Server
<sip:[email protected]>
Content-Type: text/plain
ABCD
-------d93kswow+
S-CSCF
l00Tr\'in�
l00Try!!!.s...
I.tSP
l
II A
( pplicationS�lVer) 1
Dia��7Rq
(
�
L
( A
I )
�
Evaluation
y I L\1 service
1-NV
I
g;;lli
TE
I
IOOTr,,;n
180Rin;'! n
Fig. 5.
TABLE I
SAMPLE MSRP MESSAGE CHUNK GENERATED
180Rinin�
�
SIP INVITE Row
MRSP Implementation: The MSRP is a protocol used
in the framework to transfer multimedia data in session
based 1M as per the standards defined by the 3GPP for IMS
ecosystem. MSRP defines two types of request or method: 1)
SEND Request 2) Report Request
SEND requests are used to deliver a message to the other
party. A message could be a complete message or a part
(chunk) of a complete message. A REPORT request reports
on the status of a previously sent message. A typical
MSRP request contains an MSRP URI, which is used
to identify a session of instant messages at a particular
MSRP device, as well as to identify an MSRP relay in
general. Table I shows a sample MSRP SEND request.
Here msrp:[email protected]:9097asa06sdkht;tcp is
an example URI, where:
•
msrp is the scheme, it can also be msrps
•
sharique-server.ericsson.com is the domain
•
9097 is the port where it want to get the requests on the
IP of the above domain
•
asa06sdkhto is the session identifier
•
tcp is the transport.
Several open-source libraries for implementation of the
MSRP were found. But no proper documentation or tutorial
was available on the use of these MSRP libraries. Therefore
it was decided to develop the required MSRP functionalities,
from scratch. Hence MSRP protocol was implemented as
per the standards defined in the MSRP standards defined by
the IETF [6]. The following functionalities were implemented:
•
Converting the byte array of data to small chunks of fixed
size.
•
Adding MSRP headers to the chunks depending on the
chunk number
•
The chunk information included if the chunk is the last
one or not.
•
MSRP parser was implemented.
Base64 encoding / file chunks: In order to send the file
data over the network, the file is converted to a byte array for
processing. The byte array is divided into chunks and Base64
encoding is applied on each chunk. The Base64 is an encoding
scheme that represents the binary data in an ASCII string
format. It is done by translation into radix-64 representation.
Base64 scheme is more popular in cases when the binary data
needs be stored and transferred over the media designed to deal
with textual data [7]. By fixing the chunk size the complete
byte array is divided into n chunks. n
filesize/chunksize +
1 Keeping the chunk size equal to 720 bytes, the byte array
divided into 'n' number of smaller byte arrays. Then MSRP
headers are added to each chunk. The MSRP header contains
the information like message ID, session ID, content-type, byte
range out of the total bytes to be sent and the information
whether this is the last chunk or more chunks are to follow.
After the successful chunking of the data into n number of
MSRP chunks, the service is informed that the chunks are
ready to be transferred.
=
V.
PERFORMANCE EVALUATIONS
The performance evaluation of the proposed framework has
been extensively carried out in order to study the processing
latencies during the session establishment and multimedia
transfer phase. The testbed environment is consisted of two
android phones and one server machine. The configuration of
the test bed is as follows:
Android phones acting as MAS framework
Model: HTC Legend
Platform: Android 2.2
Camera: 5-megapixel color camera with auto focus and flash
Memory: ROM: 512MB RAM: 384MB
CPU Speed: 600MHz
Latencies at different processes
1 200
IMS testbed
Ericsson Service Development Studio is used as IMS testbed.
It comes as an Eclipse plug-in. It was running on the machine
with the following specifications.
System Manufacturer: Acer
Model: Aspire 5551G
Processor: AMD Phenom II, X3 Mobile Processor
Speed: 2.1 GHz
Memory: RAM: 4GB
Operating System: Genuine Windows 7 Home Premium
64-bit.
1000
800
I
.�
600
�
:s
40 0
200
0
A. Session Establishment Latencies
Tc
Processing latencies at Application Client (Tc)
Processing latencies at Application Server (Ts)
Processing latencies at IMS Proxies (Tp)
Network latencies Tn
Fig. 7.
The different multimedia types such as text, image and
audio files of different sizes were tested to evaluate multimedia
transfer times. All the files types except the text files were
encoded using Base 64 encoding scheme. Figure 8 shows
image files of different sizes, before and after encoding. The
blue bars indicate the number of bytes before encoding and
the red bard indicate the number of bytes after encoding. After
encoding the byte size increases by about 36 %.
1200
i\[obi&eSfn"rr
Platform !
[
Application
Server(AS11
Application
Oient(Ac,,1
T e
Cl
T e....
C2
Fig. 6.
Il'''VITE
�
ACK ->
Tnl
Tn4
Tn5
CSCF
l
8TPI
TP2C
<-200 OK
8TP3
Application
Oienl(AC:z1
!
�
�
Il'I;,iJTE ->
<-100 OK
8 TSI
Effects on file sizes by Base64 encoding
1000
Appl ication
ServerlAS21
Tn2
Tn3
Session establishment latencies
B. Multimedia transfer Latencies
The average time computed for session negotiations is about
l.8 seconds. So, the actual media transfer start after l.8
seconds of the initial service request. Figure 7 depicts the
individual times computed at each stage. It is noteworthy that
the processing time at IMS proxy is very less, whereas most
of the time is consumed by the application server in order to
perform service invocation and response generation.
MobileSrn-u
Platform 1
800
600
400
•
200
•
II
•
ACK ->
8m
Classification of processing latencies in session establishment phase
Fig. 8.
•
original
•
encoded
I
�II I
Average increase
Tn6
Tn
Ts
Latency Categorv
Figure 6 shows a three way hand-shaking process to
complete a session establishment phase of an asynchronous
service. The processing latencies in this phase are computed
at four different stages:
1.
2.
3.
4.
Tp
10
11
12
.. 36 "
File size after base64 encoding
The transfer rates for different image files are calculated
and plotted in figure 9. It is observed that the file transfer rate
starts with a reasonable value of around 26 kB/s for smaller
files but keeps decreasing gradually with increase of file size.
Transfer speeds for Text files of different sizes
This is because of the fact that slow processing of the chunks
at the android device slows down the file transfer speed.
45
File size vs transfer rate
30
35
30
,---
25
:::
!
�
•
�
20
15
10
\
1---\-----------
"....
1--�
..
-------�------���-��----------------------.,...,
20
15
1\
\.
\
\
\
"-..
10
100
------
200
300
400
�
500
600
File Size (kB)
200
600
400
800
1200
1000
Fig. 11.
Encoded file size (k6)
Transfer rate of image files of different sizes
Fig. 9.
Similarly, the file transfer times were also calculated for
audio and text files of variable sizes as shown in figures 10
and 11. It is observed that the transfer rate increases rapidly,
if the chunks received at the client side are not processed and
stored.
The variable processing times increase with the increase
of the file size. The media file is broken down into MSRP
chunks of fixed sizes and transferred over the TCP link. All the
received TCP segments are stored and added in the previous
received segments. In case of bigger files, the received string
becomes quite large. The memory heap size allocated to the
android application is exceeded. The additional memory is
allocated to the application on runtime and this produces
delays in the file transfer. A new data chunk is not processed
unless a previous chunk is stored successfully. In this case, the
bottleneck is the processing speed and memory size and not
the network speed as compared to the high end servers with
high processing powers and huge memory sizes.
40
35
30
25
20
Transfer rates for audio files of different sizes
�
'"
'----....
15
--
10
100
200
300
400
500
.....
600
700
file Size IkB)
Fig. 10.
Transfer rate of audio files of different sizes
VI.
SUMMARY
Telecom operators today are more interested in business
systems that enable them to apply multiple charging policies
over their network based on the user subscriptions and service
Transfer rate of text files of different sizes
profiles. The system must ensure QoS provisioning of high
profile multimedia services such as Push-To-Talk, video con
ferencing and multiparty gaming over the operator network.
Keeping such demand by mobile users and network operators
in view, 3GPP introduced the concept of IMS to guarantee
QoS of multimedia applications over the operator network.
By extending an existing IMS-MSP, the paper introduces a
M2M multiuser chat service framework for mobile operator
networks. The design and implementation of text messaging
and multimedia file sharing is explained in detail. The per
formance evaluation of the proposed framework is extensively
conducted in perspective of processing latency and transfer of
multimedia data.
REFERENCES
[1] M. Aziz and M. Jarke, "Mobile-to-mobile multimedia service provision
ing in the ims using rest-based mobile services," International Journal
of Computer and Communication Engineering (lJCCE), 2013, Vol. 2(4):
455-459 ISSN: 2010-3743, July 2013.
[2] The Architecture and Benefits of IMS, White Paper by Dialogic
Corporation Canada. [Online]. Available: http://www.dialogic.com!
medialproducts/docs/whitepapers/II297- ims-arch-benefits-wp.pdf
[3] H. Khalifi and J. Gregoer, "Ims application servers roles, requirements,
and implementation technologies," IEEE Internet Computing magazine,
June 2008.
[4] H. Khalifi and J. Gregoir, "Ims for enterprises," IEEE Communication
magazines, July 2007.
[5] F. Aijaz, S. Z. Ali, M. A. Chaudhary, and B. Walke, "Enabling high
performance mobile web services provisioning," Published in Proceedings
of the 2009 IEEE 70th Vehicular Technology Conference Fall, p. 6,
Anchorage, Alaska-USA, ISBN: 978-1-4244-2515-0, December.
[6] B. Campbell, R. Mahy, and C. Jennings, "The Message Session Relay
Protocol (MSRP)," http://tools.ietf.org/html/rfc4975, September 2007.
[7] S. Josefsson, "The Basel6, Base32, and Base64 Data Encodings," http:
//tools.ietf.org/html/rfc4648, October 2006.
