JP2005509381A - Wireless communication device for header compression - Google Patents

Abstract

Packet-based improved wireless communication device using header compression, improved method of operating the wireless communication device, and improvements used in connection with such improved communication devices and methods Provide communication units and software products.
A method for performing wireless transmission between a first unit AP and a second unit MT is disclosed. The method includes that the unit AP, MT converts the real-time bit stream (eg, VoIP, audio, and video) into one or more payloads whose maximum length is predetermined. One or more predefined headers (RTP / UDP / IP) are applied to the payload or each corresponding payload, and transmission between the units AP and MT is performed according to a predefined communication protocol. A packet suitable for is generated. This packet or each packet is then encapsulated in an encapsulating protocol (BNEP) frame adapted to transfer this packet or each packet over the entire wireless connection between the units MT, AP. Next, a predefined header compression technique (IETFROHC) is applied to the encapsulated packet, or each encapsulated packet.

Description

  The present invention relates to a wireless communication device and a method of operating the wireless communication device, and more specifically, to a wireless communication device based on a packet and to operating the wireless communication device based on a packet using header compression. With respect to methods. The invention also relates to a communication unit and a software product used in such a device.

  Wireless communication systems are known that are based on radio units and connections used to at least temporarily group these radio units into a shared resource network. One current example of this general type is in the form of a network with frequency hopping with a short range, and is known in the art as Bluetooth® communication. This device is controlled by the Bluetooth standard, and a complete specification based on Bluetooth communication can be found in the Bluetooth SIG (Special Interests Group). On this web site (www.bluetooth.com) you can find current Bluetooth standards and related information.

  A useful explanation of Bluetooth communication can be found in the form of Jennifer Bray and Charles F. Sturman's textbook "Bluetooth, Connect Without Wires" (Publisher: Prentice Hall PTR, ISBN 0-13-089840-6). be able to.

  Further prior art can be found, for example, in International Patent Publication No. WO 01/20940, US Pat. No. 5,940,431, and published US application 2001/0005368 and US application 2001/0033601. These documents also describe some of the current state of the art in this technical field.

  Readers of this specification can obtain general background information on Bluetooth by referring to the above-mentioned materials, and further clarify technical terms that are used in the present specification but are not specifically defined. Should.

  Each access point in the Bluetooth network forms a Bluetooth piconet having one or more mobile terminals such as a telecommunications handset. This Bluetooth PAN can carry VoIP flows and other types of IP traffic. Since many handsets (or other terminals) can be attached to the same access point, it can be seen that maximizing efficiency when using the limited available bandwidth is important (total capacity per piconet is , The total is 1Mbps).

  A new use for Bluetooth is to send voice over the Internet Protocol (VoIP), which is deployed on the Internet and within corporate networks / intranets. For enterprise networks / intranets, the main advantage of VoIP is that it is used by voice traffic in existing network infrastructure that is typically used for data. However, if you have to carry VoIP traffic over a limited bandwidth wireless link, it is important to minimize bandwidth waste because the VoIP flow is sensitive to delays and the header overhead is significant. It is.

The architecture depicted in Figure 1 is a third-generation Bluetooth enabled 3G (3G) with an IP stack embedded and capable of operating as a cordless telephone handset by establishing a VoIP connection within a corporate network such as an intranet. ) mobile telephone, one MT ₁ has within a group of mobile terminals MT _1-n, shows a possible scenario. The mobile handset MT ₁ establishes a VoIP connection using a set of access points AP _{1... N} in the intranet. The VoIP connection is connected through a dedicated gateway to the telephone network (PABX / VoIP GW), or for example, may be any of connections within the intranet with one or more other handset MT _n.

  According to this VoIP paradigm, voice samples are compressed into packets whose length depends on the voice coder being used. Such payload length must be limited so that long delays do not occur during the conversation. To obtain GSM quality, a 5.3 kb / s G; 723.1 coder can be used that produces 20-byte voice packets. This payload is time stamped using the Real Time Protocol (RTP), which makes the header 12 bytes. In addition, the resulting segment is carried in a UDP datagram, which further adds its own 8-byte header. RTP makes it easy to perform time synchronization, and UDP allows to multiplex several streams simultaneously on an unconnected logical channel. The RTP / UDP packet is then encapsulated in an IP datagram, which adds a 20 byte IP header. This situation may be exacerbated when IP version 6 (IPv6) is used. This is because the IP header increases from 20 bytes to 40 bytes in this case, and the entire header may become 60 bytes for a payload having only 20 bytes. If VoIP packets are carried over a wired LAN, this low bandwidth utilization may not be a big problem, but if a wireless LAN is used instead, there will be significant limitations. There is.

  In the specific case of Bluetooth communication, the Personal Area Network (PAN) working group has standardized IP over Bluetooth, and for this reason it was named "Bluetooth Network Encapsulation Protocol (BNEP)" A new protocol is being developed. This protocol defines a packet format for encapsulating in a Bluetooth network that is used to transfer a common networking protocol over Bluetooth media. BNEP performs Ethernet emulation for Bluetooth, whereby IP datagrams are encapsulated in Ethernet frames and sent to the underlying L2CAP layer. By introducing the Ethernet emulation layer, for example, broadcasting, multicasting, and layer 2 bridging functions can be implemented in a network access point or in a Bluetooth special network. Full details of BNEP can be obtained from the Bluetooth SIG mentioned above and its website.

  However, while BNEP is very flexible, the overhead is large despite the mechanism for compressing its own header. Aggregating BNEP into higher layer protocol overhead can waste considerable bandwidth for some applications. For example, in the case of the VoIP application mentioned above, encapsulating RTP / UDP / IP packets using BNEP will add 3 to 15 bytes to the already long header, so the entire header will be compared to the 20-byte payload. Can be at least (12 + 8 + 20 +3 = 43) bytes and up to (12 + 8 + 40 + 15 = 75) bytes. Similar considerations apply to other types of IP traffic, such as media such as audio and / or video signals. For these other types of IP traffic, packets generated by audio / visual applications may be larger than VoIP packets, but again it is important to minimize header overhead. In fact, when a Bluetooth system is used, it is common for audio / visual coders to generate packets that can be mapped one-to-one to L2CAP frames. This allows better retransmission control and makes it easier to flush the buffer whenever the effective packet life is over. When the header size is minimized, the baseband packet payload is valid, so a wider bandwidth is reserved for the actual audio / visual payload.

