JP2003505929A - Method of synchronizing network slots for computer network communication channels - Google Patents

Abstract

(57) [Abstract] Synchronization within a common communication channel specifying transmission time slots for various devices of a computer network is a clear channel evaluation, where previous time slots are determined by their associated devices. Enable transmission on channels outside the specified time slot of the network device if indicated to be unused and / or upon receiving an indication that transmission of the other device has ended in the network. Maintained by doing so. The clear channel assessment preferably takes into account that of the devices in the communication channel with respect to the designated transmission time slot of the other network device, the predetermined clear channel wait time and the other network device. Is the time frame, which is the product of the numerical representations of the devices in the communication channel with the specified transmission time slot. The network master device can specify the clear channel latency itself as part of the network connection process. The network device can be configured to build one or more packets to accommodate these early transmissions for transmission within the network prior to a designated time slot.

Description

Detailed Description of the Invention

(Related Application) The present specification describes Rajugopal R. et al. Gubbi, Natarajan E
filed on Sep. 11, 1998 by Kambaram and Nirmalendu Bikash Patra, assigned to the assignee of the present specification, “
Method and Apparatus for Accessing a
Computer Network Communication Chan
This is a continuation-in-part application of co-pending application No. 09/151579 entitled "nel".

FIELD OF THE INVENTION [0002] The present invention relates generally to communication schemes within computer networks, and more particularly, as it occurs across a wireless communication link between a central server and several client units. Regarding the synchronization of various communications.

Background Today's computer networks allow intercommunication between several nodes, such as personal computers, workstations, and peripheral units. Network links transport information between these nodes, which may be quite far apart. However, most computer networks to date have relied on wired links to transport this information.
When wireless links are used, these links are typically components of large networks, such as wide area networks, and satellite communication links are used to interconnect network nodes at significant distances. Can be used. In such cases, the transmission protocols used across the wireless links have generally been established by service entities that carry the data to be transmitted, such as telephone companies and other service providers.

In the home, computers have traditionally been used as stand-alone devices. However, recently, some measures have been taken to integrate the home computer into other appliances. For example, in a so-called "smart home", a computer can be used to turn various appliances on and off and control their operational settings. These systems use wired communication links to
The computer and the electrical appliances controlled by the computer are interconnected. Such wired links are expensive to install, especially if they are later added to an already built house.

In an effort to reduce the difficulties and costs associated with wired communication links, some systems for interconnecting computers and appliances have analogs to transfer information between these units. Some use a wireless link of the method. Such analog radio links operate at frequencies commonly used by radio telephones. Although easier to deploy than traditional wired communication links, analog wireless communication links have some drawbacks. For example, signal degradation due to multipath interference is expected on such links. In addition, interference from existing appliances such as televisions, mobile phones, wireless phones, etc. can occur. Therefore, analog wireless communication links may not provide optimal performance in the home environment.

[0006] The aforementioned copending application Ser. No. 09/151579 incorporated herein by reference.
The issue describes a computer network using digital communication links adapted for use in the home environment. The architecture includes a number of networked computers arranged in a hierarchical fashion and communicatively coupled to each other via communication links operable at different hierarchical levels. The top level of the hierarchy uses a communication protocol that supports the dynamic addition of new network components at any level of the hierarchy, depending on the bandwidth requirements within the communication channels that can operate at the top level of the network hierarchy. .

A schematic diagram of this network structure is shown in FIG. The subnet 10 includes a server 12. In this scheme, the term "subnet" is used to describe a cluster of network components that includes a server and some clients associated with it (eg, coupled via a wireless communication link). However, depending on the context of consideration, a subnet may represent a network that includes a client and one or more sub-clients associated with it. A "client" is a network node linked to a server via a wireless communication link. Examples of clients include audio / video equipment such as televisions, stereo components, personal computers, satellite television receivers, cable television distribution nodes, and other home appliances.

The server 12 may be another computer that controls the communication link, but may also be implemented as an add-on card or other component attached to the host computer (eg, personal computer) 13. The server 12 has an associated wireless device 14 that is used to wirelessly couple the server 12 to other nodes on the subnet 10. Wireless links generally support both high and low bandwidth data and command channels. Here, a channel is defined as a combination of a transmission frequency (more correctly, a transmission frequency band) and a pseudo random (PN) code used in a spread spectrum communication system. In general, some available frequencies and PN codes may provide some available channels within subnet 10. As described in the aforementioned co-pending application, the server and client may search for a desired channel to use during intercommunication via the available channels.

