A Distributed Continua AHD System with ZigBee/PAN-IF Gateway and Continua QoS Control Mechanism

Abstract

In a residential or nursing home environment, using ZigBee/802.15.4 wireless network specifically to collect and gather various types of personal health data proves to be a feasible choice. The Continua Guidelines has defined both the sensor-LAN IF (sensor Local Area Network Interface) PHD (Personal Health Device) and PAN IF (Personal Area Network Interface) PHD, but only a Continua certified sensor-LAN IF PHD with Zigbee HC (Health Care) profile can connect with Continua AHD (Application Hosting Device) through Zigbee/802.15.4 network and allows data communicating between AHD and PHDs. In this paper, we present a distributed Continua AHD system design that divides the AHD device containing Continua PAN IF into Continua AHD Host and Continua AHD Gateway with communication through ZigBee/802.15.4 network. Under this structure, a Continua PHD connects with a Continua AHD Host through Continua AHD Gateway within ZigBee/802.15.4 network. One immediate advantage of the proposed system is that both of the Continua sensor-LAN IF and PAN IF PHDs can connect with Continua AHD (Host) through ZigBee/802.15.4 network. To further address the QoS (Quality of Service) issue for Continua PAN IF message transmission in a ZigBee network, we present a software approach to automatically determine the types of packet transmitted and execute Continua QoS control. Together with the QoS mechanism in the enhanced ZigBee MAC Layer, this approach realizes a complete Continua QoS control mechanism for the distributed AHD system.

1. Introduction

The impacts of aging population and gradual insufficiency of medical resources have motivated the health industry to search for more efficient healthcare delivery mechanisms in recent years. Among various proposed healthcare delivery methods, telecare has been recognized as one of the most effective methods. In constructing an effective tele-healthcare system, one of the most important considerations is the establishment of an interoperable standard that is recognized by, and compliant with, all involved parties. With a mission to establish a system of interoperable personal telehealth solutions that fosters independence and empowers people and organizations to better manage health and wellness, Continua Health Alliance [1] was established in 2006. Now, with more than 240 member companies around the world, the Continua Design Guidelines has been regarded as one of the most important references in tele-healthcare systems. This paper describes an innovative system design that focuses on the communication interface standards between AHD (Application Hosting Device) and PHD (Personal Health Device) of the interoperable standard interfaces in Continua Personal Health Eco-System as depicted in Figure 1. Currently, the Continua Design Guidelines has completed two PAN IF Transport Layer standards, namely, BT HDP (Bluetooth Health Device Profile) and USB PHDC (Universal Serial Bus Personal Healthcare Device Class). In addition, a sensor-LAN IF Transport Layer standard based on ZigBee HC/IEEE 802.15.4 [2] has also been completed. It is worthwhile to note that the standard selected by Continua in the Application Profile layer above all these PAN IF and sensor-LAN IF Transport Layer standards is the IEEE 11073 PHD family of standards to enable data format interoperability.

Figure 1. Interoperable standard interfaces in the Continua Personal Health Eco-System (Resource: Continua Health Alliance).

Figure 1. Interoperable standard interfaces in the Continua Personal Health Eco-System (Resource: Continua Health Alliance).

The PAN IF Transport Layer standards in the Continua Design Guidelines provide a point-to-multiple points connection and allow data communicating between AHD and PHDs. However, the transmitting distance specified in this type of connection is limited. On the other hand, a sensor-LAN IF Transport Layer standard permits AHD and sensor-LAN IF PHDs to be connected through ZigBee/IEEE 802.15.4 network. This arrangement extends the transmitting distance between AHD and PHD to a wider coverage of ZigBee/IEEE 802.15.4 network. It is expected in our design approach that a Continua AHD can simultaneously connect all PHDs on both sensor-LAN IFs and/or PAN IFs to aggregate biometric signals and data in residential or nursing home environment with existing ZigBee/IEEE 802.15.4 network. To accomplish this goal, we take advantage of the mature existing system architecture of a ZigBee/IP Gateway and extend it to a ZigBee/PAN-IF Gateway system architecture. Replacing and separating the original Continua AHD with Continua AHD Host and Continua AHD Gateway stacks, this in turn enables Continua PHDs connecting to Continua AHD Host through the following sequence:

