Method and apparatus for controlling communication within a computer network

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

(Field of invention) The present invention generally relates to methods for communication within a computer network, more specifically to communication between a central server and a plurality of client units via wireless links. [0002]

(background) Modern computer networks enable intercommunication between multiple nodes such as personal computers, workstations, and peripherals. Network links propagate information between these nodes, but such nodes can sometimes be far apart from each other. But so far, most computer networks have relied on wired links to propagate this information. When wireless links are used, they are usually components of very large networks, such as wide area networks, and satellite communication links can also be used to interconnect network nodes that are very far apart. is there. In such cases, the transmission protocol used between the wireless links is generally established by a service entity that propagates the data being transmitted, such as a telephone company and other service providers. [0003]

In the home environment, computers have traditionally been used as stand-alone devices. But in recent years, some steps have been taken to integrate home computers with other appliances. For example, in so-called "smart homes," computers can be used to switch on and off various appliances and control their operational settings. In such a system, a wired communication link is used to interconnect the computer with the equipment it controls. These wired links are expensive to install, especially if they are added after the house is first built. [0004]

To reduce the problems and costs associated with wired communication links, some systems for interconnecting appliances and computers utilize analog wireless links to transmit information between these units. .. These analog radio links operate at the frequencies commonly used by radio telephones. Although easier to install than traditional wired communication links, analog wireless communication links have several drawbacks. For example, in such a link, it is expected that the signal will be degraded due to multi-path interference. In addition, interference from existing appliances such as televisions, mobile phones and radiotelephones may occur. Therefore, the analog wireless communication link cannot be said to provide the optimum function for the home environment, and it is desired to have an improved method for wireless network communication in such an area. [0005]

(Outline of the invention) The present invention provides an improved method for wireless network communication. In particular, one embodiment of the present invention provides a method of controlling a communication channel so that it can dynamically accept a request from a network client seeking access to it. Communication channels can also be supported over wireless links. In such cases, the client request for access can be dynamically accepted by allocating time slots for the client's transmission over the wireless link. The communication channel is preferably supported on a spread spectrum radio link that supports code division multiple access (CDMA) communication. By providing a quiesce slot that allows a client to request access to a communication channel, it is possible to accept various client requests for access to the communication channel. These quiesced slots may be present with other forward and reverse time slots superimposed on the communication channel, with one or more forward and reverse time slots for each. Includes data frames. [0006]

The forward and reverse time slots are preferably fixed but negotiable time frames. Each data frame may contain multiple data packets, each data packet of varying length. Each data packet preferably contains information used to synchronize the transmitter's pseudo-random number generator with the receiver operating according to the communication protocol, as well as error correction coding information. Each data frame may further contain link identification information that uniquely identifies the radio link that supports the communication protocol. [0007]

In another embodiment, the invention provides a network that includes a server configured to operate according to a communication protocol. One or more clients in the network operate according to the same communication protocol and may be configured to use the communication protocol to exchange information with the server between wireless links. It can also include shadow clients, in which case each shadow client is associated with one client. A shadow client receives information from a server destined for a client associated with itself, but may adapt to exchange unique command information with a server unrelated to the client associated with itself. Good. [0008]

In one embodiment, the radio link used by the network is a half-duplex radio link. In this case, the communication protocol allows the forward time slot to accept transmissions from the server and one or more reverse time slots to accept transmissions from each client. Each forward time slot and reverse time slot may contain one or more data frames, preferably a fixed but negotiable time frame. [0009]

Each data frame can contain multiple data packets, in which case each data packet can vary in length. As pointed out above, the data packet can contain error correction coding information and / or information used to synchronize the client and server pseudo-random number generators. Each data frame preferably also contains link identification information that uniquely identifies the wireless link. [0010]

These and other features and advantages of the present invention will become apparent with reference to the detailed description below and the accompanying drawings thereof. [0011]

The present invention is illustrated in the form of the accompanying drawings as an example, not as a limitation. [0012]

(Detailed explanation) Described here are (a) the network client associated with the server, and (b) the network architecture and associated protocols used between the server and its associated host computer. This technology can generally be applied to various wireless network environments, but is particularly useful in computer networks located in home environments. Therefore, the present technology will be described with reference to specific situations in the home environment. However, this description is by no means limiting the application of the present invention to other network environments, and the broader spirit and scope of the present invention are listed in the claims that follow this description. [0013]

As used herein, "subnet" refers to a cluster of network components that includes a server and several clients associated with it (eg, joined by a wireless communication link). In the context of the description, a subnet may also refer to a network that contains a client and one or more subclients associated with it. In some cases, the term "subnet" is used to replace "cell". In the present technology, a "client" is a network node linked to a server through a wireless link. Examples of clients include audio / video equipment such as televisions, stereo components, satellite television receivers, cable television distribution nodes, and other household appliances. The server may be another computer that controls the communication link, but in other cases the server may be an add-on card or a component connected to the host computer (eg, a personal computer). Subclients include keyboards, joysticks, remote controls, multidimensional input devices, cursor controls, display devices and / or other input and / or output devices associated with a particular client. [0014]

Another term used throughout the description below is "channel". Channels are defined as a combination of transmission frequencies (more preferably, transmission frequency bands) used in spread spectrum communication and pseudo-random (PN) codes. Generally, multiple available frequencies and PN codes provide multiple channels available within a subnet. As described in more detail below, servers and clients can search within the available channels to find the desired channel for communicating with each other. Table 1 below shows an exemplary channel plan for this scheme. [0015]

[table 1]

<img file="JP2002525913A_D0001.tif" />In one embodiment, channel planning using two frequency bands is adopted, and the details of channel selection in such a technique are described in more detail below. [0016]

With these terms in mind, the technology is discussed first with reference to exemplary network topologies that use wireless communication links and related communication protocols. Second, network operation using a hierarchical structure for data transmitted within the communication channels supported on the wireless link will be described. Third, we discuss an exemplary packet structure used according to the wireless communication link protocol. Fourth, various network issues such as overhead, error coding and correction, data encryption, network initialization and management will be discussed. [0017]

A. Network topology Figure 1 shows an overview of the network architectures supported by this technology. Subnet 10 contains server 12. As pointed out earlier, the server 12 is a stand-alone unit, or more likely an attachment card for a personal computer that acts as a host 13 to the server. Server 12 has an associated radio device 14, which is used to wirelessly couple server 12 to other nodes in subnet 10. Wireless links generally support both high-bandwidth and low-bandwidth data and command channels. [0018]

Subnet 10 also contains multiple clients 16, some of which have shadow clients 18 associated with them. Shadow client 18 is defined as a client that receives the same data input as the associated client 16 (from server 12 or another client 16), but exchanges commands with server 12 independently of its associated client 16. Will be done. Each client 16 has an associated radio device 14 used to communicate with the server 12, and some clients 16 may have an associated subclient 20. The client 16 and its associated subclient 20 communicate with each other via a communication link 22, which may be a wireless (eg, infrared, ultrasonic, diffuse spectrum, etc.) communication link. [0019]

Each subnet 10 can be regarded as a hierarchically arranged network by various levels of the hierarchy according to the level at which communication of components in the network occurs. At the top of the hierarchy are servers 12 (and / or their associated hosts 13) that communicate with various clients 16 over wireless communication channels. At one lower level of the hierarchy, client 16 communicates with various subclients 20 using wireless communication links, such as wired or infrared links. This hierarchy can also be described by a three-layer structure as shown in Table 2 below. As pointed out, the device can be added to any level of network online (eg hot insertions while other networks are running). [0020]

[Table 2]

<img file="JP2002525913A_D0002.tif" /> 【0021】

In general, subnet 10 can contain a single server 12 and virtually any number of clients 16. However, the number of 16 clients supported at the same time depends on the forward and backward bandwidth requirements. In one embodiment, the wireless link that combines the server 12 and the client 16 (eg, via the wireless device 14) is a full-duplex 10 Mbps link. In another embodiment, the wireless link is a half-duplex, 4 Mbps link. Still other embodiments allow half-duplex or full-duplex linking in different bands. [0022]