Subnet 10 also includes a number of clients 16, some of which have shadow clients 18 associated with them. The shadow client 18 receives the same data input as the associated client 16 (server 1
Defined as a client that receives commands (either from two or other clients 16) but exchanges commands with the server 12 independently of the associated client 16. Each client 16 has an associated wireless device 14 used to communicate with the server 12, and some clients 16 have associated sub-clients 20. The sub client 20 is a keyboard,
A joystick, remote control device, multi-dimensional input device, cursor control device, display unit, and / or other input and / or output device associated with a particular client 16 may be included. The client 16 and its associated sub-client 20 are capable of communicating with each other via a communication link 21, which may be a wireless (eg infrared, ultrasound, spread spectrum, etc.) communication link.

Each subnet 10 is arranged and configured in a hierarchical format with various levels of hierarchy corresponding to the level at which intra-network component communication occurs. At the top level of the hierarchy is a server 12 (and / or its associated host 13), which communicates with various clients 16 via wireless channels. On the other hand, at the lowest level of the hierarchy is a client 16 that communicates with its various sub-clients 20 using wireless communication links, such as wired or infrared links.

When half-duplex wireless communication is used on the wireless link between the server 12 and the client 16, a communication protocol based on the slotted link structure with dynamic slot allocation is used. Such a structure supports point-to-point connections within subnet 10 and slot sizes can be negotiated again during the session. Therefore, the data link layer supporting wireless communication has a time management for data packet processing, packet transmission and slot synchronization, an error correction code (
ECC), channel parameter measurements, as well as channel switching. The high level transport layer provides all services for required connections, bandwidth utilization monitoring, low bandwidth data processing, data broadcasting, and optionally data encryption. Further, the transport layer is for each client 16
Bandwidth, continuously monitor any usage above or below that bandwidth, and also handle any bandwidth re-arrangements, as new clients 16 come online. Always, or when any one of the clients 16 (or associated sub-clients 20) needs more bandwidth, it can make the request.

A slotted link structure of a wireless communication protocol for transmitting multimedia data (eg, as a frame) in real time within the subnet 10 is shown in FIG. The highest level in the channel is provided with fixed (but negotiable) forward (F) slots and reverse or reverse (B) slots during each frame transmission. During forward time slot F, server 1
2 is capable of transmitting to the client 16 video and / or audio data and / or commands arranged in listening mode. During reverse time slot B, server 12 listens for transmissions from client 16. Such a transmission may include audio data, video data, or other data and / or commands from client 16 or associated sub-client 20. At the second level of the hierarchy, each transmission slot (forward or reverse) has one or more radio data frames 40 of variable length.
Composed of. Finally, at the lowest level of the hierarchy, each wireless data frame 40 consists of server / client data packets 42, which may be of variable length.

Each wireless data frame 40 consists of one server / client data packet 42 and its associated error correction code (ECC) bits. The ECC bits can be used to simplify detection of the beginning and end of data packets at the receiver. Variable length framing is preferred over constant length framing in order to shorten the frame length under harsh channel conditions and vice versa. This adds rigidity to the channel and saves bandwidth. Variable length frames can be used, but ECC
The block length is preferably fixed. Thus, whenever the data packet length is shorter than the ECC block length, the ECC block can be truncated (eg, using conventional virtual zero technique). If the data packet is longer, a similar procedure can be adopted for the final block of ECC bits.

As shown, each wireless data frame 40 includes a preamble 44 used to synchronize the transmitter and receiver pseudo-random (PN) generators. The link ID 46 is a fixed length field (eg, 16 bits long in one embodiment) and is unique to the link and thus identifies the particular subnet 10. The data from the server 12 / client 16 is of variable length as indicated by the length field 48. The Cyclic Redundancy Check (CRC) bit 50 can be used for error detection / correction in a conventional manner.

In the illustrated embodiment, the frame 52 is then divided into a forward slot F, a backward slot B, a quiet slot Q, and a number of radio turnaround slots T. The slot F is for communication between the server 12 and the client 16. Slot B is time-divided into a number of mini-slots B ₁ , B _2, etc., which are allocated by server 12 for transmission by each individual client 16 to server 12. Each mini-slot B ₁ , B _2, etc. contains audio, video, voice, lossy data (ie, may be encoded / decoded using lossy techniques, or is Partial packet loss tolerable data), lossless data (ie, data that is encoded / complexed using lossless techniques or cannot tolerate any packet loss during transmission / reception), low bandwidth data , And / or time for transmitting the command (Cmd.) Packet. Slot Q is kept quiet so that a new client can insert a request packet when trying to log in to subnet 10. The slot T appears during the change from transmit to receive, and vice versa, during the turnaround time of the individual wireless device (ie, half-duplex wireless device 14 from transmit to receive operation). The purpose is to accommodate the time when switching or vice versa). The duration of each of these slots and mini-slots can be dynamically changed by a re-negotiation between the server 12 and the client 16 to achieve the highest possible bandwidth utilization for the channel. . If full-duplex radios are used, slots in each direction (
Note that F and B) are always unidirectional and no radio turnaround slot is required.

The forward and reverse bandwidth allocation depends on the data processed by the client 16. If the client 16 is a video consumer, such as a television, then that client is allocated a large amount of forward bandwidth. Similarly, if the client 16 is a video generator, such as an integrated camera video, then a large amount of reverse bandwidth is allocated to that particular client. The server 12 maintains a dynamic table (e.g., in memory on the server 12 or host 13 side), which includes forward and reverse bandwidth requirements for all online clients 16. This information can be used in determining whether new clients can be granted new connections. For example, if a new client 16 requests more bandwidth than is available in either direction, server 12 may refuse the connection request. The bandwidth requirement (or allocation) information may also be used by a particular client 16 in determining how many wireless packets to wait before initiating a packet transmission to the server 12. In addition, whenever channel conditions change, EC must be prepared to handle the new channel conditions.
The number of C bits can be increased or decreased. Therefore, it may be necessary to dynamically change the forward and reverse bandwidth allocation depending on whether the source side information rate has changed.

Given that the communication channel is a slotted link structure, the network master device (eg, server 12) and other network devices (eg, client 16) may communicate properly with each other in order to allow them to communicate properly. Slot synchronization method is required.