Continua PHD→Continua AHD Gateway→ZigBee/802.15.4→Continua AHD Host

Furthermore, since QoS (Quality of Service) plays a major role in the transmission of biometric signals in Personal Health, the Continua Guidelines has described six combination values for parameters in the QoS bin for the transmission of biometric signals in Personal Health based on the two QoS requirements: reliability and latency. With reference to these six QoS bin requirements; we suggest a method in this paper to automatically determine the required QoS Control Parameters in transmitting Continua PHD messages between the corresponding Continua AHD Host and Continua AHD Gateway such that the transmission of biometric signal is compliant with the QoS requirements described in the Continua Guidelines.

In the following section, Section 2, some background information on the gateway architecture that connects the two different networks and the existing QoS controlling methods at the Media Access Control (MAC) layer of a ZigBee/802.15.4 network will be summarized. In Section 3, the design of a distributed AHD system architecture will be presented. The QoS control mechanism at the Application Interface (API) layer and MAC layer will also be described. Finally, a conclusion will be provided at the Section 4.

2. Related Work

2.1. Gateway System Architecture

Connecting two drastically different networks through a gateway device and maintaining seamless and transparent communication between the two networks have always been an important topic in networking and communication. In the document of US Patent number US 8,149,849 B2 [3], two important models were recommended for the system architecture that connects ZigBee/802.15.4 and IP networks. However, it lacks in presenting any solution in dealing with how the gateway handles the QoS requirements across the two connected networks. In the first ZigBee /IP gateway model, there is only a simple IP/Ethernet communication agreement existed on the IP client equipment in the IP/Ethernet network. Similarly, there is only a simple ZigBee/802.15.4 communication agreement existed on the ZigBee client equipment in the ZigBee/802.15.4 network. There is no knowledge of client presence on either one of the client equipments. Through the mapping between TCP/IP port and the ZigBee device in the ZigBee/IP gateway, IP client device can access the resources of ZigBee client device. However, the ZigBee/IP gateway in this architecture must possess complete communication agreements of both networks. Moreover, it has to be able to have transparent transform between the communication agreements of both networks. In the second ZigBee/IP gateway model, the IP client equipment located in the IP network possesses ZigBee/IP/Ethernet hybrid communication agreement while the ZigBee/IP gateway also possesses IP/Ethernet and 802.15.4 mixed communication agreement. This can be pictured as two separated facilities derived from the original ZigBee/802.15.4 client with the simple communication agreement. One of these two facilities contains communication agreement of the ZigBee layers, including stacks above, and the IP/Ethernet. The other facility contains communication agreement of the 802.15.4 layer, including stacks below, plus the IP/Ethernet. Since both of these are covered within the same IP/Ethernet network, a device with ZigBee/IP/Ethernet communication agreement can connect and communicate with a ZigBee/IP gateway device equipped with both 802.15.4 and IP/Ethernet through the IP/Ethernet network. In practice, the facility function of the ZigBee/IP gateway from the second system architecture discussed above is simpler and more cost-effective.

2.2. QoS Control for 802.15.4 MAC Layer

Even though the currently available 802.15.4 MAC standard still does not adequately support QoS control mechanism, research with successful results have been emerging due to practical demands. Kim et al. [4] reported the enhancement of CSMA/CA algorithm by adopting a Priority Toning strategy so that high priority frames can be rapidly handled and transmitted. Unfortunately, this modification is not totally compatible with the current IEEE 802.15.4 MAC protocol due to significant changes required in the protocol. On the other hand, Pang et al. [5] proposed a mechanism to dynamically adjust the size of the contention window so that the performance of the packet transmission in IEEE 802.15.4 MAC can be improved. However, there is no consideration of reliability for various frame transmission control requirements. Moreover, Koubaa et al. [6] introduced the concept of service differentiation for a slotted CSMA/CA frame. Although the approach is promising, it only establishes a differentiation between the high priority MAC command frames and the low priority data frames. There is no further detailed priority control mechanism presented in this article.

