WO2002039484A2

WO2002039484A2 - Intelligent bluetooth inquiry procedure

Info

Publication number: WO2002039484A2
Application number: PCT/SE2001/002413
Authority: WO
Inventors: Johan Rune
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2000-11-09
Filing date: 2001-11-02
Publication date: 2002-05-16
Also published as: WO2002039484A3; TW529264B; AU2002212909A1

Abstract

A method of providing useful connection information to an inquiring node, about neighboring nodes and the services andd evice types they can access, in an ad-hoc communication system. The method provides for special or modified access codes that first, informs neighboringnodes of the service or device type the inquiring node wishes to receive information aobut, and secondly, forces the neighboring node that responds to provide useful connection information, through a variety of methods, in a variety of means.

Description

INTELLIGENT BLUETOOTH INQUIRY PROCEDURE Background Of the Invention

The present invention generally relates to network configuration. More particularly, the present invention relates to providing network nodes with information related to other nodes which the network nodes can use when forming a network.

Conventional networking protocols are based on the characteristics and/or features of fixed networks. In fixed networks, the network configuration typically does not change. Although nodes can be added and removed in fixed networks, the route traveled by data packets between two nodes typically does not change. The disadvantage is that fixed networks cannot be easily reconfigured to account for increases in data traffic, also called system loading. Accordingly, when system loading increases for one node, the surrounding nodes are likely to experience increased delays in the transmission and reception of data.

In contrast to fixed 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 mechanism 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.

Figure 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. In each piconet, for example piconet 100, there exists one master Bluetooth unit and one or more slave Bluetooth units. In Figure 1 Bluetooth unit 101 is a master unit and unit 102 is a Bluetooth slave unit.

Figure 2 illustrates a larger piconet, including a master and several slaves. According to Bluetooth technology a slave unit can only communicate directly with a master unit. Figure 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.

Figure 3 illustrates an exemplary scatternet 300. A scatternet is formed by multiple independent and unsynchronized piconets. In Figure 3, piconet 1 includes the master node 303 and slave nodes 301, 302 and 304; piconet 4 includes the master node 305 and slave nodes 304, 306, 307 and 308; and piconet 5 includes the master node 309 and slave nodes 308 and 310. To implement a scatternet it is necessary to use nodes which are members of more than one piconet. Such nodes are herein referred to as forwarding nodes. If, for example, node 301 wishes to communicate with node 310, then nodes 304 and 308 might act as forwarding nodes by forwarding the information between the two piconets and in particular between nodes 301 and 310. For example, 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 Bluetooth unit can simultaneously be a slave member of multiple piconets, but only master in one piconet. Additionally, a Bluetooth unit that acts as master in one piconet can participate in other piconets as a slave. A Bluetooth unit can only transmit and receive data in one piconet at a time, so participation in multiple piconets has to be on a time division multiplex basis.

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 is never changed. 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 de-assigned 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, it includes its own AM_ADDR (not the master's) in the packet header.

Figure 4 illustrates a 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 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).

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, as will be described below. There are two types of inquiry access codes, the general inquiry access code (GIAC) and the dedicated inquiry access code (DIAC). The general inquiry access code (GIAC), is sent to discover any Bluetooth unit in the neighborhood. The dedicated inquiry access code (DIAC), is sent to discover only certain types of Bluetooth units. Each individual dedicated inquiry access codes is unique to a different type of Bluetooth unit. Both the general inquiry access code and the dedicated inquiry access code are used in the INQUIRY procedure.

Since ad-hoc networks are dynamic, ad-hoc networking technology typically has a neighbor discovery feature. The neighbor discovery feature allows one Bluetooth unit to find any other Bluetooth unit which the first Bluetooth unit can communicate with 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 Bluetooth units, a Bluetooth unit can connect to the neighboring Bluetooth unit using the PAGE procedure.

Figure 5 illustrates the signaling performed between two Bluetooth units for neighbor discovery and connection establishment. Note that in Figure 5, there are two headings "Message." These are meant to indicate the relative sequencing of transmissions. A Bluetooth unit, such as Bluetooth unit 1 wishing to discover neighboring Bluetooth units broadcasts an INQUIRY message. A Bluetooth unit issuing an INQUIRY message is referred to as an inquiring Bluetooth unit (IBTU). The Bluetooth unit then waits and listens for INQUIRY RESPONSE messages. An INQUIRY message consists of only an inquiry access code, i.e. either a GIAC or DIAC. The INQUIRY message will be sent repeatedly according to well specified timing and frequency sequences.

When a neighboring Bluetooth unit, such as Bluetooth unit 2, receives an INQUIRY message, Bluetooth unit 2 responds with an INQUIRY RESPONSE message. The neighboring Bluetooth unit that responds to the inquiring Bluetooth unit is referred to as a responding Bluetooth unit (RBTU). The INQUIRY RESPONSE message is a frequency hop synchronization (FHS) packet. Messages 1 and 2 constitute the neighbor discovery procedure, or, INQUIRY procedure.

Figure 6 illustrates a frequency hop synchronization packet. All fields in the FHS packet, except the AM_ADDR field (and the undefined field) indicate properties or parameters of the Bluetooth unit that sends the FHS packet. The FHS packet includes fields for parity bits, lower address part (LAP), scan repetition (SR), scan period (SP), upper address part (UAP), non-significant address part (NAP), Class of Device, AM_ADDR, internal value of the sending unit's clock (CLK), and Page Scan Mode. The LAP, UAP and NAP together comprise the BD_ADDR of the sending unit.

The "Class of Device" field indicates the class of device of the responding Bluetooth unit. For example, a class of device might be a fax machine, or phone or printer, or refrigerator. The CLK field contains the current value of the responding Bluetooth unit's internal clock. 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 is only used when the FHS packet is used in the PAGE procedure) and the undefined field is reserved for future use.

Referring again to Figure 5, when a Bluetooth unit desires to establish a connection with a neighboring Bluetooth unit, the Bluetooth unit sends a PAGE message. Messages 3 through 6 constitute the connection procedure, or PAGE procedure. A PAGE message (message 3) consists of the Device Access Code (DAC), derived from the BD_ADDR of the paged Bluetooth unit. 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 (message 4) of the paged Bluetooth unit (Bluetooth unit 2). The paging Bluetooth unit, i.e., Bluetooth unit 1, then replies with an FHS packet (message 5) , 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 (message 6) thereby establishing a connection between the two Bluetooth units. If the paging Bluetooth unit already was 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.

Even though existing Bluetooth specifications describe the mechanisms that can be used to create piconets and form scatternets, the criteria to create a specific scatternet is not specified. The INQUIRY and PAGE procedures are well specified, but no rules or guidelines exist as to how to use them. For example, when neighbors are discovered there is no way to know who to connect to in order to form an appropriate piconet. Hence, piconets will more or less form at random, often resulting in far from optimal piconet and scatternet structures.

The provision of information about available services and device types would facilitate the piconet and scatternet forming procedures. Further, since setting up connections with a plurality of nodes in order to retrieve this type of information is a very time consuming task, i.e., requiring performing an INQUIRY and PAGE procedure with each of the plurality of nodes, the provision of information about available services and devices types prior to actual connection establishment improves a node's ability to make informed decisions as to which nodes to connect to.

Summary of the Invention