SUMMARY OF THE INVENTION In one embodiment, synchronization within a common communication channel that specifies transmission time slots for various devices in a computer network is a clear channel estimate, and a previous time slot. Is maintained by allowing transmission on a channel outside the designated time slot of the network device, only if it has been shown to be unused by its associated device. The clear channel evaluation preferably takes into account that of the devices in the communication channel with respect to the designated transmission time slots of other network devices. In some cases, the clear channel estimate is a time window that is the product of a given clear channel wait time and its numerical representation of the devices in the communication channel for designated transmission time slots of other network devices. The network master device may specify the clear channel wait time itself as part of the network connection process.

The network device is configurable to build one or more packets for transmission in the network prior to the designated time slot.
For example, the device may include an early transmission timer configured to trigger the construction of such packets prior to the designated time slot. This allows early transmission without excessive delay.

In another embodiment, a transmission time timer residing in a first device configured to operate within a computer network having a common communication channel is configured such that the first device has a designated transmission associated with it. It is maintained to ensure transmission within the time slot. At that time, each device in the network is designated with a specific transmission time slot. However, the transmission of the first device via the common communication channel is permitted when the indication that the transmission of the second device in the computer network having the designated transmission time slot is completed is received. , The transmission of the second device precedes the transmission of the first device regardless of whether it will occur at the time specified by the transmission time timer. For example, when receiving a command or a token that has been passed, the first device, again, is ready to accommodate such a token path in order to transmit in the network prior to the specified transmission time. One or more packets can be constructed. However, in general, the first device transmits over the common communication channel only if the channel is not used by another network device, which means that the transmission time timer specifies the first device. This is true whether or not it indicates that the time slot has been reached.

The first device may also maintain a clear channel assessment indicator that takes into account that of the first device in the communication channel for designated transmission time slots of other network devices. Thus, the clear channel evaluation indicator indicates that the first device can use the channel for transmission regardless of whether or not the transmission time timer indicates that the specified transmission time of the first device has been reached. At this point, transmission within the common communication channel is possible. Usually, the indication of the clear channel evaluation is the time that is the product of a given clear channel wait time and its numerical representation of that of the first device in the communication channel for the designated transmission time slot of another network device. Created when the frame expires. The clear channel wait time can be specified by the network master device when it is connected by the first device. The clear channel evaluation transmission method allows the transmission of commands or tokens in order to allow transmission without undue delay.
It can be used with any scheme that provides an indication that transmission through the path is complete.

The above and other features and advantages of the invention will be apparent from a review of the detailed description and the accompanying drawings.

[0023]   The present invention is illustrated by way of example and not limitation in the accompanying drawings.

DETAILED DESCRIPTION Network slot synchronization for use herein within a communication channel of a computer network, between a network master device (eg, a server) and an associated network client. The method will be described. Although this scheme is generally applicable to a variety of network environments, it has been found to be particularly useful in wireless computer networks located within the home environment. Therefore, the scheme is discussed with reference to a particular form of home environment. However, this discussion is not intended to limit the applicability or use of the invention to other network environments, the broader spirit and scope of the invention being set forth in the appended claims.

One of the key terms used throughout the following discussion is “channel”. As described above, a channel is defined as a combination of a transmission frequency (more correctly, a transmission frequency band) and a pseudo random (PN) code used in spread spectrum communication system. In general, some available frequencies and PN codes can provide some available channels within a subnet. Network masters and clients can search through the available channels for the desired channel to communicate with. Table 1 below shows an exemplary channel plan according to this method.

[Table 1] In one embodiment, a channel plan using two frequency bands is employed, but the details of channel selection in such a scheme are discussed in more detail below.

Network slot synchronization within subnet 10 is performed when a client boots up, a new client appears online, a channel is changed, and when the client is absent or shuts down. Four situations are addressed in which the network is operational. These situations will be described with reference to various finite state diagrams of client 16 and server 12. In the figure, the operational states of the network components are described in circles. State transitions are made in response to the output of processing associated with the current state and / or the receipt and content of incoming messages. Any message (ie command) received or transmitted is shown next to the state transition line. For example, if "A / B" is shown on the state transition line, the message "A" is received,
During the transition to the next state, it means that the message "B" was sent as an answer to this. Otherwise, "A" is the output of the process in progress and "B"
May be an action performed by a finite state machine. “XX” represents an “unspecified” action, input, or output. A full description of the various commands referenced in these figures is provided in the aforementioned copending application.

As shown in FIG. 3, the client 16 is in the reception mode (state 60) at startup.
Started with, listen to the channel. When client 16 detects activity on the channel, it listens to determine if server 12 is in the process of changing channels (state 62) (discussed below). Once the channel change process is recognized, the client 16 changes the channel with the rest of the subnet 10 (state 6
4). Of course, if there is no channel change in progress, the client 16 will only detect normal channel communication. Client 16 waits for slot Q (whether or not client 16 needs a channel change).
State 66), send the connection request (CRQ) packet in that slot to the server 12. CRQ packets as well as other communication packet formats discussed herein are described in the aforementioned copending application. However, the specific structure of these packets is
It is not essential for this method of network synchronization.

