Energy Efficient Wireless Data Transmission for Personal Health Devices

Abstract

The family of ISO/IEEE11073 standards is the basis of the e-health system and provides interoperability for personal health devices. In the early stage of e-health business, it was expected that people would use a health device individually. In this case, a measurement datum was episodically acquired and generally transmitted for one person at a time. Recently, a health device is expected to be used by multiple people, and large amounts of measurement data are gathered in a short time interval. In addition, mobile health devices have become more popular, so that energy efficient measurement data transmission is required, to prolong the use of a device. In IEEE11073 PHD standards, data transmission is classified into three different types: immediate individual transfer, small block transfer, and large block transfer. The large block transfer using PM-store concept provides efficient transmission. However, an existing PM-store has problem when a device is used by multiple people. To address the defined problem, a modified PM-segment that is in compliance with 11073 standards is proposed in this paper. In particular, the proposed PM-segment is designed to minimize the additional complexity of an agent instead of a manager and it is interoperable with the existing manager. The proposed PM-segment shows better performance than the existing PM-segment, in terms of memory requirements and expected queue time. Also, performance comparison among the three transfers is performed in regard to the delay time and communication power consumption points of view.

1. Introduction

With the advancement of science and technology, the average longevity of human beings has also been increased, and the trend for many advanced countries is to spend more government expenditure on national health [1]. In the same regard, developed countries have put their efforts into finding a systematic solution that will effectively reduce their medical expenditure. As a result, the ISO/IEEE11073 personal health device (PHD) working group (WG) started to make standards entitled “health informatics-personal health device communication” for cost effective e-health services, by providing interoperability for citizen-related medical, healthcare, and wellness devices [2]. Healthrelated personal information acquired by a personal health device (also called an agent) will be gathered and controlled by a manager, to remotely monitor his/her physical status for healthcare services. Interoperability - not among agents but between an agent and a manager - is specifically defined in the 11073 PHD standards.

For the purpose of establishing a system of interoperable personal telehealth solutions in a cost effective way, based on 11073 PHD standards, Continua Health Alliance, with more than 220 member companies, provides the additional protocol stack for increasing the interoperability between an agent and a manager being made by different vendors, and gives developing design guidelines and a product certification program, for safe and effective interoperation between continua-certified agent and manager [3]. In addition, many experts and market leaders expect that the e-health service market applied to a personal user, who has a history of any disease, or who needs to get any health management, will be emerged and expanded, based on the basic personal health devices (PHDs), like thermometer, weighing scale, blood pressure monitor, glucose meter and so on.

But in spite of the efforts and the hopeful market forecasts of healthcare service from many research and consulting centers, as mentioned above, no product for ehealth has yet successfully entered into the consumer’s healthcare market, because of many difficulties; the global economic recession, deficiency in customer satisfaction service, cost-price inefficiency, customers’ lake of awareness of e-health, and so forth. That is, the negative market results indirectly show that private healthcare service is not effective at the present time, even though 11073 PHD standards mainly provide for private use of PHDs, and optionally support multi-person use of PHDs for family members.

Fig. 1.PHD Environment

To partly solve the above difficulties, it is expected that a healthcare system is not privately, but commonly used by multiple persons. When PHDs are used in hospitals, medical service centers, welfare facilities, public health centers, or fitness clubs, there are many advantages, of reasonably reducing the cost, effectively advertising healthcare services, and practically surveying customer demand. After many competitive healthcare products, systems, and services become available, and the cost becomes reasonable and one that a person can willingly pay, many people will start to buy and use his/her own PHDs, and the e-health business will boom.

A personal health device in the above environment will be a nomadic or mobile one within a restricted space, in order to provide easy access for many users. Therefore, PHDs will mainly be powered by a battery, and communicate with a manager by wireless personal area network (wireless PAN). A systematic architecture of ehealth service is shown in Fig. 1, and consists of a personal health device (PHD) network, and health service provider (HSP) network. Our research work is totally focused on the PHD network, including several agents and a manager, that are linked by wireless PAN, including Bluetooth [4] and ZigBee [5].

