CN102804694B - Terminal device, coordinator and method for managing emergency events - Google Patents

Abstract

The present invention provides an integrated medium access control for handling separate sets of traffic states separately. It is a further object of the invention to optimize the power consumption during polling based operation of the medium access control mechanism. It is an object of the present invention to provide a polling based error recovery mechanism for obtaining a preferred application reliability by a power efficient and cost efficient method. It is yet another object of the present invention to provide an in-band wake-up method for a medical implant device in a human body area network. It is still another object of the present invention to provide a method for medical implant devices in a human body area network. It is still another object of the present invention to provide a method for simultaneously accessing a power channel of a minimum level based on polling and operating a plurality of body area networks in medical implant communication.

Description

Terminal device, coordinator and method for managing emergency events

technical field

The present invention relates generally to communication systems in body area networks (BANs), and more particularly, the present invention relates to systems and methods for single media access control (MAC) protocols for communication systems in BANs, such as error recovery mechanisms, low power Consumption, emergency message handling, and integration aspects.

Background technique

In a wireless access network, communicating devices of the network typically communicate (with each other and/or with other communicating devices) using radio transmissions that share the same transmission medium, typically the surrounding atmosphere. Although such radio transmissions are typically configured to occupy allocated or assigned frequency bands (also known as sub-channels, and which may be divided in time to form "chunks"), the radio spectrum is simply shared by such transmissions .

The term wireless access network encompasses wireless sensor networks (WSNs) in which the nodes are some type of sensors configured to act at least as transmitters (and sometimes also as receivers). A special form of wireless sensor networks is the so-called body area network or BAN, where sensors are placed at one or more locations on or in a living body for the purpose of monitoring medical parameters or physical activity. Two forms of BANs are MBANs or medical BANs used in hospitals or other health related applications, and wireless BANs or WBANs, this more general designation also extends to eg security applications.

There is a need for a power efficient and reliable medium access control (MAC) mechanism for a body area network (BAN) with devices generating multiple types of traffic, where multiple radio transmissions are constituted to the MAC interface of the wireless system .

Contents of the invention

technical problem

The present invention provides integrated media access control for handling different sets of separate traffic scenarios.

Another object of the invention is to optimize the power consumption during the polling based operation of the medium access control mechanism.

Still another object of the present invention is to provide a polling based error recovery mechanism to achieve desired application reliability in a power efficient and cost effective manner.

Still another object of the present invention is to provide an in-band wake-up method for a medical implant device in a body area network.

Yet another object of the present invention is to provide a method for handling medical emergencies and medical events of implanted devices according to priority in a body area network.

Yet another object of the present invention is to provide a method for accessing poll-based ultra-low power channels and operating multiple BANs simultaneously in medical implant communications.

Still another object of the present invention is to provide a low power single MAC protocol system and method thereof for constituting a communication system for multiple radio transmissions.

Technical solutions

According to an aspect of the invention, a method for managing emergency events in an end device (=end device) is provided. The method includes: determining whether an emergency event has occurred; if an emergency event has occurred, selecting a channel for sending an alarm message indicating the occurrence of the emergency event; using the selected channel to send the alarm message to the coordinator; Determine whether a response message to the alarm message is received within a certain time; and if a response message is received, perform operations related to the emergency event.

According to another aspect of the present invention, a method for managing emergency events in a coordinator is provided. The method includes: sending a polling message to a device causing the device to send data to the coordinator; resending the polling message when no data for the polling message is received; determining the polling message Whether the number of retransmissions of the message exceeds the predetermined maximum number of retransmissions; if the number of retransmissions of the polling message exceeds the maximum number of retransmissions, then migrate to the sleep state for receiving an alarm message indicating the occurrence of an emergency event; when When an alarm message is received, a confirmation message is sent to the device that has sent the alarm message; and operations related to the emergency event are performed.

According to another aspect of the present invention, a method for managing emergency events in a coordinator is provided. The method includes: determining whether energy greater than or equal to a predetermined threshold is detected in a sleep state; when detecting energy greater than or equal to a predetermined threshold, selecting a channel through channel scanning; when detecting an alarm message indicating the occurrence of an emergency When , send an acknowledgment message to the device that has sent the alarm message; and process the emergency event.

According to yet another aspect of the present invention, a coordinator for managing emergency events is provided. The coordinator includes: an energy detector for determining whether an energy greater than or equal to a predetermined threshold is detected, and when detecting energy greater than or equal to a predetermined threshold, triggering a processor in a sleep state; and the processing device, if triggered by the energy detector, transition to the power-on state, and when receiving an alarm message indicating the occurrence of an emergency event, send an acknowledgment message to the device that has sent the alarm message, and process the emergency event .

According to still another aspect of the present invention, a coordinator for managing emergency events is provided. The coordinator includes: a sender, configured to send a polling message to the device to enable the device to send data to the coordinator; a controller, configured to resend when the data for the polling message is not received the polling message, determining whether the number of retransmissions of the polling message exceeds a predetermined maximum number of retransmissions, and if the number of retransmissions of the polling message exceeds the maximum number of retransmissions, transitioning to a sleep state for for receiving an alarm message indicating the occurrence of an emergency event; and a receiver for receiving the alarm message; wherein, when receiving the alarm message, sending an acknowledgment message to the device that has sent the alarm message by means of the transmitter; And performing operations associated with the emergency event.

Beneficial effect

The present invention provides methods for accessing poll-based ultra-low power channels and operating multiple BANs simultaneously in medical implant communications.

The present invention provides an integrated channel access mechanism that will work with separate physical layers that can operate on separate frequency bands.

The present invention provides an efficient poll-based MAC that will significantly reduce power requirements, especially for power-constrained devices.

The present invention provides a method of handling emergency operations where a node or network node may be in a power saving mode such as sleep.

The present invention provides a method of waking up a device in a sleeping state for better management of power consumption.

The present invention provides a mechanism to reduce errors in transmission through an efficient error recovery mechanism.

The invention provides a situation in which devices are admitted according to service level agreements created for the body area network and further networks.

The present invention provides a mechanism to operate multiple networks simultaneously.

Description of drawings

Fig. 1 shows a schematic representation of a BAN star topology according to an embodiment of the invention.

FIG. 2 shows a high-level architecture diagram of a WBAN device according to an embodiment of the present invention.

Figure 3 shows a general superframe format according to an embodiment of the present invention.

Fig. 4 shows a fixed-length superframe format according to an embodiment of the present invention.

FIG. 5 shows a variable-length superframe format according to an embodiment of the present invention.

FIG. 6 shows an exemplary format of an EoP message according to an embodiment of the present invention.

FIG. 7 shows an exemplary format of a POLL (Poll) message according to an embodiment of the present invention.

Fig. 8 shows a schematic representation of a scheduled polling scheme with polling periods according to an embodiment of the invention.

Fig. 9 shows a schematic representation of a delayed polling scheme according to an embodiment of the present invention.

FIG. 10 illustrates different polling schemes associated with different WBAN devices in a BAN star topology according to an embodiment of the present invention.

Fig. 11 shows a schematic representation of the synchronization of the sleep and wake schedules of the WBAN device and the coordinator according to an embodiment of the present invention.

FIG. 12 is an exemplary data retransmission process illustrating polling and data collisions according to an embodiment of the present invention.

13 is a flowchart of the operation of an error recovery mechanism for high data rate applications according to an embodiment of the invention.

Figure 14 shows a schematic representation of polling based error recovery processing for a single data transfer according to an embodiment of the invention.

FIG. 15 shows a schematic representation of polling-based error recovery processing for block data transfers according to an embodiment of the invention.

Fig. 16 shows a schematic representation of a BAN star topology for an emergency situation according to an embodiment of the invention.

FIG. 17 is a diagram showing a system level of a transmitter and a receiver when a coordinator operates according to an embodiment of the present invention.

FIG. 18 is a diagram showing a system level of a transmitter and a receiver when a coordinator is not operating according to an embodiment of the present invention.

19 is a process flow diagram illustrating device-side operations for emergency handling when the coordinator is in an active state according to an embodiment of the present invention.

20 is a process flow diagram illustrating coordinator-side operations for emergency detection when the coordinator is in a sleep state, according to an embodiment of the present invention.

21 is a process flow diagram of coordinator-side operations for emergency detection when the coordinator is in a sleep state according to another embodiment of the present invention.

FIG. 22 is a process flow diagram showing the coordinator side operation when the maximum number of failures occurs when the coordinator is in an active state according to an embodiment of the present invention.

FIG. 23 shows the emergency handling process during the sleep mode of the coordinator according to an embodiment of the present invention.

Fig. 24 shows the emergency handling process during the running mode and idle mode of the coordinator according to an embodiment of the present invention.

Fig. 25 shows the emergency handling process during the run mode and the busy mode of the coordinator according to an embodiment of the present invention.

Fig. 26 shows a block diagram of an implant medical communication process according to an embodiment of the present invention.

Fig. 27 shows a schematic representation of a BAN star topology for implanted medical communication according to an embodiment of the invention.

FIG. 28 shows a state transition diagram of a WBAN device according to an embodiment of the present invention.

Fig. 29 shows a dutycycling scheme in different channels of an implanted device according to an embodiment of the present invention.

FIG. 30 illustrates an exemplary single wakeup process according to an embodiment of the present invention.

Fig. 31 shows a schematic representation of a data communication session showing avoidance of interference so that the implanted device does not wake up during the data communication session, according to an embodiment of the invention.

FIG. 32 illustrates the lock and wake phases in a multi-device wakeup process, according to an embodiment of the invention.

FIG. 33 illustrates an exemplary multiple wakeup process according to an embodiment of the present invention.

Fig. 34 shows a schematic representation of a wake-up message frame format payload according to an embodiment of the present invention.

Fig. 35 shows a schematic representation of a lock message frame payload according to an embodiment of the present invention.

FIG. 36 is an exemplary diagram of a network with a single MAC layer and two physical layers according to an embodiment of the present invention.

Figure 37 is an exemplary representation of a single MAC frame structure with a polling period according to an embodiment of the present invention.

Figure 38 shows channel access for different polling rates according to an embodiment of the present invention.

FIG. 39 is an exemplary representation of a polling frame structure for on-body communication according to an embodiment of the present invention.

FIG. 40 illustrates single polling rate channel access according to an embodiment of the present invention.

Figure 41 shows a MAC protocol with multiple routines according to an embodiment of the present invention.

Figure 42 shows a MAC protocol with a single routine according to an embodiment of the present invention.

Figure 43 illustrates a single MAC architecture for implanted and on-body dual PHYs according to an embodiment of the invention.

FIG. 44 is a flowchart illustrating coexistence of multiple implanted networks according to an embodiment of the present invention.

Figure 45 is a schematic representation illustrating exemplary power saving options according to an embodiment of the present invention.

Figure 46 is a process flow diagram of an exemplary method for microscopic power saving in accordance with an embodiment of the invention.

Detailed ways

It should be noted that in the drawings, method steps and system components have been represented by conventional symbols, only showing specific details relevant to an understanding of the present disclosure. Also, details that would be apparent to one of ordinary skill in the art may not be disclosed. In this disclosure, relational terms such as first and second, etc. may be used to distinguish one entity from another without necessarily denoting an actual relationship or order between such entities.

The present invention provides a channel access mechanism for handling traffic where there are different schemes such as low data rate constant bit rate applications, high data rate constant bit rate applications and variable data rate high bit rate applications scheme method. This channel access scheme helps to enable body area network applications such as medical applications and non-medical applications to share wireless channels simultaneously. The requirements of each of these varying applications are very different, and thus it is not easy to design a single channel access mechanism, whereas the disclosed concept provides an integrated approach to such channel access schemes.

In addition to the above situation, some medical applications have high reliability requirements, thus, the channel access mechanism should also help the error recovery of wireless data transmission that will have any errors due to loss of data reception, etc.

Other recognized requirements for such device classes also support emergency medical situations for medical applications. There are also instances of incorporating efficient and faster wake-up schemes that would enable faster response for reducing power consumption and also reducing response time.

This disclosure considers low power design for channel access mechanisms for wireless personal area networks. In media access control, the following designs are uniquely provided.

First, an integrated media access control mechanism is provided that will handle a different set of separate traffic scenarios. Second, low power based operation of the medium access control mechanism is provided which reduces battery usage in an efficient manner. Third, an identified urgent data transfer mechanism for faster transfer of urgent data from a device to a monitor or coordinator device is proposed. Fourth, faster re-operation of the device is proposed when the device goes through power saving mode and is in sleep state. Fifth, a coexistence mechanism is proposed in which multiple piconets operate and cooperatively share available physical channels.

In an embodiment of the invention, resources such as bandwidth are not reserved for emergency services, receiver radio frequencies for emergency data transmissions are not known to the device, and resources are not reserved for emergency message transmissions. Moreover, in an embodiment of the present invention, a wake-up mechanism is proposed, and a mechanism for obtaining a fixed polling time is proposed.

The present disclosure is specifically designed by keeping in mind the special requirements of compact and power-efficient media access control for Body Area Networking (BAN) applications.

Before describing the present disclosure, the BAN used in the present disclosure will be briefly described.

BAN is a relatively new concept that is being standardized. Work has begun within the Bluetooth SIG, the Zigbee Alliance, to create BAN standards, but these standards are also well set up and incorporated into a considerable number of devices. Existing standards such as the Bluetooth SIG and the Zigbee Alliance are focusing on aspects related to single-mode utilization of body-worn BAN nodes. Currently, IEEE working group 802.15 has advocated new mechanisms that will enable standardization of body area network networking. The focus of this new standardization is to develop a physical layer (PHY) and media access control layer that will be adapted to work for channel environments specific to the human body.

Thus, the disclosed MAC concept is specifically designed with considerations such as power consumption, faster emergency operation, power-efficient wake-up mechanisms, error recovery mechanisms, independent of any specific physical layer design, and the uniqueness of the concept It is also an aspect that addresses methods of integrating channel access mechanisms where the physical layer may be separate.