In accordance with exemplary embodiments of the present invention, methods and apparatus are provided for informing network nodes of services available and/or device types present in a network prior to the establishment of a connection between a node and the network. More specifically, in response to a message which is used to discover neighboring nodes, neighboring nodes reply with a message which indicates services and/or device types present in the neighboring node's network.

An exemplary embodiment of the invention comprises a method for selectively establishing a communication link between an inquiring Bluetooth unit and one or more of a plurality of neighboring Bluetooth units. The method begins by the inquiring Bluetooth unit transmitting an INQUIRY message, which contains an inquiry access code. The inquiry access code represents a request by the inquiring Bluetooth unit to determine if any service or device is accessible through neighboring Bluetooth units. The neighboring Bluetooth unit(s), if they have received the inquiring Bluetooth units INQUIRY message transmits an INQUIRY RESPONSE message to the inquiring Bluetooth unit, which contains the accessible device or service information requested, and other information useful in making a connection between the neighboring Bluetooth unit(s) and the inquiring Bluetooth unit. A neighboring Bluetooth unit that responds in this manner is known as a responding Bluetooth unit. If the responding Bluetooth unit is connected (either through its own, or through its own and other piconets) to a service or device of interest to the inquiring Bluetooth unit (or is itself such a device or offering such a service), the inquiring Bluetooth unit may choose to connect with that responding Bluetooth unit, or another or several responding Bluetooth units, each of which has access to the desired service or device type. The inquiring Bluetooth unit can then use information acquired from the INQUIRY message to generate a page message to the responding Bluetooth unit. Next, the responding Bluetooth unit responds by sending a message including the DAC of the responding Bluetooth unit to the inquiring Bluetooth unit. Upon reception of the response message, the inquiring Bluetooth unit transmits a FHS packet which contains selective connection data to connect to the responding Bluetooth unit. The responding Bluetooth unit will then transmit a DAC message to the inquiring Bluetooth unit, forming a connection. In accordance with one embodiment of the present invention, herein is presented a method for providing connection information in an ad-hoc network comprising the steps of broadcasting an inquiry message, from an inquiring node, to neighboring nodes, the inquiry message requesting connection information about accessible nodes. The inquiring node receiving a response from a neighboring node, the response containing connection information about the responding node and nodes which are accessible by the neighbor nodes. Lastly, determining whether to establish a network with the responding neighbor nodes using the connection information in the response.

Brief Description of the Several Drawings

The objects and advantages of the invention will be understood by reading the following detailed description in conjunction with the drawings in which:

FIG. 1 illustrates a Bluetooth piconet;

FIG. 2 illustrates a larger piconet, including a master and several slaves;

FIG. 3 illustrates an exemplary scatternet;

FIG. 4 illustrates an INQUIRY message packet;

FIG. 5 illustrates the signaling performed between two Bluetooth units for neighbor discovery and connection establishment;

FIG. 6 illustrates an INQUIRY RESPONSE message packet;

FIG's. 7 and FIG. 10 illustrate signaling between two nodes for establishing a selective connection in accordance with a first embodiment of the invention;

FIG. 8 illustrates the bit allocation of the redefined fields of an INQUIRY RESPONSE message packet; FIG. 9 illustrates a bit map example of the available bits from the redefined fields in an INQUIRY RESPONSE message packet;

FIG. 11 illustrates a list example of the available bits from the redefined fields in an INQUIRY RESPONSE message packet;

FIG's 12, 14, 15, 16, 18 and 19, illustrate signaling between two nodes for establishing a selective connection in accordance with a second embodiment of the invention;

FIG. 13 illustrates an INQUIRY message packet, modified with a first inquiry access code;

FIG. 17 illustrates an extended INQUIRY RESPONSE message, showing a bit allocation for redefined fields in the extension part of the extended INQUIRY RESPONSE message;

FIG. 20 illustrates an extended INQUIRY RESPONSE message, showing a bit allocation for redefined fields in the first (regular) and second (extension) part of the extended INQUIRY RESPONSE message;

FIG's 21, 23, 24, 25, 26 and 27 illustrate signaling between two nodes for establishing a selective connection in accordance with a third embodiment of the invention;

FIG. 22 illustrates an INQUIRY message packet, modified with a second inquiry access code;

FIG's 28, 30, 31, 32, 33 and 34 illustrate signaling between two nodes for establishing a selective connection in accordance with a fourth embodiment of the invention;

FIG. 29 illustrates an INQUIRY message packet, modified with a third inquiry access code;

FIG's 35, 37, 38, 39, 40 and 41 illustrate signaling between two nodes for establishing a selective connection in accordance with a fifth embodiment of the invention; FIG. 36 illustrates an INQUIRY message packet, modified with a fourth inquiry access code;

FIG. 42 illustrates several piconets, showing the number of hops from an inquiring Bluetooth unit, to a device offering a certain type of service or a device of a certain type;

FIG. 43 illustrates an example of embedding hop count information in an INQUIRY RESPONSE message, with redefined fields;

FIG. 44 illustrates an example of embedding hop count information in an extended INQUIRY RESPONSE message;

FIG. 45 illustrates an example of embedding hop. count information in a first and extended INQUIRY RESPONSE message;

FIG. 46 illustrate signaling between two nodes for establishing a selective connection in accordance with a sixth embodiment of the invention;

FIG. 47 illustrates an INQUIRY message packet, modified with a fifth inquiry access code;

FIG. 48 illustrates a first example of embedding hop count information in an INQUIRY RESPONSE message;

FIG. 49 illustrates a second example of embedding hop count information in an extended INQUIRY RESPONSE message;

FIG. 50 illustrates, as Table 3, the different types of inquiry access codes, their definitions, and examples of each;

FIG. 51 illustrates a block diagram of an arrangement in which the present invention can be carried out; and

FIG. 52 illustrates an exemplary set of apparatuses within which the arrangement of FIG. 51 can be implemented. Detailed Description of the Invention

The present invention is directed to ad-hoc networks. More particularly, the present invention is directed to obtaining information about available devices and/or services in ad-hoc networks.

In the following it is described that a node sends a request for connection information regarding services or device types. It is recognized that in the ad-hoc networking art in general, and Bluetooth in particular, that a node is associated with a physical object: a fax machine, computer; scanner, car radio, etc. These physical objects are herein referred to as devices. The present invention provides information regarding devices to inquiring nodes. Further in accordance with the present invention, the inquiring BLUETOOTH unit can request (or be given) information about "services" as well. As a service is not a physical object, it is technically not a "node." But, in order to access a service, the inquiring BLUETOOTH unit must access a node that either provides the service, or is a node connected to another node that can provide the service (and so on). Therefore, although not technically accurate to equate a "node" and "service, " for the purposes of the present invention, it is to be understood that a request for connection information regarding services, is the same as requesting information regarding services provided by nodes - because only through a node can the service be accessed.

Figure 7 illustrates signaling between two nodes for establishing a selective connection in accordance with a first embodiment of the invention.

Conventionally, when an inquiring Bluetooth unit broadcasts the INQUIRY message, it cannot indicate what services or device types it is interested in connecting with. As illustrated in figure 7, the inquiring Bluetooth unit broadcasts an INQUIRY message (1) to all neighboring nodes. The numbers in parentheses indicate the order in which a particular message is transmitted; that is, the relative timing of message transmissions that the inquiring and responding Bluetooth units broadcast or transmit. No "master" or slave" has been established between the nodes because no firm connection has been created between the nodes. However, the transmission protocol is setting up the inquiring Bluetooth unit to be the master, and the responding Bluetooth unit to be the slave.