When a personal health device is used by multiple persons in common-use of a PHD environment (CUPE), one measurement datum is episodically generated for one person at a time, but a lot of measurement data are acquired by an agent in a short time interval. Because the communication between an agent and a manager is pointto- point (P2P) connection, and the resources of an agent (e.g. processing speed, memory space, battery capacity, and so on) are more critically restricted than that of a manager, energy efficient communication between an agent and a manager is definitely required in CUPE, to lengthen the lifetime of an agent. When a piece of body information acquired by an agent is immediately transferred to a manager, an agent shall frequently send a data report message to a manager, so both of them should consume a lot of power for data transmission. In order to save communication power consumption, the number of data report messages should be reduced. Therefore, a fixed amount of measured data has to be stored in an agent, and then all of this will be transferred at once, in an event report message, limited by an application protocol data unit (APDU). That is, the block transmission of a fixed amount of data is much more efficient than immediate individual datum transmission, from the energy saving point of view.

In the case of block transmission, only two different types are provided in 11073-20601 optimized exchange protocol [6, 7]. One is the temporarily stored measurement transfer, and the other is the persistently stored measurement transfer. Because the amount of data transported by the temporarily stored measurement transmission is limited, the agent shall provide no more than 25 temporarily stored measurements in any one event report. When more than 25 measurements are stored and transported, the PM-store mechanism should be used. Therefore, based on the amount of measurements in any one event report, we largely classify measurement transmission from an agent to a manager into the following three different types:

1) Immediate individual transfer (IIT) As soon as a measurement is acquired by an agent, it is immediately transported to a manager. 2) Small block transfer (SBT) At most, 25 acquired measurements are temporarily stored in the memories of an agent, and then they are transported in an event report. 3) Large block transfer (LBT) An agent stores more than 25 acquired measurements in the memory persistently, using the PM-store concept, and then those are transported in an event report.

Our contribution is that the problem of the existing PMsegment in CUPE is clarified and a novel modified PMsegment is proposed to address that. Although the proposed PM-segment has modifications, it is still in compliance with 11073 PHD standards. Moreover, the proposed PMsegment is designed to minimize the additional complexity of an agent instead of a manager and it is interoperable with the existing manager. in CUPE, we classify measurement transmission into three types, and verify the performance of those three in terms of the number of data message transfers, delay time, including queue delay and transmission delay, and communication power consumption. According to our comparison results, LBT can significantly reduce communication power consumption, even though delay time is slightly increased. Therefore, using our research work in CUPE, it will be very helpful to design healthcare systems or services, with resource limitation of an agent.

The remainder of this paper is organized as follows. 11073 PHD standards and the detailed information about the PM-store concept are summarized in Section 2. In Section 3, when a personal health device is commonly used by many users in CUPE and PM-store concept is applied to LBT, firstly the problem of the existing PM-Segment is presented, and then our modified PM-Segment is proposed, to address the defined problem. In Section 4, the simulation results are presented, by comparing IIT, SBT, and LBT using our proposed PM-Segment, in terms of delay time and communication power consumption. We make our conclusions in Section 5.

 

2. ISO/IEEE 11073 PHD Standards

PHD standards aim at addressing the interoperability of PHDs made by different vendors, such as weighing scales, blood pressure monitors, blood glucose monitors, and the like. The scope of 11073 standards is to provide interoperability between an agent that is any of the PHDs, and a manager or compute engine, so any operation between a manger and remote support services is out of the scope of 11073 standards.

11073 standards are mainly available for services related to disease management, health and fitness, or aging independently applications, and it consists of a technical report (11073-00103), device specifications (11073-104zz), and optimized exchange protocol between an agent and a manger (11073-20601), as shown in Fig. 2. 11073 PHD standards are above the transport layer, thereby the most part of 11073 is not specific to any particular transport. But due to the recommendations of Continua Health Alliance, medical profiles for USB (USB PHDC) [8], Bluetooth health device profile (BT-HDP) [9], and ZigBee health care profile (ZHC) [10] were developed by special interest groups.

Fig. 2.Document map

2.1 ISO/IEEE 11073-104zz device standards

11073-104zz standards define the specifications of existing PHDs over 11073-20601. Currently, many PHDs are already standardized and updated, and others are in the process of standardization. For example, thermometer (- 10408) [11], weighing scale (-10415) [12], glucose meter (- 10417) [13], and blood pressure monitor (-10407) [14] are the most frequently used PHDs, and the first standardized, and some will be updated.

2.2 ISO/IEEE 11073-20601 optimized exchange protocol