In response to the CRQ packet, the server 12 (eg,
Periodically, perhaps on the network, to the sending client until a response is received.
Check the consistency of incoming requests (by sending once per frame).
When the client's request is confirmed (eg, by receiving a confirmation packet from the client and then the client enters wait state 68), server 12 sends a connection accept (CAG) packet to client 16.

This package contains, among other things, information about the forward and reverse bandwidth that the new client 16 is entitled to (eg slot of the channel). In addition, the maximum number of bytes that the new client 16 can send / predict in each data packet depends on the various packets (eg video data,
Data etc.) is set. The connection acceptance package includes the maximum number of data frames the new client 16 has to wait from the start of transmission of the server (ie before sending traffic), as well as the preceding client (ie
Information may also be included regarding the identity of the client that owns the preceding reverse transmission slot).

All clients comply with their respective connection agreements by counting the number of data frames received after the server starts transmission, and each client transmits each transmission after the end of the latest data frame received from the preceding client. Start. While counting, the client is a predecessor (eg token)
If it encounters an indication to end the transmission via the command transmitted by the client, it stops counting and immediately starts its own transmission. Therefore,
Using commands is one of the mechanisms by which network slot synchronization is guaranteed in this scheme.

After receiving the connection accept packet, client 16 configures itself to send its data during the allotted time slot (eg, B ₁ , B _2, etc.) until the slot is cycled through. Wait (state 70). At the designated time slot, the client 16 can initiate normal communication with the server 12 and send any data or commands it has. Precise slot timer (AST) programming can be included as part of this configuration process to help maintain proper time slot synchronization.

FIG. 4 illustrates a client 16 with AST 54, according to one embodiment of the invention.
FIG. The AST 54 is a conventional timer (eg, incremented or decremented periodically according to an appropriate clock signal maintained by the client device) that is programmed using information provided by the network master as part of the connection process. Register or memory location). For example, where is the network master (eg, server 12) located within the slotted link structure of the communication protocol for the newly connecting client (
That is, an instruction can be provided that indicates when the transmission should start. Then, this time can be monitored using AST 54 (which can be reset for each master transmission or each transmission of the associated client) to ensure that the newly connected client 16 can initiate a transmission. You can accurately predict the seeds.

Of course, this synchronization scheme avoids improperly triggering or unnecessarily delaying the client's transmission, the token pass operation, early packet construction, and early packet construction discussed herein. It is preferably used with other techniques such as clear channel estimation. Furthermore, if the client detects that the preceding client has not completed its own transmission, then it cannot transmit even if the AST monitoring time expires. Otherwise, the transmissions will overlap and may cause confusion in the network.

Using AST 54 and other synchronization schemes discussed below, the client 16 ensures that packets are ready for transmission in the subnet when the client's transmission slot is reached. Early trigger timer (ET
T) 55 can also be incorporated. That is, ETT 55 will assemble these packets when the client's transmission slot becomes available,
It can be used to improve the internal structure of packets for transmission, with the goal of being ready for transmission. Thus, the ETT 55 (which may be implemented as a conventional timer) uses the packet construction engine 56 (which may be part of the client 16 or part of the wireless device 14),
Trigger the process of forming a packet and its error protection bits so that at least a few packets are ready before the actual transmission starts.
For example, in one embodiment, packets may be assembled and stored for transmission one network frame ahead of the actual transmission. Such pre-assembly helps prevent idle time on the channel when the first few packets of the transmission sequence are formed. 1 network from transmission
Collecting data ahead of the frame may cause the system to delay one network frame in the first transmission slot, but this period is expected to be reduced to a few milliseconds.

The above discussion assumes that client 16 has started to find the channel in use. However, the channel may not be busy when the client 16 is started. In such a case, the client 16 is the server 1
The connection request packet can be transmitted in the hope that 2 will wait for a random time frame in response (state 74). If no response is received, the client will change channels. In the new channel while in receive mode (
In state 76), when the client 16 detects activity, it proceeds to negotiate with the server 12 to allocate bandwidth as described above. Otherwise, if no channel activity is detected, the client 16 retransmits the connection request packet and waits for a response (state 78). This process can be repeated until a server 12 is found for all available channels. If there is no response, the client notifies the user that no server is available and turns off (state 80).
However, if a response is received from the server 12 on any one of the channels, the client negotiates the connection (state 82) and then initiates normal communication as discussed above (state 84).

In FIG. 5, illustrated from the server side, the client 16 can be inserted online. For example, the client 16 can be activated if the server 12 is already running. The server 12 listens to slot Q for any connection request packet transmitted by a new client seeking a connection (
State 90). As mentioned above, after further exchanging connection request packets and synchronizing with the new client 16, the server 12 requests such authentication from the host computer 13 which stores a valid client ID, thereby authenticating the client. Is checked (state 92). If the authentication test passes, the server 12 assigns a new client session identifier (CS-ID) to the client (state 93) and reallocates the bandwidth of the channel (state 94). Bandwidth reallocation is necessary to accommodate new clients. After that, the server 12 transmits a connection acceptance packet to the new client 16 and starts normal communication. As shown, each state 92, 93, and 94
May have an associated timeout parameter (eg, maintained using an onboard timer). Whenever a client response is not received within the timeout period, server 12
Assuming 6 has gone offline, we can return to listening in Q slots (state 90).

As shown in FIG. 6, in the absence of the online client 16, the server 12 parks in the free channel and remains in receive mode until a client packet is detected (state 95). To determine if a channel is free, the signal strength of each received channel (provided by wireless device 14) is checked and the one with the lowest energy is selected. Next, any received data is analyzed for valid data packets other than connection request packets. A channel is declared busy if any other packet is received, especially a packet marked as generated by the server. On the other hand, if a packet received on a channel does not contain valid data other than a connection request packet generated by a client waiting for a connection, then the channel is declared free. If no data packet is received, the server 12 remains in receive mode in that channel (state 95), waiting for the client's connect request packet. In the meantime, if the channel is occupied by another subnet near the current server's wireless device, that server switches to the other channel and waits for the client's request. If all channels are occupied, the server 12 continues to change channels periodically until it finds a free channel. If the client 16 consistently detects packets from the two servers 12,
The client 16 recognizes that there is a jamming condition on the channel and does not establish a connection over the wireless link. Similarly, if server 12 consistently detects a packet from another server, that server does not try to establish any client connection on the channel. These two measures prevent servers from one subnet from owning clients from nearby subnets. In addition, a unique identifier can be used for each subnet 10 to avoid having one server's clients be taken by other servers in the neighboring subnets.