The radio device 14 is preferably configured to allow intra-subnet communication within a typical home environment. In one embodiment, this means that the radio device 14 can establish and manage communications within a particular cell area. In one embodiment, the typical cell area is approximately 100'x 80'x 30', allowing communication in a typical home environment. The radio link supported by the radio device 14 preferably provides at least two separate frequency spaces and supports two overlapping cells 22. That is, the wireless device 14 can operate in one of the available frequency bands. Within the same frequency band, individual subnets (12 servers, 16 multiple clients, and optionally 18 shadow clients and 20 subclients) utilize code division multiplexing (CDMA) communication technology. It is preferable to exchange information within. For half-duplex operation, forward and reverse channels in the same frequency band (using the same CDMA pseudo-random (PN) code) have dynamically adjustable time division multiple access (TDMA). It can be used to distinguish between transmission from server 12 and transmission from client 16. Error correction (eg, using a Reed-Solomon encoder / decoder) and data encryption techniques may be used to increase eavesdropping robustness and security. [0023]

In order not to cause high interference between individual subnets, it is preferable that the arrangements of the plurality of subnets 22a, 22b, 22c, 22d in the environment do not overlap each other as shown in FIG. 2a. However, it is recognized that it is difficult to guarantee such an ideal model. For example, overlapping subnets can occur (actually expected) when there are two different subnets in two adjacent homes / apartments. Overlapping subnet range areas 24a and 24b (different transmit units T, respectively) as illustrated in Figure 2b.₁And T₂Can lead to eavesdropping, increased interference within the subnet, frequent channel changes, etc. The defenses against these issues that may arise are described below. [0024]

The protocol scheme may overlay on the well-known Open Systems Interconnection (OSI) model, as shown in Figure 3. The three layers from the top of the OSI model, application layer 30, presentation layer 31, and session layer 32, are host computer 13 (ie, a computer that supports server 12 or a server that stands on a server. If it is a unit, it is preferably implemented by the server 12 itself). The lower layers, namely transmission layer 33, network layer 34, data link layer 35, and physical layer 36, should be implemented on server 12 and client 16 (although they may overlap with the behavior of host 13). Is preferable. [0025]

As mentioned above, the physical layer 36 is preferably implemented as a wireless link using the wireless device 14. Thus, server 12 or client 16 (as appropriate) can handle the initialization of data frame parameters, the radio parameters, and the initiation of data frame transmission, but the configuration, transmission, and transmission of data frames. Other services such as reception and spreading operations are processed directly by the radio device 14. [0026]

For one embodiment, for example when half-duplex wireless communication is used, the data link layer 35 uses a slotted link structure (discussed in more detail below) with dynamic slot allocation. I have something to do. Such a structure supports two-point connections within subnet 10, and slot sizes can be renegotiated during the session. Therefore, data link layer 35 can accept data packet processing, time management for packet transmission, slot synchronization, error correction coding (ECC), channel parameter measurement, and channel switching. Transmission layer 33 provides all necessary service-related connections, bandwidth utilization monitoring, low bandwidth data processing, data broadcasting, and optionally data encryption. Transmission layer 33 allocates bandwidth to each client 16 and constantly monitors utilization below or above that bandwidth. Transmission layer 33 re-uses any bandwidth that is required whenever a new client 16 comes online or one of the clients 16 (or associated subclient 20) requests more bandwidth. We also accept negotiations. Presentation layer 31 provides video / voice data compression / decompression on server 16 (and / or its host computer 13) and client 16. In addition, the display service is provided by client 16. [0027]

As described in more detail below, this network architecture allows multiple network components (eg, server 12, client 16, shadow client 18, subclient 20) to be arranged hierarchically. At one level of the hierarchy, server 12 and client 16 operate to exchange information such as multimedia data. At another level of the hierarchy, client 16 can communicate with its individual subclients 20 to exchange information such as commands issued / terminated by server 12. At each level of this network hierarchy, the individual network components are communicatively coupled to each other through communication links operating at that level of the hierarchy. For example, the next section describes a protocol that operates at the top level of the hierarchy (ie, between server 12 and client 16), which is a new network configuration according to its bandwidth requirements for the communication channels used at the top level of the hierarchy. Supports dynamic addition of elements at any level of the hierarchy. Communication at a lower level of the hierarchy (eg, between client 16 and its associated subclient 20) should use a similar protocol or any other suitable communication protocol, depending on the operations performed by the client and its subclients. Can be done. For example, it supports existing communication protocols for exchanging information within a wireless (eg infrared) or wired communication link between a subclient and its associated client, and that information is between client 16 and server 12. Any such data is subsequently encapsulated (and / or reformatted if necessary) within the data packet to be exchanged according to the protocol described below when attempted to be transmitted. [0028]

B. Network operation Since the basic topology of the network that supports this technology has been described above, an exemplary operation (for example, half-duplex operation) for the network will be described next. As shown in Figure 4, these operations utilize a hierarchical arrangement to transmit real-time multimedia data (eg, as frames) within subnet 10. At the highest level in the channel, forward (F) and backward or reverse (B) slots of fixed (but negotiable) duration are provided during each frame transmission period. During forward time slot F, server 12 sends video and / or audio data and / or commands to client 16, which is put into listening mode. During the reverse time slot B, the server 12 waits for the transmission from the client 16. Such transmissions can include audio, video, or other data and / or commands from client 16 or associated subclient 20. At the second level of the hierarchy, each transmit slot (forward or reverse) consists of one or more variable length radio data frames 40. Finally, at the lowest level of the hierarchy, each radio data frame 40 contains a variable length server / client data packet 42. [0029]

Each radio data frame 40 consists of one server / client data packet 42 and associated ECC bits. ECC bits can be used to simplify detecting the start and end of data packets on the receiving side. Variable length framing is preferred over constant length framing, and vice versa, for the purpose of allowing smaller frame lengths during severe channel situations. This increases channel robustness and bandwidth savings. However, although a variable length frame is used, the ECC block length is preferably fixed. Therefore, whenever the data packet length is less than the ECC block length, the ECC block is truncated (eg, using traditional virtual zero technology). If the data packet is larger, a similar procedure can be adopted for the last block of ECC bits. [0030]

As shown, each radio data frame 40 contains a preamble 44, which is used to synchronize the transmitter and receiver PN generators. Link ID 46 is a fixed length field (eg, 16 bits long in one embodiment) and is unique to the link and thus identifies a particular subnet 10. The data from server 12 / client 16 is of variable length specified by length field 48. The Cyclic Redundancy Check (CRC) bit 50 is used to detect / correct errors in the traditional way. [0031]

For the embodiments illustrated below, each frame 44 (eg, a duration of 33.33 msec in one embodiment) is a forward slot F, a backward slot B, a stationary slot Q, and a plurality of radio turnaround slots T. It is divided into. Slot F is for communication from the server 12 to the client 16. Slot B has multiple mini slots B₁, B₂It is a time shared between, etc., and minislots are allocated to individual clients 16 by the server 12 for transmission to each server 12. Each mini slot B₁, B₂Such as voice, video, voice, lossy data (ie data coded / uncoded using lossy technology, or data that can tolerate the loss of some packets being sent / received), loss, etc. No data (ie, data encoded / uncoded using lossless technology, or data for which loss of any packet being sent / received is unacceptable), low bandwidth data and / or commands (Cmd. ) Includes time to send the packet. Slot Q is quiesced so that new clients can insert request packets when they try to log in to subnet 10. Slot T appears during the transmit-to-receive change and vice versa, and the turnaround time of the individual radios (ie, the half-duplex radio 14 goes from transmit to receive operation and vice versa. It accepts the switching time). The duration of each of these slots and minislots is dynamically varied through renegotiation between server 12 and client 16 to achieve the best possible bandwidth usage for the channel. When full-duplex radio is used, each direction slot (ie F and B) is full time in one direction and no radio turnaround slot is required. Therefore, the communication protocol communicates two or more units of a computer network (eg, servers and multiple clients, subclients and / or shadow clients) with a TDMA Direct Sequence Spread Spectrum (DS-SS) communication link. Can be combined. As shown, the TDMA DS-SS communication link includes a communication time slot that can be dynamically allocated to units in the computer network. [0032]

