Rune, Johan (Lidingo, SE)
Larsson, Tony (Stockholm, SE)
Kauppinen, Tero (Espoo, FI)

10/735047

07/22/2004

12/12/2003

Images are available in PDF form when logged in. To view PDFs, Login  or  Create Account (Free!)

View patents that cite this patent

Click for automatic bibliography generation

370/401

(IPC1-7): H04L012/28

JENKENS & GILCHRIST, A PROFESSIONAl CORPORATION,Stanley R. Moore (Suite 3200, Dallas, TX, 75202, US)

What is claimed is:

1. A method of bridging a point-to-point network with a shared medium network, said point-to-point network having a plurality of nodes including at least one network access point, comprising: connecting said point-to-point network to said shared medium network via said network access point; receiving data packets from said shared medium network and said point-to-point network; converting said data packets from a shared medium network format to a point-to-point network format, or vice versa; and forwarding certain ones of said data packets, including ARP requests and ARP route requests, between said shared medium network and said point-to-point network.

2. The method according to claim 1, wherein said step of forwarding includes receiving said ARP request from a source node in said shared medium network at said network access point, converting said ARP request to said ARP route request in said network access point, sending said ARP route request to said point-to-point network, and indicating said shared medium network as a next hop node in a route entry for a source node of said ARP request.

3. The method according to claim 2, wherein said step of forwarding further includes receiving an ARP route reply from a destination node in said point-to-point network at said network access point in response to said ARP route request, converting said ARP route reply to an ARP reply in said network access point, and sending said ARP reply to said shared medium network.

4. The method according to claim 2, wherein said step of forwarding further includes receiving a broadcast ARP reply from a destination node in said point-to-point network at said network access point in response to said ARP route request, sending said broadcast ARP reply to said shared medium network as a broadcast ARP reply, receiving a unicast ARP route reply from said point-to-point network at said network access point in response to said ARP route request, converting said unicast ARP route reply to a unicast ARP reply in said network access point, and sending said unicast ARP reply to said shared medium network.

5. The method according to claim 1, wherein said step of forwarding includes receiving a unicast data packet from a node in said shared medium network at said network access point without a preceding ARP request, and sending said unicast packet to a destination node in said point-to-point network if a route entry exists for said destination node in said network access point.

6. The method according to claim 5, wherein said step of forwarding further includes broadcasting a non-ARP route request to said point-to-point network from said network access point to establish a route to said destination node if no route entry for said destination node exists in said network access point, and sending said unicast data packet along said established route, wherein a non-ARP route reply received by said network access point in response to said non-ARP route request is not sent to said shared medium network.

7. The method according to claim 1, wherein said step of forwarding includes receiving an ARP route request from a source node in said point-to-point network at said network access point, encapsulating said ARP route request, and sending said encapsulated ARP route request to said shared medium network.

8. The method according to claim 7, wherein said step of forwarding further includes converting said ARP route request into an ARP request, and sending said ARP request to said shared medium network after said encapsulated ARP route request has been sent.

9. The method according to claim 8, wherein no ARP request is sent to said shared medium network if it is determined that a destination node of said ARP request is located in any point-to-point network, and no encapsulated ARP route request is sent to said shared medium network if it is determined that said destination node is located in said shared medium network.

10. The method according to claim 8, wherein said step of forwarding further includes storing a target IP address and source MAC address for said ARP request in said network access point, receiving an ARP reply at said network access point, converting said ARP reply to an ARP route reply, and sending said ARP route reply to said point-to-point network if a sender IP address and target MAC address for said ARP reply matches said stored target IP address and source MAC address of said ARP request.

11. The method according to claim 10, wherein said target IP address and source MAC address for said ARP request are stored in said network access point in a table for pending ARP requests triggered by route requests received from said point-to-point network.

12. The method according to claim 11, wherein said network access point is a first network access point, said step of forwarding further includes receiving said encapsulated ARP route request at a second network access point, storing a target IP address and source MAC address for said encapsulated ARP route request in said second network access point, extracting said ARP route request from said encapsulated ARP route request, sending said ARP route request to said point-to-point network, and indicating another NAP as a next hop node in a route entry for said source node in said second network access point.

13. The method according to claim 12, wherein said target IP address and source MAC address of said encapsulated ARP route request are stored in a table for pending ARP route requests triggered by encapsulated ARP route requests.

14. The method according to claim 12, wherein said step of forwarding further includes receiving said ARP request at said second network access point, comparing a target IP address and source MAC address of said ARP request with said stored target IP address and source MAC address of said encapsulated ARP route request, and if they do not match, converting said ARP request to an ARP route request and sending said converted ARP route request to said point-to-point network.

15. The method according to claim 14, wherein said step of forwarding further includes receiving an ARP route reply from said point-to-point network at said second network access point, encapsulating said ARP route reply, and sending said encapsulated ARP route reply to said shared medium network.

16. The method according to claim 15, wherein said step of forwarding further includes receiving said encapsulated ARP route reply at said first network access point, extracting said ARP route reply from said encapsulated ARP route reply, determining whether a sender IP address and a target MAC address of said ARP route reply matches said stored target IP address and source MAC address of said ARP route request, and sending said ARP route reply to said point-to-point network if a match is found.

17. The method according to claim 14, wherein said step of forwarding further includes receiving an ARP reply from said point-to-point network at said second network access point in response to said ARP route request and sending said ARP reply to said shared medium network.

18. The method according to claim 17, wherein said step of forwarding further includes receiving said ARP reply at said first network access point, determining whether a sender IP address and a target MAC address of said ARP reply matches said stored target IP address and source MAC address of said ARP route request, sending said ARP reply to said point-to-point network if no match is found, and converting said ARP reply to an ARP route reply and sending said ARP route reply to said point-to-point network if a match is found.

19. The method according to claim 18, wherein said ARP reply received from said point-to-point network at said second network access point is a broadcast ARP reply, said step of forwarding further including sending said ARP reply as a broadcast ARP reply from said first network access point to said point-to-point network in addition to said ARP route reply if a match is found.

20. The method according to claim 1, wherein said step of forwarding includes receiving a non-ARP route request from a source node in said point-to-point network at said network access point, encapsulating said non-ARP route request, and sending said encapsulated non-ARP route request to said shared medium network.

21. The method according to claim 20, wherein said step of forwarding further includes sending an unconfirmed proxy non-ARP route reply from said network access point to said point-to-point network, generating an unconfirmed route entry for a destination node of said non-ARP route request in said network access point, and indicating said shared medium network as a next hop node in said unconfirmed route entry.

22. The method according to claim 21, wherein no unconfirmed proxy non-ARP route reply is sent to said point-to-point network if it is determined that said destination node of said non-ARP route request is located in any point-to-point network, and no encapsulated non-ARP route request is sent to said shared medium network if it is determined that said destination node is located in said shared medium network.

23. The method according to claim 21, wherein said network access point is a first network access point, said step of forwarding further includes receiving said encapsulated non-ARP route request at a second network access point, extracting said non-ARP route request from said encapsulated non-ARP route request, and sending said non-ARP route request to said point-to-point network.

24. The method according to claim 22, wherein said step of forwarding further includes receiving a non-ARP route reply from said point-to-point network at said second network access point, encapsulating said non-ARP route reply, and sending said encapsulated non-ARP route reply to said shared medium network.

25. The method according to claim 24, wherein said step of forwarding further includes receiving said encapsulated non-ARP route reply at said first network access point, replacing said unconfirmed route entry with a confirmed route entry for said destination node, extracting said non-ARP route reply from said encapsulated non-ARP route reply, and sending said non-ARP route reply to said point-to-point network.

26. The method according to claim 1, wherein said step of forwarding includes receiving an ARP route request from a source node in said point-to-point network at said network access point, creating a route entry for said source node if no previous route entry for said source node exists, converting said ARP route request into an ARP request, and sending said ARP request to said shared medium network.

27. The method according to claim 26, wherein said step of forwarding further includes storing, in said network access point, a target IP address and source MAC address for said ARP request, a pointer to said route entry for said source node, and a type of reply indicator.

28. The method according to claim 27, wherein said target IP address and source MAC address for said ARP request, said pointer to said route entry for said source node, and said type of reply indicator are stored in said network access point in a table for pending ARP requests triggered by route requests received from said point-to-point network.

29. The method according to claim 28, wherein said type of reply indicator indicates an ARP route reply, and said pointer to said route entry is a source MAC address of said ARP route request.

30. The method according to claim 29, wherein said network access point is a first network access point, said step of forwarding further includes receiving said ARP request at a second network access point connected to said shared medium network, converting said ARP request to an ARIP route request and sending said ARP route request from said second network access point to said point-to-point network.

31. The method according to claim 30, wherein said step of forwarding further includes receiving an ARP route reply from said point-to-point network at said second network access point in response to said ARP route request, converting said ARP route reply to an ARP reply, and sending said ARP reply to said shared medium network.