Reducing power consumption at the MAC layer is also design critical, considering the form factor and battery backup available in the device. The scope of BAN applications is medical, non-medical and entertainment applications, and the design considers a common way to address these applications in an integrated manner. There are also situations where urgent data needs to be processed in view of life-critical aspects of Internet of Body applications, and the handling of such urgent data is also provided in this disclosure.

Wireless channels are error prone and unreliable. A better way of handling or reducing errors in BAN is particularly important considering medical situations are involved. Error handling and mitigation are also uniquely designed and addressed in this disclosure.

In other standards such as 802.11 PCF mode and 802.16, poll-based MACs have been proposed. However, the basic requirements of the upcoming 802.15.6 standard are to save energy and obtain latency and reliability requirements. The design paradigm for energy-constrained networks is different. The primary design objective is to reduce power consumption and at the same time meet the quality of service (QoS) requirements of different services. A power optimized polling mechanism is proposed in this disclosure for energy constrained networks such as 802.15TG6. The approach proposed in this disclosure differs from the prior art in the following ways:

First, they differ in that in a single MAC architecture, multiple transceivers share the channel access mechanism in time, and the channel access mechanism is a polling mechanism. Second, unlike 802.11 and 802.16 standard devices, 802.15TG6-BAN devices generate services dedicated to a specific application. Application-specific devices in 802.15TG6 can sleep immediately after completing a data transfer operation and become active until the next data transfer time. Such features allow 802.15TG6 devices to conserve energy and comply with QoS requirements at the same time. Third, in the existing automatic repeat request (ARQ) or error recovery mechanism, the device can use the polling message to resend the data immediately after the data is lost, instead of performing Resource security and notification procedures with specific delay times.

New receiver-driven ARQ mechanisms need to evolve for networks with constraints where contention is not a priority due to power consumption and asymmetric channel sensing, due to US Communications Commission (FCC) Limitations of use stipulate that the device cannot initiate data transfers.

Fourth, the present disclosure handles specific QoS requirements for urgent data when the receiver is in sleep mode and polling in a channel unknown to the sender and when the receiver is in active mode and the sender has no information about the receiver's operating channel .

Fifth, prior art solutions cannot solve the problem of multiple wakeups in implanted communication systems. Existing wakeup mechanisms for a single implant can be repeated multiple times to wake up multiple implants. However, it may introduce intolerable wake-up latencies and high signaling overhead for implanted devices. A method is proposed for waking up multiple implanted devices in a manner that reduces worst case wakeup latency for a system comprising multiple implanted devices and an external coordinator. An in-band wake-up solution also has the added advantage of being a single radio and low cost.

Sixth, a coexistence mechanism for operating multiple piconets simultaneously is proposed. In the coexistence mechanism, the piconet is a secondary user, requiring listen before talking (LBT) or adaptive frequency agility (AFA) + LBT to occupy the channel, the end device cannot initiate communication, the transmission power is limited, and the channel sensing is non- Symmetrical.

Seventh, a power-efficient polling mechanism is proposed to meet the setup of various QoS requirements for different kinds of traffic, where one device has the following constraints. LBT or AFA+LBT are required to occupy the channel, end devices cannot initiate communication, transmit power is limited, and channel sensing is asymmetric. Another device has the following properties: low and constant arrival rate. Another device has the following properties: a high and constant arrival rate, and a high and variable arrival rate.

The present invention provides integrated media access control for handling different sets of separate traffic scenarios. Furthermore, the present invention provides methods and systems for optimizing power consumption during poll-based operation of a medium access control mechanism. Furthermore, the present invention provides a polling based error recovery mechanism to achieve desired application reliability in a power efficient and cost effective manner.

The present invention provides an in-band wake-up method for a medical implant device in a body area network. Furthermore, the present invention provides a method for handling medical emergencies and medical events of implanted devices according to priority in a body area network. Furthermore, the present invention also provides methods for accessing poll-based ultra-low power channels and operating multiple BANs simultaneously in medical implant communications.

method 1

The present invention provides solutions for handling channel access mechanisms in which there are different types of traffic such as low data rate constant bit rate applications, high data rate constant bit rate applications and variable data rate high bit rate applications method. This channel access mechanism helps to enable BAN networking applications such as medical and non-medical to share wireless channels simultaneously. The requirements for each of these varying applications are quite different and thus it is not easy to design a single channel access mechanism.

To meet the requirements of the application, IEEE802.15TG6-Body Area Network (BAN) can operate in star topology or extended star topology. The present invention is based on a star topology; however, the proposed solution has the scope to extend to future extended star topologies.

As shown in FIG. 1, in the star topology of the present invention, a communication session is established between an end device and a BAN coordinator. BAN is considered an application to support embodiments of the present disclosure. The focus of BAN can be broadly divided into two categories, implanted communication and on-body communication. Implanted communications will support services for medical applications, while on-body communications will support services for both medical and non-medical applications.

For on-body communication, both the coordinator and the device can initiate or terminate the communication. Additionally, a coordinator can route data from one device to another. BAN traffic is basically dominated by upstream traffic where devices (sensors attached to the body) generate data and send data to the coordinator. However, the coordinator can send any application-specific data to the device if desired.

In the present invention, it is assumed (as shown in Figure 1) that for a relatively simple and reliable standard, the topology is configured in a star or extended star. A communication session is established between an end device and a BAN coordinator.

According to Fig. 1, the present invention proposes an operation scheme for personal communication services called Body Area Networks (BAN), for medical or entertainment services. In addition, for power consumption optimization, the present invention proposes a resource access method based on polling. Furthermore, the present invention proposes a power-efficient and cost-effective poll-based error correction method. Besides, considering the resource access method, the present invention also provides an in-band wake-up method, a method for processing emergency signals and a method for simultaneously operating multiple BAN piconets for on-body implantation of medical instruments.

Figure 2 shows the architecture of a WBAN device. IEEE802.15TG6 devices may include PHY120 or PHY222 or both PHY120 and PHY222, which include transceivers for signal transmission and reception. The PHY1 transceiver operates in a frequency band suitable for implant communication, while the PHY2 transceiver operates in a frequency band suitable for on-body communication. The IEEE802.15TG6 device also includes a MAC layer 24 and an LLC layer 26 to access a channel of a selected frequency band for various types of data transmission.

A BAN can support single or multiple PHYs. Possible PHYs may include MICS, ISM, UWB, etc. When multiple PHYs are used, they collectively use different frequency bands, but they may need to operate in the same frequency band depending on the requirements of the application.

It is desirable to design a single MAC that supports the transmission of data on both the implanted and on-body communication bands and satisfies the functional requirements of both the implanted and on-body communications. A single MAC architecture on a device with two different physical transceiver structures is depicted in FIG. 2 .

The network generates five services as described in Table 1 with different settings of QoS requirements.

Table 1

The MAC function is described as follows. The proposed MAC for BAN is a hybrid of contention-based and non-contention channel access mechanisms to take advantage of both. The timeline is divided in multiple superframes, where each superframe consists of parts based on contention and non-contention access mechanisms. In particular, the invention relates to poll-based non-contention channel access. To complete the MAC protocol, details of contention-based access are provided.

The superframe structure is shown in Figs. 3 to 5 . In one superframe, the time interval established by the coordinator is divided into multiple parts to provide various channel access methods for network devices. The superframe duration (SD) is determined by the coordinator to meet the communication requirements of all devices connected to the network. A superframe is divided into four main parts, as shown in Figure 3 which describes the structure of a general superframe containing all parts.

Polling-based resource access and error correction methods will be described below with reference to FIGS. 3 to 5 .

Assuming that there is a contention-based resource access method and a non-contention resource access method in a superframe, the present invention mainly proposes the order of the two methods and the polling-based method in the non-contention period.

Referring to FIG. 3, the polling period (PP) is used by the coordinator to provide poll-based channel access to network devices by polling each device according to the polling mechanism and polling scheme employed for the devices. This time period is mainly used for the transmission of data frames to and from the coordinator. The size of PP in a superframe depends on the number of devices and the time interval allocated to each device (allocation interval). Depending on the polling mechanism employed, this size may or may not change over the superframe. In other words, PP is a time period for polling-based resource access, and its length can be determined by the coordinator according to the number of connected devices or the required data rate.

The Extended Polling Period (EPP) is used to handle additional data transmission and retransmissions required by the device/coordinator due to packet drops, changes in packet arrival rate, and on-demand traffic. In other words, the EPP is used for additional transmission when data supporting retransmission or irregular data occurs in the event of a transmission error occurring in the PP.

The allocation interval in EPP is not pre-scheduled, and it is scheduled to devices in real-time during the polling period of a superframe for additional data transmission and/or retransmission of frames. The actual length of the EPP in a superframe is not fixed throughout the superframe; it depends on the dynamic requirements of the device and channel environment. The size of EPP in a superframe can vary from 0 to SD, to PP, to minCAP, to IP.

The Contention Access Period (CAP) is used for the transmission of data/control/management frames to and from the coordinator. The channel access mechanism suggested in this section is contention-based, where devices first compete to acquire the channel before data transmission. CAP can be absent if not needed. The length of the CAP is dynamic throughout the superframe. When present, the duration of CAP (if present) can vary from minCAP to SD, to polling period, to EPP, to IP.

CAP is the same as the usual contention period and is used for transmission of control/management frames in addition to data transmission. In this disclosure, the length of the CAP is known from the coordinator to the end devices through the end of poll (EOP) message, and it can be shortened according to changes in the EPP, but at least not below minCAP. Thus, in each superframe, the length of the CAP can vary from minCAP to SD, to PP, to EPP, to IP.

An Inactive Period (IP) is an optional inactive part that a superframe can have. During the inactive part, the coordinator can either enter a low power mode or use the inactive time period to share channel bandwidth with other coexisting networks.

Each of PP, EPP, and CAP belongs to an active period (AP), and they are periods in which the coordinator performs a resource access operation. In contrast, IP is the period of time in which the coordinator is only in the receive state or transitions to the sleep state for low power consumption. This time period may also be used to avoid interference in coexistence between piconets.

An End of Poll (EoP) message is a specific frame marker and is shown in FIG. 6 . EoP messages are sent by the coordinator after completion of PP to advertise the duration of EPP, CAP and IP.

An EOP message is sent upon completion of PP. This message basically indicates the length of the CAP and IP, and if necessary even the length of the EPP. The location of CAP, EPP and IP can be indicated in the 'frame specification'.

The concepts of fixed-length, variable-length superframe and no-superframe structures will be described below with reference to FIGS. 4 and 5 .

When an end device is connected, the coordinator receives the required data rate and traffic type of the end device and operates superframe. The coordinator can change PP and EPP operation methods in consideration of information on end devices. Figures 4 and 5 illustrate QoS for handling energy-constrained devices and devices requiring different methods of operation, respectively.

As shown in Figures 4 and 5 are superframe structures with fixed and variable superframe durations, respectively. The size of a superframe can be fixed or variable. Fixed superframes are useful for energy constrained devices with deterministic or periodic packet generation. The fixed superframe in Figure 4 provides a deterministic sleep and wake schedule for devices.

In FIG. 4 , an end device utilizing PP periodically performs wakeup/sleep and performs access in a poll allocation interval. Although each superframe is invariant from the transmission time of the EOP message to the end of the CAP, since end devices with errors or requiring additional transmissions in the PP should be processed during the EPP following the EOP message, EPP and CAP Can vary according to variability. In this operation method, since the allocation interval for a specific end device has periodicity, if the end device wakes up accurately for polling, the effect of power reduction can be obtained.

On the other hand, the variable superframe in Figure 5 is useful for supporting data transfers from devices with uncertain and busy packet arrivals. Typically, non-medical applications have stringent QoS (delay and jitter) requirements. In the case of variable superframes, no EPP is required since variability and retransmissions are handled by changing the size of the superframe. In Fig. 5, since the erroneous end device in PP is processed immediately without waiting until after the EOP message, the sending time of the EOP message can vary according to the variability of the PP, and thus the length of the SD of the entire superframe period It can also be variable. Therefore, in this operation method, in each end device, retransmission due to an error is performed immediately, which makes it possible to prevent transmission delay or jitter, and ensure reliability.

It is also possible that there are only variable PPs in a superframe without CAPs and inactive periods. In the operation of FIG. 5, if the EOP is not transmitted, the CAP is also not used, and a no-superframe structure operating only in the PP is also available. The transmission/reception between the coordinator and the end device is implemented as a whole by polling, and the control/management related part is instructed by the coordinator sometimes by sending CAP of EOP notification.

In this particular case, there is no superframe structure so defined by the coordinator. Figure 5 shows a variable PP without a superframe structure. The coordinator may decide not to send EOPs periodically and it may occasionally send an equivalent broadcast message to aid certain network operations.

In the case of a poll-based channel access mechanism, in order to allow channel access to a device, the coordinator sends a POLL message destined for a specific device. An exemplary format of a POLL message according to an embodiment of the present invention is shown in FIG. 7 . Referring to FIG. 7, an 'ontime' field 70 is a one-bit field in a fixed superframe for synchronization with a device clock of an end device. The 'window size' field 72 is a field indicating the data capacity (the number of data frames) allowed by the peer device.

Upon receipt of a single POLL message, a device may send no data packets, send a single data packet, or send multiple data packets. The number of packets that a device can send after receiving a POLL message is communicated by the coordinator through the POLL message itself. If the device does not have any data to send, the device may send NULL_DATA back to the coordinator in response to a POLL message. According to the requirements of the device application, three polling mechanisms are used: scheduled polling access, delayed polling access and non-scheduling polling access.

The polling mechanism for scheduled polling access is as follows. This mechanism is particularly useful for highly energy constrained devices that also require a deterministic quality of service. Most medical applications in Body Area Networks (BANs) fall into this category. This mechanism helps devices sleep in a deterministic and scheduled manner to save energy and at the same time achieve higher throughput in high load environments.

Devices and coordinators will use a scheduled round-robin access as described below.

In scheduled polling access, transmission/reception is possible only in the polled allocation interval shown in FIG. 8, and uplink, downlink, and bidirectional link transmissions are possible. The end device wakes up and undergoes synchronization at the beginning of the polling allocation interval repeated every time period.