A neighboring Bluetooth unit which receives an INQUIRY message and responds by sending an INQUIRY RESPONSE message is referred to as a responding Bluetooth unit (RBTU). In accordance with a first embodiment of the present invention, a responding Bluetooth unit uses the Class of Device field, the AM_ADDR field, the Undefined field, and the NAP field in the INQUIRY RESPONSE message to provide information about accessible services or device types. It should be understood that redefining any combination of a subset of these three fields would not alter the principles of this embodiment, just reduce the number of redefined bits. However, in this particular embodiment, the Class of Device field has to be one of the redefined fields, which will be understood by further description of the embodiment.

Figure 8 illustrates the bit allocation of the redefined fields of an INQUIRY RESPONSE message packet. In figure 8, the Undefined field (shown by (1)), the NAP field (2), the Class of Device field (3), the AM_ADDR field (4) have been redefined to convey connection information about available services or device types. "Redefine" means the bits allocated for the purpose indicated by the field name (AM_ADDR, for example), have now been made available to convey connection information. Instead of conveying the AM_ADDR data of the responding Bluetooth unit, the bits convey connection information.

Within conventional INQUIRY RESPONSE messages, the Class of Device field is broken into two sections. The first section comprises the first 2 bits, and the latter section contains the latter 22 bits. The first section is designed to indicate which one of four independent formats the remainder of the Class of Device field follows. Presently, only one of the four formats is defined and it indicates which class the responding device belongs to. Within the presently specified format code, the remaining 22 bits are divided among three subclasses: service classes (networking, capturing, audio, telephony, etc.), major device class (computer, phone LAN, access point, peripheral, etc.) and minor service class (detailed subclasses of major device class, e.g. desktop workstation, laptop, palm sized PC/PDA, etc., if the major subclass is "computer").

Although it is preferred to use one of the undefined codes (in the first two bits of the Class of Device field) to indicate the INQUIRY RESPONSE message contains connection information about services or device types, the currently defined code could be used as well. The remaining 22 bits of the Class of Device field will then be used to convey information about accessible services or device types.

The AM_ADDR field has three bits that can be used to convey information about accessible services or device types, since the AM_ADDR field in an FHS packet is only used in the PAGE procedure and not in an INQUIRY RESPONSE message. The two Undefined bits can also be used to convey information about accessible services or device types. In addition, the NAP field (16 bits) can be used also, bringing the total number of available bits to convey information about accessible services or device types to 43.

In accordance with the present invention, the first two bits of the Class of Device field are used by the responding Bluetooth unit to inform the inquiring Bluetooth unit that the responding Bluetooth unit is returning an INQUIRY RESPONSE message with redefined fields which indicates what services or device types the responding Bluetooth unit is connected to or represents itself. See Table 1, which illustrates the bit allocation for each field. Table 1

In accordance with the present invention, the 43 bits of the redefined fields will contain information about accessible services or device types using a bit map. In Table 1, the total shows 43, because the 2 bits of the Class of Device format bits are not used to convey connection information. Figure 9 illustrates an exemplary bit map using the available bits from the redefined fields in an INQUIRY RESPONSE message packet.

Each bit of the bit map represents whether a service or device type is accessible (e.g. a particular bit being set to one) or not accessible (e.g, a particular bit being set to zero) by the responding Bluetooth unit. For example, bit 22 can represent Network Access Point services; bit 30 can represent Application services. These are examples only, and as such, are not meant to limit the invention. . The bits are numbered from right to left.

In figure 9, there are two columns; the left column is entitled "Available Bits" and the right column is entitled "Definition." The "Available Bits" column shows the 45 available bits grouped together, in one continuous string. In any particular row, the two left-most bits represent the bit contribution from the Undefined field. The next 16 bits are those from the NAP field. The next 24 bits are those from the Class of Device field. The last three bits are those from the AM ADDR field. It will be recognized that to be able to cope with future growth of the number of services or device types an available bit should be allocated to represent the general service class "other services" in the case of reporting about available services. Similarly, when reporting about available device types, an available bit should be allocated to represent the general device type class "other device types." In either situation, the same available bit might be allocated for this use, or it could be different available bits for services and device types.

In accordance with the present invention, the first two bits of the Class of Device field (bits 4 and 5) are reserved to indicate an INQUIRY RESPONSE message that contains connection information. These two bits are shown in bold in figure 9. This leaves 43 bits available to convey connection information.

In figure 9, the first line shows a printer service, fax service, scanner service, network access point service and application service, as being described in the first bit map. An application service is the service of allowing a customer to pay to use an application program residing in the application service provider's computer. Network access point service is the service of allowing a Bluetooth unit to access some network at some point in the network. Note that a total of five bits have been set to "1." A "1" indicates the service or device type is present, i.e. connection information is known about it. In the second row, the bit for the network access point service is underlined, and in the third line, the bit for the application service is underlined.

Because a bit map allows the responding Bluetooth unit to inform the inquiring Bluetooth unit about the accessibility or non-accessibility of many different services or device types in a dense format (only one bit per service or device type), it is efficient. However, because each service or device type is allocated one bit, the bit map is limited to the number of available bits. In this case, information concerning a maximum of 43 different device types or services can be relayed to the inquiring Bluetooth unit.

The accessible services or device types are those services or device types that are accessible to the responding Bluetooth unit. Typically, this information is known to the responding Bluetooth unit well before an inquiring Bluetooth unit INQUIRY message is broadcast. Information about accessible services and device types could be distributed in a scatternet using one of the existing protocols for publishing, discovery and location of services, such as the Service Discovery Protocol (SDP) of Bluetooth, the Service Location Protocol (SLP, RFC2608), the Simple Service Discovery Protocol (SSDP) of UPnP (Universal Plug and Play), or the Extended Service Discovery Protocol which is an extension of SDP based on UPnP. The accessible device types could be derived from the service information or distributed via similar means. To reduce the load in the network these mechanisms can use the concept of proxies or agents which hold service information on behalf of the service publishers. Other Bluetooth units can then request this information from an agent or proxy or an agent or proxy can transfer information triggered by some specified event.

Referring again to figure 7, the INQUIRY RESPONSE message (2) occurs after the INQUIRY message. After the inquiring Bluetooth unit receives the INQUIRY RESPONSE message, from neighboring Bluetooth Units, the inquiring Bluetooth unit decides which, if any, of the responding Bluetooth units to attempt to connect to (assuming that any or more than one has responded). Assuming that the responding Bluetooth unit indicates that the desired device type or service is accessible (implying that either the responding Bluetooth unit itself or another node reachable through the same ad-hoc network provides the desired service or is of the desired device type), the inquiring Bluetooth unit responds to the INQUIRY RESPONSE message by transmitting a PAGE message (3) to the specific responding Bluetooth unit. The responding Bluetooth unit that receives a PAGE message directed to it responds by transmitting an identical message (i.e. including its own DAC) (4) to the inquiring Bluetooth unit. The inquiring Bluetooth unit receives that response message from the responding Bluetooth unit and transmits a message consisting of a FHS packet (5) to the responding Bluetooth unit. The responding Bluetooth unit, upon reception of the FHS packet from the inquiring Bluetooth unit responds by transmitting another message consisting of its own DAC, (6), which, when received by the inquiring Bluetooth unit, completes the connection forming process, and the two Bluetooth units are formally connected.

