WO2009056899A1 - Décision de changement de canal basée sur une priorité de connexion - Google Patents

Décision de changement de canal basée sur une priorité de connexion Download PDF

Info

Publication number
WO2009056899A1
WO2009056899A1 PCT/IB2007/003332 IB2007003332W WO2009056899A1 WO 2009056899 A1 WO2009056899 A1 WO 2009056899A1 IB 2007003332 W IB2007003332 W IB 2007003332W WO 2009056899 A1 WO2009056899 A1 WO 2009056899A1
Authority
WO
WIPO (PCT)
Prior art keywords
channel
change
channel change
priorities
prioritized
Prior art date
Application number
PCT/IB2007/003332
Other languages
English (en)
Inventor
Christian Zechlin
Thomas Block
Original Assignee
Nokia Corporation
Nokia Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Corporation, Nokia Inc. filed Critical Nokia Corporation
Priority to PCT/IB2007/003332 priority Critical patent/WO2009056899A1/fr
Publication of WO2009056899A1 publication Critical patent/WO2009056899A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/06—Reselecting a communication resource in the serving access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/08—Reselecting an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/16—Discovering, processing access restriction or access information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks

Definitions

  • the technical field relates to wireless communications. More particularly, the technical field relates to techniques for sharing wireless communications media in wireless network environments.
  • Short-range wireless proximity networks typically involve devices that have a communications range of one hundred meters or less. To provide communications over long distances, these proximity networks often interface with other networks. For example, short- range networks may interface with cellular networks, wireline telecommunications networks, and the Internet.
  • High rate physical layer (PHY) techniques for short-range proximity networks are quickly emerging.
  • One such technique involves frequency hopping applications of orthogonal frequency division multiplexing (OFDM).
  • This technique involves the transmission of OFDM symbols at various frequencies according to pre-defined codes, such as Time Frequency Codes (TFCs).
  • Time Frequency Codes can be used to spread interleaved information bits across a larger frequency band.
  • the WiMedia Ultra- Wideband (UWB) Common Radio Platform incorporates media access control (MAC) layer and physical (PHY) layer specifications based on Multi-band Orthogonal Frequency Division Multiplexing (MB- OFDM).
  • MAC media access control
  • PHY Physical
  • MB- OFDM Multi-band Orthogonal Frequency Division Multiplexing
  • the WiMedia UWB enables short-range multimedia file transfers at high data rates with low power consumption, and operates in the 3.1 to 10.6 GHz UWB spectrum.
  • WiMedia Alliance has developed an OFDM physical layer. This physical layer is described in WiMedia Alliance MultiBand OFDM Physical Layer Specification, Release 1.1, January 14, 2005 (also referred to herein as the WiMedia PHY. This document is incorporated herein by reference in its entirety.
  • the WiMedia Medium Access Control (MAC) group is developing a MAC layer that would be used with an OFDM physical layer, such as the WiMedia PHY.
  • This MAC layer involves a group (referred to as a beacon group) of wireless communications devices that are capable of communicating with each other.
  • the timing of beacon groups is based on a repeating pattern of "superframes" in which the devices may be allocated communications resources. These communications resources may be in the form of one or more time slots, referred to as media access slots (MASs).
  • MASs media access slots
  • a MAC frame may have various portions. Examples of such portions include frame headers and frame bodies.
  • a frame body includes a payload containing data associated with higher protocol layers, such as user applications. Examples of such user applications include web browsers, e-mail applications, messaging applications, and the like.
  • MAC layers govern the allocation of resources. For instance, each device requires an allocated portion of the available communication bandwidth to transmit frames.
  • the WiMedia MAC provides for the allocation of resources to be performed through communications referred to as beacons. Beacons are transmissions that devices use to convey non-payload information. Each device in a beacon group is assigned a portion of bandwidth to transmit beacons.
  • WiMedia MAC Such transmissions allow the WiMedia MAC to operate according to a distributed control approach, in which multiple devices share MAC layer responsibilities. Accordingly, the WiMedia MAC Specification v. 1.2 provides various channel access mechanisms that allow devices to allocate portions of the transmission medium for communications traffic. These mechanisms include a protocol called the distributed reservation protocol (DRP) in which reservations for connections are negotiated among devices. These mechanisms also include a protocol called prioritized contention access (PCA).
  • DRP distributed reservation protocol
  • PCA prioritized contention access
  • the WiMedia PHY provides for various channels across a frequency range.
  • Each logical channel employs a different Time Frequency Code (TFC).
  • TFCs specify a repeating time sequence in which various frequency bands within a frequency range are used.
  • a device employing a TFC transmits at different frequencies at particular times specified by the TFC.
  • the WiMedia PHY specifies each band having a 528 MHz bandwidth. Also, these bands are within a frequency operating range of between 3.1 and 10.6 GHz.
  • a WiMedia MAC device decides to change or re-select a beacon group channel, it can send a Channel Change IE notice in its beacon to inform the other devices of that beacon group.
  • Many situations can occur in which a channel change is desirable (for either a device or to a group of devices).
  • a channel change is desirable (for either a device or to a group of devices).
  • a currently used channel i.e. a beacon group) is congested. This congested condition may be attributed to a large number of devices in the beacon group and/or to a lack of available resources for a new application or DRP reservation.
  • Other situations in which a channel change is desirable to occur is when radio conditions for the current channel are poor (e.g. interference, frame error rate, etc.), the achievable range on the current radio channel is insufficient, and/or a specific device is found operating on another channel.
  • a problem in the art is that in channel change situations, the UWB PHY device that has been requested to make a channel change by an external host device or a link owner device needs to respond to the channel change request quickly. However, if the channel change request is forwarded to the device host side from the UWB PHY chip, unnecessary delay is created that can result in degrading channel change performance.
  • the existing WiMedia MAC Specification provides that a device initiating a channel change will send a ChannelChange IE containing a ChannelChangeIECount which tells when the Channel Change will happen.
  • the WiMedia MAC Specification does not define any minimum start value for the counter; it could be as short as 130ms.
  • the WiMedia MAC Specification states: "On reception of a Channel Change IE, a device that also intends to change channels in a coordinated manner should include a Channel Change IE with the same fields in its beacon.” This means that a device initiating a Channel Change will assume that a remote device will not follow if the remote device did not include the same ChannelChange IE in its beacon. Thus, a device receiving a ChannelChange IE must react fast to reply with its own ChannelChange IE, indicating: "Yes, I agree with this Channel Change”.
  • a problem in the art is that the physical transceiver chip that receives a ChannelChange IE would have to ask its Host each time whether or not a channel change is allowed. This means (assuming e.g. a ChannelChangeIECount start value of 130ms) that the Host needs to return an acknowledgement within 65ms, otherwise there is no chance to add its own ChannelChange IE in the next beacon to be transmitted.
  • the UWB PHY chip makes a channel change decision based on priority information that has been provided to the UWB PHY chip by the host using an API that the host uses for assigning priorities for various existing connections.
  • API primitives enable the host to provide the necessary information to the UWB PHY chip.
  • the UWB PHY chips include logic to maintain the priority information and to appropriately react to various events based on the available priority information.
  • a wireless communications device selects a channel finding technique in a first stage, based on whether the device has any active connections in a current channel.
  • the device receives channel change priorities from its host, assigning priorities for various existing connections.
  • the device then performs the selected channel finding technique with a plurality of channels to find a candidate channel.
  • the device determines based on the priorities of the existing connections whether a channel change is prioritized without involving the hosting entity in the determination. If the determination indicates that the channel change is prioritized, then the device sends a request to at least one remote device to change its channel from the current channel to the candidate channel during an allocated time slot of a beacon period within a repeating time interval.
  • the initiating device receives an acceptance of the request from the remote device. Then in a second stage, the initiating device selects a channel changing technique based on whether the device has any active connections in the current channel. If it is determined that the channel change is prioritized, then the initiating device executes the selected channel changing technique to change a channel from the current channel to the candidate channel, thereby establishing the desired new connection across the candidate channel with the remote device.
  • a transceiver module comprises a wireless interface configured for exchanging information across a current channel through wireless connections with one or more remote devices, wherein the information includes receiving information indicative of a channel change by at least one of the one or more remote devices, an interface configured for coupling the transceiver module with a local hosting entity configured for receiving channel change priorities assigning priorities for the existing wireless connections from the hosting entity and a controller configured for determining, based on the priorities of the existing wireless connections, whether a channel change is prioritized without involving the hosting entity in the determination.
  • a chipset comprises at least one radio part and an antenna configured for exchanging information across a current channel through wireless connections with one or more remote devices, wherein the information includes receiving information indicative of a channel change by at least one of the one or more remote devices, one or more data buses coupling the chipset with a local hosting entity configured for receiving channel change priorities assigning priorities for the existing wireless connections from the hosting entity and a controller configured for determining, based on the priorities of the existing wireless connections, whether a channel change is prioritized without involving the hosting entity in the determination.
  • the resulting embodiments solve problems of unnecessary delay when a channel change request is forwarded to the device host side from the UWB PHY chip.
  • FIG. 1 is a diagram of an exemplary operational environment
  • FIGs. 2A and 2B are diagrams of superframe formats employed in shared transmission media;
  • FIG. 3 A is a flowchart of a channel changing process executed by an initiating device according to at least one embodiment
  • FIG. 3B is a more detailed flowchart of an exemplary channel changing process executed by an initiating device, according to at least one embodiment
  • FIG. 3 C is a flow chart of a channel changing process executed by a remote device according to at least one embodiment
  • FIGs. 4-6 are diagrams involving the format of a Distributed Reservation
  • FIG. 7 is a diagram of a device architecture, according to at least one embodiment
  • FIG. 8 is a diagram of a wireless communications device implementation, according to at least one embodiment
  • FIG. 9 A is a diagram of a new Unavailability Information Element according to at least one embodiment
  • Fig. 9B is a flow diagram of the channel finding technique using the
  • FIG. 1 OA is a diagram of a modified Channel Change Information Element according to at least one embodiment
  • Fig. 1 OB is a flow diagram of the channel changing technique using the modified Channel Change Information Element according to at least one embodiment
  • FIG. 11 is a diagram of a new Channel Change Request Information Element according to at least one embodiment
  • FIG. 12 is a diagram of a new Channel Change Response Information Element according to at least one embodiment
  • FIG. 13 is a diagram of a Command Frame definition for Channel Change
  • FIG. 14 is a diagram of a Channel Change Command Frame Type encoding according to at least one embodiment.
  • FIG. 15 illustrates an exemplary software architecture according to at least one embodiment.
  • FIG. 16 is an example message sequence diagram for Channel Change according to at least one embodiment.
  • FIG. 17 is an example message sequence diagram for getting the remote device to change to the current active channel according to at least one embodiment.
  • FIG. 18A-18E illustrate exemplary channel change decision making scenarios.
  • FIG. 19 is a diagram of a transceiver according to at least one embodiment.
  • FIG. 1 is a diagram of a communications environment in which the techniques of the embodiments may be employed.
  • This environment includes a beacon group 100 in which multiple communications devices (DEVs) 102 may exchange wireless transmissions.
  • DEVs communications devices
  • FIG. 1 shows a device 102a sending a wireless transmission 120 to a device 102b.
  • FIG. 1 shows a device 102d sending a wireless transmission 122 to a device 102c.
  • Transmissions 120 and 122 are shown as being point-to-point communications. However, each of devices 102 periodically sends a transmission referred to as a beacon, which is directed (broadcast) to each device in beacon group 100. For instance, FIG. 1 shows device 102a transmitting a beacon 124, device 102b transmitting a beacon 126, device 102c transmitting a beacon 128 and device 102d transmitting beacon 125. Beacon transmissions are described in greater detail below.
  • Wireless network transmissions in the environment of FIG. 1 such as beacons and data communications may be based on a repeating time interval, such as a superframe.
  • An exemplary superframe format is shown in FIG. 2A.
  • FIG. 2A shows a frame format having superframes 202a, 202b, and 202c.
  • Each superframe 202 includes a beacon period 204 and a data transfer period
  • each beacon period 204 includes multiple beacon slots 207. Slots 207 each correspond to a particular device in the network.
  • the devices employing beacon slots 207 are referred to as a beaconing group.
  • the corresponding device may transmit various overhead or networking information. For WiMedia networks, such information may be in predetermined forms called Information Elements (IEs).
  • IEs Information Elements
  • beacon periods 204 may be used to transmit information regarding services and features (e.g., information services, applications, games, topologies, rates, security features, etc.) of devices within the beaconing group. The transmission of such information in beacon periods 204 may be in response to requests from other devices.
  • services and features e.g., information services, applications, games, topologies, rates, security features, etc.
  • Data transfer period 206 is used for devices to communicate data according to various transmission schemes. These schemes may include, for example, frequency hopping techniques that employ OFDM and/or time frequency codes (TFCs). For instance, data transfer periods 206 may support data communications across links 120 and 122. In addition, devices (e.g., DEVs 102a-d) may use data transfer periods 206 to transmit control information, such as request messages to other devices. The current WiMedia MAC provides for command and control frames for the transfer of such information. To facilitate the transmission of traffic, each device may be allocated one or more particular time slots within each data transfer period 206. In the context of the WiMedia MAC, these time slots are referred to as media access slots (MASs).
  • MASs media access slots
  • a MAS is a period of time within data transfer period 206 in which two or more devices can exchange data (i.e., communicate).
  • MASs may be allocated among devices within the beacon group by a dedicated reservation protocol, called the distributed reservation protocol (DRP).
  • DRP protects the MASs from contention access by devices acknowledging the reservation.
  • the WiMedia MAC provides for resource allocation according to a prioritized contention access (PCA) protocol.
  • PCA isn't constrained to reserving one or more entire MASs. Instead, PCA can be used to allocate any part of the superframe that is not reserved for beaconing or DRP reservations.
  • FIG. 2B is a diagram of an exemplary frame format designated by the
  • WiMedia MAC Specification v. 1.2 Like the frame format of FIG. 2 A, the WiMedia frame format has successive superframes 210. As shown in FIG. 2B, the current WiMedia superframe includes 256 MASs and has duration of 65,536 microseconds. Within each WiMedia superframe 210, a first set of MAS(s) is designated as a beaconing period 212. The number of MASs in this period is flexible, so it may dynamically change. The remaining portion of the (i.e., non-beaconing period portion) of WiMedia superframe 210 is designated as a data transfer period 214.
  • the present embodiment provides techniques for a device to find best available channel for its needs. Such a channel may be found when the device has already joined a beacon group (and has thus selected a channel). Also, this may occur when the device has connection(s) or other active data transmission(s) with one or more other devices. Embodiments involve procedures for finding the best available channel as fast as possible.
  • the device has already joined a beacon group, finding the best available channel involves scanning the other channels and possibly scanning for other devices. However, given the current WiMedia PHY and WiMedia MAC, such scanning is difficult after joining a beacon group on a specific channel. Also, if a device has connections with one or more other devices, it is desirable for the device to find a new channel that meets its needs without losing its existing connections. In addition, it is desirable for the device to ensure that the other device(s) will follow it into the new channel (or at least know which devices are willing to follow it into the new channel)
  • FIG. 3 A is a flowchart of an exemplary channel changing process executed by an initiating device, according to at least one embodiment.
  • the process of FIG. 3 A includes a step 300 in which a device establishes a connection to a beacon group.
  • the device finds one or more channel candidates.
  • Step 302 may employ different techniques based on various factors.
  • the device may continually search for channel candidates before or during a connection or alternatively, may search for channel candidates only on demand.
  • the device receives channel change priorities from its local host, assigning priorities for various existing connections.
  • the device may receive the channel change priorities at any time prior to when a determination needs to be made based on the priorities.
  • the device decides to change the channel in step 306.
  • the decision to change the channel may be based on a command from the local host, available bandwidth on the current channel, the number of connections on other channels already active, distortions on the current channel or expected distortions due to internal interferences.
  • the device shares information with other devices in its network
  • Step 308 may comprise exchanging information through various information elements (IEs) in beacon transmissions.
  • step 308 may include the exchange of control/command frames (which are non-beacon, payload transmissions containing control/command information).
  • the device may in step 310, execute the channel change if it is determined, based on the priorities of the existing connections, whether the channel change is prioritized without involving the host in the determination.
  • This channel change may employ different techniques based on various factors. For instance, certain techniques maybe employed when the device has no active connections (e.g., DRP reservations), but may have active PCA data transmissions in the current channel, while other techniques may be employed when the device has one or more active connections (e.g. DRP reservations) in the current channel.
  • the other device(s) having connections with the device may follow the channel change.
  • the device may, according to at least one embodiment, continue to search for channel candidates as described in step 302.
  • FIG. 3B is a more detailed flowchart of an exemplary channel changing process, according to at least one embodiment.
  • the flow diagram of Fig. 3B represents a computer program and the steps of the flow diagram represent programmed instructions of the computer program that, when executed by a computer program processor, carry out the functions of the at least one embodiment.
  • Step 320 Initially, a wireless communications device selects a channel finding technique in a first stage, based on whether the device has any active connections in a current channel.
  • Step 325 The initiating device receives channel change priorities from its host, assigning priorities for various existing connections.
  • the device may receive the channel change priorities at any time prior to when a determination needs to be made based on the priorities.
  • Step 330 The initiating device then performs the selected channel finding technique with a plurality of channels to find a candidate channel.
  • Step 335 The initiating device determines, based on the priorities of the existing connections, whether a channel change is prioritized without involving the host in the determination.
  • Step 340 If it is determined that the channel change is prioritized, then the initiating device sends a request to at least one remote device to change its channel from the current channel to the candidate channel during an allocated time slot of a beacon period within a repeating time interval.
  • Step 350 If the request is successful, the initiating device receives an acceptance of the request from the remote device.
  • Step 360 Then in a second stage, the initiating device selects a channel changing technique based on whether the device has any active connections in the current channel.
  • Step 370 If it is determined that the channel change is prioritized, the initiating device then executes the selected channel changing technique to change a channel from the current channel to the candidate channel.
  • Step 380 The initiating device then establishes the desired new connection across the candidate channel with the remote device.
  • FIG. 3 C is a flowchart of an exemplary channel changing process according to at least one embodiment executed by a remote device in response of receiving a channel change request from an initiating device.
  • the process of FIG. 3 C includes a step 312 in which a device establishes a connection to a beacon group.
  • step 314 the device receives channel change priorities from its host, assigning priorities for various existing connections.
  • the device may receive the channel change priorities at any time prior to when a determination needs to be made based on the priorities.
  • step 316 the device receives, from an initiating device, a request to change its channel from the current channel to a specified channel during an allocated time slot of a beacon period within a repeating time interval.
  • step 318 the device, based on the channel change priorities received in step
  • the device will either execute the channel change, ask the host what to do or will not follow the channel change. If the device decides to execute the channel change, then in step 322, the device will transmit an acceptance of the request to the initiating device and share the channel change information with the other devices in its network (e.g., beacon group). In accordance with at least one embodiment, the device may transmit the channel change information through various information elements (IEs) in beacon transmissions or alternatively, may transmit control/command frames (which are non-beacon, payload transmissions containing control/command information). Next, in step 324, the device executes the channel change.
  • the channel change may employ different techniques based on various factors.
  • certain techniques maybe employed when the device has no active connections (e.g., DRP reservations), but may have active PCA data transmissions in the current channel, while other techniques may be employed when the device has one or more active connections (e.g. DRP reservations) in the current channel.
  • the other device(s) having connections with the device follow the channel change. Commands, Responses and Notifications
  • Channel Change Description: Tell the UWB radio modem chip to change the connection defined by handle to new channel.
  • Channel Change Allow Description: Tell the UWB radio modem chip if a remote channel change for handle is allowed and with what priority. priorityThe priority of the connection.
  • CCA-QUERY I means ask for channel change with Channel Change Request Notification.
  • Priority>l If any other connection exists with a higher priority (that has been set using ChannelChangeAllow) then a channel change will not be done. The default value for a new created connection is 1. Thus the Channel Change Request Notification is created for a connection per default when the notification is not masked.
  • Channel Change Request Notification Description: Asks whether it is allowed to change all existing connections to the specified channel.
  • the chip will not perform the proposed channel change unless it has been accepted by the UWB radio modem chip host using Channel Change Confirm.
  • Channel Change Confirm Description: Accepts or rejects a channel change that has been requested by the UWB radio modem chip using Channel Change Request Notification.
  • Certified Wireless USB CWUSB: Before accepting or rejecting the channel change, the chip host should ask the actual supported channel map from all connected CWUSB devices (using DE VICE_CAP AB ILITIY descriptor). In case a remote device does not support the channel proposed by the UWB radio modem chip, chip host should reject the channel change. If it decides to accepts, it should explicitly disconnect from the respective CWUSB device prior to issuing the ChannelChannelConfirm command.
  • Channel Map Set Description: This command sets the allowed channels. For WLP and for a CWUSB Host this means: If a connection exists using a channel that is not marked as allowed, the UWB radio modem chip shall move the connection to another
  • the UWB radio modem chip is CWUSB Device to A and then a remote CWUSB Device B connects. If the channel map required by B does not match the one sent to A (via DEVICE CAP ABILITY descriptor), then the chip host needs to initiate disconnection from B.
  • a device may employ various techniques to find a channel candidate.
  • Selection of these techniques is based on whether the device has any connections or active data transmissions. More particularly, certain techniques may be selected when a device has joined a beacon group, but has no active connections (e.g., DRP reservations), but may have active PCA data transmissions. Similarly, certain techniques may be employed when a device has an active connection (e.g., a DRP reservation).
  • the embodiments provide two alternative techniques.
  • the first alternative technique involves hibernation.
  • the device announces (e.g., in a beacon transmission) that it will hibernate.
  • the device scans the available channels. This scanning is directed at finding either the best available radio channels or at finding a specific target device.
  • a second alternative shown in Fig. 9 A describing at least one embodiment involves the addition of a new information element (IE) 900 to the current WiMedia MAC.
  • This new Unavailability IE 900 includes three fields.
  • a first field 902 is the element's ID, for example the value 23.
  • a second field 904 gives the length of the following fields, in this case a length of one octet.
  • the third field 906 gives the unavailability duration in units of superframes. In one embodiment, the number of superframes of unavailability is predetermined.
  • the number of superframes of unavailability is expressly stated in the field 906.
  • the Unavailability IE 900 contains information, which indicates that the device will be unavailable for a predetermined number of superframes (N superframes).
  • N superframes a predetermined number of superframes.
  • the other devices in the beacon group still update the device's status in their own beacons.
  • the device scans the available channels for either the best available radio channels or a specific target device.
  • Fig. 9B is a flow diagram of the channel finding technique using the
  • Unavailability information element (IE) 900 according to at least one embodiment.
  • the initial channel finding Steps 320, 325, and 330 of Fig. 9B are the same as those same numbered steps described for Fig. 3B.
  • Step 330 The device then performs the selected channel finding technique with a plurality of channels to find a candidate channel.
  • Step 331 the initiating device, based on the selected channel finding technique, broadcasts a beacon with the Unavailability information element (IE) 900 indicating that the initiating device will be unavailable (or that the initiating device will hibernate) for a predetermined number of superframes. Then in Step 332, the initiating device scans for available channels during the predetermined number of superframes, either to find a best available radio channel or to find a specific target device.
  • IE Unavailability information element
  • Step 340 If a suitable channel is found, then the initiating device sends a request to at least one remote device to change its channel from the current channel to the candidate channel during a time slot within a repeating time interval.
  • Step 350 If the request is successful, the initiating device receives an acceptance of the request from the remote device.
  • timing delays occur in finding a new channel candidate.
  • such delays are at least two superframes in duration. More particularly, it may require at least one superframe for the device to synchronize to the new channel and receive needed information from the new channel. In addition, one superframe may be required for the device to synchronize to the old channel again.
  • the device sends a beacon in its old channel and changes to new channel. Then the device scans the new channel and returns to the original (old) channel for one or two superframes in order to continue its DRP reservations (as well as to send or receive possible data). Thus, the device scans one channel at a time. This technique does not require changes to the current WiMedia MAC Specification.
  • a second technique requires changes to the current WiMedia MAC specification.
  • This technique adds a new field (e.g., a 1-bit field) to the DRP IE.
  • This new field informs peer devices (devices in the beacon group) of the original channel that the device is performing ongoing channel selection operations by including the corresponding field in the DRP IE in its beacon.
  • N [2, 58]).
  • a third technique also requires changes to the current WiMedia MAC specification.
  • a new field e.g., a 3-bit field
  • This new field informs peer devices (devices in the beacon group) of the original channel that the device is performing ongoing channel selection operations for a certain number of superframes indicated by this new field. For example, when a three bit field is employed such channel selection operations may occur for 1 to 7 superframes. In embodiments, a zero value indicates no ongoing channel selection operations.
  • the peer device(s) keeps up the device's reservation and status in the original channel by including the corresponding DRP IE in its beacon.
  • this technique requires changes to the current WiMedia MAC specification.
  • the current DRP IE has room to accommodate this new field (e.g. the 3 -bit Reserved field in DRP Control Field).
  • the Reservation Status bit of the DRP IE is changed to zero with a new Reason Code called "Channel Selection Ongoing".
  • N [2, 58]
  • a fifth technique modifies the current WiMedia MAC specification by adding a new IE for beacon transmissions shown in Fig. 9A.
  • This new IE contains information that the device will be unavailable for a certain number (N) of superframes.
  • the peer devices for the DRP reservations maintain (keep up) the device's reservation and the peer devices still update the device status in their own beacons during this period of unavailability.
  • WiMedia MAC Unlike the aforementioned techniques for finding candidate channels, information sharing is independent of any active data transmission.
  • the current WiMedia MAC specification allows a device to inform other devices that it is changing its channel by using the Channel Change IE. However, other devices are not required to follow the device to the new channel.
  • a first technique expands the existing Channel Change IE by adding a new list element.
  • the modified Channel Change Information Element 1000 of Fig. 1 OA includes the following fields.
  • a first field 1002 is the element ID, for example "18".
  • the second field 1004 is the length of the remaining fields, in this case it is two octets for fields 1006 and 1008 plus two additional octets for each of N device addresses listed in fields 1012 through 1014 to 1016 of the list element 1010.
  • Field 1006 is the channel change countdown and field 1008 is the new channel number being requested by the IE 1000.
  • This new list element 1010 contains device identifiers (DEV IDs) of the peer devices that are requested to change channel with the device originating the modified Channel Change IE 1000.
  • This list 1010 may specify a group of devices that, for example, belong to the same context (e.g. a person's data storage and data display).
  • the Channel Change information element (IE) 1000 shown in Fig. 1OA may include a new channel indicator and a countdown timer.
  • Fig. 1 OB is a flow diagram of the channel changing technique using the
  • Step 361 the initiating device, based on the selected channel changing technique, transmits a beacon including the Modified Channel Change IE 1000 that includes the list 1010 of identifiers of peer devices in the initiating device's beacon group, the information element 1000 including a request to change channel with the initiating device to a new channel number in field 1008.
  • each device in the list Upon receiving such an IE, each device in the list responds with its own
  • a second technique for sharing channel change information involves modifying the current WiMedia MAC to include a new Channel Change Request IE 1100 as shown in Fig. 11 and a Channel Change Response IE 1200 as shown in Fig. 12.
  • the Channel Change Request Information Element 1100 of Fig. 11 includes the following fields.
  • a first field 1102 is the element ID, for example "24".
  • the second field 1104 is the length of the remaining fields, in this case it is two octets for fields 1106 and 1108 plus two additional octets for each of N device addresses listed in fields 1112 through 1114 to 1116 of the list element 1110.
  • Field 1106 is the channel change countdown and field 1108 is the new channel number being requested by the IE 1100.
  • the Channel Change Request IE 1100 contains a list 1110 of DEV IDs of peer devices that are requested to change channel with the device transmitting this IE 1100.
  • the Channel Change Request IE 1100 includes a new channel identifier in field 1108 and a countdown timer in field 1106.
  • each device in the list Upon receiving a Channel Change Request IE 1100, each device in the list responds with its own Channel Change Response IE 1200 shown in Fig. 12 according to at least one embodiment.
  • the Channel Change Response Information Element 1200 of Fig. 12 includes the following fields.
  • a first field 1202 is the element ID, for example "25”.
  • the second field 1204 is the length of the remaining fields, in this case it is five octets for fields 1206, 1208, 1210, and 1212.
  • this IE 1200 contains either a positive confirmation or a rejection in field 1206 of the channel change requested in the Channel Change Request IE 1100.
  • Field 1208 is the channel change countdown and field 1210 is the new channel number that the responding device is agreeing to change to, as was requested in the IE 1100.
  • the flow diagram of Fig. 1OB also applies to the channel changing technique using the Channel Change Request IE 1100 of Fig. 11 and the Channel Change Response IE 1200 of Fig. 12.
  • a third technique for sharing channel change information involves providing new control/command frames.
  • this technique requires changes to the current WiMedia MAC specification.
  • the embodiments add a new command/control frame, Channel Change Request and Response command frame 1300 shown in Fig. 13, which is identified by a Frame Type value in field 1302.
  • Command Frames are sent as MAC payload, with the payload occupying N octets in field 1308.
  • a Frame Type 1402 with a first value of "zero" can identify that a Channel Change Request (with information similar to the Channel Change Request Information Element 1100 of Figure 11) is in the payload in field 1308.
  • a Frame Type 1402 with a second value of "one” can identify that a Channel Change Response (with information similar to the information in the Channel Change Response Information Element 1200 of Fig. 12) is in the payload in field 1308.
  • the frame 1300 contains a list of DEV IDs in payload field 1308 for a Channel Change Request, which identifies devices that are requested to change their channel along with the device transmitting this control frame.
  • this control frame 1300 for a Channel Change Request provides a new channel identifier and a countdown timer in payload field 1308, similar to the information in the Channel Change Request Information Element 1100 of Figure 11.
  • Devices included in the device list of the Channel Change Request frame respond with a Channel Change Response frame having information in payload field 1308 similar to the information in the Channel Change Response Information Element 1200 of Fig. 12.
  • This Channel Change Response frame contains either a positive confirmation or a rejection of the requested channel change in payload field 1308, similar to the Channel Change Response Information Element 1200.
  • a rejection may instead be made with an additional Channel Change Reject message.
  • command/control frames can be sent in a secure manner.
  • channel change execution is based on whether the changing device has active DRP reservations. If the device has no active DRP reservations, the changing device changes to the new channel' according to channel change information using MAC procedures. Once the channel change has occurred, the device selects a new beacon slot in the new channel and resumes normal mode of operation.
  • a device when a device changes its channel, other device(s) having DRP reservations with the device follow the channel change as agreed on information sharing phase. Accordingly, if the device has active DRP reservations, the device (and its associated channel changing devices) changes to the new channel according to channel change information using MAC procedures. Once the channel change has occurred, each device selects a new beacon slot in the new channel, hi embodiments, all existing DRPs from the old channel are renegotiated in the new channel.
  • a device after changing channels, a device may be precluded from changing its channel again within a certain time (e.g., 50 superframes). This feature advantageously prevents continuous channel changes (so called "ping-pong" effect)
  • IEs information elements
  • DRP IEs DRP IEs
  • Channel Change IEs DRP IEs
  • DRP IEs are described with reference to FIGs. 4-6. These IEs are used to negotiate a reservation for certain MASs. In addition, DRP IEs are used to announce the reserved MASs.
  • FIG. 4 is a diagram of a DRP IE format according to the current WiMedia MAC standard. The DRP IE shown in FIG. 4 includes an Element ID field 402, a Length field 404, a DRP Control field 406, a Target/Owner DevAddr field 408, and one or more DRP Allocation fields 410.
  • FIG. 5 is a diagram showing the format of DRP Control Field 406 according to at least one embodiment. As shown in FIG. 5, this field includes a reserved field 502, an unsafe field 504, a conflict tie-breaker field 506, an owner field 508, a reservation status field 510, a reason code field 512, a stream index field 514, and a reservation type field 516
  • Unsafe field 504 indicates whether any of the MASs identified in DRP
  • Allocation Fields 410 are considered unsafe because they exceed one or more specified reservation limit(s). Such an indication exists when unsafe field 504 is set to "1".
  • Owner field 508 is set to "1 " if the transmitting device is the owner of the reservation. Otherwise this field is set to "0" when the transmitting device is the target.
  • Reservation status field 510 indicates the status of the DRP negotiation process. For instance, this field is set to "0" when the corresponding reservation is under negotiation or in conflict. In contrast, this field is set to "1" when the transmitting device is confirming a reservation or maintaining an established reservation.
  • Reason code field 512 is used by a reservation target. This field indicates whether a DRP reservation request was successful and whether a reservation has been modified. The encoding scheme of this field is provided below in Table 1.
  • Stream index field 514 identifies the stream of data to be sent in the reservation.
  • Conflict tie breaker field 506 contains a randomly generated bit value.
  • Reservation type field 516 indicates the type of reservation. The encoding scheme for this field is provided below in Table 2.
  • FIG. 6 provides the format of a DRP Allocation field 410 according to at least one embodiment.
  • a DRP Allocation field 410 includes a Zone Bitmap 602 and a MAS Bitmap 604.
  • Zone Bitmap field 602 identifies particular zones containing reserved MASs. If a bit in the field is set to one, the corresponding zone contains reserved MASs. However, if a bit is set to zero, there are no reserved MASs in the corresponding zone.
  • MAS Bitmap 604 indicates which MASs in the zones identified by Zone Bitmap field 602 are part of the reservation. If a bit in field 604 is set to one, the corresponding MAS within each zone identified by the Zone Bitmap is included.
  • FIG. 7 is a diagram of an exemplary wireless communications device 700, according to at least one embodiment.
  • This device may operate according to the techniques of the present embodiment.
  • This device may be used in various communications environments, such as the environment of FIG. 1.
  • device 700 includes a physical layer (PHY) controller 702, a media access controller (MAC) 703, transceiver 704, upper protocol layer(s) 705, and an antenna 710.
  • PHY physical layer
  • MAC media access controller
  • transceiver 704 upper protocol layer(s) 705
  • antenna 710 an antenna
  • MAC controller 703 generates frames (data transmissions) and beacons for wireless transmission. In addition, MAC controller 703 receives and processes frames and beacon transmissions that are originated from remote devices. MAC controller 703 exchanges these frames and beacon transmissions with PHY controller 702. Li turn, PHY controller 702 exchanges frames and beacon transmissions with transceiver 704. Moreover, in embodiments employing WiMedia, MAC controller 703 performs operations involving the exchange of IEs. For instance, MAC controller 703 is responsible for the processing and generation of IEs, Control/Command frames, and DRP negotiations.
  • transceiver 704 includes a receiver portion 750 and a transmitter portion 760.
  • transceiver 704 may transmit and receive OFDM signals.
  • transmitter portion 760 may include components, such as an inverse fast Fourier transform (IFFT) module, a zero padding module, an upconverter, and a transmit amplifier.
  • receiver portion 750 may include components, such as a downconverter, a receive amplifier, and a fast Fourier transform (FFT) module.
  • IFFT inverse fast Fourier transform
  • FFT fast Fourier transform
  • device 700 further includes one or more upper protocol layers 705. These layers may involve, for example, user applications. Accordingly, upper layers 705 may exchange information with remote devices. This involves layer(s) 705 exchanging protocol data units with MAC controller 703. In turn, MAC controller 703 operates with PHY controller 702 and transceiver 704 to transmit and receive corresponding wireless signals.
  • the device of FIG. 7 may be implemented in hardware, software, firmware, or any combination thereof.
  • the components of portions 750 and 760 may include electronics, such as amplifiers, mixers, and filters.
  • implementations of device 700 may include digital signal processor(s) (DSPs) to implement various modules, such as components of receiver portion 750 and transmitter portion 760.
  • DSPs digital signal processor(s)
  • processor(s) such as microprocessors, executing instructions (i.e., software) that are stored in memory (not shown) may be used to control the operation of various components in device 700.
  • components, such as PHY controller 702 and MAC controller 703 may be primarily implemented through software operating on one or more processors.
  • FIG. 8 illustrates the terminal device implemented according to one embodiment. As shown in FIG. 8, this implementation includes a processor 810, a memory 812, and a user interface 814. In addition, the implementation of FIG. 8 includes transceiver 704 and antenna 710. These components may be implemented as described above with reference to FIG. 7. However, the implementation of FIG. 8 maybe modified to include different transceivers that support other wireless technologies.
  • Processor 810 controls device operation. As shown in FIG. 8, processor 810 is coupled to transceiver 704. Processor 810 may be implemented with one or more microprocessors that are each capable of executing software instructions stored in memory 812, for example, as a computer system. In accordance with at least one embodiment, processor 810 may also be implemented as an application specific integrated circuit (ASIC).
  • ASIC application specific integrated circuit
  • Memory 812 includes random access memory (RAM), read only memory
  • ROM read-only memory
  • modules stored in memory 812.
  • memory 812 may store software components that control the operation of transceiver 704.
  • memory 812 may store software components that provide for the functionality of PHY controller 702, MAC controller 703, and upper protocol layer(s) 705.
  • memory 812 may store software components that control the exchange of information through user interface 814.
  • user interface 814 is also coupled to processor 810.
  • User interface 814 facilitates the exchange of information with a user.
  • FIG. 8 shows that user interface 814 includes a user input portion 816 and a user output portion 818.
  • User input portion 816 may include one or more devices that allow a user to input information. Examples of such devices include keypads, touch screens, and microphones.
  • User output portion 818 allows a user to receive information from the device.
  • user output portion 818 may include various devices, such as a display, and one or more audio speakers (e.g., stereo speakers) and a audio processor and/or amplifier to drive the speakers.
  • exemplary displays include color liquid crystal displays (LCDs), and color video displays.
  • FIG. 8 may be coupled according to various techniques.
  • One such technique involves coupling transceiver 704, processor 810, memory 812, and user interface 814 through one or more bus interfaces.
  • each of these components is coupled to a power source, such as a removable and/or rechargeable battery pack (not shown).
  • FIG. 19 is a diagram of a transceiver 704 in accordance with at least one embodiment.
  • Transceiver 704 may include a radio front-end 1804, a controller 1802, an interface-to-local-host 1800 and an antenna 710.
  • Radio front-end 1804, which is coupled to the antenna 710, maybe configured to exchange information across a current channel through wireless connections with one or more remote devices using the antenna 710.
  • Radio front- end 1804 and antenna 710 may receive information indicative of a channel change by one or more of the remote devices.
  • radio front-end 1804 is also coupled to the controller
  • Controller 1802 which is coupled to the interface-to-local-host 1800, determines based on the priorities of the existing wireless connections, whether a channel change is prioritized without involving the hosting entity (i.e., processor 810) in the determination. Controller 1802 may initiate the execution of the channel change if it determines that the channel change is prioritized. Upon the determination that the channel change is prioritized, radio front-end 1804 and antenna 710 may transmit information indicative of the execution of the channel change.
  • the interface to local host 1800 is also coupled, via one or more data buses (not shown) to the processor 810 (local hosting entity). Interface to local host 1800 facilitates the exchange of information between the processor 810 (local hosting entity) and the controller 1802. Controller 1802 receives, through the interface to local host 1800, channel change priorities assigning priorities for the existing connections from the processor 810.
  • API Application Program Interface
  • PALs Adaptation Layers
  • BT Bluetooth
  • CWUSB Certified Wireless USB
  • WLP Wireless Link Control Protocol
  • ECMA European Computer Manufacturers Association
  • USB USB
  • WLP Wireless Link Control Protocol
  • the API may, for example, include functionalities such as hiding MAC/PHY related details from chipset's host for reducing the amount of UWB chipset specific details to be programmed on the host side which leaves the host more generic.
  • the ultimate goal is to have an API on chipset level. This reduces the SW changes needed on chipset's Host side (when changing chipsets) to a minimum. Nevertheless it is also possible that the API is made available as a library (running on chipset's Host side) in case the API on chipset level is different from the API. In that case the chipset vendor can use the already existing chipsets with their own APIs on chip level.
  • FIG. 16 is an example message sequence diagram for Channel Change.
  • the sequence diagrams use UML 2.0 notation.
  • the API objects in the diagram may be the library API or the chipset API.
  • the sequence diagrams show the flow of commands, responses, notifications and data above the hardware/driver layer. There are three sequence scenarios in FIG. 16.
  • the topmost depicted message sequence 1602 takes place when the remote side has initiated a channel change, but the local side did not follow, and thus the proposed connection defined by handle has been lost.
  • a message ChannelChangeAllow(handle, CCA_NOT_ALLOWED) from the local side adaptation layer to the local side API tells the local side chip that a remote channel change for a handle is not allowed. The local chip thus does not accept the channel change and the proposed connection is considered to be lost.
  • the local side API sends a notification to the local side adaptation layer of disconnection for the proposed connection;
  • the middle depicted message sequence 1604 takes place when the remote side has initiated a channel change.
  • a message ChannelChangeAllow(handle, CCA_QUERY) from the local side adaptation layer to the local side API indicates that the chip is asking its host whether or not to follow the channel change ⁇
  • the local side adaptation layer confirms the channel change to the local side API with the message ChannelChangeConfirm(handle, ETrue).
  • the local side chip transmits channel change notices to other wireless devices it is connected to, that the local device will change channels. If the other connections do not follow the channel change of the local device, they get disconnected and the local side API sends a notification to the local side adaptation layer of the other disconnections. If the alternate channel change was not accepted by the initiating remote device, the proposed alternate connection is considered lost and the local side API sends a notification to the local side adaptation layer.
  • the bottommost depicted message sequence 1606 takes place when the remote side has initiated a channel change, and both the local device and the remote device have pre- stored channel change priorities, assigning priorities for various connections. Where the priority of the proposed remote channel change is lower than other active link priorities of the local device, then a message ChannelChangeAllow(handle, priority) from the local side adaptation layer to the local side API tells the local side chip that the remote channel change for the handle is not allowed because of its lower priority.
  • Message sequence 1606 depicts a channel change decision without query from the host according to at least one embodiment.
  • FIG. 17 is an example message sequence diagram for getting the remote device to change to the current active channel.
  • the sequence diagram uses UML 2.0 notation.
  • the API objects in the diagram may be the library API or the chipset API.
  • the sequence diagram shows the flow of commands, responses, notifications and data above the hardware/driver layer.
  • the message sequence begins at the top of FIG. 17 when there are active conditions at the remote device and it has received a channel change request from the local device.
  • B_HANDLE_MEDIA_WLP,0,length) from the remote side adaptation layer to the remote side API sets the remote side chip into snooze mode, i.e. the chip falls asleep for the specified interval, wakes up for checking if there is something to transfer (Rx or Tx) for the length of time specified by "length", then falls asleep again.
  • WLP WiMedia Logical Link Control Protocol
  • a message ChannelChange(handle, channel) from the remote side adaptation layer to the remote side API tells the remote chipset to change the connection to a new channel. Then the remote side API sends a notification
  • NtfSnooze (B_HANDLE_CWUSB_ALL
  • FIG. 18 A-E show exemplary channel change decision scenarios in accordance with at least one embodiment.
  • device 1 asks for a channel change
  • no channel change would be done by the local device because connection priority 2 is lower than any other existing connection priority.
  • device 2 asks for a channel change
  • the channel change will not be executed by the local device because the priority for device 3 is higher than the priority for device 2.
  • device 3 asks for a channel change
  • the channel change will be executed by the local device because the connection to device 3 has the highest priority.
  • connections to device 1 and device 2 may be lost after the channel change.
  • the local device asks for a channel change, the channel change is executed but connections to the devices may be lost.
  • a transceiver module (not shown) of the local device can, based on the priorities, perform the channel change determination without involving the local hosting entity (not shown) in the determination.
  • the priorities are typically provided to the transceiver module by the local hosting entity and the priority information can be provided by the hosting entity at any time prior to when a determination needs to be made based on the priorities.
  • FIG. 18B if device 1 asks for a channel change and the local host allows the channel change, the channel change is executed. However, device 2 may or may not follow. If the local host does not allow the channel change, the channel change is not executed. If device 2 asks for a channel change, the channel change may be executed without involving the local hosting entity in the determination because the connection to device 1 has a lower priority. If the local device decides to make a channel change, the channel change is executed but connections to the devices may be lost. [0122] In FIG. 18C, if device 1 asks for a channel change, it will not be executed by the local device because the transceiver module of the local device has received instructions from the local hosting entity to not allow channel changes. Similarly, if device 2 asks for a channel change, the channel change will not be executed . If the local device decides to make a channel change, the channel change is executed but connections to the devices may be lost.
  • device 1 decides to make a channel change, it will not be executed by the local device because the transceiver module of the local device has received instructions from the local hosting entity to not allow channel changes. Similarly, if device 2 asks for a channel change, it will not be executed. If the local device decides to make a channel change, the channel change is executed but connections to the devices may be lost.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé, un appareil et un produit de programme informatique pour des réseaux de communications sans fil, tels que des réseaux WiMedia, pour résoudre des problèmes de retard non nécessaire lorsqu'une requête de changement de canal est transférée au côté hôte du dispositif à partir de la puce physique à bande ultra-large (UWB PHY). Un dispositif de communications sans fil sélectionne une technique de recherche de canal dans une première étape, basée sur le fait que le dispositif possède d'éventuelles connexions actives dans un canal actuel. Le dispositif reçoit de son hôte des priorités de changement de canal, attribuant des priorités pour diverses connexions existantes. Selon au moins un mode de réalisation, le dispositif peut recevoir les priorités de changement de canal à n'importe quel moment avant l'instant auquel une détermination doit être effectuée sur la base des priorités. Le dispositif applique ensuite la technique de recherche de canal sélectionnée sur une pluralité de canaux pour trouver un canal potentiel. Le dispositif initiateur détermine, sur la base des priorités des connexions existantes, si un changement de canal est prioritaire ou non sans impliquer l'hôte dans la détermination. S'il est déterminé que le changement de canal est prioritaire, alors le dispositif initiateur envoie une requête à un ou plusieurs dispositifs distants pour changer son canal du canal courant au canal potentiel durant un intervalle de temps alloué d'une période de balise à l'intérieur d'un intervalle de temps de répétition. Si la requête est fructueuse, le dispositif initiateur reçoit du dispositif distant une acceptation de la requête. Puis dans une seconde étape, le dispositif initiateur sélectionne une technique de changement de canal sur la base du fait que le dispositif possède d'éventuelles connexions actives dans le canal actuel. S'il est déterminé que le changement de canal est prioritaire, alors le dispositif initiateur applique la technique de changement de canal sélectionnée pour changer un canal du canal actuel au canal potentiel, établissant ainsi la nouvelle connexion désirée par le canal potentiel avec le dispositif distant.
PCT/IB2007/003332 2007-11-02 2007-11-02 Décision de changement de canal basée sur une priorité de connexion WO2009056899A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/IB2007/003332 WO2009056899A1 (fr) 2007-11-02 2007-11-02 Décision de changement de canal basée sur une priorité de connexion

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IB2007/003332 WO2009056899A1 (fr) 2007-11-02 2007-11-02 Décision de changement de canal basée sur une priorité de connexion

Publications (1)

Publication Number Publication Date
WO2009056899A1 true WO2009056899A1 (fr) 2009-05-07

Family

ID=39731656

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2007/003332 WO2009056899A1 (fr) 2007-11-02 2007-11-02 Décision de changement de canal basée sur une priorité de connexion

Country Status (1)

Country Link
WO (1) WO2009056899A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012173643A1 (fr) 2011-06-17 2012-12-20 Algaeventure System, Inc. Procédé amélioré de collecte de matière à l'aide d'une unité de collecte de matière
CN112106426A (zh) * 2018-05-16 2020-12-18 宝马股份公司 主从系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1394994A2 (fr) * 2002-08-30 2004-03-03 Seiko Instruments Inc. Système de transmission de données et dispositif de communication portable
US20070213012A1 (en) * 2006-03-10 2007-09-13 Janne Marin Channel change procedures in a wireless communications network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1394994A2 (fr) * 2002-08-30 2004-03-03 Seiko Instruments Inc. Système de transmission de données et dispositif de communication portable
US20070213012A1 (en) * 2006-03-10 2007-09-13 Janne Marin Channel change procedures in a wireless communications network

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012173643A1 (fr) 2011-06-17 2012-12-20 Algaeventure System, Inc. Procédé amélioré de collecte de matière à l'aide d'une unité de collecte de matière
CN112106426A (zh) * 2018-05-16 2020-12-18 宝马股份公司 主从系统

Similar Documents

Publication Publication Date Title
US7610018B2 (en) Channel change procedures in a wireless communications network
US7756101B2 (en) Efficient resolution of relinquishment requests in a wireless communications network
RU2342788C1 (ru) Технологии для снижения взаимных помех в сетях беспроводной связи
RU2330383C1 (ru) Адаптивный маяковый период в распределенной сети
EP2484173B1 (fr) Négociation de propriétaire de groupe pair à pair dans un réseau étendu
JP4945559B2 (ja) 無線通信ネットワークのためのリカバリー技術
CA2565163C (fr) Periode de balises adaptative dans un reseau reparti
CA2586171C (fr) Techniques de gestion de flux dans des reseaux de transmission sans fil
US20060198335A1 (en) Embedding secondary transmissions in an existing wireless communications network
US20070149123A1 (en) Multiple radio usage in a wireless communications device
WO2006111826A1 (fr) Reduction de temps d'acquisition d'intervalle de balise dans un reseau de commande d'acces au support distribue
WO2009056899A1 (fr) Décision de changement de canal basée sur une priorité de connexion

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07825579

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07825579

Country of ref document: EP

Kind code of ref document: A1