International Patent Publication No. WO 01/20940 U.S. Application No. 2001/0005368 US Application 2001/0033601 U.S. Application No. 2001/0005368 US Application 2001/0033601 Jennifer Bray and Charles F. Sturman's “Bluetooth, Connect Without Wires” (Publisher: Prentice Hall PTR, ISBN 0-13-089840-6) Robust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP and uncompressed "(Internet Engineering Task Force (IETF) website (reference number" RFC3095 ", URL: http://www.ietf.org/rfc/rfc3095.txt) S. Casner and V. Jacobson “Compressing IP / UDP / RTP Headers for Low-Speed Serial Links for Low-Speed Serial Links” (Internet RFC 2508)

  An object of the present invention is to provide an improved wireless communication device and an improved method of operating the wireless communication device. It is a further object of the present invention to provide an improved packet based wireless communication device using header compression and an improved method of operating the wireless communication device. It is a further object of the present invention to provide an improved communication unit and software product for use in connection with such an improved communication device and method. Thus, the object of the present invention is specifically to RTP / UDP / IP / for Internet Protocol (IP) bit streams such as VoIP, audio and / or video within a Bluetooth personal area network. It is to reduce the overhead caused by the BNEP header.

Accordingly, the present invention is a method for performing wireless transmission between a first unit and a second unit,
The unit is
a) converting the real-time bit stream into one or more payloads whose maximum length is predetermined;
b) applying one or more predefined headers to the payload or each such payload to generate a packet suitable for transmission between the units according to a predefined communication protocol;
c) encapsulating said packet or each said payload in a frame of an encapsulation protocol adapted to transfer said packet or each said packet over the entire wireless connection between said units;
d) applying a predefined header compression technique to the encapsulated packet or each such encapsulated payload;
A method comprising:

  The method may include generating the payload, or each such payload, from the real-time bit stream having Internet Protocol (IP) traffic, such as a VoIP stream, an audio stream, or a visual stream.

  The method may include performing a service discovery procedure between the first unit and the second unit, and advertising the header compression technique during the service discovery procedure.

  The method may include reassembling and multiplexing the service of the predefined communication protocol that carries the compressed bit stream.

  This method may be used, for example, to encapsulate protocol information having a static header field for the encapsulation protocol, in the context of a compressor and decompressor that is adapted to apply the header compression technique. In addition to applying the header compression.

  The unit may include a radio communication network portion such as a Bluetooth network, and the method may include encapsulating the packet or each such packet using an encapsulation protocol having BNEP.

  The method preferably includes reducing the combination of the predetermined header and BNEP header to a predetermined length (eg, 3 bytes), thereby reducing the encapsulated packet or each It may include compressing the encapsulated packet into a single slot Bluetooth baseband packet using the header compression technique.

  The method may include applying the header compression technique in the form of a robust header compression (ROHC) framework, such as ROHC approved by the Internet Engineering Task Force (IETF).

This method
a) Use a real-time protocol (RTP) profile for the packet;
b) Use a bi-directional optimistic approach (o-mode) by IETF ROHC;
c) Use a small ROHC context identifier (R-CID) (R-CID default is empty);
d) Do not transmit a Universal Datagram Protocol (UDP) checksum, and optionally recalculate this checksum with a decompressor;
e) Consider the entire encapsulation protocol header as the static context part during any one packet flow;
f) transmit only the real-time protocol (RTP) sequence number and / or the internet protocol identification;
g) Transitions between the “initialization and refresh” (IR) state in the compressor, the “first order” (FO) state, and the “second order” (SO) state, and the “ Defining a transition between a "no context" (NC) state, a "static context" (SC) state, and a "full context" (FC) state;
One or more may be included.

  The method may include classifying the encapsulated frame such that only the predetermined frame is compressed using the header compression technique.

  The method may include applying a header to the payload according to one or more of Real Time Protocol (RTP), Universal Datagram Protocol (UDP), and Internet Protocol (IP).

  The method may include configuring the unit to configure a plurality of logical channels for communication between the units, wherein at least one of the channels is dedicated to transfer of the compressed encapsulated packet. .

This method uses the header compression technique, W-LSB (Window-Least Significant Bit coding).
) May be included.

  This method manages the switching between compressor state and decompressor state by providing a feedback channel between the units, adapted for error recovery requests and optionally notification of receipt of context updates. May be included.

This method
The unit receives a series of such compressed encapsulated frames segmented into baseband packets;
A positive acknowledgment of each packet is received, then the next packet is transmitted, and
If a transmission error occurs in either the latest packet or the reception notification message, the latest packet is retransmitted.
May be included.

This method retransmits the packet,
a) If no baseband packet access code is received,
b) An uncorrectable error is present in the baseband packet header, or
c) If an uncorrectable error is present in the payload of the packet,
Performing at least one of the following.

This method
For example, it may include limiting the number of retransmissions of the compressed encapsulated frame by setting a timeout until the frame is successfully transmitted.

The present invention is a software product for performing wireless communication based on a packet between a first communication unit and a second communication unit,
a) convert the real-time bit stream into one or more payloads with a predetermined maximum length;
b) Apply one or more predefined headers to the payload or each such payload to generate a packet suitable for transmission between the units according to a predefined communication protocol;
c) encapsulating said packet or each said packet in a frame of an encapsulation protocol adapted to transfer said packet or each such packet over the entire wireless connection between said units; and
d) applying a predefined header compression technique to the encapsulated packet or each such encapsulated packet;
We also provide software products, including code for

  The software product may be run in conjunction with a driver for Bluetooth network interface software that forms part of the communication unit.

The present invention
A packet-based wireless communication device having a first unit adapted to communicate information to a second unit in substantially real time,
The first unit is
a) convert the real-time bit stream into one or more payloads whose maximum length is predetermined;
b) Apply one or more predefined headers to the payload, or each of the payloads, in order to generate packets suitable for transmission between the units according to a predefined communication protocol. And
c) encapsulating the packet or each of the packets in a frame of an encapsulation protocol adapted to transfer the packet or each of the packets to the entire wireless connection between the units; and
d) applying a predefined header compression technique to each of the encapsulated packet or each of the encapsulated packets;
There is also provided a packet-based wireless communication device that is adapted as such.

  The first unit is operable according to the Bluetooth protocol. The encapsulation protocol preferably has BNEP, and the header compression technique is preferably compatible with the Internet Engineering Task Force (IETF) Robust Header Compression (ROHC) technique.