The allocation of forward and backward bandwidth depends on the data handled by client 16. If the client 16 is a video consumer, such as a television, then a large forward bandwidth is allocated to that client. Similarly, if the client 16 is a video generator, such as a video camcorder, a large amount of reverse bandwidth is allocated to that particular client. Server 12 maintains a dynamic table (eg, in memory of server 12 or host 13), which includes forward and backward bandwidth requirements for all online clients 16. This information can be used when deciding whether a new connection is allowed for a new client. For example, if the new client 16 requests more bandwidth than is available in either direction, the server 12 can reject the connection request. Bandwidth requirement (or allocation) information can also be used to determine how many radio packets a particular client 16 should wait before it starts sending its packets to server 12. it can. In addition, error correction coding (ECC) can be increased / decreased to address the new channel state whenever the channel state changes. Therefore, depending on whether the information rate at the source has changed, it requires dynamic changes to the forward and backward bandwidth allocations. This can be achieved through the Connection Agreement command (discussed further below). [0033]

Time slot synchronization between server 12 and client 16 is considered for four network operating conditions. That is, the operating conditions when a client wakes up, a new client comes online, a channel changes, the client is absent or shuts down. These situations are described with reference to various finite phase diagrams for client 16 and server 12. In the figure, the operating state of the network component is written in a circle. State transitions are made by the reception of the current state and / or incoming messages and the output of processing related to the content. The received or sent message (ie, command) is shown next to the state transition line. For example, "A / B" on the state transition line means that the message "A" was received, and the message "B" was sent as a response while transitioning to the next state. In other cases, "A" is the output of the processing in progress and "B" may be the action taken by the finite state machine. "XX" represents an input or output don't care action. A complete description of the various commands referenced in this figure is given below. [0034]

As shown in Figure 5, when client 16 wakes up, it boots into receive mode (state 60) and receives the channel. When client 16 detects activity on a channel, it receives and determines if server 12 is changing channel (state 62) (discussed further below). If the channel change process is recognized, client 16 changes the channel with the remaining subnet 10 (state 64). Needless to say, if no channel change is in progress, client 16 will only detect normal channel communication. Whether or not client 16 needs to change channels, client 16 waits for slot Q (state 66) and sends a Connection Request (CRQ) packet to server 12 in that slot. In response, Server 12 checks the integrity of incoming requests (eg, the same request destined for the source client is received periodically, perhaps once per video frame. By sending to). [0035]

When the client's request is confirmed (for example, by receiving a confirmation packet from the client; then the client enters wait state 68), server 12 sends a Connection Agreement (CAG) package to client 16. .. This package specifically contains information about forward and backward bandwidth (eg channel slots) given to the new client 16. In addition, the maximum number of bytes that the new client 16 can send / anticipate within each data packet is set for each type of packet (eg video data, audio data, etc.). Connection The Agreement package may also contain information about the total number of data frames that the new client 16 must wait from the server's transmission and from the start of identification of the preceding client (ie, the client with the preceding reverse transmission slot). it can. All clients accept their individual connection consents by counting the number of data frames they receive from the start of the server's transmission, and start each transmission after the end of the last data frame received from the preceding client. To do. If a client encounters a Token Pass command sent by a preceding client during a calculation, the client will stop the calculation and immediately start sending itself. [0036]

After receiving the Connection Agreement packet, client 16 configures itself to send its data during its assigned time slot (eg B1, B2, etc.) and waits for the slot to come around (state). 70). In the specified time slot, client 16 initiates normal communication with server 12 (state 72) and sends any data or commands it may have. [0037]

The above description assumes that client 16 will awake and detect the channel in use. But it's possible that the channel isn't busy when Client 16 wakes up. In such a case, the client 16 sends a Connection Request packet in anticipation of the server 12 responding and waits for an arbitrary period (state 74). If no response is received, the client changes channels. If client 16 detects activity while in receive mode within the new channel (state 76), it continues to negotiate with server 12 for bandwidth allocation as described above. Otherwise, if no channel activity is detected, client 16 will connect again. Sends a Request packet and waits for a response (state 78). This process repeats for all available channels until server 12 is found. If no response is received, the client notifies the user that no server is available and powers down (state 80). However, if a response is received from server 12 on one of the channels, the client negotiates a connection (state 82) and then initiates normal communication as described above (state 84). [0038]

As shown in FIG. 6, the client 16 may be inserted online when viewed from the server. For example, client 16 may wake up after server 12 is already up and running. Server 12 is configured to wait for slot Q for a Connection Request packet sent by a new client seeking a connection. As described above, after synchronizing with the new client 16 by further exchanging Connection Request packets, the server 12 requests such authentication from the host computer 13 that stores the valid client ID. Check the authenticity of the client (state 92). If the authentication test passes, server 12 assigns a new session identifier (ID) to the client (state 93) and reallocates bandwidth for the channel (state 94). Bandwidth reallocation is required to accept new clients. Then server 12 connects Sends an Agreement packet to the new client 16, which initiates normal communication. As shown, each state 92, 93, 94 may have an associated time-out parameter (eg, maintained using an on-board timer). If no client response is received within the time-out period at any time, server 12 assumes that client 16 has gone offline and returns to wait for reception in the Q slot (state 90). [0039]

As shown in Figure 7, in the absence of an online client 16, server 12 waits in a free channel and remains in receive mode until a client packet is detected (state 95). To determine if the channels are free, check the strength of the signal received for each channel (provided by radio device 14) and select the signal with the lowest energy. It then analyzes any received data other than the Connection Request packet to see if there is a valid data packet. The channel is declared busy if any other packets, especially those marked as server-generated, are received. On the other hand, if the packet received on the channel contains no valid data other than the Connection Request packet generated by the client waiting for a connection, the channel is declared free. If no data packets are received, server 12 remains in receive mode (state 95) within that channel and the client's Connection. Wait for a Request packet. In the meantime, if the channel is occupied by another subnet close to the current server's radio, that server switches to another channel and waits for client requests. If all channels are occupied, server 12 will continue to cycle through the channels until it finds a free channel. If client 16 consistently detects packets from two servers 12, client 16 recognizes that there is an interference condition on the channel and does not establish a connection within the wireless link. Similarly, if server 12 consistently detects packets from another server, that server will not attempt to establish any client connections on the channel. These two measures ensure that servers from one subnet do not occupy clients from neighboring subnets. In addition, a unique link identifier (ID) may be used for each subnet 10 to prevent another server in an adjacent subnet from occupying a client on one server. [0040]

The client 16 can bring the server 12 into operation, for example by sending a Connection Request packet. Client 16 then returns to slave mode (eg with the time out option). When a client request is received, the server 12 periodically sends a Connection Request packet and waits for the client 16 to follow it as described above (state 96). After confirming that the client is in slave mode by the transmission, the server 12 tests the authenticity of the client (state 97), and if it passes, provides the client 16 with a Connection Agreement. If the host computer 13 takes longer than the client 16 needs to respond during any time during the authentication process, the server 12 retransmits the Connection Agreement packet to the client 16 However, the confirmation notification from the client 16 is practically unexpected. Connection After sending the Agreement, server 12 assigns a new session ID (state 98) and waits for client 16 to recognize and notify the send (state 99). Normal communication can then be initiated (state 100). [0041]

Making the client the master first, and then making it the slave after the server 12 awakes ensures low interference in the free channels when subnet 10 is not running. Needless to say, in other embodiments, the server 12 polls the client 16 at regular intervals within the channel. However, these schemes can keep channels busy even when subnet 10 is not running, thus denying channels to nearby subnets. [0042]

