GB2445391A - Resource Reservation in Distributed Communication Network - Google Patents

Abstract

In a distributed network comprising a plurality of nodes, access to a communication medium is effected by maintaining at each node a record of reservation of the medium by nodes in the network. On a node seeking reservation of the communications medium, for engagement of communication with a target node, the reservation seeking node checks its reservation record before sending a reservation request taking account of the checking step. A node in receipt of the reservation request checks its reservation record to determine if the reservation request is capable of being fulfilled and responds to said reservation seeking node accordingly.

Description

2445391

1

Communications Apparatus

The present invention is concerned with the reservation of bandwidth in a wireless communications system. It is particularly for use in distributed systems, most especially MBOA DRP MAC compliant systems.

Recently, the Multi-band OFDM Alliance (MBOA) published a specification for use of multi-band OFDM in UWB networks, namely "High rate ultra wideband PHY and MAC Standard" (ECMA-368, ECMA International, December 2005). This standard is hereinafter referred to as "MBOA". The means of coordinating channel access in this standard is similar to that specified in the IEEE 802.15.3 standard (IEEE 802.15.3 Working Group, Part 15.3: wireless medium access control (MAC) and physical layer (PHY) specifications for high rate wireless personal area networks (WPANs), Draft Standard, June 2003).

However, a significant difference is exhibited, in that MBOA is fully distributed, whereas 802.15.3 is oriented towards networks containing a centralized piconet control entity.

