with recent trends and technology advancement in the development of converged broadband next generation networks ( ngns ) and advanced multimedia services , the potential has increased for delivering various e - health services to end users  anywhere , anytime  .
the term e - health has been used to refer to the use of information and communication technology ( ict ) in delivering healthcare services . a wide variety of e -
health services exist , including health information networks , electronic health record ( ehr ) , telemedicine services , wearable and portable systems which communicate , health portals , and many other ict - based tools assisting disease prevention , diagnosis , treatment , health monitoring , and lifestyle management .
a related term is m - health , referring to  mobile computing , medical sensor , and communications technologies for health care  .
m - health services refer to e - health services in mobile environments , characterized by limited resource availability and changing network conditions . in general ,
a wide variety of services may be built on top of tools and applications that provide the necessary communications and computer - aided support ( e.g. , multimedia conferencing / streaming enablers , image analysis and visualization tools , immersive and collaborative virtual environments , etc . ) , as shown in figure 1 .
converged ngns are being designed to deliver different types of traffic across heterogeneous end - user environments . in order to meet the requirements of e - health service traffic delivered over networks in conjunction with other commercial traffic ( e.g. , voice calls , streaming multimedia , and internet traffic ) , qos mechanisms such as class - based traffic prioritization are necessary .
the wide variety of e - health services impose different quality of service ( qos ) requirements on underlying networks .
one aspect is delay tolerance , with service requirements ranging from strict real - time and delay - intolerant data transmission ( e.g. , tele - consultation services involving transmission of patient physiological parameters in emergency situations ) to delay - tolerant services ( e.g. , access to a patient 's ehr ; home tele - monitoring ) .
another aspect is application data sensitivity to loss , with conversational voice - based applications often tolerating a certain packet loss , while data transmission ( e.g. , transfer of medical images ) being highly loss intolerant . a significant amount of related work deals with performance requirements of e - health services and evaluated network capabilities in meeting those requirements . in
, the authors categorize the importance of various qos parameters for different fields of e - health . prioritization and resource allocation schemes for various types of telemedicine traffic delivered over wireless networks has been addressed in [ 5 , 6 ] .
further studies have more specifically focused on evaluating support for the delivery of emergency telemedicine services over high speed 3 g networks [ 3 , 710 ] and other wireless networks [ 11 , 12 ] , with evaluation results showing generally reliable performance .
apart from emergency scenarios , 3 g networks have been evaluated in the support of various tele - consultation services involving the delivery of high - definition images , such as the delivery of ultrasound still and streaming images in robotic tele - ultrasonography systems .
projects such as mobihealth , healthservice24 , and myheart   have focused on developing systems for continuous tele - monitoring of patient vital signals and their transmission to healthcare institutes using 2.5/3 g networks .
( it should also be noted that within the european seventh framework programme there are many more projects focusing on e - health services , but they do not specifically consider their provisioning and qos in 3 g networks . ) while this list is by no means exhaustive , it demonstrates the emerging needs which the ngn aims to answer .
limited research , however , has focused on evaluating support for e - health services in the context of the latest ngn standards . in order to support multimedia service delivery over
a multiaccess converged all - ip core network , the third generation partnership project ( 3gpp ) has finalized the release 8 specifications of the evolved packet system ( eps ) , thus representing a milestone in the development of standards for the mobile broadband industry . for a detailed description of eps , an interested reader is referred to .
the eps represents an evolution of the 3 g umts characterized by higher data rates , lower latency , and a packet - optimized system aimed to deal with the rapid growth in ip traffic . a key element of the eps is specification of a class - based qos control concept offering service and subscriber differentiation .
the packet forwarding treatment received by a given session data flow is based on an assigned qos class identifier ( qci ) that serves as a standardized reference to node - specific treatment ( e.g. , scheduling weights , admission thresholds , queue management thresholds , etc . ) .
the 3gpp specifications include nine qcis with corresponding standardized characteristics in terms of bearer type ( guaranteed versus nonguaranteed bit rate ) , priority , packet delay , and packet - error - loss rate . in the context of delivering e - health services , a key issue for the eps qos control architecture will be the accurate mapping of service requirements to qcis .
we emphasize that our focus in this paper is not on determining the actual network requirements of e - health services , as a significant amount of related work deals with this issue .
rather , we aim to contribute to the ongoing research by proposing a mapping of requirements to 3gpp qcis , based on a classification of heterogeneous e - health service context and network qos requirements . the proposed mapping aims to provide network operators with valuable guidelines for enabling service prioritization and making necessary network resource authorization decisions .
the paper is organized as follows . in section 2 , we discuss the various requirements of e - health services and propose a service classification .  
a mapping of e - health service requirements to standardized qcis is given in section 4 .  
section 5 presents an example involving a tele - consultation service between a patient and a doctor used to illustrate eps qos control procedures and use of the proposed mapping to qcis .
among the numerous classifications of e - health services that may be found in literature , services are often broken down based on specific objectives into the following : tele - diagnosis , tele - consultation , tele - monitoring , tele - management , tele - education , and value - added services .
tele - diagnosis services have been described as generally characterized by asynchronous point - to - point communication ( e.g. , specialists at a remote site review transmitted patient data and return a diagnosis report ) , while tele - consultation has been described as generally based on synchronous viewing and manipulation of medical multimedia data .
tele - monitoring in most cases refers to transmission of a patient 's vital bio - signals and other related data , as in the case of home care telemedicine services .
such services are often targeted at treating patients with chronic diseases or for posthospital home care , and may involve multiparametric monitoring including patient vital signs ( e.g. , electrocardiogram ( ecg ) , blood pressure , saturation of peripheral oxygen ( spo2 ) , glucose level , etc . ) , physical sensors ( monitoring patient activity ) , and environmental sensors ( e.g. , air temperature , humidity , and air pressure ) .
the european commission funded mobihealth project has focused on mobile tele-monitoring.tele-monitoring may also involve an expert interacting with a remote examination site using audio / visual communication .
for the purposes of this paper , we use the term tele - education as referring to any health - related education performed at a distance and in non - emergency situations . in
, perakis and koutsouris use the term tele - management to refer to a combination of advanced tele - monitoring and tele - consultation services , such as those involving computer assisted medical interventions and automatic surgical tools ( tele - surgery ) .
a classification of e - health services based on qos requirements has been proposed in vouyioukas et al . .
the authors state that applications may generally be classified as real - time applications and near real - time applications .
we note , however , that in certain cases the instances of the same generic type of service ( e.g. , tele - diagnosis ) may have very different qos requirements depending on actual context in which the service is invoked .
for example , in an emergency situation , a remote specialist diagnosis may require near real - time transmission of medical data , while in a different , non - emergency situation , the patient medical data is transferred ( with tolerance for delay ) to a remote location to be analyzed by specialists .
another example of a service with strict qos requirements and involving patient critical data transmission is tele - surgery .
hence , determining service context in terms of emergency or patient critical versus non - emergency and noncritical service delivery is crucial in providing input for traffic scheduling mechanisms .
context awareness with respect to qos has also been addressed for m - health services , where the authors use contextual information ( information about the user environment ) to adapt the service .  
table 1 illustrates the classification proposed in , extended by the notion of sensitivity to context , whereby context refers to the emergency nature of the service .
all application types for which use in an emergency or patient critical context may be envisioned are marked as being sensitive to context .
we build upon this idea later , in the proposed mapping of qos requirements to qcis .
typical e - health applications may involve multimedia conferencing , transmission of patient physiological parameters , transfer of high resolution medical images , transmission of clinical / administrative data , and access to ehrs .
such applications generate traffic with very diverse network requirements , differing in required bandwidth , real - time versus non - real - time interactivity , and tolerance for packet loss . often times , an e - health service will involve the simultaneous transmission of multiple media flows , such as for example a mobile emergency system including audio / video , medical images , and ecg signals . in this section
, we present an overview of related work that has focused on specifying the requirements of such services .
multimedia conferencing applications are often a key part of e - health services , as they may be used for various communication scenarios including patient - doctor , doctor - doctor ( e.g. , hospital specialists and general practitioners ) , and patient - patient scenarios ( e.g. , virtual support groups ) . furthermore , they may involve preorchestrated , as well as live conferencing .
in general , voice and video transmission applications tolerate some packet loss as a tradeoff for achieving low - delay and real - time interactivity . the third generation partnership project ( 3gpp )
specifies the requirements for conversational audio / video applications in umts networks as being highly delay and jitter sensitive , with one - way end - to - end ( e2e ) delay bounds being 150400  ms . with regards to loss , acceptable frame erasure rates ( fers )
furthermore , the international telecommunications union ( itu ) specifies objective values for ip packet transfer performance in ip networks , with bounds of 100400  ms for e2e delay and 1  10 packet loss ratio for real - time conversational services .
the itu also specifies the model for end - user qos categories with respect to tolerance to information loss and delay tolerance , and provides indicative performance targets for audio and video applications as well as for data applications .
the 3gpp has specified the quality of experience and related metrics of the end - to - end multimedia service performance in 3 g networks .
for example , a service involving audio / video conferencing between a patient and a doctor for a routine checkup may be considered  less critical  with regards to qos guarantees ( i.e. , may tolerate increased degradation and delays of 150400  ms ) as compared to an audio / video conferencing service employed in an emergency accident situation where visual communication with a remote specialist doctor is imperative ( i.e. ,  hard  real - time interactivity with one - way delay 0150  ms ) . in
, the authors note that it is important to distinguish between the requirements for : ( a ) real - time video transmission , ( b ) offline video transmission , ( c ) medical video and audio for diagnostic applications , and ( d ) nondiagnostic video and audio .
real - time video transmission for diagnostic applications is stated as being the most demanding .
real - time diagnostic audio applications include the transmission of stethoscope audio , or the transmission of the audio stream that accompanies the diagnostic video .
the transmission of high definition still images is often a part of a tele - consultation service .
examples of images include : dermatological images , x - rays , magnetic resonance images ( mris ) , ultrasound images , and computed tomography ( ct ) . with regards to bandwidth , there are no specific requirements other than the fact that low bandwidth leads to longer transmission times .
an overview of image sizes and data rates corresponding to typical devices is given in table 2 ( taken from ) .
in general , an important issue in the transfer of medical data is reliable data delivery , with packet losses having potentially disastrous consequences in terms of patient diagnosis .
tele - robotic systems , such as those used for tele - surgery and tele - ultrasonography , may involve the transmission of both still and streaming images .
qos requirements are generally very strict in terms of delay and loss intolerance , with invasive robotic services ( tele - surgery ) being patient critical and thus having more stringent requirements than noninvasive robotic services ( e.g. , tele - ultrasonography ) . in the case of robotic tele - surgery ,
a key requirement is a minimal delay time from when a surgeon 's hand movement is initiated , the remote manipulator actually moves , and images are shown on the surgeon 's monitor .
studies have shown that the limit of the acceptable time delay in terms of a surgeon 's perception of safety was roughly 330  ms .
mechanisms for compensating delay include slowing surgeon hand movement and a remote surgeon performing tasks that require less precision , while a local surgeon performs precision - dependent tasks .
furthermore , it has been noted that two - way video conferencing among members of the healthcare team greatly enhances robotic tele - surgery
. with regards to reliability and error rate , relatively low data rates for transmission of robotic control data ( < 20  kbps ) allow for error - protection coding and the possibility for transmitting equipment to send commands more than once to the receiving end . the qos requirements of a robotic tele - ultrasonography system have been conducted in the scope of the end - to - end mobile tele - echography using an ultralight robot ( otelo ) project .
the project developed a fully portable tele - operated robot allowing a specialist sonographer to perform a real - time robotized tele - echography ( ultrasonography ) to remote patients .
three types of critical data are transmitted over the otelo system : ( 1 ) robotic control data , ( 2 ) ultrasound still images , and ( 3 ) medical ultrasound streaming data , with controlled ultrasound medical streams being the most demanding in terms of data rate ( in that case qcif format and h.263 codec have been used ) . focusing on a umts network ,
the authors point out that for the exchange of medical image sequences with real - time requirements , a mapping to the umts conversational qos class would be necessary .
a test carried out on the otelo system showed reliable functioning of the system with a minimum packet loss of less than 0.5 percent .
furthermore , performance evaluation of the ultrasound streaming images showed that round trip delays ( along the expert - patient - expert path ) of up to 300  ms were within acceptable boundaries of maintaining high / quality real - time interaction of the system .
the amount and frequency of information related to monitored patient vital signs that needs to be transmitted depends on patient needs .
while for some patients it may be sufficient to transmit vital signs every few minutes , other patients ( e.g. , those considered high - risk ) may require transmission every few seconds . in , the authors discuss the requirements of tele - monitoring systems for cardiac patients which consist of wearable and light - weight wireless biomedical sensors ( for measuring 3 lead ecg , spo2 , heartbeat , and blood pressure ) .
sensors communicate with a signal processing module which further transmits physiological measurements ( based on patient - specific thresholds , timing and frequency as specified by a healthcare provider ) via various network interfaces to , for example , hospital servers , emergency stations , local physician clinic , and so forth .
transmission requirements are mapped to the following categories based on the severity of the patient 's health condition ( as specified by a health provider ) :   class 0 : highest priority requiring real - time monitoring ( patients in emergency situations , or , with severe medical conditions ) ; class 1 : requiring near real - time monitoring within a few hours ; class 2 : requiring periodic monitoring such as twice daily ; class 3 : requiring monitoring from time to time .
the mobihealth project   developed a system for the continuous monitoring of patient vital signals ( using body area networks ) and their transmission to healthcare institutes using gprs and umts .
trials were conducted involving home care , high - risk patient monitoring , and emergency services , with the goal being to evaluate whether 2.5/3 g communications technologies can support the requirements of such systems .
different trials were conducted to cover a range of bandwidth requirements ( low : less than 12  kbps , medium : 1224  kbps , and high : greater than 24  kbps ) , and to address both non - real - time ( e.g. , periodic transmission of ecg ) and real - time transmission requirements ( e.g. , alarms , transmission of vital signs in emergency situations ) . at the time the trials were run ( 2003 ) ,
the identified network barriers included restricted available data bandwidth for uplinks ( in tele - monitoring systems , high data rates generally originate at user side , not server ) , delay variation , delays in transmission ( ranging from approximately 100 ms for packet sizes of 174  bytes , to 1200  ms for packet sizes of 8122  bytes ) , and handover ( sometimes resulting in connection loss ) .
one of the most important application areas for telemedicine that relies on broadband services has been recognized as tele - consultation and tele - diagnosis in emergency accident situations , where paramedics attending to accidents do not have the necessary expertise to handle such situations [ 8 , 13 ] .
this results in the need for real - time transmission of accident victim 's physiological parameters ( e.g. , ecg leads , oxygen saturation , and blood pressure ) from an accident site or ambulance vehicle to a hospital / medical center .
furthermore , the transmission of still images and video streaming of the victim to specialized doctors may be of critical importance for the doctor to obtain a thorough clinical image of the patient prior to arrival at the emergency room .
the joint transmission of voice , real - time video , ecg signals , and medical scans from an ambulance to a hospital in a realistic cellular multiuser simulation environment based on umts is further considered in , with corresponding qos requirements summarized in table 3 .
a three - lead ecg signal is sampled at 250  hz and quantized with 12 bits per sample . while voice and video packets are considered error tolerant , ecg and file transmission require data integrity . in their simulations
, the authors set a maximum allowed delay of 400  ms for voice and video traffic and a maximum delay of 300  ms for ecg traffic .
similar research conducted in   provides experimental evaluation of a mobile tele - trauma system capable of simultaneously transmitting video , medical images , and ecg signals in real 3 g network conditions .
various stream parameters have been tested , including different sampling rates , frame rates , resolutions , and so forth .
the authors note that trauma specialists have suggested that a resolution of 320  240 ( tv resolution ) is enough for trauma cases , while a lower resolution of 160  120 may be used in extreme bandwidth conditions . with regards to requirements and stream priorities ,
the authors conclude the following :    video requirements : loss tolerant , delay intolerant , and low priority ; image requirements : loss intolerant , delay tolerant , and medium priority ; ecg requirements : loss and error intolerant , high priority .
the same traffic priority order as used in   has been used by the authors in , who present new scheduling ideas for the integration of telemedicine traffic with other traffic types in a high capacity cellular network , focusing on handling urgent telemedicine traffic transmission with full priority , while satisfying the qos requirements of regular traffic as well .
the four types of telemedicine traffic that were considered by the authors in their simulations : ecg , x - ray files , medical images , and video .
their corresponding characteristics are as follows : ecg data : sampled at 360  hz with 11  bits / sample precision .
a strict upper bound of 1 channel frame ( 12  ms ) is set for the transmission delay of an ecg packet .
the upper bound for the transmission delay of an x - ray file is set to 1 minute .
the upper bound for the transmission delay of an image is set to 5 seconds .
video : h.263 is reported as the most widely used video - encoding scheme for telemedicine video .
traces were used with mean bit rates of 91  kbps , peak rates of 500  kbps and standard deviation of 32.7  kbps . due to the need for very high - quality telemedicine video , the maximum allowed video packet dropping probability
the performance obtained by using simulation , with telemedicine traffic set to 10% of total channel capacity , showed delay and loss values far below the upper bounds set for the particular data type .
in related work , the authors studied the capabilities of a high - speed packet access ( hspa ) 3 g network in meeting the qos requirements of emergency situations involving the joint transmission of voice , real - time video , medical data such as ecg and other vital signals , heart sound , and file transfer .
their results showed that in the case of congestion , congestion control and service prioritization may be used based on modifications in the operation of the hsdpa scheduler ( critical e - health services are treated favorably in comparison with all other kinds of calls ) . by prioritizing emergency e - health services ,
the authors show that delay is constrained within acceptable values ranging from 150  ms to 240  ms in the downlink ( for voip and video , resp . ) , and approximately 200  ms , 500  ms , and 800  ms in the uplink ( for voip , medical data , and video , resp . ) . in , the authors study the qos requirements of a patient tele - monitoring system for emergency vehicles using 3 g umts access and propose adaptive qos decision mechanisms in light of varying network resources .
they identify different types of services ( audio , video , biomedical signals , transmission of high resolution images , transmission of administrative data , and remote ehr access ) which can be combined in different ways based on resource availability to deliver an optimal tele - monitoring service .
combined service qos ( corresponding to simultaneous transmission of different service types in real time ) is evaluated against the following thresholds ( determined based on itu standards and additional referenced work ) : e2e delay threshold for audio as 150  ms and video 250  ms , and packet loss rate as less than 12% audio and less than 10% video . in their previous work ,
the authors have developed an automated tool to model e - health service requirements , and optimize application design regarding available network resources . in
, the author presents a resource allocation model for wireless healthcare information systems which maps e - health applications to three different service classes based on the emergency nature and degree of interactivity ( real time versus nonreal time ) .
the classes include : ( 1 ) highest priority class incorporating life - threatening situations , characterized by very low blocking probability ; ( 2 ) medium priority class representing real - time e - health applications which are not life - critical , with the possibility of qos degradation in order to meet the high priority class requirements ; and ( 3 ) low - priority class representing non - real - time applications whose qos requirements are met when given resources are not required by the other two classes .
simulation results serve to illustrate the benefits of assigning different priority levels to traffic based on the specific medical application requirements . existing and emerging hospital and primary health care information systems
an ehr is designed to contain all possible health relevant data of a person . over the past years
, european governments have identified the ehr as the basis for nation - wide exchange and seamless integration of patient data .
access to and management of ehrs may occur in both emergency and non - emergency situations .
however , a key requirement is reliable transmission with zero packet loss . a wide variety of applications support health related education , such as distance learning for health professionals located in rural and remote areas .
examples of applications include interactive collaborative tools and tele - conferencing , streaming audio / video , virtual classrooms , and interactive surgical simulations .
such applications are generally not considered to be as time - critical as those involving patient care , and may tolerate low delay , data loss , and unavailability .
furthermore , biomedical research may involve the transmission of high - resolution images from remote databases . in the case of remote instrument manipulation for research purposes
, low - delay requirements may result from the need to position samples or adjust instrument settings .
a summary of findings related to the qos requirements for e - health services is given in table 4 .
we group together services based on delivery requirements ( real time or nonreal time ) and transmission type ( two - way conversational communication , unidirectional streaming , interactive request - response , and background data retrieval ) . for certain services , delay requirements are indicated as  not available  since no specific requirements have been found .
for example , in the case of image transfer , delay will depend on image size and available bandwidth .
it is clear that for emergency services , such transfer should be completed within a few seconds .
a general conclusion based on referenced work is that qos mechanisms in ngns are necessary in order to be able to guarantee that the requirements of e - health services will be met , in particular for emergency and patient critical services . in the following sections , we describe the qos control architecture specified by 3gpp and map e - health services to standardized qos classes .
   in order to provide support for ip multimedia services in converged ngns , the 3gpp has specified the eps , comprised of both an evolved packet core ( formerly known as service architecture evolution ( sae ) ) , together with an evolved radio access network ( e - utra and e - utran , commonly associated with the long term evolution ( lte ) work item ) .
the eps also supports non-3gpp access , wireline ( e.g. , xdsl , cable ) , as well as fixed and mobile wireless ( e.g. , wlan , wimax ) .
the eps specifies class - based qos provisioning , allowing operators to differentiate the treatment received by different subscribers and services .
functional network entities and interfaces responsible for providing service - aware qos control have been specified as a part of the overall 3gpp policy and charging control ( pcc ) architecture , illustrated in figure 2 , and briefly summarized next . in general
, the pcc architecture extends the architecture of an ip - can ( ip connectivity access network ) , where the policy and charging enforcement function ( pcef ) is a functional entity in the gateway node implementing the ip access to a packet data network ( pdn ) . an application function ( af ) located along the application - level signaling path interacts with end user applications , situated in the user equipment ( ue ) , and extracts session information from signaling flows .
an example of an af is the proxy - call session control function ( p - cscf ) in the ip multimedia subsystem ( ims ) .
the ims has been specified by the 3gpp ( and further adopted by other standardization bodies ) as a multimedia session control subsystem comprised of core network elements for the provision of multimedia services . in ims , session
qos negotiation procedures are based on an end - to - end message exchange using the session initiation protocol ( sip )   in combination with the session description protocol ( sdp ) .
an enhancement involving negotiable qos based on advanced qos parameter matching and optimization functionality to be included along the signaling path in the ims has been proposed in . once the ue is switched on , a default bearer is established , based on subscribed qos profile .
as shown in figure 2 , the session information is extracted by the af ( 1 ) , and is further passed to a policy control and charging rules function ( pcrf ) ( 2 ) , which is the policy engine of the pcc architecture .
the pcrf makes session - level policy decisions to determine whether the user session can have access to requested services and , if yes , under what constraints .
decision - making is based on the session information received from the af ( 2 ) , combined with the subscription information / policies for a given user received from a subscription profile repository ( 3 ) , and the information about access network technology ( received from the access network ; not shown in the figure ) .
the pcrf then provides session - level policy decisions to the pcef ( 4 ) in the access gateway , where the policy decisions are enforced and used to establish a new bearer or modify an existing bearer ( 5 ) . detailed qos signaling procedures are specified for establishing and modifying bearers . in the scope of the eps , a particular  bearer  is used to uniquely identify packet data flows belonging to a logical ip transmission path that receive a common qos treatment between the terminal and the gateway at the edge of the access network .
hence , the bearer is the basic enabler for providing differential treatment for traffic with differing qos requirements . according to standards ,
it shall be possible to apply qos control on a per service data flow basis .
the two types of bearers that have been defined are guaranteed bit - rate ( gbr ) and non guaranteed bit - rate ( non - gbr ) . in the case of a gbr bearer establishment , network resources are reserved in the network ( e.g. , by an admission control function in a radio base station ) , and as long as traffic along such a bearer conforms to the reserved gbr , it is assumed that no congestion - related packet loss will occur . on the other hand
, services delivered over a non - gbr bearer may experience congestion - related packet loss .
furthermore , a non - gbr bearer may be established for a longer period of time as it does not block transmission resources .
a maximum bit rate ( mbr ) , defined as the upper limit for allowed bit rate on a given bearer , may be defined only for gbr bearers .
an aggregate mbr ( ambr ) values may also be defined for a group of non - gbr bearers ( for uplink and downlink separately ) , thus enabling operators to limit the total amount of bit rate consumed by a single subscriber .
figure 2 shows an example how different bearers correspond to different packet flows for the given ip address of the end user terminal ( one bearer may be established per combination of ip address and qos class ) .
each established bearer is assigned one and only one qos class identifier ( qci ) .
a qci is defined as a scalar value that represents a standardized reference to specific packet forwarding behavior to be provided to a service data flow on the path between a user equipment and access gateway .
( the parameters that control the forwarding behavior are preconfigured by the operator owning the node . )
the goal of standardizing qci characteristics is to ensure that applications and services mapped to that particular qci receive the same minimum level of qos across multivendor networks , in multioperator environment , and in case of roaming .
the 3gpp specifications include nine qcis with corresponding standardized characteristics in terms of bearer type ( also referred to as  resource type  ) , priority , packet delay budget , and packet - error - loss rate ( given in table 5 ) .
a primary difference between qci 14 and qci 59 is the bearer type ( gbr versus non - gbr ) .
the specified packet delay budget defines an upper bound for the time that a packet may be delayed between a user equipment and the access gateway , with actual packet delays  in particular for gbr traffic - expected to be typically lower as long as the end user has sufficient radio channel quality .
the packet error loss rate defines an upper bound for a rate of noncongestion related packet losses .
each qci is further associated with a priority level ( from 1 to 9 , with priority level 1 being the highest ) .
priority levels are used to differentiate between service data flow aggregates of the same ue and also to differentiate between flow aggregates from different ues ( i.e. , a scheduler shall meet the packet delay budget requirements of flows on priority level n in preference to meeting the packet delay budget of flows on priority level n + 1 ) .
while a qci specifies user - plane treatment for associated bearers , the qos parameter allocation and retention priority ( arp ) ( also signaled by the pcrf to the access gateway ) specifies control plane - treatment for bearers , that is , it may be used to decide whether a bearer establishment or modification request should be accepted or rejected due to resource limitations .
the arp parameter contains information about the priority level , the pre - emption capability and the preemption vulnerability of a resource request .
the range of the arp priority level is 1 to 15 , with 1 as the highest level of priority .
values reserved for intraoperator use ( priority levels 18 ) may be used to prioritize ims emergency calls .
the pre - emption capability information defines whether a service data flow can get resources that were already assigned to another service data flow with a lower priority level .
the pre - emption vulnerability information defines whether a service data flow can lose the resources assigned to it in order to admit a service data flow with a higher priority level .
when the system is overloaded , or , when resources must be freed up for other purposes ( e.g. , an incoming emergency call ) , bearers associated with a low arp are released .
for example , for video telephony , the operator may map video to a bearer with a lower arp and voice to a bearer with a higher arp , and thus have the option to drop only the video bearer if needed , while keeping the voice bearer unaffected . in normal circumstances
each eps bearer qos profile comprises the parameters qci and arp ; and for gbr bearers also gbr and mbr . for aggregate ( set of ) eps non - gbr bearers ,
a mapping of authorized ip qos parameters received from the pcrf to authorized umts qos parameters is performed by the translation / mapping function in the packet gateway .
the rules for this mapping with regards to the qci parameter are specified in   and summarized in table 6 .
for the purposes of this paper , we assume that the eps as such can provide the performance as specified and we use these values as a basis for our mapping .
in the context of delivering e - health services over an ngn architecture based on the eps , a key issue for operators will be the accurate mapping of service requirements at session establishment / modification time to standardized qcis .
a particular service may comprise multiple media types and traffic flows that may need to be mapped to different qcis .
( an example of such a situation is shown in an illustrative example later in this paper . ) using as a basis the analysis of referenced work which has addressed the qos requirements of heterogeneous e - health services ( summarized in table 4 ) , we explored the idea of mapping the previously defined types of e - health services to qcis .
while for some types of e - health services this mapping turned out to be rather straightforward , the question of context , as well as  relative importance  between flows belonging to different services within the same qci , proved to be more difficult , as will be explained in more detail shortly . in order to address the requirements of e
- health in different contexts , we find it necessary to break down existing classifications as proposed in [ 7 , 13 ] by considering service delivery requirements ( real time or nonreal time ) and transmission type ( two - way conversational communication , unidirectional streaming , interactive request - response , and background data retrieval ) .
furthermore , certain types of e - health services mentioned in table 4 are broken down into multiple e - health classes based on service prioritization ( emergency versus non - emergency ) . in the case of emergency situations ( e.g. , medical data transmission from ambulance or accident site to a hospital ) ,
data streams should be treated as parts of an emergency session , implying specific call - handling mechanisms and guaranteed qos support
. emergency service support available in current networks generally refers to emergency calls established in the circuit switched domain , such as 112 or 911 voice calls . with regards to
the packet switched domain , emergency ip flows need to be identified by the p - cscf and signaled to the pcrf ( using an emergency indicator ) to allow the pcrf to prioritize emergency service data flows over non - emergency service data flows within the access network .
in addition to assigning a qci value , an arp value may be specified that is reserved for intra - operator use of emergency calls . in general ( not only for emergency services ) during congestion times the arp parameter may be used to assign greater priority to bearer establishment / modification for e - health services , as compared to other typical commercial services ( e.g. , non - health related calls , networked games , iptv , etc . ) .
we assume tele - consultation services to be based on synchronous two - way communication between involved parties based on conversational audio and/or video .
such services generally impose large bandwidth requirements and are delay - intolerant and loss - tolerant .
we therefore map real - time conversational voice - based tele - consultation and real - time conversational video - based tele - consultation to qcis 1 and 2 respectively , with the resource type corresponding to gbr . as the timely and reliable delivery of e - health services may in certain cases be considered of critical importance ( i.e. , a patient 's well being or life is endangered ) , it is imperative that the top priority be assigned to corresponding traffic flows .
we argue that in order to support e - health services , particular classes need to be further broken down with regards to the assigned priority level .
we therefore propose for qci 2 to be broken down with respect to priority level into priority level 2 ( for higher priority conversational video - based services ) and priority level 4 ( standard 3gpp priority level for qci 2 ) .
since qci 3 specifies a gbr and very strict delay bounds ( 50  ms ) , we map hard real - time interactive services to this class .
we identify the requirements of invasive real - time robotic services ( e.g. , tele - surgery involving the transfer of robotic control data and streaming medical images ) as corresponding to qci 3 characteristics , but distinguish such services from non - invasive real - time robotic services ( e.g. , ultrasound examination ) in terms of priority .
we therefore break down qci 3 in two classes corresponding to priority levels 1 and 3 .
first priority application data  , not the  overall first priority  which is reserved for ims signaling . in table 7 , this is denoted as priority level 1*. ) a potential problem with mapping real - time interactive services to qci 3 is that the specified packet error loss rate ( pelr ) for qci 3 is 10 , which is considered too high for critical services such as tele - surgery .
it is interesting to note that in the case where more strict loss requirements must be met , the only mapping that  fits  in terms of both delay and loss is that to qci 5 . considering that qci 5 is normally used for ims signaling ( signaling indication  yes  ) , the operator would need to implement a special policy and resource dimensioning to secure the network resources necessary to accommodate both the signaling and emergency application traffic .
( the application traffic can be distinguished from the signaling traffic by setting the signaling indication to  no  ) .
tele - monitoring services generally refer to services involving the transmission of a patient 's vital biosignals and other related data .
we distinguish between three types of tele - monitoring services based on delay , loss , and bit rate ( gbr versus non - gbr ) requirements .
we map emergency real - time tele - monitoring services to qci 4 and priority level 1 ( 1 * , as noted above ) , assuming applications involving the streaming of patient vital signs in emergency situations and with very strict loss bounds .
non - emergency real - time tele - monitoring services are mapped to qci 4 and priority level 5 and refer to tele - monitoring services that are not of an emergency nature , but that involve a doctor viewing the patient data in real time .
finally , non - real - time tele - monitoring services that are based on patient data which do not involve real - time viewing being delivered to a remote location are mapped to qci 8 because they are delay tolerant and may be assigned a non - gbr bearer .
an example of such a service is patient care , for example , for people with special needs , involving the continuous monitoring of patients at their point of need ( e.g. , home , work , and on the move ) .
we map real - time ehr data access , real - time tele - diagnosis , and real - time messaging services to the equivalent of qci 5 ( with same arguments regarding ims signaling as above ) due to sensitivity to loss , as well as a generally interactive ( request - response pattern of the end user , rather than conversational or one - way streaming ) and high - priority nature of such services .
such services do not require for bearer resources to be blocked for an extended period of time ( as is the case with gbr bearers ) and as such are mapped onto a non - gbr bearer type . however , due to high - priority
, an operator may use the arp parameter to specify the pre - emption capability that allows for the service data flow to be assigned resources that have previously been assigned to another service data flow with a lower priority level . while real - time messaging services representing emergency alarms sent to care givers
are assigned a priority level of 1 ( 1 * , as noted above ) , we assign a priority level of 2 to real - time ehr data access and real - time tele - diagnosis ( generally characterized by data and image transfer ) in order to distinguish from the priority level assigned to ims signaling . on the other hand , we map non - real - time ehr data access / storage , non - real - time tele - diagnosis , and non - real - time messaging services to qci 6 , as such services may be considered more delay tolerant , while being loss - intolerant . while tele - diagnosis services may have high bandwidth requirements due to the transfer of potentially very large medical images , messaging services generally refer to typically low - bandwidth consuming alarms or reminders . in the case of e - health services based on research and education ,
meeting qos requirements may be considered less critical then in the case of patient care services . with regards to delay requirements and degree of interactivity , we distinguish between the following : conversational research and education services mapped to qci 2 and priority level 4 , streaming research and education services mapped to qci 4 ( primarily unidirectional data transfer ) , and interactive research and education services mapped to qci 7 ( characterized by a request - response pattern ) . in the case of services involving the retrieval of health - related information , we distinguish between interactive health information data exchange mapped to qci 8 ( e.g. , health related web sites involving web browsing ) , and non - interactive health information data exchange mapped to qci 9 ( e.g. , background download of health related data ) .
both qci 8 and 9 are characterized by loss - intolerance and delay - tolerance , with qci 8 generally referring to low - priority interactive services and qci 9 referring to low - priority background services ( i.e. , are the most delay tolerant ) .
finally , we identify a class of e - health services referred to as administrative and financial transactions that are mapped to qci 9 and have generally low bandwidth requirements .
examples include patient referrals , appointment scheduling , charging and billing applications , and transfer of prescription orders .
a proposed scheme for assigning qcis and priority levels to e - health service data flows is given in figure 3 .
while standards specify performance requirements for each qci , actual performance that will result if multiple services with a given qci coexist in the network at the same time will depend on operator dimensioning of network resources for each class , as well as specification of arp values including pre - emption capability and vulnerability . in
that respect e - health services do not differ from other active services in the network .
in order to illustrate eps qos control procedures and the proposed mapping of e - health service requirements to standardized qcis , we present a use case involving a tele - consultation service . for the purposes of this paper ,
the service is referred to as e - consult and it involves real - time video conferencing and streaming of ecg signals between a patient and a doctor .
the service enables a patient or doctor to initiate an e - consult session using an early research prototype client application ( figure 4 shows the makeshift gui ) .
the main e - consult console offers the choice of media components to include in the session ( audio / video , audio only , and ecg ) . in case
audio / video is selected , two windows with camera views of the  patient  and the  doctor  , respectively , are shown .
there is also a user - friendly streaming control panel for selecting audio / video quality and starting and stopping the media flows .
, audio and video streaming corresponds to bidirectional conversational streaming , and it has been implemented using the java media framework ( jmf ) api , which enables the capture , streaming , and transcoding of multiple media formats . we simulate a scenario whereby the patient has access to a remote ecg sensor unit and may choose to transmit ecg signal data to the doctor during the active session . in order to simulate streaming ecg data
, we used data available from physiobank , a freely available archive of digital recordings of physiological signals to be used for research purposes .
the recorded ecg files in physiobank used 2- , 3- , and 12-lead ecg records sampled at 500  hz with 16-bit resolution over a 32  mv amplitude range . for the purpose of our ecg visualization ,
a small sample of data extracted from ecg recording was stored in a text file in a numerical format .
the network requirements for audio / video correspond to standard requirements for audio and video streaming , with exact values for network parameters depending on the specific type of codec .
a streaming control panel included in the e - consult application enables end users to configure preferences with regards to audio and video quality ( different chosen quality levels will results in different codecs ) .
audio quality levels correspond to the following jmf codec settings : ( 1 ) low - quality  gsm , ( 2 ) medium - quality  ulaw , and ( 3 ) high quality  mpeg audio .
video quality levels and jmf settings were specified as follows : ( 1 ) low - quality
 h.263 , and ( 2 ) high - quality  motion jpeg . a view of the network architecture used for service delivery and a session establishment signaling diagram are given in figure 5 . in the use case involving ims , both the doctor and
the patient would access the e - consult service via their respective access networks and home ims networks .
( we selected this use case since the focus of the paper is on eps , but in a more general case of end users connecting through their respective access networks through a common core network , qos agreements among the providers involved in the service delivery chain should exist in order to provide end - to - end qos . ) service establishment and modification is based on an end - to - end sip / sdp message exchange via ims control nodes .
service requirements in terms of media types and bandwidth requirements are specified by the end user application and signaled by using sip / sdp .
the signaling diagram depicts the patient application as initiating the session by sending a sip invite message including a session description offer specified using sdp .
the doctor application replies with a 200  ok message including a subset of supported media types and codecs . in this case , we assume that both end users support specified audio , video , and data formats / codecs . as described in section 3 , the p - cscf nodes are responsible for extracting session information and invoking authentication and network resource authorization procedures .
the pcrf nodes are the functional entities responsible for making session - aware policy decisions and signaling bearer establishment / modification rules to the access network ( referred to provisioning of pcc rules in the diagram ) .
this interaction is performed by using an appropriate diameter   application protocol ( as defined by the 3gpp ) .
step 7 illustrated in figure 5 may be executed in parallel with steps 8 and 9 , and step 10 in parallel with steps 13 and 14 . in the case of e - consult ,
the different media flows established as part of the session are mapped to different qcis due to different qos requirements .
we assume the following mappings : ( 1 ) audio stream to qci 1 , ( 2 ) video stream to qci 2 , and ( 3 ) ecg signal stream to qci 4 . considering that the example service is not of an emergency nature
, there is no need to assign arp values corresponding to emergency services . on the other hand , if this were to be treated as an emergency situation , then the ecg signal stream would be mapped to qci 3 , and operator policies would determine what arp values to assign . since qci characteristics are specified for the access network ( ue to access gateway / pcef ) , in the case of two access networks along the end - to - end path , delay values should be summed , and a value for delay in the core network ( likely to be much lower ) added to it .
based on the findings described earlier , and considering that delay values specified for qcis represent upper bounds , it may be concluded that the required end - to - end values could be met .
further research and concrete case studies would be needed to validate these conclusions in practice .
due to a possibly high impact on human life and well - being , e - health services represent a category of services for which the research on qos requirements has moved beyond the well - known properties of individual media flows .
it has been shown that the context in which the service is invoked may determine the actual classification and prioritization of flows .
our work provides some general guidelines and proposes a mapping of e - health service types to standardized qcis in eps as a next - generation communication technology .
a use case of the e - consult service illustrates how the mapping can be applied .
 e - health services comprise a broad range of healthcare services delivered by using information and communication technology . in order to support existing as well as emerging e - health services over converged next generation network ( ngn ) architectures , there is a need for network qos control mechanisms that meet the often stringent requirements of such services . in this paper 
 , we evaluate the qos support for e - health services in the context of the evolved packet system ( eps ) , specified by the third generation partnership project ( 3gpp ) as a multi - access all - ip ngn . 
 we classify heterogeneous e - health services based on context and network qos requirements and propose a mapping to existing 3gpp qos class identifiers ( qcis ) that serve as a basis for the class - based qos concept of the eps . 
 the proposed mapping aims to provide network operators with guidelines for meeting heterogeneous e - health service 
 requirements . as an example , we present the qos requirements for a prototype e - health service supporting tele - consultation between a patient and a doctor and illustrate the use of the proposed mapping to qcis in standardized qos control procedures . 
1. Introduction
2. QoS Requirements for e-Health Services
3. QoS Control in the 3GPP EPS
4. Mapping of e-Health Service Requirements to Standardized QCIs
5. Example
6. Conclusions and Future Work