The invention also provides a communication unit adapted to operate according to the method of the invention, preferably having a master unit or slave unit of a Bluetooth network such as an access point or a mobile terminal. Header compression and / or decompression of the encapsulated packet may be implemented in the form of a software product that runs on the driver of the Bluetooth network interface software associated with the communication unit. . The software product may include a BNEP and L2CAP layer, a frame classifier, a ROHC codec, and a management entity (ME) for harmonization. This management entity may perform Bluetooth baseband communication via an HCI (Host Control Interface) and communicate with the upper protocol layer by a mechanism that the operating system is identified. For example, whenever a slave communication unit embodied as a mobile terminal MT _1-n connects to a master unit embodied as an access point AP _1-n , for example, the management entity A logical channel for the slave unit may be configured by registering a media access address (MAC).

The present invention will now be described with reference to particular embodiments and with reference to the drawings described above. Such description is exemplary only, and the present invention is not limited to this illustration. Specifically, reference is made to a packet and a communication system based on the packet. The present invention is not limited to packet switched systems, and any system that uses packets as a means for transmitting data (i.e., this system is a packet switched system, a circuit switched system, Those skilled in the art will recognize that the present invention is applicable to any other system or not. Where the term “wireless” is mentioned, it should be understood in its broadest sense. For example, wireless can include any system whose transmission is not dependent on a wired network (eg, includes optical transmission methods such as diffuse infrared). However, it should be noted that all embodiments of the present invention can be used with the Bluetooth protocol. Such system features may include one or more of the following.
-Slow frequency hopping is used as a scattering spectrum technique.
-A master unit and a slave unit, and the master unit can set a hopping sequence.
-Each device has its own clock and its own address.
-The hopping sequence of the master unit can be determined from the address of the master unit.
-A set of slave units in communication with one master unit all have the same hopping frequency (and this master unit) and form a piconet.
-A scatter net can be formed by linking piconets via a common slave unit.
-Time division multiplex transmission (TDMA) between the slave unit and the master unit.
-Time division duplex (TDD) between the slave unit and the master unit.
-The transmission between the slave unit and the master unit may be either synchronous or asynchronous.
-The master unit determines when the slave unit can transmit.
-It must respond only if the slave unit is addressed by the master unit.
-The clock is self-propelled.
-The network is not harmonized, especially in the 2.4 GHz license-free ISM band.
-The software stack allows applications to find other Bluetooth devices in the area.
-Other devices can be found by the discovery / query procedure.
-Hard handover and soft handover are performed.

  For frequency hopping, “slow frequency hopping” means that the hopping frequency is slower than the modulation rate, and “fast frequency hopping” means that the hopping rate is the modulation rate. It is faster than that. The present invention is not limited to either low speed hopping or high speed hopping.

  The user terminal referred to below is a mobile terminal, but the present invention is not limited to a mobile terminal, and includes a fixed user terminal such as a computer.

  This specification refers to header compression techniques, and specifically to robust header compression (ROHC). It may be helpful to summarize some aspects of these techniques, but for a better understanding, see the July 2001 paper by C. Borman et al., “Robust Header Compression (ROHC): Frames”. Work and 4 profiles: RTP profile, UDP profile, ESP profile, and uncompressed profile (Robust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP and uncompressed). This paper can be found on the Internet Engineering Task Force (IETF) website (reference number “RFC3095”) and from the URL: http://www.ietf.org/rfc/rfc3095.txt Is accessible.

  In general, the header compression mechanism takes advantage of the fact that static header fields with IP addresses and UDP ports, for example, do not change between sessions and therefore do not need to be transmitted in every packet, thereby increasing header overhead. Reduce. In addition, fields that change between sessions (eg, RTP timestamps, RTP sequence numbers, and IP identification) can be handled efficiently, further reducing header overhead. These so-called “changing fields” may be predictable from the previous packet using simple linear extrapolation. Since other header fields (eg, IP header length and UDP length) can be estimated from the data link level and these fields do not need to be transmitted, these fields are referred to as “estimated fields”.

  The header compression method is described in the February 1999 paper “Compressing IP / UDP / RTP Headers for Low-Speed Serial Links” (Internet RFC 2508). Proposed by S. Casner and V. Jacobson. This scheme compresses the RTP / UDP / IP header but is not designed to handle the error rate and round trip delay encountered on a typical wireless link.

  For example, header compression, such as `` Adaptive header compression (ACE) '' and `` Robust Checksum-based header compression (ROCCO) '', to adapt header compression to the wireless environment. Techniques have been proposed. “ACE” introduces “changing fields” (W-LSB (Window-based Least Significant BIT)), which is a method for coding fields. In this scheme, several reference values contained within a variable sliding window (VSW) are used and these values are communicated to the decompressor. ROCCO uses CRC to verify that the reconstruction was done correctly in the decompressor and to prevent errors from propagating.

  The IETF ROHC working group is currently researching new compression schemes that work well on links with high error rates and long round trip times. These schemes must be effective for cell links built using technologies such as WCDMA, EDGE, and CDMA-2000. However, these schemes need to be applicable to other future link technologies that are lossy and have long round trip times so that compression over unidirectional links can be achieved. IETF ROHC uses and combines all techniques studied by ACE and ROCCO. Details can be found at the IETF ROHC Working Group URL: http://www.ietf.org/html.charters/rohc-charter.html.

ROHC provides an extensible framework for robust header compression that can be applied to RTP / UDP / IP streams over wireless channels. Support for compression of TCP / IP headers and other types of protocols (eg Mobile IPv6) has also been added, and the following four profiles have been defined by the ROHC RFC to date.
0 Uncompressed IP packet
1 RTP / UDP / IP
2 UDP / IP
3 ESP / IP

  The present invention focuses on profile 1.

  ROHC compressors and decompressors allow static fields (that is, remain unchanged within a given context) while the dynamic fields of the real-time flow are processed correctly and the headers are reconstructed accordingly. Context information must be maintained so that no field is transmitted at all. Specifically, referring to FIG. 6a, a diagram of the compression and decompression chain can be seen.

A list of dynamic fields in the case of RTP / UDP / IP flow is shown below.
-IP identification (16 bits) IP-ID
-UDP checksum (16 bits)
-RTP marker (1 bit) M-bit-RTP sequence number (16 bits) SN
-RTP timestamp (32 bits) TS

  All other header fields are either static or estimated fields.

  Initially, the compressor is in an “initialization and refresh state” (IR). Here, the header is sent uncompressed so that the decompressor can create context for the IP flow. In the “first order” (FO) state, the compressor sends only static field updates to the decompressor to compensate for anomalies in the stream that may corrupt the context. Thus, in this state, the compressor only sends context updates. In the “second order” (SO) state, the compressor sends a compressed header because it is confident that the decompressor has already received a valid context. See specifically FIG. 6b.

  The decompressor starts from a “No-Context” (NC) state. As soon as the decompressor succeeds in decompressing the header, it goes to the “Full Context” (FC) state, which is the normal operating state. Only after decompressing the header repeatedly, the decompressor goes to the "Static Context" (SC) state, where it waits for a packet with an updated context to be sent by the compressor in the FO state. . If the valid context cannot be recovered, the decompressor returns to the NC state. See specifically FIG. 6c.

  Transitions between the states are managed by operation modes. Among these modes of operation, ROHC is “unidirectional” (U mode), “bi-directional optimistic” (O mode), and “bidirectional trust mode (bi)”. -directional reliable) "(R mode). In U mode, the decompressor-to-compressor feedback channel does not exist (or cannot be used), so transitions between compressor states are only based on periodic timeouts and anomalies in the incoming packet header. Absent. In this case, it is necessary to periodically refresh the context. In O mode, the feedback channel is used for error recovery requests and (optional) context update receipt notifications. The purpose of this mode of operation is to minimize the use of the feedback channel. Finally, the R mode uses a feedback channel intensively to maximize robustness against loss propagation and damage propagation.