Each device is assigned a time interval "assignment interval" by the coordinator. The device and the coordinator can only communicate with each other during the allocated interval. An allocation interval may be further subdivided into slots and it may only have an integer number of slots. The poll allocation interval can be used as an uplink, downlink or bi-directional link. A device may have one or more scheduled poll allocation intervals spanning the same multiple allocated slots in each beacon period or multiple beacon periods. A device should wake up at the beginning of the allocation interval to send or receive frames to or from the scheduler. Scheduling Polling Access devices do not need to listen for beacon frames for synchronization. Synchronization information is provided to devices via poll frames.

Referring to Figure 8, the coordinator will send a polling message 80 to the device at the beginning of the device's allocation interval with the 'on time' field 70 set, indicating the number of frames allowed for transmission by the polled device. The device needs to wake up before its allotted interval in order to properly receive polling messages. Upon successful reception of the polling message, the device may send up to a specified number of data frames 82, 84 and 86 to the coordinator. FIG. 8 shows a situation in which the allowed number of frames is 3, and the device sends 3 data frames after receiving a poll message in which the number of data frames is 3. Outside of the allocation interval, there will be no transmission of frames from or to the device. When a frame transaction between the coordinator and a device completes within the allocated interval, the coordinator may choose to send a poll message with a window size 72 of FIG. 7 with a value of 0 to cause the device to enter sleep mode immediately.

After not receiving any frames from the polled device, the coordinator will resend the poll message with an offset value indicating the delay from the start of the device's allocation interval. Upon receiving a poll frame, the device can select any ACK strategy (no ACK, immediate ACK, later ACK, or block ACK) for data frame acknowledgment. Further data transmissions from the device can occur after a new poll or poll+ACK message is received in the same allocation interval or the next allocation interval of the device. The coordinator will start a frame transaction with the next scheduled device after completing the allocation interval for the current device.

During a device's scheduled poll access allocation interval, the device may indicate to the coordinator via the 'more bits' of the data/control/management frame if the device has more data to send. The coordinator may send a poll message immediately or subsequently in a superframe to allow allocation for additional frame transmissions using the time offset value in the poll message, where the time offset represents the allocation interval until the additional frame transmission is granted time.

When a poll message is received, the end-device first starts an uplink transmission by determining the number of possible transmission frames according to the 'window size' value. In the case where the allocation interval is not over when the transmission of a poll message is completed and the end device determines that the 'more data' bit is set in the data frame, the coordinator sends an ACK message for the data frame by sending the poll message along with the to inform the possible number of additional transmission frames using the 'window size' field.

If the end-device has no more uplink data to send, the end-device sends the last uplink data frame with the 'more data' bit not set. When receiving the data frame, if the coordinator has downlink traffic, the coordinator sends an ACK message and successfully sends the downlink data frame to the end device. If the 'window size' is not '0', the end-device waits after sending the ACK message, if the 'window size' is '0', the end-device transitions to the sleep state after sending the ACK message.

In the case of starting a scheduled poll assignment, in order to obtain one or more new scheduled poll assignments, the device will send a connection request frame to the coordinator by specifying the application's arrival rate, access latency and reliability factor.

To grant a scheduled poll assignment in response to a connection request from a device, the coordinator will respond to the device with a connection assignment frame with different values in the Interval Start field and the Interval End field so that the device's assignment interval does not vary. will overlap each other.

For connection requests from multiple devices, the coordinator may grant scheduled poll assignments to multiple devices through a group assignment frame in this frame with different values for the interval start and interval end fields assigned to each device.

The allocation using scheduled round-robin will be described below. When a connection assignment frame is successfully sent, the coordinator may start sending a poll to the device for the device to initiate one or more frame transactions, or the coordinator may start initiating a frame transaction with the device in the corresponding poll allocation interval given to the device. The device will not initiate a frame transaction until it receives a poll frame.

The receiver (device or coordinator) will be ready to receive frames sent by the sender in the allocated interval and return the appropriate frame. The device or coordinator will send the next frame pTIFS after the current frame ends. The pTIFS time between two frames is the time required for the device to process the frame plus some additional turnaround time. Devices and coordinators will ensure that frame transactions (including acknowledgment frames if required) are within their scheduled allocation intervals taking into account appropriate turnaround times.

In the case of modifying a scheduled poll assignment, a device may modify an existing scheduled poll assignment by sending another connection request frame specifying a new requirement. The coordinator will treat this request as a new request, except that it will set the change indication field in the connection assignment frame of its response with reference to the last connection assignment frame it sent to the device. In particular, if the coordinator rejects the modification but keeps the current assignment, it will respond with a Connection Assignment frame with the Change Indication field set to 0, and the other fields kept as they were in the last The corresponding value contained in the connection assignment frame.

A coordinator can itself modify a device's scheduled poll assignments by sending them unsolicited connection assignment frames specifying new assignments to those assignments, and setting the change indication in that frame with reference to the last connection assignment frame it sent to the same device field.

A coordinator can modify the scheduled poll assignments of multiple devices by itself by sending Proactive Group Connection Assignment frames specifying new assignments for these assignments to multiple devices, and referencing the last Group Connection Assignment frame it sent to the same group of devices. Set the change indication field in this frame.

In the case of an aborted scheduled poll allocation, a device or coordinator will consider an existing scheduled poll allocation to be aborted when no frames have been received for the last finite number of allocation intervals for that allocation. Subsequently, the coordinator may reclaim the aborted scheduling poll assignment.

Devices and coordinators can start a new SR assignment process as specified in the section (Starting SR assignments) to recover their lost SR assignments or obtain their replacements.

A device or coordinator considers their connection to be aborted after all scheduled poll assignments of the device to the coordinator have been aborted.

In the case of ending scheduled round-robin assignments, a device may end a scheduled round-robin assignment at any time by sending a modified connection request frame that includes an assignment request field with an assignment ID identifying those assignments field and the Minimum Allocation Length field and the Minimum Gap Length field are set to 0.

The coordinator may, but should not, at any time if possible, end any Scheduled Polling assignments for a device by sending a modified Connection Assignment frame to the device including an Assignment ID field identifying these assignments and the assigned Assignment fields for interval start and interval end fields set to 0.

A method of defining an attribute of a specific message by setting the field value to 0 is not necessarily limited to a specific scheme.

A device or coordinator can send a disconnect frame to end their connection, ie to release the device's address ID, wakeup schedule, and scheduled poll assignment with the coordinator.

The polling mechanism for delayed polling access is as follows. This mechanism is especially useful for less power-constrained devices that require very strict quality of service. Some non-medical applications like pose detection and gaming in BAN fall into this category. However, medical devices that are not very power constrained and require high quality of service in terms of latency and reliability can use this mechanism. This mechanism helps devices sleep in a less deterministic and scheduled manner, and thus consumes slightly more power than scheduled access, but it is able to quickly handle retransmissions of individual devices due to frame loss, it can Better latency performance than scheduled access.

Devices and coordinators will use delayed polling access as described below.

Figure 9 shows delayed polling access. This access method is suitable for end-devices whose QoS requirements are higher than those with high power requirements. In other words, the access method will benefit in terms of latency or reliability. In the case of scheduled polling access, if a transmission error occurs, there is no chance in that superframe and the end device will wait until the next superframe. However, in the case of delayed polling access, when the coordinator sends the next polling message due to a failure in the transmission of data frames, the coordinator notifies the end devices of the possibility of transmission by continuously sending polling messages regardless of the allocation interval initially set. In other words, the coordinator sends a poll message with the window size set to be greater than or equal to one.

Figure 9 shows where the i-th end-device successfully retransmits with the original allocation interval of the j-th end-device when its retransmission is performed immediately, and successfully sends a poll message to the j-th end-device which is already waiting thereby continuing the transmission situation of the process.

If the i-th end-device has been affected by the delay, the j-th end-device will wait in the receiving state even if no polling message is received in the awake state. The jth end device waits for a maximum period of time D from the start of its allocation interval. Since the coordinator also knows the time period, if time period D ends, it sends the poll of the device at the next end, without sending an additional poll. This time period D is determined in connection request/assignment frame processing.

In a superframe, the delayed poll access interval shall occur after the scheduled poll access interval. A device may have one or more delayed poll assignment intervals spanning the same assigned slot every beacon period or every few beacon periods. The device will wake up at the beginning of the allocation interval to send a data frame. Delayed polling access devices are not required to listen for beacon frames for synchronization, similar to scheduled devices.

Unlike in scheduled poll access, frame transmissions to and from a device can start outside of the device's allocation interval. For uplink data transmissions, the coordinator may send a poll frame to a device within a duration of D after the start of the allocation interval for that device, indicating the number of frames allowed for transmission by the polled device. The device will wake up at the beginning of the allotted interval to receive poll messages from the hub. When a poll frame is successfully received, the device can send up to the specified number of data frames to the hub.

The coordinator will not poll the device beyond the D duration after the start of the device's allocation interval. If no polling messages are received within the D interval from the start of the allocation interval, the device may enter sleep mode. The coordinator continuously schedules delayed access devices, and the delayed polling access interval in a superframe may vary from one beacon period to another.

The delayed access interval is followed by an EoP message and a contention for access period in a superframe, where the occurrence of an EoP message in a superframe depends on the actual delayed access interval occurring in that superframe. The length of the contention access period just after the delayed access interval in a superframe depends on the duration of the actual delayed poll access interval occurring in that superframe, and has the total length of the contention access period is the limit equal to or longer than minCAP.

In the case of initiating delayed poll assignments, in order to obtain one or more delayed poll assignments, a device will submit a request to the coordinating The device sends a connection request frame. To grant a delayed poll assignment, the coordinator will respond to the device with a connection assignment frame.

For connection requests from multiple devices, the coordinator can grant delayed poll assignments to multiple devices through a group assignment frame in this frame with different values assigned to each device's Interval Start and Interval End fields, so that each The allocation intervals of the devices do not overlap each other.

In the case of using delayed poll allocation, when a connection assignment frame is successfully sent, as shown in Figure 9, within the corresponding poll allocation interval granted to the device, the coordinator can start sending poll messages to the device for the device to start One or more frame transactions or the coordinator may initiate a frame transaction with the device. The device will not initiate a frame transaction until it receives a poll frame.

The receiver (device or hub) will be ready to receive frames sent by the sender and return appropriate frames during the allocation interval.

In the case of modifying a delayed poll assignment, a device may modify an existing delayed poll assignment by sending another connection request frame specifying a new requirement. The coordinator will treat this request as a new request, except that it will set the change indication field in the connection assignment frame of its response with reference to the last connection assignment frame it sent to the device. In particular, if the coordinator rejects the modification, but keeps the existing assignment, it will respond with a connection assignment frame with the change indication field set to 0, the other fields being kept as the last The corresponding value contained in the connection assignment frame.

A coordinator can modify a device's delayed poll assignments itself by sending the device an unsolicited connection assignment frame specifying new assignments to these assignments, and setting the change indication in that frame with reference to the last connection assignment frame it sent to the same device field.

A coordinator can modify the delayed polling assignments of multiple devices by itself by sending active group connection assignment frames specifying new assignments for these assignments to multiple devices, and set by reference to the last group connection assignment frame it sent to the same group of devices Change indication field in this frame.

In the case of an aborted Delayed Poll allocation, a device or coordinator shall consider an existing Delayed Poll allocation to be aborted when no frames have been received within the last mDelayedPollAllocationAborted allocation interval for that allocation. The coordinator can then reclaim the aborted delayed poll assignment.

Devices and coordinators can start a new delayed round-robin assignment process as specified in the section (Starting delayed round-robin assignments) to recover their lost assignments or obtain their replacements. The device or coordinator considers their connection to be aborted after all deferred poll assignments of the device to the coordinator have been aborted.

In the case of ending a delayed poll allocation, a device may end a delayed poll allocation at any time by sending a modified connection request frame including an allocation request field with an allocation ID identifying those allocations field and the Minimum Interval Length and Minimum Allocation Length fields are set to 0.

If possible, the coordinator MAY, but SHOULD NOT, at any time end any delayed poll assignments for a device by sending a modified connection assignment frame to the device that includes an assignment assignment field with a field identifying these Allocation ID field for allocation and Interval Start and Interval End fields set to 0.

A device or coordinator can send a disconnect frame to end their connection, ie void the device's address ID, wakeup schedule, and delayed polling assignment with the hub.

In the case of non-scheduled round-robin access, the device and the coordinator shall employ non-scheduled round-robin access as described below.

For unscheduled round-robin access, the coordinator does not assign an allocation interval in advance. The coordinator can request a transmission by specifying the number of data frames to allocate according to the 'window size' value, or can send all the frames it has in the end device's buffer using the largest value among the 'window size' values. It is assumed that end devices are always active in non-scheduled polling access.

The coordinator does not assign any pre-assigned intervals to non-scheduled polling access devices. The coordinator will send a poll frame to the device with a value of window size 72 in the poll frame, where the window size 72 allows the device to send single or multiple data frames up to this value of window size 72 . A specific value (eg 0xFF) among the window size values allows the device to send frames stored in the buffer or until the buffer is empty.

A device does not have to stay in the active state to receive polling messages intended for that device. The coordinator determines the order of devices to poll with unscheduled polling access. The coordinator will start a frame transaction with the next device in this sequential list after completing the transaction with the current device. A device will send a connection request frame to the coordinator for unscheduled polling access by specifying the arrival rate, access latency, and reliability factor. To grant a connection, the coordinator will respond to the device with a connection assignment frame.

When the connection assignment frame is successfully sent, the coordinator may start sending a poll to the device for the device to initiate one or more frame transactions, or the coordinator may start to initiate a frame transaction with the device. The device will not initiate a frame transaction until it receives a poll frame. During unscheduled polling access, the receiver (device or hub) will be ready to receive frames sent by the sender and return the appropriate frame. The device or coordinator will send the next frame pTIFS after the current frame ends. The coordinator will consider the connection aborted when no frames have been received during the last finite number of polling cycles. A device or coordinator can send a disconnect frame to end their connection.