Superframes are defined in MBOA to provide a basic timing structure for frame exchange. A superframe is composed of 256 medium access slots (MASs), where each MAS has a duration of 256 (is. Each superframe starts with a beacon period (BP),

which extends over one or more contiguous MASs. The MBOA MAC consists of two channel access methods: the distributed reservation protocol (DRP) and prioritized contention access (PCA). DRP is a contention-free channel access scheme since it uses guaranteed time slot reservation to provide QoS support. On the other hand, PCA is very similar to IEEE 802.1 le enhanced distributed channel access (EDCA) in that it is a prioritized contention-based access scheme for the slots outside the BP and DRP reservations. This invention is primarily concerned with DRP.

2

To illustrate the field of the invention, figure 1 shows an extract from MBOA, setting out information element (IE) format, Control Field format, and Allocation Field format, terms to be explained in due course. DRP enables a device to reserve one or more MAS, which the device can use to communicate with one or more neighbours. All devices that use DRP for transmission or reception will announce their reservations by including DRP IEs in their beacons, as shown in Figure 1. A reservation is the set of MASs identified by DRP IEs with the same values in the Target/Owner DevAddr (abbreviation of Device Address), Owner, Reservation Type, and Stream Index fields. Reservation negotiation is always initiated by the device that will initiate frame transactions in the reservation, referred to as the reservation owner. The device that will receive information is referred to as the reservation target.

The MBOA standard does not specify the method for MAS allocation in DRP. That is, there is no definition of a specific method by which time slot(s) in a superframe are to be chosen so as to avoid collisions among multiple network devices. Instead, the standard includes a clause for the resolution of DRP reservation conflict, which is complex and consists of seven rules.

"Multi-band OFDM: a new approach for UWB" (Batra, A.; Balakrishnan, J.; Dabak, A.; Proceedings of 2004 International Symposium on Circuits and Systems, 2004, Volume 5, 23-26 May 2004 Page(s): V365 - V368 Vol. 5.) and Multiband OFDM Alliance -The next generation of Wireless Personal Area Networks (Hiertz, G.R.; Yunpeng Zang; Habetha, J.; Sirin, H.; IEEE/Sarnoff Symposium on Advances in Wired and Wireless Communication, 2005, April 18-19, 2005 Page(s):208 - 214) provide tutorial background on the standard. However, neither document discusses this problem or its solution.

Aspects of the invention are therefore concerned, in general terms, with a distributed bandwidth reservation protocol for use in MBOA DRP MAC.

3

One aspect of the invention provides a method of controlling access to a communications medium in a distributed network, the network comprising a plurality of nodes, the method comprising maintaining at each node a record of reservation of said medium by nodes in said network and, on a node seeking reservation of said communications medium, for engagement of communication with a target node, said reservation seeking node checking its reservation record before sending a reservation request taking account of said checking step, a node in receipt of said reservation request checking its reservation record to determine if said reservation request is capable of being fulfilled and responding to said reservation seeking node accordingly.

Aspects of the invention enable interference (or collision) avoidance and address the hidden node and exposed node problems. The underlying substance of the invention can also be applied to other TDMA-based time slot reservation systems.

In addition to the above aspects, aspects of the invention can be delivered in the form of processor executable instructions for configuring a general purpose, communications compatible computer. Such instructions may be provided in software form, such as a carrier, a storage medium or a signal. Also, the instructions may be provided on a solid state memory means, such as flash memory, or by means of an ASIC or other preconfigured processing means.

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

Figure 1 illustrates diagrams comprising an extract from the MBOA Standard;

Figure 2 illustrates a schematic diagram of a wireless communications network in accordance with an embodiment of the invention;

Figure 3 illustrates a communications device of the network illustrated in figure 2;

Figure 4 illustrates a process of executing a three way handshake in accordance with the specific embodiment of the invention; and

4

Figure 5 illustrates an example of sending and receiving tables stored and utilised by nodes in an illustrative network.

A network 10 in accordance with the specific embodiment described herein is illustrated in figure 2. The network comprises a plurality of interconnected hardware devices 201 -205 (which may or may not be configured at least partially by software processes). As illustrated, certain of these devices can be hidden. Hidden nodes present problems in management of nodes in a network, as certain nodes will have incomplete knowledge of the structure of the network at any given time. Hidden nodes can occur in both distributed and centrally controlled networks. For instance, in figure 2, wherein lines between nodes represent direct, in-range, communication, node 205 is hidden with respect to node 201, and vice versa.

Figure 3 illustrates schematically a device 20x (where x designates the specific device number) of the network 10 illustrated in figure 2. In a practical case, it will be appreciated that the device 20x can be implemented by means of a general purpose computer by means of software or application specific hardware components. The device 20x comprises a processor 110 operable to execute machine code instructions stored in a working memory 112 and/or retrievable from a mass storage device 116. By means of a general purpose bus 114, user operable input devices 118 are capable of communication with the processor 110. The user operable input devices 118 comprise, in this example, a keyboard and a mouse though it will be appreciated that any other input devices could also or alternatively be provided, such as another type of pointing device, a writing tablet, speech recognition means, or any other means by which a user input action can be interpreted and converted into data signals.

An alternative implementation could also include a transceiver without predefined user interface.

Audio/video output hardware devices 120 are further connected to the general purpose bus 114, for the output of information to a user. Audio/video output hardware devices

5

120 can include a visual display unit, a speaker or any other device capable of presenting information to a user.

Communications hardware devices 122, connected to the general purpose bus 114, are connected to an antenna 124. In the illustrated embodiment in Figure 3, the working memory 112 stores user applications 130 which, when executed by the processor 110, cause the establishment of a user interface to enable communication of data to and from a user. The applications in this embodiment establish general purpose or specific computer implemented utilities that might habitually be used by a user.

Communications facilities 132 in accordance with the specific embodiment are also stored in the working memory 112, for establishing a communications protocol to enable data generated in the execution of one of the applications 130 to be processed and then passed to the communications hardware devices 122 for transmission and communication with another communications device. It will be understood that the software defining the applications 130 and the communications facilities 132 may be partly stored in the working memory 112 and the mass storage device 116, for convenience. A memory manager could optionally be provided to enable this to be managed effectively, to take account of the possible different speeds of access to data stored in the working memory 112 and the mass storage device 116.

On execution by the processor \ 10 of processor executable instructions corresponding with the communications facilities 132, the processor 110 is operable to establish communication with another device in accordance with a recognised communications protocol.

This protocol is, in accordance with the specific embodiment, compliant with the MBOA DRP MAC layer, with certain modifications which will become apparent from the following description.

DRP operates on the basis of the principle of TDMA. To prevent interference in a TDMA network, a time slot t is considered free to be allocated to send data from a node x to a node y if the following conditions are met.

6

1. Slot t is not scheduled for receiving or transmitting in either node x or y;

2. Slot t is not scheduled for receiving in any node z that is a one-hop neighbour of x;

3. Slot t is not scheduled for sending in any node z that is a one-hop neighbour of y-

This is explained in "QoS support in TDMA-based mobile ad hoc networks" (I. Jawhar and J. Wu, Journal of Computer Science & Technology, Nov. 2005, pp. 797-810) and "A TDMA-based bandwidth reservation protocol for QoS routing in a wireless mobile ad hoc network" (W. Liao et al., IEEE ICC, 2002). These rules address the problems of hidden and exposed terminals (as will be seen in an example of the network in use).

All the devices 20x in the network 10 discover their neighbours via beacons. Each device 20x maintains two tables: a sending table and a receiving table. The sending table records the time slots a device and its neighbours currently use or are scheduled to use in the future for sending activities. The receiving table records the time slots a node and its neighbours currently use or are scheduled to use in the future for receiving activities. All the entries of both tables are updated every time a device hears a beacon with DRP IE. More specifically, from the Target/Owner DevAddr and Owner fields of the DRP IE in the beacon, a device records the sending or receiving device in the corresponding table. Likewise, from the zone bitmap and MAS bitmap of the DRP Allocation field, the device records the reserved MASs.

In DRP there are two mechanisms used to negotiate a reservation, namely explicit and implicit negotiation. For explicit negotiation, the reservation owner and target use DRP Reservation Request and DRP Reservation Response command frames to negotiate the desired reservation. For implicit negotiation, the reservation owner and target use DRP IEs transmitted in their beacons.

Explicit negotiation will now be described in detail. Explicit reservation, in a similar fashion to TCP, applies a three-way handshake procedure in order to establish reservation, as shown in Figure 4. The advantage of this mechanism is that the neighbours of both the owner and the target can have up-to-date MAS allocation

7

information. Before the reservation owner (device A) sends a DRP Reservation Request, it first checks its sending and receiving tables and selects the MASs based on the three conditions described above. It then puts the selected MASs in the DRP Allocation field in the DRP IE to be sent within the DRP Reservation Request.

On receipt of a DRP Reservation Request, the reservation target (device B) checks its own sending and receiving tables to see if the requested MASs are indeed available. It then sends a DRP Reservation Response command to the reservation owner. In the meantime the reservation target updates its sending and receiving tables temporarily, taking into account the new reservation. If the reservation cannot be granted due to a conflict with its own or its neighbours' reservations, the reservation target includes a DRP Availability IE in the DRP Reservation Response command frame. Upon reception of the DRP Reservation Response with the reservation granted, the reservation owner updates its sending and receiving tables taking into account the new reservation. It then sends out a Confirmation command.

The format of the Confirmation command frame is similar to that of a DRP Reservation Request, but with a different Frame Subtype value. If the reservation target does not grant the reservation request, the owner has to check its tables in addition to the DRP Availability IE received, and possibly choose another set of MASs. It is possible that different nodes have different views of the current utilization of MASs due to node mobility or stale information.

During this negotiation process, neighbouring nodes (i.e. devices other than Device A and Device B in figure 4) hear the Reservation Request and Response commands and check their sending tables and receiving tables to detect any conflict. In the rare event of conflict, the neighbouring node in question sends out a Reservation Conflict message to the reservation owner with a DRP Availability IE. The Conflict command should be sent with a higher priority, e.g. with a smaller inter-frame space. The format of the Conflict command frame is similar to that of a DRP Reservation Response, but with a different Frame Subtype value. The processing of the Conflict frame at the owner is similar to that of a Response frame as described above.

8

All nodes update their sending and receiving tables after the reserved MASs are confirmed. That is, once negotiation for a reservation is successfully completed, the reservation owner sends out the Confirmation. Any temporary entries made to sending and receiving tables during the negotiation process are then replaced or deleted. As specified in MBOA, the owner and target may optionally also include DRP IE(s) in their beacons that describe the reservation. Within each DRP IE, the Reason Code will be set to Accepted and the Reservation Status bit set to ONE.

When the data transmission of a reservation is completed, or a reservation is terminated by the reservation owner, the owner and target will remove the DRP IE from their beacons. In this case, all the nodes update their sending and receiving tables accordingly. Similarly, when hard or private DRP reservation blocks are released with UDA (Unused DRP Reservation Announcement) frames, the changes of MAS utilization should be noted in the tables.

Implicit negotiation will now be described in detail. Implicit negotiation is carried out by transmitting DRP IE(s) in beacon frames. Similar to explicit reservation, a reservation owner first checks its sending and receiving tables and selects the MASs based on the three conditions described above. It then puts the selected MASs in the DRP Allocation field in the DRP IE. The reservation owner device continues to include the DRP IE for at least mMaxLostBeacons+1 consecutive superframes or until a response is received.

A device that supports the DRP parses all beacons received from neighbours, to detect DRP IE(s) whose Target/Owner DevAddr field matches either the device's DevAddr or a multicast DevAddr for which the device has activated multicast reception. From this initial selection, the device processes the DRP IE(s) that are new with respect to DRP IE(s) included in the most recently received beacon from the same device as a DRP reservation request or a DRP reservation response. The skilled person will appreciate that this is consistent with MBOA.

On reception of a unicast DRP reservation request in a beacon, the reservation target checks its own sending and receiving tables to determine if the requested MASs are

9

indeed available. It then includes a DRP reservation response IE in its beacon no later than the next superframe. If there is a reservation conflict, the reservation target includes a DRP Availability IE in its beacon. As before, neighbouring nodes (neither the sender nor the receiver) receive the beacons and check their sending tables and receiving tables to determine if there is any conflict. In the rare event of conflict, the neighbouring node in question sends out a conflict message to the reservation owner with a DRP Availability IE.

If the implicit reservation negotiation is successful, the reservation owner sets Reservation Status to ONE in the DRP IE in its beacon after receiving a beacon from the reservation target that contains a corresponding DRP IE with Reservation Status set to ONE. Subsequently, all the nodes update their receiving and sending tables accordingly.

In order to construct a reservation request, the number of MASs must be determined, based on application bandwidth requirement. A suitable method for determining this number of MASs will now be described. In a particular example, the network has transmission capacity of C, the packet size is L, the superframe size is T and the application has bandwidth requirement of b. A typical application would be playback of video data. The time required to serve one packet (with immediate ACK) is

Tp= L/C + 2SIFS + Tack (JIS),

where SIFS is the short inter-frame space. If the guard time interval in a MAS for synchronization drift is G and each MAS lasts t, then the number of packets a MAS can accommodate is

N = (t-G)/Tp.

The bandwidth b corresponds to b*T/L packets per superframe. Then the number of MASs needed to reserve in a superframe is

M - b*T/L/N.

10

As a simple specific example of this, the following values are assigned to the quantities set out in the above example:

C = 480 Mbps b = 3 Mbps T = 65536 us t - 256 |as L = 1500 bytes Tack =12 jxs SIFS = 10 jj.s G = 28 jas

Then Tp = 57 ^s, N = 4, and M = 4. Thus, four MASs need to be reserved in a superframe.

The above example assumes constant bit rate (CBR) traffic. For more bursty variable bit rate (VBR) traffic, for instance MPEG-4 encoded streams, more dynamic MAS allocation schemes are needed, e.g. the linear-prediction-based allocation method as described in UK Patent Application 0513520.7, in the name of the same applicant. In that application, bandwidth allocation is described for use in variable bit rate streams. Bandwidth-related parameters (such as I-frame size or GOP size) are tracked using an adaptive linear filter. Where the filter predicts a significant difference between anticipated bandwidth requirement and current channel time allocation, it prompts a channel time allocation update request to be sent to the network controller in the case of a centrally controlled network or, in this case, such a message to be distributed among all active devices.

The exact method of MAS allocation is not specified in the MBOA standard. Allocating MAS randomly without careful consideration can lead to heavy interference and collision, as well as large amount of communication overhead and delay due to the resolution of reservation conflicts. It will be appreciated by the skilled person that the above disclosure involves examples which describe a distributed MAS allocation

11

method in which a number of interference-avoidance rules are used to reserve slots for devices. Devices maintain sending and receiving tables to track activities in the neighbourhood. A three-way handshake procedure is used for connection establishment. The examples are intended to be compatible with the current standard and provides a simple, effective solution to the DRP MAS allocation problem, avoiding reservation conflicts and interference from hidden terminals.

It will also be appreciated that the subject matter of this application is not limited in its application to MBOA but can also be applied to other distributed TDMA-based reservation systems, e.g. distributed scheduling in IEEE 802.16 mesh mode. The cost, though, is the maintenance and storage (memory) of sending and receiving tables. If this cost is an issue, the size of the tables can be reduced if the zone structure of MAS allocation is taken into account. That is, the same sets of slots are allocated in every zone (with reference to Figure 1). However, the disadvantage of this zone structure is that it is less flexible and may require multiple DRP Allocation descriptors. An alternative would be to use one table to represent both sending and receiving activities with entries such as the following: 2 for sending, 1 for receiving, and 0 for no-activity. In this case each table entry needs 2 bits whereas only one bit is needed if two tables are used.

The described communications protocol makes use of various command frames already defined in the standard (e.g. DRP Reservation Request and Response) and hence does not incur extra overhead. It enables interference (or collision) avoidance and addresses the hidden node and exposed node problems. It has the potential to eliminate completely reservation conflict.

Figure 5 illustrates a practical example of use of the protocol in accordance with the specific embodiment of the invention. The example comprises a network in which five wireless devices (A — E) are connected by means of wireless communications channels, which do not form a universal network; that is, some nodes are hidden with respect to at least one other. Certain slots are already marked as allocated for use by devices that have made scheduling requests that have been processed by earlier action in accordance with the protocol. In this diagram, "s" represents a device scheduled to send, "r" a

12

device scheduled to receive, and an empty field an indication that the device is neither scheduled to receive or send.

The scenario of the example is that node A requires a time slot to transmit to node B. Firstly, slots 1 and 2 cannot be considered because slot 1 is used by A to send and slot 2 is used by B to receive (violating condition 1). Secondly, slots 3 and 4 cannot be used either, because they will cause collision at C and D (violating condition 2). Lastly, slots 5 and 6 cannot be reserved because D and E are sending on these slots (violating condition 3). So only slot 7 can be used.

An example of a typical combined sending and receiving table is given below in table 1. It should be emphasised for the aid of the reader that the entries in this table are consistent with the entries marked in the scheduling in figure 5, and for conciseness the table makes use of the two-bit alternative embodiment which combines the function of the sending and receiving table described previously. In table 1, rows correspond to nodes, and columns correspond to MASs, wherein 2 represents the existence of sending activity, 1 represents the existence of receiving activity and an empty entry (in lieu of entering 0) represents no activity.

Table 1

1

2

3

4

5

6

7

A

2

B

1

C

1

D

1

2

E

2

The invention has been described by way of a software implementation. This software implementation can be introduced as a stand alone software product, such as borne on a storage medium, e.g. an optical disk, or by means of a signal. Further, the implementation could be by means of an upgrade or plug-in to existing software.

13

Whereas the invention can be so provided, it could also be by way exclusively by hardware, such as on an ASIC, a DSP board, a solid state memory means, such as flash memory, or the like.

The reader will appreciate that the foregoing is but one example of implementation of the present invention, and that further aspects, features, variations and advantages may arise from using the invention in different embodiments. The scope of protection is intended to be provided by the claims appended hereto, which are to be interpreted in the light of the description with reference to the drawings and not to be limited thereby.

Claims (19)

CLAIMS: 14

1. A method of controlling access to a communications medium in a distributed network, the network comprising a plurality of nodes, the method comprising maintaining at each node a record of reservation of said medium by nodes in said network and, on a node seeking reservation of said communications medium, for engagement of communication with a target node, said reservation seeking node checking its reservation record before sending a reservation request taking account of said checking step, a node in receipt of said reservation request checking its reservation record to determine if said reservation request is capable of being fulfilled and responding to said reservation seeking node accordingly.

2. A method in accordance with claim 1 wherein said step of sending an allocation request comprises sending a message for receipt by one or more nodes on the network, the message comprising information indicating the reservation seeking node,

information indicating said target node, and information indicating a time slot for which the reservation seeking node requests reservation of the communications medium.

3. A method in accordance with claim 2 wherein said step of responding performed at a node in receipt of said reservation request comprises determining if said receiving node corresponds with the information indicating the target node and, on such correspondence, sending a message indicating that said time slot is or is not available for communication.

4. A method in accordance with claim 3 wherein determining that said time slot is available for communication is carried out on the basis of:

the slot not being scheduled for receiving or transmitting in either the requesting node or the intended recipient node;

the slot not being scheduled for receiving in any node that is a one-hop neighbour of the requesting node; and the slot not being scheduled for sending in any node that is a one-hop neighbour of the intended recipient node.

15

5. A method in accordance with claim 3 or claim 4 wherein in the event that said time slot is available for communication, updating the reservation record at said target node to reflect the newly allocated reservation by said requesting node.

6. A method in accordance with any of claims 3 to 5 wherein, on receipt of a message indicating that a time slot is not available for communication, a node updates its reservation record accordingly.

7. A method in accordance with any of claims 2 to 6 wherein said step of responding performed at a node in receipt of said reservation request comprises determining if said receiving node corresponds with the information indicating the target node and, on no such correspondence, checking said receiving node's reservation record for availability of said time slot and in the event that said time slot is not available sending a message indicating that said time slot is not available for communication.

8. A method in accordance with any of claims 2 to 7 wherein said information indicating said target node defines a multicast request by which a plurality of target nodes are each configured to determine from said information that said message indicates a reservation request with said node.

9. A method in accordance with any preceding claim wherein each message so sent in said method comprises a command frame in accordance with the communications protocol adopted in the communications medium.

10. A method in accordance with any of claims 1 to 8 wherein the method is for use in a communications medium managed by way of a distributed medium access protocol involving transmission of beacon frames, and wherein each of said messages is contained in a beacon frame sent by its respective node.

11. A communications device for use in a communications network, the device comprising reservation record storing means operable to store a record of reservation of said medium by devices in a network in which the device is engaged in use, requesting

16

means for requesting reservation of said communications medium, said requesting means comprising means of checking said reservation record for existing reservations of said communications medium and means for constructing and sending a reservation message on the basis of information stored in said reservation record for engagement of communication with a target device, and request processing means for processing reservation request messages received from other devices in the network, the request processing means being operable to check the reservation record to determine if said received reservation request message is capable of being fulfilled and to respond to the device originating said received reservation request message accordingly.

12. A communications network comprising a plurality of devices in accordance with claim 11.

13. A communications network defining a communications medium and operable to manage access to said communications medium in accordance with any of claims 1 to 10.

14. A computer program product operable to cause a computer to become configured as a device operable as a node within the method of any of claims 1 to 10.

15. A computer program product operable to configure, in a distributed manner a computing network to operate the method of any of claims 1 to 10.

16. A computer readable storage medium storing a computer program product in accordance with claim 14 or claim 15.

17. A signal bearing computer receivable instructions defining a computer program product in accordance with claim 14 or claim 15.

18. A communications network comprising a plurality of nodes, the network being operable to define a communications medium in which access is managed in a distributed manner, the network comprising at each node a reservation record operable to store information defining reservations of said medium by nodes in said network and,

17

on a node seeking reservation of said communications medium, for engagement of communication with a target node, said reservation seeking node being operable to check its reservation record before sending a reservation request taking account of said checking step, a node in receipt of said reservation request being operable to check its reservation record to determine if said reservation request is capable of being fulfilled and being operable to respond to said reservation seeking node.

19. A method of controlling access to a communications medium in a network comprising a plurality of communications nodes, the method being performed on generation at a first node of a request for reservation of a time slot in the medium, the method comprising checking in a stored record of previous slot reservation activity at the first node if the slot is, according to that node, available, checking in a stored record of previous slot reservation activity at a second node to which the first node intends to communicate if the slot is, according to that second node, available, and checking in a stored record of previous slot reservation activity at nodes neighbouring the first and second nodes if the slot is, according to said neighbouring nodes, available and, only on determination at all three, performing reservation of the slot.