Communications and Network, 2013, 5, 590-595 Published Online September 2013 (
Copyright © 2013 SciRes. CN
Real-Time Communication Method for mHealth Base on
Extended XMPP Protocol
Chenjie Shi, Yu Fang
The Key Laboratory of Embedded System and Service Computing, Ministry of Education, Tongji University, Shanghai, China
Email: t a,
Received June 2013
Considering characteristic of mHealth communication and problems of existing methods, this paper presents a real-time
communication method for mHealth based on extended XMPP protocol. The method can maintain the role status effi-
ciently and reduce data latency during the communication process. Meanwhile, it can be extended flexibly to meet in-
creasing communication demands of mHealth services. Furthermore, a system framework is presented to support tele-
monitoring scene. Finally, system implementation and feasibility tests verify the effectiveness of the method and
Keywords: mHealth; XMPP Protocol; Real-Time Communication
1. Introduction
With the increasing proportion of urban sub-health and
aging population, medical resource for diagnosis and
treatment of chronic diseases are in high demand. Taking
advantage of sensor technology and mobile communica-
tion technology, mHealth provides various medical in-
formation and services which improve utilization of med-
ical resources efficiently and reduce costs as well. With
the development of urban wireless communication infra-
structures as well as the popularity of mobile terminals,
mHealth has become a new trend of medical informatio-
nizati on [1].
Existing communication methods of mHealth use cus-
tom packages to transport data and produce service res-
ponses through socket or http request. All these methods
are lack of unified application layer protocol and cannot
maintain the role status dur ing co mmunication. Moreover,
custom binary packages make method extension uneasy.
In order to solve these problems, a real-time communica-
tion method for mHealth based on extended XMPP pro-
tocol is presented. With XMPP protocol, functions of
connection maintenance, status tracking and data transfer
process of mHealth services are implemented. By ex-
tending iqand “message” package of XMPP protocol,
the demands for different types of data transfers and ser-
vice requests and responses are met. A system framework
using proposed method is presented to support mHealth
service of telemonitoring scene and concrete system im-
plementation with tests validates the feasibility of the
method and fram e work.
2. mHealth Communication and Existing
The typical mHealth real-time communication process is
shown in Figure 1. User wearing physiological signal
sensors (ECG, SPO2, NIBP sensors, etc.) holds mobile
terminal to collect and transmit signal data and user d ata.
mHealth processing with service results are exhibited in
terminals by communicating with mHealth providers via
server. Different mHealth providers use clients to provide
concrete mHealth services (telemonitoring, online diagno-
sis, health advisory, etc.) on signal data and service re-
quests received from the server [2,3].
The foundation of mHealth service processes is real-
time data transmission of various service requests and
responses. The transmission has three main features [4,5].
First, communication roles, users and providers, stand at
heterogeneous platforms and network environments.
Communication should adapt to different terminal plat-
forms and diverse networks. Second, diversion and ex-
panding of mHealth services need communication pro-
Figure 1. mHealth communication process.
Copyright © 2013 SciRes. CN
tocol to adapt to changing requirements in data encapsu-
lation. Third, some mHealth services such as telemoni-
toring require low-latency transmission.
The existing real-time communication methods for
mHealth use socket or http to maintain data link as well
as perform data transmission using custom binary data
packages [6,7]. These methods have two aspects of prob-
lems. First, due to stateless transmission which most me-
thods are using, they cannot handle service status renew-
al on breakout chain and deal with latency of service
requests and responses. Second, lacking of unified appli-
cation layer protocol and using binary format in data
package make methods not suitable for expanding trans-
mission demand of mHealth services.
3. Communication Method
3.1. XMPP Protocol Basis
XMPP protocol is an X ML based instant messaging pr o-
tocol, which uses XML based structured information dur-
ing entire communication process, having good semantic
integrity and flexible scalability. SASL and TLS built
into the core XMPP specifications guarantees the securi-
ty of the data transmission [8,9].
XMPP protocol use TCP persistent connection to bu ild
XML stream flow which carries messa g e”, “iqand
“presence” packages to composite instant communication
process. This paper uses and extends these basic me-
chanisms to implement connection maintenance, status
tracking and data transfer process of mHealth service.
Based on XEP-0045 standard of XMPP [10], proposed
method constructs the session room to organize the trans-
mission process and trace the status between user and
providers. Data format for mHealth service can be scala-
ble defined by exte nding “message” and “iq” packages.
3.2. Establishment and Destruction of
mHealth services typically involve several roles as user
and multiple service providers. Using session room me-
chanism of XMPP, the method organizes all roles into a
session room initiated by user. With session room, server
can track the status of all roles, forward data packages
during service process and isolate user’s medical data
from external. The communication process is shown in
Figure 2.
1) User conn ects to XMPP server and finishes id entity
authentication. Session room creation request will be sent
after connection established.
2) Server receives session room creation request and
create the room with identity username@service/name.
Then server query providers bounded to user and send
invitation request to them.
Figure 2. Establishment and destruction of communication.
3) Providers receive invitation request and join the
session room. User and providers confirm all the roles in
session room by exchanging “presence” packages and
meanwhile start the service process.
4) Wh en user de cides to termin ate pro cess, iqpackage
will be sent to server for connection destruction.
5) Server receives destruction request and remove all
roles in session room. Then server destroys the session
room and notifies user by sending “iq” package.
3.3. Information Data Communication
Information data of mHealth services refers to non-in-
teractive data passing between user and providers. This
type of data is mainly designed for information delivery
during the servic e process, including user info data, ph y-
siological signal data, diagnostic data, advisory informa-
tion, etc.
The data is packaged as extended message” packages
according to the data type and sent to server. Server will
forward it to corresponding roles of session room. User
or providers receive “message” packages and restore the
information to finish the service process.
With the scalability of XMPP protocol, various data
formats in the mHealth services can be defined. Physio-
logical signal data for instance involves waveform data
like ECG and numerical data like NIBP. A child element
monitordatais added to “message” package to define
the type of data. Specific data can be encapsulated in
XML sematic way or in-band binary way. The XML way
distinguishes types of sensors by ecg” “nibp” element
and record data by body of elements. The In-band way
encapsulates sensor’s byte array in Base64 encoding
packages and attaches them to monitordata” element.
An instance of ECG monitoring data packaged in XML
way is showed in Figure 3. The data includes 3 path
Copyright © 2013 SciRes. CN
Figure 3. ECG monitoring data package.
ECG wave, 1 path RESP wave, HR and RR value. An
instance of 6-parameter monitoring data packaged in in-
band way is shown in Figure 4. The data includes ECG,
RESP, SPO2, PR, NIBP an d TEM P sig nal s.
3.4. Request Data Communication
Request data in mHealth services refers to querying and
setting data between user and providers. This data is mainly
for requests and responses during the service process.
Using “iq” request-response mechanism of XMPP, the
method encapsulates this type of data by adding a new
class of “iq” package.
Taking sensor setting for instance, providers require to
set user-sensor parameters (ECG lead, RESP gain, etc.)
to meet different diagnosis requirements. The communi-
cation pr oc e s s is show n i n Figure 5.
1) Provider sends iqpackage with querysensor/ set-
sensor element to query/set user’s particular sensor’s
2) Server receives and recognizes the request by iq”
package’s querysensor/setsensor element and only for-
ward it to user.
3) User receives “iq” package and query/set particular
sensor, then sends back the parameter value or setting
result to the provider through “iq” result package.
4. System Framework
With proposed extended XMPP protocol method, a
mHealth system framework is designed to support mHealth
service of telemonitoring scene, in which user wearing
physiological signal sensor use mobile terminal to trans-
mit real-time signal data while remote doctor uses client
system to monitor user condition and give medical sug-
gestions [11]. The framework is divided into two parts:
mobile terminal and client.
4.1. Mobile Terminal
Mobile terminal part use Smack library as basis of
XMPP communication. The upper level is divided into
four layers (Figure 6): protocol extension layer which
Figure 4. 6-parameter monitoring data package.
Figure 5. Sensor query/setting communication.
Figure 6. Mobile terminal framework.
handles XML streams of extended XMPP protocol, com-
munication support layer which coordinates underlying
communication processes of various applications, sensor
communication layer which interacts with physiological
signal sensor and application layer which organizes ser-
vice process of telemonitoring.
Protocol extension layer use packet provider mechan-
ism supported by Smack library to extend XMPP proto-
col. XMPP packets’ processing of Smack library is di-
vided into three major parts. First, data packages are re-
trieved or sent from/to socket buffer by Java I/O. Second,
wrapper module i mplements packag e read/write processes
Copyright © 2013 SciRes. CN
by observer pattern. Third, provider module uses pro-
grammed package extension to unpack iq, “message”
and “presence” packages. Protocol extension layer de-
signed by this paper programs the package extension men-
tioned in the communication method via provider module
which can handle the information data from message”
packages and request data from iq” packages.
Communication support layer provides upper applica-
tion layer with required XMPP communication interfaces.
This paper uses singleton pattern to encapsulate five ob-
jects for interfaces of different communication processes.
XMPP connection object provides interfaces for connec-
tion establishment, authentication and connection destruc-
tion between user and server. Session room object pro-
vides interfaces of creation, setting and destruction of
session room, and processes room message exchange.
Sensor setting object encapsulates parameters of all sorts
of sensors and provides interfaces for querying and set-
ting user’s sensors. Information data object and request
data object encapsulate entities with data properties and
their operations, and provides interfaces for packing and
unpacking “message” and “iq” packages.
Sensor communication layer supports sensor operations
through data transfer between mobile terminal and phy-
siological signal sensors.
Application layer is the direct interactio n layer for user
to use telemonitoring service while feature interaction
process is encapsulated into several APIs. Application
layer includes three main modules. User use multi-user
session module to launch telemonitoring service. Data
visualization module and service control module couple
communication support layer and application layer to
handle data transfer, process user interface display and
organize telemonitoring service process.
4.2. Client
Client part implements mHealth service visualization and
operation interface for providers. This paper designs a
telemonitoring extension plugin for Spark (Figure 7) , an
open source IM client based on XMPP protocol which
can be easily extended by flexible plugin structure, to
implement client part. The plugin extends the functional-
ity of multi-user session room window of Spark through
three portions. First, package unpacking/packing module
handles extended XMPP packages during telemonitoring
process through filtering “message” and “iq” packages
sent to session room. Second, interface extension module
adds physiological signal data visualization function to
session room window via Java Swing graphic API to
visualize waveform data and numeric data. Third, tele-
monitoring service module is responsible for coordinat-
ing other modules to organize logic flow of telemonitor-
ing service process, including data transfer adaption, user
interface display and user action response.
5. Tests and Analysis
A concrete mHealth service system is implemented in
this paper to validate the feasibility of communication
methods and system framework as illustrated above. The
system environment is as follows, Android 4.1.0 opera-
tion system used by mobile terminals, service system
based on AS mack, the mon itor powered by Berry
Bluetooth 6-parameter monitoring sensor as physiologi-
cal signal input, Dell Power Edge T110 servers with
Openfire 3.8.1, clients acted by PCs w ith Spark 2.6.3. All
the servers are publicly available, mobile terminal and
client get access to the public network through local
network. Network configuratio n is sh own in Table 1.
5.1. Functional Test
Mobile terminal system runs as shown in Figure 8. Sys-
tem gets physiological sensor data, encapsulates using
XMPP protocol and sends them out to server. Client
works as shown in Fig u re 9, system par ses received data
and provides appropriate services according to the data
Control communicated XML packages are captured by
taking advantage of debug mode. Figure 10 shows the
XML segments of telemonitoring session room creation
process which includes “iqpackages for connection
Figure 7. Client framework.
Table 1. Test system network environment.
Device IP
Mobile Terminal
PC Client
Figure 8. Running status of mobile terminal.
Copyright © 2013 SciRes. CN
establishment and “presence” packages for status com-
munication. Figure 11 shows the XML segments when
monitoring which contains “message” packages for in-
formation data.
5.2. Communication Latency Test
Timestamp is added to the extended protocol in order to
test the latency of real-time communication. Latency
status of the extended XMPP protocol under different
data sizes can be measured by comparing the receiving
time of mobile terminal or client with timestamps. Test
results shown in Table 2 indicate the protocol is able to
deal with latencies because of the persistent connection
feature of XMPP prot ocol.
6. Conclusion
This p aper analyzes the characteris tic of real-time mHealth
communication and existing problems, proposing an ex-
tended XMPP protocol that can be used in real-time mo-
bile medical communication. This approach implements
Figure 9. Running status of client.
Figure 10. XML segments of session room creation process.
Figure 11. XML segments of motoring data.
Table 2. Latency test result.
Direction Data Size (byte) Average Latency (ms/100 packages)
100 130.29
500 131.50
1000 142.41
100 128.54
500 136.28
1000 138.54
Total Average Latency 134.59
Copyright © 2013 SciRes. CN
a universal extensible real-time mHealth communication
application layer protocol by using and extending the
connection maintenance, status tracking and data com-
munication feature of XMPP. Based on that, this paper
presents a system framework that supports telemonitor-
ing scene of mHealth service which is validated by im-
plementation and tests. In the future, the method should
be improved in efficiency based on quantitive analysis
and data compressing.
7. Acknowledgements
This work was f inancially supported by Nation al Natural
Science Foundation of China Youth Foundation
[1] M. Lin and Z. Z. Qiao, “Thinking of Mobile Medical
Demands and Development,” Mobile Communications,
Vol. 23, No. 6, 2010, pp. 31-35.
[2] D. K. Jang, J. M. Kim, S. Sohn and K. R. Han, “Devel-
opment of a Mobile e-Health Care System for Rapid De-
tection of Emergent Situations,” International Conference
on New Trends in Information Scie nc e and Service
Science, Ma cao, 24-26 October 2011, pp. 93-96.
[3] S. Adibi, “Link Technologies and BlackBerry Mobile
Health (mHealth) Solutions: A Review,” IEEE Transac-
tions on Information Technology in Biomedicine, Vol. 16,
No. 4, 2012, pp. 586-697.
[4] E. C. Kyriacou, C. S. Pattichis and M. S. Pattichis, “An
Overview of Recent Health Care Support Systems for
eEmergency and mHealth Applications,Annual Interna-
tional Conference of the IEEE on Engineering in Medi-
cine and Biology Society, Minnesota, 2-6 September 2009,
pp. 1246-1249.
[5] P. Zhou, H. Y. Jiao, F. Wang and C. D. Wang, “Design of
Portable Wireless ECG Monitoring Terminals,” Comput-
er Engineering and Design, Vol. 33, No. 9, 2012, pp.
[6] L. H. Zhong, C. L. Li and W. D. Zhou, “Transmission
and Processing of Home Telemonitoring Data,” Journal
of Biomedical Engineering Research, Vol. 22, No. 4,
2003, pp. 40-42.
[7] M. A. Chowdhury, W. Mciver and J. Light, “Data Asso-
ciation in Remote Health Monitoring Systems,” IEEE
Communications Magazine, Vol. 50, No. 6, 2012, pp.
144- 149.
[8] IETF, “RFC 6120 Extensible Messaging and Presence
Protocol (XMPP): Core,” Standard, 2011.
[9] IETF, “RFC 6121 Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence,”
Standard, 2011.
[10] XMPP Standards Foundation, “XEP-0045 Multi-User
Chat,” Standard, 2011.
[11] W. J. Jia, Y. P. Bai, X. J. Sheng and S. C. Wu, “Devel-
opment of Physiological Multi-Parameters Telemonitor-
ing System,” Journal Press of China Medical Devices,
Vol. 24, No. 8, 2009, pp. 76-78.