In contrast, Garcia and Falck [7] presented a novel mechanism intended to provide QoS for non-beacon-enabled 802.15.4 network. This mechanism is compatible with existing MAC protocol and provides QoS over the IEEE 802.15.4 standard with regard to both reliability and timeliness/latency. In dealing with timeliness, this approach uses the three reserved bits in the Frame Control Field of MAC header to define and convey PacketPriority parameter. This PacketPriority parameter can take on eight different values representing various packet priorities. In addressing the reliability parameter, this approach enhances the existing acknowledgement mechanism in IEEE 802.15.4 standard by applying acknowledgement settings on a per packet basis, depending on its Access-Category parameter. Instead of having macMaxFrameRetries parameter set at a default value of 3 for all packets, it allows various degrees of reliability to be provided for various priorities packets. Nonetheless, the fact that a higher priority packet always requires higher degree of reliability does not fit in the nature characteristics of practical streaming data.

3. Distributed Continua AHD System and QoS Mechanism

Based on the background information and current research on the gateway architecture discussed in the previous section, we herein introduce a distributed Continua AHD system. This system uses ZigBee/802.15.4 network to connect the Continua PAN IFs of Personal Health Devices (PHDs) and to realize the Quality of Service (QoS) in packet transmission.

3.1. Distributed Continua AHD System

We extend and consider the ZigBee/IP gateway structure concept presented in the Patent US 8,149,849 B2 [3] in constructing our distributed Continua AHD system. As depicted in Figure 2, Communication layered stacks and interfaces in Continua AHD are mutually connected with both Continua AHD Host and Continua AHD Gateway accordingly. In an original Continua AHD device, IEEE 11073 PHD Stack passes messages to PAN IF Transport Stack through PAN IF Transport API, whereas PAN IF Transport Stack passes messages to IEEE 11073 PHD Stack through IEEE 11073 PHD API. In the proposed distributed Continua AHD system, we separate the originally combined ISO/IEEE 11073 PHD Stack (including stacks above) and PAN IF Transport Stack (including stacks below) into Continua AHD Host stack facility and Continua AHD gateway stack facility with the corresponding ZigBee/802.15.4 Stacks associated together. In this design, Virtual PAN IF Transport API is contained in the API1 Layer of Continua AHD Host Stack while Virtual IEEE 11073 PHD API is contained in the API2 Layer of Continua AHD gateway Stack. In this manner, the original communication between interfaces within the same stack will be converted and extended to communication among interfaces of different stacks across networks. This conversion is depicted in the following sequences and can be graphically visualized in Figure 3 and Figure 4:

A. Message sequence for ISO/IEEE 11073 PHD Stack → PAN IF Transport Stack:

• a. Original sequence: Continua AHD: IEEE 11073 PHD Stack → (call) Continua AHD: PAN IF Transport API
• b. Coverted sequence: Continua AHD Host: IEEE 11073 PHD Stack → (call) Continua AHD Host: Virtual PAN IF Transport API → ZigBee/802.15.4 network → Continua AHD Gateway: PAN IF Transport Stack

B. Message sequence for PAN IF Transport Stack → ISO/IEEE 11073 PHD Stack:

• a. Original sequence: Continua AHD: PAN IF Transport Stack → (call) Continua AHD: IEEE 11073 PHD API
• b. Converted sequence: Continua AHD Gateway: PAN IF Transport Stack → (call) Continua AHD Gateway: Virtual IEEE 11073 PHD API → ZigBee/802.15.4 network → Continua AHD Host: IEEE 11073 PHD Stack.

Figure 2. Communication layered stacks and interfaces in Continua AHD, Continua AHD Host, and Continua AHD Gateway.

Figure 2. Communication layered stacks and interfaces in Continua AHD, Continua AHD Host, and Continua AHD Gateway.

Figure 3. Message sequence conversion from IEEE 11073 PHD Stack to PAN IF Transport Stack.

Figure 3. Message sequence conversion from IEEE 11073 PHD Stack to PAN IF Transport Stack.