The polling scheme will be described below. Various polling schemes or MAC scheduling will be described in detail below. The coordinator completes data transactions with each device one after the other in a round-robin fashion, as defined by the polling cycle. A session is defined between a coordinator and a device for the duration that the coordinator first sends a POLL message to a device and switches to the next device. In a session, the coordinator can send single or multiple POLL messages to collect data from a device and move on to the next device. Depending on the situation, the coordinator can move to the next device. The different situations include: when the device has no more data to send, or when the allocated interval is over, or when the device has sent its maximum allowed data frames specified by the polling scheme, or when the maximum polling retries are set when running out, or when an emergency occurs in another device.

In the case of a superframe structure, devices may tend to be polled in every ith (i>0) superframe, and the coordinator does not necessarily have to poll devices in every superframe.

The coordinator can collect required data packets from devices by sending a single POLL message or multiple POLL messages. The number of packets that a device can send upon receipt of a POLL message is conveyed in the POLL message itself. How many packets a device can send in a session is defined by the polling scheme adopted by the device. The following are the supported polling schemes. Figure 10 shows polling based data transfer with different schemes and shows the operation of single polling, limit polling and exhaustion polling in polling end devices by the coordinator.

In the case of the single data poll of FIG. 10, one poll is sent to the end-device during the polling period, and the end-device sends one data frame in response thereto. This data frame has values in it that help identify the grouping order of the frame such as pktSeqnumber. This value can be used to determine whether the frame packet is a retransmitted packet or a newly transmitted packet.

In this polling scheme, the coordinator needs to collect a single piece of data in a session with a device. To collect data from devices, the coordinator sends POLL messages to devices. A device may only send a single data frame upon receipt of this message. The pktSeqnumber74 in the POLL message of Figure 7 indicates that all previous data frames including frames with this sequence number have been successfully received at the coordinator. Depending on the pktSeqnumber74 specified in the POLL message, the data frame sent may be a retransmission of a previously sent packet or a new packet transmission. Error recovery mechanisms related to poll-based channel access are described in detail in a later section. This polling scheme is particularly suitable for devices with deterministic packet generation and with low latency requirements. Since only a single piece of data needs to be collected, this polling scheme is mainly suitable for the scheduled polling access method and the delayed polling access method with a fixed superframe structure.

In the case of the limited data polling of Figure 10, when a POLL message is received and a data frame is sent, only up to the possible number of data frames that the coordinator has determined may be sent.

In this polling scheme, the coordinator needs to collect multiple but limited data in sessions with devices. To collect data from devices, the coordinator sends POLL messages to devices. When it is less than the number of data frames granted by the coordinator, the device may send data frames up to the number of packets stored in the buffer upon receipt of this message. The pktSeqnumber74 in the POLL message of Figure 7 indicates that all previous data frames including frames with this sequence number have been successfully received at the coordinator. Depending on the pktSeqnumber74 specified in this message, the data frame sent may be a retransmission of a previously sent packet or a new packet transmission. Since a certain amount of data needs to be collected, this polling scheme is mainly suitable for the scheduled polling access method and the delayed polling access method with a fixed superframe structure.

In the case of data exhaustion polling of FIG. 10, all frames in the buffer of the end device may be sent. Single polling and limited polling are correctly operated when provided for certain services in fixed superframes with scheduled poll access or delayed scheduled access. Drain polling operates correctly when offered for variable services in variable superframe structures or without superframe structures. It can be correctly used even when fixed traffic and variable traffic coexist in a fixed superframe.

In this polling scheme, the coordinator can collect unlimited data in a session with a device. To collect data from devices, the coordinator sends POLL messages to devices. A device may send multiple data frames as specified in the 'window size' field of the POLL message. The pktSeqnumber74 in the POLL message of Figure 7 indicates that all previous data frames including frames with this sequence number have been successfully received at the coordinator. Depending on the pktSeqnumber74 specified in the message, the data frame sent may be a retransmission of a previously sent packet or a new packet transmission. This polling scheme is particularly suitable for traffic with indeterminate and bursty packet arrivals. Since the number of packets that a device can send in a session is not deterministic, this polling scheme is mainly suitable for non-polling access methods with a variable superframe structure or without a superframe structure. This polling scheme also applies to fixed superframe structures when devices with definite and indeterminate traffic characteristics are present together.

The random access mechanism shall operate in the contention access period (CAP) of the superframe structure defined by the coordinator. It is mainly used for the exchange of protocol messages related to network management between the device and the coordinator, and for non-QoS applications. Since carrier sense is unreliable on all channel modes and PHYs, a variant of the collision resolution solution can be employed instead of carrier sense.

In the case of channel time partitioning, a channel time unit is characterized by a symbol duration. The absolute value of the symbol duration depends on the PHY. All of the access mechanisms detailed above can be implemented with both slotted and unslotted systems. In a slotted system, time is divided into an equal number of slots (multiple symbol durations) and each frame transmission should start at the beginning of the slot edge. On the other hand, in an unslotted system, channel times are not marked and frame transmissions are allowed at any channel time.

Device clock synchronization will be described below with reference to FIG. 11 .

Power constrained devices, especially medical devices, try to sleep most of the time to save energy when there is no data transaction in progress with the coordinator. Such devices need to synchronize their sleep and wake schedules with the coordinator in order to receive POLL messages sent by the coordinator. Since devices can only send data when polled in poll-based access, no synchronization is required for data transmission. Also, devices that don't need to conserve energy have no synchronization requirements at all. The synchronization requirement applies only to fixed superframes. With variable superframes, the next polling time is not fixed, and the device has to be awake all the time. A device's polling rate can be a number of polling periods established by the coordinator.

In a fixed superframe, an end device listens to a POLL message according to a polling period determined by the coordinator, and performs data transmission/reception. An end device may sequentially receive multiple POLL messages in one allocated interval once it wakes up. The 'on time' bit is set in the first sent POLL message among multiple POLL messages. Only in this case, synchronization information such as timestamps contained in received POLL messages are used for synchronization correction, and when other POLL messages are received with 'on time' bits not set, they are not reflected. In case of downlink traffic, the coordinator may send a NULL_POLL message with the 'on time' bit set before the actual data. For example, 'set' means that the 'on time' bit has a value of 1, and 'not set' means that it has a value of 0.

The "on time" bit 70 in the POLL message of Figure 7 is used to inform the device of the start of the allocation interval. Additionally, POLL messages can contain a timestamp value if they were not sent in time. The device can calculate the next POLL time to synchronize with the coordinator to receive the next POLL message correctly. If the 'on time' bit is not set, the device will not use received POLL messages for synchronization. The device must wake up before its next scheduled poll time to receive the next poll message. The duration before the scheduled POLL time that the device needs to wake up (i.e. the guard time) depends on the time that the last POLL with the "on time" bit set for synchronization was received on the device relative to the coordinator Maximum clock skew following a message. The duration between two timely POLL messages 110 and 112 is called the synchronization duration. In case of downlink traffic, the coordinator may send a NULL_POLL message with the "on time" bit set before the actual data, for device synchronization. Figure 11 illustrates device synchronization in polling based access with a fixed superframe structure.

Error recovery will be described below with reference to FIG. 12 .

In order to provide reliable packet transmission, the standard supports two error recovery mechanisms: poll-based error recovery (coordinator-driven), which is only applicable to uplink traffic using poll-based channel access; and automatic repeat request ( sender-driven), applicable to both upstream and downstream traffic. ARQ is a common error correction method and is applicable to both uplink and downlink traffic. However, since ARQ-based error recovery is inefficient in terms of power and bandwidth due to the extra transmission of acknowledgments of packets, polling-based error recovery is provided for highly power-constrained devices. The polling based error recovery method proposed by the present invention is only applied to the uplink traffic sent from the end device to the coordinator.

In addition, as shown in Figure 12, the ARQ mechanism requires retransmission of data packets once a data packet or acknowledgment (ACK) is lost. Polling based access does not allow retransmission of packets without any response received from the coordinator, otherwise it may cause collision of retransmitted packets with polling messages. This situation is illustrated in Fig. 12, which is a flowchart showing the requirements for an error recovery procedure suitable for polling access. If device 2 attempts to retransmit in the allocation interval when no ACK for the uplink data frame is received, a collision with the next device's POLL message 3 may occur.

Figure 12 is a flowchart illustrating the operation of a data recovery mechanism for low data rate applications.

During polling, most low data rate applications include one packet to send, while high data rate applications may include multiple packets to send. In the traditional error recovery mechanism, if an ACK message is not received within a specified time, the device will resend the data. However, this is not possible in poll-based channel access mechanisms where data can only be sent after a POLL message is received by a device due to possible transmission collisions between POLL messages and data messages.

As shown in Figures 12 and 13, if all data packets are successfully received, the coordinator sends an ACK message.

If all data packets or POLL messages are lost, the coordinator resends POLL messages to avoid collisions between data and POLL messages.

If the ACK message is lost, the coordinator goes into sleep mode after the next device receives the POLL message or after a timeout.

Figure 13 is a flowchart illustrating the operation of an error recovery mechanism for high data rate applications. As shown in Figure 13, if some data is lost, some of the lost data can be received by resending the POLL message to the device.

The ACK message and the next POLL message may not coalesce, and each ACK message introduces a waste of power consumption if a lower number of packets and/or some smaller packets are sent.

Polling-based error recovery will be described below with reference to FIGS. 14 and 15 .

The poll-based error recovery mechanism is an integral part of the poll-based channel access mechanism and does not require a separate acknowledgment sent by the coordinator in response to receiving a packet from a device. This error recovery is coordinator driven and only applies to upstream traffic. The following sections detail polling-based error recovery in the case of single data transfers and block data transfers, respectively. Error recovery to handle different kinds of packet loss within a single data transfer is detailed below. Figures 14 and 15 illustrate poll-based error recovery for single data transfers and block data transfers.

In the present invention, for the uplink traffic accessed by polling, the error recovery procedure is defined as follows. This method can achieve higher power efficiency than the ARQ method because no additional transmission/reception of ACK messages is required. Polling-based error recovery procedures include single-polling error recovery, block polling error recovery, and bitmap polling error recovery. Single poll error recovery is shown in FIG. 14 .

First, SINGLE_POLL message transmission, reception, and retransmission will be described with reference to FIG. 14 .

The coordinator sends a SINGLE_POLL message 130 with 'pktSeqNum' number 74 in Figure 7 to the device, requesting the device to send a packet with the sequence number next to 'pktSeqNum' 74. When the SINGLE_POLL message 130 is received, the device sends a single data 132 with a sequence number next to the specified 'pktSeqNum' 74 specified in the SINGLE_POLL message 130 . The device sends the data frame corresponding to the next sequence number of 'pktSeqNum'. Data stored in the buffer up to 'pktSeqNum' is discarded for retransmission.

The device may discard all transmitted packets up to the sequence number specified in the SINGLE_POLL message 130 from its buffer. In case the coordinator does not detect any corruption of transmitted or received data from the polled device, then the coordinator will resend the SINGLE_POLL message 134 with the following exceptions.

In these exceptions, in case of scheduled access, the data transaction can be completed in the remaining allocation interval, otherwise, a SINGLE_POLL with the same 'pktSeqNum'74 will be sent in the next polling cycle. Retransmissions of SINGLE_POLL message 134 will not reach the maxPollreTransmission value. The polling period is not extended within a superframe, therefore, only minCAP remains.

In other words, when retransmitting a POLL message, in the case of scheduled polling access, if retransmissions are possible within the predetermined allocation interval, then in the remaining possible polling periods other than the expected retransmission time period When the minCAP is no longer shortened in the time period, the POLL message can be resent. Otherwise, a retransmission is attempted by sending the current pktSeqNum in the next polling period. Retransmissions are limited by a maximum retransmission value such as maxPollreTransmission.

BLOCK_POLL transmission, reception, and retransmission will be described below with reference to FIG. 15 . The block poll error recovery method is similar to the single poll error recovery method, except for the possible number of multiple data frames indicated by the 'window size' value in the POLL message, as shown in Figure 15.

The coordinator sends a BLOCK_POLL message 140 with a 'pktSeqNum' number 74 and a 'window size' 72 to the device, requesting the device to send a number of data packets starting with the next sequence number of the 'pktSeqNum' 74 specified by the window size.

Upon receipt of the BLOCK_POLL message 140, the device sends data with sequence numbers 142 and 144 as specified in the window size field 74 of the message with sequence numbers following the specified 'pktSeqNum' 74.

The device may discard all transmitted packets up to the sequence number specified in the BLOCK_POLL message 140 from its buffer.

When the coordinator does not detect any transmissions from the polled device after sending the BLOCK_POLL message 145, the coordinator will only resend the BLOCK_POLL message 146 with the same or reduced window size in the following cases:

- In case of scheduled access, data transactions of multiple packets can be completed in the remaining allocation interval. Otherwise, a BLOCK_POLL message 147 with the same 'pktSeqNum' number will be sent to the device in the next polling cycle;

- retransmissions of POLL messages will not reach the maxPollreTransmission value; and

- The polling period is not extended within a superframe, therefore, only minCAP remains.

BITMAP_POLL transmission and retransmission will now be described with reference to FIG. 15 . The block polling error recovery method is a method in which when a partial error occurs in a plurality of data frames when a BLOCK_POLL message is transmitted, information on the partial error is carried by the POLL message in the form of a bitmap.

The coordinator will send a BITMAP_POLL message 148 to the device only if the coordinator receives a part number of packets from the device in response to a BLOCK_POLL message and the last packet received from the device was not received with "more bits" reset. The BLOCK_POLL message specifies the 'pktSeqNum' number 74, the 'window size' 72 and the bitmap of the packet to be retransmitted.

In the event that the coordinator does not detect any transmissions from the device being polled, if:

- In case of scheduled access, data transactions of multiple packets can be completed in the remaining allocation interval. Otherwise, in the next polling cycle, a BITMAP_POLL message with the same 'pktSeqNum' number will be sent to the device;