11073-20601 optimized exchange protocol (20601 OEP) defines a common framework, for making an abstract model of personal health data available in transportindependent transfer syntax. It establishes logical connections between an agent and a manager to provide presentation capabilities and services for communication tasks [6, 7]. Above the transport layer is 20601 OEP, which consists of the application layer services, and the data exchange protocol between agents and managers. The application layer services provide the protocol for connection management, and reliable transfer of actions and data between agent and manager. The data exchange protocol defines the commands, agent configuration information, data format, and overall protocol. Therefore, 20601 OEP provides the basis to support many different types of agents. In this section, 20601 OEP is briefly described, in order to grasp the point of our research work.

The system model of 11073 PHD consists of a domain information model (DIM), service model, and communication model that are specified in detail in 20601 OEP.

1) Domain information model (DIM). The DIM characterizes the information of an agent as a set of objects having one or more attributes, because PHDs specified in 11073 PHD standards are defined using an object-oriented model. Attributes describe measurements that are communicated to a manager, as well as elements that control behavior, and report on the status of the agent. The DIM defines the medical device system (MDS) object (top-most object), scanner object, and metric object consisting of zero or more numeric, real-time sample array (RT-SA), enumeration objects, and persistent metric (PM) object, as shown in Fig. 3.

Fig. 3.Domain Information Model (DIM)

2) Service model. The service model provides data access primitives that are sent between the agent and manager, to exchange data specified by the DIM. Get, Set, Action, and Event Report commands are included in these primitives.

3) Communication model. The communication model supports the topology of one or more agents communicating over P2P connections to, currently, a single manager. For each P2P connection, the connection state machine specifically defines the dynamic system behavior. In addition, the connection machine defines the states and substates an agent and manager pair passes through, including states related to connection, association, and operation.

Because 11073 PHD standards are based on 20601 OEP, an agent and the corresponding manager should be operated within the connection state machine, and an agent is only able to send its measurements to a manager in connected/ associated/operating state using the proper DIM and service model.

2.3 PM-Store concept

A method for representing, accessing, and transferring a large amount of metric data that is stored in the agent is provided by the PM-store concept. In this concept, an instance of the PM-store class provides long-term storage capabilities for metric data that are stored in one or more PM-segment objects. Therefore, PM-store will be used in two different operating environments: one is that an agent should safely store the measurements, because the corresponding manager cannot make a connection properly; and the other is that an agent wants to send a large amount of measurements that cannot be sent by temporarily stored measurement transfer, because an agent shall not provide more than 25 temporarily stored measurements in an event report. As shown in Fig. 4, a hierarchical model of PM-store concept consists of the following four key parts:

Fig. 4.PM-store with 2 PM-segment with fixed segment data

1) PM-store.

PM-store object is at the top level, and attributes about the storage object, as well as zero or more PMsegments, are contained in this object. An agent may provide more than one PM-store, in order to represent the different types of measurement data.

2) PM-segment.

The attributes that describe the segment, as well as zero or more entries, are contained in this object. The agent controls the number of PM-segments located in a PMstore, so a PM-store may have one or more PMsegment objects, when data are present.

3) Entry.

Each entry successively holds an optional entry header, and one or more elements. All entries within a segment should have the same data structure defined by the PMSegment- Entry-Map.

4) Element.

Each element holds data from one or more metric measurements, defined by the SegmEntryElem, within the PM-Segment-Entry-Map. That is an element contains the binary representation of the defined attributes of one metric object.

In addition, the detailed information about interactions between an agent and a manager is based on the PM-store concept in 20601 OEP. In order for a manager to be aware of the existence of the PM-store during the configuring state in the connection state machine, an agent having one or more PM-store objects should have the Handle and PMStore- Capab attributes as a part of the configuration. After the configuration procedure is passed, when both an agent and a manager are in operating state, the manager will query the PM-store object(s) of the agent, and retrieve the information in the PM-store(s), using the following interactions between the manager and agent:

1) Retrieving the PM-store attributes.

When the agent and manager are in the operating state, the manager having information about the existence of PM-store in an agent can inspect the configuration negotiated with the agent, to determine the number of PM-store objects in the agent. The manager may query each PM-store, to retrieve the PM-store attributes, using Get command.

2) Retrieving the PM-segment information.