In some embodiments, multiple clients 16 (or shadow clients 18) are supported with the same input from server 12. In such cases, only one copy of the forward data packet (the client ID is the ID of the first client) needs to be sent. The remaining clients are treated as shadow clients, each with a separate command packet from server 12. [0043]

In the multi-client model, if one of the clients 16 wakes up late, it waits for a quiesced (Q) slot and begins sending its command packets into that slot. However, it is possible for multiple clients to wake up after server 12, in which case the technology may cause conflicts if two or more clients 16 each attempt to send in the Q slot. We have prepared a means to solve the problem. To avoid such conflicts, client 16 can optionally choose to insert (or not) each request into the Q slot. The first client 16 recognized by the server 12 is added to the subnet 10 first, and so on. [0044]

Table 3 below (Tx represents radio device 14 in transmit state and Rx represents radio device 14 in receive state) details multiple client models and a general phase diagram for inserting new clients online. ..

[Table 3]

<img file="JP2002525913A_D0003.tif" /> 【0045】

Because of the specified time slot array, if one client responds late for some reason, the other client will not be able to keep track of the specified time slot. This can waste valuable bandwidth. Therefore, the technology provides a two-element solution to this problem. [0046]

First, each client 16 is required to track the current client occupying the channel, thereby attempting to detect the client immediately preceding it in the line. If the channel is quiesced, the current client waits for a predetermined length of time before initiating its own transmission. The wait time is determined by the quiesce threshold allowed between the two clients and the number of clients to send before the current client. It uses the order of transmission established during connection set-up. The only exception to quiesce is the Q slot, where all online clients 16 must suppress transmissions. [0047]

Second, Server 12 monitors takeovers on any channel and takes appropriate action to connect / disconnect clients that are consistently delayed. When such a delay occurs in the response, the video generation client / server reduces the size of the output data in the next video slot accordingly. This allows proper slot time synchronization to be maintained. The video generation client / server knows the unused channel length and appropriately reduces its output during the current / next video slot. [0048]

To connect a new client, the size of slot Q should be at least as long as one radio data frame 40 propagating the Connection Request packet. That is, the new client 16 receives all data frames, learns the data frame structure during the current session, and makes its request for a connection in slot Q between the last online client and server 12 transmission. insert. The request is confirmed after checking its consistency for several transactions (ie, between server transmissions). Keep in mind the radio turnaround time and be careful not to confuse it with the Q slot. This may be verified using a timer. [0049]

The server 12 needs to send a packet to the new client in order to notify the new client that the server 12 has acknowledged the connection request. That is, server 12 is the first client (ie, slot B) that is supposed to initiate its transmission following the server.₁The client assigned to) must not overlap the last packet sent by server 12 to the new client at the end of the F slot. Therefore, the server can broadcast a Token Pass at the end of its transmission. The first client in the line then sends it after receiving a Token Pass from server 12 (and, if necessary, allowing radio turnaround time), or after timed out an unused channel. To start. [0050]

As explained above, when the channel changes, all clients 16 need to resynchronize with server 12. Channel switching can occur when one of server 12 or client 16 experiences a serious channel failure (eg, despite antenna diversity and / or a high degree of ECC). In such a model, Server 12 seeks another channel in an attempt to detect a channel where the interference is less severe. If it determines that the new channel gives better prospects for communication operation, the server 12 initiates a channel change or switch operation. [0051]

Figure 8 shows the procedure for changing channels for a 2-channel subnet as seen from server 12. If during normal communication (state 101) the server 12 determines that the channel status is unacceptable or becoming unacceptable, the server 12 will start searching for a new channel for all of it. Notify client 16 that it is temporarily quiesced. This procedure is repeated multiple times (state 102) (eg 5 times) to ensure that the message is received by all clients 16. The client is required to send a confirmation notification in response, but even if the confirmation notification is not received from all clients 16 online, the timer on server 12 times out and server 12 adjusts its radio 14. Allows you to inspect other channels (state 104). If a new channel is free, Server 12 switches back to the original channel (for example, after a predetermined receive wait period of 4 ms for one embodiment) and changes. Broadcast a Chanel message (perhaps about 5 times) to all online clients 16 and wait for individual channel Change Channel Acknoeledge (Ack.) Messages for client 16 (state 106). Each client 16 changes channels only after sending its Change Channel Ack. Message. If server 12 still does not receive a response from one or more online clients 16 after waiting for a predetermined length of time, server 12 determines that the client is unreachable. Similarly, if the client 16 does not receive a message from the server even after waiting for a predetermined period of time, the client 16 determines that the server 12 cannot be contacted, and can arbitrarily change the channel. Server 12 switches to the new channel after all online clients 16 have responded or after a time-out situation. [0052]

Upon entering a new channel, client 16 waits for server 12 to start communicating. Server 12 broadcasts a Change Channel Ack. Message (state 108), informs it that it is on a new channel, and waits for Change Channel Ack. From each client 16. If one or more clients 16 do not respond within a given number of attempts, server 12 determines that client 16 is temporarily absent. Correspondingly, server 12 modifies client 16's response sequence (for example, by sending a new Connection Agreement) to keep out absent clients. After all clients 16 wait (state 110) to verify that they are in the new channel (or the time-out period expires), server 12 issues a call-answer slot sequence to the new channel. Update and send new connection consent to all clients 16. Normal communication can then be resumed (state 112). [0053]

If client 16 arrives late on the new channel, the client must wait for the server call to answer. If server 12 has already determined that client 16 is absent, client 16 waits for normal communication to resume and sends a Change Channel Ack. Message in the quiesce (Q) slot. Upon receiving such a message, Server 12 sends a connection consent, including new clients in the network. [0054]

During this time, two steps are taken to keep any users associated with the new client unaffected. First, all clients 16 perform video frame freezes and / or audio iterations to simulate a smooth session at the user level. Second, server 12 maintains session details for a predetermined period of time long enough to facilitate reconnection. The absent client 16 is eventually removed from the server's online client list only after the predetermined wait period has expired (state 114). [0055]

If server 12 receives a Change Channel Ack. Message from a very new client 16 after it has been removed from the online list, client 16 will be notified to make a new connection by sending a Connection Request. In such a case, the client 16 can notify the user that the link has been lost. This looks like a power failure at the user level and may instruct the user to reestablish the link with server 12. [0056]

During channel selection (eg, initially or as part of a channel change operation), server 12 is already running subnet 10 on the current channel, and a link with the same PN code and / or link ID. It is necessary to detect the potential existence of. It is highly unlikely that such a case will occur, but it is not zero. The link ID is assumed to be unique to the link / subnet / cell. To ensure this uniqueness, users may be prompted to enter a unique password (eg, a Social Security number or other unique alphanumeric string of similar length) during subnet installation. This password may be parsed by server 12 (and / or its host computer 13) to determine a unique ID and PN code. These values remain the same for all sessions unless the user decides to change it (eg by reinstalling subnet 10). [0057]

In one embodiment, longer bit lengths can be used to guarantee uniqueness and thereby provide additional security, but 11-bit PN codes (barker codes) can also be used. A table of available PN codes is maintained by server 14 / host computer 13 and one of those codes is selected based on the password entered by the user. The PN code may be changed whenever interference increases due to the use of the same PN code within the adjacent subnet 10. [0058] [0058]

If both channels are occupied or there is significant interference, server 12 can take one of two actions. If the number of clients 16 that have severe channel interference to or from it is small, the server 12 decides to disconnect them. On the other hand, if the number of clients 16 involved is large, the server 12 waits for a while and decides to try the channel after some time. In either case, Server 12 must send a Retry Later command to each of the associated clients 16 until it receives a Disconnect Ack. Message from each of the affected clients 16. [0059]

Next, FIG. 9 illustrates the channel switching operation from the client side for an exemplary 2-channel subnet. If client 16 is instructed to be quiesced during normal communication (state 120), that client 16 sends an acknowledgment (eg Disconnect Ack.) And waits for further instructions from server 12 (state). 122). If server 12 broadcasts a Change Channel message, client 16 sees it and then changes the channel. Alternatively, if no message is received from the server 12 after waiting for a predetermined time, the client 16 may determine that the server 12 is unreachable and voluntarily change the channel. [0060]