- retransmissions of POLL messages will not reach the maxPollreTransmission value; and

- the polling period is not extended within a superframe, thus leaving only minCAP,

The coordinator will then resend the BITMAP_POLL message with the same or reduced window size.

Automatic Repeat Request (ARQ) based error recovery will also be described.

ARQ based error recovery is applicable to both uplink and downlink traffic. The stop-and-wait ARQ mechanism will be used for single data transfers with immediate acknowledgments, while selective repeat ARQ will be used for block data transfers with delayed acknowledgments specifying a bitmap of successful transmissions.

Method 2

The Media Access Control (MAC) layer is responsible for providing a channel access mechanism between devices that can communicate with each other using a shared communication medium without conflict. Different kinds of data services (audio, video, file transfer, etc.) require different types of QoS for their underlying channel access mechanisms. Wireless communication has ushered in a new era in telemedicine systems, where medical information of a patient captured by various medical sensors can be sent over a wireless medium. This avoids bulky wiring, increases the patient's range of movement and facilitates remote monitoring of the patient. In the case of wireless media, the task of providing reliable medical communication becomes more difficult because wireless communication systems are more error-prone than wired media.

Emergency management is one of the most critical requirements in any telemedicine system. Most previous research works consider urgent data traffic similar to traditional QoS applications. However, emergency messages are characterized by high volatility compared to periodic traditional QoS applications such as voice streaming and multimedia traffic. First, emergencies are very rare and may occur only once in a few months/years. Therefore, resources reserved for emergency traffic may result in a waste of network resources. Second, although emergencies rarely occur, this type of data is very intolerant of delay. It must be sent as soon as possible. Therefore, urgent data should not be delayed or rejected due to the dynamic availability of network resources. Third, the network (coordinator) may not be running when the emergency is sent.

The proposed mechanism considers a star topology network with multiple end devices (medical sensor nodes) and a single coordinator responsible for collecting sensory data from the devices. Figure 16 shows an exemplary diagram of a star topology and an emergency event occurring on a medical sensor node. The node can detect emergency events (e.g. abnormal heart rate, high blood sugar) at any time, regardless of whether the coordinator is running (busy collecting scheduled periodic medical data). This urgent data must be delivered to the coordinator in a timely and reliable manner.

The following problems are solved by the proposed method.

Emergencies can occur weekly, monthly or yearly, and in this case it can be assumed that there is no synchronization between the devices (sensor nodes) and the coordinator (data collectors).

The coordinator may be active when an emergency occurs on a device. Also, other coexisting networks may be operational and their data/control messages may interfere with emergency traffic.

Since multiple networks have to coexist with each other, channels cannot be fixed for emergency traffic. Fixed channels may be having interference when an emergency occurs.

Emergencies are very rare and may only occur once in a few months/years. Therefore, reserved resources may result in a significant waste of resources, and it may degrade the performance of normal medical services when there is no emergency.

Urgent traffic cannot be denied due to limited resources or when most resources are being used.

Urgent data needs to be delivered within the margin of latency required by urgent applications.

A method for processing emergency messages in an end device (especially an implanted end device in the BAN system in FIG. 16 ) will now be described. Urgent messages are all types of business that happen very rarely. Therefore, pre-allocating resources for emergency messages may result in a significant waste of resources. However, delays may be unavoidable if urgent messages are sent without using resources allocated in advance.

The following problems are solved by the proposed method.

The proposed invention does not reserve any resources (time slots or frequency channels) for emergency traffic. Emergency alarms can be received/detected even when the coordinator is not running or other coexisting networks are running. Reliable and fast delivery of urgent data is required even when most of the bandwidth is already used by the remaining nodes. Reliable detection of emergency events is required even in the presence of multiple networks.

According to the proposed method for handling emergencies, resources are secured in advance, but resources for other end devices that transmit usual data are used, which prevents resources from being wasted, and even when the coordinator handles normal end devices, there can be no Deal with emergencies with delay. Of course, emergency events can also be handled when the coordinator is only in the receiving state. If emergency services are also required in situations where the coordinator needs to migrate to sleep, a wake-up device should be installed separately.

Emergency events may occur in some end devices in the network of FIG. 16 . For example, the heartbeat adjustment device also expects to send irregular heartbeats to the external coordinator. The MAC protocol should support an emergency message processing mechanism that meets the requirements of emergency services. The emergency message handling mechanism should have existing access devices not only in the coordinator but also in end devices allowing fast and reliable delivery of emergency data and reducing power consumption.

Conventional solutions have proposed methods for handling the delivery of emergency messages. However, in this case it is assumed that the receiver is activated all the time to receive some possible emergency message and that the transmitter and receiver operate on the same channel.

This assumption may not be valid for networks with energy-constrained low-wheel-parking devices. In this case, after completing its data session, the device sleeps to save energy. Also, in some frequency bands (eg MICS), the network controller performs LBT to select a channel for network operation. The controller can select other channels for each network operation. Accordingly, embodiments of the present invention address the delivery of urgent data in the situations described above.

When an emergency occurs, there are two possible situations, including a situation where the piconet is running (ie, the coordinator is in an active state) and a situation where the piconet is not running (ie, the coordinator is in a sleep state). This will be described with reference to FIGS. 17 and 18 .

17 and 18 depict schematic diagrams of the sending and receiving of emergency messages from medical sensors (ie, end devices 160 ) to the coordinator 162 when the coordinator is running and not running, respectively. Upon receipt of the emergency alert message 164, the coordinator 162, in its runtime, sends an acknowledgment message 166 back to the end device 160. In this way, the end device 160 that has not been allocated resources enters the emergency processing process when it receives the ACK message after sending the emergency alert message to the coordinator 162 .

On the other hand, as in Figure 18, when the coordinator 162 is not operating, only the energy detector 170 continues to operate (discussed in detail later). When the coordinator 162 is in a sleep state, the energy detector acts as a wake-up device.

The energy detector 170 is in the idle state, and the processor 174 is in the shutdown state. Upon detection of energy due to the emergency alert message 164 , the energy detector 170 triggers the processor 174 of the receiver 172 and the coordinator 162 then sends an acknowledgment message 166 back to the end device 160 . The processor 174 is powered on after receiving the emergency alert message. The concept of only keeping the energy detector 170 on when the coordinator 162 is not running saves a lot of power consumption on the coordinator 162 .

The sensor side or end device operation will be described below with reference to FIG. 19 .

When an emergency occurs, the end device 160 may be awake or asleep regardless of the state of the coordinator 162 (running or non-running). The proposed invention covers the latter case. Emergency handling for the former case (device is awake) can be handled by the underlying channel access mechanism and is outside the scope of the present invention. FIG. 19 is a flow chart showing the sequence of operations performed by the end device when an emergency occurs. An end device operates in a POLL scheme of transmitting data in an allocated interval after receiving a POLL message from the coordinator. However, since the end device will proactively deliver emergency data when an emergency event is detected, it preferably operates as follows.

Below are the steps.

When an emergency event is detected in step 180, in step 181, the end device 160 establishes a channel for sending an emergency alert message. Specifically, end device 160 selects the highest priority frequency channel. The channel selection method may include a method of selecting any or a preferred one of channels that can be supported by the device and channels notified by the coordinator, and is not limited thereto. Prioritization of channels will be described later.

Thereafter, in step 182, the end device 160 sends a message to the coordinator 162 on the selected channel indicating that an emergency has occurred.

In step 183, the end device 160 waits for an acknowledgment (ACK) message from the coordinator 162 within a predetermined time after sending the alert message.

In case the ACK is received in step 184 , the end device 160 performs in step 187 an action according to the emergency. In other words, end device 160 performs urgent action (ie, action) according to the indication conveyed by coordinator 162 through the ACK message. Accordingly, end device 160 waits for the next message from coordinator 162, or immediately sends one or more emergency data associated with the emergency event.

If no ACK message is received within a predetermined time in step 184, end device 160 determines in step 185 whether its retry has reached the maximum number of retries (Max retries). If its retries do not reach Max retries, the end device 160 returns to step 182 and repeats sending the alert message until it receives an ACK message from the coordinator 162 on the selected channel.

In step 186, when its retries reach Max retries, if an acknowledgment message was not received from the coordinator 162 on the previous channel, the end device 160 selects another channel to send the alert message. Accordingly, the end device 160 selects a new channel from the channel set in order of priority, and repeatedly sends the alert message until receiving an acknowledgment message from the coordinator 162 . In other words, end device 160 finds out which channel coordinator 162 uses.

If all channels are used, the end device 160 performs all of the above operations a limited number of times until an ACK message from the coordinator 162 is received.

If there is no response from the coordinator 162, the end device 160 declares failure and stops the operation.

As described above, if the ACK message is not received, the end device 160 repeats the process of retransmitting the alarm message and re-waiting for the ACK message of the alarm message. If the retries exceed Max retries during this process, the end device 160 selects a channel from the remaining possible channels except this channel in the same way, and repeats the above-mentioned operation.

The coordinator side operation will be described below with reference to FIGS. 20-22.

When an emergency occurs, the coordinator 162 can be in a running state (busy with data transfers with other nodes) or a non-running state. When the coordinator 162 is running, a panic event is detected when the maximum retries time out due to forced collisions. This will be described in detail later. When the coordinator 162 is inactive, its energy detector 170 remains active, but not the entire receiver circuit. For further power optimization, wheel parking of the energy detector 170 is also allowed, ensuring that emergency messages can be detected with the required reliability. As mentioned above, the coordinator 162 cannot rotate on fixed channels because multiple networks have to co-exist on available channels and networks also have to co-exist with other technologies on the same frequency band. It is also possible that some channels may experience interference from other technologies during an emergency. In this case, urgent data cannot be sent reliably on these channels. Therefore, a separate channel for emergencies cannot be fixed. The coordinator 162 always tries to round-robin on the highest priority channel (channel prioritization is discussed later). This technique significantly reduces the effective time to detect emergency events. FIG. 20 shows a flowchart of the sequence of actions performed by the coordinator 162 when energy above a threshold is detected while the wheels are stopped.

FIG. 20 shows emergency operations performed when the coordinator 162 is in a sleep state according to an embodiment of the present invention.

At step 190, the coordinator 162 determines whether a signal or energy has been detected, or whether an internal timer has expired.

If energy is detected due to interference (major or minor) in steps 191 and 194, the coordinator 162 performs a channel scan and selects another high priority non-interference channel in steps 192 to 196. When energy of a certain level or higher is detected using the energy detector 170, the coordinator 162 finds a channel with the least interference through channel scanning to avoid primary or secondary interference.

If an emergency alert message is received in this state in step 197 , the coordinator 162 sends an acknowledgment message to the end device 160 in step 198 and processes the emergency event in step 199 .

If the internal timer expires, the coordinator 162 looks for a non-interference channel with higher priority than the current channel and starts round-robin on it. Otherwise, the coordinator 162 continues to utilize the current channel if available.

FIG. 21 shows emergency operations performed when the coordinator 162 is in a sleep state according to another embodiment of the present invention.

Referring to FIG. 21, when a signal is detected in step 191a, the coordinator 162 determines whether an emergency alert message is received in step 192a. If the detected signal is not an emergency alert message, the coordinator 162 determines whether an internal timer has expired in step 193a. If the internal timer does not expire, the coordinator 162 repeats the above operations. Otherwise, the coordinator 162 determines whether the detected energy is greater than or equal to a threshold in step 194a.

If the detected energy is greater than or equal to the threshold, the coordinator 162 performs channel scanning in steps 195a and 196a, such as performing LBT and then selecting another channel. If an emergency alert message is received in step 192a, the operations in steps 197a and 198a are the same as the operations in steps 197 and 198 of FIG. 20 .

The emergency processing procedure when the coordinator is in a non-running state will be described below with reference to FIG. 23 .

Devices notify the occurrence of emergency events by sending alert messages to the coordinator. A device sends an alert message in the channel and then waits for an ACK message from the coordinator. If no ACK message from the coordinator is received on the previous channel, the device selects a new channel from the set of channels and sends an alert message. The device repeatedly sends the alarm message until it receives an ACK message from the coordinator.

Referring to FIG. 23 , a complete set of operations performed by implanted devices (hereinafter, sensor nodes) and the coordinator together to quickly and reliably handle emergency events on sensor nodes when the coordinator is in a non-running state will be described. Fig. 23 shows that the coordinator is in a non-operational state when an emergency event occurs on the implanted device (hereinafter sensor node) 212 and on some non-interfering channel (not necessarily the highest priority channel due to interference) ) Sequence of operations for the exemplary case of a wheel stop. The sensor node 212 starts sending emergency alert messages on the highest priority channel pre-negotiated between the sensor node 212 and the coordinator. After sending each emergency alert message, the sensor node 212 waits for an ACK message. If the ACK message is not received within a limited duration, the sensor node 212 resends the emergency alert message.

The sensor node 212 in which an emergency occurs selects channels in order of quality according to a predetermined channel list between both ends, and continuously transmits emergency alert messages. The interval between consecutive emergency alert messages is determined so that sensor nodes 212 can receive ACK messages from the coordinator. If the coordinator wakes up at a certain time and receives an alarm message, the coordinator enters emergency management processing because it is performing a round-robin. During this process, sensor nodes 212 may first send data or wait for commands from the coordinator.

Once the sensor node 212 arrives on the channel exactly while the coordinator is in rotation, the coordinator 210 wakes up and receives the emergency alert message 214 if it has sent the emergency alert message, and replies with an ACK message 216 . The maximum number of emergency alert messages sent by sensor nodes 212 on each channel depends on the coordinator's outage percentage, reliability, and delay requirements for emergency events. Once the sensor node 212 receives the ACK message, the sensor node 212 either waits for the next command from the coordinator 210, or immediately sends the urgent data indicated by the ACK message, depending on the urgency both the sensor node 212 and the coordinator 210 know. Event profile. The further sequence for emergency handling after detection of an emergency warning message is application-dependent and outside the scope of the present invention.