32. The method according to claim 31, wherein said step of forwarding further includes receiving a broadcast ARP reply from said point-to-point network at said second network access point in response to said ARP route request and sending said broadcast ARP reply to said shared medium network.

33. The method according to claim 30, wherein said step of forwarding further includes receiving an ARP reply at said first network access point, determining whether a sender IP address and target MAC address of said ARP reply matches said stored target IP address and source MAC address, and if a match is found, converting said ARP reply to an ARP route reply if the type of reply indicator indicates an ARP route reply and sending said ARP route reply to said point-to-point network.

34. The method according to claim 33, wherein said step of forwarding further includes removing said matching entry from said table for pending ARP requests triggered by route requests received from said point-to-point network.

35. The method according to claim 1, wherein said step of forwarding includes receiving a non-ARP route request from a source node in said point-to-point network at said network access point, retrieving a destination node 1P address for said non-ARP route request from an ARP cache, generating a new ARP request using said retrieved IP address as a target IP address and a MAC address of said network access point as a sender MAC address for said new ARP request, using an IP address of said network access point as a sender IP address and said MAC address of said network access point as a source MAC address for said new ARP request, and sending said new ARP request to said shared medium network.

36. The method according to claim 35, wherein said step of forwarding further includes storing, in said network access point, said target IP address and source MAC address for said new ARP request, a pointer to said route entry for said source node, and a type of reply indicator.

37. The method according to claim 36, wherein said target IP address and source MAC address for said new ARP request, said pointer to said route entry for said source node, and said type of reply indicator are stored in said network access point in a table for pending ARP requests triggered by route requests received from said point-to-point network.

38. The method according to claim 37, wherein said type of reply indicator indicates a non-ARP route reply, and said pointer to said route entry is a source MAC address of said non-ARP route request.

39. The method according to claim 27, wherein said step of forwarding further includes receiving a unicast ARP reply at said network access point, comparing a sender IP address and target MAC address of said unicast ARP reply with said stored target IP address and source MAC address, and if a match is found, converting said unicast ARP reply to a non-ARP route reply if said type of reply indicator indicates a non-ARP route reply, and sending said non-ARP route reply to said point-to-point network.

40. The method according to claim 35, wherein if said destination node IP address cannot be received from said ARP cache, said step of forwarding further includes sending an unconfirmed proxy non-ARP route reply from said network access point to said point-to-point network, generating an unconfirmed route entry for a destination node of said non-ARP route request in said network access point, and indicating said shared medium network as a next hop node in said unconfirmed route entry.

41. A system for bridging a point-to-point network with a shared medium network, comprising: a plurality of nodes in said point-to-point network and said shared medium network, said nodes including at least one network access point connecting said point-to-point network to said shared medium network; a bridging function in said network access point configured to convert said data packets from a shared medium network format to a point-to-point network format, or vice versa, and forward certain ones of said data packets, including ARP requests and ARP route requests, between said shared medium network and said point-to-point network.

42. The system according to claim 41, wherein said network access point receives an ARP request from a source node in said shared medium network, said bridging function configured to cause said network access point to convert said ARP request to an ARP route request, send said ARP route request to said point-to-point network, and indicate said shared medium network as a next hop node in a route entry for a source node of said ARP request in said network access point.

43. The system according to claim 42, wherein said network access point receives an ARP route reply from a destination node in said point-to-point network in response to said ARP route request, said bridging function further configured to cause said network access point to convert said ARP route reply to an ARP reply and send said ARP reply to said shared medium network.

44. The system according to claim 42, wherein said network access point receives a broadcast ARP reply from a destination node in said point-to-point network in response to said ARP route request, said bridging function further configured to cause said network access point to send said broadcast ARP reply to said shared medium network as a broadcast ARP reply, and when a unicast ARP route reply from said point-to-point network is received at said network access point in response to said ARP route request, said bridging function further configured to cause said network access point to convert said ARP route reply to an ARP reply and send said ARP reply to said shared medium network.

45. The system according to claim 41, wherein said network access point receives a unicast data packet from a node in said shared medium network without a preceding ARP request, said bridging function further configured to cause said network access point to send said unicast packet to a destination node in said point-to-point network if a route entry exists for said destination node in said network access point.

46. The system according to claim 45, wherein said bridging function is further configured to cause said network access point to broadcast a non-ARP route request to said point-to-point network to establish a route to said destination node if no route entry for said destination node exists in said network access point, and send said unicast data packet along said established route, wherein a non-ARP route reply received by said bridging function in response to said non-ARP route request is not sent to said shared medium network.

47. The system according to claim 41, wherein said network access point receives an ARP route request from a source node in said point-to-point network, said bridging function further configured to cause said network access point to send said ARP route request as an encapsulated ARP route request to said shared medium network.

48. The system according to claim 47, wherein said bridging function is further configured to cause said network access point to convert said ARP route request into an ARP request and send said ARP request to said shared medium network after said encapsulated ARP route request has been sent.

49. The system according to claim 48, wherein no ARP request is sent to said shared medium network from said bridging function if it is determined that a destination node of said ARP request is located in any point-to-point network, and no encapsulated ARP route request is sent to said shared medium network from said bridging function if it is determined that said destination node is located in said shared medium network.

50. The system according to claim 48, wherein said bridging function is further configured to cause said network access point to store a target IP address and source MAC address for said ARP request in said network access point, and when an ARP reply is received at said network access point, said bridging function is further configured to cause said network access point to convert said ARP reply to an ARP route reply and send said ARP route reply to said point-to-point network if a sender IP address and target MAC address for said ARP reply matches said stored target IP address and source MAC address of said ARP request.

51. The system according to claim 50, wherein said target IP address and source MAC address for said ARP request are stored in said network access point in a table for pending ARP requests triggered by route requests received from said point-to-point network.

52. The system according to claim 51, wherein said network access point is a first network access point and said encapsulated ARP route request is received at a second network access point, said second network access point having a bridging function that is configured to cause said second network access point to store a target IP address and source MAC address for said encapsulated ARP route request, send an ARP route request contained in said encapsulated ARP route request to said point-to-point network, and indicate another NAP as a next hop node in a route entry for said source node in said second network access point.

53. The system according to claim 52, wherein said target IP address and source MAC address of said encapsulated ARP route request are stored in a table for pending ARP route requests triggered by encapsulated ARP route requests.

54. The system according to claim 52, wherein said ARP request sent by said first network access point is received at said second network access point, said bridging function of said second network access point further configured to cause said second network access point to compare a target IP address and source MAC address of said ARP request with said stored target IP address and source MAC address of said encapsulated ARP route request, and if they do not match, convert said ARP request to an ARP route request and send said converted ARP route request to said point-to-point network.

55. The system according to claim 52, wherein an ARP route reply from said point-to-point network is received at said second network access point, said bridging function of said second network access point further configured to cause said second network access point to send said ARP route reply as an encapsulated ARP route reply to said shared medium network.

56. The system according to claim 55, wherein said encapsulated ARP route reply is received at said first network access point, said bridging function of said first network access point further configured to cause said first network access point to determine whether a sender IP address and a target MAC address of said encapsulated ARP route reply matches said stored target IP address and source MAC address of said ARP route request, and send said ARP route reply contained in said encapsulated ARP route reply to said point-to-point network if a match is found.

57. The system according to claim 54, wherein an ARP reply from said point-to-point network is received at said second network access point in response to said ARP route request, said bridging function of said second network access point further configured to cause said second network access point to send said ARP reply to said shared medium network.

58. The system according to claim 57, wherein said ARP reply is received at said first network access point, said bridging function of said first network access point further configured to cause said first network access point to determine whether a sender IP address and a target MAC address of said ARP reply matches said stored target IP address and source MAC address of said ARP route request, send said ARP reply to said point-to-point network if no match is found, and convert said ARP reply to an ARP route reply and send said ARP route reply to said point-to-point network if a match is found.

59. The system according to claim 58, wherein said ARP reply received from said point-to-point network at said second network access point is a broadcast ARP reply, said bridging function of said first network access point further configured to cause said first network access point to send said ARP reply as a broadcast ARP reply from said to said point-to-point network in addition to said ARP route reply if a match is found.

60. The system according to claim 41, wherein a non-ARP route request is received at said network access point from a source node in said point-to-point network, said bridging function further configured to cause said network access point to encapsulate said non-ARP route request and send said encapsulated non-ARP route request to said shared medium network.

61. The system according to claim 60, wherein said bridging function further configured to cause said network access point to send an unconfirmed proxy non-ARP route reply to said point-to-point network, generate an unconfirmed route entry for said destination node of said non-ARP route request, and indicate said shared medium network as a next hop node in said unconfirmed route entry.

62. The system according to claim 61, wherein no unconfirmed proxy non-ARP route reply is sent to said point-to-point network if it is determined that said destination node of said non-ARP route request is located in any point-to-point network, and no encapsulated non-ARP route request is sent to said shared medium network if it is determined that said destination node is located in said shared medium network.