For purposes of illustration only, figure 7 shows the inquiring Bluetooth unit as attempting to connect to a single responding Bluetooth unit. This in no way limits the invention, as the number of responding Bluetooth units an inquiring Bluetooth unit can attempt to connect to is theoretically unlimited.

Figure 10 illustrates signaling between two nodes for establishing a selective connection in accordance with a first embodiment of the invention.

The embodiment of the invention described in reference to figure 10 is similar to that as described in figure 7, except that the information about accessible services or device types is encoded in a list format, instead of a bit map. The bits will list predefined identities of accessible services or device types. Such standardized service identities already exist to be used in conjunction with the service information distribution protocols mentioned above.

Figure 11 illustrates a list example of the available bits from the redefined fields in an INQUIRY RESPONSE message packet. In the list, a particular number of consecutive bits are used to list accessible services or device types. In figure 11, eight bits are used, by way of example only. Again, the first two bits of the Class of Device field (shown in bold) have been set to "1" to indicate that the responding Bluetooth unit has connection information for the inquiring Bluetooth unit about certain services or device types, i.e. to indicate the format code of the INQUIRY RESPONSE message.

In the first line, the first and second nibble (numbered from left to right, for illustration purposes only) have been underlined to represent the list identity (0010 1001) for printer services. In nibbles three and four, the list identity of the fax service (1000 0100) is shown. Following that, the list identity of the application service (0011 0000), scanner service (0011 0001) and finally, network access point services (0110 1001) are shown. The second row shows the identity of the network access point service (0110 1001) alone.

In figure 11, by way of example only, the second row shows the service identity of a network access point service placed in nibbles 9 and 10. Note that this is the first available identity field space; if there is only one service identity to report, it will be placed here. The responding Bluetooth unit will place the service or device type identity in the most convenient position, not in any specific one. If there were two service identities, they would be placed in nibbles 9 and 10, and then nibbles 7 and 8, respectively. This is the situation shown in figure 11, row three.

The examples just shown are merely an illustration of how a list might be constructed in this embodiment. Although figure 11 illustrates 8 bits defining the identity of the service or device type it will be recognized that other bit field sizes can be used to define identities. The number of services or device type identities that can be transmitted at once is limited to the number of available bits divided by the number of bits used to define an identity. In this example, 43 divided by 8, yields 5 identities for each INQUIRY RESPONSE message, plus 3 extra bits.

There are only 2⁸ different identities available to be defined because each identity uses 8 bits. This yields 256 identities. 254 would be used, because the identity of 1111 1111 would be used to indicate "other services," or other "device types." The all-zero identity, or 0000 0000, can not be used because the superfluous bits after the last item should be set to zero to distinguish them from list items (i.e. service or device type identities).

If the size of the identity is defined to be 8 bits, there will be 3 bits leftover. The unused bits can define a flag to indicate that more services or device types are available or known about by the responding Bluetooth unit. Additionally, services will only be reported once; if the responding Bluetooth unit knows of, or is connected to 2 or more printing services, for example, it will report knowledge of being connected to one only. Note an important difference in using a bit map versus lists in the first embodiment of the invention: The range of possible services or device types to report about is much larger if a list format is used (254 different services or device types in this example) than if a bit map is used (42 different services or device types in this example, plus the bit for "other services" or "other device types"). On the other hand the advantage of the dense bit map format is that it can report about more services or device types in the same INQUIRY RESPONSE message (42 in this example) than the list format (only 5 in this example).

Figure 12 illustrates signaling between two nodes for establishing a selective connection in accordance with a second embodiment of the invention.

In accordance with the second embodiment of the present invention, the INQUIRY message contains information as to what connection information the inquiring Bluetooth unit is seeking. This indication is accomplished by utilizing a new access code placed in the INQUIRY message. The first inquiry access code is referred to as an accessible services general inquiry access code (AS-GIAC). Figure 13 illustrates an INQUIRY message packet, modified with a first inquiry access code. Use of the first inquiry access code signifies that the inquiring Bluetooth unit is interested in the services that are accessible via the neighboring Bluetooth units, including service provided by the neighboring Bluetooth units themselves.

In accordance with the present invention, upon receipt of an INQUIRY message containing an AS-GIAC, the neighboring Bluetooth units will respond regardless of whether they are connected to any services or device types or not, and regardless of the types of services or devices, or how many they are connected to.

As with the first embodiment of the invention, there are several ways in which to transfer the useful connection information from the responding Bluetooth unit to the inquiring Bluetooth unit in the second embodiment. The first is by redefining the fields in the INQUIRY RESPONSE message, as was discussed previously. The same fields can be redefined, in the same manner, with the exception of the Class of Device field. Here, it is not necessary to use the first two bits to indicate the special format: The reason for this is because use of the AS- GIAC, in the INQUIRY message, indicates that the returned INQUIRY RESPONSE is going to be providing the useful connection information. Therefore, instead of only 43 available bits, there will be 45 available bits. See Table 2. In figure 9, the INQUIRY RESPONSE IS shown in the second (2) message.

Table 2

Field Name Bit Allocation

Class of Device

-Format 2

-Data 22

AM_ADDR 3

Undefined Field 2

NAP 16

Total: 45

As described above in connection with figures 8 and 8A connection information can be conveyed in the INQUIRY RESPONSE message using either a list or a bit map.

In figure 12, a bit map is used to convey connection information from the responding Bluetooth unit to the inquiring Bluetooth unit, about available services, in redefined fields of an INQUIRY RESPONSE message.

Figure 14 illustrates signaling between two nodes for establishing a selective connection in accordance with a second embodiment of the invention.

In figure 14, the first inquiry access code in the INQUIRY message is an AS- GIAC, and a list is used to convey connection information from the responding Bluetooth unit to the inquiring Bluetooth unit, about available services, in redefined fields of an INQUIRY RESPONSE message. The method of using a list to convey connection information with an AS- GIAC, according to the second embodiment of the invention, is the same as has been discussed with the first embodiment. However, instead of there being 43 bits available to convey connection information in the INQUIRY RESPONSE message, there will now be 45 bits available.

Figures 15 and 16 illustrate signaling between two nodes for establishing a selective connection in accordance with a second embodiment of the invention.

The second way to convey useful connection information to the inquiring Bluetooth unit from the responding Bluetooth unit, in the second embodiment of the invention, is to use an extended INQUIRY RESPONSE message. The regular INQUIRY RESPONSE message is just one time slot long. An extended INQUIRY RESPONSE message would preferably be an integer number of time slots longer, e.g. one time slot longer, making the extended INQUIRY RESPONSE twice as long as a regular one. In the first time slot, i.e. the first part of the extended INQUIRY RESPONSE message, the fields of the regular INQUIRY RESPONSE message would be included, while the second time slot, i.e. the extension part of the extended INQUIRY RESPONSE message, could be used for connection information. Using an extended INQUIRY RESPONSE message provides a great deal of available bits to provide useful connection information.