As mentioned above, the coordinator is in a sleep state, and the coordinator rotates on a non-interfering channel in the sleep state. The coordinator performs round-robin in such a way that it receives at least one alarm message from the device. When an alarm message is detected, the coordinator transitions from the sleep state to the active state (emergency state), and sends an ACK message to process the urgent data.

Emergency processing while the coordinator is running using forced conflict will be described below with reference to FIGS. 24 and 25 .

A description will now be given for fast and reliable handling of emergency events on the sensor nodes, performed by the sensor nodes and the coordinator together when the coordinator is operating on a certain clear channel or small interference channel when an emergency event occurs on the sensor node. The complete collection of actions for the event. Figures 24 and 25 show the sequence of operations for an exemplary scenario where the coordinator is running and in idle or busy mode, respectively. This exemplary diagram describes emergency handling when the coordinator is in the running state and controls access to the wireless communication channel using a polling based mechanism. However, the same method of forcing collisions can be applied to any channel access mechanism.

The sequence of operations performed by the sensor nodes is the same as the previous condition when the coordinator was in the non-running state. This is because the sensor nodes don't have to first find out whether the coordinator is running or not. The sensor node starts sending emergency alert messages on the highest priority channel pre-negotiated between the sensor node and the coordinator. Two scenarios may occur in this case.

As shown in FIG. 24 , when the coordinator 210 is in the idle section 220 , the emergency alert message 222 may be correctly received by the coordinator 210 . Conversely, as shown in FIG. 25 , when the coordinator 210 is in the idle portion 230 , if the emergency alert message is received, the emergency alert message will collide with other data/management packets of the operational network such as the implanted device 213 . When the coordinator 210 is in the idle section 232 and receives an emergency alert message 234, it will send an acknowledgment message 236 to the sensor nodes 212 as described above. On the other hand, when the coordinator 210 is in the busy segment 237, the emergency alert message will collide with other management or data packets. Therefore, the coordinator 210 will not be able to successfully receive the emergency alert message 239 sent by the sensor node 212 .

As described above, when the coordinator is active, multiple alert messages from devices introduce forced collisions in the coordinator's data, which causes the coordinator to listen to the channel and receive alert messages from the devices. When an alarm message is received after a forced conflict, the receiver processes the emergency message generated by the slave.

Operations in the coordinator will be described with reference to FIG. 22 . In this case, the proposed invention uses a combination of mandatory collisions and a maximum retry timeout to detect possible emergency events at the sensor nodes.

First, if the coordinator 210 is in the idle section 220 as shown in FIG. 24 , it can correctly receive the emergency alert message in step 200 . Unlike this, as shown in FIG. 23, if the continuous transmission 239 of the emergency alert message from the sensor node 212 collides with multiple polling or data packets (forced collision), then in step 201 on the coordinator side 210 Trigger the max retry timeout event. When a conflict is detected, the coordinator 210 waits for a merged alert message, determining that a merged alert message is being delivered from the sensor nodes 212 .

When the maximum retry times out in step 201, the coordinator 210 suspends its normal operation in step 202 and waits for a possible emergency alert message from the sensor nodes. In other words, if data is not sent up to the maximum number of retries due to continuous data transmission errors, the coordinator 210 sets the maximum retries and waits for an emergency alert message.

If the coordinator 210 receives any emergency alert message within a certain time period in step 203 , it stores the MAC state so far in step 204 and sends back an acknowledgment message to the sensor node 212 in step 205 . Thereafter, the coordinator 210 handles the emergency in step 206 and restores the MAC status in step 207 . Otherwise, the coordinator 210 performs the required actions (such as finding out the cause and selecting a new channel) to handle the maximum retry timeout stipulated by the MAC protocol. The idea of forcing conflicts also works when the coordinator is not running but other coexisting networks are running. In this case the emergency alert message will collide with management or packet data of other networks and force them to suspend their operation by forcing the collision so that the emergency alert message can be correctly received by the coordinator of the desired network.

The prioritization of channels at the coordinator will be described below.

As described in Figure 20, sensor nodes send emergency alert messages in a predefined channel order. When not running, the coordinator always tries to round-robin on the highest priority non-interfering channel. When rounding on a channel, the coordinator periodically looks for a higher priority clear channel with the help of an internal timer. Most of the time, the coordinator will listen on a higher priority channel. Therefore, when an emergency event occurs, the emergency alarm message is detected with a minimum waiting time. The channel priority order is not fixed. The coordinator can randomly choose any channel priority order and communicate it to the sensor nodes. Randomization of the order of priority in different networks avoids collisions of simultaneous emergency alert messages in coexisting networks.

Method 3

The method involves implanted medical wireless communication between an implanted medical device such as a glucose sensor and an external programmer/data collector (coordinator) on the body. The proposed method enables the wake-up of implanted devices by an external programmer. The coordinator needs to wake up the implant to start a communication session with the implant. The proposed in-band wake-up mechanism is power efficient, reliable and fast, and is in accordance with the rules for MICS medical implant communications defined by the FCC. Implantable medical devices such as pacemakers typically have the capability to communicate data via a radio frequency telemetry link with a device known as an external programmer or data collector. One application of such an external programmer or data collector is to program the operating parameters of an implanted medical device and collect medical sensing data from the implantable device.

Implantable devices are resource constrained especially in terms of power. They can use energy harvesting technology as their energy source or use very thin thin-film batteries that have a limited power source and, once the device is implanted, the battery cannot be replaced during its lifetime. The life cycle of an implantable device can range from a few hours to several years. Due to energy constraints, implanted devices cannot be kept powered on all the time. This limitation requires that the device sleep be implanted most of the time when no communication is required between the device and the external programmer.

In this case, whenever the external programmer/data collector wants to set some parameters of the implanted device or collect some sensory data from the implanted device, it has to wake up the device first and then establish a communication session. In a star topology, there can be a single external programmer/data collector communicating with multiple implanted devices. Here, waking up is defined as being sure that the implanted device is listening to the same channel selected by the coordinator to start a communication session. According to the MICS rules, the coordinator must perform a Listen Before Talk (LBT) to start a communication session before acquiring a channel. For a sufficiently large distance between successive communication sessions, the coordinator may adopt any channel among all available channels, regardless of the channel used for previous communication. The probability of taking a particular channel is assumed to be equal.

Using inductive coupling (a non-RF method) between the implantable device and the antenna of an external programmer as a wake-up mechanism is very limited due to its short range coverage (eg, a few inches). The present invention attempts to solve this problem by proposing an in-band (same RF for wake-up and data communication) wake-up mechanism in a way that reduces power requirements of the implanted device, reduces wake-up latency and increases reliability of the wake-up process.

This method is used to solve the following problems.

To avoid idle listening and overhear, which draw a lot of power, implanted devices are required to sleep as much as possible to increase the lifetime of the device. In order to initiate a communication session with a sleeping implanted device, a power efficient, less complex and fast wake-up mechanism is required. Out-of-band wake-up solutions require additional transceiver circuitry, which increases system complexity and cost, and is not suitable for resource-constrained implanted devices. Therefore, an in-band wake-up mechanism is required.

Non-RF wake-up mechanisms are limited in distance (few inches)

In the case of multiple implants, waking up one after the other can introduce intolerable delays and high power consumption. Therefore, a multi-wake (wake up multiple devices at the same time) mechanism is required.

Per FCC guidelines, a separate channel for wakeup cannot be fixed for any operation by any entity.

While out of gear, the implanted device may receive interference from data transmissions from other devices during the communication session. This may result in additional unnecessary power consumption of the device.

Therefore, the present invention will show a method for performing wake-up in the MICS band. Communication for implantable medical devices utilizing the MICS frequency band has MICS constraints and implementation limitations. According to MICS constraints, the coordinator should always perform Listen Before Talk (LBT) to start a communication session before securing a channel. Utilizing the same RF in the same frequency band is simple in environments such as sensors because of lower technical and cost burden.

Figure 26 shows a general sequence of operations performed by the coordinator to accomplish data communication tasks with implanted devices. In order to start a communication session with an implanted device, the coordinator must first select No Interference by performing a Listen Before Talk (LBT) and ensuring that no other implanted networks or primary users (licensed users of the allocated spectrum) are present on the channel channel.

If no free channels are available, it attempts to coexist with other networks using suitable coexistence mechanisms (242). The first two steps (selection of signals and coexistence) are outside the scope of the present invention. After successfully selecting a channel (244), the coordinator needs to wake up the device with which it wants to start a communication session (246). Thereafter, the coordinator performs session communication (248), and then ends the session (250). The proposed mechanism considers a star topology network with multiple end nodes (implanted devices) and a single coordinator responsible for collecting sensory data from and/or setting parameters to the devices.

Figure 27 shows a schematic diagram of a star topology and medical implant sensor nodes with different states.

As shown in Figure 27, an implanted device can be in one of three states: active, sleeping, or hibernating (deep sleep).

In the case of the active state, the device has woken up and is involved in data communication with the coordinator. Sleeping and waking at a human-perceivable level within a data communication session is responsible for the channel access mechanism and is outside the scope of the present invention. In this disclosure, the active state means that the device is awake and does not require the coordinator to wake up the device.

In the case of a sleep state, the device is spinning down in a low power mode (with most receiver circuits powered off except the wakeup detector) to receive a wakeup signal.

In the case of hibernation, the transceiver implanted into the device is completely powered off and only an internal timer in the device is running to facilitate self-wake-up.

Figure 28 shows a transition diagram between all three states.

In case of hibernation mode, most of the time, the coordinator can determine a periodic schedule of communication sessions or a next expected time of communication sessions with the implanted device. For example, blood glucose values can be collected at a specified time every day. In this case, the coordinator may instruct the implanted device to enter a hibernation state (a state in which the entire transceiver circuitry is powered down) and begin polling just before the next desired/scheduled communication session. Hibernation mode is always preferred for implanted sensor devices. However, it should be optional for these types of applications that require frequent intervention of an external programmer/data collector (coordinator).

In the case of a wake-up mechanism, as already discussed, the channel used for wake-up may not be fixed. In order to correctly receive the wake-up signal while sleeping, the energy detector of the implanted device cycles through all available frequency channels one after the other in a periodic manner, as shown in Figure 29. An implanted device with an energy detector performs round-robin by alternately turning on and off the receiving state from channel f1 to channel fn according to a certain cycle.

The actual ratio of Rx_ON and Rx_OFF times at wheel stop depends on the latency, reliability and power consumption requirements of the system. An increase in the ratio of Rx_ON to Rx_OFF reduces wake-up latency and increases reliability and power consumption.

Referring to FIG. 30 , the coordinator transmits a continuous wakeup signal on a specific channel, and if an end device already in rotation receives the wakeup signal while changing channels, a data session starts. When sending a wake-up signal, the coordinator uses a known address to send a wake-up signal to connected end devices, and uses a device address to send a wake-up signal to unconnected end devices. Generally, the IEEE address is a representative device address.

In the case of a single-device wakeup mechanism, the coordinator will employ that mechanism to wake up the implanted device, as described below.

A unicast wakeup mechanism will be employed to wake up implanted devices whose addresses are known to the coordinator. It can be the MAC address of the device or a relatively small logical address assigned to the device by the coordinator.

When the wake-up process starts, the coordinator will send a wake-up message to the implant requesting an immediate acknowledgment, the address of the implanted node as the destination address, the session start time, and the approximate session duration, and then wait for an acknowledgment from the implant . A 'type' field of size 1 bit in a wakeup message may be used to distinguish single wakeup messages from multiple wakeup (lock) messages.

If the "type" bit is reset, the message is considered a single wakeup message. In principle, any available bits in the header could also be used as 'type' bits in order to save extra bit requirements. For example, since the 'more data' bit present in the header only applies to data frames, it can be used as the 'type' field of a wakeup message to distinguish a wakeup message from a multicast wakeup (lock) message.

To wake up an unconnected device with a known IEEE address, the coordinator will send a wakeup frame to the node with an ACK policy of immediate ACK, the IEEE address as the recipient address in the wakeup frame payload, The duration of the session in and the time to start the session, and then wait for an ACK frame from the node.

To wake up a connected device, the coordinator will send a wakeup frame to the node with the ACK policy set to ACK immediately, the connection ID as the receiver ID, and in the frame payload the time to start the session and the session duration , and then wait for an ACK frame from that node. The contents of the wakeup message payload are shown in FIG. 34 . As shown in FIG. 34, the wakeup message includes a destination address, an origination address, a session start time offset, and a session length.

If no acknowledgment is detected within a finite duration (the time it takes for the implanted device to process the wakeup message and acknowledge with an ACK), it will send another wakeup frame to the device. The coordinator will send wakeup frames with a maximum number of consecutive wakeup frames until it receives an ACK frame from the node. The maximum value will depend on the rotation of non-session state implants. The sending of multiple wake-up frames ensures that the device receives at least one wake-up frame while parking. The polling period for an implant in a non-session state depends on the implant's wake-up latency, reliability, and power consumption requirements.

When the implant is not in session, it will cycle through all available channels one after the other in a periodic fashion. The implant will send an acknowledgment to the coordinator when the wakeup message is successfully received. After sending the ACK message, the implanted device can go back to sleep and wake up at the time defined by the session start time in the wakeup message. This saves considerable power in implanted devices by trying not to wait for their polling messages. After completing the wake-up process, the coordinator can send a poll message granting the implanted device a poll allocation to start its own data frame transaction.

Upon receiving a wake-up frame on a channel while toggling in a non-session state, the inadvertent implant excludes that channel for toggling for the session duration specified in the wake-up frame. After the session expires, the device resumes rounds on the channel. In cases where the coordinator does not want unintentional devices to exclude the channel from round-robin, the coordinator may set the session duration value to '0'. This is especially useful when the coordinator is trying to wake up multiple devices one after the other by using the single-device wakeup mechanism. Although the waiting time of this process is longer than that of multi-device wakeup, the difference is not obvious when the number of devices is very small. Furthermore, when polling in a non-session state, after receiving interference in a channel, an inadvertent implant excludes that channel from polling for a fixed period of time. The device will resume rotation on that channel after the time expires.