In order to retrieve information on the segments in a PM-store, the manager can send an ACTION.Get- Segment-Info command to the specific PM-store, with a request to return information from all segments, a particular list of segments, or any segments within a given time range. The first two selection criteria should be supported by an agent, and support for the time range selection criteria may be provided by an agent. The manager is able to know whether the time range selection criteria are provided or not, using the PMStore- Capab attribute obtained in the above interaction.

3) Transfer PM-segment content.

The manager retrieves specific PM-segments by using the Trig-Segm-Data-Xfer ACTION method including information about the PM-store handle to access, and the segment instance number to transmit. The agent shall decide whether the request can be honored, and then send a response, depending on the decision. If the agent sent a successful response, the agent shall send confirmed Segment-Data-Event event reports, until all entries in the PM-segment are sent to the manager, or the transfer is aborted by either agent or manager. When the manager receives an event report, it shall reply with a SegmentDataResult response.

4) Clear a PM-segment.

A PM-segment may be cleared by a manager at any time. A typical time for clearing a segment is directly after the entire segment was transferred to the manager. Depending on the segment selection criteria, all segments, a particular list of segments, or any segments within a given time range can be cleared. After the agent clears the specified segments, the corresponding response should be sent.

Using the above four interactions, a manager can obtain the information about PM-store(s) and PM-segment(s), and let an agent send or clear its measurements in PM-segment(s). Because the manager has to ensure enough memory space to save the measurements sent from the PMsegment of an agent, all interactions, except actual data transmission, are initiated by the manager.

 

3. Proposed PM-Segment

In our research work, it is assumed that PHDs, including thermometer, weighing scale, blood pressure monitor, glucose meter, etc., are commonly used by multiple persons in CUPE. In this case, a measurement will be episodically acquired by an agent, for one specific user at a time. But a lot of measurements will be generated in a short period, due to frequent acquisition for many users. In CUPE, our research is to find an energy efficient measurement data transmission based on 11073 PHD standards, with the consideration of memory requirement, delay time, and communication power consumption in an agent. As mentioned before, according to our criteria of classification, firstly we classify measurement transmission into three; IIT, SBT, and LBT, and then these are compared, in terms of memory requirement, delay time, and communication power consumption.

In this section, firstly, how to implement the three transfers is investigated, based on 11073 PHD standards, and the suitable event types for each of those are specified, respectively. Secondly, when LBT is used in CUPE, it is found that there is a problem in the existing PM-segment, and we clarify what is the problem of the existing PMsegment in detail. In addition we propose a modified PMsegment complying with 11073 PHD standards, to address the problem; and present how to identify our proposed PMsegment from an existing one.

3.1 Implementation issues for three transfers

To find energy efficient measurement transmission in CUPE, measurement transmission is largely classified into individual and block transfers. Then, block transfer is divided into SBT and LBT by 11073 PHD standards. IIT, SBT, and LBT are investigated in detail, based on standards. By the characteristics of local memory in an agent, block transmission is divided into temporarily and persistently stored measurement transfers. The temporarily stored measurements mean that a small number of measurements are temporarily stored in local memory, so SBT belongs to this category. The amount of data transported by this mechanism is limited by 20601 OEP; thereby an agent can transport at most 25 temporarily stored measurements in an event report. The persistently stored measurements mean that a large amount of measurements are persistently stored in local memory, using PM-store concept having one or more PM-store(s), so LBT belongs to this category. If more than 25 measurements are stored and transported in any one event report, the PM-store mechanism should be used for archiving measurements.

Each of the three transfers is characterized, and the suitable event types for each of those are specified as follows:

1) Immediate individual transfer (IIT) This is the generally used measurement transmission, but it spends the largest amount of battery power for data communication among the three, due to the most frequent data transmission. In order to send a single measurement to the manager, MDC_NOTI_SCAN_ REPORT_MP event type should be used.

2) Small block transfer (SBT) The amount of temporarily stored measurements in any one event report is restricted by 11073 PHD standards. Therefore an agent can send at most 25 temporarily stored measurements as a block. In addition, an agent should use the MDC_NOTI_UNBUF_SCAN_REPORT_MP event type for sending a block of measurements to the manager.

3) Large block transfer (LBT) Using PM-store concept, an agent can store and send more than 25 measurements in an event report. But a number of measurements in a block will be restricted by an APDU, because an APDU in the agent-to manager direction shall be no larger than 63K (64512) bytes in size. Also, an agent should use the MDC_NOTI_SEGMENT_DATA event type, for sending a block of measurements based on a PMsegment. The detailed information of measurement transmission is specified in 20601 OEP.