In figure 15 a bit map is used to encode connection information in the extension part of the INQUIRY RESPONSE message.

In figure 16 a list is used to encode connection information in the extension part of the INQUIRY RESPONSE message.

Figure 17 illustrates an extended INQUIRY RESPONSE message, showing the bit allocation for redefined fields in the extension part of the extended INQUIRY RESPONSE message. The entire extended portion of the INQUIRY RESPONSE message is available for encoding data, either as a bit map, or as a list. The previous discussion of bit usage with respect to figures 9 and 11 also pertain to this embodiment of the invention. The difference being the number of services or device types the responding Bluetooth unit could report about, because of the increased number of available bits (144).

Figures 18 and 19 illustrate signaling between two nodes for establishing a selective connection in accordance with a second embodiment of the invention.

The third way to convey useful connection information to the inquiring Bluetooth unit from the responding Bluetooth unit, in the second embodiment of the invention, is to use an extended INQUIRY RESPONSE message along with redefining specific fields of the first (regular) part of the INQUIRY RESPONSE message. The same fields that were discussed in the first way to convey useful connection with an AS-GIAC will be redefined here. This third method, the combination of the first two, yields a tremendous amount of available bits to convey useful connection information.

In figure 18 a bit map is used to encode connection information in the first (regular) and second (extension) part of the INQUIRY RESPONSE message.

In figure 19 a list is used to encode connection information in the first (regular) and second (extension) part of the INQUIRY RESPONSE message.

Figure 20 illustrates an extended INQUIRY RESPONSE message, showing a bit allocation for redefined fields in the first (regular) and second (extension) part of the extended INQUIRY RESPONSE message. Note that by redefining the fields of the first (regular) part of the INQUIRY RESPONSE message, a total of 189 bits are available for either a bit map, or a list.

Referring again to figures 12, 14, 15, 16, 18 and 19, if the responding Bluetooth unit indicates that a desired service or device type is accessible (implying that either the responding Bluetooth unit itself, or another node reachable through the same ad-hoc network, provides the desired service or is of the desired device type), the inquiring Bluetooth unit will initiate the PAGE procedure in a similar manner to that described in connection with figure 7. Figures 21, 23, 24, 25, 26 and 27 illustrate signaling between two nodes for establishing a selective connection in accordance with a third embodiment of the invention.

The third embodiment of the invention for providing useful connection information to an inquiring Bluetooth unit, is to change the INQUIRY message to include a second inquiry access code (IAC) that indicates that the inquiring Bluetooth unit desires to receive information about accessible device types. The second inquiry access code is known as accessible type of device general inquiry access code (ATD-GIAC).

Figure 22 illustrates an INQUIRY message packet, modified with a second inquiry access code.

Use of the second inquiry access code signifies that the inquiring Bluetooth unit is interested in the devices that are accessible via the neighboring Bluetooth units (including the neighboring Bluetooth units themselves) and that all neighboring Bluetooth units that can "hear" the inquiring Bluetooth unit will respond. The neighboring Bluetooth units will respond regardless of whether they are connected to any services or device types or not, and regardless of the services or device types, or how many they are connected to.

In figure 21 a bit map is used to encode connection information in the INQUIRY RESPONSE message field.

Thus, connection information about device types can also be shared with an inquiring Bluetooth unit. All the same features described regarding redefining fields in an INQUIRY RESPONSE message, using an extended INQUIRY RESPONSE message, or a combination of the two, and then encoding the data through a bit map or lists, according to the second embodiment of the invention, are available for providing useful connection information about device types in the third embodiment of the invention.

In figure 23 a list is used to encode connection information in the INQUIRY RESPONSE message field. In figure 24 a bit map is used to encode connection information in an extension part of the INQUIRY RESPONSE message field.

In figure 25 a list is used to encode connection information in the extension part of the INQUIRY RESPONSE message field.

In figure 26 a bit map is used to encode connection information in the extension part of the INQUIRY RESPONSE message field and the certain redefined fields in the first (regular) part of the INQUIRY RESPONSE message fields.

In figure 27 a list is used to encode connection information in the extension part of the extended INQUIRY RESPONSE message field and the certain redefined fields in the first (regular) part of the INQUIRY RESPONSE message.

Referring again to figures 21, 23, 24, 25, 26 and 27, if the responding Bluetooth unit indicates that a desired service or device type is accessible (implying that either the responding Bluetooth unit itself or another node reachable through the same ad-hoc network, provides the desired service or is of the desired device type), the inquiring Bluetooth unit will initiate the PAGE procedure in a similar manner to that described in connection with figure 7.

Figures 28, 30, 31, 32, 33 and 34 illustrate signaling between two nodes for establishing a selective connection in accordance with a fourth embodiment of the invention.

The fourth embodiment of the invention for providing useful connection information to an inquiring Bluetooth unit, is to change the INQUIRY message to include a third inquiry access code (IAC) that specifies which types of services (i.e. a subset of all types of services) the inquiring Bluetooth unit desires to receive information about. The third inquiry access code is known as a dedicated accessible services general inquiry access code (D AS-GIAC). There may be many DAS- GIAC's defined, each associated with a certain type of service (i.e. a certain subset of all types of services).

Figure 29 illustrates an INQUIRY message packet, modified with a third inquiry access code. Use of the third group of inquiry access codes signifies that the inquiring Bluetooth unit is interested in a smaller subset of services that are accessible via the responding Bluetooth unit and that all neighboring Bluetooth inquiring units that can "hear" the inquiring Bluetooth unit will respond. In this case, any neighboring Bluetooth unit that can hear the INQUIRY message will respond, but, will only pass along useful connection information regarding the type of specific service that is indicated by the DAS-GIAC. The DAS-GIAC will indicate a subset of the universal group of services that the inquiring Bluetooth unit is interested in.

The use of DAS-GIAC in the INQUIRY message provides the ability to reduce the size of the bit-map (e.g. in order to make it always fit into an un-extended INQUIRY RESPONSE message) or the list. Each DAS-GIAC requests a certain category of accessible services (e.g. gateway services, printer services, or more general office services, etc.), which allows for greater efficiency in bit usage when encoding data about accessible services.

In figure 28 a bit map is used to encode connection information in redefined fields of an INQUIRY RESPONSE message.

In figure 30 a list is used to encode connection information in the certain redefined fields in the INQUIRY RESPONSE message.

In figure 31 is a bit map is used to encode connection information in the extension part of the INQUIRY RESPONSE message.

In figure 32 a list is used to encode connection information in the extension part of the INQUIRY RESPONSE message.

In figure 33 a bit map is used to encode connection information in the extension part of the extended INQUIRY RESPONSE message and the certain redefined fields in the first (regular) part of the INQUIRY RESPONSE message.

In figure 34 a list is used to encode connection information in the extension part of the extended INQUIRY RESPONSE message and the certain redefined fields in the first (regular) part of the INQUIRY RESPONSE message. Thus, connection information about specific service types can be shared with an inquiring Bluetooth unit. All the same features described regarding redefining fields in an INQUIRY RESPONSE message, using an extended INQUIRY RESPONSE message, or a combination of the two, and then encoding the data through a bit map or a list, according to the second embodiment of the invention, are available for providing useful connection information about specific services in the fourth embodiment of the invention.