Figure 4. Message sequence conversion from PAN IF Transport Stack to IEEE 11073 PHD Stack.

Figure 4. Message sequence conversion from PAN IF Transport Stack to IEEE 11073 PHD Stack.

3.2. QoS Controller Design

The Continua Design Guidelines uses reliability and latency as the two vectors to describe the QoS requirements of data transmission in Continua Personal Health Eco-System. There are three values representing three degree levels of reliability: Best, Better, and Good; and there are four values representing the four levels of latency: Low, Medium, High, and Very High. Though there are twelve combinations between these two vectors, only six of them are used. From the first two columns on Table 1, we can clearly see the values of various reliability levels in Continua QoS bin and their respective types of message.

Based on the six values in the Continua QoS bin, we can design a QoS Control mechanism for message transmission from Continua AHD host or Continua AHD Gateway to ZigBee/802.15.4 network. This QoS Control mechanism is composed of the following three components:

• 1. QoS control mechanism in API1 and API2 stacks: Automatically monitors message and records connection information. Maps the message type and connection information to a corresponding < Priority, APS ACK, MAC Retries > QoS Control Parameter, where APS ACK and MAC Retries are QoS Control parameters for the stacks at lower layers of ZigBee/802.15.4 network. The message is transmitted based on the value of QoS Control parameters.
• 2. QoS control mechanism in ZigBee layer: To comply with the standard set for Continua sensor-LAN IF, we adopt the APS ACK (Application Sub-layer Acknowledge) mechanism in ZigBee 2007 to support Reliability vector.
• 3. QoS control mechanism in 802.15.4 MAC layer: It has been shown in article [7] that QoS can be achieved with some modified mechanisms at the 802.15.4 MAC layer while maintaining backward compatibility. To meet the End-to-End QoS requirements, we can further modify these mechanisms in supporting the prioritized transmitting service at MAC layer and the proper control of MAC Retries parameters.

In the following, we define the relationship between < Reliability ∙ Latency > in the Continua QoS bin and < Priority, APS ACK/NO-ACK, MAC Retries > QoS Control Parameter. As shown in the first column of Table 1, the Latency in Continua bin is mainly correspondent to the Priority parameter while Reliability is correspondent to APS ACK and MAC Retries parameters. It is also noted that both < better ∙ medium > and < best ∙ medium > are all mapped to the same QoS parameters. To avoid any data loss in blood pressure/blood glucose/blood oxygen saturation measured data in practice, we have upgraded the mapping cases for < better ∙ medium > to the level of < best ∙ medium >.

Table 1. Continua QoS bin /Message Type/QoS Parameter Mapping Table.

Continua QoS bin< Reliability ∙ Latency >	Message Type	QoS Control Parameters < Priority ∙ APS ACK ∙ MAC Retries >
< Best ∙ Very High >	=6:	< 5:Low ∙ 1:ACK ∙ 3 >
	• Print, transfer or exchange of summaries, reports or histories
< Best ∙ High >	=5:	< 4:Medium ∙ 1:ACK ∙ 3 >
	•Both physiological driven alarms and equipment issued alarms
< Best ∙ Medium >	=4:	< 3:High ∙ 1:ACK ∙ 3 >
	• Aka get/set device parameters; aka events and/or notifications; aka request/response
	• Control/status of both physiological and equipment functionality
< Better ∙ Medium >	=3:	< 3:High ∙ 1:ACK ∙ 3 >
	• measured parameter (Blood Pressure, SpO2 (blood oxygen saturation), Heart Rate)
< Good ∙ Medium >	=2:	< 2:VeryHigh ∙ 0:NO-ACK ∙ 5 >
	• waveform information (ex:ECG wave data)
< Good ∙ Low >	=1 : NA.	< 1:Highest ∙ 0:NO-ACK ∙ 5 >

Table 1. Continua QoS bin /Message Type/QoS Parameter Mapping Table.

Continua QoS bin< Reliability ∙ Latency >	Message Type	QoS Control Parameters < Priority ∙ APS ACK ∙ MAC Retries >
< Best ∙ Very High >	=6:	< 5:Low ∙ 1:ACK ∙ 3 >
	• Print, transfer or exchange of summaries, reports or histories