W-LSB encoding:
If the value of the header field to be compressed is given as “v”, the W-LSB algorithm only transmits its least significant bit if an appropriate reference value (v_ref) is maintained at the compressor and decompressor. do not do. In order to eliminate mismatches between “v_ref” values, a suitable robust algorithm is defined that selects “v_ref” within the variable sliding window VSW. The number of least significant bits “k” to be transmitted for the value “v” to be compressed is selected as described below.

  Let (1) be an interval in which v is predicted to change. The offset parameter p can be selected according to the behavior of the specific field to be compressed.

Next, in the compressor,
The value k can be selected to be

  Therefore, k is a minimum value such that v falls within the interval f (v_ref, k).

However, this scheme may not be robust against errors. This is because the compressor does not know that the decompressor is using the same reference value (which may actually be different due to transmission errors). Instead, a variable sliding window is introduced.
Equation (3) includes the last w-th value that has been transmitted. Each time a new value enters the compressor, this value is added to VSW. Once the compressor is fully certain that some of the old values in the VSW have been received correctly, these values are removed from the VSW.

  In equation (4), the minimum and maximum values of VSW are defined. For the LSB coding scheme, k is selected according to the following equation:

G () in the formula is already defined in (2).

Thus, since it is not certain that the decompressor has enough reference intervals to decode the m bits transmitted, the field is coded with a larger number of bits. In practice, the decompressor decoding technique is based on the following algorithm.

  Equation (6) is defined as an interval for interpretation (given the last correctly decompressed value v_ref_d and the number of bits m received). To derive the uncompressed field, simply select a value in the interval for the above interpretation whose m least significant bits match the received m bits. Good.

  The size w of the variable sliding window depends on the certainty that the compressor has against the state of the decompressor. This decompressor state depends on the selected ROHC mode. For U mode and O mode, w depends on the embodiment. The syntax of a compressed packet by ROHC (defined later) sets the allowable dimensions of w. In fact, each packet type has a specific number of bits reserved for the coded header field, which automatically determines the window size. For example, RTP-SN reserves four bits in the UO-0 packet. This means that the window length is set to 16 (ie, a maximum of 15 packets can be lost). In R mode, the compression ratio can be maximized by using explicit feedback from the decompressor and minimizing the sliding window dimensions.

The W-LSB algorithm can be further illustrated with a simple example. Assume that the compressor sends the values 151, 152, 153, 154, and 155 and that the last three values were not received due to transmission errors on the radio link. At this time, in the compressor,
VSW = [151,152,153,154,155], v _min = 151, and v _max = 155
It becomes.

  Next, the value 156 is input to the compressor. The least significant bit number k to be transmitted is given by equation (5), from which k = max (3,1) = 3. Therefore, the last three LSBs (“100”) with the value 156 = “10011100” are transmitted.

In the decompressor, the values of 153, 154, and 155 are lost, so the last good reference value is 152. According to equation (6), the decompressor has an interval I _d = [152, 159] for interpretation. This is expanded below.

  It can be recognized that only 156 matches the three LSBs with the pattern “100” in this section. A little CRC applied to the original header (eg 8 bits depending on the mode) so that an undetected transmission error causes an incorrect decompression value that can later be used as a reference value to prevent damage propagation By doing so, the accuracy of decompression can be checked. Even if the CRC fails to detect the damaged value, it is compensated within the ROHC framework.

  Other encoding schemes are as follows.

  The W-LSB coding algorithm is not the only algorithm that can be used within the ROHC framework. There are other schemes that take advantage of some specific features of the header field, such as RTP timestamps, which usually increase in regular steps with time (by a multiple of the value of TS_STRIDE). This feature is exploited by the encoding of “scaled RTP timestamps”.

  The RTP timestamp can also be approximated using a linear function of the time of day for traffic generated at a constant rate, a fixed sampling frequency, and when packet generation is determined at this sampling frequency. In this case, “compress RTP time stamp based on timer” is applied. Consider only the offset between IP-ID and RTP sequence number (RTP sequence number is incremented by 1 for each new packet) and apply W-LSB coding to such offset Thus, the IP identification field (IP-ID) is encoded.

  The ROHC RTP profile is as follows.

  Certain header fields of the RTP / UDP / IP stream to be compressed can be configured as an ordered list. The ROHC framework provides a means for manipulating these lists so that the compressor can flexibly insert, remove or modify the list items (which form the context) in the decompressor.

The dynamic fields of the RTP header are encoded according to Table 1.
Table 1-RTP header dynamic field coding

  Since the IP-ID usually increases by the same delta as the sequence number and the timestamp increases by a fixed multiple of this same delta, the RTP TS and IP-ID fields are often from the RTP SN. Derivable. Therefore, when these conditions are true, only the RTP SN is included in the compressed header, and functions for deriving other fields are included in the context.