The client 16 can set the action of the server 12 by transmitting a connection request packet, for example. The client 16 can then return to slave mode (eg, with a timeout option). Once the client's request is received, the server 12 periodically transmits a connect request packet and waits for the client 16 to enter the line as described above (state 96).
). After confirming the slave mode of the client via transmission, the server 12 tests the authenticity of the client (state 97) and if the result is good, the client 1
Give 6 connection consent. If the host computer 13 may take longer than the response time of the client 16 during the authentication process, the server 12
Can delay client 16 by retransmitting the connection acceptance packet without actually expecting an acknowledgment from client 16. After transmitting the connection acceptance, the server 12 allocates a new CS-ID (state 98) and then waits for the client 16 to acknowledge the transmission (state 99). Then, normal communication can be started (state 100).

By first turning the client into a master and then turning it into a slave after the server 12 has started up, there is less interference on the free channel when the subnet 10 is not in operation. Of course, in other embodiments, server 12 may poll clients 16 at regular intervals across the channel. However, in such a scheme, the channel is always busy even when the subnet 10 is not operating, so there is a possibility that the channel may be rejected to any neighboring subnet.

In some embodiments, multiple clients 16 (or shadow clients 18) are supported with the same input from server 12. In such cases,
1 of the forward data packet (which is the client ID of the first client)
Only the copy needs to be transmitted. The remaining clients are each server 1.
It can be treated as a shadow client with two separate command packets.

In a multiple client scenario, if one of the clients 16 wakes up later, that client waits for a quiet (Q) slot and begins transmitting command packets into that slot. However, it is possible that more than one client can be started after the server 12 and the present scheme has the potential to occur when two or more clients 16 each attempt to transmit in a Q slot. Provide a means for resolving such conflicts. To avoid such collisions, the client 16 randomly chooses to insert each request into a Q slot (
Or not selected). The client 16 firstly recognized by the server 12 will be first added to the subnet 10 and will be similarly added thereafter.

The following Table 2 (where Tx represents that the wireless device 14 is in the transmitting state and Rx represents the state in which the wireless device 14 is in the receiving state) is a multi-client scenario and online insertion of a new client. 3 shows a detailed schematic state diagram in the case of performing.

[Table 2]

Due to the arrangement of designated time slots, if one client responds with a delay for some reason, other clients cannot occupy the designated time slot. This wastes valuable bandwidth. Therefore, in this method,
There are two solutions to this problem.

First, each client 16 needs to keep track of the current client occupying the channel, thereby trying to find the last client on the line. If the channel is quiet, the current client waits a predetermined amount of time before initiating its own transmission. In one embodiment, the length of this waiting time is the quiet time threshold allowed between two clients (referred to as clear channel evaluation or CCA time), and the client that is still transmitting before the current client. Depends on the number of. For example, the waiting time may be the product of the CCA threshold and the number of devices still transmitting. The transmission sequence established at connection setup is used for the calculation of this waiting time. If all online clients 16 have to stop transmitting, the only exception to quiet time is the Q slot.

As shown, CCA transmission (ie, client transmission based on wait period timeout) is suitable for transmission because it is essentially the result of the client's determination that the channel is free. Each client device keeps track of how many devices have completed the transmission from the time the network master completes its transmission. This tracking can be performed using counters that are incremented each time a client transmission is detected, and the implementation of such counters is well known in the art. Then an index of your position in the network frame (value received from the network master at the time the connection was established)
By knowing, each client device can determine when to initiate a CCA transmission. This is best shown in one example.

