WO2001097447A2 - Gestion d'identite aleatoire dans des scatternets - Google Patents

Gestion d'identite aleatoire dans des scatternets Download PDF

Info

Publication number
WO2001097447A2
WO2001097447A2 PCT/SE2001/001301 SE0101301W WO0197447A2 WO 2001097447 A2 WO2001097447 A2 WO 2001097447A2 SE 0101301 W SE0101301 W SE 0101301W WO 0197447 A2 WO0197447 A2 WO 0197447A2
Authority
WO
WIPO (PCT)
Prior art keywords
node
network
scatternet
identification
message
Prior art date
Application number
PCT/SE2001/001301
Other languages
English (en)
Other versions
WO2001097447A3 (fr
Inventor
Johan Rune
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to AU2001264504A priority Critical patent/AU2001264504A1/en
Publication of WO2001097447A2 publication Critical patent/WO2001097447A2/fr
Publication of WO2001097447A3 publication Critical patent/WO2001097447A3/fr

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W92/00Interfaces specially adapted for wireless communication networks
    • H04W92/02Inter-networking arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/005Discovery of network devices, e.g. terminals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • H04W84/18Self-organising networks, e.g. ad-hoc networks or sensor networks

Definitions

  • the present invention relates to ad-hoc networks. More particularly, the present invention relates to forming ad-hoc networks.
  • ad-hoc networks are dynamic.
  • An ad-hoc network is formed when a number of nodes decide to join together to form a network. Since nodes in ad- hoc networks operate as both hosts and routers, ad-hoc networks do not require the infrastructure required by fixed networks. Accordingly, ad-hoc networking protocols are based upon the assumption that nodes may not always be located at the same physical location.
  • Bluetooth is an exemplary ad-hoc networking technology.
  • Bluetooth is an open specification for wireless communication of both voice and data. It is based on a short-range, universal radio link, and it provides a mechamsm to form small ad-hoc groupings of connected devices, without a fixed network infrastructure, including such devices as printers, PDAs, desktop computers, FAX machines, keyboards, joysticks, telephones or virtually any digital device.
  • Bluetooth operates in the unlicenced 2.4 GHz Industrial-Scientific-Medical (ISM) band.
  • ISM Industrial-Scientific-Medical
  • FIG. 1 illustrates a Bluetooth piconet.
  • a piconet is a collection of digital devices, such as any of those mentioned above, connected using Bluetooth technology in an ad-hoc fashion.
  • a piconet is initially formed with two connected devices, herein referred to as Bluetooth devices.
  • a piconet can include up to eight Bluetooth devices.
  • each piconet for example piconet 100, there exists one master Bluetooth unit and one or more slave Bluetooth units.
  • Bluetooth unit 101 is a master unit and unit 102 is a Bluetooth slave unit.
  • FIG. 2 illustrates a piconet with a master unit 201 and a plurality of slave units 202-208 arranged in a star network topology. If slave unit 202 wishes to communicate with slave unit 206, slave unit 202 would have to transmit the information it wished to communicate to master unit 201. Master unit 201 would then transmit the information to slave unit 206.
  • FIG. 3 illustrates an exemplary scatternet 300.
  • piconet 1 includes a master node 303 and the slave nodes 301, 302 and 304
  • piconet 2 includes a master node 305 and the slave nodes 304, 306, 307 and 308
  • piconet 3 includes a master node 309 and the slave nodes 308, 310 and 311.
  • nodes which are members of more than one piconet. Such nodes are herein referred to as forwarding nodes.
  • nodes 304 and 308 might act as forwarding nodes by forwarding information between the two piconets and in particular between nodes 301 and 310.
  • node 301 transfers the information to the master node of piconet 1 node 303.
  • Master node 303 transmits the information to forwarding node 304.
  • Forwarding node 304 then forwards the information to master node 305, which in turn, transmits the information to forwarding node 308.
  • Forwarding node 308 forwards the information to master node 309 which transmits the information to the destination node 310.
  • a single piconet is just a trivial case of the more general scatternet concept.
  • the term "scatternet" refers to either a single piconet or multiple interconnected piconets.
  • Each Bluetooth unit has a globally unique 48 bit IEEE 802 address. This address, called the Bluetooth Device Address (BD_ADDR) is assigned when the Bluetooth unit is manufactured and it has never changed.
  • the Master of a piconet assigns a local active member address (AM_ADDR) to each active member of the piconet.
  • the AM_ADDR which is only three bits long, is dynamically assigned and deassigned and is unique only within a single piconet.
  • the master uses the AM_ADDR when polling a slave in a piconet. However, when the slave, triggered by a packet from the master addressed with the slave's AM_ADDR, transmits a packet to the master, the slave includes its own AM_ADDR (not the masters) in the packet header.
  • the packets can carry both synchronous data, on Synchronous Connection Oriented (SCO) links which is mainly intended for voice traffic, and asynchronous data, on asynchronous connectionless links (ACL) links.
  • SCO Synchronous Connection Oriented
  • ACL asynchronous connectionless links
  • an acknowledgment and retransmission scheme is used (not for SCO packets transferring synchronous data) to ensure reliable data transfer, as well as forward error correction (FEC) in the form of channel coding.
  • FEC forward error correction
  • FIG. 4 illustrates a conventional Bluetooth packet.
  • the conventional Bluetooth packet consists of access code 410, header 420 and payload 430.
  • the header 420 contains the AM_ADDR followed by some control parameters, e.g., a bit indicating acknowledgment or retransmission request of the previous packet, when applicable, and a header error check (HEC).
  • the access code 410 in the packet can be of three different types including a channel access code (CAC), a device access code (DAC) or an inquiry access code (IAC).
  • CAC channel access code
  • DAC device access code
  • IAC inquiry access code
  • the channel access code identifies a channel that is used in a particular piconet, i.e., in essence the channel access code identifies the piconet. Accordingly, all packets exchanged within a piconet carry the same channel access code.
  • the channel access code is derived from the BD_ADDR of the master unit of the piconet.
  • the device access code is derived from a BD_ADDR of a particular Bluetooth unit.
  • the device access code is used for special signaling procedures, e.g., the PAGE procedure.
  • GIAC general inquiry access code
  • DIAC dedicated inquiry access code
  • the format of payload 430 depends on the type of packet.
  • the payload of an ACL packet consists of a header, a data field and a cyclic redundancy check (CRC).
  • CRC cyclic redundancy check
  • AUX1 packets do not include a CRC
  • the payload of an SCO packet consists only of a data field.
  • hybrid packets including two data fields, one for synchronous data and one for asynchronous data. Packets in which the payload does not include a CRC are neither acknowledged nor retransmitted.
  • ad-hoc networking technology typically has a neighbor discovery feature.
  • the neighbor discovery feature allows one node to find any other node with which the first node can communicate, and consequently form an ad-hoc network with.
  • a neighbor discovery procedure in Bluetooth is known as the INQUIRY procedure. Once a Bluetooth unit knows of neighboring nodes, a Bluetooth unit can connect to the neighboring node using the PAGE procedure.
  • FIG. 5 illustrates the signaling performed between two Bluetooth units for neighbor discovery and connection establishment.
  • a Bluetooth unit such as Bluetooth unit 1
  • wishing to discover neighboring nodes broadcasts an INQUIRY message.
  • the Bluetooth unit then waits and listens for an INQUIRY RESPONSE message.
  • An INQUIRY message consists of only an inquiry access code.
  • the inquiry access code can be a general inquiry access code, which is sent to discover any Bluetooth unit in the neighborhood, or a dedicated inquiry access code, which is sent to discover only certain types of Bluetooth units, for which the particular dedicated inquiry access code is dedicated.
  • the INQUIRY RESPONSE message is really an FHS (Frequency Hop Synchronization) packet.
  • a FHS packet is illustrated in FIG. 6.
  • the FHS packet includes fields for parity bits, lower address part (LAP), Scan Repetition (JSR), Scan Period (SP), upper address part (UAP), non-significant address part (NAP), class of device, AM_ADDR, internal value of the units clock (CLK), and Page Scan Mode.
  • LAP, UAP and NAP together comprise the BD_ADDR.
  • the SR, SP and Page Scan Mode fields are control parameters used during the page procedure.
  • the AM_ADDR field can be used to assign an AM_ADDR to a Bluetooth unit which is becoming a slave in a piconet, i.e. , the AM_ADDR field is used only when the FHS packet is used in the PAGE procedure, and the undefined field is reserved for future use.
  • An FHS packet is also used for other purposes in a Bluetooth system, e.g., for synchronization of the frequency hop channel sequence.
  • the Bluetooth unit that initiated the INQUIRY procedure e.g., Bluetooth unit 1
  • a Bluetooth unit When a Bluetooth unit desires to establish a connection with a neighboring node the Bluetooth unit sends a PAGE message.
  • a PAGE message consists of the Device Access Code (DAC) which is derived from the BD_ADDR of the paged Bluetooth unit.
  • DAC Device Access Code
  • a Bluetooth unit e.g., Bluetooth unit 2
  • receiving a PAGE message including its own DAC responds with an identical packet, i.e., a packet including only the DAC of the paged Bluetooth unit.
  • the paging Bluetooth unit i.e., Bluetooth unit 1
  • the paging Bluetooth unit replies with an FHS packet, including the BD_ADDR of the paging Bluetooth unit (Bluetooth unit 1), the current value of the internal clock of the paging Bluetooth unit (Bluetooth unit 1), the AM_ADDR assigned to the paged Bluetooth unit (Bluetooth unit 2) and other parameters.
  • the paged Bluetooth unit (Bluetooth unit 2) then responds with its DAC and thereby the connection between the two Bluetooth units is established.
  • the paging Bluetooth unit is already the master of a piconet, the paged Bluetooth unit has now joined this piconet as a new slave unit. Otherwise, the two Bluetooth units have just formed a new piconet with the paging Bluetooth unit as the master unit. Since the INQUIRY message does not include any information about its sender, in particular not its BD_ADDR, the Bluetooth unit that initiated the INQUIRY procedure is the only one that can initiate a subsequent PAGE procedure. Thus, the Bluetooth unit initiating an INQUIRY procedure will also be the master of any piconet that is formed as a result of a subsequent PAGE procedure. However, if considered necessary, the roles of master and slave can be switched using a master-slave-switch mechanism. This, however, can be a complex and extensive procedure, potentially resulting in a redefinition of the entire piconet, involving all other slave units in the piconet.
  • the INQUIRY and PAGE procedures are well defined in the current Bluetooth standard. These are all the tools that are needed to form a new Bluetooth piconet or join an existing one. However, even though the tools are well specified, there are no rules or guidelines as to how to use them. When neighbors are discovered there is no way to know who to connect to in order to form an appropriate piconet. Further, using a master-slave- switch mechanism is an extensive procedure and it is difficult to determine when to use it in order to improve the efficiency of a piconet. Hence, piconets will more or less form at random, often resulting in far from optimal piconet and scatternet structures. Further, the Bluetooth units forming a piconet or a scatternet will not have an idea as to the structure and interconnection of various piconets.
  • Piconet and scatternet forming procedures would be facilitated, and more efficient piconet and scatternet topologies would be possible to achieve, if more information about the involved Bluetooth units could be exchanged before the piconets and scatternets are actually established. Accordingly, it would be desirable to provide pieces of information during the INQUIRY and PAGE procedures which aid a Bluetooth unit in deterntining an efficient method for scatternet forming.
  • the INQUIRY RESPONSE messages only include information about the responding node itself. Accordingly, even if an inquiring node would collect INQUIRY RESPONSE messages from all the nodes in its vicinity, it would not obtain any information about how these nodes are interconnected, which nodes would be reachable through each other, and which nodes are connected to the same scatternet. Having a picture of how the different neighboring nodes are interconnected via "islands of connectivity" in the form of separate scatternets, would be valuable information for a node trying to establish connectivity, especially while trying to establish a so-called Maximum Connectivity Scatternet (MCS). For more information regarding Maximum Connectivity Scatternets the interested reader should refer to U.S. Provisional Application No. 60/210,908, which is herein expressly incorporated in its entirety by reference.
  • MCS Maximum Connectivity Scatternet
  • the inquiring node Since no information regarding what nodes belong to the same scatternet is included in the INQUIRY RESPONSE message, i.e., in an FHS packet, the inquiring node must first establish a connection to the responding node before it can, potentially, find out what other nodes that are reachable through it. Further, even then there is no simple mechanism to collect this information. In addition, establishing connections in order to gather information is a time consuming and resource demanding procedure, which could be greatly simplified if more information could be transferred in the INQUIRY RESPONSE message.
  • nodes can determine whether the responding nodes are members of the same network by comparing network identities.
  • the present invention provides various apparatus and methods for initial selection of the network identity.
  • the present invention provides methods and apparatus for selecting which network identity should be used by the new merged network.
  • the present invention provides for periodically changing the network identity.
  • the present invention allows nodes which have broken a connection between them to determine whether they are still members of the same network before broadcasting a message to change the network identity.
  • nodes in ad-hoc networks can determine how neighbor nodes are interconnected. Further, a node can determine whether a neighbor node is already connected to the same network as the node.
  • FIG. 1 illustrates an exemplary piconet
  • FIG. 2 illustrates an exemplary star-topology network
  • FIG. 3 illustrates an exemplary scatternet formed by a plurality of piconets
  • FIG. 4 illustrates a conventional Bluetooth packet
  • FIG. 5 illustrates signalling between two nodes for neighbor discovery and connection establishment
  • FIG. 6 illustrates a conventional FHS packet
  • FIGS. 7A-7C illustrate exemplary methods for selecting a scatternet ID in accordance with the present invention
  • FIGS. 8 A and 8B illustrate exemplary methods for selecting a scatternet ID in accordance with another embodiment of the present invention
  • FIG. 9 illustrates an exemplary method for selecting a scatternet ID when a node receives a change-scatternet-ID-message in accordance with one embodiment of the present invention
  • FIG. 10 illustrates another exemplary method for selecting a scatternet ID when a node receives a change-scatternet-ID-message in accordance with another embodiment of the present invention
  • FIGS. 11A and 11B illustrate exemplary methods for selecting a scatternet ID in accordance with yet another exemplary embodiment of the present invention.
  • FIG. 11C illustrates an exemplary method for reception and processing of a change- scatternet-ID-message in accordance with exemplary embodiments of the present invention
  • FIG. 12 illustrates an exemplary method for periodically selecting a scatternet ID in accordance with one embodiment of the present invention
  • FIG. 13 illustrates an exemplary scatternet in accordance with the present invention
  • FIG. 14 illustrates an exemplary method for selecting a scatternet ID when a node has broken a connection with a node of another piconet in accordance with another exemplary embodiment of the present invention.
  • FIG. 15 illustrates an exemplary Bluetooth unit in accordance with the present invention.
  • the present invention is directed to ad-hoc networks. More particularly, the present invention is directed to obtairiing topology information related to an ad-hoc network.
  • nodes In dynamic networks such as ad-hoc networks keeping track of the detailed topology of a scatternet, i.e., the exact connections that each node in the scatternet has with other nodes in the scatternet, would be too demanding. Further, as a scatternet grows, tracking of the detailed topology of a scatternet becomes increasingly complex. In accordance with exemplary embodiments of the present invention, nodes only keep track of which scatternet a particular node belongs to, so that it can easily be determined whether two nodes belong to the same scatternet, without knowing anything about the connection structure between them. This reduces the topology of a scatternet to the "cloud" stage, i.e., a cloud being a commonly used symbol to represent a network with arbitrary topology.
  • each scatternet has a randomly chosen scatternet identity (scatternet ID) which is known by each node in the scatternet.
  • scatternet ID the scatternet identity
  • a node When responding to an INQUIRY message, a node will include the scatternet ID in the INQUIRY RESPONSE message, e.g., in the class of device field. The inquiring node then knows that the node from which it has received an INQUIRY RESPONSE message is reachable via all other nodes that respond with the same scatternet ID. By collecting INQUIRY RESPONSE messages including different scatternet IDs, the inquiring node obtains a picture of the different "scatternet islands" that are present in the vicinity of the particular node.
  • an idle node i.e., a node that is not connected to any other node, should respond with a default scatternet ID, e.g., all zeros, reserved for this purpose.
  • a default scatternet ID e.g., all zeros
  • the idle status could be indicated explicitly by some other means, e.g. , using the undefined field of the FHS packet. In such case, an idle node would not have to include any scatternet ID at all in the INQUIRY RESPONSE message.
  • neighbor nodes of a particular node there are two types of neighbor nodes, those which are connected to the particular node (i.e., part of the same piconet or scatternet) and those which are within radio range of the particular node but does not have an established connection with the particular node. Accordingly, it will be recognized that in the following when it is described that a message is forwarded to a neighbor node, this neighbor node is a connected neighbor node. Further, it will be recognized that when it is described that the particular node is performing a process to determine which network a neighbor node belongs to, this neighbor node is within radio range but does not have an established connection with the particular node. This will be evident because if the particular node and the neighbor node have an established connection, the particular node will already know which network the neighbor node belongs to.
  • FIG. 7A illustrates an exemplary method for selecting a scatternet ID in accordance with the present invention.
  • this node may be a single node (i.e. , idle) or the new node can be connected to another scatternet or piconet, where a single piconet is a trivial case of the more general scatternet concept.
  • the scatternet ID should be transferred to the new node.
  • two scatternets have been merged and one of their respective scatternet IDs has to be selected as the scatternet ID for the new merged scatternet. Accordingly, it is determined whether a new node has joined the scatternet (Step 730). If a new node has not joined the scatternet ( "NO" path out of decision Step 730), then the nodes of the piconet continue to wait (Step 740).
  • Step 745 it is determined whether the new node was previously idle. An idle node is not a member of a scatternet, and hence, does not have a scatternet ID. If the new node was previously idle (“YES" path out of decision Step 745) then the scatternet ID is transferred to the new node (Step 747). If the new node is not an idle node then the new node is a member of another scatternet and the scatternets are merged (Step 750).
  • the scatternet ID of the larger scatternet is selected as the scatternet ID of the merged scatternets (Step 770).
  • a change-scatternet-ID-message is then broadcast through the scatternet whose scatternet ID was not selected, i.e., the change-scatternet-ID-message is forwarded between nodes until the message has reached all the nodes in the scatternet/network (Step 790). If, however, the size of the scatternets is not available (“NO" path out of decision Step 760) then the scatternet ID of either of the two nodes forming the connection that merges the two scatternets could be chosen.
  • Step 780 An arbitrary rule could be selected for this choice, e.g., that the scatternet associated with the joining node is selected (Step 780), wherein the "joining node" is the node assuming the slave role in the connection merging the scatternets.
  • a scatternet ID has been selected a change-scatternet-ID-message is then broadcast through the scatternet whose scatternet ID was not selected (Step 790).
  • the method illustrated in FIG. 7 A is an advantageous way of selecting a scatternet ID. Since the scatternet ID of the scatternet with the larger number of nodes is selected the change- scatternet-ID-message only has to be broadcast through the smaller scatternet, thus resulting in less load being placed on the ad-hoc network. However, such size information may not be generally available. Further, when a change-scatternet-ID-message is broadcast due to a merger of two scatternets, there is a slight risk that a merger with another scatternet, or several scatternets, is being performed simultaneously. This could result in colliding of change- scatternet-ID-messages, i.e., multiple change-scatternet-ID-messages being distributed through the scatternet simultaneously.
  • a scatternet could be merging with another scatternet via two different connections, i.e., between the same two scatternets, simultaneously. This could result in either colliding or looping of change-scatternet-ID-messages. Accordingly, it would be desirable to provide a mechanism to control these situations, i.e., a mechanism of how to establish which scatternet ID has precedence over the other scatternet ID. This mechanism would govern the way a node acts whenever it has to choose between scatternet IDs, e.g. , when it receives a change-scatternet-ID-message and already has a stored scatternet ID. The mechanism would instruct the node whether it should replace the stored scatternet ID with one received in the change-scatternet-ID-message or retain its stored scatternet ID and discard the new one it received.
  • FIGS. 7B and 7C illustrate alternative methods for selecting a scatternet ID.
  • the scatternet ID can be selected based upon the size of the scatternet or based upon which node is the joining node
  • the method can be implemented such that the scatternet ID is selected solely based upon which node is the joining node (FIG. 7B), or solely based upon the size of the scatternet (FIG. 7C). It will be recognized that if the selection of the scatternet ID is based solely upon the size of the scatternets, the size of the scatternets will always be available, and hence, the method illustrated in FIG. 7C does not need to determine whether scatternet size is available (Step 760 in FIG. 7A).
  • FIG. 8 A illustrates an exemplary method for selecting a scatternet ID when two scatternets have been merged, without reducing the randomness of the selected scatternet ID and without driving the scatternet ID towards any particular value in the scatternet ID range. It is first determined whether a new node has joined the scatternet (Step 805). If a new node has not joined the scatternet ("NO" path out of decision Step 805) then the method loops back to decision Step 805 and waits for a new node to join the scatternet. If a new node has joined the scatternet ("YES" path out of decision Step 805) then it is determined whether the new node was previously idle (Step 806).
  • Step 806 If the new node was previously idle (“YES" path out of decision Step 806) then the scatternet ID is transferred to the new node (Step 807). If the new node was not previously idle (“NO” path out of decision Step 806) then the scatternets are merged (Step 810). The nodes then exchange their scatternet IDs (Step 815). Each node then determines whether the received scatternet ID is the same as the stored scatternet ID (Step 820). If the received scatternet ID is the same as the stored scatternet ID ("YES" path out of decision Step 820) then the processing in the node ends (Step 825).
  • Step 820 If the scatternet ID is not the same as the stored scatternet ID ("NO" path out of decision Step 820) then an "Exclusive OR” (XOR) operation is performed using the least significant bit (LSB) of the received scatternet ID and the current scatternet ID (Step 830). If the result of the XOR operation is 0 ("YES" path out of decision Step 835) then the node will determine that the lower scatternet ID has precedence over the higher scatternet ID (Step 840). If, however, the result of the XOR operation is not equal to 0 ("NO" path out of decision Step 835) then the node will deterrriine that the higher scatternet ID has precedence over the lower scatternet ID (Step 845).
  • LSB least significant bit
  • Step 850 After it has been determined which scatternet ID has precedence over the other (Step 840 or Step 845) it is determined whether the received scatternet ID has precedence over the old scatternet ID (Step 850). If the received scatternet ID has precedence over the old scatternet ID ("NO" path out of decision Step 850) then the processing for the node ends (Step 855). If, however, the received scatternet ID does not have precedence over the old scatternet ID ("YES" path out of decision Step 850) then the node sends the new scatternet ID in a change-scatternet-ID message to the new node (Step 860). In FIG. 8A the dashed lines returning to step 805 illustrate that the method illustrated in FIG. 8 A is performed by nodes as a continuous process.
  • Step 815 Assume that node A in scatternet A connects to node B in scatternet B.
  • the two nodes then exchange scatternet IDs (Step 815) by using means other than the above described change- scatternet-ID-message, for example, by using some type of message dedicated for this purpose.
  • the scatternet ID of node B has precedence over the scatternet ID of node A as a result of the XOR operation (Step 830 through Step 845). Accordingly, node A will wait for a change-scatternet-ID-message from node B.
  • node B receives a change-scatternet-ID- message from its old scatternet, i.e., scatternet B, that takes precedence over the current scatternet ID of node B. If this new scatternet ID does not take precedence over the scatternet ID of node A, then when node B forwards the change-scatternet-ID-message to node A, node A will discard the change-scatternet-ID-message and keep its old scatternet ID. This results in the two old scatternets, although now merged into one, still having different scatternet IDs.
  • FIG. 8B illustrates an exemplary method for selecting a scatternet ID when two scatternets have merged which addresses the above described problems. Accordingly, whereas in FIG. 8A the nodes exchange scatternet IDs using means other than a change- scatternet-ID-message (Step 815), in FIG. 8B this step is replaced by a step where a node sends a change-scatternet-ID-message to the new node and receives a change-scatternet-ID- message from the new node (Step 817).
  • FIG 8A Another difference between the procedures illustrated FIG 8A and FIG 8B is the procedure following the determination of the result of the XOR operation on the least significant bit of the two scatternet IDs, i.e. , decision Step 835.
  • the node just determines which of the two scatternet IDs that has precedence over the other (Step 840 or 845) without replacing the old scatternet ID irrespective of the result of this determination. If the stored scatternet ID has precedence over the received scatternet ID, the node sends a change-scatternet-ID-message including the stored scatternet ID to the other node (Step 860). The actual replacement of scatternet ID will occur when this change-scatternet-ID- message is received unless the above described problem occurs.
  • the node selects one of the scatternet IDs to be the new one (Steps 841 or 846) and if the received scatternet ID is selected, the old scatternet ID is replaced by the received scatternet ID and the change-scatternet-ID-message is forwarded to other nodes in the original scatternet of the node (Step 851 and 861). On the other hand, if the received scatternet ID is not selected as the new scatternet ID, the node keeps the old scatternet ID and discards the change-scatternet-ID-message.
  • Step 81-7 By sending a change- scatternet-ID-message to the new node and receiving a change-scatternet-ID-message from the new node (Step 817) the problems described above in connection with FIG. 8A are avoided because the exchanging of scatternet IDs and the replacement of scatternet ID are effectuated by the same message, i.e. without separation of the two steps. It will be recognized that in FIG. 8B the dashed lines returning to step 805 illustrate that the method illustrated in FIG. 8B is performed by nodes as a continuous process.
  • FIG. 9 illustrates the exemplary behavior of a node which has received a change- scatternet-ID-message.
  • the node determines whether it has received a change-scatternet- ID-message (Step 905). If a node has not received a change-scatternet-ID-message ("NO" path out of decision Step 905) the node continues to wait to receive a change-scatternet-ID- message. If, however, the node has received a change-scatternet-ID-message ("YES" path out of decision Step 905) the node determines whether the received scatternet ID is the same as the stored scatternet ID (Step 910).
  • the node If the received scatternet ID is the same as the stored scatternet ID ("YES" path out of decision Step 910) the node will discard the change-scatternet-ID-message (Step 915). If the received scatternet ID is not the same as the stored scatternet ID ("NO" path out of decision Step 910) then the node performs an XOR operation using the least significant bit from the scatternet ID in the message and the current stored scatternet ID (Step 920).
  • Step 930 If the result of the XOR operation is equal to 0 ("YES" path out of decision Step 925) the node will select the lower scatternet ID as the new scatternet ID (Step 930). If the result of the XOR operation is not equal to 0 ("NO" path out of decision Step 925) then the node will select the higher scatternet ID as the new scatternet ID (Step 935). Once either the lower scatternet ID or the higher scatternet ID has been selected (in accordance with either Step 930 or Step 935) then the node determines whether the received scatternet ID has replaced the old scatternet ID (Step 940).
  • the node If the received scatternet ID has not replaced the old scatternet ID ("NO" path out of decision Step 940) then the node keeps the old scatternet ID and discards the change-scatternet-ID-message (Step 945). If, however, the received scatternet ID has replaced the old scatternet ID ("YES" path out of decision Step 940) then the node stores the new scatternet ID and forwards the change-scatternet-ID- message to all connected neighbor nodes except the one from which the change-scatternet- ID-message was received (Step 950).
  • FIG. 10 illustrates another exemplary behavior of a node which has received a change-scatternet-ID-message.
  • a timestamp representing the time when the scatternet ID was generated, is associated with each scatternet ID. This timestamp is included in the change-scatternet-ID- message together with the new scatternet ID.
  • a node which receives a change-scatternet- ID-message compares the received timestamp with a timestamp associated with the stored scatternet ID.
  • a node determines whether it has received a change-scatternet-ID-message (Step 1005). If the node has not received a change-scatternet-ID-message ("NO" path out of decision Step 1005) then the node waits until it has received a change-scatternet-ID- message. If a node has received a change-scatternet-ID-message ("YES" path out of decision Step 1005) then the node determines whether the scatternet ID in the received message is the same as the stored scatternet ID (Step 1010). If the received scatternet ID is the same as the stored scatternet ID (“YES" path out of decision Step 1010) then the received message is discarded (Step 1015).
  • the node compares the received timestamp with the stored timestamp (Step 1025). If the timestamps are the same (“YES" path out of decision Step 1030) then the node performs an XOR operation using the least significant bit of the scatternet ID in the message and the current scatternet ID (Step 1050). If the timestamps are not the same (“NO" path out of decision Step 1030) then the node determines whether the received timestamp is newer than the stored timestamp (Step 1035).
  • the node will discard the message (Step 1015). If, however, the received timestamp is newer than the stored timestamp ("YES" path out of decision Step 1035) then the node replaces the stored scatternet ID with the received scatternet ID (Step 1040). The node will then forward the change-scatternet-ID-message to all connected neighbor nodes except the one from which the change-scatternet-ID-message was received (Step 1045).
  • Step 1055 If the timestamps are the same ("YES" path out of Step 1030) and the node has performed an XOR operation using the least significant bit of the scatternet ID in the message and the current scatternet ID (Step 1050) then the node will determine the result of the XOR operation (Step 1055). If the result of the XOR operation is equal to 0 ("YES" path out of decision Step 1055) the node selects the lower scatternet ID as the new scatternet ID (Step 1060). If the result of the XOR operation is not equal to 0 ("NO" path out of decision Step 1055) the node will select the higher scatternet ID as the new scatternet ID (Step 1065).
  • the node determines whether the received scatternet ID has replaced the old scatternet ID (Step 1070). If the received scatternet ID has not replaced the old scatternet ID ("NO" path out of decision Step 1070) then the node keeps the old scatternet ID and discards the change-scatternet-ID-message (Step 1075).
  • the node stores the new scatternet ID and forwards the change-scatternet-ID- message to all connected neighbor nodes except the one from which the change-scatternet- ID-message was received (Step 1080).
  • the timestamp method illustrated in FIG. 10 helps avoid colliding or looping of change-scatternet-ID-messages because when a node receives a change-scatternet-ID- message with a timestamp which is older than the stored timestamp associated with the node's current scatternet ID (Step 1035) the node discards the received change-scatternet- ID-message. Accordingly, older scatternet IDs contained in change-scatternet-ID-messages are prevented from propagating throughout the remainder of the scatternet.
  • FIGS. 11A and 11B illustrate exemplary methods of periodically generating and propagating new scatternet IDs throughout a scatternet, thereby ensuring if a scatternet has broken off of the current scatternet that the original scatternet and the broken off scatternet will have different scatterent IDs.
  • the master nodes Preferably, only the master nodes periodically generate and distribute scatternet IDs. This spares the slave nodes from this burden and reduces the risk of colliding messages distributing periodically generated scatternet IDs.
  • the periodical generation and distribution of new scatternet IDs also work as a general "safety net" procedure which cleans up fault conditions that may occur during the management of scatternet IDs.
  • each node determines whether it is a master node (Step 1105). If a node is not a master node ("NO" path out of decision Step 1105) then the processing for that node ends (Step 1110). If a node is a master node ("YES" path out of decision Step 1105) then the node randomly chooses a time value between a predefined minimum value TO and a predefined maximum value TI (Step 1115). The node then starts a timer (Step 1120).
  • the node determines whether a new scatternet ID has been received and whether the stored scatternet ID has changed since the timer was started (Step 1130). If a new scatternet ID has been received and the stored scatternet ID has been changed since the timer was started ("YES" path out of decision Step 1130) then the node randomly chooses a time value (Step 1115). If, however, a new scatternet ID has not been received and the stored scatternet ID has not been changed since the timer was started ("NO" path out of decision Step 1130) the node continues to determine whether the timer has exceeded the random value (Step 1125). If the timer exceeds the random time value ("YES" path out of decision Step 1125) then the node generates a new random scatternet ID (Step 1135).
  • Step 1135 The differences between the procedures illustrated in FIGS. 11A and 11B is the type of message distributed by the master node after the master node has generated a new random ID (Step 1135).
  • the master node distributes the new ID in a change-scatternet-ID-message (Step 1140) and then returns to randomly choose a time value (Step 1115).
  • a node which receives the new ID in the change-scatternet-ID- message generated using the method described in connection with FIG. 11 A would perform an XOR operation on the least significant bit of the scatternet ID in the message and the current ID as described in above in connection with FIGS.
  • Steps 830-860 of FIG. 8A or Steps 830-862 in FIG. 8B i.e., Steps 830-860 of FIG. 8A or Steps 830-862 in FIG. 8B.
  • a node receiving the change-scatternet-ID-message generated using the method described in connection with FIG. 11A would follow steps 1010-1080 in FIG. 10.
  • Step 1136 the master node distributes the new ID in a periodically-changed-scatternet-ID-message (Step 1142) and then returns to randomly choose a time value (Step 1115).
  • the differences between a change-scatternet-ID-message and a periodically-changed-scatternet-ID-message is the procedures followed by a node which receives the particular message. It should be noted that the procedure described in connection with 11B can be used only if the timestamp method is used, i.e., if the procedure described in connection with FIG. 10 is used for reception of regular change-scatternet-ID-messages.
  • FIG. 11C illustrates the procedures performed by a node which receives a periodically-changed-scatternet-ID-message. Initially, the node determines whether it has received a periodically-changed-scatternet-ID-message (Step 1145). If the node has not received a periodically-changed-scatternet-ID-message ("NO" path out of decision Step 1145) then the node continues to wait until it receives such a message.
  • Step 1150 the node compares the timestamp in the received message with the stored timestamp (Step 1150) and the node determines whether the timestamps are the same (Step 1155). If the node determines that the timestamps are the same ("YES" path out of decision Step 1155) the node uses the XOR method to select a scatternet ID (Step 1160) as described above in connection with FIGS. 8-10, i.e., Steps 830-861 of FIG. 8B; Steps 920-950 of FIG. 9; and Steps 1050-1080 of FIG. 10 with the only difference being that the message to be either discarded or forwarded is a periodically-change-scatternet-ID-message instead of a regular change-scatternet-ID-message .
  • the node determines whether the differences between the timestamps is less than a time period TO (Step 1162), wherein TO is the shortest time that the timer governing periodical generation of new scatternet IDs can be set to. If the differences between the timestamps is less than TO ("YES" path out of decision step 1162) then it is determined whether the received timestamp is older than the stored timestamp (Step 1164). If the received timestamp is not older than the stored timestamp ("NO" path out of decision Step 1164) then the node discards the message (Step 1166).
  • the node replaces the stored scatternet ID with the received scatternet ID (Step 1175) and forwards the periodically-changed-scatternet-ID-message (Step 1180).
  • the node determines whether the received timestamp is newer than the stored timestamp (Step 1168). If the received timestamp is not newer than the stored timestamp ("NO" path out of decision Step 1168) then the node discards the message (Step 1170). If, however, the received timestamp is newer than the stored timestamp ("YES" path out of decision Step 1168) then the node replaces the stored scatternet ID with the received scatternet ID (Step 1175) and forwards the periodically- changed-scatternet-ID-message (Step 1180).
  • FIG. 12 illustrates an exemplary method for generating a new random ID when only the XOR method (without timestamps) is used.
  • the procedure described in connection with FIG. 11A governs when to generate a new random scatternet ID and the procedure described in connection with FIG. 9 is used when a node receives a change-scatternet-ID- message.
  • the method illustrated in FIG. 12 provides the details of Step 1135 in FIG. 11 A.
  • a fraction F is chosen such that l/2 n ⁇ F ⁇ x / 2 where n is the number of bits in the scatternet ID.
  • a node first determines whether the stored scatternet ID is in the lowest F fraction of the range of scatternet ID (Step 1243). If the stored scatternet ID is in the lowest F fraction of the range of scatternet ID ("YES" path out of decision Step 1243) the node will set the least significant bit of the new scatternet ID to the inverted value of the least significant bit of the stored scatternet ID (Step 1246). Next the node will randomly select the remaining bits of the new scatternet ID in the range above the stored scatternet ID (Step 1249).
  • the node determines whether the stored scatternet ID is in the highest F fraction of the range of scatternet IDs (Step 1252). If the stored scatternet ID is in the highest F fraction of the range of scatternet IDs ("YES" path out of decision Step 1252) then the node sets the least significant bit of the new scatternet ID to the same value as the least significant bit of the stored scatternet ID (Step 1255). Next the node randomly selects the remaining bits of the new scatternet ID in the range below the stored scatternet ID (Step 1258).
  • the node randomly chooses the least significant bit of the new random ID to be either a 1 of a 0 (Step 1261).
  • the node performs an XOR operation using the randomly chosen least significant bit with the least significant bit of the stored scatternet ID (Step 1264). If the result of the XOR operation is 0 ("NO" path out of decision Step 1267) then the node randomly selects the remaining bits of the new scatternet ID in the range below the stored scatternet ID (Step 1258).
  • a scatternet split is always caused by the breaking of a connection between two nodes. If the broken connection was the only connection between two parts of the scatternet, the broken connection results in two separate scatternets. However, a broken connection does not always split a scatternet. Other connections may still hold all the nodes together and in such case they are still a single scatternet.
  • a broken connection between two nodes of a scatternet does not necessarily indicate the formation of two separate scatternets, it would be advantageous to be able to determine whether in fact two scatternets have been formed as a result of the split between the two nodes. For example, referring now to FIG. 13, if connection 1305 between nodes 1310 and 1320 were broken, the two nodes would not be able to communicate with each other directly over link 1305. However, nodes 1310 and 1405) the node continues to make this determination. If the node determines that it has broken a connection with another node ("YES" path out of decision Step 1405) the node determines whether the node is now idle (Step 1407).
  • Step 1407 If the node is now idle (“YES" path out of decision step 1407) then processing for the node ends (Step 1408). If the node is not idle (“NO" path out of decision step 1407) then the node determines whether it has a lower BD_ADDR than the node with which there was a broken connection (Step 1410). If the node does not have a lower BD_ADDR than the node with which there was a broken connection (“NO" path out of decision Step 1410) the node sets a timer (Step 1412) and waits for a message from the other node of the broken connection (Step 1415).
  • the node with the higher BD_ADDR determines whether it has received a message from the node with the lower BD_ADDR (Step 1420). If the node with the higher BD_ADDR has not received a message from the node with the lower BD_ADDR ("NO" path out of decision Step 1420) then the node determines whether the timer has expired (Step 1422). If the node determines that the timer has expired ("YES" path out of decision step 1422) then the node concludes that the scatternet has been split (Step 1424). If the timer has not expired ("NO" path out of decision step 1422) then the node continues to wait to receive the message (Step 1415).
  • the node with the higher BD_ADDR If, however, the node with the higher BD_ADDR has received a message from the node with the lower BD_ADDR ("YES" path out of decision Step 1420) the node with the higher BD_ADDR sends a reply message to the node with the lower BD_ADDR (Step 1425). Accordingly, these two nodes will now know that although there is no longer a direct link between them, i.e. , a link with zero hops, they are still part of the same scatternet.
  • steps 1412-1425 An alternative to steps 1412-1425 is that the processing in the node with the higher BD_ADDR ends with the "NO" path out of decision step 1410. If a message is subsequently received from the node with the lower BD_ADDR, the node with the higher BD_ADDR would still send a reply message to the node with the lower BD ADDR, not because the node with the higher BD_ADDR was waiting for the message from the node with the lower BD_ADDR, but because the message from the node with the lower BD_ADDR was a type of message that should always be replied to by the intended receiver, e.g. a route request message.
  • the node with the higher BD_ADDR might not determine whether the scatternet was split or not by the broken connection. If the node determines it has a lower BD_ADDR than the node with which there was a broken connection ("YES" path out of decision Step 1410) the node sends a message to the other node (Step 1430). For example, the message can be a request for route message to the other node. The node then sets a timer (Step 1435) and determines whether it has received a reply message from the other node (Step 1440).
  • Step 1440 If the node has received a reply message from the other node ("YES" path out of decision Step 1440) then the node knows that the other node is part of the same scatternet and the node ends its current processing (Step 1445). If, however, the node does not receive a reply message from the other node ("NO" path out of decision Step 1440) the node determines whether the timer has expired (Step 1450). If the node determines that the timer has not expired (“NO" path out of decision Step 1450) then the node continues to determine whether it has received a reply message from the other node (Step 1440).
  • Step 1450 If the node determines that the timer has expired ("YES" path out of decision Step 1450) then the node determines that the scatternet has been split and generates a new random scatternet ID (Step 1455). The new scatternet ID is then transferred to connected neighboring nodes in a change-scatternet-ID-message (Step 1460).
  • FIG. 15 illustrates an exemplary apparatus for implementing the methods described above.
  • the apparatus includes antenna 1510, transceiver 1520 and processor 1530.
  • ad-hoc networking nodes, and Bluetooth units in particular can be embodied in various forms.
  • the apparatus illustrated in FIG. 15 could be a mobile telephone, a personal digital assistant (PDA), a router, a printer, a kitchen appliance, or any other device for which it would be advantageous to form wireless networks.
  • FIG. 15 illustrates processor 1530, one skilled in the art will recognize that this apparatus can be implemented with either a microprocessor, an application specific integrated circuit (ASIC), hard- wired logic, or any other equivalent means.
  • ASIC application specific integrated circuit
  • one node may broadcast the scatternet ID in a neighbor discovery message and compare the responses received from neighboring nodes. Based upon the comparison of the responses the one node can determine whether the responding nodes are part of the same scatternet. This information can be used by the one node to determine that if it connects to one of the responding nodes, the one node will also be able to reach the other responding node because they are part of the same scatternet.

Abstract

Dans un réseau ad-hoc, des identités réseau sont affectées à chaque réseau. Les identités réseau permettent à un noeud de déterminer si un noeud voisin (non connecté à ce noeud) appartient au même réseau que lui ou si un noeud voisin (non connecté au noeud) appartient au même réseau qu'un autre noeud (non connecté au noeud). Si deux réseaux fusionnent, l'identité réseau de l'un d'eux est sélectionnée et diffusée dans la partie du réseau fusionné devant changer d'identité réseau. Pour éviter que des réseaux multiples, ayant appartenu au même réseau, aient la même identité réseau, les identités réseau sont périodiquement réaffectées et diffusées dans chaque réseau. De plus, lorsqu'une connexion entre deux noeuds est coupée, les noeuds peuvent déterminer s'ils appartiennent toujours au même réseau avant d'initier un changement de la procédure d'identité réseau.
PCT/SE2001/001301 2000-06-12 2001-06-07 Gestion d'identite aleatoire dans des scatternets WO2001097447A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001264504A AU2001264504A1 (en) 2000-06-12 2001-06-07 Random identity management in scatternets

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US21076100P 2000-06-12 2000-06-12
US60/210,761 2000-06-12
US70964300A 2000-11-13 2000-11-13
US09/709,643 2000-11-13

Publications (2)

Publication Number Publication Date
WO2001097447A2 true WO2001097447A2 (fr) 2001-12-20
WO2001097447A3 WO2001097447A3 (fr) 2002-07-25

Family

ID=26905491

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2001/001301 WO2001097447A2 (fr) 2000-06-12 2001-06-07 Gestion d'identite aleatoire dans des scatternets

Country Status (2)

Country Link
AU (1) AU2001264504A1 (fr)
WO (1) WO2001097447A2 (fr)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002063829A2 (fr) * 2001-02-05 2002-08-15 Nokia Corporation Transfert de donnees
WO2003017579A1 (fr) * 2001-08-17 2003-02-27 David Nordfors Connexion de dispositifs bluetooth les uns aux autres
WO2003103230A1 (fr) * 2002-06-03 2003-12-11 Nokia Corporation Procede et dispositif de formation d'un reseau disperse (≤ scatternet ≥) dans des reseaux ad hoc
EP1480415A1 (fr) * 2003-05-23 2004-11-24 Deutsche Thomson-Brandt Gmbh Méthode pour l'allocation d'un identificateur à un groupe de noeuds point-à-point dans un réseau point-à-point
JP2004350297A (ja) * 2003-05-23 2004-12-09 Thomson Licensing Sa 共通の識別子の自動割り当て方法およびネットワークにおける第1ノードであるデバイス
EP1487181A2 (fr) * 2003-05-23 2004-12-15 Thomson Licensing, Inc. Méthode pour l'allocation d'un identificateur à un groupe de noeuds point-à-point dans un résesau point-à-point
FR2880433A1 (fr) * 2005-01-06 2006-07-07 Bodet Sa Ets Procede pour initialiser un systeme de distribution horaire sans fil
EP1766877A2 (fr) * 2004-07-09 2007-03-28 Interdigital Technology Corporation Separation d'un reseau maille logique et physique
CN100334859C (zh) * 2003-09-18 2007-08-29 三星电子株式会社 在子微微网坐标方位仪和目标装置之间通信的方法和系统
KR100788851B1 (ko) 2005-01-21 2007-12-27 리서치 인 모션 리미티드 컴퓨팅 장치의 구성요소 사이의 지정된 접속을 결정하는 시스템 및 방법
US7349413B2 (en) 2004-04-26 2008-03-25 Samsung Electronics Co., Ltd. Method and apparatus for communicating between coordinator-based wireless networks connected through a backbone network
CN100384146C (zh) * 2005-06-08 2008-04-23 杭州华三通信技术有限公司 管理分布式网络设备的方法
WO2009150492A1 (fr) * 2008-06-11 2009-12-17 Freescale Semiconductor, Inc. Procédé et appareil destiné à permettre une communication entre un premier dispositif et au moins un autre dispositif
US8958288B2 (en) 2008-07-14 2015-02-17 Electronics And Telecommunications Research Institute Method and apparatus for setting detour path in wideband high frequency wireless system using centralized MAC protocol
US10939299B2 (en) 2008-12-23 2021-03-02 Koninklijke Philips N.V. Self-coexistence of devices in a flexible wireless system including two or more wireless networks that share a frequency band

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4464752A (en) * 1981-11-06 1984-08-07 The Singer Company Multiple event hardened core memory
US5408506A (en) * 1993-07-09 1995-04-18 Apple Computer, Inc. Distributed time synchronization system and method
EP0709983A1 (fr) * 1994-10-26 1996-05-01 International Business Machines Corporation Méthode et dispositif d'allocation pour la réutilisation des ressources de réseau dans un système de communication sans fils
WO1997017667A1 (fr) * 1995-11-09 1997-05-15 British Technology Group Limited Detection amelioree de transmissions de donnees multiples
US5740160A (en) * 1995-03-06 1998-04-14 Nec Corporation Setting network identifier in wireless local area network
US5742905A (en) * 1994-09-19 1998-04-21 Bell Communications Research, Inc. Personal communications internetworking
WO1998035453A1 (fr) * 1997-02-06 1998-08-13 Norand Corporation Reseau de balisage de faible puissance sans fil a fonction de formation, separation et restructuration en mode proximal
US5881372A (en) * 1995-09-02 1999-03-09 Lucent Technologies Inc. Radio communication device and method
US6032042A (en) * 1992-09-10 2000-02-29 Nokia Telecommunications Oy Cellular radio network having mobile radio station user-activated unlocking of prevention of location-updating feature
WO2000048367A2 (fr) * 1999-02-10 2000-08-17 Nokia Wireless Routers, Inc. Protocole adaptatif de communication destine aux reseaux sans fil
US6154136A (en) * 1998-02-26 2000-11-28 Van Eeden; Hendrik Lodewyk Free running RF identification system with increasing average inter transmission intervals

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3183224B2 (ja) * 1997-07-31 2001-07-09 日本電気株式会社 複数nw端末接続通信制御方法及びその装置

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4464752A (en) * 1981-11-06 1984-08-07 The Singer Company Multiple event hardened core memory
US6032042A (en) * 1992-09-10 2000-02-29 Nokia Telecommunications Oy Cellular radio network having mobile radio station user-activated unlocking of prevention of location-updating feature
US5408506A (en) * 1993-07-09 1995-04-18 Apple Computer, Inc. Distributed time synchronization system and method
US5742905A (en) * 1994-09-19 1998-04-21 Bell Communications Research, Inc. Personal communications internetworking
EP0709983A1 (fr) * 1994-10-26 1996-05-01 International Business Machines Corporation Méthode et dispositif d'allocation pour la réutilisation des ressources de réseau dans un système de communication sans fils
US5740160A (en) * 1995-03-06 1998-04-14 Nec Corporation Setting network identifier in wireless local area network
US5881372A (en) * 1995-09-02 1999-03-09 Lucent Technologies Inc. Radio communication device and method
WO1997017667A1 (fr) * 1995-11-09 1997-05-15 British Technology Group Limited Detection amelioree de transmissions de donnees multiples
WO1998035453A1 (fr) * 1997-02-06 1998-08-13 Norand Corporation Reseau de balisage de faible puissance sans fil a fonction de formation, separation et restructuration en mode proximal
US6154136A (en) * 1998-02-26 2000-11-28 Van Eeden; Hendrik Lodewyk Free running RF identification system with increasing average inter transmission intervals
WO2000048367A2 (fr) * 1999-02-10 2000-08-17 Nokia Wireless Routers, Inc. Protocole adaptatif de communication destine aux reseaux sans fil

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JAMES KARDACH: "Bluetooth Architecture Overview" JAMES KARDACH: BLUETOOTH ARCHITECTURE OVERVIEW, [Online] 18 March 1999 (1999-03-18), pages 1-45, XP002141146 Retrieved from the Internet: <URL:www.palowireless.com/infotooth/downlo ad.asp> [retrieved on 2001-01-04] *

Cited By (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002063829A2 (fr) * 2001-02-05 2002-08-15 Nokia Corporation Transfert de donnees
WO2002063829A3 (fr) * 2001-02-05 2003-08-07 Nokia Corp Transfert de donnees
WO2003017579A1 (fr) * 2001-08-17 2003-02-27 David Nordfors Connexion de dispositifs bluetooth les uns aux autres
WO2003103230A1 (fr) * 2002-06-03 2003-12-11 Nokia Corporation Procede et dispositif de formation d'un reseau disperse (≤ scatternet ≥) dans des reseaux ad hoc
CN1574774B (zh) * 2003-05-23 2014-06-11 汤姆森许可贸易公司 在对等网络中为对等组分配标识符的方法
KR101036714B1 (ko) * 2003-05-23 2011-05-24 톰슨 라이센싱 식별자를 피어-투-피어 네트워크내 피어-그룹에 할당하기위한 방법
EP1487181A2 (fr) * 2003-05-23 2004-12-15 Thomson Licensing, Inc. Méthode pour l'allocation d'un identificateur à un groupe de noeuds point-à-point dans un résesau point-à-point
EP1487181A3 (fr) * 2003-05-23 2005-02-09 Thomson Licensing, Inc. Méthode pour l'allocation d'un identificateur à un groupe de noeuds point-à-point dans un résesau point-à-point
EP1480415A1 (fr) * 2003-05-23 2004-11-24 Deutsche Thomson-Brandt Gmbh Méthode pour l'allocation d'un identificateur à un groupe de noeuds point-à-point dans un réseau point-à-point
US7991855B2 (en) 2003-05-23 2011-08-02 Thomson Licensing Method for assigning an identifier to a peer-group in a peer-to-peer network
JP2004350297A (ja) * 2003-05-23 2004-12-09 Thomson Licensing Sa 共通の識別子の自動割り当て方法およびネットワークにおける第1ノードであるデバイス
CN100334859C (zh) * 2003-09-18 2007-08-29 三星电子株式会社 在子微微网坐标方位仪和目标装置之间通信的方法和系统
US7349413B2 (en) 2004-04-26 2008-03-25 Samsung Electronics Co., Ltd. Method and apparatus for communicating between coordinator-based wireless networks connected through a backbone network
EP1766877A2 (fr) * 2004-07-09 2007-03-28 Interdigital Technology Corporation Separation d'un reseau maille logique et physique
EP1766877A4 (fr) * 2004-07-09 2008-01-23 Interdigital Tech Corp Separation d'un reseau maille logique et physique
FR2880433A1 (fr) * 2005-01-06 2006-07-07 Bodet Sa Ets Procede pour initialiser un systeme de distribution horaire sans fil
KR100788851B1 (ko) 2005-01-21 2007-12-27 리서치 인 모션 리미티드 컴퓨팅 장치의 구성요소 사이의 지정된 접속을 결정하는 시스템 및 방법
CN100384146C (zh) * 2005-06-08 2008-04-23 杭州华三通信技术有限公司 管理分布式网络设备的方法
WO2009150492A1 (fr) * 2008-06-11 2009-12-17 Freescale Semiconductor, Inc. Procédé et appareil destiné à permettre une communication entre un premier dispositif et au moins un autre dispositif
US8947199B2 (en) 2008-06-11 2015-02-03 Freescale Semiconductor, Inc. Method and apparatus for enabling communication between a first device and at least one further device
US8958288B2 (en) 2008-07-14 2015-02-17 Electronics And Telecommunications Research Institute Method and apparatus for setting detour path in wideband high frequency wireless system using centralized MAC protocol
US9900243B2 (en) 2008-07-14 2018-02-20 Electronics And Telecommunications Research Institute Method and apparatus for setting detour path in wideband high frequency wireless system using centralized MAC protocol
US10382318B2 (en) 2008-07-14 2019-08-13 Electronics And Telecommunications Research Institute Method and apparatus for setting detour path in wideband high frequency wireless system using centralized mac protocol
US10979344B2 (en) 2008-07-14 2021-04-13 Electronics And Telecommunications Research Institute Method and apparatus for setting detour path in wideband high frequency wireless system using centralized MAC protocol
US10939299B2 (en) 2008-12-23 2021-03-02 Koninklijke Philips N.V. Self-coexistence of devices in a flexible wireless system including two or more wireless networks that share a frequency band

Also Published As

Publication number Publication date
WO2001097447A3 (fr) 2002-07-25
AU2001264504A1 (en) 2001-12-24

Similar Documents

Publication Publication Date Title
EP1107522B1 (fr) Formation intelligent de Piconets
US6751200B1 (en) Route discovery based piconet forming
KR100605896B1 (ko) 모바일 애드 혹 네트워크에서 부분 경로 탐색을 이용하여 라우트 경로를 설정하는 방법 및 이동통신 단말기
JP4505454B2 (ja) 無線通信ネットワークの性能全体を改良するためのシステム及び方法
US20020044549A1 (en) Efficient scatternet forming
US8134950B2 (en) Cluster head election in an ad-hoc network
US6876643B1 (en) Clustering in wireless ad hoc networks
KR101088217B1 (ko) 그물형 네트워크의 중앙 제어 장치 및 방법
US20040167988A1 (en) Bridging between a Bluetooth scatternet and an Ethernet LAN
TWI249306B (en) Channel assignment method in mobile ad-hoc networks
US20040141511A1 (en) Bridging between a bluetooth scatternet and an ethernet LAN
US20040151193A1 (en) Bridging between a Bluetooth scatternet and an Ethernet LAN
US20030081603A1 (en) Pending data announcements
US20060007882A1 (en) System and method for selecting stable routes in wireless networks
US20030069988A1 (en) In-band signaling
WO2001041377A1 (fr) Formation de picoreseau basee sur la recherche de voies d&#39;acheminement
WO2004053940A2 (fr) Protocole de radiodiffusion multicanal pour reseau s&#39;organisant automatiquement
WO2002021769A2 (fr) Coordination d&#39;horaire d&#39;emission entre des radios internet cosituees
EP1810043A2 (fr) Systeme et procede pour reduire le temps de convergence de voies d&#39;acheminement et pour trouver des voies d&#39;acheminement optimales dans un reseau de communication sans fil
WO2001097447A2 (fr) Gestion d&#39;identite aleatoire dans des scatternets
US20040153520A1 (en) Bridging between a bluetooth scatternet and an ethernet LAN
US20040156318A1 (en) Bridging between a Bluetooth scatternet and an Ethernet LAN
US20040156384A1 (en) Bridging between a Bluetooth scatternet and an Ethernet LAN
KR101093616B1 (ko) 무선 센서 네트워크를 위한 주파수 다중화지원 기반 매체접근제어 프로토콜 구조 및 그 운영 방법
JP7326230B2 (ja) 通信システム、ノード、通信方法及びプログラム

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP