WO2002043335A1

WO2002043335A1 - A method and system for bridging mobile ad-hoc networks

Info

Publication number: WO2002043335A1
Application number: PCT/SG2000/000204
Authority: WO
Inventors: Luying Zhou; Radharkrishna Pillai Raghavan Pillai; Jit Biswas; Eng Hwa Teo
Original assignee: Kent Ridge Digital Labs
Priority date: 2000-11-24
Filing date: 2000-11-24
Publication date: 2002-05-30

Abstract

This proposed mobile ad hoc network bridging method routes packet at the data link layer instead of at the IP network layer. This method includes two major parts. The first part is a bridge election method, by which bridges are elected based on two-hop neighborhood information and the elected bridges are consistent to all nodes in the network. The second part is a packet (frame) forwarding method, by which the elected bridges are responsible for relaying frames and there is no requirement for a node to find a route before it can send data message.

Description

A METHOD AND SYSTEM FOR BRIDGING MOBILE AD-HOC NETWORKS FIELD OF INVENTION

The present invention relates to communication networks in which there is no direct wireless link between two communicating nodes, such as Mobile Ad Hoc Networks (MANETs), but also to Wireless WAN, Wireless Bridging, and Infrastructureless Networks. In particular, in these networks the transmission range of a node is limited and the topology of the network is also dynamic, i.e. not fixed.

Overall the present inventive aspects provide an alternative to the network routing of the prior art fixed networks. The inventive aspects relate to method (s) of bridging election and frame forwarding. BACKGROUND ART 1.1 Mobile ad hoc networks

A mobile ad hoc network (MANET) is a collection of wireless mobile nodes dynamically forming a network without the use of any existing network infrastructure. In a MANET, there is no predetermined topology or central control, and it does not rely on a pre-existing fixed infrastructure, such as a wireline backbone network or a base station. The responsibilities for organising and controlling the network are distributed among the nodes themselves. The entire network is mobile, and the individual nodes are allowed to move at will relative to each other. Each mobile node in the MANET operates not only as a host but also as a router, as some pairs of nodes may not be able to communicate directly with each other and may require other nodes to relay messages. MANETs have several salient characteristics: • Mobility of nodes, dynamically changing topology: Nodes are free to move arbitrarily; thus, the network topology (which is typically multihop) may change randomly and rapidly at unpredictable times. • Flat addressing: Nodes are unable to form a subnet and to have subnet addresses. • Energy-constrained operation: Some or all of the nodes in a MANET may rely on batteries for energy. For these nodes, power conservation is a critical design criteria.

• Wireless vulnerabilities and limited physical security. Mobile wireless networks are generally more prone to information and physical security threats than the fixed, hardwired networks.

A MANET can be used in military, rescue and emergency applications, where either there is no other wireless communication infrastructure present or such infrastructure cannot be used because of security, cost or safety reasons, or it can operate as robust and inexpensive alternative or enhancement to the cell-based mobile network infrastructures.

Commercially, MANET technology may be used to extend the range of WLAN technology over multiple radio hops. , Networks that cover areas of several square kilometres could be built from WLAN technologies such as HiperLAN and IEEE802.11. People and vehicles can thus be internetworked in areas without a pre-existing communication infrastructure, or when the use of such infrastructure requires wireless extension. On smaller scales, technologies like Bluetooth can be exploited in various ways to build embedded wireless networks. These networks could have a combination of static and mobile nodes, which could be fielded without cabling and with minimal pre-configuration. As computing and communication devices proliferate and the requirements of highly adaptive mobile networking technology increase, unforeseen uses of this technology are likely to emerge, particularly in the embedded systems and micro-networking fields. 1.2 Challenges to mobile ad hoc network routing

Traditionally, end user devices, such as host computers or telephones, attach to the networks at fixed locations. As a consequence, they are assigned addresses based on their location in a fixed network-addressing hierarchy and oftentimes assume an identity equivalent to their address. This identity-location equivalence greatly simplifies routing in these systems, as a user/router's location does not change. In mobile ad hoc networks, however, the routing infrastructure can move along with the end devices. Thus the infrastructure's routing topology can change, and the addressing within the topology can change. Given the fundamental change in the composition of the routing infrastructure, much of the fixed infrastructure's control technology is no longer useful. The infrastructure's routing methods and, indeed, much of the networking suite must be reworked to function efficiently and effectively in this mobile environment.

There is a MANET working group, which can be referenced at, http://www.ietf.org/html.charters/manet-charter.html and which discloses Internet-Drafts, such as:

Ad Hoc On Demand Distance Vector (AODV) Routing;

Temporally-Ordered Routing Algorithm (TORA) Version 1 Functional

Specification;

The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks; • On-Demand Multicast Routing Protocol (ODMRP) for Ad-Hoc Networks;

Optimized Link State Routing Protocol;

INSIGNIA;

Relative Distance Micro-discovery Ad Hoc Routing (RDMAR) Protocol;

SOURCE TREE ADAPTIVE ROUTING (STAR) PROTOCOL This working group in the lETF's Routing Area is chartered to provide improved mobile routing and interface definition standards for usage within the Internet Protocol Suite. All proposed routing protocols for mobile ad hoc networks are developed in the network (IP) layer.

M. Gerla, J.T. Tsai, "Multicluster, mobile, multimedia radio network," Wireless Networks, No.1 , 1995, pp255-265 discloses that in the formation of cluster and election of cluster header the purpose is to allow the cluster header to coordinate the node activities within the respective cluster. Within a cluster, a cluster header can hear every other node directly but a node may not hear every other node directly. Cluster headers in different clusters should not be directly linked. Another set of nodes, called gateway nodes which can hear two or more cluster headers, are required to connect different clusters. It is an object of the present invention to address a problem associated with prior art MANETs or improve bridging methods or packet forwarding methods.

SUMMARY OF INVENTION

With this in mind, the present invention provides a mobile ad hoc network bridging method by which the routing function is realised at the data link layer. This bridging method includes two inventive aspects: bridge election and frame forwarding. The purpose of bridge election is to elect the minimum number of bridges that can facilitate mobile node communication by connecting all the nodes in the ad hoc network together. Based on the elected bridges and formed segments, the frame forwarding method will use conventional bridging concept and can be as simple and reliable as possible.

Thus, in one aspect, the present invention provides in a mobile ad hoc network having a plurality of mobile and/or fixed user terminals or nodes, a method of determining a bridging node to be used for bridging between a first and a second node, the method including the step of: a) arranging neighbor node information in a two-hop table; and b) selecting as the bridging node, a node which is listed in the table as being available for connection to highest number of other nodes, including the first and second nodes.

Preferably, the selection is in accordance with a bridging algorithm as herein disclosed.

In another aspect, the present invention provides in a mobile ad hoc network having a plurality of mobile and/or fixed user terminals or nodes, a method of bridging between a first and a second node, the method including the step of: a. obtaining a destination address from either a two-hop table or from learning route cache; b. compiling a frame for forwarding to the destination (second) node; c. unicasting the frame to the second node. The present invention further provides a mobile ad-hoc network having a plurality of mobile and / or fixed user terminals or nodes adapted to carrying out the method as disclosed herein.

The present invention stems from taking into account the flat addressing features of mobile ad hoc network, where it can be noticed that the packet routing at the IP layer has to be based on the unique address of the destination node instead of its subnet address as is he case with wired IP networks.

Furthermore, if ad hoc network routing can be realised at the data link layer, then the data link layer frame forwarding, or bridging, method is expected to be faster and more efficient compared to the IP layer routing, due to the following reasons:

• no network layer processing and hence better performance

• independent of network layer protocols

• low power consumption due to simpler protocol processing DESCRIPTION OF PREFERRED EMBODIMENT

A preferred embodiment of the present invention will now be described with reference to the accompanying drawings, in which:

Figure 1 illustrates a topology of a mobile ad-hoc network,

Figure 2 illustrates a schematic equivalent representation of the topology of Figure 1 , and

Figures 3a to 3i illustrate an example of two-hop neighbor tables kept at each node, and in which the elected bridge node is marked with the '*' symbol. 3 Bridge election method

In mobile ad hoc networks, there are no specified nodes that serve as routers and the network topology changes dynamically. In order for a node to communicate with another node that is beyond its signal transmission range, some nodes in between are required to relay the message for them.

In the present specification, the term bridge is used to denote the node which relays message, and the term segment is used to denote a group of nodes which are within the same signal transmission range, i.e., they can hear each other using a single hop of transmission. Whilst it is desirable to use the known bridge concept from wired networks, where bridges are dedicated devices which connect LAN segments, there are problems of forming segments and electing bridges if the concept is applied to bridging mechanisms in the mobile ad hoc networks. Assuming that every node in the mobile ad hoc network is able to serve as a bridge, and the links are symmetric, the definitions of segment and bridge are as follows:

• Segment is formed by a group of nodes in such a way that each node can reach every other node in the same group through a single hop transmission;

• Bridge is a node that belongs to two or more segments at the same time. A node may also belong to different segments and bridges link different segments. There are two addresses associated with each node, one is layer 2

MAC address and another is layer 3 IP address. In the bridging method of the present invention, the packet routing (frame forwarding) will be based on node's

MAC address.

The purpose of the proposed segment formation and bridge election method are different from that of cluster formation as referred to in the prior art.

3.1 Bridge election procedure 1) A Periodical beacon message is necessary for each node to probe its neighbors. The frame format of the beacon message for a node, assuming node

1 (one), is, for example, as follows:

Where MAC and IP_1 are node 1's MAC address and IP address respectively. The beacon message is broadcast to all the neighbor nodes to notify them the IP address and MAC address of the sending node. 2) Each node keeps a neighbor list which includes all the neighbor nodes that it can communicate with. Assuming the maximum size of a neighbor list is N, the format of the neighbor list for the node with IP address IP_1 and MAC address MAC_1 is, for example, given by:

Where MAC_x and IP_x are its neighbor's MAC address and IP address respectively.

3) Each node broadcasts its neighbor list to its neighbors if any entry in the list has changed since last broadcasting. The frame format of the neighbor list message for the node 1 (one) is, for example:

4) Each node builds up and keeps a two-hop neighbor table based on the neighbor list(s) received from its neighbors, and the two-hop neighbor table for node 1 (one) has an exemplary form:

In this table, the first row represents node 1 and its neighbours, and each other row represents a neighbour list of its neighbours. Preferably, the node also keeps a corresponding IP address table in order to facilitate the mapping between IP and MAC addresses within the two-hop neighbourhood. There is a trade-off between keeping this table in the node and requesting IP to MAC mapping when required.

5) Each node elects bridges independently based only on its two-hop neighbor table through the following bridge election method. 3.2 Bridge election method

Bridge election procedures are carried independently by each node. The two-hop neighbor table of node 1 (one) is shown here again:

row 1 row 2

row N

Assuming the rows in the table are arranged in the order from longest to shortest, from top row to bottom row, and in the case of the rows with the same length, the row with smaller MAC address in the first column will be positioned higher. Importantly, the bridge election procedures seek to find the minimum number of bridges that can cover maximum number of nodes. Accordingly, a node is elected as bridge if it connects the highest number of nodes, i.e., the longest row, or it connects node(s) that is not connected by the previously elected bridge node(s).

It should be noted that the arrangement of the two-hop neighbor table as indicated above is not mandatory. If the table was otherwise arranged, or even randomly arranged, the present invention contemplates election so that the minimum bridges are sought or determined with the maximum number of nodes. Assuming that:

S: set of nodes;

R,-: set of nodes in row i; B: set of elected bridges;

Rj\S: set of all nodes in Rj that are not in S;

The bridge election method is as follows:

S= Rι;

B={MAC_1}; for (j=2; j<= N; j++)

{ if ( R_jΛS ≠0 )

{ B=Bu{MACJ}; S=S R_j; }

} The elected bridge nodes are in set B. This method seeks all nodes in the network to obtain consistent elected bridge information from their respective two- hop neighbor tables. 3.3 Other aspects of bridge election method

In this bridging method, it is assumed that the network has symmetric links, which means if a node (node A) can hear another node (node B), then B can also hear A, and bridge election is proceeded under this condition. However if the symmetric link condition can not be met temporarily for some reason, such as by way of signal interference, then the bridge election method may experience a convergence problem. For example, if node A just joins the network and can hear node B, but B can not hear A, then it is possible that A receives a neighbour list, broadcast by B, in which A is not included. In such a situation, the nodes (node A and B's neighbour nodes) may elect bridges that are not consistent. Only after B broadcasts its updated neighbour list in which A is included, will the elected bridge be consistent. On the other hand, if A is already in B's neighbour list and B fails to receive A's beacon message, the fluctuation in electing consistent bridges can be prevented in the following way. The node B will wait for A's beacon message for same time in order to make sure that A has actually left instead of immediately broadcasting a updated neighbour list without A in it. 3.4 Example of bridge election

Figure 1. illustrates a topology of a mobile ad hoc network, and Figure 2 schematically illustrates the segments and bridges of the topology of Figure 1.

In Figure 3a to Figure 3h, a number of tables are used in illustrate one example implementation of the present invention, and with reference to Figures 1 and 2.

Table 3a shows with a '*' designation, the nodes elected at node A1. Table 3b shows with a '*' designation, the nodes elected at node A2.

Table 3c shows with a '*' designation, the nodes elected at node A3.

Table 3d shows with a '*' designation, the nodes elected at node A4.

Table 3e shows with a '*' designation, the nodes elected at node B1. Table 3f shows with a '*' designation, the nodes elected at node B2.

Table 3g shows with a '*' designation, the nodes elected at node C1.

Table 3h shows with a '*' designation, the nodes elected at node C2.

Table 3i shows with a '*' designation, the nodes elected at node D1. 4. Bridging method Once the bridges have been elected, nodes can start sending data frames to the nodes not in the same segment via these bridge nodes. The bridge node will act to relay the frames that can not directly reach the destination node from the source node. A non-bridge node is not responsible to relay other node's frames. In a conventional bridging concept, where bridges are connected by wired lines, the bridge relays the frame to a specific segment through corresponding interface or port, without modifying any field in the frame. But it is different in the wireless environment. Since all bridges within the transmission range could hear the frame, the frame needs to be modified to indicate the intended bridge. General frame format

An example of a general frame format is as follows, but noting that some fields may be only present in certain frame types:

Contents of the frame fields: Message Type: distinguishing different control and data frames;

Receiver, the MAC address of a bridge who will receive the frame immediately; Transmitter, the MAC address of a bridge who is transmitting the frame currently; Destination: the MAC address of the ultimate destination node; Source: the MAC address of the source node; Sequence number, a number set by the source node and incremented by one each time when a new frame is generated; PDU: Protocol Data Unit from higher layer.

4.1 Procedures of the bridging method In one example implementation of the invention, the procedures of the bridging method are outlined as follows:

1) Obtain the destination node's MAC address. Since a source node usually only knows the IP address of the destination node to which it wants to send messages, a mapping from IP address to MAC address as is required for the bridging method is based on the MAC addresses. This can be done by a) checking whether the destination node is within two-hop neighborhood, if both the two-hop neighbor table and its corresponding IP address table are kept in the node, then the IP to MAC address mapping for the node within the two-hop neighborhood can be done by simply checking the two tables, otherwise b) requesting the MAC address by broadcasting an MAC address requesting frame.

2) Send data frames. After a source node having obtained the MAC address and formed a data frame, or a bridge received a data frame, the node/bridge can send data frames to its destination node a) directly, if the destination node is its neighbor; b) via a bridge, if the destination node is within the two-hop neighborhood, otherwise c) via learnt route, if there is a learnt route in the node's or bridge's cache, otherwise d) via multicasting to other bridge(s).

4.2 Backward route learning

A Learning bridge approach is adapted in this embodiment of the inventive method, which enables a bridge to learn the route from each received frame and store the learnt route in its cache, and thus not being required to apply explicit route discovering. When receiving a frame, and by looking at the source address and the transmitter address, a bridge can derive the information that a node with that source address is accessible through the bridge with that transmitter address. The bridge will record that source address and the transmitter address information in its cache for the purpose of routing frames destined to a node with that source address. A destination node can also maintain such learnt information from the received frame. Each entry in the table is only kept for certain time period in order to take into account the mobility of the nodes.

The strategy used by the bridge is as follows:

• the bridge listens promiscuously, receiving every frame transmitted; • for each frame received, the bridge stores the address in the frame's source address field in a cache, together with the address in the transmitter's field;

• the bridge ages each entry in the station cache and deletes it after a period of time in which no traffic is received with that address as the source address.

4.3 Requesting destination node's MAC address

In order to obtain MAC address of a destination node outside the two-hop neighborhood, a source node sends a broadcast ReQuest MAC address frame (RQM) to all the nodes in the network. Unlike broadcasting, where every node is responsible for rebroadcasting the received frame, the number of nodes which rebroadcast the frame here is limited to the bridge nodes, thus it can be more efficient and bandwidth saving. The preferred format of the RQM message is of the form:

Message Broadcast Transmitter Source MAC Sequence Destination Source Type MAC address MAC address Address number IP address IP address

When receiving this broadcast RQM frame, a node, bridge or non-bridge node, records the source MAC address and Sequence number and checks whether the frame is a duplicate one. Duplicate RQM is simply discarded. The learnt route information is also stored in the node's cache. The bridge node is responsible to rebroadcast this RQM frame. Also, the node will compare its IP address with the Destination IP address in the frame and, if it matches, it will unicast a RePly MAC address frame (RPM) to the requesting source node. The preferred format of the RPM message is of the form:

Example: Let's illustrate the broadcasting method based on the Figure 1.

Node C1 wants to get node D1's MAC address, it broadcasts the following frame:

Nodes C2 and A1 will receive this frame and process it but only bridge node A1 will rebroadcast the frame:

Nodes C1, C2, A2, A3, and A4 will receive this frame. Nodes C1 and C2 will identify this frame as a duplicate frame and will not process it. Only bridge node A3 will rebroadcast the frame:

Nodes A1 , A2, A4, B1 and B2 will receive this frame. Nodes A1 , A2, A4 will discard this frame as it is a duplicate frame, and only bridge node B2 will rebroadcast the frame:

At the same time, bridge node B2 stores the route information learnt in its cache:

Destination node: C1 Next bridge node: A3 When node D1 receives and processes this broadcast frame, it will identify itself as the intended destination node and will reply by unicasting a RPM message to the source node C1 through the learnt route. 4.4 Sending Frames

After the node S has obtained the MAC address of destination node D, it will send the data frame according to following procedures. While the frame is being sent or relayed, some fields in the frame (e.g., receiver and transmitter field) may be omitted or the value be changed. 1) If D is a neighbor node, then it sends the frame to D directly.

where XJvlAC represents the MAC address of node X.

2) If D is in the two-hop neighbor table but is connected to its neighbor(s), then one of the neighbors must have been elected as bridge already, it inserts the MAC address of the bridge which connects D into the frame, and the frame is in the form;

a) When the bridge receives this frame, it will check the destination address DJMAC, by examining its two-hop neighbor table it will relay the frame to D in the following format:

3) If the destination node D is not in the two-hop neighbor table, then the node looks through its station cache for the address listed in the frame's destination address field. a) If the address is found in the station cache, it sends the frame to the corresponding bridge. The frame is in the following format:

a.1) When the bridge receives this frame, it will check the destination address D_MAC, by examining its two-hop neighbor table first and then its station cache it will relay the frame further to other bridge in the following format: ;

a.2) or if the destination node is not in the two-hop neighbourhood and no route in the cache leading to it, this frame will be multicast as described in the following b). b) if the address is not found in the station cache, then the data frame is multicast to bridge(s) by the node or bridge in the following general frame format.

Where the multicast address is a special group address, it addresses all currently elected bridges. This data frame is handled in the same manner as an RQM frame to prevent bridge from re-multicasting duplicate data frame, but source address, sequence number as well as destination address are used.

The bridges receiving this data frame will relay the frames in the way as described in 2 a), 3 a.1) and 3 b) above in Section 4.4. If the destination node is still connected by bridge(s) in the network by the time data frame being transmitted, then one or more bridges may find the destination node in its two- hop neighbor table and deliver the data frame to it ultimately. 4.5 Other aspects of the bridging method Loop preventing

The bridge keeps the latest Sequence number of each S_MAC, D_MAC pair and checks S_MAC, D_MAC and Sequence number in the incoming frame to discard duplicate frames in the case when frame is broadcast. Sequence number approach aims to have that frame travel each link only once, so that frame transmitting loop can not be formed in the, network. Storage requirement on the node