< Best ∙ High >	=5:	< 4:Medium ∙ 1:ACK ∙ 3 >
	•Both physiological driven alarms and equipment issued alarms
< Best ∙ Medium >	=4:	< 3:High ∙ 1:ACK ∙ 3 >
	• Aka get/set device parameters; aka events and/or notifications; aka request/response
	• Control/status of both physiological and equipment functionality
< Better ∙ Medium >	=3:	< 3:High ∙ 1:ACK ∙ 3 >
	• measured parameter (Blood Pressure, SpO2 (blood oxygen saturation), Heart Rate)
< Good ∙ Medium >	=2:	< 2:VeryHigh ∙ 0:NO-ACK ∙ 5 >
	• waveform information (ex:ECG wave data)
< Good ∙ Low >	=1 : NA.	< 1:Highest ∙ 0:NO-ACK ∙ 5 >

3.2.1. QoS Controller Design for API1 & API2 Module

Figure 5 and Figure 6 display the decision flow to determine Message Types and their corresponding QoS Control Parameters.

Figure 5. Message Type & QoS Control Parameters Decision Flow.

Figure 5. Message Type & QoS Control Parameters Decision Flow.

Figure 6. Measurement data transmission from PHD to AHD.

Figure 6. Measurement data transmission from PHD to AHD.

The following describes an example in which an AHD Gateway is connected with a BT HDP Blood pressure meter: In the BT HDP Transport Stack, all the information about BT HDP Connection, also known as MDL (MCAP Data Link) through the connecting process, is available to the BT HDP Transport Stack in AHD Gateway. This information includes Major Device Id (=BT_HEALTH_DEVICE), Minor Device Id (=BLOOD_PRESSURE), MDL_ID (MCAP Data Link Identification), BT QoS bin (=LINK_RELIABLE), and MDL Status (=LINK_ENABLED/LINK_DISABLE), etc. Before the establishment of MDL, it is impossible to transmit IEEE 11073 PHD information between AHD Host and the PHD (in this case, a blood pressure meter) among AHD Host, AHD Gateway and BT HDP blood pressure meter (a PHD). These non-IEEE 11073 PHD messages can be categorized as default (Control/Status) messages with example values of Message Type = 4, Continua QoS bin = < Best ∙ Medium > as shown in Table 1. In practice, since an AHD Gateway potentially can simultaneously connect with multiple BT HDP PHDs and establish multiple MDL connections, it is convenient to create a lookup table that records the QoS information of all MDLs. An example of this can be seen in Table 2, where the recorded information can contain MDL_ID, MDL Status, Message Type, QoS Control Parameters, etc. It is also noted during recording MDL connection information of Bluetooth devices (BT) that we cannot simply map the MDL identification of the message directly to the six types of Continua QoS bin. This is because BT only categorizes the QoS bin of MDL into two categories, namely: Reliable and Streaming. From the data shown in Table 1, we can see that a Reliable message contains four message types: Message Type = {3|4|5|6}; and a Streaming message contains two message types: Message Type = {1|2}. Therefore, we choose to only record QoS Control Parameter when the content of the message are biomedical measurements. This can be exemplified from the descriptions of the two rows next to the last one on Table 1. We can see the first row of these two indicates that a Reliable MDL message containing biomedical measurements corresponds to a measured parameter of Message Type = 3 and QoS Control Parameter of < 3:High ∙ 1:ACK ∙ 3 >. The second row of these two indicates that a Streaming MDL message containing biomedical measurements corresponds to a waveform information of Message Type = 2 and QoS Control Parameter of < 2:VeryHigh ∙ 0:ACK ∙ 5 >. The recording on Table 2 can be illustrated as follows for the first three rows of data:

• 1. A BT MDL connection with label of # 1MDL_ID, Message Type = 3 indicates transmission of biomedical measurements like blood pressure/blood glucose/heart rate, QoS Parameters = < 3 ∙ APS ACK ∙3 >.
• 2. An MDL connection with label of # 2MDL_ID, Message Type = 2 indicates transmission of ECG waveform data, QoS Parameters = < 2 ∙ PS NO-ACK ∙ 5 >.
• 3. An MDL connection with label of # 3MDL_ID, Message Type = 3 indicates transmission of biomedical measurements like blood pressure/blood glucose/heart rate, QoS Parameters = < 3 ∙ APS ACK ∙ 3 >.