Upon entering a new channel, client 16 waits for server 12 to start communication (state 126). Server 12 broadcasts a Change Channel Ack. Message to notify it that it is in a new channel and asks for Change Channel Ack. From each client 16. In response, client 16 verifies that the server is in a new channel and waits for new connection consent from server 12 (state 128). After negotiating that connection agreement with server 12, client 16 waits for normal communication to resume (state 130). [0061]

If client 16 is slow to reach the new channel, the client must wait for the server call to answer. If server 12 has already determined that client 16 is absent, client 16 waits for normal communication to resume, and then sends a Change Channel Ack. Message in the quiesced (Q) slot (state 132). .. Upon receiving such a message, Server 12 sends a connection consent to include the new client in the network. During this time, client 16 performs video frame freezes and / or audio iterations to simulate a smooth session at the user level so that it does not affect any users associated with the new client. be able to. [0062]

If server 12 receives a Change Channel Ack. Message from a very new client 16 after it has been removed from the online list, client 16 is notified to make a new connection by sending a Connection Request. In such cases, client 16 may notify the user that the link has been lost (state 134). This looks like a power failure at the user level and may instruct the user to reestablish the link with server 12. If client 16 loses contact with server 12 for an extended period of time during channel selection, the client may notify the user of the situation and turn off (state 136). [0063]

Like client 16, subclient 20 can be added to a subnet running online (ie, also known as hot insertion). As shown in FIG. 18, when the subclient 20 wakes up, it sends a registration packet to its associated client over the communication link 21 (state 220). In some cases, the communication link 21 is a wireless link (eg, an infrared communication link), in other cases it may be a wired link. When client 16 receives a transmission from subclient 20, it authenticates the subclient, for example by checking its registration identity against a list of known / authenticated subclients (state 222). In some cases, this may require communication with server 12. If subclient 20 is approved, client 16 configures a subclient session identifier that uniquely identifies the new subclient from other subclients operating with the client on the network. Then client 16 adds Send a Subclient command (see further below) to server 12 (state 224). The Add Subclient command includes a subclient session identifier and subclient features described in more detail below. [0064]

When server 12 receives the Add Subclient command, it records the subclient session ID and whether the subnet accepts the addition of a new subclient (for example, to accept commands sent by or sent to it). Completes the subclient authentication process by determining if sufficient bandwidth is available on the wireless link (state 226). If the authentication process is successful, the server adds the new subclient to the subnet by inserting the new subclient into the online service table and by sending the Subclient Added command to the associated client. If the new subclient cannot be accepted, or if the new subclient is rejected in another way, the server sends a Subclient Not Added command. [0065]

Whatever decision the server makes, the result of the authentication process is sent from the client to the subclient (state 228). If the subclient is approved, it begins normal operation and communicates with that client and server 12 (state 230). If the subclient is rejected, it will be disconnected (state 232). In either case, the user is notified of the addition or rejection of subclients through the appropriate status message displayed on the display. [0066]

During network operation, subclient 20 may be disconnected by either server 12 or associated client 16. For example, if the subclient 20 is inactive for more than a predetermined length of time, the client 16 may disconnect from the subclient 20. In such a case, client 16 must notify server 12 of the situation and request that the disconnected subclient be removed from the list of servers on the online device (see the Delete Subclient and Subclient Deleted commands below). I want to be). [0067]

In other cases, server 12 may decide to remove subclient 20 directly, for example if the application running on host 13 does not support a particular subclient (or, for that matter, client). Network maintenance and shutdown operations may also require the subclient (and client) to be automatically removed. [0068]

C. Network packet structure As shown in Figure 10, packet 42 transmitted within the wireless link has three main parts: header 140, variable length payload 142, and ECC block 144. As detailed in FIG. 11, header 140 includes field 146 for client ID, time stamp 148, STP150, packet length 152. Some packets (eg, audio packets and some commands) 42 originate on the host computer 13 and are therefore inputs to the server 12. However, the server 12 adds a time stamp 148 to these packets 42 (eg, to allow proper synchronization on the receiving side) before writing the packets 42 to the associated radio device 14. [0069]

In one exemplary embodiment, the header 140 is a double word (DWORD, eg 32 bits in one embodiment), which 8/16/32 writes and reads data to or from packet 42. The hardware structure of the bits is also aligned to be processed with less processor time consumption. The client ID field 146 is 1 byte long and is unique to client 16 in subnet 10. This allows 255 different clients 16 to be supported for each server 12. A special client ID (eg all "1") can be reserved for broadcasting and another client ID (eg all "0") can be reserved for server 12 .. Timestamp 148 is added to eventually synchronize audio and video packets. Timestamp 148 is given as the output of the time counter maintained on server 12. Client 16 and host computer 13 can use the time stamp 148 provided in the incoming packet to synchronize their time counters. [0070]

The STP field 150 provides information about the source of the packet, the type of data contained within the packet, and the position of the packet within the current time slot. This field is divided into three subfields (not shown). The top subfield (3 bits long in one embodiment) is used to represent the origin of the packet (eg all 1s for server 12 and all 0s for client 16). However, this field is ignored for communication packets exchanged between server 12 and its host computer 13. When packet 42 is received, majority logic voting is performed using the data in this field to determine the origin of packet 42. [0071]

The intermediate subfield of STP field 150 (which may also be 3 bits long in this embodiment) represents the packet type. Supported types are: audio packets, video packets, data packets (eg from input / output devices such as keyboards, mice, joysticks), command packets from or to client 16, from server 12 or Contains command packets to server 12. The protocol scheme allows video, audio, commands between server 12 and client 16 and the transfer of low bandwidth data from subclient 20 within subnet 10. Examples of low bandwidth data include keyboard input, mouse input, analog joystick input, and the like. The audio and video are communicated in separate packets and transmitted by the radio device 14 as separate data frames 40. However, the low bandwidth data packet may be combined with the command packet and transmitted as one data frame 40. [0072]