In order for the node to tell whether a frame is duplicate, the sequence number in the frame along with source node and destination node pair are required to be stored in the node. Assuming that there are N nodes in the ad hoc network, it would require up to N^*N entries for each node to store this information in the case that all nodes are active and communicate with each other. But the actual storage requirement is greatly reduced due to the fact that the node only needs to store this information for the frame with a broadcasting or multicasting address. This is because, if the route is known, through two-hop neighbor table or learnt route, then the frame is forwarded by unicasting and it will not generate duplicate frames. As the bridging method is mainly based on unicasting approach, the amount of storage related to broadcasting or multicasting frames is limited, and furthermore each entry is only kept for a fixed time. Two-hop neighbor table look up

The bridging method requires that the two-hop neighbor table be searched for the destination node address each time a frame to be sent or relayed (procedure 2) in Section 4.1). This measure enables the method to adapt to the dynamic of the mobile ad hoc network more quickly, this is because the two-hop neighbor table captures the newest local network topology information. A non-bridge node is not responsive to relay frames, it only accepts frames which are unicast or broadcast to it and does not need to search its two- hop neighbor table. Only bridge node will search the table if it receives a frame to be relayed. The table look up operation can be sped up by limiting to a few rows instead of the whole table.

For example, if bridge node A3 receives a unicast or multicast frame 1) if the frame is from bridge node A1 , it only needs to search the bridge sitting rows except the bridge node A1 sitting row. It searches its row first for directly reachable destination node, then searches bridge node B2 sitting row. A3:

2) if the frame is from non-bridge node A2, again it only needs to search A3 sitting row first and then B2 sitting row. Because bridge node A1 is in the same row with A2, A1 has received the same frame. The elements of the rows may be arranged in a way that the search operation can be further reduced.

5. Advantages

The proposed bridge election method elects bridges that are consistent to all nodes in the network and enables nodes, through the bridges, to communicate with other nodes beyond their transmission ranges. To elect bridges, the method requires each node to maintain a two-hop neighbour table. Based on the elected bridges, a bridging method in mobile wireless networks is provided, which acts similar to conventional wired network bridging methods. This bridging method prevents frame transmission loop and has the ability to learn routes. Advantages:

1. packet routing (frame forwarding) is conducted at data link layer, so independent of network layer protocols;

2. do not deliver received frame to network layer for routing processing, so act faster and have less protocol overhead;

3. no periodic route table information exchange: each node broadcasts only its neighbor list and only under the condition that neighbor list has changed;

4. consistent bridge information is obtained through local node information; 5. do not require route discovery before sending the frames;

6. frame can reach destination node through more than one route when the frame is sent by multicasting, more robust and reliable;

7. better utilize data link layer protocol information; 8. by obtaining destination node address from two-hop neighbor table, can adapt to node mobility quickly;

9. by obtaining destination node route information from route cache, can unicast frame to its destination node ; thus can avoid multicasting, and it is possible to save bandwidth and prevent other nodes from unnecessar processing;

10. multiple bridges can be allowed to connect two segments for the purposes such as balancing traffic load;

11. based on the elected bridges, the frame can be broadcast to its destination node in the same manner as pure broadcasting, but the number of nodes who rebroadcast the frame is limited to the number of bridge nodes, hence it is more efficient and bandwidth saving than pure broadcasting;

12. low energy consumption.

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:

1. In a mobile ad hoc network having a plurality of mobile and/or fixed user terminals or nodes, a method of determining a bridging node to be used for bridging between a first and a second node, the method including the step of: arranging neighbor node information in a two-hop table; and selecting as the bridging node, a node which is listed in the table as being available for connection to highest number of other nodes, including the first and second nodes.

2. A method as claimed in claim 1 , where the selection of bridging node is in accordance with the algorithm:

S= Rι;

B={MAC_1}; for 0=2; j<= N; j++)

{ if ( R_j\S ≠0 )

{ B=B {MACJ};

S=S R_j-;

} } where,

S: represents a set of nodes;

Rj.- represents a set of nodes in row i of the two-hop table; B: represents a set of elected bridges; Rj\S: represents a set of all nodes in Rj that are not in S;

3. A method as claimed in claim 1 , further including the step of: each Node broadcasts neighbor information to its neighbors.

4. A method as claimed in claim 1, further including the step of: each Node keeps a two-hop neighbor table.