Table 2. BT MDL Connection QoS Parameter Mapping Table for measurement data transmission.

Loc_MDL_ID	Message Type	Priority	APS ACK	MAC Retries
#1_MDL_ID	3	3 (HIGH)	1 (ACK)	3 (default)
#2_MDL_ID	2	2 (VERY HIGH)	0 (NO-ACK)	5
#3_MDL_ID	3	3 (HIGH)	1 (ACK)	3 (default)
⋮	⋮	⋮	⋮	⋮

Table 2. BT MDL Connection QoS Parameter Mapping Table for measurement data transmission.

Loc_MDL_ID	Message Type	Priority	APS ACK	MAC Retries
#1_MDL_ID	3	3 (HIGH)	1 (ACK)	3 (default)
#2_MDL_ID	2	2 (VERY HIGH)	0 (NO-ACK)	5
#3_MDL_ID	3	3 (HIGH)	1 (ACK)	3 (default)
⋮	⋮	⋮	⋮	⋮

After the establishment of MDL connection, AHD Host, AHD Gateway and PHD are able to transmit message that contains IEEE 11073 PHD payload through this connection. This message could be any message listed in Table 1. Therefore, API1 Stack and API2 Stack have to determine the type of message from the IEEE 11073 payload. The dicision flow of this process is illustrated in Figure 5 and it is summarized in the following:

First, determine whether the message source includes IEEE 11073 PHD data payload, that is, whether message is transmitted on a MDL or not. If not, this is a Message Type = 4 (default value; Command/Event). If the message source contains IEEE 11073 PHD data payload, then the payload is inspected to determine the message type. If the message type is not related to biomedical measuremnets, Table 1 can be used to obtain the corresponding QoS Control Parameters. Otherwise, Table 2 needs to be used to obtain the corresponding QoS Control Parameters based on its MDL Identification. Figure 6 is an example to illustrate the decision process for the IEEE 11073 PHD data payload containing biomedical measurements. As shown in the first boxed text in Figure 6, when the APDU CHOICE Type in the first column is not equal to 0xE7 0x00 (i.e., APDU CHOICE Type ! = 0xE7 0x00), it indicates that the message is a message of (Message Type = 4) as illustrated in Table 1. On the other hand, when (APDU CHOICE Type == 0xE7 0x00) is the case, further examination on CHOICE and event-type is required to determine the nature of message. Moreover, MDL_ID in Table 2 also needs to be further identified to determine the Message Type and QoS Parameters when the nature of message is identified in the earlier process to be measurements related. The example shown in the second boxed text in Figure 6, CHOICE = 0x02 0x01, represents a remote operation response for a confirmed event. The event-type = 0x0D 0x1D in the last boxed text indicates a measurements transmitting event; hence it needs to use MDL_ID in Table 2 for the determination of QoS Control Parameters.

The QoS controller design for USB PHDC Transport Stack is similar to the process discussed above for the BT HDP Transport Stack. For example, the connection created in USB PHDC is a pipe while the connection established in BT HDP is an MDL. Since the QoS bin of USB pipe can be directly mapped to the six values of Continua QoS bin as depicted in Table 3, the QoS Control Parameters can be identified straightforwardly from the table without analyzing the contents of the message. Therefore, the process in determining QoS parameters for USB PHDC Transport Stack requires no further discussion.

Table 3. USB PHDC pipe QoS bin versus Continua QoS bin.

USB PHDC pipe QoS bin [Delay Reliability]	Continua QoS bin < Reliability Delay >
[very high best]	< best ∙ very high >
[high best]	< best ∙ high >
[medium best]	< best ∙ medium >
[medium better]	< better ∙ medium >
[medium good]	< good ∙ medium >
[low good]	< good ∙ low >