3.2 Problem of the existing PM-Segment

To clarify the problem of the existing PM-segment in detail, the attributes of an existing PM-segment are presented first as follows:

1) Instance-Number 2) PM-Segment-Entry-Map 3) PM-Seg-Person-Id Different persons are differentiated by a Person ID that is uniquely assigned to each of the registered users. If the PM-store is able to store data for multiple persons, the pmsc-multi-person bit in the PM-Store-Capab attribute shall be set. If this bit is set, all PM-segment instances contained in the PM-store shall support the PM-Seg-Person-Id attribute. 4) Operational-State 5) Sample-Period 6) Segment-Label 7) Segment-Start-Abs-Time 8) Segment-End-Abs-Time 9) Data-and-Time-Adjustment 10)Segment-Usage-Count 11)Segment-Statistics 12) Fixed-Segment-Data 13)Confirm-Timeout 14)Transfer-Timeout

Because MP-Seg-Person-Id is an attribute of a PMsegment, as shown above, a PM-segment should be assigned to a person, in accordance with the existing PMsegment. Therefore, when measurements are periodically and frequently generated by a person in a short time, like Electrocardiograph (ECG) or heart rate monitor (11073- 10406) [15, 16], the existing PM-segment has no problem.

But, when an agent using LBT, supports for multiple person mode in CUPE, the problem appears. Because only one Person ID is allowed for a PM-segment, under present 11073 standards, a PM-segment is definitely assigned to one person, and it is impossible to put measurements having different Person IDs into the same PM-segment. Moreover, the measurements stored in PM-store should be sent as a unit of a PM-segment. Therefore, it is quite clear that the amount of required memory for PM-segments will be rapidly increased, when the number of users is increased. That is, the required memory is linearly proportional to the number of users.

In addition, even though large amount of measurements are generated by an agent in a short time period in CUPE, the number of measurements for a specific user is relatively small. For example, no one is likely to take his/her weight over 25 times a day. In order to save more communication power consumption, as many as possible measurements should be put into an APDU. Therefore, measurements contained in a PM-segment will be much larger than 25, the maximum limit of SBT, to make LBT more energy efficient than SBT. But as mentioned above, the amount of measurements generated by a person is relatively too small to fill up and send a PM-segment in a short time. So it is clear that the queue time for sending a PM-segment will be sharply increased, when the size of a PM-segment is increased.

As a result, it is clear that the existing PM-store is not suitable to CUPE, when the memory requirement and queue time are considered. To address the above problem, we propose a modified PM-segment that is in compliance with 11073 PHD standards.

3.3 Proposed PM-Segment

To address the problem of existing PM-segment in CUPE, our research idea is to make a PM-segment be able to contain a large amount of measurements having different Person IDs, with minimized modifications. Therefore, it is needed that the Person ID, like MP-Seg-Person-Id in the existing PM-segment, can be an attribute of memory unit lower than the PM-segment in the hierarchical model of the PM-store concept. That is, in the proposed PM-segment, a Person ID and a measurement can be contained in an Entry, and many Entry(s) can be stored in a PM-segment, as shown in Fig. 5. Thereby, it is possible to put many Entries generated by multiple persons into a PM-segment, because each of the Entries can have its own Person ID in the optional header, and the manager can find out by whom the received measurement was generated. In consideration of compatibility, the proposed PM-segment can have a Person ID as an attribute of either a PM-segment or an Entry. If a Person ID is in Entry, the proposed PM-segment is used. Otherwise, the existing PM-segment is used. The proposed PM-segment is designed to minimize the modification in both the agent and manager sides, and to be compatible with the existing PM-segment.

Fig. 5.Proposed PM-segment

At first, PM-store, PM-segment, Entry, and Element are investigated in detail, to help understanding of our proposed PM-segment. The data types for object attributes and services related to PM-store are PmStoreCapab, PmSegmentEntryMap, SegmEntryHeader, SegmEntryElem List, and SegmEntryElem, as shown in Fig. 6. The specific statistic capabilities and properties of PM-store object instance are defined in PmStoreCapab. pmsc-epi-segentries, pmsc-peri-seg-entries, and pmsc-multi-person play an important role in our proposed PM-segment. If pmscepi- seg-entries is set, some/all of the PM-store contains episodic/aperiodic entries. If pms-peri-seg-entries is set, some/all of the PM-store contains periodic sampled entries. If pmsc-multi-person is set, PM-segment(s) in the PMstore supports multiple persons. Using these attributes, the manager can get two important tips about PM-segment in PM-store: whether multiple person mode is supported or not, and whether a measurement is episodically generated or not.