An example is shown in FIG. 31 . While spinning on channel '2', the device receives a wakeup signal that was not intended for it and stops spinning on that channel '2'. In this way, when the coordinator starts a communication session with an implanted device, all other devices that are not part of the active session stop polling on this channel (on which the communication session is established) caused by crosstalk. Similarly, if a device receives interference caused by its own piconet's communications while it is in a non-session state (not part of a session), it stops polling on that channel for a fixed duration.

FIG. 31 shows a situation in which a device assists the operation of a data session between an actually designated device and a coordinator by not performing round-robin on a frequency band for a certain time when a wake-up signal not designated thereto is received.

Sometimes, data communication sessions with other implanted nodes may already be active when the coordinator is about to wake up the implanted device. As mentioned above, in order to avoid crosstalk due to interference, the device stops polling on the channel in which the active session is running. In this case, the coordinator cannot send a wakeup signal on the same channel to wake up the device. Also, if the coordinator uses the same channel for wake-up where the active session is running, this will cause cross-talk in the wake-up signal to the devices that are part of the active session. To avoid this problem, the coordinator selects a new interference-free qualified (according to FCC regulations) channel and performs a wake-up on the newly selected channel. In this way, devices that are already part of an active session do not receive the wake-up signal sent by the coordinator, thus avoiding crosstalk. FIG. 30 shows an example of a single-device wakeup mechanism with three devices in which the coordinator separately wakes up each device one by one.

In the case of a multicast device wakeup mechanism, the coordinator will employ this mechanism to wake up multiple implanted devices as described below.

The proposed wake-up method for multiple implanted devices will be described below with reference to FIG. 32 . To perform a round-robin when changing channels as in Figure 29, the end-device will receive a lock signal sent by the coordinator on a specific channel during the lock phase. Upon receipt of this lock signal, the session start time offset value contained in the lock signal in the wake-up frame format as shown in Figure 35 is interpreted as its wake-up start time, when the device is waiting on the current channel in the off state Turn on its receive mode and wait for the wakeup signal. The wakeup signal in the wakeup step is the same as the message in single wakeup.

The coordinator must have selected a MICS channel following the MICS rules, and will send a wakeup message on the selected channel to wake up connected devices. The connected devices are those that have been assigned unique and multicast addresses by the coordinator. Multicast wakeup has two phases: lock and wakeup or acknowledge.

When the lock phase starts, the coordinator will send a lock frame (multicast wakeup frame) to multiple connected nodes with an acknowledgment policy set to NO-ACK and a type bit set to 1, in the frame payload The session duration in and the time to start the session. The destination address of the lock frame may include a list of the addresses of the individual devices or the multicast ID of the group of nodes if assigned. The contents of multiple wakeup frame payloads are shown in FIG. 35 . A single wakeup frame payload is shown in FIG. 34 .

The coordinator will send a limited number of lock frames in succession without expecting an acknowledgment (ACK) from any connected device. The number of lock frames will ensure that each connected device will receive at least one wakeup frame.

The coordinator will send a lock frame with the multicast ID or broadcast ID as destination address to the wake-up devices belonging to a single group.

Upon successful reception of a lock frame, the intending connected device will lock itself to the channel where it received the lock frame, and wait for a wake-up frame on the same channel in the acknowledgment phase. An intentionally connected device will interpret the time of the start session field information as the time to start its validation phase and may only become active at that moment after locking.

During the 'acknowledgement' or 'wakeup' phase, the coordinator should send wakeup frames to each connected device one after the other in any desired order. Note: These wakeup frames sent during the acknowledgment phase are the same as those used in individual device wakeups. The coordinator will send a wakeup frame to the connected device with an acknowledgment policy set to ACK immediately, the type bit set to 1, and the connected node's address. Once the wake-up frame is successfully received, the device will send an ACK frame to the coordinator. When the slave device receives the ACK or the time for the slave device to receive the ACK expires, the coordinator will send a wake-up frame to the next device in this order. After a round of lock and wake phases is complete, the coordinator will send lock frames to devices that did not acknowledge during the acknowledge phase. Figure 31 shows the concept of lock and wake (or acknowledge) phases.

When polling in the non-session state, after receiving a wake-up frame on a channel, an inadvertently connected device excludes the channel for polling for the session duration specified in the wake-up frame. After the session expires, the device will resume rotation on that channel.

FIG. 33 shows an example of multi-device wake-up in which the coordinator wakes up three devices at the same time.

Method 4

The method involves polling-based ultra-low power channel access and simultaneous operation of multiple BANs in medical implant communications. Medical Implant Communication Service (MICS) is an ultra-low power, unlicensed mobile wireless service used to transmit data to support diagnostic or therapeutic functions associated with implanted medical devices. MICS allows individuals and medical practitioners to utilize ultra-low power medical implants such as cardiac pacemakers and defibrillators without causing interference to other users of the electromagnetic radio spectrum. In medical implant communications, a base station (external programmer or data collector) is located on or outside the body (within a limited range of 2-3 meters) and one or more medical implants form a single-hop star network.

The IEEE is already working on a standard (Body Area Network (BAN, IEEE 802.15.6)) to standardize all wireless medical and non-medical applications that operate on or around the body. The MICS frequency band (402-405 MHz) has been allocated by the FCC for medical implant communications with certain rules of use of frequency bands in order to avoid interference with primary users (measurement satellite users) of the same frequency band. These rules and regulations make the design of channel access mechanisms for implanted medical communications different from traditional MAC designs.

FIG. 36 is an exemplary diagram of a network with a single MAC layer and two physical layers according to an embodiment of the present invention.

Some communication networks may include multiple data rates under different traffic plans, eg, constant bit rate traffic, variable bit rate traffic, best effort traffic, and traffic per plan. Combinations of service plans and data rates can form unique types of services. Each type of business may have different QoS requirements. Preferably, a MAC protocol is designed to satisfy various settings of QoS requirements. A traditional solution may lie in the MAC being able to obtain different set QoS requirements for different types of traffic. However, it is assumed that all traffic is generated in a device or system with the same physical layer.

On the other hand, as shown in FIG. 36, the present invention relates to various types of traffic generated from devices (implanted devices or BAN devices) having different physical layers. Different physical layers mean that the transceivers operate on different frequency bands (for example, the frequency of UWB (3.1 to 10.6 GHz) for BANs and the medical frequency of 401 to 406 MHz for implants). The present invention proposes a MAC protocol capable of satisfying various settings of QoS requirements in a network having the situation shown in FIG. 36 .

Figure 37 is an exemplary representation of a single MAC frame structure with a polling period according to an embodiment of the invention.

In a device with a single MAC and two PHYs, the MAC shares time with PHY1 and PHY2. This design ensures that the separate PHY1 and PHY2 are not busy at the same time and that one of the transport structures (PHY1 and PHY2) is used by the MAC at a certain time. The busy periods of PHY1 and PHY2 are handled through a power efficient polling mechanism.

The following are the problems addressed/solved by the present invention.

A Media Access Control (MAC) protocol is required to enable the use of MICS for medical implant communications. Existing MAC protocols for wireless communication are not suitable for implantation in medical communication because of different QoS requirements and FCC regulations for MICS band usage.

The lifetime of implanted devices can range from a few hours to 2-3 years, and they are particularly resource-constrained in terms of power. Unlike traditional wireless networks, charging/replacing a depleted battery is difficult. Therefore, maximizing the lifetime of the implanted device becomes the primary objective, leaving other performance metrics such as band utilization as a secondary objective. The present invention proposes a contention-free based simple and ultra-low power medium access control protocol for implanted networks in star topology, which minimizes the overhead due to idle listening, crosstalk, packet collisions, and packet control Energy wasted.

Medical implant communications can be compared to wireless sensor networks, where one or more sensors (implanted devices) sense and send data to a base station node (external programmer or data collector). The nature of the communication pattern is usually convergent transmission (many-to-one): the data collection process from all or a collection of sensor nodes in the network to the base station. Most MAC protocols for wireless sensor networks are designed for multi-hop network technologies and are not optimized for single-hop star networks, which are the main concept of medical communication. The design of the proposed MAC protocol is customized according to the topological requirements of implanted medical communication, which makes it simple and power efficient.

The reliability of medical communication is higher than traditional wireless sensor network. Therefore, the reliability requirement is a key factor to be satisfied by any MAC protocol designed for medical communication. Using current FCC and ARQ mechanisms increases device complexity and power requirements. The proposed poll-based contention-free channel access mechanism provides a built-in reliability mechanism that supports the higher reliability requirements of medical implant conflicts.

Medical emergencies are one of the differentiating factors for embedded communications and other wireless networks. Emergency handling is critical and it should be handled very quickly with high reliability. The proposed MAC provides a fast and reliable channel access mechanism for handling medical emergencies.

Sometimes implanted medical applications can coexist with on-body applications. In other words, a single external programmer with dual interfaces may exist to communicate with both implanted and on-body devices. In this case, a transparent single MAC is required to support both implanted and on-body communication. Typically, implanted medical communications require stricter QoS than on-body communications. The MAC will give priority to implant communications over on-body communications.

The FCC imposes certain restrictions on the use of MICS channels for implant medical communications. The proposed MAC follows the rules established by the FCC for implant communications.

According to the upcoming IEEE standard for body area networks (IEEE802.15.6), the MAC protocol should efficiently support at least 10 co-existing implanted networks. Sometimes, when less than 10 channels are available, it may be necessary for two or more networks to coexist on the same channel and share bandwidth. The proposed coexistence mechanism for implant communication also provides a way to share channels between multiple coexisting implant networks.

Embedding data communication requirements is very simple. The coordinator has to collect medical sensory data from medical implants periodically or on demand. Once a communication session is active between the coordinator and the implanted device, typical sessions range in length from milliseconds to seconds. The coordinator may select multiple implanted devices as part of one data communication session if data from multiple devices needs to be collected simultaneously. Support for a star topology is required to facilitate data communication sessions with multiple implanted devices. Figure 27 shows an exemplary star topology for implant communication. Except in the event of an emergency, if the implant is not part of an active data session until awakened by the coordinator, it will sleep. Figure 26 shows a proposed sequence of operations performed by the coordinator for establishing a communication session with an implanted device to obtain sensory data.

The first step in starting a communication session is to perform Listen Before Talk (LBT) on all available channels and select a non-interfering channel for data operations. If no interference-free channel is available, the coordinator will try to coexist with other implanted networks (piconets) and share bandwidth with them. The coexistence mechanism of the shared channel will be discussed later. After successful channel selection, the coordinator needs to wake up the implant. Once the session is established, the core channel access mechanism takes over and handles collecting data from the different implants. After completing the data operation, the coordinator terminates the session and the device goes back to sleep.

As mentioned above, contention-based channel access mechanisms are not suitable for implant communications because they are not power efficient and do not follow FCC rules for accessing the MICS band. Also, a non-contention channel access mechanism based on the periodic transmission of beacons to maintain synchronization between the implanted device and the external device is not compliant with FCC regulations.

Some of the FCC rules for using the MICS band are:

