Patent Application
20080250160
1. Field of the Invention
This invention relates to methods, apparatus and computer program code for identifying whether an address in a network with a variable topology in which a device address may change, is intended to identify a particular device. Embodiments of the invention are particularly useful in ultra wideband (UWB) distributed medium access control (MAC) wireless networks.
2. Background Art
Embodiments of the invention will be described with particular reference to standard ECMA-368 (First Edition, 2005); reference may also be made to similar standards published later by the WiMedia Alliance. The skilled person will understand, however, that applications of embodiments of the invention are not limited to such networks.
ECMA-368 defines a high rate ultra wideband PHY and MAC standard including a distributed protocol for access and allocation of addresses. There is no central control node and instead a distributed reservation protocol (DRP) is employed, broadly a device observing which resources are used by other devices and then making a choice of address and channel time; a conflict resolution protocol is also provided. Short (16 bit) device addresses are mainly used because these are easier and quicker to process and in general locally unique. However because of device mobility two devices can have the same address and there is therefore the possibility of address clashes, albeit with a low probability, and the potential for ambiguity.
A network also employs frequency reuse and each device beacons to its neighbour, mainly for the purposes of the MAC, inter alia to maintain synchronisation. A variable length beacon period is divided into 85 μs beacon slots and a device beacon provides information about the neighbours of a device (other devices it can “hear”—receive from) and therefore a received beacon can provide a device with information relating to its neighbour's neighbours including, in particular the occupancy of beacon slots. Broadly a device is able to transmit in a slot if it appears free and it also perceived as free by the device's neighbours' this enables spatial reuse of frequencies.
Communications in the MAC layer are organised into superframes, each superframe comprising 256 medium access slots each of 256 μs (a total of 65 ms). A device may use one or more MAS slots depending upon the requirements of a communication channel between devices.
c shows the general format of an example MAC frame for a beacon including from 1 to N information elements (IEs) for BPO (Beacon Period Occupancy) and DRP (Distributed Reservation Protocol) data, as well as other information elements. The MAC header comprises, in addition to control information and information identifying the type of frame (0 for a beacon frame), a source and destination address each specified by a 16 bit device address (DevAddr) which is generated locally by a device, essentially randomly avoiding addresses known to be used by neighbours and neighbour's neighbours. Most (but not all) devices also have a globally unique 48 bit extended unique identifier (EUI-48™) and provision is also made for including this value in a beacon. Device address clashes can be identified either by one device noting that another is using its own address as a source address, or by receiving similar information from a neighbour about its neighbours, that is that a neighbour's neighbour is using the device's own address as a source address.
The BPO information element provides information on the beacon period (see
As mentioned above, different applications have different requirements in terms of throughput and maximum delay (latency), and this translates into a repetition rate of an allocated time slot within a single superframe having a slot duration of n MAS periods, repeated in subsequent superframes. The pattern of MASs depends upon the type and priority of data—for example real time delay data requires a low latency whereas for bulk data transmission the delay is of little consequence but a large channel time is desirable.
The DRP protocol enables an initiating device (“owner”) to make a claim for channel time between the owner and another device (“target”). Broadly the owner device decides on the request and inserts a DRP information element in its outgoing beacon claiming some MASs which it believes are free DRP IEs in the beacons from other devices. Thus the owner sends a DRP and qualifies the target with a target address (DevAddr). The target device is responsible for granting the request and for providing ongoing reconfirmation during the period of use that the channel time requested by the owner remains free.
The inventors, however, have recognised that there is a problem with this approach, albeit relatively uncommon, which arises from ambiguity of the DevAddr address. The question is, to which device (owner/target) does the DevAddr in the information element correspond? The owner device puts the target device's DevAddr in the DRP IE and the target parses the incoming beacon to see whether or not its address is included and, if so, schedules channel time to receive data from the owner accordingly. However, if the target device has recently changed its address once or perhaps twice, the owner device may still be using an old address for the target. The question then arises, in this example from the target's perspective, does the owner mean me or another device?
According to the invention there is therefore provided a method to enable a first device to determine whether a device address used by a second device is intended to identify said first device, said first and second devices comprising mobile devices forming part of a network of devices with a variable topology in which a said device address may change to resolve an address conflict within the network, the method comprising: transmitting, repeatedly, a beacon from said first device to said second device, said beacon including information updating a said device address of said first device; storing, in said first device, a history of device addresses used by said first device; receiving, at said first device, from said second device, a signal including a said device address; comparing, in said first device, said received device address with device addresses in said history of device addresses back in time for a period limited by a synchronisation refresh time, wherein said synchronisation refresh time comprises a maximum time for which said second device may fail to receive said beacon from said first device without considering that said first device is no longer synchronised to said network; and determining that said received device address is intended to identify said first device if said received device address matches a device address in said history of device addresses over said limited period.
In embodiments communications in the network are divided into superframes, each superframe comprising a plurality of data frames, and the transmitting of the beacon comprises transmitting a beacon data frame comprising beacon data. Then the synchronisation refresh time preferably comprises an integral number of the superframes, in some embodiments four.
In embodiments of a UWB network if the clock of one device runs as fast as possible within the defined tolerance limits and the clock of another device as slowly as possible within the tolerance limit then after greater than four superframes the worst case clock drift effectively desynchronises the devices and thus a device is effectively no longer part of the local group. Thus the address of a device can only be as old as the synchronisation refresh time, that is in embodiments a period of four superframes. Thus in embodiments a device maintains a history of its own addresses (or address changes) over the last four superframes. In this way a received device address can be compared with a device address in the history (either by searching through or by looking up a location specified by a received device address) to determine whether or not the received device address is intended to identify the device receiving the address. If the received device address is in the history it is assumed that it is intended to specify the device receiving the address; if the sender of the address (for example the owner device) really intended to identify a different target device then that other target device would qualify the address.
Embodiments of the above-described method may be employed in the DRP protocol of a UWB network, and also in conjunction with a beacon protocol, more particularly with the BPO IE. For example, as described above, broadly speaking a beacon reports occupied slots and, more particularly, one device listens to the beacons of other devices it can hear and reports these (so that a device can determine which slots are occupied by its neighbour's neighbours). Consider a case where a device, y, is occupying beacon slot x, and device y receives the beacon of another device indicating that slot x is also occupied by a device with address (DevAddr) z. The question then arises, is address z mine? If it is there is no problem, if not then device y should change the beacon slot it is occupying because it is used by another device. Embodiments of the above-described method can be employed to determine whether or not the address in a beacon (BPO IE) received from a second device at a first device identifies the first device, even if the beacon is received in the slot occupied by the first device, this is acceptable. However if the determination is made that the address does not identify the first device, and the beacon is in a slot occupied by the first device, then there is a (potential) conflict, in particular because this slot in a neighbour of the neighbour is occupied.
Since, in embodiments, only information obtained from a previous superframe is included in the BPO IE then the information may only be one superframe out of date. Thus where embodiments of the method are used in connection with beacon period occupancy a shorter view of the history, for example one or two superframes, may be sufficient.
Thus in another aspect there is provided a method to enable a first device to determine whether a device address used by a second device is intended to identify said first device, said first and second devices comprising mobile devices forming part of a network of devices with a variable topology in which a said device address may change to resolve an address conflict within the network, wherein communications in said network are divided into superframes, each superframe comprising a plurality of data frames, the method comprising: transmitting, repeatedly, a beacon from said first device to said second device, said beacon including information updating a said device address of said first device; storing, in said first device, a history of device addresses used by said first device; receiving, at said first device, from said second device, a signal including a said device address; comparing, in said first device, said received device address with device addresses in said history of device addresses back in time for a period comprising at least two said superframes, and determining that said received device address is intended to identify said first device if said received device address matches a device address in said history of device addresses over said period.
Embodiments of the method decrease the probability of an unnecessary move to another beacon slot, which would otherwise potentially carry a risk of destabilising the network. Embodiments of the method applied to beacon period occupancy information are not able to rely upon stream identification information (see below) for greater ambiguity resolution so there is a low risk of assuming there is no need to move when in fact there is, and hence a marginally increased collision risk. However overall the benefits of embodiments of the method outweigh this disadvantage.
Returning to previously described aspects of the method, in particular (but not necessarily) in relation to a distributed reservation protocol, qualification of a communication link may use more than an owner-target DevAddr) address pair. For example in embodiments of the method the DRP also employs a stream index, a separate number space associated with each address pair, more particularly a 3 bit number which aims to uniquely identify a reservation within the communications channel (because there may be multiple reservations between a single pair of devices, for different applications).
Thus in preferred embodiments a stream identifier of a current communications stream is also used for determining whether the received device address is intended to identify the receiving device. The qualification of a received device address to determine whether it is intended to identify a receiving device may further employ the set of medium access slots (MASs) used for a communications stream. The set of MASs is described in the DRP information element and is repeated (and may change) for each superframe. However broadly speaking for a communications stream between two devices it is expected that the set of MASs will remain the same, or at least will overlap (in the case where a conflict has required one or other end of the link to modify some of the MASs used). However the MASs employed would not be mutually exclusive from one superframe to another and thus a set of MASs of a current communication stream between first and second devices may be compared with a set of MASs identified by a signal such as a request for reservation of communications bandwidth to determine whether a received device address is intended to identify a receiving device. In embodiments, if there is no overlap (between the MASs in the current communications stream and those requested in the reservation) then it may be assumed that the received device address is not intended to identify the receiving device. There is a low risk of a false match but this is of little consequence compared with the consequence of not making a correct match, which is a break in the communications reservation which could result, say, in a jerky real-time video or audio sequence. (As previously mentioned, the superframe comprises 256 MASs, but an MAS may comprise more than one frame).
As previously mentioned, the beacon may include a global address associated with a local device address (DevAddr), that is an address which is useable to unambiguously identify a device. In this way a temporary local address can be guaranteed to be up to date. In embodiments the global address is an address allocated by a central or global address allocation system or authority, in particular an EUI-48 address. Thus when a global or EUI-48 address is received in a beacon, at that point an up to date view of the device address of the sending device is guaranteed (although on occasion, for example where a device does not have unique EUI-48 value, the device identifier field which would normally contain this address may be set to a null value. Alternatively (or additionally) to the above-described techniques, it may be mandated within the network that a device does not change its address more frequently than the synchronisation refresh time, for example four superframes (because another device may not hear your beacon for up to four superframes). However this does not remove the problem entirely since the time window, of say four superframes, is moving and thus there is the possibility of a single address change within the period.
According to a further aspect of the invention there is therefore provided a method to enable a first device to determine whether a device address used by a second device is intended to identify said first device, said first and second devices comprising mobile devices forming part of a network of devices with a variable topology in which a said device address may change to resolve an address conflict within the network, the method comprising: transmitting, repeatedly, a beacon from said first device to said second device, said beacon including information updating a said device address of said first device; receiving, at said first device, from said second device, a signal including a said device address; determining that said received device address is intended to identify said first device if said received device address matches a device address of said first device; and delaying for at least a synchronisation refresh time after a change of said device address of said first device before another change of said device address of said first device; and wherein said synchronisation refresh time comprises a maximum time for which said second device may fail to receive said beacon from said first device without considering that said first device is no longer synchronised to said network.
As mentioned above, embodiments of this method do not eliminate the risk of falsely identifying a received address as intended for the receiving device, but this risk is reduced and hence provides some advantages. However such a system is less responsive to a genuine address conflict because, potentially, there is a need to maintain an ambiguous address for up to the synchronisation refresh time, for example four superframes.
The invention still further provides processor control code to implement the above-described protocols and methods, in particular on a data carrier such as a disk, CD- or DVD-ROM, programmed memory such as read-only memory (Firmware), or on a data carrier such as an optical or electrical signal carrier. Code (and/or data) to implement embodiments of the invention preferably comprises code for a hardware description language such as Verilog (Trade Mark) or VHDL (Very high speed integrated circuit Hardware Description Language) or SystemC, although it may also comprise source, object or executable code in a conventional programming language (interpreted or compiled) such as C, or assembly code, or code for setting up or controlling an ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array). As the skilled person will appreciate such code and/or data may be distributed between a plurality of coupled components in communication with one another.
In a further aspect the invention provides a first mobile device for communicating with a second mobile device over a network of devices with a variable topology in which an address of a said device many change to resolve an address conflict within the network, said first mobile device comprising: a transmitter to transmit, repeatedly, a beacon from said first device to said second device, said beacon including information updating a said device address of said first device; memory to store, in said first device, a history of device addresses used by said first device; a receiver to receive, at said first device, from said second device, a signal including a said device address; a comparator to compare, in said first device, said received device address with device addresses in said history of device addresses back in time for a period limited by a synchronisation refresh time, wherein said synchronisation refresh time comprises a maximum time for which said second device may fail to receive said beacon from said first device without considering that said first device is no longer synchronised to said network; and an address identifier to determine that said received device address is intended to identify said first device if said received device address matches a device address in said history of device addresses over said limited period.
The invention further provides a communications network including a plurality of mobile devices as described above, in particular a UWB communications network, more particularly compatible with standard ECMA-368.
These and other aspects of the invention will now be further described, by way of example only, with reference to the accompanying figures in which:
a to 1d show, respectively, a MAC superframe structure, details of a beacon period (BP), a general format of an example MAC frame for a beacon including beacon period occupancy (BPO) and distributed reservation protocol (DRP) data, and structure of a BPO information element;
a and 6b show, respectively, a block diagram of a PHY hardware implementation for an OFDM UWB transceiver and an example RF front end for the receiver of
Broadly speaking we will describe a technique where, for each superframe, a device stores the address (DevAddr) it uses in its beacon for a time limited history, that is a sliding window over the last four superframes. We also use knowledge of how out of date another device's view of an address can be—for example if a device knows that it has not changed its address in the last four superframes then it also knows that local devices will not have a stale view of its address. However once a beacon has been received this guarantees that the address (DevAddr) is up to date because the beacon also includes the global EUI-48 address. Thus the time for which the history should be stored is the period for which a beacon can validly not be received.
In a corresponding way, when a DRP is received by a target, because the target may not necessarily have received the owner's most recent beacon the target's view of the owner's address may be out of date. However if the owner device maintains a history of its own addresses it can determine whether or not the target's response is intended for the owner (because the response will include the owner's address together with a granted or otherwise response to the broadcast DRP request for an allocation of channel time).
In more detail, an owner or target device holds n DRP reservation objects, each one qualified by:
At step 200 the receiving device receives and parses a DRP IE to extract the address and then determines whether or not the address is for the receiving device by, initially (step 202) looking up in an address history table to determine whether the address is present in the table. If the address is not in the history then the DRP IE is not for the receiving device and can be ignored (step 204), but if the address matches any in the history then the procedure continues to perform further checks to determine whether the DRP relates to an existing allocation.
Thus at step 206 the procedure determines whether the other (sending) device address matches an existing allocation, and if not, implements a new reservation allocation according to standard ECMA-368 in the usual way. However if a match is found the procedure then checks the stream index (step 209) to determine whether this matches an existing allocation and again, if there is no match, proceeds to step 208 to implement a new reservation. However if a match is found the procedure then further checks the MAS set (step 210) to determine whether or not this overlaps with an existing allocation. If there is no overlap again the procedure continues to step 208 and the DRP is treated effectively as a request for a new allocation although, in reality, this is a request to modify (extend) an existing reservation—ultimately the new reservation will be combined with an existing allocation. If, however, at step 210 an overlap is found then it is confirmed that the sender is referring to an existing reservation and then the procedure continues (step 212) with further action accordingly. For example for a target device this may comprise sending a signal to indicate confirmation that the requested allocation is granted or, if the allocation is the same as previously, re-confirmation of this allocation. Alternatively an owner device may have received information from a target device relating to a conflict in which case the owner device is permitted (according to standard ECMA-368) to unilaterally modify the reservation.
The MAC system 300 comprises a message parsing interface (MPI) 302 with a bidirectional data and control connection, “X” to the physical layer hardware shown in
In embodiments of the MAC system 300 the Boot and/or code memory 324a, b stores implement a procedure as shown in
Thus referring to
Data for transmission from the MAC CPU (central processing unit) is provided to a zero padding and scrambling module 802 followed by a convolution encoder 804 for forward error correction and bit interleaver 806 prior to constellation mapping and tone nulling 808. At this point pilot tones are also inserted and a synchronisation sequence is added by a preamble and pilot generation module 810. An IFFT 812 is then performed followed by zero suffix and symbol duplication 814, interpolation 816 and peak-2-average power ratio (PAR) reduction 818 (with the aim of minimising the transmit power spectral density whilst still providing a reliable link for the transfer of information). The digital output at this stage is then converted to I and Q samples at approximately 1 Gsps in a stage 820 which is also able to perform DC calibration, and then these I and Q samples are converted to the analogue domain by a pair of DACs 822 and passed to the RF output stage.
a shows a block diagram of physical hardware modules of a UWB OFDM transceiver 1000 which implements the transmitter and receiver functions depicted in
Referring to
The FFT unit 1012 provides an output to a CEQ (channel equalisation unit) 1020 which performs channel estimation, clock recovery, and channel equalisation and provides an output to a DEMOD unit 1022 which performs QAM demodulation, DCM (dual carrier modulation) demodulation, and time and frequency de-spreading, providing an output to an INT (interleave/de-interleave) unit 1024. The INT unit 1024 provides an output to a VIT (Viterbi decode) unit 1026 which also performs de-puncturing of the code, this providing outputs to a header decode (DECHDR) unit 1028 which also unscrambles the received data and performs a CRC 16 check, and to a decode user service data unit (DECSDU) unit 1030, which unpacks and unscrambles the received data. Both DECHDR unit 1028 and DECSDU unit 1030 provide output to a MAC interface (MACIF) unit 1032 which provides a transmit and receive data and control interface for the MAC.
In the transmit path the MACIF unit 1032 provides outputs to an ENCSDU unit 1034 which performs service data unit encoding and scrambling, and to an ENCHDR unit 1036 which performs header encoding and scrambling and also creates CRC 16 data. Both ENCSDU unit 1034 and ENCHDR unit 1036 provide outputs to a convolutional encode (CONV) unit 1038 which also performs puncturing of the encoded data, and this provides an output to the interleave (INT) unit 1024. The INT unit 1024 then provides an output to a transmit processor (TXP) unit 1040 which, in embodiments, performs QAM and DCM encoding, time-frequency spreading, and transmit channel estimation (CHE) symbol generation, providing an output to (I)FFT unit 1012, which in turn provides an output to TXT unit 1014 as previously described.
Referring now to
No doubt many other effective alternatives will occur to the skilled person. For example, although embodiments of the techniques have been described with reference to DRP data the skilled person will understand that similar techniques may also be employed with beacon data, more specifically BPO data. Further, more generally, the techniques we describe may be employed in any network with a variable topology in which an address may change, for example to resolve an address conflict, and applications of the technique are not limited to UWB networks.
It will therefore be understood that the invention is not limited to the described embodiments and encompasses modifications apparent to those skilled in the art lying within the spirit and scope of the claims appended hereto.
| Number | Date | Country | Kind |
|---|---|---|---|
| 0706484.3 | Apr 2007 | GB | national |