The last subfield of the STP field 150 (the position of the subfield) is 2 bits long and specifies where the packet falls within the group of packets. This field has a value expressed as below (one value may be DON'T CARE). [0073]

First Packet: Indicates that the current packet is the first packet sent from the source and there are still packets after it. Continuation Packet: This indicates that there are at least two packets from the same source after the current packet. One Before the Last Packet: This indicates that there is only one packet from the same client 16 (or server 12 in slot F) after the current packet. Last Packet: This indicates that the current packet is the last packet from the current client 16 (or server 12 in slot F). [0074]

By using the information in this field, the next client 16 in the line can detect the end of transmission by the preceding client 16 at least one packet earlier. While receiving the last packet 42, it instructs its associated radio device 14 to switch to transmit mode after that packet. [0075]

The length of packet field 152 indicates the number of DWORDs in the current packet 42. The actual number of DWORDs may be one more than the length indicated by length field 152, since zero-length packets are preferably not used. [0076]

Payload field 142 is the body of packet 42. For audio and video packets, this field contains compressed audio or video data (as appropriate) from their respective sources. For data packets, the payload field contains data generated by an input / output device such as a keyboard or mouse. [0077]

Figure 12 shows the payload structure of data packet 154. Preferably, the subclient type (SCT) 156, subclient ID (SCID) 158, and data length 160 appear before the actual data 162 to help the receiver learn the source of the data generator. One or more sets of data 162 may be contained within a single data packet 154, where each data set always has its own SCT, SCID and length parameters. [0078]

The SCT field 156 comprises the type of information source such as keyboard, mouse, analog joystick on the receiving side, and the SCID field 158 identifies individual subclients of that particular subclient type. For example, keyboards and mice can have similar subclient IDs, but can be distinguished by associating their different subclient types with their respective IDs. This type of protocol support makes it easy to add different types of low-bandwidth subclients 20 to the same client 16 at any time during or before a running session. Both the SCT field 156 and the SCID field 158 can be 8-bit wide, thereby supporting 256 different types of subclients 20 and up to 256 subclients of each type can connect to each client 16. [0079]

The data request does not include the length field 160. However, the data transmission includes a length field 160, which may be 1 byte long and specifies the length of the data that follows. The actual low bandwidth data 162 itself follows the length field. For one embodiment, the total length of these packets 154 shall not exceed 120 bytes for each video frame. [0080] [0080]

For command packets, payload field 142 contains a series of commands, each command followed by the associated data bytes and / or low bandwidth data from subclient 20. That is, in this embodiment, the server 12 collects all the commands that need to be transmitted to the client 16 one after another over the wireless link in one data packet 42. Therefore, the maximum number of command packets sent by server 12 is equal to the number of online clients 16 currently supported by server 12. Conversely, the maximum number of command packets that must be sent to server 12 during each frame, including a sequence of commands and / or low bandwidth data from its associated subclient 20, is from any client 16. There is only one. [0081]

The commands supported in each direction of communication between wireless links are described below. Unless otherwise noted, no acknowledgment (Ack.) Is required for any packet sent from server 12 / client 16 in this embodiment. Any number of commands can be lined up together to form a data packet 42, in which case the only limit is the size of the overall packet 42. For this embodiment, the total size of packets 42 must not exceed 80 bytes for each video field duration. Other packet sizes can be selected based on the bandwidth requirements of various input devices (eg keyboards, mice, joysticks, etc.). Figure 13 shows the general payload structure for command packet 164. Each command packet 164 contains a header 166 and an "n" command field 168. Command field 168 may include command 170 and any associated payload 172, if any. If there is no associated payload 172, command field 168 is single byte long. For some commands 170, the associated payload 172 is of a given size. Yet another command 170 may have a variable length payload 172. In such cases, the payload length is explicitly stated before (or within) payload field 172. [0082]

1. Commands to or from client 16 A set of commands from server 12 to client 16 and a set of commands from client 16 to server 12 are supported by the present technology. Server 12 is configured to handle most of the commands independently of its host computer 13. Only decisions associated with access to large tables (eg, those that cannot be stored locally by server 12) and user input need to be passed to (and originate from) host computer 13. When server 12 reads / compiles each command packet 164, if such information can be useful (eg, server 12 must adhere to the same agreed constraint for each particular client 16). (For commands like the Connection Agreement) may decide to keep a copy of the packet for itself. In one embodiment, the supported commands may include: [0083]

Connection Request: This is a packet with no payload. Each client 16 uses this command to inform server 12 that it is up and needs service. Server 12 responds using the same command. Client 16 and server 12 repeatedly send this command to each other until a suitable time synchronization is achieved. When synchronization is achieved, server 12 becomes the master and checks the reliability of client 16. If the authentication procedure fails, Server 12 rejects Client 16 by sending a Disconnect Request (Req.) Command. Client 16 is required to respond by sending a Disconnect Ack. On the other hand, if client 16 is successfully authenticated, host computer 13 sends a Client Authentication Pass message to server 12. Server 12 checks whether it is able to accept the throughput request of client 16. If not possible, the server will retry Notify the client to retry the connection later by sending a Later command to client 16. In such cases, client 16 is prompted to respond by sending a Disconnect Ack. When the server 12 decides to accept the client 16, it implies connection permission by sending a Connection Agreements packet to the client 16. [0084]

FIG. 17 illustrates the structure of an exemplary Connection Request packet 210. Connection The Request packet 210 includes a connection request command field 212, a client serial number field 214, and a client characteristic field 216. The information contained in the serial number field 214 and the client characteristic field 216 serves to identify individual clients to server 12. Such information can be stored in memory within the client during manufacture (eg, read-only memory) and can include client type, manufacturer, driver information, and other client identification information. If the client attempts to be granted access to the subnet, server 12 may add client session ID 218 to the packet while sending the packet to client 16. The client can then utilize the session ID information in its transmission to the server 12 without having to retransmit the redundant serial number and characteristic fields each time. Therefore, client session ID 218 serves as a simple way to identify client 16 to server 12, and server 12 can address data and commands destined for a particular client 16 if desired. I will do it. This saves overall bandwidth. [0085]

Connection Agreements: Server 12 uses this command for three purposes. First, to imply connection authorization to the new client 16 and to specify connection conditions (for example, for server-client and client-server bandwidth, ECC type, audio / video information compression type, etc. ). Second, when client 16 receives this command during a session, it implies a forced change in the previously negotiated connection agreement (eg, bad channel condition, new client is added to subnet 10). For some reason). Third, when Server 12 notices that a particular client 16 has been quiesced for a given amount of time (relatively long), Server 12 makes a Connection without effectively changing the previously negotiated connection. Send an Agreements packet and ask for confirmation in exchange. If no confirmation is received after a certain number of attempts to contact client 16, client 16 is declared disconnected. Note that in some cases, for example, if client 16 cannot handle the data transfer rate of the server, this same command may be issued from the client side. [0086]

In one embodiment, the total payload size for the Connection Agreement command is 5 bytes, and the negotiation section contained in packet structure 174 is shown in FIG. Connection Agreement packet 174 begins with the connection agreement command 176 that identifies the packet. The forward bandwidth field 178 is used to specify the number of packets that the client can expect to receive from the server. The reverse bandwidth field 180 is used to specify the number of packets that the client can send to the server during its reverse slot. These fields also define video, audio, and data bandwidth in each direction. The PCL-ID field 186 specifies the ID of the preceding client (8 bits). The first client allowed to send after server 12 receives zero (0) as its PCL-ID. CNUM188 is the client online number, which informs client 16 of the number of clients that precede it in the current online service list. [0087]