63. The system according to claim 61, wherein said network access point is a first network access point and said encapsulated non-ARP route request is received at a second network access point, said second network access point having a bridging function that is configured to cause said second network access point to extract said non-ARP route request from said encapsulated non-ARP route request, and send said non-ARP route request to said point-to-point network.

64. The system according to claim 62, wherein a non-ARP route reply from said point-to-point network at said second network access point, said bridging function of said second network access point further configured to cause said second network access point to encapsulate said non-ARP route reply and send said encapsulated non-ARP route reply to said shared medium network.

65. The system according to claim 64, wherein said encapsulated non-ARP route reply is received at said first network access point, said bridging function of said first network access point further configured to cause said first network access point to replace said unconfirmed route entry with a confirmed route entry for said destination node, extract said non-ARP route reply from said encapsulated non-ARP route reply, and send said non-ARP route reply to said point-to-point network.

66. The system according to claim 41, wherein an ARP route request from a source node in said point-to-point network is received at said network access point, said bridging function configured to cause said network access point to create a route entry for said source node if no previous route entry for said source node exists, convert said ARP route request into an ARP request, and send said ARP request to said shared medium network.

67. The system according to claim 66, wherein said bridging function is further configured to cause said network access point to store a target IP address and source MAC address for said ARP request, a pointer to said route entry for said source node, and a type of reply indicator.

68. The system according to claim 67, wherein said target IP address and source MAC address for said ARP request, said pointer to said route entry for said source node, and said type of reply indicator are stored in said network access point in a table for pending ARP requests triggered by route requests received from said point-to-point network.

69. The method according to claim 68, wherein said type of reply indicator indicates an ARP route reply, and said pointer to said route entry is a source MAC address of said ARP route request.

70. The system according to claim 69, wherein said network access point is a first network access point and an ARP request is received at a second network access point connected to said shared medium network, said second network access point having a bridging function therein configured to cause said second network access point to convert said ARP request to an ARP route request and send said ARP route request from said second network access point to said point-to-point network.

71. The system according to claim 70, wherein an ARP route reply from said point-to-point network is received at said second network access point in response to said ARP route request, said bridging function of said second network access point further configured to cause said second network access point to convert said ARP route reply to an ARP reply, and send said ARP reply to said shared medium network.

72. The system according to claim 71, wherein a broadcast ARP reply from said point-to-point network is received at said second network access point in response to said ARP route request, said bridging function of said second network access point further configured to cause said second network access point to send said broadcast ARP reply to said shared medium network.

73. The system according to claim 70, wherein an ARP reply is received at said first network access point, said bridging function of said first network access point further configured to cause said first network access point to determine whether a sender IP address and target MAC address of said ARP reply matches said stored target IP address and source MAC address, and if a match is found, convert said ARP reply to an ARP route reply if the type of reply indicator indicates an ARP route reply and send said ARP route reply to said point-to-point network.

74. The system according to claim 73, wherein said bridging function of said first network access point is further configured to cause said first network access point to remove said matched entry from said table for pending ARP requests triggered by route requests received from said point-to-point network.

75. The system according to claim 41, wherein a non-ARP route request from a source node in said point-to-point network is received at said network access point, said bridging function further configured to cause said network access point to retrieve a destination node IP address for said non-ARP route request from an ARP cache, generate a new ARP request us said retrieved IP address as a target IP address and a MAC address of said network access point as a sender MAC address for said new ARP request, use an IP address of said network access point as a sender IP address and said MAC address of said network access point as a source MAC address for said new ARP request, and send said new ARP request to said shared medium network.

76. The system according to claim 75, wherein said bridging function further configured to cause said network access point to store said target IP address and source MAC address for said new ARP request, a pointer to said route entry for said source node, and a type of reply indicator.

77. The system according to claim 76, wherein said target IP address and source MAC address for said new ARP request, said pointer to said route entry for said source node, and said type of reply indicator are stored in said network access point in a table for pending ARP requests triggered by route requests received from said point-to-point network.

78. The system according to claim 77, wherein said type of reply indicator indicates a non-ARP route reply, and said pointer to said route entry is a source MAC address of said non-ARP route request.

79. The system according to claim 67, wherein a unicast ARP reply is received at said network access point, said bridging function further configured to cause said network access point to compare a sender IP address and target MAC address of said unicast ARP reply with said stored target IP address and source MAC address, and if a match is found, convert said unicast ARP reply to a non-ARP route reply if said type of reply indicator indicates a non-ARP route reply, and send said non-ARP route reply to said point-to-point network.

80. The system according to claim 75, wherein if said destination node IP address cannot be retrieved from said ARP cache, said bridging function further configured to cause said network access point to send an unconfirmed proxy non-ARP route reply from said network access point to said point-to-point network, generate an unconfirmed route entry for a destination node of said non-ARP route request in said network access point, and indicate said shared medium network as a next hop node in said unconfirmed route entry.

RELATED APPLICATION

[0001] This patent application claims priority from and incorporates by reference the entire disclosure of U.S. Provisional Patent Application No. 60/421,132 filed on Dec. 23, 2002.

BACKGROUND OF THE INVENTION

[0002] 1. Field of the Invention

[0003] The present invention relates to Bluetooth networks and, in particular, to a system and method for connecting a Bluetooth network to an Ethernet LAN.

[0004] 2. Description of the Related Art

[0005] In order to appreciate the merits of the invention a general knowledge of Bluetooth and the problems involved in bridging a Bluetooth network and an Ethernet LAN is in order. Bluetooth is an ad-hoc wireless network technology intended for both synchronous traffic (e.g., voice) and asynchronous traffic (e.g., data traffic) based on IP (Internet Protocol). The aim is that any commodity device such as telephones, PDAs, laptop computers, digital cameras, video monitors, printers, fax machines, etc., will be able to communicate with one another over a radio interface using a Bluetooth radio chip and software. The Bluetooth wireless communication technology uses a frequency hopping scheme in the unlicensed 2.4 GHz ISM (Industrial-Scientific-Medical) band.

[0006] Two or more Bluetooth (BT) units sharing the same channel form a piconet. FIG. 1 illustrates several examples of Bluetooth piconets 100 - 104 . Within each piconet 100 - 104 , there must be one and only one master 106 (shaded circles) and up to seven active slaves 108 (empty circles). Any BT unit can become a master 106 in a piconet 100 - 104 .

[0007] Furthermore, two or more piconets 100 - 104 can be interconnected to form a scatternet. FIG. 2 illustrates an example of a scatternet 200 made of several interconnected piconets 202 - 224 . As can be seen, the connection point between any two piconets 202 - 224 includes one BT unit 226 that is a member of both piconets. The BT unit 226 can simultaneously be a slave member of multiple piconets 202 - 224 , but a master in only one. Partially shaded circles represent BT units 226 that are masters in one piconet while participating as slaves in other piconets. BT units 226 can only transmit and receive data in one piconet at a time, so participation in multiple piconets 202 - 224 has to be on a time division multiplex basis.

[0008] Bluetooth provides packet based full-duplex transmission using slotted Time Division Duplex (TDD). Each time slot is 0.625 ms long and is numbered sequentially using a very large number range (e.g., 2 ²⁷ ). Master-to-slave transmission always starts in an even-numbered time slot while slave-to-master transmission always starts in an odd-numbered time slot. An even-numbered time slot and its subsequent odd-numbered time slot (i.e., a master-to-slave time slot and a slave-to-master time slot, except when multi-slot packets are used) together are called a frame. There is no direct transmission between slaves in a Bluetooth piconet.

[0009] The communication within a piconet is organized such that the master polls each slave according to some polling scheme. A slave is only allowed to transmit after having been polled by the master. The slave will then start its transmission in the next slave-to-master time slot immediately following the packet received from the master. The master may or may not include data in the packet used to poll a slave. The only exception to the above principle is when a slave has an established Synchronous Connection-Oriented (SCO) link (explained below). When this happens, the slave is always allowed to transmit in a pre-allocated slave-to-master time slot, even if not explicitly polled by the master in the preceding master-to-slave time slot.