The ROHC packet has the following format.
Table 2-ROHC packet

  Each packet element in Table 2 starts with a unique bit pattern, except for the payload.

  The header carries context ID (CID) information. These headers contain 1 byte of “additional CID” (starting with the pattern “1110”) in octets for small CIDs of 1 to 15 or large CID space (up to 2 bytes ), Can carry embedded CID information. The ROHC context identifier is referred to as R-CID. If CID = 0 is not transmitted, the packet starts with the type of packet. This is a unique bit pattern different from “1110”, and it is estimated that the CID is empty.

  The feedback information can be piggybacked on any ROHC packet and carries negative and positive receipt notifications for context updates and header compression. The decompressor can also use a feedback packet to request a transition between modes (eg, from U mode to O mode).

Packet type:
Several packet type definitions are made by ROHC depending on these types of functions, the mode used, and which fields are carried. The notation of ROHC packet is as follows.
<Mode>-<type><optionalfield>
For example, UOR-2 packets can be used in U-mode, O-mode, or R-mode, and are of type 2.

As shown below, within the RTP profile, three packet types are used to identify the compressed header, and two packet types are used to initialize and refresh.
0. (R-0, R-0-CRC, UO-0) This is the RTP-SN coded in W-LSB, because all functions that derive other fields are known to the decompressor This is the smallest packet type that can only be transmitted.
1. (R-1, R-1-ID, R-1-TS, UO-1, UO-1-ID, UO-1-TS) This packet is necessary to encode RTP-SN. Used when the number of bits exceeds the number of bits available for packet type 0, or when the function for deriving RTP TS and IP-ID from IP-ID SN changes.
2. (UOR-2, UOR-2-ID, UOR-2-TS) Used to change the parameters of any SN function.
3. IR: This packet is used to communicate the static part of the context, ie a certain SN function.
4. IR-DYN: This packet type is used to communicate the dynamic part of the context, ie the non-constant SN function.

Table 3 shows the bit patterns that form a unique prefix for each of these packet types.
Table 3-Packet prefixes

  When the decompressor receives the packet, it immediately parses the first byte and, as a result, drives its state machine.

IR packet:
Initialization and refresh (IR) packets allow the decompressor to create a context for RTP / UDP / IP flows. The structure is shown in Table 4 below.
Table 4-IR packet format

  The octet-based Add-CID allows a context identifier to be associated with static header information carried in the rest of the packet. The D bit indicates that there is dynamic subheader information immediately after the static chain in the case of a profile specialized and RTP profile. The CID information field exists only when a large context identifier needs to be used. The profile field is an identifier for the ROHC profile. This is followed by an 8-bit CRC, but in this regard, Robust Header Compression (ROHC) outside C. Borman: Framework, and four profiles (RTP profile, UDP profile, ESP profile, and uncompressed profile) ) ". This can be found under the reference number “RFC3095” from the Internet Engineering Task Force (IETF) website. See Section 5.9.1 for the generator polynomial in which each value is computed on that field.

  The static chain contains an ordered list of static header fields. For example, the IPv4 header needs to be initialized with a static part including version, protocol, source address, and destination address. The dynamic part of the IPv4 header includes service type, lifetime, identification, DF, RND, NBO, and extended header list.

IR-DYN packet:
With this type of packet, the dynamic part of the context is updated and its format is shown in Table 5 below. In this case, only dynamic chains can be carried.
Table 5-IR-DYN packet format

General packet format Table 6 shows the compressed packet format. Since this structure depends on many conditions (Cx), it can be appreciated that the process may not be clear.
Table 6-Common compressed packet formats

  Each condition depends on the value of the flag field decoded immediately before. Optionally, there may be a header extension that carries additional ROHC information (four different extension types are defined). An IP-ID field may be present if the context indicates that this field changes randomly.

  AH data refers to an authentication header that contains security-related values. The GRE checksum refers to the GRE tunnel (RFC2784, RFC2890). UDP checksums exist only when explicitly indicated in the context.

Robust header compression for Bluetooth:
The present invention
a) application of robust header compression (ROHC) to Bluetooth communication systems; and
b) Extension of ROHC to BNEP,
Focus on two main issues:

  The present invention provides a new protocol that compresses VoIP frames, video / audio streams, or the like, to fit into a single slot Bluetooth baseband packet. This protocol is referred to as “ROHC-BNEP” for convenience in the present specification.

  The present invention is not limited to voice applications only, but can also be applied to other IP traffic such as audio / video streaming applications, including the transfer of real-time IP services within a Bluetooth piconet. According to the present invention, BNEP information is added to the context of ROHC compressor and decompressor. By doing this, not only IP packets but also layer 2 frames are compressed.

Referring specifically to FIG. 2, a protocol stack for a mobile handset MT _1-n can be seen according to one embodiment of the present invention. By adding a 12-byte RTP header to each packet generated by the speech encoder, time synchronization is possible. By adding an 8-byte UDP header, it is possible to multiplex application flows into one and add a header checksum. This UDP datagram is encapsulated in an IP packet. The IP packet has a 20-byte or 40-byte header depending on whether the IP version used is 4 or 6. The BNEP header used to encapsulate IP packets into Bluetooth frames ranges from 3 to 15 bytes. It can be seen that robust header compression (ROHC) is applied to BNEP frames carrying RTP / UDP / IP flows.

  To carry this compressed frame in a single slot DH1 baseband packet with a 27-byte payload, and considering the 4-byte L2CAP header overhead, the RTP / UDP / IP / BNEP header Must be reduced to 3 bytes by ROHC compressor. This goal can be reached if the BT system and ROHC compressor are properly configured as described below.

The proposed solution includes several steps:
-Advertise ROHC compression capability using standard Bluetooth service discovery protocol.
-Configuring the L2CAP channel to carry the compressed bit stream.
-Adding BNEP static header fields to the ROHC context (all BNEP header fields are static within a single VoIP session).
-Adapting the ROHC framework to the Bluetooth baseband retransmission scheme.
Classifying BNEP frames so that only frames carrying VoIP packets are compressed using the proposed ROHC-BNEP algorithm.