Fig. 6.Data types for object attributes and object services related to the proposed PM-segment

PmSegmentEntryMap defines the format of all entries in the PM-segment, and it consists of SegmEntryHeader and SegmEntryElemList. SegmEntryHeader defines optional data items related to time information that are located in front of each entry. SegmEntryElemList and its SegmEntry- Elem(s), closely related to the elements, are followed as Element(s).

Our only modification of the proposed PM-segment is that the optional data item, seg-elem-hdr-person-id(3) will be added in SegmEntryHeader, as shown in Fig 6. So, each entry can contain a Person ID in its header field. Therefore, the complexity of an agent is just a little increased, in order to manage seg-elem-hdr-person-id(3) bit in SegEntry- Header attribute, and Person ID in optional Entry header. In this paper, it is recommended that an entry has only one element, as shown in Fig. 5, because the measurements for a person are episodically and infrequently generated.

Now, we have to verify the way for a manager to correctly decide whether the proposed PM-segment, or the existing PM-segment, is used in an agent. Using the information of attributes of PmStoreCapab and SegmEntry- Header, the manager can easily find out whether the proposed PM-segment is used or not. If both pmsc-epi-segentries( 4) and pmsc-multi-person(12) are set in PmStore- Capab, and seg-elem-hdr-person-id(3) in SegmEntry Header is set, the proposed PM-segment is used. If any one of the three bits is not set, the proposed PM-segment is not used, that is, the existing PM-segment is used. Therefore, a smart manager supporting the proposed PM-segment can definitely distinguish the proposed PM-segment from the existing PM-segment, using simple combinational logic, with the three informative bits that are mentioned above. But an existing manager will not support the proposed PMsegment, because seg-elem-hdr-person-id(3) in SegmEntry- Header of PmSegmentEntryMap is undefined information, and any unknown PM-segment operation is rejected. In this case, the agent can be equipped with the existing PMsegment for compatibility.

Without any large burden, the proposed PM-segment can be applied to both an agent and a manager. In addition, the performance of PM-segment in an agent is remarkably improved in CUPE by our proposed PM-segment, strictly complying with 11073 PHD standards.

 

4. Verification and Simulation

To verify the compliance between an agent and a manager equipped with the proposed PM-segment, both an agent and a manager programs are implemented, and tested on the embedded systems as shown in Fig. 7. The embedded system specification is as follows:

1) 8-bit μController 2) 20MHz system clock 3) 1024 bytes SRAM 4) 256 bytes Data EEPROM 5) 14Kbytes Program Memory 6) 4 8-bit Timers & 1 16-bit Timer 7) 1 UART (RS-232) 8) Bluetooth version 1.2

Fig. 7.Embedded system for an agent and a manager

A set of communication messages for the finite state machine is verified under both wired (RS-232) and wireless (Bluetooth) communication environments. The messages are related to the unassociated, associating, associated, operating, configuring, and disassociating states. To verify the compatibility between an agent equipped with the existing PM-segment and the smart manager, the above messages and states are tested on the same embedded systems.

Through simulation, it is presented how much communication power consumption can be reduced from IIT by SBT and LBT, based on the number of messages sent from an agent to a manager. So it is assumed that the amount of measurements transported to a manager is fixed during a time interval, and its communication power consumption is proportional to the number of event report messages, for quantitative comparison. Therefore, the number of messages including one or more measurement (s) is used as a metric of communication power consumption. Secondly, it is shown how much better performance is provided by the proposed PM-segment than the existing PM-segment, in terms of memory requirements, and the expected queue time for sending a PM-segment. Finally, a performance comparison among the three transfers, in terms of delay time and communication power consumption, is presented, using our simulation results.

4.1 Comparison among the three transfers

