FIELD OF THE INVENTION
The present invention relates to the field of telecommunications. More particularly, the present invention relates to the field of ad-hoc network telecommunications.
BACKGROUND OF THE INVENTION
“Bluetooth” is an example of an ad-hoc wireless network technology that uses a frequency hopping scheme in the unlicensed 2.4 Ghz ISM (Industrial-Scientific-Medical) band. The original intention of Bluetooth was to eliminate cables between devices such as phones, PC-cards, wireless headsets, etc., in a short-range radio environment. Today, however, Bluetooth is a true ad-hoc wireless network technology intended for both synchronous traffic, e.g., voice and asynchronous traffic, e.g., IP based data traffic. The aim is that any digital communication device such as telephones, PDAs, laptop computers, digital cameras, video monitors, printers, fax machines, etc. should be able to communicate over a radio interface through the use of a Bluetooth radio chip and its accompanying software.
FIGS. 1A-C illustrate three exemplary Piconets. In accordance with, the Bluetooth technology, two or more Bluetooth (BT) units sharing the same channel form a piconet. Within a piconet, a BT unit can be either a master or a slave, although each piconet must have only one master and up to seven active slaves. Any BT unit can become a master. FIG. 2 illustrates a scatternet. A scatternet is formed through the interconnection of two or more piconets. Two or more piconets connect with each other through a commonly shared BT unit, that is a member of each piconet. BT unit 205 is an example of a BT unit that is shared by three piconets 1, 2 and 3.
FIG. 2 further illustrates that a BT unit, which is shared by two or more piconets, may be a slave unit in several piconents, but a master unit in only one piconet. For example, BT unit 210 is the master unit in piconet 10, but only a slave unit in piconet 111 and 12. In addition, a BT unit that is a member of two or more piconets may transmit and receive data in one piconet at a time. Accordingly, participation in multiple piconets has to be on a time division multiplex basis. It should be noted that there is no direct transmission between slaves, only between master and slave and vice versa.
Each BT unit has a globally unique 48-bit IEEE 802 address. This address, called the Bluetooth Device Address (BD_ADDR), is assigned when the BT unit is manufactured, and it never changes. In addition, 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 to poll a particular slave in the piconet. When the slave, triggered by a polling packet from the master, transmits a packet to the master, it includes its own AM_ADDR in the packet header.
Though all data is transmitted in packets, the packets may contain synchronous data, on SCO links, which is primarily intended for voice traffic, and/or asynchronous data, on Asynchronous Connectionless (ACL) links. If the packet contains asynchronous data, an acknowledgment and retransmission scheme is used to ensure reliable transfer of data, as is forward error correction (FEC) in the form of channel coding.
FIG. 3 illustrates the standard format of a Bluetooth packet, although there are exceptions for certain control packets. The AM_ADDR is located in the packet header, followed by control parameters (e.g., a bit indicating acknowledgment or retransmission request, when applicable, and a header error check (HEC) code.
The format of the payload depends on the type of packet. The payload of an ACL packet consists of a header, a data field and, in most instances, a cyclic redundancy check (CRC) code. The payload of an SCO packet only contains a data field. In addition, there are hybrid packets that include two data fields, one for synchronous data and one for asynchronous data. Packets which do not include a CRC are neither acknowledged nor retransmitted.
FIG. 4 illustrates the protocol layers of a Bluetooth system. The Baseband, LMP and L2CAP are existing Bluetooth specific protocols, the “high level protocol or application” layer represents protocols that may or may not be Bluetooth specific, while the Network layer does not currently exist in the current Bluetooth specifications.
A significant limitation associated with Bluetooth is that there is no defined method for addressing and routing packets from a BT unit in one piconet to a BT unit in another piconet. In other words, the current Bluetooth specification does not specify how inter-piconet communication is performed in a scatternet.
An important capability in any ad-hoc networking technology is the neighbor discovery feature. This is also true for Bluetooth. Without a neighbor discovery capability, a BT unit can not find other BT units with which to communicate, and consequently, no ad-hoc network would be formed. The neighbor discovery procedure in Bluetooth involves an INQUIRY message and an INQUIRY RESPONSE message. A BT unit wanting to discover neighboring BT units within radio coverage will, according to well specified timing and frequency sequences, repeatedly transmit INQUIRY messages and listen for INQUIRY RESPONSE messages. An INQUIRY message consists of only an Inquiry Access Code. The Inquiry Access Code can be a General Inquiry Access Code (GIAC), which is sent to discover any BT unit in the neighborhood, or a Dedicated Inquiry Access Code (DIAC), which is sent to discover a certain type of BT unit, for which a particular DIAC is dedicated.
A BT unit receiving an INQUIRY message, whether it contains a GIAC or a DIAC responds with an INQUIRY RESPONSE message. The INQUIRY RESPONSE message is, in actuality, a Frequency Hop Synchronization (FHS) packet. Bluetooth uses FHS packets for other purposes, e.g., for synchronization of the frequency hop channel sequence, as the name suggests. In any event, by listening for INQUIRY RESPONSE messages, the BT unit that initiated the INQUIRY can collect the BD_ADDR and internal clock values, both of which are included in the FHS packet, of the neighboring BT units.
Related to the INQUIRY procedure is the PAGE procedure. A PAGE procedure is used to establish an actual connection between two BT units. Once the BD_ADDR of a neighboring BT unit is known, as a result of an INQUIRY procedure, the neighboring BT unit can be paged with a PAGE message. Knowing the internal clock value of the BT unit being paged speeds up the PAGE procedure, since it is possible for the paging unit to estimate when and on what frequency hop channel the neighboring BT unit will listen for PAGE messages.
A PAGE message consists of the Device Access Code (DAC), derived from the BD_ADDR of the paged BT unit. A BT unit receiving a PAGE message that includes its DAC, responds with an identical packet. The paging BT unit then replies with an FHS packet, including the BD_ADDR of the paging BT unit, the current value of the internal clock of the paging BT unit, the AM_ADDR assigned to the paged BT unit and other parameters. The paged BT unit then responds once again with its DAC, and the connection between the two BT units is established.
If the paging BT unit is already the master of an existing piconet, the paged BT unit joins the existing piconet as a new slave unit. Otherwise, the two BT units form a new piconet with the paging BT unit as the master unit. Since the INQUIRY message does not include any information about its sender, the BT unit initiating the INQUIRY procedure is the only one that can initiate a subsequent PAGE procedure. Thus, the BT 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 in Bluetooth. This, however, is a complex and extensive procedure resulting in a redefinition of the entire piconet which may involve other slave units in the piconet.
The INQUIRY and PAGE procedures are well specified in the current Bluetooth standard. These are all the tools that are needed to form a new Bluetooth piconet or to add a new BT unit to an existing piconet. However, even though these 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 with whom to connect in order to form an appropriate piconet. Moreover, even if the master-slave-switch mechanism exists, using it is an extensive procedure, as stated, and it is hard to know 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. An exception is when the BT unit initiating the INQUIRY procedure already knows the BD_ADDR of the BT unit it wants to connect to.
An important aspect of Bluetooth is the ability to support IP on top of the Bluetooth protocol stack. There are currently two proposals for achieving this. The first proposal regards each piconet as an IP subnet, and runs IP on top of L2CAP in each piconet. The second proposal regards an entire Bluetooth scatternet as an IP subnet. This requires that an adaptation layer, herein referred to as the Network Adaptation Layer (NAL), be inserted between L2CAP and the IP layer, as illustrated in FIG. 5. The purpose of the NAL is to emulate a shared medium network (i.e., a broadcast medium) which is assumed by the IP layer.
The first proposal suffers from a number of problems, due, in part, to the fact that Bluetooth piconets are not shared medium networks. The second proposal is of course, not without problems, but it seems to be a more promising approach. The present invention is applicable to the second proposal. Accordingly, the present invention assumes protocol layers as illustrated in FIG. 5, which includes a NAL.
The NAL layer has to support a number of features. For instance, it must support a routing mechanism to route packets within a scatternet while causing the scatternet to emulate a single shared medium network which is assumed by the IP layer. Regardless of the routing scheme used to route packets through the scatternet, the scheme must rely on BT units that are members of more than one piconet to forward packets from one piconet to another. These BT units are referred to herein below as forwarding nodes.
In general, routing protocols can be classified as proactive or reactive. A proactive routing protocol maintains routes between nodes, even if the route is not currently needed. Proactive routing protocols react to network topology changes even if no traffic is affected by the topology change. Proactive routing protocols are very costly in terms of overhead, because every node must periodically send out control information to other nodes in the network.
An alternative approach is to use reactive routing. In accordance with reactive routing, routes are established only when there is an explicit need to route packets to a particular destination. This means that the routing protocol only keeps track of routes that actually are needed for sending data. Therefore, there is less cost in terms of overhead to maintain the routes.
To establish a route from a source to a destination, the source node typically broadcasts a REQUEST message which requests a route to a stated destination. All nodes that are within range receive this REQUEST message. A node that receives the REQUEST message but is neither the destination node or a node with a valid route to the destination node, will rebroadcast the REQUEST message to its neighbors. When the destination node, or a node with a valid route to the destination node receives the REQUEST message, it limits network flooding by not rebroadcasting the REQUEST message, and it sends a Unicast REPLY message back to the source node.
Typically, the source node uses the first reply message received, and it only requests a new route when the actual route breaks. The routing can be accomplished according to one of the following disciplines. First, there is source routing, where the entire route is received in the REPLY message. No information is needed in the intermediate nodes, only the source needs to keep track of the route. The entire route is specified in every packet sent. The second involves a distance vector, which means that the REPLY message stores information in the routing tables of the intermediate nodes. This means that only the destination is needed in sent packets.
The Bluetooth specification, as stated, has the INQUIRY and PAGE procedure to establish piconets, but it fails to describe how these can be used to form efficient scatternets. Moreover, current solutions do not provide a procedure for nodes that have packets to send to a destination, wherein these nodes are not members of any piconet.
SUMMARY OF THE INVENTION
These and other problems, drawbacks and limitations associated with present techniques are overcome according to the present invention, wherein a source node in a telecommunications network (i.e., a node from which a packet is sent) can form one or more new network connections based upon predetermined events.
Accordingly, it is an objective of the present invention to allow reactive ad-hoc routing protocols to determine whether new network connections are to be made in order to form a route between the source node and the destination node.
It is another objective of the present invention to provide means for a source node in a network, upon the occurrence of a predetermined event, to create new network connections in forming a route between the source node and the destination node.
In accordance with one aspect of the present invention, the foregoing and other objectives are achieved by a method in a communications network for establishing a route over which data packets are to be sent from a source node to a destination node. The method involves requesting route discovery between the source node and the destination node over existing network connections. Ultimately, a determination is made as to whether the request for route discovery has failed. If the request for route discovery failed, a route between the source node and the destination node is formed by creating one or more new network connections.