Above we have referred to the general ROHC framework. The next section details the application of the ROHC framework to the Bluetooth case, including the packet types to use, how to select these packet types, and how to manage transitions between compressor states. ROHC-BNEP uses the following tools:
-RTP profile is used.
-ROHC bi-directional optimistic mode is the approach used. However, if decompression is not successful, only NACKS is fed back, so try to minimize the use of NACKS as much as possible.
-Only small R-CIDs are used. A large CID space is not required and an empty R-CID does not need to be transmitted and is used by default.
-UDP checksum is not transmitted (it is optionally possible to recalculate the UDP checksum with the decompressor only if the payload is not encrypted).
-The entire BNEP header will never change for the same VoIP flow and must be considered as part of the static context.
-Since the function of deriving the RTP TS is known, only the RTP sequence number and / or IP-ID is transmitted (timer based coding is applied to compensate for silence suppression).
-The use of the feedback channel is minimized so that only the context update request from the decompressor to the compressor is carried.
-Transitions are defined between the "initialization and refresh" (IR) state, the "first order" (FO) state, and the "second order" (SO) state for the compressor, and the decompressor In this case, a definition is made between a "no context" (NC) state, a "static context" (SC) state, and a "context full" (FC) state.

  The state machine in Figure 7 further clarifies ROHC over Bluetooth. For each compressor state, it is shown which information is transmitted (top), which packet is being used (bottom), and how many bytes are sent in the header information (between parentheses). The transitions between each state are also shown. Hereinafter, the transition between the states will be described.

  Initially, the compressor is in the IR state and all static and dynamic parts of the context must be transmitted to the decompressor. The transition from IR to FO can only be performed if the number of packets lost at observation time t lp (t) is less than the number of packets lost at observation time t-1 lp (t-1) . These observation times are fixed points of time at which the compressor registers the number of VoIP frames that could not be successfully sent to the decompressor within a configurable time threshold. lp (t) increases by 1 each time an L2CAP timeout event is received in the L2CAP layer in the Bluetooth stack during the interval (t−1, t). The FO to SO transition can only occur if the compressor registers that the incoming VoIP stream does not indicate anomalies (eg, silence suppression in a voice coder). Once the compressor is in the SO state, it returns to FO if the IP stream indicates an abnormality. In the FO state, the compressor returns to the IR state if a NAK packet is received via the feedback channel indicating that the static context has been corrupted.

Mapping of ROHC RTP over Bluetooth:
The ROHC-BNEP algorithm described in the next section corresponds to the ROHC two-way optimistic approach. This approach is referred to above by “Robust Header Compression (ROHC)” by C. Borman, “Robust Header Compression (ROHC): Framework and 4 Profiles: RTP Profile, UDP Profile, ESP Profile, and Uncompressed Profile (RoHC Header Compression (ROHC) : Framework and four profiles: RTP, UDP, ESP and uncompressed).

  The use of a feedback channel is kept to a minimum so that it only carries context update requests from the decompressor to the compressor. The packet types used in the ROHC RTP profile can be found in Section 5.2.7 of the paper by C. Borman et al. The decompressor indicates that it wants to transition to the optimistic mode after starting in one-way mode and sending a feedback packet back to the compressor to obtain context information. As soon as the compressor receives such a request, it saves bandwidth by stopping sending periodic IR updates and going to O mode.

  In order to evaluate the effectiveness of the ROHC-BNEP RTP / UDP / IP header compression algorithm within a Bluetooth system, several points must be considered. First, consider the Bluetooth logical link control and adaptation layer (L2CAP), and then consider again the mechanism for handling baseband errors.

Link layer framing:
The L2CAP layer provides logical channels and segmentation and reassembly (SAR) functionality to the Bluetooth stack. The logical channel is identified by a channel ID (CID) and set up by a dedicated L2CAP signaling message between peer entities using existing baseband connections. Several logical channels can be established between two BT devices on this same baseband connection. For each logical channel, a link layer MTU (Maximum Transmission Unit) is defined, which limits the maximum L2CAP frame size. The L2CAP SAR function is a function in which an L2CAP frame is divided into a plurality of baseband packets and these packets are transmitted in sequence.

  Since baseband layers cannot distinguish between L2CAP connections, baseband packets belonging to different L2CAP frames cannot be interleaved. In other words, once the first packet of the L2CAP frame is transmitted, all remaining packets of the same logical connection must follow this.

  This feature means that when two applications are using the same logical channel (or even when using two different logical channels), a longer frame with a lower priority than a higher priority This means that transmission of short frames may be delayed.

  Therefore, it is recommended that L2CAP MTU parameters be used appropriately to eliminate these blocking effects. As an example, consider a VoIP application and a BT client with one or more TCP / IP connections. These two applications have different characteristics. That is, the first application is easily affected by delay and the packet is short, while the second application is not limited by delay, but the packet can be up to 1500 bytes long. To avoid delaying real-time traffic, a small MTU value must be used for TCP / IP connections even if fragmentation overhead in the IP layer increases.

  These two applications have different reliability requirements. For real-time traffic, packets that are delayed due to transmission errors that exceed a certain threshold can no longer be valid and can be dropped, but this is not the case for TCP / IP data connections.

  Automatic flush timeout is applicable to each L2CAP logical channel using a configurable value. In the case of simulation by the applicant, a timeout of 12.5 ms was used to discard the VoIP frame.

  Allows TCP / IP frames to be discarded to improve the quality of VoIP applications when TCP / IP and RTP / UDP / IP are simultaneously on the same BT link, as in the above example by the applicant You must evaluate whether or not. This choice depends on many factors and is related to both real-time traffic and data traffic (in the case of data traffic, TCP / IP retransmission will have to be considered).

  When applying the ROHC-BT algorithm in a Bluetooth system, the number of logical channel L2CAP timeouts that are sensitive to delay plays a major role in increasing the robustness to errors of the header compression mechanism. In fact, the L2CAP timeout event indicates that a frame has been lost, so the header compressor can use this information to increase the window, for example, by selecting the appropriate ROHC packet type. .