In order to compare the three transfers: IIT, SBT, and LBT, based on the number of event report messages that is encapsulated in an APDU, it is assumed that the number of measurements is fixed to M during a fixed time period, and each of those is episodically and independently generated by a person among many registered users, at random. In addition, it is assumed that an APDU can contain a lot of measurements, within the maximum limit of an APDU defined by 11073 PHD. Therefore, the number of measurements in an APDU is only one measurement in IIT, at most 25 measurements in SBT, and PM measurements in LBT. Let us notate the number of APDUs required for sending M measurements as NII for IIT, NSB for SBT, and NLB for LBT. Then each of NII, NSB, and NLB can be arithmetically expressed as follows:

where, ⌈·⌉ is the smallest integer that is larger than ·.

Equation (1) shows that block transfer is much better than individual transfer, because the number of report messages is significantly reduced. In addition, as PM in LBT is increased, the number of messages is more drastically decreased, and the communication power consumption will be effectively reduced. Finally, when a certain amount of measurements are gathered during a fixed time period, the larger size of block transfer, the more effectively and efficiently the communication power consumption is saved. So, it is strongly recommended that LBT using PM-store should be applied to measurement transmission in CUPE.

4.2 Comparison between the existing and proposed PM-Segment

In order to compare the performance between the proposed and existing PM-segments, firstly, some assumptions are needed, to make a simplified system model of CUPE. It is assumed that an agent is commonly used by U number of multiple persons, and each of them has his/her own Person ID (how to generate, assign, and identify Person ID is outside the scope of our research and 11073 PHD standards). For a given ith user who has his/her own unique Person ID, where 1 ≤ i ≤ U, it is assumed that a measurement episodically generated by ith user is a discrete Poisson random process, with a mean λi in the time interval T, and independent from others. Let us define the size of PM-segment as the number of measurements, PM, stored in a PM-segment.

When the existing PM-segment is used for LBT, at least (U × PM) amount of PM memories are required, because each of the users should have his/her own PM-segment. On the other hand, the proposed PM-segment just needs PM amount of PM memories. Even though the practical requirement of PM memories needed to store PM measurements in a proposed PM-segment is a little larger than that of a existing PM-segment due to Person ID, segelem- hdr-person-id in the optional header of an Entry, the proposed PM-segment can effectively reduce about {(U-1) × PM} amount of PM memories.

When the expected queue time, E[TQ] for sending a PMsegment is considered, the proposed PM-segment is much better than the existing PM-segment. In the case of the existing PM- segment, E[TQ]existing is calculated as follows:

Because a PM-segment is evenly shared by all users in the proposed PM-segment, the incoming measurement in a PM-segment is a discrete Poisson random process, with a mean λλT in the time interval T, according to the superposition property of the Poisson random process, and λT is expressed as follows:

Therefore, E[TQ]proposed for the proposed PM-segment is calculated as follows:

According to (3) and (4), when U is increased, λT is getting larger than λi, and E[TQ]proposed is getting smaller than E[TQ]existing. As a result, it is clear that the effectiveness of our proposed PM-segment is getting better, in terms of memory requirement and expected queue time, when more users share an agent.

4.3 Simulation results

From the delay time and communication power consumption points of view, the performance comparison among the three transfers is done using simulation results, where our proposed PM-segment is used for LBT. Firstly, delay time based comparison is performed. Let us define the delay time as the sum of the time differences from the generation of a measurement in an agent, to its reception in a manager, for all measurements in a message. Let us denote the jth measurement generated by ith user to Yi,j, and it is assumed that Yi,j is the independently and identically distributed Poisson random process, with a mean λ in the time interval T, where λ has a Gaussian random distribution. The merged Y(x) is the Poisson random process with a mean (U × λ) in T, and Y(x) is ordered by the generation time, where x is a positive integer. Denote tx as the occurrence time of Y(x). It is assumed that there are no data loss in the PM-segment, and no packet loss in communication. Then, the delay time, D consists of the queue delay in the PM-segment, DQ and the transmission delay, DT. So the delay time is expressed as D = DQ + DT. Now let us denote the size of queue, that is, the size of PMsegment, PM in the previous comparison, as q then DQ is expressed as follows:

Let us divide the transmission delay time into three parts; communication preparation time (tpre), transmission time for a common APDU part, including just one measurement (tcom), and additional transmission time for remainder measurements in block transfer (tadd). It is assumed that tpre, tcom, and tadd are fixed and known, depending on the applied wireless communication, and the size of a block. Then, DT is obtained, as follows:

where, α is a parameter for the time to send a measurement.