SCA (Outgoing Client Attribute) 190 is a control field used by Server 12 to inform client 16 whether its property or attribute is needed or not. For example, if SCA190 is set to all 1s, this indicates that client 16 needs to send its properties to server 12 (eg if the client's profile is accidentally erased or a new client is installed). If). Server 12 repeats the packet (with the time stamp change) confirming that it has received these properties, after which client 16 confirms that it has received the Connection Agreement. Send Ack. On the other hand, if the SCA field 190 is set to all 0s, this is used as an indication that the server 12 is requesting that the client 16 adhere to or log out of the previously defined property. To. If any bit in the SCA190 is corrupted while the radio link is being transmitted, the inherent redundancy during the iteration is used on the server 12 / client 16 (eg by majority logic voting). Determine its actual content. [0088]

Connection Agreement Ack .: This packet originates from client 16 and is sent in response to the Connection Agreements command. This is a packet with no payload. [0089]

Add Subclient: Each client 16 is responsible for determining which subclient 20 it needs to support and uses this command to report the same content to server 12. This allows the server 12 to allocate the required bandwidth. If the bandwidth requirement is met, the server 12 notifies the host computer 13 about the subclient 20 so that the host computer 13 can load the associated driver. As shown in FIG. 15, the subclient add packet 192 may include command ID 194, as well as subclient session ID (SS-ID) 196, subclient type (SCT) 197, and subclient ID (SCID) 198. it can. SS-ID196 serves the same purpose as the client session ID described above, and SS-ID196 and SCID198 are dynamically allocated by server 12 and the corresponding client 16 as long as subclient 20 wakes up. Note that you can. [0090]

Subclient Not Added: This command was sent by server 12 to client 16 to indicate that it succeeded in including the new subclient 20. In addition to the command type, you may use SCT and SCID fields similar to the fields in the associated Add Subclient command. [0091]

Subclient Not Added: This command is sent by server 12 to client 16 to indicate that it is not possible to add a new subclient. The command structure may be the same as the Add Subclient command. [0092]

Delete Subclient: Client 16 does not respond Any subclient 20 may time out and report it to server 12. In some cases, only selected sets of subclient 20 can be timed out. By removing the subclient 20 that is no longer in use, the server 12 can reuse the previously allocated bandwidth and the host computer 13 can unload any associated drivers. .. The packet contains the subclient type and subclient ID, and its command structure may be the same as the Add Subclient command. [0093]

Subclient Deleted: This packet is sent from server 12 to client 16 in response to the Delete Subclient command. Its command structure may be the same as for the Add Subclient command. [0094]

Reset Client: This command originates from server 12 and requires the receiving client 16 to reset itself and start again from the Connection Request stage. This is a packet with no payload. [0095]

Reset Ack .: This is an acknowledgment for the Reset Client command. This is a packet with no payload. [0096]

Disconnect Request: This command originates from either server 12 or client 16 depending on whether server 12 excludes client 16 or client 16 is turned off. This is a packet with no payload. [0097]

Retry Later: This command originates from server 12 and notifies client 16 that it cannot currently serve client 16 due to either severe channel conditions or bandwidth limitations. Upon receiving such a command, client 16 passes the same information to the associated user, thereby instructing the user to try to connect later. This packet has no payload. [0098]

Disconnection Ack .: This is an acknowledgment for the Disconnect Request and Retry Later commands. This is a packet with no payload. [0099]

Key Frame Request: This command originates from the receiver of the video transmission and is sent whenever there is a frame loss on the receiver. Confirmation notifications for this command may take the form of keyframes retransmitted by the sender. This is a packet with no payload. [0100]

Channel Status: This command is voluntarily provided by client 16 at regular intervals to notify server 12 of its channel status. The channel status bytes form the payload of the packet, which can be 1 byte long. [0101]

Token Pass: This is a payloadless command that signals the end of transmission from the sender. This command instructs the next client 16 (or server 12) to start sending. Server 12 waits for this command from the last client 16 to initiate its transmission. When server 12 sends this packet, all client IDs are set to 0, instructing the first client 16 in the string to start sending it. This can also be seen as a dummy confirmation or a "client alive" signal, in which case server 12 tracks any client 16 that shuts off without first notifying server 12. You can also use the same command to indicate that the channel change is complete. [0102]

Remain Quiet: This is a payloadless command originating from server 12. Server 12 uses this command before channel switching to notify all clients 16 that the server is quiesced until it checks for other channels and returns. Each client 16 is prompted to acknowledge the command (eg by sending a Disconnect Ack.). [0103]

Change Channel: This is a payloadless command originating from server 12. If server 12 determines that the other channel is better than the current channel, the server notifies all clients 16 to change channels. [0104]

Change Channel Ack .: This is an acknowledgment sent by each client 16 to server 12 in response to the Change Channel command. This is a packet with no payload. The same command can be used by both server 12 and client 16 to confirm the completion / termination of the channel change. [0105]

New PN Code: This command originates from server 12 and contains a payload containing a new PN code bit and a time mark at which the change will be made. [0106]

New PN Code Ack .: This is an acknowledgment sent from each client 16 to server 12 in response to the received New PN Code command. Each client 16 iterates over the new PN code to allow server 12 to verify proper reception. If the two codes do not match, Server 12 may resend the New PN Code command. [0107]

2. Commands from or to host computer 13 The host computer's communication with Server 12 is not on the wireless link and can be seen at two levels. The first level uses traditional hardware ports and low-level signaling to communicate low-level messages commonly used in computer applications, such as "transmission complete" and "receiver buffer full." The second level is established on top of the first level and propagates higher levels of information such as connecting and disconnecting clients using the network protocols, packet formats, etc. described above. The first level of communication is virtually conventional and will not be discussed further. The second level of communication uses the following commands. [0108]

Data Request: This command originates from host computer 13 as a request for the contents of the server's memory. Server 12 is Data Respond by providing data using the Send command. The same command is used by server 12 to fill a particular block of memory with data from host computer 13. The command structure is the same as the data transmission packet except that there is no data. [0109]

Data Send: This command originates from host computer 13 or server 12. The host computer 13 uses this command to change the contents of the data stored on the server 12. The server 12 uses this command to supply the data when requested by the host computer 13. [0110]

The format of the data transmission packet 200 is illustrated in FIG. As shown, the packet contains command ID 202, which identifies the command type. High-byte and low-byte address fields 240, 206 are included to identify the memory location being accessed. Finally, the data payload 208 itself is provided. [0111]

Data request / send commands are supported here due to the fact that mailbox registrations commonly used in low-level communications may not be sufficient to store the contents of the server's memory location (it is another embodiment). It may be a low-level command). [0112]

Client Authentication Pass: This command is sent from host computer 13 to server 12 to indicate that client 16 can be accepted. This can be a command without a payload. [0113]

Shutdown: Host computer 13 sends this command to server 12 before shutting down. The same command may be used during times when the host computer 13 does not want to support client 16 for any reason (eg, parental regulation). Server 12 disconnects from all clients 16 and acknowledges the host command through Shutdown Ack. This is a command without a payload. [0114]

Shutdown Ack .: This is a payloadless command originating from server 12. After this command is passed, server 12 times out and shuts down. Host computer 13 waits for (or times out) this confirmation notice before shutting down. [0115]

D. Network matters The network must be installed during the first startup. This requires the distribution of PN codes between subnets 10 (for example, to minimize the use of the same PN code by two adjacent subnets) and initiates a list of clients 16 on host computer 13. (For example, so that the server 12 can deny a connection request from any uninstalled client whose properties and bandwidth requirements are unknown to the host computer 13), the client ID is between the clients 16. Distribute (eg, for expected data from server 12 and for each transmit slot to prevent confusion between clients 16) and form a table of estimated bandwidth requirements for each client 16 (eg, for example). Allow server 12 to pre-calculate bandwidth requirements online before connections are allowed to any particular client 16). [0116]

Before deploying any new client 16 to subnet 10, the list of clients recognized by host computer 13 must be updated. This may be done directly by the user on the host computer 13 or remotely as long as the client ID is provided to both the server 12 and the new client 16. [0117]

During normal operation, client 16 may interrupt the response. This can lead to catastrophe, as client 16 may not be able to use the channel after the absent client. Two-way solutions are implemented to alleviate this problem. First, if client 16 does not receive a packet from the preceding client on the line, client 16 calls a timer and waits a predetermined amount of time before capturing the channel. Second, it uses the Receive Signal Strength Indication (RSSI) from the radio 14 to check for free channels and the associated radio 14 cannot recognize the true packet (eg due to a serious channel condition). It is also possible to avoid false captures in cases. [0118]

To solve the problem of one or more clients being absent, the latency in a free channel is predefined. All clients track unused time and capture channels after waiting for appropriate predefined multiple wait times. If K consecutive clients 16 are absent, the (K + 1) th client 16 takes over after K predefined times. In addition, the server 12 tracks the unresponsive client 16 and moves the responsive client 16 (eg, by modifying its Connection Agreement) to properly fill the gap in the channel. [0119]

As pointed out earlier, if client 16 wakes up after server 12 is already up and running, client 16 must check the channel and then respond in the quiesce (Q) slot. For this reason, Server 12 predetermines all Online Clients 16 before removing them from the list of Online Clients, even if the Clients are shut down without proper communication with Server 12. I remember the time. If a shut-down command sequence or time-out removes a client from the online list, the bandwidth released by the outgoing client is reassigned to the client that needs it. [0120]

If client 16 wants to disconnect, a Disconnect Request is sent to server 12, which shuts off after receiving the Disconnect Ack. Server 12 removes the client from the list of online clients after sending the confirmation notification. If the acknowledgment is lost, client 16 sends another Disconnect Request packet, and server 12 remembers that client 16 has already been deleted, so it sends another Disconnect Ack. Packet to send client 16. Can be shut down. [0121]

Client 16 may remain powered on when the client's application is shut down. However, since the server 12 shuts down the application, it waits for a predetermined length of time, sends the Connectioin Terminate command to the client 16, and waits for the Disconnect Ack. Packet. In response to the Connection Terminate command, client 16 powers down and server 12 removes client 16 from the list of online clients. However, if the client's previous confirmation notification is lost, the server 12 may send another Connection Terminate packet, so the client 16 waits for a while before it actually powers off. [0122]