Error handling:
The ARQ mechanism within the Bluetooth baseband is a mechanism in which the receiver must explicitly acknowledge receipt of each baseband packet before the next packet is transmitted. If a transmission error occurs in either a data packet or an acknowledgment message, the packet must be retransmitted. Error conditions that cause packet retransmission include the following:
-The baseband packet access code is not received.
-Errors in the baseband packet header cannot be corrected.
-The error in the packet payload cannot be corrected (only if such an error condition occurs in the acknowledgment packet, the ACK field is carried in the packet header, so retransmission is not triggered) .

  All baseband packets that are part of the same L2CAP frame must be received correctly before the frame assembled at the receiver is passed to the upper layer. At the transmitter, the L2CAP frame must be positively acknowledged within a configurable time range to avoid any L2CAP timeout event, with all baseband packets that are split into it.

  When an L2CAP timeout event occurs, the transmitter flushes all remaining baseband packets in both the L2CAP layer and in the host controller using the HCI_Flush command (Bluetooth SIG “core” See Specification v1.1 ”(H: Part 1, Section 4.7.4)). This command resets all pending retransmissions for the specified connection handle. Normal operation resumes only when a new HCI data packet tagged as the beginning of a new frame is received.

  The receiver of the L2CAP connection is notified of the transmitter's L2CAP timeout using the Flush_Timeout option in the L2CAP channel configuration (see Bluetooth SIG “Core Specification v1.1.1” (Part D, Section 6.2)) I want to be)

From point to multipoint:
If the VoIP transmitter is running in a Bluetooth slave and other slaves are connected to the master, the polling access method needs to be considered to some extent.

  First, the slave needs to request the master to poll at a rate that matches the generation of VoIP packets (eg, every 30 ms). This is accomplished by negotiating with the appropriate Tpol using the HCI_QoS_setup command translated as LMP_quality_of_service_request.

  However, in the case of a point-to-multipoint configuration, the number of retransmissions of the Bluetooth baseband ARQ scheme is not limited. Means that this can be done when the slave polls the slave. (See Bluetooth SIG "Core Specification v1.1" (Part B, Section 5.3.1)). This means that the L2CAP timeout in the slave can be activated according to the master's scheduling policy.

Constitution:
FIG. 3 shows the initial configuration process. This figure shows the flow between a personal area network user (PANU) and a network access point NAP (AP _1-n ). As soon as the handset MT makes a first connection to the access point AP _1-n , it performs an SDP query to obtain information about the services supported by the access point AP _1-n . The access point AP _1-n advertises PAN capability to the standard BNEP protocol (assigned PSM value) and the ROHC-BNEP capability is the new ROHC-BNEP protocol specified in this document. (For this, a dynamic PSM can be used).

  Initially, a reliable connection with L2CAP is made by requesting a PSM specific to BNEP. Next, a second L2CAP connection is made by using the dynamic PSM value for ROHC-BNEP already advertised in the SDP record. This second connection will be configured as unreliable using L2CAP quality of service (QoS) setup messages. As a result, the number of retransmissions of VoIP packets can be limited. In fact, if packet transmission is not successful within a certain period of time, this packet becomes useless to the receiver and can be discarded, thereby saving bandwidth. This requires deferring packet retransmission and freeing all associated buffers in the BT link manager by combining the L2CAP timeout with the baseband flush command. In summary, a mobile handset needs to configure two logical channels: one logical channel for carrying standard IP traffic and the other logical channel for compressing VoIP streams. Once these L2CAP logical channels are set up, the mobile terminal and access point must use these channels consistently, as described in the next subsection.

  When only one L2CAP channel can be established between the access point AP and the mobile terminal MT, it is necessary to make a data connection using this “unreliable” channel in order to protect the VoIP flow. This loss of data packets on unreliable logical channels can be handled by higher layer protocols (eg, TCP / IP).

Transmitter and receiver logic:
At the transmitter, whenever the BNEP frame has to be sent to the L2CAP, the algorithm represented in FIG. 4a can be used.

  First, in order to understand whether the BNEP frame must be compressed, the BNEP frame must be classified. In practice, only BNEP frames carrying RTP / UDP / IP packets must be processed by the proposed ROHC-BNEP algorithm.

The following BNEP header fields are checked:
-BNEP end-point address (peer must have ROHC capability)
-BNEP protocol type (must be “IP” or “IPv6”. In addition, IEEE802.1p and IEEE802.1q must be interpreted for Ethernet frame tagging as they are used in LANs that support QoS. Must)
-IP protocol type (must be UDP)
-UDP port (must be compatible with H.323)
If a BNEP frame must be compressed, its ROHC context is retrieved and the resulting compressed frame is sent to the L2CAP layer using the L2CAP CID (L-CID) corresponding to the unreliable channel. The If this frame does not need to be compressed, a highly reliable channel L-CID is used instead.

  In the receiver, as shown in FIG. 4b, it is assumed that when a frame corresponding to ROHC-BNEP L-CID arrives from an unreliable channel, ROHC-BNEP must be decompressed. This frame is sent to the BNEP layer after successful reconstruction.

  If the compressed frame cannot be accurately reconstructed, this frame is discarded in the decompressor. If N2 compressed consecutive packets could not be reconstructed, a negative ACK is sent back to the peer ROHC compressor using the unreliable channel and ROHC feedback packet type (ROHC algorithm See below for explanation). N2 is set to 15, for example.

  FIG. 5 shows a block diagram of the ROHC-over-BNEP configuration. The ROHC codec and all associated logic can be implemented in the form of a software product that runs in conjunction with a Bluetooth network interface software driver. The software product includes a BNEP and L2CAP layer, a frame classifier, a ROHC codec, and a management entity (ME) that coordinates the various blocks. The ME can communicate with the BT baseband via a standard HCI interface (if present) and can communicate with higher layers by a mechanism specific to the operating system.

Each time the mobile terminal MT _1-n connects to the AP _1-n , the ME registers its MAC address and configures a logical channel for this address. In the case of Bluetooth, a logical channel is characterized by several channel termination points named L2CAP channel ID (L-CID). Immediately after channel setup, each peer assigns its own local L-CID and sends it to the remote device. Therefore, the following table for ROHC can be constructed.
Table 9-Example AP configuration of ROHC-BNEP

In the case of the example in Table 9, two mobile terminals MT _{1 and 2} are connected to AP ₁ .
MT1 consists of two logical channels, one for normal IP traffic and the other for VoIP. This second channel will use an empty ROHC context ID. When MT2 connects to access point AP _1, it configures a channel for VoIP. In this case as well, an empty R-CID can be used. However, if MT1 configures another channel for the second RTP / UDP / IP / BNEP flow (fourth column), a different ROHC context must be used. This is because MT1 now has two real-time streams that must be handled separately (eg, one audio channel and one video channel).

  Applying the proposed robust header compression technique disclosed herein between the mobile terminal and the access point saves bandwidth and thereby allows more in the same pinonet It becomes possible to handle the connection.

  While the invention has been particularly shown and described with reference to preferred embodiments, it will be understood by those skilled in the art that changes in form and detail are possible within the scope of the invention.