Except in response to transmissions from the medical implant controller (ie, when the patient's health is at risk), the medical implant device does not transmit non-radio frequency excitation signals for medical implant events generated by external devices.

Channels authorized for MICS operation are only available on a shared basis and will not be assigned for the exclusive use of any entity.

The medical implant controller must monitor the channel or channels that a device of the MICS system is attempting to occupy for a minimum of 10 milliseconds per channel (LBT or LBT+AFA) within 5 seconds prior to initiating a communication session.

The channel access mechanism for implant communication is as follows.

The proposed channel access mechanism for implant communication is power-efficient, light-weight and follows MICS rules for implant communication. The external controller defines a static polling scheme for each implanted device based on their power and QoS requirements and traffic characteristics. The fixed polling scheme facilitates sleep of the implanted device between consecutive polling durations to further save power consumption. The coordinator sends a POLL message to the device at its scheduled time. After receiving the polling message, the implant sends data to the coordinator. The coordinator acknowledges the receipt of the data by sending an ACK message back to the device. A sequence of operations completes a single data transaction. After successfully completing a single transaction, the implant goes back to sleep and wakes up just before its scheduled polling time to receive the next polling message. The duration that a device has to wake up before its scheduled poll time depends on the device's polling period and clock drift.

When multiple devices are part of an active data communication session, the devices are polled in a round robin fashion. The frame cycle in which polling is performed is fixed and consists of two parts: a polling period and an idle period, as shown in FIG. 40 . The idle time period is used for error handling and coexistence with other embedded networks. Devices can be polled using one of the following two schemes.

Scenario 1: Single polling rate

In this case, all devices are polled with the same rate determined by the coordinator based on the maximum packet arrival rate among all devices. In this method, each device is polled during each frame period. This method is especially useful when most devices have the same packet arrival rate. Otherwise, low polling devices (small packet arrival rate) suffer from excessive polling even when they have no data to send. This causes more power consumption of low polling devices due to receiving extra polling messages.

Scenario 2: Differential Polling Rate

In this case, devices are polled according to their packet arrival rate. The polling rate for a particular device is always a power of two number of frame periods. For example, if the frame period length is Fc, the polling rate can only be 2Fc, 4Fc, 8Fc, . . . . Devices with higher polling rates are always polled before lower polling rates. This mechanism facilitates easy implementation and avoids gaps between two devices in the frame period, thereby maximizing the idle time period. A period of idle time will be recommended to aid the coexistence of other implanted networks in the same channel. Based on its packet arrival rate, the closest polling rate is chosen for the device.

Figure 37 is a channel access mechanism with differential polling rates. Devices with a polling rate of Fc are polled every frame period, devices with a polling rate of 2Fc are polled every two frame periods, and so on. This method is useful when there are devices with different packet arrival rates in an active data session to save power for low polling devices due to overhearing extra polling messages. FIG. 38 is an exemplary representation of a polling frame structure of implant communication in which the polling period of PHY1 is shown. Each polling cycle includes a busy time period and an idle time period. The device is polled during the polling cycle. Devices have different polling rates based on the rate at which data arrives at that device. For example, device 1 is polled at twice the rate of devices 2 and 3. Devices with a higher polling rate are polled earlier than devices with a lower polling rate to avoid idle time in the polling cycle. This helps to better manage the device's sleep or wake schedule, which helps reduce power consumption on the device.

FIG. 39 is an exemplary representation of a polling frame structure for on-body communication, showing a polling cycle for PHY2. The polling cycle includes a polling period, a contention period and an idle period. The device is polled during the polling cycle. Devices generating constant bit rate (CBR) data have a fixed polling time in a polling period, while devices generating variable bit rate (VBR) traffic may have a variable polling time in a polling period. A fixed polling time helps reduce power consumption on the device. Devices are assigned transmission durations based on arrival rates. When polled, a device can send data for an allotted duration. Such allocation helps to reduce power consumption and comply with the application's QoS requirements.

Some applications have high reliability requirements. Such applications can tolerate packet error rates as high as 10 ^-2 . The MAC protocol is required to provide an error recovery mechanism to achieve the desired reliability.

For power management, sleep and wake up over the entire superframe will be described below.

The scheduled poll channel access mechanism and the delayed poll channel access mechanism facilitate the sleep of devices between their consecutive polls. The length of time a device can sleep depends on its polling rate. There is no need for the device to have to wake up on every superframe if it is being polled after multiple superframes. Once the device wakes up during the polling period, it can go back to sleep earlier with different power saving options.

The flow of scheduling the sleep state of the device according to the 'sleep' bit in the received POLL message will be described below with reference to FIG. 46 .

When a POLL message is received in step 451 after waking up in step 450 , the device sends data in step 452 .

Power saving options provide flexibility for devices to save power. Different levels of power saving options help the device go back to sleep as early as possible after completing a data transaction with the coordinator. As shown in Figure 45, there are four different levels and each level defines how early a device can go back to sleep after a data transmission requested by the coordinator via a poll message.

In the case of level 1 in FIG. 45, if 'sleep' in the received POLL message is set in step 453, the device can directly go to sleep after sending the number of data packets requested by the coordinator in step 454.

In the case of level 2 in Figure 45, if 'sleep' is not set in the received POLL message in step 453, the device can wait for a NULL_POLL message from the coordinator to send the amount of data requested by the coordinator Back to sleep after grouping. If a NULL_POLL message is received in step 455, the device may go back to sleep.

In case of level 3 in FIG. 45 , in case of scheduled access, if no NULL_POLL message is received, the device waits until the allocation interval is completed. Thereafter, at step 456 the device determines whether the allocation interval is complete by performing a scheduled poll. In this way, the device can go back to sleep after completing the scheduled access interval.

In the case of level 4 in Figure 45, if the allocation interval is not complete in step 456, the device waits for a POLL message from the next device. In the case of delayed polling access, the device may go back to sleep in step 454 when the next device's POLL message is received in step 457 .

In a single MAC approach, at times, implanted medical applications can co-exist with on-body medical applications. In other words, a single external programmer may be able to communicate with implanted devices as well as on-body devices through a dual-PHY interface. In this case, a transparent single MAC is required to support both implanted and on-body communications. Most existing MACs support multiple PHYs, but not simultaneously. The unique requirements of medical communications running both on the implant and on the body impose the requirement of a single transparent MAC running on both PHYs. Unfortunately, due to the differences between in-body and on-body channel modes, it is not always possible to design a single PHY for both implant and on-body applications.

One way to achieve this is by running the two MAC routines independently on separate PHYs in a single processing unit. This concept is illustrated in FIG. 41 . This implementation requires a high-end processor to support multiple MAC instances running simultaneously, which increases system complexity and cost. Also, it is more likely that the MAC and PHY are formed together in a single hardware chip; in this case, it is very difficult to implement two MAC states in hardware. This software solution is slow and requires an additional task manager to switch between the two MAC states, which results in additional overhead for the associated switching.

The proposed single-MAC design that handles simultaneous operation of multiple PHYs uses time sharing between the two PHYs. As shown in Figure 42, there is only one routine that takes care of the two PHYs in a time-shared manner. The method is simple and does not require any high-end processor to run the MAC protocol. This method is only applicable to star topology networks where a single node (external controller) manages the allocation of resources to implanted and on-body devices.

In the proposed single-MAC design, implanted devices are given priority over on-body devices. The on-body device will utilize the idle period of the implant frame cycle, as shown in FIG. 43 . Although the bandwidth of this method is not very efficient, it allows simultaneous operation of implanted and on-body in a simple and power-efficient manner.

Figure 43 shows an exemplary single MAC frame structure.

A polling-based channel access mechanism is proposed for T0, T1, T2 and T3, and a contention-based channel access mechanism is proposed for T4. A single MAC architecture is proposed for T0, T1, T2, T3 and T4.

In one embodiment, the present disclosure relates to a single MAC structure for T0, T1, T2, T3 and T4. In one embodiment, the present disclosure relates to a power efficient polling mechanism for T0, T1, T2 and T3. In one embodiment, the present disclosure relates to a packet error recovery mechanism for T0, T1, T2 and T3. In one embodiment, the present disclosure relates to the handling of emergency messages in a network with T0 and T1 traffic. In one embodiment, the present disclosure relates to single-device wake-up and multi-device wake-up in a network with T0 and T1 traffic. In one embodiment, the present disclosure relates to the coexistence of multiple piconets generating TO type traffic. In one embodiment, the present disclosure relates to various settings of QoS requirements for executing T0, T1, T2, T3 and T4 type traffic through the proposed polling based channel access mechanism.

In single MAC operation of the coordinator, when both implanted and on-body devices are present, the coordinator establishes a single star topology network of all (implanted and on-body) devices. The polling cycle is defined to complete the data transaction operation with the device according to the QoS requirements of the implanted and on-body devices, the number of devices used for the implanted and on-body, and the PHY data rate of each interface.

Implanted devices are first polled to give priority to on-body applications. The polling period of the on-body device depends on the dynamic requirements of the implanted application. Implanted device retransmissions due to packet loss are processed first before moving to on-body device polling. After completing the implant polling period, the coordinator saves the context information of the implant device and reloads the context of the on-body device to continue the polling of the on-body device, and vice versa.

In the case of piconet coexistence, according to the IEEE technical requirements for body area network (BAN), at least 10 implanted piconets should be able to coexist in a limited space of 6*6*6 cubic meters. At times, it may be possible that all 10 channels of the MICS band (402-405MHz) are unavailable due to the presence of primary users or other noise sources. In this case, it becomes necessary for two or more implanted networks (piconets) to coexist on a single channel based on time sharing.

The proposed invention provides mechanisms to support the coexistence of multiple piconets on the same channel. The efficiency of the proposed mechanism depends on the topology changes and the load of each piconet. The following are the operations performed by the external controller to start a piconet and try to coexist with other networks. A flowchart of the proposed protocol is shown in Figure 44.

In step 430, the external controller selects a channel.

Thereafter, in step 431, the external controller performs a Listen Before Talk (LBT) for a time prescribed by FCC regulations. In step 432, the external controller determines whether the channel is free. If the channel is not free, the external controller determines in step 436 whether all channels have been used up. If not all channels have been used, ie if the channel is found to be busy, the external controller selects another channel in step 430 and repeats the operation. If the channel is free, at step 433 the external controller sends an inquiry message to confirm the existence of another piconet.

If no response is received to the inquiry message in step 434, the external controller activates the piconet in step 439 on the selected channel. If a response is received, then at step 435 the external controller selects a new channel by collecting piconet statistics.

If all channels are used up, no free channels can be used to try coexistence with other existing piconets. If at step 436 all channels are used up and there are no free channels available, the foreign controller attempts to coexist with other existing piconets. Accordingly, at step 437, the external controller determines whether it can share time with other piconets. If time sharing with other piconets is not possible, then at step 440 the external controller selects the channel with the lowest power level. Otherwise, if it is possible to share time with other piconets, then at step 438 the external controller exchanges messages with the piconets for channel sharing.

Figure 45 shows a sleep and wake scheme with different levels of power saving options. Figure 46 presents a flowchart for scheduling a sleep state in a device based on the 'sleep' bit in a received POLL message.

Embodiments of the present disclosure relate to the use of embedded systems for performing the techniques described herein. In one embodiment, the techniques are performed by a processor using information contained in memory. Such information can be read into main memory from another machine-readable medium, such as a storage device. The information contained in the memory causes the processor to perform the methods described herein.

The term "machine-readable medium" is used herein to refer to any medium that participates in providing data that causes a machine to operate in a specific manner. In one embodiment implemented using a computer system, for example, various machine-readable media are involved in providing information to a processor for execution. A machine-readable medium may be a storage medium. Storage media includes non-volatile media and volatile media. Non-volatile media include, for example, optical or magnetic disks, such as server storage units. Volatile media includes dynamic memory. All such media must be possible to implement such that the information carried by the media can be detected by the physical mechanism that reads the data into the machine.

Common forms of machine-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tape or any other magnetic media, CD-ROMs, any other optical media, punched cards, paper tape, any Other physical media, RAM, PROM and EPROM, Flash-EPROM, any other memory chips or cartridges.

In another embodiment, the machine-readable medium may be a transmission medium, including coaxial cables, copper wire, and fiber optics, including wires including buses. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications. Examples of machine-readable media may include, but are not limited to, carrier waves or any medium from which a computer can read, such as online software, download links, install links, and online links.

In the foregoing specification, the disclosure and its advantages have been described with reference to specific embodiments. However, it will be apparent to those of ordinary skill in the art that various modifications and changes can be made without departing from the scope of the present disclosure. Accordingly, the specification and drawings are to be regarded as illustrative examples of the present disclosure, rather than restrictive. All possible variations are intended to be included within the scope of this disclosure.

Claims (18)

1., for managing a method for emergency in terminal equipment, wherein between terminal equipment and body area network BAN telegon, setting up communication session, comprising:

Detect and whether there occurs emergency;

If there occurs emergency, then select the channel of the warning message of the generation for sending indicating emergency event;

Channel selected by utilization sends described warning message to BAN telegon;

Determine whether in the given time to receive the response message to described warning message; And

If the response message of receiving, then perform the operation relevant to described emergency.

2. the method for claim 1, also comprises:

If received polling message from BAN telegon before determining whether that emergency occurs, then operate in the mode based on poll, for sending data with assignment interval to described BAN telegon.

3. the method for claim 1, wherein perform the operation relevant to described emergency to comprise and send emergency data to described BAN telegon.

4. the method for claim 1, also comprises: if do not receive response message in the given time, then retransmit described warning message.

5. method as claimed in claim 4, also comprises:

Determine whether the sending times of described warning message has exceeded predetermined maximum number of retransmissions; And

If the sending times of described warning message has exceeded maximum number of retransmissions, then select another channel.

6. the method for claim 1, wherein selective channel comprises: according to priority the supported channel of described terminal equipment or described BAN telegon notice channel in select any one channel.

7. method as claimed in claim 2, wherein, described polling message comprise for the field synchronous with described BAN telegon and indicate the Frame allowed quantity field at least one.

8., for managing a method for emergency in body area network BAN telegon, wherein between BAN telegon and multiple equipment, forming Star topology, comprising:

Sending to an equipment makes this equipment send the polling message of data to described BAN telegon;

Described polling message is retransmitted when not receiving the data for described polling message;

Determine whether the sending times of described polling message has exceeded predetermined maximum number of retransmissions;

If the sending times of described polling message exceedes maximum number of retransmissions, then move to the warning message of sleep state for the generation of reception indicating emergency event;

When receiving warning message, send acknowledge message to the equipment sending described warning message; And

Perform the operation relevant with described emergency.

9. method as claimed in claim 8, also comprises: if the sending times of described polling message exceedes maximum number of retransmissions, then store current media interviews and control (MAC) state.

10. method as claimed in claim 9, also comprises: when not receiving warning message in the given time, recovers the mac state stored.

11. methods as claimed in claim 8, wherein, described polling message comprise for send data device synchronization field and indicate the Frame being permitted for the equipment sending data quantity field at least one.

12. 1 kinds, for managing the method for emergency in body area network BAN telegon, comprising:

Determine whether in sleep mode the energy being more than or equal to predetermined threshold to be detected;

When the energy being more than or equal to predetermined threshold being detected, by scan channel selective channel;

When the warning message of generation of indicating emergency event being detected, send acknowledge message to the equipment sending described warning message, and

Process described emergency.

13. 1 kinds, for managing the body area network BAN telegon of emergency, comprising:

Energy detector, for determining whether to detect the energy being more than or equal to predetermined threshold, and when the energy being more than or equal to predetermined threshold being detected, triggering and being in dormant processor;

Described processor, if triggered by described energy detector, then moves to open state, and when receiving the warning message of generation of indicating emergency event, sending acknowledge message, and process described emergency to the equipment sending described warning message.

14. telegons as claimed in claim 13, also comprise: transmitter, for sending acknowledge message to the equipment sending described warning message.

15. 1 kinds, for managing the body area network BAN telegon of emergency, comprising:

Transmitter, makes described equipment send the polling message of data to described BAN telegon for sending to equipment;

Controller, for retransmitting described polling message when not receiving the data for described polling message, determine whether the sending times of described polling message has exceeded predetermined maximum number of retransmissions, and if the sending times of described polling message exceedes maximum number of retransmissions, then move to the warning message of sleep state for the generation of reception indicating emergency event; With

Receiver, for receiving described warning message;

Wherein, when receiving warning message, send acknowledge message by described transmitter to the equipment sending described warning message; And perform the operation relevant with described emergency.

16. telegons as claimed in claim 15, also comprise: memory cell, if exceed maximum number of retransmissions for the sending times of described polling message, then store current media interviews and control (MAC) state.

17. telegons as claimed in claim 16, wherein, described controller recovers stored mac state when not receiving warning message in the given time.

18. telegons as claimed in claim 15, wherein, described polling message comprise for send data device synchronization field and indicate the Frame being permitted for the equipment sending data quantity field at least one.