Table 3. USB PHDC pipe QoS bin versus Continua QoS bin.

USB PHDC pipe QoS bin [Delay Reliability]	Continua QoS bin < Reliability Delay >
[very high best]	< best ∙ very high >
[high best]	< best ∙ high >
[medium best]	< best ∙ medium >
[medium better]	< better ∙ medium >
[medium good]	< good ∙ medium >
[low good]	< good ∙ low >

To complete the QoS control mechanism proposed in this paper, the AHD Host and AHD Gateway will first need to obtain the QoS Parameter of a given message using the process discussed above. Additionally, the QoS Control parameters are provided by ZigBee/802.15.4 Stack. It is also noted the mechanism we used in the API1 Stack and API2 Stack contains five Priority Queues and a ZigBee APS ACK response to determine whether a message requires a retransmission or not.

3.2.2. QoS Control Parameters Supported By ZigBee/802.15.4

We adopt the APS ACK (Application Sub-layer Acknowledge) mechanism provided by ZigBee 2007 to support the transmission control of Best Reliability message in API1 and API2 Stacks. Also, since most 802.15.4 MAC layer do not support CFP/GTS (Contention Free Period/Guaranteed Time Slot) transmission mode, we choose only to use the CAP (Contention Access Period) competition mode. Furthermore, unless all packets passing through ZigBee Router support QoS Control, End-to-End QoS cannot be achieved. Therefore, it is required that our 802.15.4 MAC should be able to support compatible QoS Control functions in 802.15.4 MAC standards. To achieve this goal, we use the method presented in article [7] as a base and modify it as follows:

• 1. Following the method in article [7], use 3-bits (Bit 7 to 9) in the Frame Control field of MAC Header to determine eight different service levels, as depicted in the Figure 7. Use the first five values to map the five-priorities in API1 Stack and API2 Stack.
• 2. Instead of using Access Category method in article [7], we expand it directly to five Priority Queues in a direct mapping to the five Priorities.
• 3. For the transmission of Best/Better Reliability type of message where there is APS ACK parameter and Resend support mechanism, we set its macMaxFrameRetries = 3 (default value). However, in order to improve the successful transmission rate for Good Reliability type of message without APS ACK parameter support, we set its macMaxFrameRetries = 5.

Figure 7. QoS-Aware frame control bits in IEEE 802.15.4 MAC header.

Figure 7. QoS-Aware frame control bits in IEEE 802.15.4 MAC header.

4. Conclusions

Although there are many types of information exchanged in an IP/Ethernet network, it is relatively straightforward to establish a ZigBee/802.15.4 wireless network in a residential or nursing home environment. Using ZigBee/802.15.4 wireless network specifically to collect and gather various types of personal health data proves to be a feasible choice. Besides connecting ZigBee HC sensor-LAN PHDs, we establish a distributed AHD system that enables AHD to connect with BT HDP PAN IF PHD and USB PHDC PAN IF PHD through ZigBee/802.15.4 network and provides necessary Continua QoS Control for message transmission. The QoS Control mechanism presented in this paper is a differential service and the priority of message transmission is comparison in nature. Therefore, as the waveform data gets larger, Best Reliability message may encounter longer latency. Fortunately, the chance of transmitting waveform type of data is typically less frequent in a residential and nursing home environment. On the other hand, the ECG waveform monitoring service may be limited in this architecture. Due to overhead of ZigBee/802.15.4 network, the achievable data rate is easily reduced by 50%. This throughput can be further reduced to one third of its capacity by introducing multi-hop technique. So, the actual effective vital sign data rate of a ZigBee/802.15.4 network can easily go down to ~40 Kbits/s. The vital sign data rate requirement for a one-lead ECG waveform data is about 4 Kbits/s to 8 Kbits/s (e.g., 250 samples/s × 16 bits/sample = 4 Kbits/s). Depending on the sampling rate used and number of bits per sample, there are about 5 to 10 patients whose ECG waveform can be continuously monitored and simultaneously supported. In the future, by integrating with existing IP/ZigBee Gateway technology, this architecture may be extended to a suitable network infrastructure to be used in hospitals and commercial buildings.