For our simulation, it is assumed that a standard weighing scale (-10415) is used in a Fitness club, as an example of CUPE, and it communicates with a manager using Bluetooth version 1.2 [17]. In this case, a measurement is not generated at the same time as any other, because an agent is not simultaneously used by many users. It is also assumed that all users visit and generate his/her own measurements within the rush hours in a day, so λ is set to 3 with the standard deviation 0.2, and T is set to 3 hours, in order to make reasonable simulation environment. Then Y(x) is generated to be a Poisson process, with total mean λT (=U × λ) in T. The data rate is 1Mbps and maximum application throughput is 0.7Mbps in Bluetooth version 1.2, so the data transmission rate is fixed to 0.7Mbps [17]. tpre is set to 22.857μS (=16/700,000) for sending a 16-bit control message, tcom is set to 525.714μS for sending a 46-byte event report message including one measurement, and α is set to 182.857μS for sending 16 bytes per measurement. The purpose of delay time simulation is to examine the changing trend of D including DQ and DT, when the size of a block, q, and the number of users, U, respectively, are increased.

As shown in Fig. 8, when q is increased, D and DQ are rapidly increased, but DT is effectively decreased. It is also shown that D is dominantly influenced by DQ, because DT is relatively much smaller than DQ. On the other hand, when U is increased, D and DQ are slightly decreased, because λT is increased and measurements occur more frequently, but DT is not affected at all. Depending on λT, it is possible to find a suitable q, if an application has a constraint on delay time, using our simulation results.

Fig. 8.Simulation results of delay time vs. q

Secondly, based on transmission delay time, DT, it is shown how much communication power consumption is consumed by the three transfers, respectively. For our simulation, T is simply divided into transmitter (Tx) time, TTx, receiver (Rx) time, TRx, and turnaround time, TTA, without consideration of power saving mode, including sleep mode, because the purpose of our simulation is to show the difference among the three transfers, and to find out which one is efficiently saving communication power consumption, and power save mode enlarges the difference. Let us denote power for data transmitter (PTx), power for data receiver (PRx), and additional power for turnaround between Tx and Rx (PTA) are fixed values that are closely related to an applied transceiver IC. Whenever a transition between Tx and Rx occurs during TTA, PTA will be additionally spent. The number of APDUs for each of the three transfers, N, is already a known value in our simulation as NII, NSB, and NLB, respectively, as mentioned before, so the total communication power consumption, PT is expressed as follows:

DT is a known value, and TTA is set to 10 μS. PTx, PRx, and PTA are set to 900μW, 700μW, and 380μW, respectively [18]. As shown in Fig. 9, when q is increased, PT of block transmission is effectively decreased from PT of individual transmission. As DT is not affected by λT, PT is not affected by λT, either.

Fig. 9.Simulation results of communication power consumption vs. q

According to our simulation results, it is clear that the larger block transfer using our proposed PM-segment is the better, in terms of transmission delay time, DT and total communication power consumption, PT, even though the total delay time D and queue delay, DQ are increased. In addition, it is possible to find the optimal block transfer under practical constraints, using our results.

 

5. Conclusion

In this paper, we proposed a modified PM-segment to address the problem of the existing PM-segment when an agent is used in CUPE. First, we classified measurement transmission into three types; IIT, SBT, and LBT, and those are investigated based on implementation issues. In addition, in CUPE, the problem of the existing PMsegment, in terms of memory requirement and expected queue time, was verified in detail. Moreover, it was shown that our proposed PM-segment effectively addresses the mentioned problem, while it complies with 11073 PHD standards. In order to find the energy efficient measurement transmission, the three transfers were compared, in terms of delay time and communication power consumption, using our simulation results. Our research work will be helpful in designing a healthcare system with any of memory, delay time, or power constraints, by supporting optimal energy efficient measurement transmission. In addition, to speed up the expansion of the healthcare service market, including PHDs, the overall introduction of 11073 PHD standards is included in this paper, and we hope our research work will be helpful in improving the standards, because some of the 11073 PHD standards are still in process, and some are updated continuously.

Our research was totally focused on finding the energy efficient measurement transmission in CUPE, using fixed size of PM-segment. In our future work, we will include an adaptive PM-segment that is dynamically controlled, for finding optimal operation on a given delay time, or communication power consumption constraints, with the consideration of a wireless channel situation.