Several network factors must be considered in order to implement the protocol described above. For example, some form of error recognition and error correction must be adopted to protect against failures due to the noisy and lossy nature of the radio links that support subnet 10. Communication channels must also be monitored so that the network can respond to changing channel conditions (eg, increased noise). This enables the channel switching operation described above. In addition, data encryption can be used to protect against eavesdropping and prevent outsiders from manipulating data and / or setting subnets. These or other matters are described in detail below. [0123]

As mentioned above, error correction coding (ECC) can be used to introduce error recognition and correction. In one embodiment, ECC coding is achieved using a Reed-Solomon encoder. Each data packet 42 (including header) is divided into blocks of 239 bytes and ECC is executed to form blocks of 255 bytes. If the number of bytes in the data packet 42 is not a multiple of an integer of 239, virtual zero coding technology is used to send the last block with the truncated ECC. In this technique, ECC bytes are calculated as if the data were zeros embedded to complete the block, but no embedded bytes were sent. Instead, embedded bytes are added in the receiving device and the data is decoded. For some embodiments, all packets are treated equally, but in other embodiments, audio and command packets are transmitted by a high degree of ECC, whereas the video data contained in the packets is important. Depending on the gender, the video packet may be protected in a different way. [0124]

Each client 16 can track all packets sent by the server 12 and use a time stamp on each packet to detect any packet loss so that the channel state can be continuously monitored. The number of packet loss calculations is automatically relayed to server 12 approximately once per second (or any other period), which can use this information to determine channel status. Such channel monitoring is useful for providing channel change decisions and changing error protection. Channel changes can be performed whenever noise / interference in the current channel becomes unacceptable. Increased (or reduced) error protection is used to provide better bandwidth utilization and robustness, depending on the channel state. [0125]

The technique avoids the use of significant overhead (ie, the time it takes to transfer information other than true data). In exemplary subnet 10, overheads come in many forms: radio turnaround time (eg 4 Mbps or 5 bytes, 10 μsec or 40 bits), radio data frame preamble 44 (eg 80 bits without diversity, or). Diversity 128-bit), wireless data frame headers (eg 16-bit Link-ID, 16-bit length information, 16-bit CRC 48 bits), packet header 140 (eg 8-bit ClientID, 8) Bit Time Provided and required for new clients to propagate Stamp, 8-bit STP, 32-bit 8-bit length field), and one connection request packet for each video frame time (eg 16 bytes). Includes slot Q, which must be provided in case. To keep the overhead to a minimum, the server 12 continuously monitors the channel usage statistics and changes the bandwidth allocation between the clients 16 accordingly. Therefore, the channel is not allowed to remain unused for an extended period of time. [0126]

The overhead for a given channel is estimated as follows for one embodiment. If each radio data frame 40 is restricted to propagate a single packet 42, the overhead of each data frame 40 is 128 + 48 + 32 = 208 bits = 26 bytes. For subnet 10 with N online clients 16, there are 2N command packets within any video field duration. The maximum payload of these packets is limited to 100 bytes. This limit is chosen to meet the typical traffic expected with a mouse, keyboard, and analog joystick interface, and to provide other commands. For example, a keyboard interface is expected to require up to 100 words per minute, or approximately 10 keystrokes per second. The result is 0.32 bytes / field. But each keystroke is a 16-bit word, which is a 2-byte payload. Audio (44.1K samples / sec, stereo, 2: 1 compression) is allocated approximately 800 bytes per video field 44. This means that it fits in one data frame 40. Needless to say, other values may be used for the above parameters as appropriate for a particular channel / subnet. [0127]

Using the above values, the total bandwidth available in video field 44 is 4 * 10⁶*16.68335*10^-3= 66733.4 = 8341 bytes. For audio information, (800 + 26) = 826 bytes for each field 44: Command information is (100 + 26) * 2N bytes (for two clients 16, this is 616 bytes); Radio turnaround time is (N) +1) * 5 bytes (15 bytes for two clients); and the quiesced (Q) slot is set to 16 bytes. The video information is allocated any remaining bandwidth, i.e. for the above embodiment, the video information is divided by approximately 8341- (826 + 616 + 15 + 16) = 6880 bytes (including overhead). This is Terra. Therefore, each radio data frame propagating video information requires (1024 + 26) = 1050 bytes. Therefore, the video information occupies a total of seven packets, six of which are filled and one packet is partially filled. So the total number of such frames in video field 44 would be 2N commands, 1 audio, 7 videos. For two clients, this would be 12 data frames. Therefore, the overhead is 15 + 12 * 26 = 327 bytes. [0128]

This corresponds to an overhead of 3.92% of the total bandwidth (8341 bytes) available for a single video field duration. If you provide 25% of the extra overhead due to any delay associated with wireless programming etc., this is a 4.9% overhead. Even after adding another 6.275% overhead for ECC, the technology contains less than 12% of the total overhead. [0129]

From the above description, it will be clear that the server 12 performs all dynamic network management, whereas the host computer 13 performs static network management. Dynamic network management includes bandwidth allocation, network monitoring (also reported on host computer 13) and renegotiation for bandwidth utilization; maintaining a list of online clients; channel selection / modification. Static network management has all the details about the installation (eg determining the link ID, PN code, etc.); maintaining the client ID; maintaining channel status and variation, and determining the PN code change (eg determining each in both directions). You need a table or other list that is maintained for client 16, which must be updated whenever channel status is received by server 12, and entries are cumulative over a long period of time, for example 1 week / 1 month. It is preferable that decisions be made for each client 16 in each direction based on the cumulative statistics of the nature of the channel); Notify. [0130]

As described above, the real-time multimedia wireless network protocol has been described. Although described with reference to the particular embodiments illustrated, the invention should not be limited thereby. Instead, the invention should only be evaluated according to the following claims.

[Simple explanation of drawings]

[Figure 1]

It is a figure which shows the generalized network architecture supported by the wireless protocol which is one Embodiment of this invention. [Figure 2]

It is a diagram (a) showing a preferable distribution of a plurality of non-overlapping subnets in an environment and a diagram (b) showing an exemplary environment in which subnets overlap. [Fig. 3]

FIG. 5 shows the conformance of Open Systems Interconnection (OSI) to a network system configured according to an embodiment of the present invention. [Fig. 4]

It is a figure which shows the hierarchical arrangement about the transmission of data in the subnet according to one Embodiment of this invention. [Fig. 5]

It is a state diagram which shows the process of adding a client to the subnet by one Embodiment of this invention. [Fig. 6]

It is a state diagram which shows the process of inserting a client into a subnet seen from the server by one Embodiment of this invention. [Fig. 7]

FIG. 5 is a phase diagram showing a process by which a server initiates a session on a new client according to an embodiment of the present invention. [Fig. 8]

It is a state diagram which shows the process of the channel change in the subnet seen from the server by one Embodiment of this invention. [Fig. 9]

It is a state diagram which shows the process of the channel change sequence about the subnet seen from the client by one Embodiment of this invention. [Fig. 10]

It is a figure which shows the format about the data packet of the client / server by one Embodiment of this invention. [Fig. 11]

It is a figure which shows the format about the data packet of a client / server by one Embodiment of this invention in more detail. [Fig. 12]

It is a figure which shows the payload structure about the data packet by one Embodiment of this invention. [Fig. 13]

It is a figure which shows the payload structure about the command packet by one Embodiment of this invention. [Fig. 14]

It is a figure which shows the exemplary payload structure of the Connection Agreement for the command packet by one Embodiment of this invention. [Fig. 15]

It is a figure which shows the exemplary structure of the Add Subclient for the command packet by one Embodiment of this invention. [Fig. 16]

It is a figure which shows the format of the data transmission packet by one Embodiment of this invention. [Fig. 17]

It is a figure which shows the exemplary structure of the Connection Request command packet by one Embodiment of this invention. [Fig. 18]

It is a state diagram which shows the process of inserting a subclient into a subnet online according to one Embodiment of this invention.