Referring again to figures 28, 30, 31, 32, 33 and 34, if the responding Bluetooth unit indicates that a desired service or device type is accessible (implying that either the responding Bluetooth unit itself or another node reachable through the same ad-hoc network provides the desired service or is of the desired device type), the inquiring Bluetooth unit will initiate the PAGE procedure in a similar manner to that described in connection with figure 7.

Figures 35, 37, 38, 39, 40 and 41 illustrate signaling between two nodes for establishing a selective connection in accordance with a fifth embodiment of the invention.

The fifth embodiment of the invention for providing useful connection information to an inquiring Bluetooth unit, is to change the INQUIRY message to include a fourth inquiry access code (IAC) that specifies which types of devices (a subset of all device types) the inquiring Bluetooth unit desires to receive connection information about. The fourth inquiry access code is known as a dedicated accessible types of devices general inquiry access code (DATD-GIAC). There may be many DATD-GIAC's defined, each associated with a certain device type or category of device types.

Figure 36 illustrates an INQUIRY message packet, modified with a fourth inquiry access code.

Use of the fourth group of inquiry access codes signifies that the inquiring Bluetooth unit is interested in very specific device types that are accessible via the responding Bluetooth unit (including the responding unit itself) and that all neighboring Bluetooth inquiring units that can "hear" the inquiring Bluetooth unit will respond. In this case, any neighboring Bluetooth unit that can hear the INQUIRY message will respond, but will only pass along useful connection information regarding the specific device types that are indicated by the DATD- GIAC. The DATD-GIAC will indicate a subset of the universal group of devices that the inquiring Bluetooth unit is interested in.

The use of DATD-GIAC in the INQUIRY message provides the ability to reduce the size of the bit-map (e.g. in order to make it always fit into an un-extended INQUIRY RESPONSE message) or the list. Each DATD-GIAC requests a certain category of accessible device types. Examples are computers, computer peripherals, networking devices, network access points, telephones and fax machines, car accessories, hi-fi devices, household equipment, etc. which allows for greater efficiency in bit usage when encoding data about accessible device types.

In figure 35 a bit map is used to encode connection information in redefined fields of an INQUIRY RESPONSE message.

In figure 37 a list is used to encode connection information in redefined fields of an INQUIRY RESPONSE message.

In figure 38 a bit map is used to encode connection information in the extension part of the INQUIRY RESPONSE message.

Figure 39 a list is used to encode connection information in the extension part of the INQUIRY RESPONSE message.

In figure 40 a bit map is used to encode connection information in the extension part of the extended INQUIRY RESPONSE message and redefined fields in the first (regular) part of the extended INQUIRY RESPONSE message.

In figure 41 a list is used to encode connection information in the extension part of the extended INQUIRY RESPONSE message and redefined fields in the first (regular) part of the extended INQUIRY RESPONSE message.

Thus, connection information about specific device types can be shared with an inquiring Bluetooth unit. All the same features described regarding redefining fields in an INQUIRY RESPONSE message, using an extended INQUIRY RESPONSE message, or a combination of the two, and then encoding the data through a bit map or a list, according to the second embodiment of the invention, are available for providing useful connection information about specific device types in the fifth embodiment of the invention.

Referring again to figures 35, 37, 38, 39, 40 and 41, if the responding Bluetooth unit indicates that a desired service or device type, is accessible (implying that either the responding Bluetooth unit itself or another node reachable through the same ad-hoc network provides the desired service or is of the desired device type), the inquiring Bluetooth unit will initiate the PAGE procedure in a similar manner to that described in connection with figure 7.

In all of the first five embodiments of the invention, certain fields from an INQUIRY RESPONSE message have been redefined. It is to be understood that some or all of the fields may be used, and that the use of all four fields is for example purposes only, and is not meant not limit the spirit or scope of the invention.

Furthermore, in all of the first five embodiments of the invention, another feature can be added that provides greater detail of the accessible services or device types, at the expense of some available bits. That is, the responding Bluetooth unit can provide hop count information to the inquiring Bluetooth unit, regarding each indicated accessible service or device type. Each service or device type indicated as accessible would have a hop count associated with it in the INQUIRY RESPONSE message. The hop count lets the inquiring Bluetooth unit know the number of hops - or connections - from the responding Bluetooth unit to the closet device offering a certain service or the closest device of a certain type. For instance, a hop count of 1 means that the device offering the associated service or the device of the associated type is connected directly to the responding Bluetooth unit (but not to the inquiring Bluetooth unit). A hop count of 0, indicates that the responding Bluetooth unit is itself offering the service or is itself of the associated device type. Figure 42 illustrates several piconets, showing the number of hops from an inquiring Bluetooth unit, to a device offering a certain type of service or a device of a certain type. In Figure 42, there are two piconets joined together. M(l) is the master of piconet 1, and M(2) is the master of piconet 2. In connection with M(l) are slaves S(l A), S(1B) and S(1C). Connected to M(2) are slaves S(2A), S(2B) and S(2C). Note that slave S(1C) and S(2A) are the same Bluetooth unit. In this scatternet, slave S(1A) has connection information about slave S(1B) and slave S(2B), that it can provide to the inquiring Bluetooth unit (IBTU). Path 1, the number of connections between S(1A) and S(1B), yields a hop count of 2. The hop count is determined by the connection between S(l A) and M(l), and the connection between M(l) and S(1B). Path 2, the number of connections between S(l A) and S(2B), yields a hop count of 4. The hop count is determined by the connection between S(l A) and M(l), M(l) and S(1C/2A), S(1C/2A) and M(2), and M(2) and S(2B).

A hop count can be represented with 1 or more bits. The number of bits used is a trade-off between efficient bit usage and the level of detail of the information. The number of bits used to represent hop count information determines the largest hop count that can be represented. For instance, if a hop count is represented by two bits, hop counts of 0-3 can be represented. If the real hop count is more than 3 hops, it would still be represented by a hop count of value of 3. So this would effectively mean "3 or more hops." The case when a hop count is represented by only 1 bit is particularly interesting. Partly because it does not use much space in the INQUIRY RESPONSE message. But more important is that such a simple hop count parameter can be set by a responding Bluetooth unit without having to retrieve the actual hop count in the network. It is not at all certain that the hop count to a service offering node or a node of a certain device type is possible to retrieve. This depends on the protocols that are supported in the network, e.g. the properties of the usual routing protocol. But the information needed to set a simple 1 bit hop count parameter is always available to the responding Bluetooth unit. This is because a 1 bit hop count parameter can only represent 2 different values: 0 hops or " 1 or more hops." And since 0 hops means "the responding Bluetooth unit itself and "1 or more hops" means "any other node in the scatternet," the responding Bluetooth unit will always know which of these two values to choose.

Figure 43 illustrates an example embedding hop count information in an INQUIRY RESPONSE message with redefined fields.

Here, the hop count information has been assigned to the NAP field, which has 16 bits. It could also have been assigned to the Undefined Field, the Class of Device Field, or the AM_ADDR field. In any case, the number of hop counts would be limited to the number of available bits in the particular data field. However, it is also possible to have assigned the hop count to any number of bits, anywhere in the available data fields. For example, the 3 bits of AM_ADDR, and the first 2 bits of Class of Devices. It is for example purposes only that the hop count has been assigned to the NAP field, and not meant to limit or constrain the invention.