Glossary:

1 is a schematic diagram of a communication system. 2 is a protocol stack for a communication unit according to one embodiment of the invention and suitable for use in the system of FIG. 3 is a flowchart of the network configuration of the communication unit of FIG. 3 is a flowchart of a header compressor used in practicing the present invention. 2 is a flow diagram of a header decompressor used in practicing the present invention. It is a diagram regarding the function of the Example of this invention. It is a schematic diagram of a header compression and decompression chain. It is a block diagram of each state of a compressor. It is a block diagram of each state of a decompressor. 4a is a state machine for the header compressor of FIG. 4a.

Claims (21)

A method for wireless transmission based on a packet between a first unit and a second unit,
The unit is
a) converting the real-time bit stream into one or more payloads whose maximum length is predetermined;
b) applying one or more predefined headers to the payload or each such payload to generate a packet suitable for transmission between the units according to a predefined communication protocol;
c) encapsulating said packet or each said payload in a frame of an encapsulation protocol adapted to transfer said packet or each said packet over the entire wireless connection between said units;
d) applying a predefined header compression technique to the encapsulated packet or each such encapsulated payload;
Including methods.   The method of claim 1, comprising generating the payload, or each such payload, from the real-time bit stream having Internet Protocol (IP) traffic, such as a VoIP stream, an audio stream, or a visual stream. Method.   The method of claim 1 or claim 2, comprising performing a service discovery procedure between the first unit and the second unit and advertising the header compression technique during the service discovery procedure.   A method according to any of the preceding claims, comprising multiplexing one or more segments, reassembling and multiplexing the services of the predefined communication protocol carrying the compressed bit stream. .   Apply the header compression, for example by adding encapsulation protocol information with the static header field of the encapsulation protocol to the compressor and decompressor contexts that are adapted to apply the header compression technique A method according to any of the preceding claims comprising: The unit includes a Bluetooth network part, and
The method encapsulates the packet or each such packet using an encapsulation protocol having a Bluetooth network encapsulation protocol (BNEP);
A method according to any preceding claim, comprising:   Preferably, the encapsulated packet or each encapsulated packet is reduced by reducing the combination of the predetermined header and the BNEP header to a predetermined length (eg, 3 bytes). 7. The method of claim 6, comprising compressing the packet into a single slot Bluetooth baseband packet using the header compression technique.   A method according to any preceding claim, comprising applying the header compression technique in the form of a robust header compression (ROHC) framework such as ROHC approved by the Internet Engineering Task Force (IETF). . a) Use a real-time protocol (RTP) profile for the packet;
b) Use a bi-directional optimistic approach (o-mode) by IETF ROHC;
c) Use a small ROHC context identifier (R-CID) (R-CID default is empty);
d) Do not transmit a Universal Datagram Protocol (UDP) checksum, and optionally recalculate this checksum with a decompressor;
e) considering the entire header of the encapsulation protocol as part of the static context during any one packet flow;
f) transmit only the real-time protocol (RTP) sequence number and / or the internet protocol identification;
g) Transitions between the “initialization and refresh” (IR) state in the compressor, the “first order” (FO) state, and the “second order” (SO) state, and the “ Defining a transition between a "no context" (NC) state, a "static context" (SC) state, and a "full context" (FC) state;
9. The method of claim 8, comprising one or more.   A method according to any preceding claim, comprising classifying the encapsulated frames such that only the predetermined frames are compressed by the header compression technique. The method of any preceding claim, comprising applying a header to the payload according to one or more of Real Time Protocol (RTP), Universal Datagram Protocol (UDP), and Internet Protocol (IP). Method. The unit configures multiple logical channels for communication between the units,
At least one of the channels dedicated to the transfer of the compressed encapsulated packet;
A method according to any preceding claim, comprising:   The method according to any one of the preceding claims, comprising performing the header compression technique based on W-LSB (Window-Least Significant Bit coding).   Managing switching between compressor state and decompressor state by providing a feedback channel between the units, adapted to provide error recovery requests and optionally notification of receipt of context updates, A method according to any of the claims. The unit receives a series of the compressed encapsulated frames segmented into baseband packets;
A positive acknowledgment of each packet is received, then the next packet is transmitted, and
If a transmission error occurs in either the latest packet or the reception notification message, the latest packet is retransmitted.
A method according to any preceding claim, comprising: Retransmit the packet
a) If no baseband packet access code is received,
b) An uncorrectable error is present in the baseband packet header, or
c) If an uncorrectable error is present in the payload of the packet,
16. The method of claim 15, comprising performing in at least one of the following cases.   The method according to any of the preceding claims, comprising limiting the number of retransmissions of the compressed encapsulated frame, for example by setting a timeout before successful transmission of the frame. A software product for executing wireless communication based on packets between the first communication unit and the second communication unit,
a) convert the real-time bit stream into one or more payloads with a predetermined maximum length;
b) Apply one or more predefined headers to the payload or each such payload to generate a packet suitable for transmission between the units according to a predefined communication protocol;
c) encapsulating said packet or each said packet in a frame of an encapsulation protocol adapted to transfer said packet or each such packet over the entire wireless connection between said units; and
d) applying a predefined header compression technique to the encapsulated packet or each such encapsulated packet;
Software products, including code for A packet-based wireless communication device having a first unit adapted to communicate information to a second unit in substantially real time,
The first unit is
a) convert the real-time bit stream into one or more payloads whose maximum length is predetermined;
b) Apply one or more predefined headers to the payload, or each of the payloads, in order to generate packets suitable for transmission between the units according to a predefined communication protocol. And
c) encapsulating the packet or each of the packets in a frame of an encapsulation protocol adapted to transfer the packet or each of the packets to the entire wireless connection between the units; and
d) applying a predefined header compression technique to each of the encapsulated packet or each of the encapsulated packets;
A packet-based wireless communication device that is adapted to: The first unit is operable according to the Bluetooth protocol;
Preferably, the encapsulation protocol has a Bluetooth network encapsulation protocol (BNEP), and
Preferably, the header compression technique is compatible with Internet Engineering Task Force (IETF) robust header compression (ROHC) technique,
21. The wireless communication device according to claim 20.   Preferably adapted to operate according to the method according to any of claims 1 to 19 and at least temporarily configured as at least one of a master unit and a slave unit of a Bluetooth communication network, Wireless communication unit.