[0010] 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 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/de-assigned and is unique only within a single piconet. The master uses the slave's AM_ADDR when polling a slave in a piconet by including the AM_ADDR in the packet header. However, when the slave transmits a packet in response to the master, the slave's own AM_ADDR (not the master's) is included in the packet header.

[0011] Even though all data is transmitted in packets, the packets can carry both synchronous data on SCO links mainly intended for voice traffic, and asynchronous data on Asynchronous Correctionless links (ACL). SCO links use regular pre-defined timeslots, as opposed to ACL links which do not have pre-defined timeslots and, therefore, the master has to poll each slave in order to let the slave communicate over the ACL link. Depending on the type of packet that is used, an acknowledgment and retransmission scheme is used to ensure reliable transfer of data. Forward error correction (FEC) in the form of channel coding may also be used to ensure reliable transfer.

[0012] The standard format of a Bluetooth packet (except for certain control packets) is shown in FIG. 3 . As can be seen, the Bluetooth packet 300 includes a packet header 302 , an Access Code 304 , and a payload 306 . The packet header 302 includes the AM_ADDR followed by one or more control parameters. Examples of control parameters in the packet header 302 include a bit indicating an acknowledgment or retransmission request of the previous packet and a header error check (HEC).

[0013] The Access Code 304 in the packet 300 can be of three different types: Channel Access Code (CAC), Device Access Code (DAC), and Inquiry Access Code (IAC). The Channel Access Code identifies the channel that is used in the piconet, which in essence identifies the piconet. All packets 300 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 the BD_ADDR of a particular BT unit. Device Access Codes are used for special signaling procedures, for example, the PAGE procedure explained later herein. The Inquiry Access Code comes in two variants: the General Inquiry Access Code (GIAC) and the Dedicated Inquiry Access Code (DIAC). Both are used in the INQUIRY procedure explained later herein.

[0014] The format of the payload 306 depends on the type of packet 300 . For example, the payload 306 of an ACL packet includes a header field, a data field and (with the exception of AUXI type packets) a cyclic redundancy check (CRC). The payload 306 of an SCO packet, on the other hand, includes only a data field. In addition, there are hybrid packets that include two data fields, one for synchronous data and one for asynchronous data. Note that packets 300 in which the payload 306 does not include a CRC are neither acknowledged nor retransmitted.

[0015] The protocol layers of a Bluetooth system are illustrated in FIG. 4 . Of these layers, the baseband layer 400 , link manager protocol (LMP) 402 and logical link control and adaptation protocol 404 (L2CAP) represent existing Bluetooth specific protocols. The high layer protocol or application layer 406 represents protocols that may or may not be Bluetooth specific. Finally, the network layer 408 is currently not specified in the Bluetooth standard, but can in most cases be assumed to be the Internet Protocol (IP).

[0016] As previously stated, transmission in a piconet is allowed exclusively between the master and a slave and not between slaves. Furthermore, the addressing scheme requires that the AM_ADDR of the transmitting slave should be used when transmitting to the master. Consequently, there is no way for a slave to send data to another slave in a piconet (there is no way for one slave to address another slave, and direct communication between slaves is not allowed). Hence, a slave can only communicate with the master of the piconet, while the master can communicate with all the slaves.

[0017] Another limitation of the Bluetooth system is that, in the current standard, there is no way to address and route packets from one piconet to another. Defining how inter-piconet communication should be performed in a scatternet is one of the tasks that the standardization body Bluetooth Special Interest Group (Bluetooth SIG) is currently working on. This work focuses mainly on the ability of Bluetooth as an ad-hoc network technology to support IP in a Bluetooth scatternet (or piconet). Essentially, IP would run on top of the Bluetooth protocol stack (i.e., IP would be the network layer 408 in FIG. 4 ). There are currently two basic proposals for how to achieve this: (a) regard each Bluetooth piconet as an IP subnet and run IP on top of the L2CAP layer 404 in each piconet, and (b) regard an entire Bluetooth scatternet as an IP subnet.

[0018] The second proposal requires that an adaptation layer be inserted between L2CAP layer and the IP or network layer, as shown in FIG. 5 . The purpose of this adaptation layer 500 is to emulate a shared medium network (e.g., a broadcast medium) which is required by the IP or network layer 408 . In the Bluetooth SIG, the adaptation layer 500 is referred to as the Bluetooth Network Encapsulation Protocol (BNEP). However, the adaptation layer 500 has also been referred to using the more general term network adaptation layer (NAL). NAL as used herein can refer to any variant or future extension of BNEP or any other adaptation layer 500 with the same basic purpose as BNEP.

[0019] The first proposal suffers from a number of problems, one of which is the Bluetooth piconets are not shared medium networks. The second proposal is more promising and has the most support in the Bluetooth SIG. Therefore, the remainder of this description will proceed with the assumption that the second proposal, the NAL/BNEP approach, is used. Furthermore, the more generic term NAL will be used throughout this description.

[0020] Both the IP subnet approach and the NAL approach require some kind of routing within a scatternet. In the IP subnet approach, the routing is performed on the IP layer 408 . In the NAL approach, the routing is performed on the adaptation layer 500 while appearing (emulating) to the IP layer 408 that the scatternet is actually a single shared medium network. In both cases, the routing can be performed according to several different routing schemes. One scheme may use ad-hoc routing protocols (also called reactive routing protocols) specifically designed for the potentially very dynamic topology of wireless ad-hoc networks. Another scheme may use traditional routing protocols (also called proactive routing protocols) designed for fixed networks with very slowly changing topology. Examples of ad-hoc routing protocols include Ad-hoc On-demand Distance Vector (AODV) and Dynamic Source Routing (DSR). Examples of traditional routing protocols include Distance Vector protocols such as RIP (Routing Information Protocol) and Link State protocols such as OSPF (Open Shortest Path First).

[0021] The ad-hoc routing protocols are the ones most seriously considered for Bluetooth scatternets and other ad-hoc network technologies. These ad-hoc routing protocols create routes on demand and retain (or cache) them for a certain period of time based on the time scale for changes of the network topology.

[0022] When a route needs to be created in AODV, a route request message is broadcast (i.e., sent to all nodes) in the scatternet. The route request message includes the address of the destination node. As the route request message propagates through the scatternet, temporary route entries are created in the nodes traversed by the message. When the route request message reaches the destination node, the destination node sends a route reply back to the source node. The route reply is unicast (i.e., sent to only one node but possibly forwarded via other nodes) along the same path that the route request message used to reach the destination node, guided by the temporary route entries in the nodes along the path.

[0023] As the route reply is forwarded to the source node, a route is created in both directions. Temporary route entries in the nodes through which the route reply does not pass are soon timed out and removed. For the nodes that lie along the path between the source node and destination node, the route entries that are created comprise the address of the destination node and the address of the next node (or hop) in the route. Between the destination node and the source node, route entries that are created include the address of the source node (which is the destination node for packets sent in this direction) and the address of the next hop node in the route. Thus, when a regular packet is subsequently transmitted from the source node to the destination node, all that is needed to route the packet to the destination node is the address of the destination node.

[0024] If an intermediate node already has a route entry for a certain destination node, it may return a route reply upon receiving a route request even though it is not the destination node. Such a route reply may also be called a proxy route reply. A node may have several route entries (to different destination nodes) stored. These route entries are together called a routing table and are stored in the node. A route entry is not stored indefinitely and may be removed from the routing table if it is not used for a certain time. The addresses used by the AODV routing protocol are the BD_ADDRs in the NAL approach and the IP addresses in the IP subnet approach.

[0025] The DSR routing protocol is similar to AODV in that it uses broadcast route requests and unicast route replies to establish a route on demand. A major difference, though, is that as the route request propagates through the scatternet, the address of each traversed node is added to the route request message. The result is that when the route request message reaches the destination node, it includes the complete route that was traversed. This route is used by the destination node to unicast the route reply message (still including the addresses of all the nodes along the route) to the source node. When a regular packet is subsequently transmitted from the source node to the destination node, the complete route (i.e., the address of all the intermediate nodes and the destination node) is included in the packet. This address information is used by the intermediate nodes to route packet to the destination node. Thus, no address information has to be stored in the intermediate nodes along the route in order to route packets to the destination node. Nevertheless, the intermediate nodes may still use the address information in the route requests and route replies to learn and store routes. As before, if a node already has a stored route for a certain destination node, it may return a route reply even though it is not the destination node. In any case, the stored routes are not stored indefinitely. If the route is not used for a certain time, the route is timed out and removed from the node's routing table. The addresses used by the DSR routing protocol are the IP addresses in the IP approach. In the NAL approach, the BD_ADDRs are used for the destination node, but either the BD_ADDRs or locally unique (i.e., within a single piconet) addresses may be used for the intermediate nodes.

[0026] Routing a packet through the scatternet, regardless of which routing scheme is used, relies on the BT units being members in more than one piconet. The BT units forward packets from one piconet to another, and are sometimes referred to as forwarding nodes. Of course, a BT unit may be a member of more than one piconet without forwarding traffic between the piconets. In that case, the BT unit is not a forwarding node. Within each piconet, the master node forwards the packets between different slave nodes. Therefore, master nodes are also referred to as forwarding nodes, even when they are not members of more than one piconet. The address used to route packets within a scatternet in the NAL approach is the BD_ADDR of each node.

[0027] The NAL layer can be designed to include functions for automatic network formation. That means that nodes may discover neighbor nodes automatically and connect to each other. Such basic connectivity can facilitate higher-level service discovery that will allow applications to use the network for application layer interactions. Thus, an important capability in any ad-hoc networking technology is the neighbor discovery feature. Without a neighbor discovery procedure, a BT unit would not be able to find any other BT units to communicate with and, consequently, no ad-hoc network would be formed. The neighbor discovery procedure in Bluetooth comprises the INQUIRY message and the INQUIRY RESPONSE message. A BT unit wanting to discover neighboring (within radio coverage) BT units will transmit INQUIRY messages and listen for INQUIRY RESPONSE messages. The INQUIRY message is transmitted repeatedly and according to well specified timing and frequency sequences. An INQUIRY message includes 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 only a certain type of BT units.

[0028] A BT unit receiving an INQUIRY message (including the GIAC or an appropriate DIAC) will respond with an INQUIRY RESPONSE message. The INQUIRY RESPONSE message is essentially a FHS (Frequency Hop Synchronization) packet being used as a response message. The format of the FHS packet 600 , shown in FIG. 6 , includes a parity field 602 , a Lower Address Part (LAP) field 604 , an as yet undefined field 606 , a Scan Repetition (SR) field 608 , and a Scan Period (SP) field 610 . Also included are an Upper Address Part (UAP) field 612 , a Non-significant Address Part (NAP) field 614 , a Class of Device field 616 , the AM_ADDR field 618 , a CLK field 620 , and a Page Scan Mode field 622 . The numbers above each field indicate how many bits in the FHS packet 600 are allocated to each field. All fields in the FHS packet 600 , except the AM_ADDR field 618 (and the undefined field 606 of course) indicate properties or parameters of the BT unit that sends the FHS packet. The LAP field 604 , UAP field 612 and NAP field 614 together comprise the BD_ADDR. The Class of Device field 616 indicates the device class of the BT unit (e.g., phone, computer, peripheral). The CLK field 620 contains the current value of the BT unit's internal clock. The SR field 608 , the SP field 610 , and the Page Scan Mode field 602 are control parameters that affect the PAGE procedure. The AM_ADDR field 618 can be used to assign an AM_ADDR to a BT unit that is becoming a slave in a piconet. Otherwise, the three bits of this field should all be set to zero. The Undefined field 606 has two bits reserved for future use, which should be set to zero.

[0029] FHS packets are actually used for another purpose in Bluetooth, namely for synchronization of the frequency hop channel sequence. However, by listening for FHS packets used as INQUIRY RESPONSE messages, the BT unit that initiated the INQUIRY procedure can collect the BD_ADDR and internal clock values (both of which are included in the FHS packet) of the neighboring BT units.

[0030] Related to the INQUIRY procedure is the PAGE procedure 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. Also, knowing the internal clock value of the BT unit to be paged will potentially speed up the PAGE procedure. The paging unit can use the internal clock value to estimate when and on what frequency hop channel the neighboring BT unit will listen for PAGE messages. A PAGE message contains the Device Access Code (DAC) derived from the BD_ADDR of the paged BT unit. A BT unit receiving a PAGE message containing its own DAC responds with an identical packet containing the DAC of the paged BT unit. The paging BT unit then replies with an FHS packet that includes 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 thereby the connection between the two BT units is established.

[0031] If the paging BT unit already was the master of a piconet, the paged BT unit has now joined this piconet as a new slave unit. Otherwise, the two BT units have just formed a new piconet with the paging BT unit as the master unit. Since the INQUIRY message does not include any information about its sender (in particular, not its BD_ADDR), the BT unit that initiated 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. (See, e.g., “Specification of the Bluetooth System,” version 1.1, Bluetooth Special Interest Group.)

[0032] One of the applications contemplated for Bluetooth scatternets is their use as a wireless ad-hoc extensions to Ethernet LANs. A scatternet can be connected to a LAN through one or more Bluetooth Network Access Points (NAP). This scenario is illustrated in FIG. 7 , where the LAN 700 has a scatternet 702 connected thereto via several NAPs 704 . The scatternet 702 is similar to the scatternet 200 of FIG. 2 and will therefore not be described here. The NAP 704 is a special type of Bluetooth device that has both a wired Ethernet interface and a wireless Bluetooth interface. In order for the LAN 700 to actually be extended via the NAPs 704 , the NAPs 704 must be able to forward packets to and from the LAN on the link layer (see FIG. 5 ), i.e., it has to be able to act as a bridge between the LAN 700 and the scatternet 702 .

[0033] A problem with the above contemplated application is that the Ethernet link layers and the Bluetooth link layers are so different. Ethernet is a shared medium technology, i.e., all nodes on the LAN share the same broadcast medium. When a packet is transmitted on the LAN, all nodes connected to the LAN can receive it. The destination address of the packets, however, means that only certain nodes will respond to certain packets.

[0034] A Bluetooth scatternet, in contrast, is made up of point-to-point links. In order to overcome this difference, the NAL (see FIG. 5 ) was developed to emulate a broadcast medium, also called a shared medium. The NAL makes the scatternet appear to be part of a single, shared medium technology LAN. The goal is that all applications designed to run on top of Ethernet, or on top of IP on top of Ethernet, should work equally well (i.e., without adaptations) in a scatternet using the NAL to emulate an Ethernet LAN. Once the NAL broadcast emulation layer is in place, the nodes (BT units) in a scatternet may connect to the NAPs (hence, to the LAN) in an ad-hoc fashion.

[0035] The way the NAL emulates the broadcast medium is by making sure that broadcast type packets are delivered to all nodes in the scatternet via the point-to-point links. Unicast packets, on the other hand, are not delivered to all nodes as would be the case on a LAN, since this would waste too much of the limited bandwidth in a scatternet. Instead, unicast packets are delivered to their destination nodes by means of a routing protocol in the NAL. Hence, a unicast packet is routed through a scatternet by the NAL via one or several successive links, while still appearing to the higher layer protocols that the scatternet is a shared medium technology.

[0036] However, even with these tools, a number of problems arise. Some of these problems are due to the large difference in capacity between the scatternet and the LAN. The large difference in capacity makes a truly unrestricted extension of the LAN into a Bluetooth scatternet impractical. The scatternet would be suffocated by the traffic from the LAN. Hence, the NAPs have to employ some mechanism to restrict the traffic flowing through them. Other problems are due to the difference in how packets are delivered in the LAN compared to the scatternet. The difference in packet delivery creates a problem of matching the routing protocol of the NAL with the delivery mechanism of the shared medium of the LAN.

[0037] Still other problems are due to the ad-hoc nature of a Bluetooth scatternet. The ad-hoc nature of a scatternet creates problems when multiple NAPs are within reach of a scatternet. If the NAPs are attached to the same LAN, broadcast loops can be inadvertently created where packets can flow from the scatternet to the LAN via one NAP and continue through the LAN back to the scatternet via another NAP. If the NAPs are attached to different LANs, the problem is manifested at the IP level where each LAN constitutes one IP subnet. Generally, two different IP subnets or LANs may be connected only via a router which routes packets between the LANs on the IP layer. However, when a scatternet is connected to two NAPs that are attached to different LANs, the router is bypassed. Such bypass of the router can result in problems with IP routing, allocation of IP addresses, and uniqueness of link-local IP addresses.

[0038] One solution to the above problems involves the concept of Administrative Domains (AD). An AD corresponds to a broadcast domain, i.e., a LAN and all the nodes that are reachable from the LAN via the NAPs. The AD concept is used to prevent packets from inadvertently flowing from one LAN to another via a Bluetooth scatternet. Within the AD, the NAP is referred to as an Administrative Domain Access Point (ADAP). Each ADAP has a unique identity associated therewith. These identities are used to prevent broadcast loops when a scatternet is attached to one LAN via multiple ADAPs. In such cases, the scatternet is dynamically divided into logical areas corresponding to the ADAPs. The packets are then prevented from crossing from one logical area to another on the scatternet side.

[0039] Although the basic principles of the AD are sound, the existing AD solution nevertheless has a number of shortcomings. For one thing, the existing solution is not a complete solution to the bridging problem. In particular, it does not address the forwarding mechanism needed to couple the scatternet routing protocol with the distribution procedure on the LAN. The existing solution also does not address packet filtering to reduce unnecessary traffic in the scatternet.

[0040] Secondly, the existing AD model does not address the criteria used by a Bluetooth node for selecting an ADAP, or for changing an ADAP. It also does not address how to handle scatternet “islands” breaking loose from the bridged scatternet, or when a scatternet with two ADAPs splits into two scatternets with one ADAP each.

[0041] Finally, the maintenance of existing AD and ADAP areas are too rigid and not dynamic or flexible enough. Such rigidity may result in suboptimal ADAP selections so that the selected ADAP is not the closest one to the node, and may also result in uneven division of a scatternet where there are two ADAPs.

[0042] Accordingly, it would be desirable to be able to provide a system and method for bridging a Bluetooth scatternet and an Ethernet LAN that can overcome the shortcomings of the prior art AD model.

SUMMARY OF THE INVENTION

[0043] The present invention is directed to a system and method for bridging a point-to-point network such as a Bluetooth scatternet with a shared medium network such as an Ethernet LAN.

[0044] In general, in one aspect, the invention comprises a plurality of nodes in the scatternet and the LAN. The nodes include at least one NAP connecting the scatternet to the LAN. A filtering function is included in the NAP. The filtering function is configured to filter data packets sent from the LAN to the scatternet to eliminate unnecessary data packets from being sent to the scatternet. A bridging function is also included in the NAP. The bridging function is configured to forward certain ones of the data packets between the LAN and the scatternet. Where multiple NAPs are connected to the LAN, an inter-NAP protocol is used to exchange messages between the NAPs. Administrative domains and NAP service areas (NAPSAs) are defined, and the nodes are configured to control the borders of the administrative domain and NAPSAs to prevent broadcast loops in the scatternet and the LAN.

[0045] In general, in another aspect, the invention comprises the steps of connecting the scatternet to the LAN via the NAP, and filtering data packets sent from the LAN to the scatternet at the NAP to eliminate unnecessary data packets from being sent to the scatternet. The invention also comprises forwarding certain ones of the data packets between the LAN and the scatternet. The invention also uses an inter-NAP protocol to exchange messages where two or more NAPs are connected to the LAN. Broadcast loops are prevented from occurring in the scatternet and the LAN by defining Administrative domains and NAPSAs and controlling the borders thereof according to a broadcast type of the data packets.

BRIEF DESCRIPTION OF THE DRAWINGS

[0046] A better understanding of the invention may be had by reference to the following detailed description when taken in conjunction with the accompanying drawings, wherein:

[0047] FIG. 1 illustrates examples of Bluetooth piconets;

[0048] FIG. 2 illustrates an example of a Bluetooth scatternet;

[0049] FIG. 3 illustrates a standard Bluetooth packet format;

[0050] FIG. 4 illustrates various layers of the Bluetooth protocol stack;

[0051] FIG. 5 illustrates a Bluetooth protocol stack that includes a network adaptation layer;

[0052] FIG. 6 illustrates a standard FHS packet format;

[0053] FIG. 7 illustrates an example of a Bluetooth scatternet attached to a LAN;

[0054] FIG. 8 illustrates an exemplary implementation of a scatternet attached to one or more LANs via NAPs;

[0055] FIG. 9 illustrates the functional structure of a NAP;

[0056] FIG. 10 illustrates the broadcast areas for the NAPSA broadcast type;

[0057] FIG. 11 illustrates the broadcast areas for the scatternet broadcast type for NAL packets containing higher layer protocols;

[0058] FIG. 12 illustrates the broadcast areas for the scatternet broadcast type for NAL control messages;

[0059] FIG. 13 illustrates the broadcast areas for the AD broadcast type;

[0060] FIG. 14 illustrates the broadcast area for an ARP-route-request;

[0061] FIG. 15 illustrates the broadcast area for a non-ARP-rout-request;

[0062] FIG. 16 illustrates two exemplary routes;

[0063] FIG. 17 illustrates Ethernet and NAL packet formats;

[0064] FIG. 18 illustrates NAPSA edge nodes;

[0065] FIG. 19 illustrates the message sequence during a NAPSA switch;

[0066] FIG. 20 illustrates the INAPP message format; and

[0067] FIG. 21 illustrates the NAL message format.

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS

[0068] Embodiments of the invention provide a system and method for bridging a Bluetooth scatternet and an Ethernet LAN. Although the system and method of the invention includes a number of functional features and components, the primary components of the invention are: a packet conversion and forwarding mechanism; a packet filtering mechanism; Administrative Domains (ADs) and NAP Service Areas (NAPSAs); and an Inter-NAP protocol (INAPP). Each of these components will be introduced briefly here, then discussed in more detail below along with the other features and components of the invention.

[0069] The first main component, the packet conversion and forwarding mechanism, requires the NAP to convert and forward the packet traffic between the nodes in the scatternet and the nodes on the LAN, and vice versa. Conversion is needed because on the LAN side, data is transported in Ethernet packets (also known as Ethernet frames), while on the scatternet side, data is transported in NAL packets. Therefore, packets passing from one side to the other need to be converted between these two different packet formats. Fortunately, the conversion is a straight forward procedure, since the same MAC (Media Access Control) addresses are used in both packet formats. (Note the MAC addresses are referred to as BD_ADDR in Bluetooth devices.)

[0070] Packet forwarding on the scatternet requires the NAP to treat unicast packets and broadcast packets differently due to the limited capacity of the scatternet. Unicast packets are forwarded using the NAL routing protocol to establish individual routes, while broadcast packets are distributed using the NAL broadcast emulation mechanism. For a proper understanding of the invention, it is necessary to understand the distinction between these two packet forwarding techniques. On the LAN side, there is no fundamental difference between transmitting a unicast packet and a broadcast packet, since Ethernet is a shared medium technology. Thus, all packets are forwarded to all nodes on the LAN and individual routes are not needed. Each node then chooses whether to receive or discard a packet based on the packet's destination address.

[0071] The second main component, the packet filtering mechanism, prevents the NAP from indiscriminately forwarding every packet it receives, particularly when there is no receiver on the other side. Filtering is especially important for the scatternet, which would otherwise be flooded by traffic from the higher capacity LAN. The filtering is performed based on (1) the destination address of the packet, (2) the higher layer protocol type specified in the payload of the packet, and for packets from the scatternet, (3) the NAL packet type. The higher layer protocol type filtering is considered to be more of a configuration issue that should be handled by the network administrator and will not be discussed herein.

[0072] The third main component, Administrative Domains (ADs) and NAP Service Areas (NAPSAs), prevents packets from being sent across two or more different LANs via the scatternet. The ADs and NAPSAs can be better explained with reference to FIG. 8 . As can be seen, an exemplary network 800 according to embodiments of the invention may include a first LAN 802 and a LAN segment 802 a . The first LAN 802 may be connected to a second LAN 804 by a network router 806 (shown as a box with a circled “R”). A network bridge 808 (shown as a circled “B”) connects the first LAN 802 to the LAN segment 802 a . Scatternets 810 and 812 may be connected to the LANs 802 , 802 a and 804 to thereby extend the scope of the LANs. In particular, a single scatternet 810 may be connected to two or more different LANs 802 and 804 , or two or more different scatternets 810 and 812 may be connected to the same LAN 802 and 802 a.

[0073] The scatternets 810 and 812 are connected to the LANs 802 , 802 a and 804 via one or more NAPs, namely NAPs 1 - 5 , as shown. Scatternets with more than one NAPs are divided into different NAPSAs. Thus, in FIG. 8 , each NAP 1 - 5 has a respective NAPSA 1 - 5 associated therewith. The borders of the NAPSAs 1 - 5 (dashed lines) are defined by the nodes (not expressly shown) that belong to each NAP 1 - 5 . Each node in the scatternet can belong to only one NAPSA at a time. The purpose of the NAPSAs is to prevent broadcast loops and duplicate packet deliveries when multiple NAPs act as bridges between the same LAN and scatternet. Note that there is one pocket of nodes that does not have a NAP. These nodes may be an island 814 of nodes that does not belong to any particular NAP and, therefore, is not connected to the LANs 802 , 802 a , and 804 .

[0074] A LAN together with the NAPSAs of the NAPs that are connected to the LAN define one AD. NAPs that are attached to different LANs must belong to different ADs. For example, NAPSAs 1 - 4 define one AD, namely AD 1 , because the respective NAPs 1 - 4 are all connected to the same LAN 802 . On the other hand, NAPSA 5 associated with NAP 5 defines a different AD, namely AD 2 , because this NAP is connected to a different LAN 804 . Each AD represents one broadcast domain (as mentioned earlier) and is identified by a unique Administrative Domain Identifier (ADI). A node belongs to the same AD as its NAPSA.

[0075] If packets are bridged across different broadcast domains or ADs, problems may arise at the IP level due to bypass of the router 806 . Therefore, the NAL will not send packets containing higher layer protocols across an AD border. A packet may traverse a NAPSA border, however, provided it is not also forwarded by a NAP. This prevents broadcast loops and duplicate packet deliveries.

[0076] The fourth main component, the Inter-NAP protocol (INAPP), enables NAPs to exchange information across the LAN. This mechanism is useful both to facilitate packet filtering and to improve forwarding of packets from one scatternet to another across the LAN.

[0077] To better understand these four primary components, it may be helpful to have an understanding of the structure of the NAP and the NAL routing protocol and broadcast mechanism (which exist in all BT nodes). Reference is now made to FIG. 9 , where the functional structure of a NAP 900 is shown according to some embodiments of the invention. As can be seen, the NAP 900 includes an internal packet handling function 902 (NAP-IPH), a bridging function 904 (NAP-B), a LAN side packet filtering function 906 (NAP-PFL), a scatternet side packet filtering function 908 (NAP-PFS), and a common packet filtering function 910 . The scatternet side packet filtering function 908 includes a packet type filtering function 912 as well as an address filtering function 914 . The LAN side packet filtering function 906 does not have a packet type filtering function, only an address filtering function 916 . The above functions are all located at the NAL 926 of the NAP 900 , and may be implemented as software, hardware, or a combination of both. For nodes that are not NAPs (i.e., regular BT nodes), the NAL does not have these functions.

[0078] A packet that is received on the scatternet side of the NAP is passed through the scatternet side lower layers (shown generally at 918 ) to the packet type filtering function 912 . Note that such a packet will likely be an NAL packet, since it was received from the scatternet. The packet type filtering function 912 can pass the packet either to the address filtering function 914 or the internal packet handling function 902 , or it may discard the packet. The address filtering function 914 may also discard the packet, or it may pass the packet either to the bridging function 904 , or to the internal packet handling function 902 if the packet is addressed to the NAP itself. The bridging function 904 will in most cases forward the packet to the lower layers on the LAN side (shown generally at 920 ), but in some cases the packet may be discarded. If the packet is a broadcast packet, the bridging function 904 will, in most cases pass the broadcast packet to the internal packet handling function 902 in addition to forwarding it to the LAN side lower layers 920 .

[0079] An Ethernet packet that is received on the LAN side of the NAP is passed through the LAN side lower layers 920 to the address filtering function 916 . The address filtering function 916 can pass the packet either to the bridging function 904 , or to the internal packet handling function 902 if the packet is addressed to the NAP itself, or the packet may be discarded. The bridging function 904 will in most cases forward the packet to the lower layers 918 on the scatternet side, but in some cases the packet may be discarded. If the packet is a broadcast packet, the bridging function 904 will, in most cases, pass the broadcast packet to the internal packet handling function 902 in addition to forwarding it to the scatternet side lower layers 918 . The bridging function 904 also handles the broadcast emulation on the scatternet side as well as conversion between NAL packet format and Ethernet packet format.

[0080] A packet that originates in the higher layers 922 of the NAP will be passed via the internal packet handling function 902 to the bridging function 904 (along with packets that originate in the internal packet handling function). The bridging function 904 will consult the common packet filtering function 910 to find out whether the LAN interface or the scatternet interface, or both, will be used to send the packet. The packet is then sent via the lower layers 918 or 920 of the indicated interface(s). It should be noted that the NAP will only receive packets from the higher layers 922 if there are higher layers present in the NAP. Some NAPs, however, may only have NAP functionality, i.e., no applications functionality and, hence, no higher layers.

[0081] Referring still to FIG. 9 , an address resolution protocol (ARP) cache 924 is also included in the NAP 900 , though not in the NAL 926 . ARP is a protocol used by the IP layer of the nodes in a network to map IP network addresses to MAC addresses. The mapping of the IP address and the MAC address is then stored in the ARP cache 924 . Both the bridging function 904 and the packet filtering functions 906 and 908 have access to the ARP cache 924 . However, access to the ARP cache 924 is a feature specially designed for the NAP of the present invention. For Bluetooth devices in general, there is no such access because the ARP cache resides in the higher layers 922 in the protocol stack and, therefore, is independent of the Bluetooth specific layers. For the same reason, the NAP 900 of the present invention can be aware of or can know its own IP address, while Bluetooth devices in general cannot.

[0082] For all nodes in a network, whether in the LAN or in the scatternet, communication between any two nodes starts with the first node sending a broadcast ARP request to get the IP address of the second node translated to a MAC address. The MAC address is then used to send the message to the second node. Once an IP address has been translated to a MAC address, the IP-MAC address pair is temporarily stored in the ARP cache of the first node. When subsequent packets are to be sent to the second node, the MAC address of the second node can be retrieved from the ARP cache of the first node. Hence, the subsequent packet can be sent without a preceding ARP request.

[0083] Within each node, the ARP cache is updated or refreshed by all ARP packets received by the node that include a valid IP-MAC address pair. Each entry (i.e., address pair) in the ARP cache has a timer that is restarted every time the entry is updated or refreshed. When the ARP cache timer for a certain entry expires, the entry is removed.

[0084] In the scatternet, unicast packets are delivered by the NAL routing protocol. The NAL routing protocol used is a reactive routing protocol that can establish a route through the scatternet. A reactive routing protocol creates routes only when they are needed, as opposed to a proactive routing protocol that attempts to maintain a route to all nodes in the network at all times. There are several different reactive routing protocols designed for ad-hoc networks (e.g., the DSR protocol mentioned previously) and the specific one used is not essential for the invention. However, to simplify the description of the invention, it is assumed that the NAL routing protocol used will be based on the AODV protocol mentioned earlier.

[0085] In reactive routing, a route request message is broadcast (not unicast) in the scatternet whenever a route needs to be created. The route request message typically includes the address of the destination node. As the route request message propagates through the scatternet, temporary routes back to the source node are created (in the form of temporary route entries) in the routing tables of the nodes traversed by the message. The traversed nodes will also store the route request packet's identity, which includes the source node address and a sequence number assigned by the source node. This packet identity is used to prevent broadcast loops, as will be explained later in more detail.

[0086] The traversed node also starts a timer for the route entry, referred to as a route entry timer. The route entry timer governs how long the node will keep the temporary route entry without having received a route reply that makes use of the temporary route entry. That is, the timer effectively governs how long the node will wait for route replies for a particular route request. When a temporary route entry is first created, the route entry timer is set to a short timer interval called shortInterval, which may be a few seconds long, for example.

[0087] When a route request message reaches the destination node, the destination node returns a route reply. The route reply is unicast (not broadcast) along the same path used by the particular route request to reach the destination node, guided by the temporary route entries of the various nodes along the way. As the route reply is forwarded to the source node, a route is established in both directions. The route entry timer in each node along the path is then set to a significantly longer time interval longInterval which may be a minute, for example. Thus, the only difference between a temporary route entry and a regular route entry for an established route is the duration of the route entry timer.

[0088] The route request message will accumulate a hop count, which is the number of hops that it has made. Each intermediate node traversed counts as one hop. The route reply message includes the total hop count accumulated by the route request message. An intermediate node can thus calculate the hop count to the destination node by subtracting the hop count to the source node (received in the route request and stored in the temporary route entry) from the total hop count (received in the route reply).

[0089] The temporary route entries in all other nodes through which the route reply did not pass are timed out upon expiration of the respective route entry timers and removed along with the route request's identity. In the nodes along the route from the source node to destination node, the created route entries mainly include the address of the destination node, the address of the next node in the route, and the hop count to the destination node. Similarly, in the other direction, the created route entries include the address of the source node (which is the destination node for packets sent in this direction), the address of the next node in the route, and the hop count to the source node (which is the destination node for packets sent in this direction).

[0090] At the sending node, the start of a route request initiates a timer, denoted route reply timer. The route reply timer governs how long the sending node will wait for a route reply. If the timer expires, the node usually resends the route request and restarts the timer for a predetermined number of times until a route reply is received. If no route reply has been received after the maximum number of repeated route requests have been sent, all packets that were waiting for the route to be established are discarded, and an indication of this may be passed to the higher layers. To simplify the description of the invention, however, it is assumed that a node will send only one route request. When the route reply timer associated with this route request expires, the node gives up. The timeout period of the route reply timer should preferably be the same as for the route entry timer for temporary route entries, or perhaps somewhat longer. For example, the route reply timer could be started at the value routeReplyTimeoutPeriod=1.2×shortInterval.

[0091] When a route reply is received, the receiving node checks its routing table to see whether it already has a route entry for the node that sent the route reply (i.e., the destination node). If yes, the hop count of the old route entry is compared with the one in the received route reply. If the hop count in the received route reply is smaller than or equal to the hop count of the old route entry, the old route entry is replaced with a new one. If no route entry was found, the node creates a route entry for the node that sent the route reply. In either case, the node starts a route entry timer for the new route entry with the value longInterval. If the hop count in the received route reply is greater than the one in the old route entry, the old route entry is kept.

[0092] If the route reply was addressed to the receiving node itself, the receiving node does not need to do anything else. Otherwise, the node checks its routing table to see whether it has a route entry for the node to which the route reply is addressed (i.e., the source node). If yes, the node restarts the route entry timer for the found route entry with the value longInterval, and forwards the route reply to the next node indicated by the found route entry. If no route entry is found, the route reply is discarded.

[0093] Thus, when a packet is subsequently transmitted from the source node to the destination node, the only information needed in the packet for routing purposes is the address of the destination node (and likewise in the other direction). Every time an existing route entry is used to route a packet, its route entry timer is restarted with the value longInterval.

[0094] If a node that already has a route entry for a certain destination node receives a route request for that destination node, it may return a route reply, even though it is not the destination node. Hence, some nodes may receive several route replies to the same route request (recall that the route request message was broadcast to all the nodes in the scatternet). These nodes will initially use the route that is established by the first route reply. If a subsequent route reply is received that has a lower hop count to the source node, the receiving node will replace the existing route with the new route.

[0095] Hop count comparison is also performed in the handling of route request messages. In general, when a node receives a route request, it checks to see whether a route entry back to the source node already exists. If yes, the hop count of the existing route entry is compared with the hop count in the route request. If the hop count in the received route request is greater than that of the existing route entry, the existing route entry is kept. If the hop count in the received route request is smaller than the hop count in the existing route entry, or if they are equal, the existing route entry is replaced with a new route entry. When this happens, a route entry timer for the new route entry is started using the current value of the route entry timer for the existing route entry. In essence, the new route entry timer is a continuation of the existing route entry timer.

[0096] The node receiving the route request may also check to see whether the current route entry timer value of the existing or the new route entry is less than shortInterval. If yes, the node may restart the route entry timer at the value shortInterval.

[0097] If no route entry for the source node was found in the receiving node, the receiving node creates a new route entry for the source node. A route entry timer for this new route entry is then started at the value shortInterval (i.e., the new route entry is a temporary route entry). The node then checks to see whether it has a route entry for the destination node of the route request (unless the route request is addressed to the receiving node itself). If yes, the node restarts the route entry timer for the destination node route entry using the value longInterval and returns a route reply to the source node. If the node does not have a route entry for the destination node, it forwards the route request to its neighbors (except, of course, the neighbor from which the route request was received).

[0098] If the route request is addressed to the receiving node itself, the receiving node either creates a new route entry for the source node, replaces an existing one, or keeps the existing route entry (according to the hop count comparison procedure described above). It then starts the timer of the route entry for the source node at the value longInterval and sends a route reply to the source node using the route entry for the source node.

[0099] A node may have several route entries to different source and destination nodes stored. These route entries are together called a routing table and are stored in a memory area that is accessible to the NAL entity in the BT node. (The NAL entity is a software and/or hardware based functional entity that handles the NAL functionality.) When a route entry's timer expires, the route entry is removed from the routing table. Thus, if a route entry has not been used for routing a packet for a time equal to longInterval, the route entry is timed out and removed.

[0100] Sometimes a route “breaks” before it is timed out. This happens when one of the links along the route is broken or otherwise becomes no longer available. There are two mechanisms to deal with route failures. The first mechanism is triggered by detection of a link loss. When a node with more than one link established detects that the link to one of its neighbors is lost, it checks to see whether it has any entries in its routing table that indicate the now unreachable neighbor as the next hop node. If yes, the node will remove these route entries.

[0101] If any of the node's remaining neighbors also use any of the broken routes, the node sends a “route failure” message to those of its remaining neighbors that are affected by the route failures. Referring back to FIG. 7 , the neighbor nodes are the nodes that are directly connected to each other (illustrated with a solid line). The route failure message includes the destination addresses of all the broken routes that are used by the particular neighbor. These neighbors will then, in turn, check to see if they have any affected route entries and, if so, remove the affected route entries and forward the route failure message to their affected neighbors (if any). Before the route failure message is forwarded, its content is updated to reflect the affected routes. In this way, the route failure message is propagated to all the affected nodes in the scatternet.

[0102] Before sending the route failure messages, a node needs to know which of its neighbors are affected by the route failure. This information is required to prevent the node from indiscriminately forwarding the route failure message to all neighbors. In the NAL routing protocol, the issue is resolved by associating a dependent neighbors table with each affected route entry in the node. The nodes in the dependent neighbors table are the upstream nodes that are dependent on the present node to provide the next hop in any route. Every time a node forwards a route reply (or sends a proxy route reply) for a certain route, the neighbor to which the route reply is sent is included in the forwarding node's dependent neighbors table. The table is then associated with the route entry for the route in which the neighbor is an upstream node (i.e., the route to the destination node in this case). In addition, the neighbor from which the route reply was received (unless it was a proxy route reply) is included in the table, and the table is associated with the route entry for the opposite route (i.e., the route to the source node). Using these dependent neighbors tables, the node can keep track of which of its neighbors depend on each of the node's routes.

[0103] Table 1 below illustrates an example of a dependent neighbors table for node M 4 , referring once again to FIG. 7 . It should be emphasized that Table 1 is exemplary only (i.e., only the parameters relevant for illustrating this feature have been included), and that other formats may certainly be used. As can be seen, each route entry in node M 4 lists a destination node, a next hop node, and zero, one or more dependent upstream neighbor nodes. In the route entry for node M 1 , for example, node S 1 is listed as the next hop node, and nodes S 2 and S 3 are listed as the dependent upstream neighbor nodes. Nodes S 2 and S 3 are listed because these are the nodes to which node M 4 has sent route replies concerning node M 1 . When a break is detected between node M 4 and the next hop node, node S 1 , node M 4 sends a route failure message (also called a route error message) to node S 2 indicating that the route to node M 1 is broken. Node M 4 also sends a route failure message to node S 3 indicating that the routes to both node M 1 and node M 3 are broken, since these are the affected route entries for which node S 3 is indicated as a dependent upstream neighbor node. In this way, node S 3 can know all the route entries that are affected by the break. 1

	TABLE 1
	Destination	Next Hop	Dependent
	Node	Node	Upstream Neighbors
	M1	S1	S2, S3
	M3	S1	S3
	...	...	...
	M9	S2	S1, S4

[0104] Note that the dependent neighbors table informs the upstream neighbors only. There is presently no way to inform a downstream neighbor that one of the routes of the downstream neighbor is no longer available. Therefore, no neighbors will be removed from the dependent neighbors table, except when the link to such a neighbor is broken (and the whole table will of course be removed when the route entry is removed). Thus, the table may sometimes contain neighbors that actually are no longer dependent on the associated route entry. Consequently, the route failure message may sometimes be needlessly sent to unaffected neighbors. Nevertheless, the dependent neighbors tables still serve to significantly limit the number of nodes to which a route failure message is propagated.

[0105] The above described NAL routing protocol must be coupled with ARP in order to bridge a Bluetooth scatternet with an Ethernet LAN. That is to say, the NAL routing protocol must be able route an ARP request through the scatternet in order to bridge a scatternet with a LAN. Therefore, the ARP request is included, or piggybacked, in a NAL route request. The ARP reply (if any) will likewise be piggybacked on a NAL route reply. The result is that when the IP address of the destination node is translated to a MAC address, the route through the scatternet is already established so that subsequent packets can be delivered without a route request. To achieve this end, the NAL includes functionality to monitor or “snoop” every ARP packet it receives from the higher layers before the ARP packet is sent.

[0106] Regular route requests (without piggybacked ARP requests) will of course still be used. For example, when the MAC address of the destination node is known (e.g., from the ARP cache), there is no need to send an ARP request. In this situation, a regular route request will be sent if the node does not already have a route entry for the destination node.

[0107] The piggybacking of ARP requests on route requests and ARP replies on route replies is well known and, therefore, will be described only briefly here. For convenience, a route request with a piggybacked ARP request will be referred to as an “ARP-route-request,” while a route request without a piggybacked ARP request will be referred to as a “regular route request” or a “non-ARP-route-request”. The term “route request” will henceforth refer to any route request generally, with or without an ARP request piggybacked thereon. Similarly, a route reply with a piggybacked ARP reply will be referred to as an “ARP-route-reply,” while a route reply without a piggybacked ARP reply will be referred to as a “regular route reply” or a “non-ARP-route-reply.” The term “route reply” will henceforth refer to any route reply in general, with or without an ARP reply piggybacked thereon. ARP requests and ARP replies will continue to be referred to as such.

[0108] When a node sends an ARP-route-request, it follows the same procedure as previously described for a node sending a regular route request. An ARP-route-request would be sent instead of a regular route request when the IP address of the destination node is known, but not the MAC address. Thus, the only difference between a regular route request and an ARP-route-request is the ARP-route-request does not contain the MAC address of the destination node (since this address is not known). In addition, only the destination node can reply to an ARP-route-request. Proxy replies by intermediate nodes (as is the case for regular route request) are not allowed. This means that in a stand-alone scatternet or a scatternet connected to only a single NAP, a node can (in most situations) receive only one ARP-route-reply to an ARP-route-request. Reception of more than one ARP-route-reply by a node indicates that more than one node is using the same IP address. Such an error would be obvious also from the fact that the MAC addresses of the nodes sending the route replies would be different. However, in a scatternet connected to more than one NAP, it is perfectly normal to receive two ARP-route-replies in response to the same ARP-route-request (as will be explained later).

[0109] All nodes that receive an ARP-route-request will pass it to the higher layers where the request can be processed by the ARP entity, which is a software and/or hardware based functional entity that handles the ARP protocol and the ARP cache. This occurs regardless of whether the node forwards the ARP-route-request or terminates it (e.g., when the receiving node itself is the destination node of the ARP-route-request). The ARP entity will then update or refresh the ARP cache with the IP address and MAC address of the node sending the ARP request. The receiving node will also reply to the ARP request if it happens to be the destination node.

[0110] In addition, when a node receives an ARP-route-request, it checks whether a route entry for the source node already exists. If yes, the hop counts of the current route entry is compared with the one in the received ARP-route-request. If the hop count in the received ARP-route-request is greater than that of the current route entry, the current route entry is kept. If the hop count in the received ARP-route-request is smaller than the hop count of the current route or if they are equal, the current route entry is replaced with a new one. The route entry timer of the new route entry is then started at the current value of the route entry timer of the existing route entry. Regardless of which route entry is used, if the current value of the route entry timer for the route entry is less than shortInterval, the node may restart the timer at the value shortInterval. If no route entry was found, the node creates a new route entry for the source node and starts the route entry timer for this new route entry at the value shortInterval (i.e., it makes the