When a bit map is used to encode accessible services or device types, each predefined service or device type in the bit map can have 2 bits instead of 1 assigned to it. One of the bits would indicate whether the particular service or device type is accessible through the responding Bluetooth unit or not; the other bit would represent the hop count of "0" or "1 or more hops" (provided that the first bit indicates that the particular service or device types is available. If the first bit indicates that the particular service or device types is not accessible, the hop count bit will have no meaning.

In the case a list is used to encode accessible services or device types, each item will consist of a service (or device type) identity followed by a hop count parameter of one or more bits.

Figure 44 illustrates an example of embedding hop count information in an extended INQUIRY RESPONSE message.

Here, the hop count information has been given 16 bits in the extended INQUIRY RESPONSE message. The attribution of bits is for example purposes only, and is not meant to limit the scope or spirit of the invention, in any manner whatsoever.

Figure 45 illustrates an example of embedding hop count information in a first and extended INQUIRY RESPONSE message.

Here, the responding Bluetooth unit is using a first and extended INQUIRY RESPONSE message to respond to the inquiring Bluetooth unit's query regarding services or device types. In this situation, the hop count information has been attributed to the first part of the INQUIRY RESPONSE message, and given 16 bits. Again, the number of bits is not materially limiting, nor is its location. The bits could also have been located in the extension part of the INQUIRY RESPONSE, in any position of the available 144 bits, and given any sufficient number to relay the hop count data.

Figure 46 illustrate signaling between two nodes for establishing a selective connection in accordance with a sixth embodiment of the invention.

The sixth embodiment of the invention for providing useful connection information to an inquiring Bluetooth unit, is to change the INQUIRY message to include a fifth inquiry access code (IAC) that specifies which services or device types the inquiring Bluetooth unit desires to communicate with. The fifth inquiry- access code is known as an accessibility based dedicated inquiry access codes (A- DIAC). There may be many A-DIAC's defined, each associated with a certain type of service or device type or category of device types.

Figure 47 illustrates an INQUIRY message packet, modified with a fifth inquiry access code.

Use of the fifth group of inquiry access codes signifies that the inquiring Bluetooth unit is interested in very specific services or device types that are accessible via the responding Bluetooth unit and that only those neighboring Bluetooth inquiring units that can "hear" the inquiring Bluetooth unit and have access to the specific types of services or device types will respond, and subsequently are known as responding Bluetooth units. Referring again to figure 46, if a Bluetooth unit responds to an INQUIRY message containing an A-DIAC, it thereby implicitly indicates that a desired service or device type is accessible, (implying that either the responding Bluetooth unit itself or another node reachable through the same ad-hoc network provides the desired service or is of the desired device type). The inquiring Bluetooth unit will then initiate the PAGE procedure in a similar manner to that described in connection with figure 7. It should be noted that in this embodiment the INQUIRY RESPONSE message does not have to be modified.

An additional optional feature of the sixth embodiment of the invention (i.e. the A-DIAC embodiment) is that a responding Bluetooth unit could include the hop count to the closest device offering the type of service associated with the A-DIAC or the closest device of the type associated with the A-DIAC. In order to include the hop count information, the INQUIRY RESPONSE message has to be modified. This could be done by redefining a field in the regular INQUIRY RESPONSE message or extending the INQUIRY RESPONSE message. Any of at least four different fields could be redefined to carry the hop count information: the Class of Device field, the AM_ADDR field, the Undefined field, or the NAP field. Only one has to be modified. If an extended INQUIRY RESPONSE message is used, the first part is used to carry the fields of a regular INQUIRY RESPONSE message, while the hop count information is placed in the extension part.

As in the first five embodiments, the case when only a single bit is used to represent hop count is of particular interest. Partly because the space required in the INQUIRY RESPONSE message is small, but more importantly because the information of whether the hop count is "0" or "1 or more hops" is always available to the responding Bluetooth unit. In this sixth embodiment the size of the total hop count information may be very small, since the response to an A-DIAC INQUIRY RESPONSE message only has to include a single hop count parameter. If this hop count parameter is only 1 or 2 bits long, the undefined field in the INQUIRY RESPONSE message can be used to encode the hop count parameter and if the hop count parameter is 1-3 bits long the AM_ADDR field can be used to encode the hop count parameter. Since both these fields are unused in the regular INQUIRY RESPONSE message, all the regular information of the INQUIRY RESPONSE message is left untouched in both these cases.

Figure 48 illustrates a first example of embedding hop count information in an INQUIRY RESPONSE message.

In Figure 48, the hop count information has been embedded in the Class of Device field. There are 24 bits available, but only 5 were allocated to encode the hop count information. With 5 bits allocated, the hop count information can represent 0 to 31 hops. As mentioned previously, the number of bits, and placement (subject to the following fields: Undefined, NAP, Class of Device and AM_ADDR) are completely arbitrary, and the example shown is not meant to limit in scope or spirit the invention.

Figure 49 illustrates a second example of embedding hop count information in an extended INQUIRY RESPONSE message.

In Figure 49, the hop count information has been embedded in an extended INQUIRY RESPONSE message. This yields a tremendous number of available bits (144) in which to convey hop count information. The actual number of bits can be much less, and the location within the extended INQUIRY RESPONSE message field is completely arbitrary.

DIAC's and A-DIAC'S may be used in a two-stage procedure: First a DIAC INQUIRY message is sent; but, if no reply is received (i.e. no such device is directly reachable), an INQUIRY message with the corresponding A-DIAC is sent to determine if there are any indirectly reachable devices of the desired type. The responding Bluetooth unit then replies with an INQUIRY RESPONSE message that can include the hop count to the closest device of the requested type. A hop count of zero would indicate that the responding Bluetooth unit is itself of the requested type. Note that if the hop count is included in the INQUIRY RESPONSE message, the two-stage procedure is not needed, since the hop count in the response (to an INQUIRY message containing an A-DIAC) would indicate whether the responding Bluetooth unit is of the requested device type (i.e. with a hop count of 0) or whether it is a Bluetooth unit through which devices of the requested type are accessible.

Additionally, there is another feature that can optionally be included in all embodiments of the invention. A responding Bluetooth unit that has collected the accessible service or device type information can then, automatically or via user interaction, connect (using the PAGE procedure) to one of the Bluetooth units that indicates that the requested service or device type is accessible. For example, this could be the responding Bluetooth unit that indicates the smallest hop count to a node offering the requested service or to a node of the requested device type, if hop counts are included in the INQUIRY RESPONSE message from the responding Bluetooth unit. If the inquiring Bluetooth unit is interested in several different services, or device types, it can choose to establish connections to a number of the responding Bluetooth units in order to get access to the whole range of requested services (or device types). These are just examples of the possible ways in which an inquiring Bluetooth unit can connect to a responding Bluetooth unit, or other Bluetooth unit that offers access to the desired service or to a Bluetooth unit of a certain device type. As such, these examples are no meant to limit the scope and/or spirit of the invention, as there are innumerable ways for an inquiring Bluetooth unit to connect to other Bluetooth units.

Figure 50 illustrates, as Table 3, the different types of inquiry access codes, their definitions, and examples of each.

FIG. 51 illustrates a block diagram of a Bluetooth arrangement in which the present invention can be carried out.

The Bluetooth arrangement of figure 51 is shown as two figures. The first is transceiver 130, which comprises processor 134, transmitter 132, receiver 133, diplexer 131 (note that element 131 could alternatively be a duplexer, switch, circulator, Magic T, etc., all of which allow RF energy to travel one path and not the other at specific times), antenna 135, waveguides 143A and 143B, and data path 144. The second shows greater detail of processor 134, which is comprised of memory 136, floppy drive 137, I/O buffer 138, datapath 144, microprocessor 139, hard drive 140, and data bus 141. The hard drive 140 and floppy drive 137 are optional, depending upon the unit the transceiver 130 is contained in.

The Bluetooth operating system is a program contained in memory 136. The Bluetooth operating system determines how the transceiver communicates to other Bluetooth nodes. Microprocessor 139 executes the program steps contained within memory 136, in a manner that is well known in the art. Floppy drive 137 and hard drive 140 are optional, and may not be present in many Bluetooth arrangements, though, in some these components will be required. Input/Output (I/O) buffer 138 transmits and receives data to and from the transmitter 132 and receiver 133 portions of the transceiver 130. It does this via data path 144. The output of the transmitter 132 is connected to waveguide 143A, which connects to diplexer 131, the output of which is connected to antenna 135. The receiver 133 is connected via a waveguide 143B, which is also connected to diplexer 131.

Use of a diplexer in this arrangement is well known in the art. As discussed previously, there are several different circuits that provide the function of a diplexer. The diplexer 131 allows RF energy to pass from the transmitter 132 to the antenna 135, without harming the receiver 133 (by overloading its input circuitry). Similarly, the diplexer 131, allows the received RF signal to be directed to the receiver 133, without allowing any RF energy to leak from the transmitter to the receiver.

FIG. 52 illustrates an exemplary set of apparatuses within which the arrangement of FIG. 51 can be implemented.

In figure 52 there is shown a car stereo 541, a network access point 543, a refrigerator 542, a PDA 545 and a printer 544.

Although the inventive solutions have been described in the context of Bluetooth technology, they are applicable to wireless ad-hoc network technologies in general. The concept of transferring accessibility information concerning services and device types during the neighbor discovery procedure is applicable to almost any wireless ad-hoc network technology, although the specific details of how the information can be included in the response message, of course, do not apply to other technologies than Bluetooth.

The embodiments described above are merely given as examples and it should be understood that the invention is not limited thereto. It is of course possible to embody the invention in specific forms other than those described without departing from the spirit of the invention. Further modifications and improvements which retain the basic underlying principles disclosed and claimed herein, are within the spirit and scope of this invention.

Claims

Claims:

1. In an ad-hoc network a method for providing connection information comprising the steps of: broadcasting an inquiry message, from an inquiring node, to neighboring nodes, the inquiry message requesting connection information about accessible nodes; receiving a response by the inquiring node from a responding neighboring node, the response containing connection information about the responding neighboring node and nodes which are accessible by the responding neighboring node; and determining whether to establish connections with the responding neighboring node using the connection information in the response.

2. The method of claim 1, wherein the type of connection information contained in the response from the responding neighboring node depends on the type of inquiry message broadcast from the inquiring node.

3. The method of claim 2, wherein the type of inquiry message is indicated by an inquiry access code.

4. The method of claim 3, wherein the type of inquiry access code is an accessible services general inquiry access code.

5. The method of claim 3, wherein the type of inquiry access code is an accessible type of device inquiry, access code.

6. The method of claim 3, wherein the type of inquiry access code is a dedicated accessible service inquiry access code.

7. The method of claim 3, wherein the type of inquiry access code is a dedicated accessible type of device inquiry access code.

8. The method of claim 3, wherein the type of inquiry access code is an accessibility based dedicated inquiry access code.

9. The method of claim 1, wherein the connection information is encoded as a bit map in the response.

10. The method of claim 1, wherein the connection information is encoded as a list in the response.

11. The method of claim 1, wherein the connection information in the response contains hop count information.

12. The method of claim 1, wherein the response contains connection information in a plurality of redefined fields.

13. The method of claim 1, wherein the response contains connection information in an extended response.

14. The method of claim 1, wherein the response contains connection information in a plurality of redefined fields and an extended response.

15. The method of claims 12 or 14, wherein the plurality of redefined fields comprises either the Undefined field, the AM_ADDR field, the NAP field or the Class of Device field.

16. The method of claim 15, wherein the connection information contains hop count information in one or more redefined fields.

17. The method of claims 13 or 14, wherein the connection information contains hop count information in the extended response.

18. The method of claim 8, wherein the response contains hop count information.

19. The method of claim 18, wherein the hop count information is contained within one or more redefined fields.

20. The method of claim 18, wherein the hop count information is contained in an extended response.

21. The method of claim 19, wherein the redefined fields comprises either the Undefined field, the AM_ADDR field, the NAP field or the Class of Device field.

22. In an ad-hoc network an arrangement for providing connection information, the arrangement comprising: an inquiring node comprising: means for broadcasting an inquiry message, the inquiry message requesting connection information about accessible nodes; means for receiving a response; a neighboring node comprising: means for receiving the inquiry message; means for broadcasting the response, the response containing connection information about the responding neighboring node and nodes which are accessible by the responding neighboring node; and the inquiring node further comprising means for determining whether to establish connections with the responding neighboring node using the connection information in the response.

23. The arrangement of claim 22, wherein the type of connection information contained in the response from the responding node depends on the type of inquiry message broadcast from the inquiring node.

24. The arrangement of claim 23, wherem the type of inquiry message is indicated by an inquiry access code.

25. The arrangement of claim 24 wherein the type of inquiry access code is an accessible services general inquiry access code.

26. The arrangement of claim 24, wherein the type of inquiry access code is an accessible type of device inquiry access code.

27 The arrangement of claim 24, wherein the type of inquiry access code is a dedicated accessible service inquiry access code.

28. The method of claim 24, wherein the type of inquiry access code is a dedicated accessible type of device inquiry access code.

29. The method of claim 24, wherein the type of inquiry access code is an accessibility based dedicated inquiry access code.

30. The arrangement of claim 22, wherein the connection information is encoded as a bit map in the response.

31. The arrangement of claim 22, wherein the connection information is encoded as a list in the response.

32. The arrangement of claim 22, wherein the connection information in the response contains hop count information.

33. The arrangement of claim 22, wherein the response contains connection information in a plurality of redefined fields.

34. The arrangement of claim 22, wherein the response contains connection information in an extended response.

35. The arrangement of claim 22, wherein the response contains connection information in a plurality of redefined fields and an extended response.

36. The arrangement of claims 33 or 35, wherein the plurality of redefined fields comprises either the Undefined field, the AM_ADDR field, the NAP field or the Class of Device field.

37. The arrangement of claim 36, wherein the connection information contains hop count information in one or more redefined fields.

38. The arrangement of claims 34 or 35, wherein the connection information contains hop count information in the extended response.

39. The arrangement of claim 29, wherein the response contains hop count information

40. The method of claim 39, wherein the hop count information is contained within one or more redefined fields.

41. The method of claim 39, wherein the hop count information is contained in an extended response.

42. The method of claim 40, wherein the redefined fields comprises either the Undefined field, the AM_ADDR field, the NAP field or the Class of Device field.