5. _: A method as claimed in claim 3, wherein the step of broadcasting neighbor information further includes the step of: obtaining the neighbor information through periodical beacon messages.

6. A method as claimed in claim 3, wherein the step of broadcasting neighbor information further includes the step of: including in the neighbor information the neighbor node's IP address and MAC address.

7. A method as claimed in claim 3, wherein the step of broadcasting neighbor information further includes the step of: broadcasting only when the neighbor information has changed.

8. A method as claimed in claim 4, wherein: the two-hop neighbor table in each node is arranged in such a way that the first column consists of this node and its neighbor nodes, and each row consists of one of the node in first column and its corresponding neighbor nodes.

9. A method as claimed in claim 4, wherein: the Node also keeps an accompany IP address table for the purpose of obtaining quick IP address to MAC address mapping when the destination node is within the two-hop neighborhood.

10. A method as claimed in claim 1 , wherein: bridge election is conducted independently by each node.

11. A method as claimed in claim 1 , wherein: the bridging node is the node that connects the highest number of node, or connects node(s) that is not connected by the previously elected bridge(s).

12. A method as claimed in claim 1, wherein: the elected bridges are consistent to all nodes in the network.

13. In a mobile ad hoc network having a plurality of mobile and/or fixed user terminals or nodes, a method of bridging between a first and a second node, the method including the step of: ₍ a. obtaining a destination address from either a two-hop table or from learning route cache; b. compiling a frame for forwarding to the destination (second) node; c. unicasting the frame to the second node.

14. A method as claimed in claim 13, wherein bridging (frame forwarding) is based on node's MAC address.

15. A method as claimed in claim 13, wherein a destination node's MAC address can be obtained by checking two-hop neighbor table, or by broadcasting RQM frame to request the MAC address.

16. A method as claimed in claim 13, wherein a node/bridge will learn route and store the learnt route in its cache.

17. A method as claimed claim 13, wherein when sending/forwarding a data frame, the node/bridge searches the route to the destination node by first examining its two-hop neighbor table, then its route cache, and finally setting multicasting address.

18. A method as claimed in claim 14, wherein a destination node's IP address to its MAC address mapping is required if only IP address is available.

19. A method as claimed in claim 15, wherein, in broadcasting a RQM frame, a sequence number is utilized to avoid the bridge from rebroadcasting duplicate RQM frames.

20. A method as claimed in claim 15, wherein the RPM frame responds to the RQM frame with the requested MAC address.

21. A method as claimed in claim 16, wherein: the bridge listens promiscuously, receiving every frame transmitted.

22. A method as claimed in claim 16, wherein for each frame received, the bridge stores the address in the frame's source address field in a cache, together with the address in the transmitter's field.

23. A method as claimed in claim 16, wherein the bridge ages each entry in the station cache and deletes it after a period of time in which no traffic is received with that address as the source address.

24. A method as claimed in claim 17, wherein if the destination node is within the two-hop neighborhood, the data frame is unicast to the destination node directly or via a specific bridge.

25. A method as claimed in claim 17, wherein, if the route to the destination node is found in the route cache, the data frame is unicast along the route.

26. A method as claimed in claim 17, wherein, if the destination node is neither within the two-hop neighborhood nor in the route cache, the data frame is multicast to bridges.

27. A method as claimed in claim 17, wherein, in multicasting a data frame, a sequence number is utilized to prevent bridge from remulticasting duplicate data frames;

28. A method as claimed in claim 19, wherein nodes store the sequence number along with source and destination node address pairs only for the broadcasting and multicasting frames.

29. A method as claimed claim 1 , wherein the selected bridges can be used in the IP layer routing.

30. A method as claimed in claim 13, wherein the underlying network protocols conform to the IEEE 802.11 specifications.

31. A method as claimed in claim 13, wherein the underlying network protocols conform to the Bluetooth specifications.

32. A method as claimed in claim 13, wherein the underlying network protocols conform to the ETSI HiperLAN specifications.

33. A mobile ad-hoc network having a plurality of mobile and / or fixed user terminals or nodes adapted to carrying out the method as claimed claim 1.

34. A mobile ad hoc network having a plurality of mobile and/or fixed user terminals or nodes, including means for determining a bridging node to be used for bridging in accordance with a method as claimed in claim 1.