Abstract:
Embodiments of the invention provide coexistence among independent networks through active superframe interleaving. Network hubs and devices exchange signals over a selected channel only during active superframes of their network. Network hubs broadcast coexistence information during their active superframes. A hub of network B desiring to use the selected channel first attempts to fit its active superframes within network A&#39;s inactive superframes, if available. If network A is not providing inactive superframes, then the network B hub determines whether network A is willing to coexist using active superframe interleaving on the channel. If so, the network B hub sends an interleave request message to the network A hub, which may accept the message and send back an interleave response message. The network A hub then offers new inactive superframes, and the network B hub adapts the transmissions and receptions of network B to fit within these inactive superframes.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims the benefit of the filing date of U.S. Provisional Patent Application No. 61/382,082 which is titled “BAN Coexistence through Active Superframe Interleaving” and was filed Sep. 13, 2010, the disclosure of which is hereby incorporated by reference herein in its entirety. 
     
    
     TECHNICAL FIELD 
       [0002]    Embodiments of the invention are directed, in general, to networks having a hub in communication with multiple nodes and, more specifically, to the coexistence of multiple such networks on a same channel. 
       BACKGROUND 
       [0003]    Two or more devices may communicate with each other using predefined channels. There is an advantage in predefining the channels for a particular type of devices, because the devices then have a known set of channels on which to hunt for other similar devices. Additionally, using a known set of channels, the devices are all capable of moving to another channel within the set if required to avoid interference or noise. The known set of channels may be defined by a standards or regulatory body so that other unrelated devices are not allowed to use the channels. 
         [0004]    In some systems, one device may act as hub that establishes network connections with other related devices, which act as nodes in a network. The devices in the network may communicate using the predefined channels. The network may be established, for example, to serve a particular group of users or to support a particular service provider. Other devices that are associated with other users or other service providers may form additional independent networks. In other situations, a hub device may be capable of serving a limited number of nodes and, therefore, other networks may be formed due to network size limitations. These other networks use the same set of predefined channels. 
         [0005]    When two or more networks are operating in the same general physical location, they typically need to select different operating channels for each network to avoid interference. In such a situation, for example, the hub in a newly formed network may monitor the channel set to identify an available channel for use in the new network. However, if the set of predefined channels is small or if a greater number of networks are operating at the same time in the one location than the number of predefined channels, then no channels may be available for the new network&#39;s sole use. 
       SUMMARY 
       [0006]    Embodiments of the invention provide active superframe interleaving between two networks, such as body area networks (BAN), that share the same operating channel with no or minimal mutual interference. 
         [0007]    A first BAN (BAN  1 ) may at any time share the same operating channel with a second BAN (BAN  2 ) by interleaving their active superframes. Depending upon the operating conditions, the networks—BAN  1  and BAN  2 —may interleave their active superframes either without requiring active superframe adjustment or with requiring active superframe adjustment. 
         [0008]    Regardless of whether BAN  1  is operating with a superframe length and inactive duration that are suitable for interleaving BAN  1  and BAN  2 &#39;s active superframes, BAN  2 &#39;s hub (Hub  2 ) may send to BAN  1 &#39;s hub (Hub  1 ) a Command—Active Superframe Interleaving Request frame to request active superframe interleaving between the two BANs. However, before sending the Command—Active Superframe Interleaving Request frame, Hub  2  first must receive a beacon or B2 frame of Hub  1  with a Superframe Interleaving field in the MAC header set to indicate support for active superframe interleaving. 
         [0009]    If BAN  1  supports active superframe interleaving, which is indicated in the MAC header of its beacon or B2 frame, Hub  1  sends a Command—Active Superframe Interleaving Response frame to Hub  2  to indicate whether Hub  1  accepts or rejects the active superframe interleaving request. If Hub  1  accepts the request, in some cases, it may continue with its current superframe length and inactive duration to enable the offered active superframe interleaving. In other cases, Hub  1  adjusts its superframe length and inactive duration to enable the offered active superframe interleaving before sending its response. 
         [0010]    Hub  1  should accept the request if it may continue with its current superframe length and inactive duration to enable the requested superframe interleaving. Hub  1  may deny the request if its inactive duration has been mostly taken by other hubs also for active superframe interleaving. Hub  1  should also accept the request from Hub  2 , if Hub  1  has a lower BAN priority than Hub  2 . 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0011]    Having thus described the invention in general terms, reference will now be made to the accompanying drawings, wherein: 
           [0012]      FIG. 1  illustrates an example of a superframe according to one embodiment; 
           [0013]      FIG. 2  illustrates the superframes used by two networks (BAN  1  and BAN  2 ); 
           [0014]      FIG. 3  illustrates superframes used by two networks (BAN  1  and BAN  2 ) in another embodiment; 
           [0015]      FIG. 4  illustrates a frame payload of a beacon frame according to one embodiment; 
           [0016]      FIG. 5  illustrates a general MAC frame according to one embodiment; 
           [0017]      FIG. 6  illustrates a MAC header format according to one embodiment; 
           [0018]      FIG. 7  illustrates the format of a Frame Control field according to one embodiment; 
           [0019]      FIG. 8  illustrates the format of a Coexistence field of a beacon or B2 frame according to one embodiment; 
           [0020]      FIG. 9  illustrates an example of a Connection Assignment frame payload according to one embodiment; 
           [0021]      FIG. 10  illustrates a Superframe Parameters information element according to one embodiment; 
           [0022]      FIG. 11  illustrates the format of a Superframe Parameters Bitmap according to one embodiment; 
           [0023]      FIG. 12  illustrates a frame payload of a Command frame according to one embodiment; 
           [0024]      FIG. 13  illustrates the format of a Command Data field of a Command—Active Superframe Interleaving Request frame; 
           [0025]      FIG. 14  illustrates the format of a Command Data field of a Command—Active Superframe Interleaving Response frame; 
           [0026]      FIG. 15  is a block diagram illustrating a network topology employing embodiments of the invention; and 
           [0027]      FIG. 16  is a block diagram of an exemplary embodiment of a device implementing embodiments of the invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0028]    The invention now will be described more fully hereinafter with reference to the accompanying drawings. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. One skilled in the art may be able to use the various embodiments of the invention. 
         [0029]    In one embodiment, a network may comprise a hub device that is in communication with a plurality of node devices. Two or more of these networks may be located within the same area. Generally, the individual networks operate independently of one another, and each hub is responsible for controlling the communications with the nodes in its network. However, when two or more networks are operating near one another, one or more of the hub devices may determine that the transmissions within the individual networks should be coordinated across the networks. This may be helpful to reduce interference between the network when they are operating on the same channel or on close frequencies. 
         [0030]    Within a network, a hub may organize communications within its network by defining repetitive periods or intervals for medium access by itself and nodes it its network. These periods may be, for example, beacon periods or superframes that define repetitive time intervals referenced by the hub and nodes in the network for medium access. The superframe repeats in intervals of equal duration. The hub may transmit zero, one or more beacon signals during the superframe. The term superframe is used herein to simplify the discussion, but will be understood to be synonymous to beacon period or the like. 
       Superframe Format 
       [0031]      FIG. 1  illustrates an example of superframe  100  according to one embodiment. Superframe  100  is operating in a beacon mode as a beacon period. In an active superframe, the hub transmits a beacon  101  and provides access phases  102 - 108 . Beacon (B)  100  is a frame transmitted by the hub to facilitate network management, such as medium access coordination, node power management, and clock synchronization within the network, and to facilitate coexistence of networks. Access phases  102 - 108  are used by the hub and its associated nodes to exchange management, control, and data type frames. 
         [0032]    In one embodiment, superframe  100  may be used in a Body Area Network (BAN) using the procedures described in the document identified as IEEE P802.15.6™/D04 and titled “Draft Standard for Information Technology—Telecommunications and Information Exchange Between Systems—Local and Metropolitan Area Networks—Specific Requirements—Part 15.6: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Wireless Personal Area Networks (WPANs) used in or around a body,” which was published in June 2011 by the Institute of Electrical and Electronics Engineers, Inc., the disclosure of which is hereby incorporated herein by reference in its entirety. 
         [0033]    In the illustrated embodiment, superframe  100  includes first exclusive access phase (EAP 1 )  102 , first random access phase (RAP 1 )  103 , managed access phase (MAP)  104 , second exclusive access phase (EAP 2 )  105 , second random access phase (RAP 2 )  106 , additional managed access phase (MAP)  107 , and contention access phase (CAP)  108 . EAP 1  or EAP 2  is an interval set aside by the hub for transfer of traffic for the highest user priority. This may include, for example, emergency or medical event reporting. RAP 1  or RAP 2  is an interval set aside by the hub for random access to the medium by network nodes. The managed access phase (MAP) is an interval set aside by the hub for improvised access, scheduled access, and unscheduled access to the medium by the hub and the nodes. The contention access phase (CAP) is an interval left over by the hub in the superframe for random access to the medium by network nodes. 
         [0034]    The hub may set the length of any of these access phases to zero. In one embodiment, RAP 1  and CAP may have guaranteed minimum lengths to support the network nodes, as announced, for example, in a connection assignment frame. 
         [0035]    In an active superframe  100 , network nodes may obtain contended allocations during EAP 1   102 , EAP 2   105 , RAP 1   103 , RAP 2   106 , and CAP  108 , to initiate frame transactions. The hub may arrange scheduled uplink, downlink and bilink allocation intervals, provide unscheduled bilink allocation intervals, and improvise certain immediate polled and posted allocation intervals only in a MAP ( 104 ,  107 ). In EAP 1 , EAP 2 , RAP 1 , RAP 2 , CAP, or MAP, the hub may also improvise future polls or posts starting and ending in a MAP. 
         [0036]    In addition to the active superframes  100  discussed above, the hub may also maintain a number (I) of inactive superframes after each active superframe  100 . There can be no allocation intervals scheduled in the inactive superframes. The number I of inactive superframes may be any positive integer chosen and announced by the hub. In the inactive superframes, the hub does not transmit any beacon or any other frames, and does not provide any access phases for the nodes in its network to transmit in. 
       Superframe Interleaving 
       [0037]    When two networks, such as two BANs, operate on the same frequency in close proximity, they may cause interference with each other. Accordingly, the networks may need to adjust their transmissions to avoid transmission overlaps that cause such mutual interference.  FIG. 2  illustrates the superframes used by two networks (BAN  1  and BAN  2 ). Transmissions by these networks in their respective superframes do not cause interference because only one BAN superframe is active at a time. Rather than using a continuously repeating superframe, BAN  1  and BAN  2  transmit in their respective active superframes  201 ,  202  and then each pass three inactive superframes before transmitting in their next active superframes  203 ,  204 . Because active superframes  201  and  202  are fully offset from each other, they do not occur at the same time. Accordingly, the active superframes  203 ,  202  for each BAN network occur during an inactive superframe  205 ,  206  for the other network. 
         [0038]    The arrangement of active and interactive superframes illustrated in  FIG. 2  may be configured by having the hub in BAN  2  listen to the transmissions of BAN  1 . BAN  2 &#39;s hub could then select an active superframe for use in BAN  2  that is offset from the active superframe used in BAN  1 . The hub in BAN  2  may select its active superframe without communicating with BAN  1 , if the inactive superframe interval  205  used in BAN  1  is long enough for the BAN  2  active superframe  202  to fit. In other embodiments, the hub in BAN  2  may be required to communicate with the hub in BAN  1  to coordinate on the location and length of their active superframes. 
         [0039]      FIG. 3  illustrates superframes used by two networks (BAN  1  and BAN  2 ) in another embodiment. BAN  1  may use continuously repeating active superframes having a duration that is relatively short ( 301 ) or relatively long ( 302 ). Because the active superframe for BAN  1  is continuously repeating, other network BAN  2  cannot use the same channel without causing interference between the networks. This is particularly true if BAN  2  is also using a continuously repeating active superframe arrangement ( 303 ). In the situation illustrated in  FIG. 3 , the hubs in BAN  1  and BAN  2  will have to communicate with each other to create room for BAN  2  to operate on the same channel as BAN  1 . 
         [0040]    In one embodiment, the hubs coordinate their respective active superframes  304 ,  305  so that each network schedules an active superframe during an inactive superframe  306 ,  307  of the other network. The hubs may select appropriate values for active superframe length, inactive superframe duration, and offset to ensure that the networks can share the same channel without interference. 
       Beacon Frame 
       [0041]      FIG. 4  illustrates a frame payload  400  for a Beacon frame according to one embodiment. A frame payload, such as Frame payload  400  may be broadcast by a hub in every superframe in beacon frame  100  ( FIG. 1 ), for example. A Beacon frame is a management-type frame that contains both mandatory fixed-length fields and optional variable-length components that are referred to as information elements (IE). 
         [0042]    Sender Address field  401  is set to the MAC address of the hub that is sending the current beacon. Beacon Period Length field  402  is set to the length of the current superframe as measured in units of allocation slots, wherein the superframe may be divided into a plurality of such allocation slots. The allocation slots are numbered 0, 1, . . . , starting from the one that starts the superframe. Allocation Slot Length field  403  is set to the value L such that the length of an allocation slot is equal to a minimum allocation slot length (pAllocationSlotMin) plus L×an allocation slot resolution (pAllocationSlotResolution). 
         [0043]    RAP 1  Start field  409  is present only if exclusive access phase  1  (EAP 1 )  102  is of nonzero length, as indicated by EAP Indicator field  701  ( FIG. 7 ) of MAC header  501  of the current beacon frame  400 . When present, it is set to the number of the allocation slot whose start time ends EAP 1  and starts RAP 1 , and it occurs after PHY Capability field  408 . 
         [0044]    RAP 1  End field  404  is set to the number of the allocation slot whose end time ends RAP 1   103 . 
         [0045]    RAP 2  Start field  405  is set to the number of the allocation slot whose end time ends EAP 1   102  and starts RAP 2   106 , if RAP 2  is of nonzero length, or is set to zero otherwise. 
         [0046]    RAP 2  End field  406  is set to the number of the allocation slot whose end time ends RAP 2   106 . 
         [0047]    MAC Capability field  407  and PHY Capability field  408  indicate support for various functions and functional requirements. 
         [0048]    Beacon Shifting Sequence  410  is optional and is present only if beacon shifting is currently enabled. Channel Hopping State field  411  is present only if channel hopping is currently enabled. Next Channel Hop field  412  is present only if channel hopping is currently enabled. 
         [0049]    Inactive Duration field  413  is optional and is present only if one or more inactive superframes will start at the end of the current superframe. When present, it is set to the number of inactive superframes after each active superframe. The presence of the Inactive Duration field  413  may be determined by the Non-final Fragment/Cancel/Scale/Inactive field  703  ( FIG. 7 ) within the Frame Control field  601  of the MAC Header  501  as discussed below. 
       MAC Header Data 
       [0050]    The capability of a network to support superframe interleaving may be determined from the MAC header of beacon or B2 frames transmitted by the network hub.  FIG. 5  illustrates a general MAC frame  500  according to one embodiment. MAC frame  500  consists of a fixed-length MAC header  501 , a variable-length MAC frame body  502 , and a fixed-length frame check sequence (FCS)  504 . The MAC frame body  502  is present only if it has a nonzero length. When present, it contains a frame payload. 
         [0051]    In one embodiment, MAC header  501  may be formatted as shown in  FIG. 6 . Frame Control field  601  carries access control information about the MAC frame, such as the protocol version, security level, and frame type and subtype. Recipient ID field  602  is set to the abbreviated address of the recipient of the current frame, which may be a node identifier or a hub identifier, for example. Sender ID field  603  is set to the abbreviated address of the sender of the current frame. BAN ID field  604  is set to the abbreviated address of the network in which the current frame is transferred, such as the address of a body area network (BAN). 
         [0052]      FIG. 7  illustrates the format of a Frame Control field  601  according to one embodiment. The information carried in Frame Control  601  may vary depending upon the frame type and frame subtype. For example, the information carried in Fragment Number/Next/Coexistence field  702  may vary depending upon whether the frame is a beacon, data, Poll, or other frame. In beacon and B2 frames, field  702  is used as a Coexistence field. 
         [0053]    Non-final Fragment/Cancel/Scale/Inactive field  703  also may vary depending upon whether the frame is a beacon, data, Poll, or other frame type. In beacon and B2 frames, field  703  is used as an Inactive field, which is set to indicate whether one or more inactive superframes will start at the end of the current superframe. When the bit in Inactive field  703  is set, the Inactive Duration field  413  ( FIG. 4 ) of the Beacon frame payload is present and will indicate how many inactive superframes follow each active superframe. 
         [0054]      FIG. 8  illustrates the format of Coexistence field  701  of beacon or B2 frames according to one embodiment. Beacon Shifting field  801  indicates whether beacon shifting is currently enabled. Channel Hopping field  802  indicates whether channel hopping is currently enabled. Superframe Interleaving field  803  indicates whether the sending hub supports active superframe interleaving which includes support of command frames. 
         [0055]    A hub in one network (e.g., BAN  2 ) may determine whether another network (e.g., BAN  1 ) supports active superframe interleaving by analyzing the MAC header of beacon or B2 frames that are broadcast by the hub in BAN  1  and determining whether the Superframe Interleaving field  803  has been set. 
         [0056]    The hub in BAN  2  may further determine how many inactive superframes follow the current superframe for BAN  1  by parsing the Inactive Duration field  413  of beacon or B2 frames broadcast by BAN  1 &#39;s hub. 
       Connection Assignment Frame Data 
       [0057]    A Connection Assignment frame may be transmitted by a hub in response to a connection request from a node or may be used to initiate or change a connection assignment.  FIG. 9  illustrates an example of a Connection Assignment frame payload  900  according to one embodiment. Connection Assignment frame payload  900  may carry both mandatory and optional fields. Superframe Parameters information element (IE)  901  is an optional field in Connection Assignment frame payload  900 . 
         [0058]      FIG. 10  illustrates a Superframe Parameters information element  901  according to one embodiment. Superframe Parameters IE  901  also has mandatory and optional fields. Superframe Parameters IE  901  itself is an optional field and, when contained in a Connection Assignment frame, is used to convey the values of chosen superframe operation parameters. 
         [0059]    Element ID field  1001  is set to a value that identifies the IE and Length field  1002  is set to the length, in octets, of the fields that follow in the Superframe Parameters IE  901 . 
         [0060]    Superframe Parameters Bitmap field  1003  indicates which optional superframe parameters are present in information element  901 .  FIG. 11  illustrates the format of a Superframe Parameters Bitmap  1003  according to one embodiment. In one embodiment, Active/Inactive Superframe Indicator field  1101  within Superframe Parameters Bitmap  1003  is set if inactive superframes are periodically provided and both Inactive Duration  1004  and Next Active Superframe  1005  fields are present in this IE, or is set to zero if both fields are absent. 
         [0061]    Inactive Duration field  1004  may be set in the same manner as used to set Inactive Duration field  413  in beacon frame payload  400  ( FIG. 4 ). Inactive Duration field  1004  may be present only if one or more inactive superframes are starting at the end of the current superframe. When present, Inactive Duration field  1004  is set to the number of inactive superframes after each active superframe. 
         [0062]    Next Active Superframe field  1005  is an optional field that, when present, may be set to the sequence number of the next active superframe. 
         [0063]    Accordingly, in addition to using beacon frames to determine the number I of inactive superframes supported by a first network, the Active/Inactive Superframe Indicator field  1101  may be used by other network hubs to determine whether the first network is providing inactive superframes. 
       Interleaving Process 
       [0064]    The encoding described above may be used by one network to determine if other networks support inactive superframes and, if so, how many inactive superframes are present and when they occur. 
         [0065]    Referring again to  FIG. 2 , a first network (BAN  1 ) is broadcasting beacon or B2 frames in active superframe  201 . The hub in a second network (BAN  2 ) may monitor the beacon frames or B2 frames broadcast by the hub in BAN  1 . In the beacon and B2 frames, an Inactive field ( 702 — FIG. 7 ) of MAC header  501  is used to indicate whether one or more inactive superframes will start at the end of the current superframe. When the Inactive field is set, then an Inactive Duration field ( 413 — FIG. 4 ) in the beacon frame payload can be read to determine how many inactive superframes follow each active superframe. 
         [0066]    With this information, the hub in BAN  2  can learn the timing of the inactive superframes  205  of BAN  1  and can adjust the active superframe  202  timing for BAN  2  to occur during the BAN  1  inactive superframes. As a result, the hub of BAN  2  may control the interleaving of active superframes on its own without the need for communicating with BAN  1 . 
         [0067]    Referring again to  FIG. 3 , the first network (BAN  1 ) is continuously broadcasting beacon or B2 frames in active superframes. Unlike the configuration of  FIG. 2 , in this case the hub of the second network (BAN  2 ) must communicate with the hub of the first network to coordinate interleaving of active superframes. 
         [0068]    The first step for BAN  2 &#39;s hub in this situation is to analyze the Coexistence field  701  of the MAC header of beacon or B2 frames broadcast by BAN  1 &#39;s hub to determine whether BAN  1  will support superframe interleaving. If Superframe Interleaving field  802  of Coexistence field  702  has been set to zero in BAN  1 , then BAN  1  will not support interleaving. As a result, BAN  2 &#39;s hub will need to identify a different channel for operation to avoid interference. On the other hand, if Superframe Interleaving field  802  of Coexistence field  702  has been set to one in BAN  1 , then BAN  1  will support interleaving. BAN  2 &#39;s hub may then attempt to communicate with BAN  1 &#39;s hub to coordinate interleaved active superframes. 
       Active Superframe Interleaving Request/Response 
       [0069]    In one embodiment, BAN  2 &#39;s hub and BAN  1 &#39;s hub exchange Command—Active Superframe Interleaving Request/Response frames to coordinate their active superframe interleaving. 
         [0070]      FIG. 12  illustrates a frame payload  1200  of a Command frame according to one embodiment. Recipient Address field  1201  is set to the MAC address of the recipient of the Command frame, and Sending Address field  1202  is set to the MAC address of the sender of the Command frame. Command ID field  1203  is set to identify the specific command of the Command frame. For example, the value of the Command ID field  1203  is set to indicate that the command is an Active Superframe Interleaving Request or an Active Superframe Interleaving Response frame. Command Data field  1204  contains information specific to the command that is conveyed in the Command frame. 
         [0071]      FIG. 13  illustrates the format of a Command Data field ( 1204 ) for a Command—Active Superframe Interleaving Request frame  1300 . The Active Superframe Interleaving Request frame  1300  is transmitted by a hub to another hub to request for channel sharing through active superframe interleaving. 
         [0072]    HID field  1301  is set to an address of the hub that is sending the current Command frame. BAN ID field  1302  may be set to an address of the network of the sending hub. BAN Priority field  1303  is set to indicate the priority of the services provided to the network of the sender of the Command frame. Table 1 lists BAN Priority field encoding according to one embodiment. Generally, the higher the value of this field, the higher the priority of the BAN services. 
         [0000]    
       
         
               
               
               
             
           
               
                   
                 TABLE 1 
               
               
                   
                   
               
               
                   
                 FIELD VALUE IN 
                   
               
               
                   
                 DECIMAL 
                 BAN SERVICES 
               
               
                   
                   
               
             
             
               
                   
                 0 
                 Non-medical services 
               
               
                   
                 1 
                 Mixed medical and non-medical services 
               
               
                   
                 2 
                 General health services 
               
               
                   
                 3 
                 Highest priority medical services 
               
               
                   
                   
               
             
          
         
       
     
         [0073]    Field  1304  may be reserved for additional data. Requested Beacon Period Length field  1305  is set to the length of the superframe, in units of allocation slots, as requested by the sender of the current frame. In one embodiment, field  1305  is set to zero to encode a value of 256 allocation slots. Requested Allocation Slot Length field  1306  is set to the value L such that the length of an allocation slot is equal to a minimum allocation slot length (pAllocationSlotMin) plus L×an allocation slot resolution (pAllocationSlotResolution). 
         [0074]    Requested Active Superframe Offset field  1307  is set to the length, in units of requested superframes or beacon periods defined in the current frame, as requested by the sender of the current frame, between the end of an active superframe of the recipient of the current frame and the start of the next active superframe of the sender of the current frame. 
         [0075]    Requested Inactive Duration field  1308  is set to the number of inactive superframes of the sender of the current frame after each active superframe of the sender, as requested by the sender. 
         [0076]      FIG. 14  illustrates the format of a Command Data field ( 1204 ) for a Command—Active Superframe Interleaving Response frame  1400 . The Active Superframe Interleaving Response frame  1400  is transmitted by a hub to another hub in response to a request for channel sharing through active superframe interleaving. 
         [0077]    The Command—Active Superframe Interleaving Response frame  1400  includes HID, BAN ID, BAN Priority and Reserved fields that function as described above for the same fields ( 1301 - 1304 ) in the Command—Active Superframe Interleaving Request frame  1300 . 
         [0078]    Command—Active Superframe Interleaving Response frame  1400  further includes a Request Status field  1401  that is set to one if the request for active superframe interleaving is accepted or is set to zero if the request is denied. 
         [0079]    Offered Beacon Period Length field  1402  is set to the length of the beacon period or superframe, in units of allocation slots, as offered by the sender of the current frame. In one embodiment, field  1402  is set to zero to encode a value of 256 allocation slots. Offered Allocation Slot Length field  1403  is set to value L such that the length of an allocation slot is equal to a minimum allocation slot length (pAllocationSlotMin) plus L×an allocation slot resolution (pAllocationSlotResolution). 
         [0080]    Offered Active Superframe Offset field  1404  is set to the length, in units of offered beacon periods or superframes defined in the current frame, as offered by the sender of the current frame, between the end of an active superframe of the sender of the current frame and the start of the next active superframe of the recipient of the current frame. 
         [0081]    Offered Inactive Duration field  1405  is set to the number of inactive superframes of the recipient of the current frame after each active superframe of the recipient, as offered by the sender of the current frame. 
         [0082]    Current Allocation Slot Number field  1405  is set to a value S such that the sender of the current frame starts sending this frame during the offered allocation slot numbered S. Current Allocation Slot Offset field  1407  is set to F in units of ┌Offered Allocation Slot Length in microseconds/65536┐ microseconds such that the sender of the current frame starts sending this frame at F after the start of the offered allocation slot indicated in the preceding field. Here, the function ┌x┐ is defined to be the least integer not smaller than x. 
         [0083]    To send a Command—Active Superframe Interleaving Request or a Command—Active Superframe Interleaving Response frame, the sender may send the frame as if it were an unconnected node of the recipient&#39;s BAN, for both medium access and MAC header setting. The transmission and setting of immediate acknowledgment (I-Ack) frames for acknowledging receipt of the interleaving request or response frames may be the same as for acknowledging receipt of any other frame. 
         [0084]    Regardless of whether BAN  1  is operating with a superframe length and inactive duration that are suitable for interleaving BAN  1  and BAN  2 &#39;s active superframes, BAN  2 &#39;s hub (Hub  2 ) may send to BAN  1 &#39;s hub (Hub  1 ) a Command—Active Superframe Interleaving Request frame to request active superframe interleaving between the two BANs. However, before sending the Command—Active Superframe Interleaving Request frame, Hub  2  first must receive a beacon or B2 frame of Hub  1  with a Superframe Interleaving field in the MAC header set to indicate support for active superframe interleaving. 
         [0085]    If BAN  1  supports active superframe interleaving, which is indicated in the MAC header of its beacon or B2 frame, Hub  1  sends a Command—Active Superframe Interleaving Response frame to Hub  2  to indicate whether Hub  1  accepts or rejects the active superframe interleaving request. If Hub  1  accepts the request, in some cases, it may continue with its current superframe length and inactive duration to enable the offered active superframe interleaving. In other cases, Hub  1  adjusts its superframe length and inactive duration to enable the offered active superframe interleaving before sending its response. 
         [0086]    Hub  1  should accept the request if it may continue with its current superframe length and inactive duration to enable the requested superframe interleaving. Hub  1  may deny the request if its inactive duration has been mostly taken by other hubs also for active superframe interleaving. Hub  1  should also accept the request from Hub  2 , if Hub  1  has a lower priority than Hub  2 . 
         [0087]    If Hub  1  rejects the request, then it may continue with its current superframe length and inactive duration, even if it offers alternative superframe and inactive duration values in its response for active superframe interleaving between the two BANs. 
         [0088]    If Hub  1  accepts Hub  2 &#39;s request, Hub  2  should set up or/and adjust its superframe boundary and inactive duration to attain active superframe interleaving as it has requested once hub  1  makes its own adjustment if required as illustrated in  FIG. 3 . 
         [0089]    If Hub  1  rejects Hub  2 &#39;s request, Hub  2  may send another request for active superframe interleaving based on the alternative offer in Hub  1 &#39;s response, or may start or continue BAN  2  operation in the same channel without regard to active superframe interleaving. 
         [0090]    Hub  2  may send to Hub  1  another Command—Active Superframe Interleaving Request frame even if it has previously sent such a frame containing the same or different requested field values. If the new request is accepted, it shall supersede the previous request. If the new request is rejected, the last accepted request, if any, shall remain valid. 
         [0091]    If Hub  2  previously sent to Hub  1  a request for active superframe interleaving and the request was accepted by Hub  1 , Hub  2  should send to Hub  1  another request when Hub  2  needs fewer or no active superframes. 
         [0092]    Hub  1  may send to Hub  2  a Command—Active Superframe Interleaving Request frame for active superframe interleaving any time as well, following the procedure specified in the above with hub  1  and hub  2  swapping their roles. 
         [0093]      FIG. 15  is a block diagram illustrating a network topology employing embodiments of the invention. Nodes  1501 ,  1502  and hubs  1503 ,  1504  are organized into logical sets, referred to as networks. In the illustrated embodiment, there is only one hub in a network, but the number of nodes in a network may vary. For example, network  1   1505  comprises hub  1503  and plurality of nodes  1501 , and network  2   1506  comprises hub  1504  and plurality of nodes  1502 . In one embodiment, data is exchanged within the same network only. In another embodiment of the invention, commands are exchanged between hubs of different networks for coordination of active superframe interleaving. 
         [0094]      FIG. 16  is a block diagram of an exemplary embodiment of a device  1600  implementing embodiments of the invention. Device  1600  may be used as a node  1501 ,  1502  and/or a hub  1503 ,  1504  in  FIG. 15 . In one embodiment, device  1600  is a hub, gateway, or controller controlling and communicating with one or more nodes or with other hubs. In another embodiment, device  1600  is a low-power wireless node operating on, in, or around a human or non-human body and communicating with a hub or another node to service one or more applications, such as medical connections, consumer electronics, and personal entertainment. 
         [0095]    Processor  1601  processes data exchanged with other nodes or hubs via transceiver  1602  and antenna  1603  and/or via wired interface  1604  coupled to Internet or another network  1605 . Processor  1601  may be a software, firmware, or hardware based device or a combination thereof. Processor  1601  may also generate and process messages sent to, and received from, another device, such as the Commands for active superframe interleaving request or response. 
         [0096]    Memory  1606  may be used to store MAC header and frame payload of beacon, B2, and other frames. Memory  1606  may also be used to store computer program instructions, software and firmware used by processor  1601 . It will be understood that memory  1606  may be any applicable storage device, such as a fixed or removable RAM, ROM, flash memory, or disc drive that is separate from or integral to processor  1601 . 
         [0097]    Device  1600  may be coupled to other devices, such as user interface  1607 , sensors  1608 , or other devices or equipment  1609 . Device  1600  may be adapted to operate in a body area network either as a node or as a hub controlling a plurality of nodes and coordinating with other hubs for coexistence. Sensors  1608  may be used, for example, to monitor vital patient data, such as body temperature, heart rate, and respiration. Equipment  1609  may be, for example, a monitor or other device that receives and analyzes signals, such as a patient&#39;s temperature, heart rate, and respiration, from another node. Alternatively, equipment  1609  may be a device for providing a service to a patient, such as controlling an intravenous drip, respirator, or pacemaker. 
         [0098]    It will be understood that the networks  1505 ,  1506  in  FIG. 15  and the device  1600  in  FIG. 16  are presented for illustrative purposes only and are not intended to limit the scope of the systems or devices that are capable of employing the active superframe interleaving procedure described herein. 
         [0099]    The interleaving of active superframes as described herein may be used in a Body Area Network (BAN) or in any other network or system, such as in the system described in U.S. patent application Ser. No. 12/697,110, filed Jan. 29, 2010, and titled “Frame Structure for Medium Access in Body Area Networks (BAN),” the disclosures of which are hereby incorporated in their entirety herein. 
         [0100]    Many modifications and other embodiments of the invention will come to mind to one skilled in the art to which this invention pertains having the benefit of the teachings presented in the foregoing descriptions, and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.