Each client device has a CCA timer 57 (
(See FIG. 4) can be programmed. The network master can specify this value when the master-client connection is established, which generally means that the network client can assume that no other client is using the channel. Represents a time interval that must expire before. Here, after the client device is the fifth transmission in the line after the master device and the second device in the line has completed the transmission (for example,
Assume that the CCA timer 57 detects a clear channel (due to timeout). Since the device is the fifth in the line, it cannot start its transmission immediately (ie there are still two client devices in front of it in the line). However, the fifth device may increment its associated CCA counter 58 at this point. After that, if both the 3rd and 4th devices were silent (ie the 5th device's CCA
If the timer 57 times out two more times in a row, the fifth device will increment its CCA counter 58 twice and immediately start its transmission at the third CCA detection. it can.

In the above example, the third device in the line will also detect that there is no transmission by the second device, so if it needs to send traffic, it immediately starts its own transmission. Note that it is possible. In other words, the waiting period of the third device is only one CCA timeout period because there is no transmission of the second device, and the waiting period of the fifth device is three CCA timeout periods. Similarly, the fourth device in the line is separated from the second device by two CCA timeout periods. Thus, by using the client slot arrangement in determining when CCA transmissions can be initiated, the client devices are able to maintain their relative order within the slotted link structure of the communication channel. You can

A second solution to prevent the client's transmission slot from being unoccupied if the client responds later for some reason is as follows. The server 12 monitors the occupancy of any channel and takes appropriate action to connect / disconnect any client that is consistently delayed. When such a delay in response occurs, the video-producing client / server will correspondingly reduce the size of the output data in the next video slot. By doing this, the correct slot time synchronization is maintained. The video generation client / server tracks the length of the idle channel and reduces its output appropriately on the current / next video slot.

To accommodate new clients, the size of slot Q must be at least the length of one radio data frame 40 carrying a connection request packet. Therefore, the new client 16 receives all the data frames and learns the data frame structure in the current session, and then sends a connection request between the last online client transmission and the server 12 transmission. It can be inserted in a certain slot Q. This request is confirmed after a consistency check over several transactions (ie between server transmissions). Note that the radio turnaround time must always be kept in mind and not be confused by Q slots. This can be verified using a timer.

In order to tell the new client that the server 12 has accepted the connection request, the server 12 needs to send a packet to the new client.
Therefore, the server 12 determines that the first client (ie, the client to which slot B ₁ is allocated) that is supposed to start the transmission after the server is F
At the end of the slot, we need to make sure it does not overlap with the latest packet sent by the server 12 for the new client. Therefore, the server can broadcast the token path at the end of the transmission. The first client in the line then receives the token path from the server 12 (and after allowing the wireless device turnaround time if necessary), or after a timeout on the idle channel. The transmission will start.

As mentioned above, all clients 16 need to resync with the server 12 if the channel is changed. Channel switching can occur if either one of the server 12 or the client 16 experiences a severe channel impairment (eg, despite antenna diversity and / or advanced ECC). In such a scenario, the server 12 seeks other channels in an attempt to find a less disruptive channel. If it is determined that the new channel will have better communication behavior, the server 12 initiates a channel change or switch operation.

FIG. 7 is a diagram showing a channel change sequence of the two-channel subnet when viewed from the server 12 side. During normal communication (state 101), if the server 12 determines that the channel condition is unacceptable or is about to become unacceptable, then before the search for a new channel begins, the server 12 will To notify the client 16 of the user to remain calm for a while. This procedure is repeated several times (state 102) (eg 5 times) to ensure that all clients 16 receive the message. In response, the client is expected to send an acknowledgment, but even if it did not receive an acknowledgment from all the online clients 16, the timer on the server 12 side has timed out and the server has switched to another channel. The wireless device 14 may be tuned to check (state 104). If the new channel is free, the server 12 switches to the original channel (eg, after a predetermined listening period, such as 4 ms in one embodiment) and sends a channel change message (possible to all online clients 16). If so, it broadcasts (up to five times, for example) and waits until it receives an individual channel change acknowledgment (Ack.) Message to client 16 (state 106). Each client 16 always sends its own channel change acknowledgment message before changing channels. Even after waiting for a predetermined time,
If server 12 has not yet received a response from one or more online clients 16, server 12 determines that the client is unreachable. Similarly, when the client 16 does not receive a message from the server even after waiting for a predetermined time, the server 16 can determine that the server 12 is unreachable and can change the channel on its own will. The server 12 switches to the new channel after all online clients 16 have responded or after a timeout condition.

Once on the new channel, the client 16 waits for the server 12 to initiate communication. The server 12 broadcasts a channel change acknowledgment message to announce its presence in the new channel (state 108) and anticipates a channel change acknowledgment from each client 16. If one or more clients 16 do not respond during a predetermined number of attempts, the server 12 determines that the client 16 is temporarily absent. Therefore, the server 12
Modify the response sequence of client 16 (eg, by transmitting a new connection agreement) so that it does not include a non-existent client. After waiting for all clients 16 to confirm their presence in the new channel (or the timeout period has expired) (state 110), the server 12 updates the paging response slot sequence for the new channel, and all The client 16
Send a new connection consent to. After that, normal communication can be resumed (state 112).
.

If a client 16 arrives late on a new channel, it must wait until it answers the server call. If the server 12 determines that the client 16 no longer exists, the client 16 waits until normal communication is resumed before sending a channel change acknowledgment message in the quiet (Q) slot. When the server 12 receives such a message, it sends a connection consent and includes the late client in the network.

Two measures are used to keep any users associated with late clients unaffected during this time. First, all clients 16 are configured to provide still and / or audio repetition of video frames to simulate a smooth session at the user level. Second, the server 12 maintains session details for a predetermined period of time long enough to easily reconnect. Only after the prescribed waiting period has expired,
The nonexistent client 16 is finally removed from the server's online client list (state 114).

If the server 12 receives a channel change acknowledgment message from the client 16 which is too late after removing it from the online list, the client 16 is advised to make a new connection by sending a connection request. . In such cases, the client 16 may notify the user that the link has been lost. This is a power failure-like symptom at the user level and will prompt the user to re-establish a link with the server 12.

When selecting a channel (eg, at the beginning of, or as part of, a channel change operation), the server 12 determines that the subnet 10 already operating over the current channel
, And the potential presence of a link with the same PN code and / or link ID needs to be detected. The probability of this happening is expected to be very low, but not zero. The link ID is assumed to be unique to the link / subnet / cell. To ensure this uniqueness, users are prompted to enter a unique password (for example, a Social Security number or other unique alphanumeric string of similar length) during subnet deployment. . This password is parsed by the server 12 (and / or its host computer 13) and used to establish a unique link ID and PN code. These values can be the same for all sessions unless the user decides to change (eg by reinstalling subnet 10).

In one embodiment, an 11-bit PN code (Barker code) can be used, but higher bit lengths can also be used to increase security, to ensure uniqueness. A table of available PN codes is available at server 14
/ Host computer 13 maintains one and selects one of the codes based on the password entered by the user. The PN code can be changed at any time if the use of the same PN code in neighboring subnets 10 increases interference.

If either channel is occupied or there is significant interference, the server 12 can take one of two actions. If there are only a few clients 16 that are severely jammed into or out of the channel, the server 12 can decide to disconnect them. In contrast, the associated client 16
If there are many, the server 12 can wait a moment for a decision and try the channel after some time. In either case, the server 12 needs to send a Retry Later command to each associated client 16 until it receives a disconnect acknowledgment message from each affected client 16.

FIG. 8 is a diagram illustrating client-side channel switch operation for an exemplary two-channel subnet. During normal communication (state 120), if the client 16 is instructed to remain quiet, the client 16 sends an acknowledgment (eg, a disconnect acknowledgment) until another instruction from the server 12 is received. Wait (state 122). When the server 12 broadcasts the channel change message, the client 16 changes channel after acknowledging. Alternatively, the client 16 can determine that the server 12 is unreachable if it does not receive any message from the server after waiting a predetermined time, and can change the channel on its own will. You can

Once on the new channel, the client 16 waits until the server 12 starts communicating (state 126). The server 12 broadcasts a channel change acknowledgment message to announce its presence in the new channel and anticipates channel change acknowledgments from each client 16. Therefore, the client 16 confirms its presence in the new channel and waits for a new connection acceptance from the server 12 (state 128). When the connection agreement is re-arranged with the server 12, the client 16 waits for normal communication to resume (state 130).

If a client 16 arrives late on a new channel, it must wait until it answers the server call. If the server 12 determines that the client 16 no longer exists, the client 16 waits until normal communication is resumed before sending a channel change acknowledgment message in the quiet (Q) slot (state 132). . When the server 12 receives such a message, it sends a connection consent and includes the late client in the network. In order to keep any users associated with late clients unaffected during this time, the client 16 uses static and static video frames in order to simulate a smooth session at the user level. And / or audio repetition can be provided.

If the server 12 receives a channel change acknowledgment message from the client 16 which is too late after removing it from the online list, the client 16 is advised to make a new connection by sending a connection request. . In such cases, the client 16 may notify the user that the link has been lost (state 134). This is a power failure-like symptom at the user level and will prompt the user to re-establish a link with the server 12. If the client 16 loses connection with the server 12 for an extended period while selecting a channel, the user can be notified of the situation and turned off (state 136).

Similar to client 16, sub-client 20 can also be inserted online into a working subnet (ie, referred to as hot insertion). As shown in FIG. 9, when the sub-client 20 starts, it sends a registration packet to the associated client via the communication link 21 (state 22).
0). The communication link 21 may be a wireless link (for example, an infrared communication link) or a wired link.

Upon receipt of the transmission from the sub-client 20, the client 16 authenticates the sub-client (state 222), for example by checking the registration identification information against a list of known / authorized sub-clients. . In some cases, communication with the server 12 may be necessary. Once the sub-client 20 is known, the client 16 builds a sub-client session identifier to uniquely identify the new sub-client from any other sub-clients operating online with the client. The client 16 then transmits an Add Client command (discussed in detail below) to the server 12 (state 224). As discussed in more detail below, the Add Subclient command includes a sub-client session identifier and sub-client characteristics.

When the server 12 receives the Add Subclient command, it records the sub-client session ID to see if the subnet can accommodate the addition of new sub-clients (eg, commands sent to and from new sub-clients). The sub-client authentication process is completed (state 226) by determining whether sufficient bandwidth is available on the wireless link to accommodate the. Upon successful completion of the authentication process, the server inserts the new subclient into the online services table and sends the associated client a Subclient Added command to place the new subclient into the subnet. to add. If the new subclient cannot be accommodated or is otherwise rejected, the server will become Subclient Not Added (no subclient added).
Send a command.

Regardless of the server's decision, the result of the authentication process is transmitted from the client to the sub-client (state 228). If the sub-client is accepted,
Start normal operation and communicate with client and server 12 (state 230)
. When the sub client is rejected, the sub client is disconnected (state 232). In either case, the user is informed of the addition or rejection of the sub-client via the appropriate status message displayed on the display device.

While the network is operating, sub-client 20 may be disconnected by either server 12 or associated client 16.
For example, if the sub-client 20 has been inactive for more than a predetermined time, the client 16 may disconnect the sub-client 20. In such a case, the client 16 must notify the server 12 of this situation and request that the disconnected sub-client be excluded from the server's online device list (below, Delete Subclient (See Delete Client) and Subscribe Deleted Commands).

In other cases, the server 12 may directly remove the sub-client 20, eg, if the application running on the host 13 does not support a particular sub-client (or more specifically, client). May be decided. Also, network maintenance and shutdown operations may require subclients (and clients) to be automatically removed.

The foregoing has described a scheme for synchronizing communications within a communications channel of a computer network. Although discussed with reference to certain exemplary embodiments, the present invention is not limited thereto. Rather, the invention is to be determined solely with reference to the appended claims.

[Brief description of drawings]

FIG. 1 is a diagram showing an outline of a network structure supported by a wireless protocol according to an embodiment of the present invention.

FIG. 2 is a diagram showing a hierarchical layout configuration related to data transmission within a subnet according to an embodiment of the present invention.

FIG. 3 is a state diagram illustrating a process for adding a client to a subnet according to an embodiment of the present invention.

FIG. 4 is a diagram illustrating a network client device configured with a collection of timers and counters used in maintaining network synchronization according to one embodiment of the invention.

FIG. 5 is a state diagram illustrating a process for inserting a client into a subnet when viewed from a server side according to an embodiment of the present invention.

FIG. 6 is a state diagram illustrating a process for a server to initiate a session for a new client, according to one embodiment of the invention.

FIG. 7 is a state diagram illustrating a process for changing a channel in a subnet as seen from a server side according to an embodiment of the present invention.

FIG. 8 is a state diagram illustrating a process for changing a sequence of channels and subnets when viewed from a client side according to an embodiment of the present invention.

FIG. 9 is a state diagram illustrating a process for online insertion of a sub-client in a subnet according to an embodiment of the present invention.

[Procedure for Amendment] Submission for translation of Article 34 Amendment of Patent Cooperation Treaty

[Submission date] July 2, 2001 (2001.7.2)

[Procedure Amendment 1]

[Document name to be amended] Statement

[Name of item to be amended] Claims

[Correction method] Change

[Contents of correction]

[Claims]

─────────────────────────────────────────────────── ─── Continued front page    (81) Designated countries EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, I T, LU, MC, NL, PT, SE), OA (BF, BJ , CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, GM, K E, LS, MW, MZ, SD, SL, SZ, TZ, UG , ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, CA, C H, CN, CR, CU, CZ, DE, DK, DM, DZ , EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, JP, KE, K G, KP, KR, KZ, LC, LK, LR, LS, LT , LU, LV, MA, MD, MG, MK, MN, MW, MX, NO, NZ, PL, PT, RO, RU, SD, S E, SG, SI, SK, SL, TJ, TM, TR, TT , TZ, UA, UG, UZ, VN, YU, ZA, ZW (72) Inventor Sebastian, Donia             United States95630 California             State / Folsom Creekside Dry             B 1200 1200 (72) Inventor Ekan Balan, Natarajan             United States95670 California             Province Rancho Cordova Vehicle             Live 2330 number 197 (72) Inventor Patra, Nirmalendu Bikas             United States95682 California             Cameron Park Santos Sir, State             Kuru 3490 F-term (reference) 5K028 BB04 CC05 DD01 DD02 EE02                       EE03 KK12 NN05                 5K033 CA11 CB15 DA17                 5K047 AA11 BB01 CC08 DD01 DD02                       HH01 HH02 HH53                 5K067 BB21 DD25 EE02 EE10 EE16                       GG01 GG11 HH05 [Continued summary] Build one or more packets to accommodate Configurable.

Claims (18)

[Claims] 1. Transmission on a channel outside a designated time slot of a network device is possible only if the clear channel evaluation indicates that the previous time slot has not been utilized by its associated device. By maintaining synchronization within a common communication channel specifying transmission time slots for various devices of a computer network. 2. The method according to claim 1, wherein in the clear channel evaluation, the designated transmission time slot of another network device is taken into account of that of the device in the communication channel. 3. A time window in which the clear channel estimate is the product of a given clear channel wait time and a numerical representation of that of the device in the communication channel for a designated transmission time slot of another network device. The method of claim 2 including. 4. The method of claim 3, wherein the clear channel latency is specified by the network master device as part of the network connection process. 5. The method of claim 1, wherein the device is configured to build one or more packets for transmission in the network prior to the designated time slot. 6. The device of claim 5, wherein the device includes an early transmission timer configured to trigger the construction of one or more packets for transmission in the network prior to the designated time slot. Method. 7. A transmission time timer in a first device configured to operate in a computer network having a common communication channel, wherein each device in the network is assigned a specific transmission time slot, Maintaining the first device to ensure transmission within its associated designated transmission time slot. 8. The transmission of the first device over the common communication channel is permitted upon receipt of the token passed by the second device within the computer network having the designated transmission time slot. The method of claim 7, wherein the transmission of the second device precedes the transmission of the first device regardless of whether the transmission time timer will occur at a specified time. 9. The method of claim 8, wherein the first device constructs one or more packets for transmission in the network prior to the designated transmission time. 10. The method of claim 7, wherein the first device constructs one or more packets for transmission in the network prior to the designated transmission time. 11. If the channel is not used by another network device, whether or not the first device indicates that the transmission time timer has reached the designated time slot of the first device. The method according to claim 7, wherein the transmission is carried out via a common communication channel only. 12. The first device further maintains a clear channel assessment indicator that takes into account that of the first device in the communication channel with respect to the designated transmission time slot of the other network device. Item 7. The method according to Item 7. 13. The clear channel evaluation indicator indicates that the channel is available for transmission regardless of whether the first device indicates that the transmission time timer has reached the specified transmission time of the first device. 13. The method of claim 12, transmitting in a common communication channel at the indicated times. 14. The clear channel evaluation indication is the product of a predetermined clear channel wait time and a numerical representation of that of the first device in the communication channel with respect to the designated transmission time slot of the other network device. 15. The method of claim 13, wherein the method is created at the expiration of the time frame. 15. The method of claim 14, wherein the predetermined clear channel wait time is specified by the network master device at the time it is connected by the first device. 16. The method of claim 15, wherein the first device constructs one or more packets for transmission in advance of a specified transmission time. 17. Transmission of the first device over the common communication channel is permitted upon receipt of an indication that the transmission of the second device within the computer network having the designated transmission time slot has ended. 16. The method of claim 15, wherein the transmission of the second device precedes the transmission of the first device regardless of whether a clear channel estimate was made. 18. The method of claim 17, wherein the first device constructs one or more packets for transmission in advance of the designated transmission time slot.