WO2001056228A2 - Stream connection management in wireless computer networks - Google Patents

Abstract

Communications between two or more network components are managed at the network data link layer level to facilitate transmitting multimedia stream data between said network components. The network data link layer includes a medium access control (MAC) protocol defining the multimedia stream communication management. In this context, managing the communications includes setting up and/or tearing down a stream data connection (which may be unidirectional or bi-directional) between said network components. Such communication may occur via a wireless communication link between the network components and this link may support radio frequency, direct sequence spread spectrum or other frequency hopping communication techniques. In other cases, infra-red frequency communications may be used. The network components preferably include a MAC level connection manager. This connection manager may include a control layer and a channel interface layer and may be responsible for managing the stream data connections.

Description

STREAM CONNECTION MANAGEMENT IN WIRELESS COMPUTER

NETWORKS

RELATED APPLICATION

The present application is related to and hereby claims the priority benefit of US Provisional Application No. 60/178,225, entitled "Stream Connection Management in Wireless Computer Networks" filed January 25, 2000, by Rajugopal R. Gubbi and Donnia Sebastian.

FIELD OF THE INVENTION

The present invention relates generally to a scheme for communications within a computer network and, in particular, to such communications as occur between nodes in such a network across a wireless link.

BACKGROUND

Modern computer networks allow for inter-communication between a number of nodes such as personal computers, workstations, peripheral units and the like. Network links transport information between these nodes, which may sometimes be separated by large distances. However, to date most computer networks have relied on wired links to transport this information. Where wireless links are used, they have typically been components of a very large network, such as a wide area network, which may employ satellite communication links to interconnect network nodes separated by very large distances. In such cases, the transmission protocols used across the wireless links have generally been established by the service entities carrying the data being transmitted, for example, telephone companies and other service providers.

In the home environment, computers have traditionally been used as stand-alone devices. More recently, however, there have been some steps taken to integrate the home computer with other appliances. For example, in so-called "Smart Homes", computers may be used to turn on and off various appliances and to control their operational settings. In such systems, wired communication links are used to interconnect the computer to the appliances that it will control. Such wired links are expensive to install, especially where they are added after the original construction of the home. In an effort to reduce the difficulties and costs associated with wired communication links, some systems for interconnecting computers with appliances have utilized analog wireless links for transporting information between these units. Such analog wireless links operate at frequencies commonly utilized by wireless telephones.

Although easier to install than conventional wired communication links, analog wireless communication links suffer from a number of disadvantages. For example, degraded signals may be expected on such links because of multipath interference. Further, interference from existing appliances, such as televisions, cellular telephones, wireless telephones and the like, may be experienced. Thus, analog wireless communication links offer less than optimum performance for a home environment.

In a co-pending application, Serial No. 09/151,579, which is assigned to the assignee of the present application and is incorporated herein by reference, a computer network employing a digital wireless communication link adapted for use in the home and other environments was described. The architecture of that network (referred to in the previously cited provisional application as a "Whitecap" network) included a number of network components arranged in a hierarchical fashion and communicatively coupled to one another through communication links operative at different levels of the hierarchy. At the highest level of the hierarchy, a communication protocol that supports dynamic addition of new network components at any level of the hierarchy according to bandwidth requirements within a communication channel operative at the highest level of the network hierarchy is used.

The generalization of this network structure is shown in Figure 1. A 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 several clients associated therewith (e.g., coupled through the wireless communication link). Depending on the context of the discussion however, a subnet may also refer to a network that includes a client and one or more subclients associated therewith. A "client" is a network node linked to the server through the 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 household appliances.

Server 12 may be a separate computer that controls the communication link, however, in other cases server 12 may be embodied as an add-on card or other component attached to a host computer (e.g., a personal computer) 13. Server 12 has an associated radio 14, which is used to couple server 12 wirelessly to the other nodes of subnet 10. The wireless link generally supports both high and low bandwidth data channels and a command channel. Here a channel is defined as the combination of a transmission frequency (more properly a transmission frequency band) and a pseudorandom (PN) code used in a spread spectrum communication scheme. In general, a number of available frequencies and PN codes may provide a number of available channels within subnet 10. As is described in the co-pending application cited above, servers and clients are capable of searching through the available channels to find a desirable channel over which to communicate with one another.

Also included in subnet 10 are a number of clients 16, some of which have shadow clients 18 associated therewith. A shadow client 18 is defined as a client which receives the same data input as its associated client 16 (either from server 12 or another client 16), but which exchanges commands with server 12 independently of its associated client 16. Each client 16 has an associated radio 14, which is used to communicate with server 12, and some clients 16 may have associated subclients 20. Subclients 20 may include keyboards, joysticks, remote control devices, multidimensional input devices, cursor control devices, display units and/or other input and/or output devices associated with a particular client 16. A client 16 and its associated subclients 20 may communicate with one another via communication links 21, which may be wireless (e.g., infra-red, ultrasonic, spread spectrum, etc.) communication links.

Each subnet 10 is arranged in a hierarchical fashion with various levels of the hierarchy corresponding to levels at which intra-network component communication occurs. At a highest level of the hierarchy exists the server 12 (and/or its associated host 13), which communicates with various clients 16 via the wireless radio channel. At other, lower levels of the hierarchy the clients 16 communicate with their various subclients 20 using communication links 21, for example, wired communication links or wireless communication links such as infrared links.

Where half-duplex radio communication is used on the wireless link between server 12 and clients 16, a communication protocol based on a slotted link structure with dynamic slot assignment is employed. Such a structure supports point-to-point connections within subnet 10 and slot sizes may be re-negotiated within a session. Thus a data link layer that supports the wireless communication can accommodate data packet handling, time management for packet transmission and slot synchronization, error correction coding (ECC), channel parameter measurement and channel switching.

A higher level transport layer provides all necessary connection related services, policing for bandwidth utilization, low bandwidth data handling, data broadcast and, optionally, data encryption. The transport layer also allocates bandwidth to each client

16, continuously polices any under or over utilization of that bandwidth, and also accommodates any bandwidth renegotiations, as may be required whenever a new client

16 comes on-line or when one of the clients 16 (or an associated subclient 20) requires greater bandwidth.

The slotted link structure of the wireless communication protocol for the transmission of real time, multimedia data (e.g., as frames) within a subnet 10 is shown in Figure 2. At the highest level within a channel, forward (F) and backward or reverse (B) slots of fixed (but negotiable) time duration are provided within each frame transmission period. During forward time slots F, server 12 may transmit video and/or audio data and/or commands to clients 16, which are placed in a listening mode. During reverse time slots B, server 12 listens to transmissions from the clients 16. Such transmissions may include audio, video or other data and/or commands from a client 16 or an associated subclient 20. At the second level of the hierarchy, each transmission slot (forward or reverse) is made up of one or more radio data frames 40 of variable length. Finally, at the lowest level of the hierarchy, each radio data frame 40 is comprised of server/client data packets 42, which may be of variable length.

Each radio data frame 40 is made up of one server/client data packet 42 and its associated error correction coding (ECC) bits. Nariable length framing is preferred over constant length framing in order to allow smaller frame lengths during severe channel conditions and vice-versa. This adds to channel robustness and bandwidth savings. Although variable length frames may be used, however, the ECC block lengths are preferably fixed. Hence, whenever the data packet length is less than the ECC block length, the ECC block may be truncated (e.g., using conventional virtual zero techniques). Similar procedures may be adopted for the last block of ECC bits when the data packet is larger.

As shown in the illustration, each radio data frame 40 includes a preamble 44, which is used to synchronize pseudo-random (PΝ) generators of the transmitter and the receiver. Link DD 46 is a field of fixed length (e.g., 16 bits long for one embodiment), and is unique to the link, thus identifying a particular subnet 10. Data from the server 12/client 16 is of variable length as indicated by a length field 48. Cyclic redundancy check (CRC) bits 50 may be used for error detection/correction in the conventional fashion.

For the illustrated embodiment then, each frame 52 is divided into a forward slot F, a backward slot B, a quiet slot Q and a number of radio turn around slots T. Slot F is meant for server 12-to-clients 16 communication. Slot B is time shared among a number of mini-slots Bi, B2, etc., which are assigned by server 12 to the individual clients 16 for their respective transmissions to the server 12. Each mini-slot Bi, B2, etc. includes a time for transmitting audio, video, voice, lossy data (i.e., data that may be encoded/decoded using lossy techniques or that can tolerate the loss of some packets during transmission/ reception), lossless data (i.e., data that is encoded/decoded using lossless techniques or that cannot tolerate the loss of any packets during transmission/reception), low bandwidth data and/or command (Cmd.) packets. Slot Q is left quiet so that a new client may insert a request packet when the new client seeks to login to the subnet 10. Slots T appear between any change from transmit to receive and vice-versa, and are meant to accommodate individual radios' turn around time (i.e., the time when a half-duplex radio 14 switches from transmit to receive operation or vice- versa). The time duration of each of these slots and mini-slots may be dynamically altered through renegotiations between the server 12 and the clients 16 so as to achieve the best possible bandwidth utilization for the channel. Note that where full duplex radios are employed, each directional slot (i.e., F and B) may be full-time in one direction, with no radio turn around slots required.

Forward and backward bandwidth allocation depends on the data handled by the clients 16. If a client 16 is a video consumer, for example a television, then a large forward bandwidth is allocated for that client. Similarly if a client 16 is a video generator, for example a video camcorder, then a large reverse bandwidth is allocated to that particular client. The server 12 maintains a dynamic table (e.g., in memory at server 12 or host 13), which includes forward and backward bandwidth requirements of all on-line clients 16. This information may be used when determining whether a new connection may be granted to a new client. For example, if a new client 16 requires more than the available bandwidth in either direction, server 12 may reject the connection request. The bandwidth requirement (or allocation) information may also be used in deciding how many radio packets a particular client 16 needs to wait before starting to transmit its packets to the server 12. Additionally, whenever the channel conditions change, it is possible to increase/reduce the number of ECC bits to cope with the new channel conditions. Hence, depending on whether the information rate at the source is altered, it may require a dynamic change to the forward and backward bandwidth allocation.

SUMMARY OF THE INVENTION

In one embodiment, communications between two or more network components are managed at the network data link layer level to facilitate transmitting multimedia stream data between said network components. The network data link layer includes a medium access control (MAC) protocol defining the multimedia stream communication management. In this context, managing the communications includes setting up and/or tearing down a stream data connection (which may be unidirectional or bi-directional) between said network components. Such communication may occur via a wireless communication link between the network components and this link may support radio frequency, direct sequence spread spectrum or other frequency hopping communication techniques. In other cases, infra-red frequency communications may be used. The network components preferably include a MAC level connection manager. This connection manager may include a control layer and a channel interface layer and may be responsible for managing the stream data connections.

In a further embodiment, a network interface includes a connection manager that manages stream data connections at a network data link layer level. This interface may include a wireless communication device.

Another embodiment provides a system that includes a network interface, the network interface (which may include a wireless communication device) including a connection manager that manages stream data connections at a network data link layer level.

A further embodiment provides a machine-readable medium (e.g., a memory or other medium) that provides instructions, which when executed by a machine, cause said machine to manage communications at a network data link layer level between said machine and one or more other machines in a computer network such that a stream data connection is established between said machines.

In any or all of the above embodiments, the connection manager associated with a network component establishes connections with applications associated with the same network component to provide stream data from other network components to such applications. The connections between connection manager and applications may be established with a set of application interface commands and messages. Examples of such application interface commands and messages include one or more of the following:

WC_Listen_Bind, WCJListenJUnbind, WC_Connect_Request,

WC_Connect_Indication, WC_Connect_Response,

WC_Connect_Confirm, WC_Disconnect_Request,

WC_Disconnect_Indication, WC_Disconnect_Response, or

WC_Di sconnect_Conf irm.

In general, the application registers with the connection manager such that a unique identifier is associated to said application. Then, the application may issue requests to the connection manager for a stream connection by providing its registered identifier and a data type for the data stream requested. The connection manager associated with a network component establishes stream data connections with one or more other connection managers associated with one or more other network components in response to such requests and the connections between connection managers are established with a set of stream commands, which may include one or more of the following commands: a stream connection request, a stream connection acceptance, a stream connection abort, a stream connection complete, a stream disconnection request, and a stream disconnection complete.

Parameters for the transmission of multimedia stream data may be dynamically negotiated for each stream communicated between network components. Such transmission parameters may include one or more of the following: a rate of data traffic across the network, a maximum tolerable delay, a maximum retransmission delay, a maximum burst size, a priority of the stream, a delay variation, and an average packet length. Priorities of the stream may be set, including isochronous stream priority, high stream priority, medium stream priority and low stream priority. Low priority streams may be transported over the network on a best effort service.

These and other features and advantages of the present invention will be apparent from a review of the detailed description and its accompanying drawings that follow.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not limitation, in the figures of the accompanying drawings in which:

Figure 1 illustrates a generalized network structure that is supported by a wireless communication protocol configured in accordance with an embodiment of the present invention;

Figure 2 illustrates a hierarchical arrangement for the transmission of data and control information within a subnet according to one embodiment of the present invention;

Figure 3 illustrates a set of application interface messages which may be passed between nodes of a computer network in accordance with one embodiment of the present invention;

Figure 4 illustrates a structure of connection managers according to one embodiment of the present invention;

Figure 5 illustrates a example of a connection setup process in accordance with one embodiment of the present invention;

Figure 6 illustrates a example of a connection tear down process in accordance with one embodiment of the present invention;

Figure 7 illustrates an example of a channel interface layer header in accordance with one embodiment of the present invention;

Figure 8 illustrates an example of a format for STREAM_QOS_P ARAMS messages in accordance with one embodiment of the present invention;

Figure 9 illustrates an example of a format for CONNECT_REQUEST messages in accordance with one embodiment of the present invention;

Figure 10 illustrates an example of a format for CONNECTJNDICATION messages according to one embodiment of the present invention; Figure 11 illustrates an example of a format for CONNECT_RESPONSE messages in accordance with one embodiment of the present invention;

Figure 12 illustrates an example of a format for CONNECT_CONFIRM messages in accordance with one embodiment of the present invention;

Figure 13 illustrates an example of a format for DISCONNECT_REQUEST messages in accordance with one embodiment of the present invention;

Figure 14 illustrates an example of a format for DISCONNECT_INDICATION messages in accordance with one embodiment of the present invention;

Figure 15 illustrates an example of a format for LISTEN_BIND messages in accordance with one embodiment of the present invention;

Figure 16 illustrates an example of a format for LISTEN_UNBT_ND messages according to one embodiment of the present invention;

Figure 17 illustrates an example of a format for SINK_TO_SOURCE_P ARAMS messages in accordance with one embodiment of the present invention;

Figure 18 illustrates an example of a format for SOURCE_TO_SINK_P ARAMS messages in accordance with one embodiment of the present invention;

Figure 19 illustrates an example of a format for STREAM_CONNECTION_ REQUESTS messages for source streams in accordance with one embodiment of the present invention;

Figure 20 illustrates an example of a format for STREAM_CONNECTION_ REQUEST messages for sink streams in accordance with one embodiment of the present invention;

Figure 21 illustrates an example of a format for STREAM_CONNECTION_ REQUEST messages for bi-directional streams in accordance with one embodiment of the present invention;

Figure 22 illustrates an example of a format for STREAM_CONNECTION_ ACCEPT messages for source streams according to one embodiment of the present invention;

Figure 23 illustrates an example of a format for STREAM_CONNECTION_ ACCEPT messages for sink streams in accordance with one embodiment of the present invention; Figure 24 illustrates an example of a format for STREAM_CONNECTION_

ACCEPT messages for bi-directional streams in accordance with one embodiment of the present invention;

Figure 25 illustrates an example of a format for STREAM_CONNECTION_ COMPLETE messages in accordance with one embodiment of the present invention;

Figure 26 illustrates an example of a format for STREAM_CONNECTION_ ABORT messages in accordance with one embodiment of the present invention;

Figure 27 illustrates an example of a format for STREAM_DIS CONNECT messages in accordance with one embodiment of the present invention;

Figure 28 illustrates an example of a format for node handshaking messages in accordance with one embodiment of the present invention; and

Figure 29 illustrates an example of a format for acknowledgement messages in accordance with one embodiment of the present invention.

DETAILED DESCRIPTION 1. Introduction

Described herein is scheme for stream connection management within a wireless computer network. In particular, a connection establishment mechanism, which operates at the network/data link layers of such networks, is discussed. The present scheme is generally applicable to a variety of wireless network environments, but finds especially useful application in a computer network which is located in a home environment. Thus, in some cases the present scheme may be discussed with reference to the particular aspects of a home environment. However, this discussion should in no way be seen to limit the applicability of the present invention to other network environments and the broader spirit and scope of the present invention is recited in the claims which follow this discussion.

Some portions of the detailed description that follows are presented in terms of algorithms and symbolic representations of operations on data within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the computer science arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers or the like. It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise, it will be appreciated that throughout the description of the present invention, use of terms such as

"processing", "computing, "calculating", "determining", "displaying", "passing" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical

(electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

In the present scheme, each node is preferably configured with a connection manager (i.e., a set of computer readable instructions and any associated data structures and/or computer hardware that provide the functionality described herein), which is responsible for setting up and tearing down network stream connections. As discussed above, in one embodiment of the network architecture, it is the master node (or server) that keeps track of bandwidth allocation and scheduling. Hence, for connection establishment between two client nodes, the master node needs to be informed of the stream connection status and characteristics. Two possible approaches for satisfying this requirement are:

1) Forwarding every connection setup request to master node, and having the master node establish the connections between the clients.

2) Having the connection-initiating node coordinate the process with the master node, but allowing the peer node (i.e., the other client node) to setup the connection.

One drawback of the first approach is that the connection establishment time would be prolonged. Moreover, an additional load is imposed on the master node. Hence, the second approach is preferably adopted. In this approach, the master node is involved in the connection setup process between two client nodes only if the new connection is an isochronous stream or if the currently available bandwidth at the client nodes is not sufficient to accommodate the new connection. 2. Application Interface

The present connection establishment mechanism provides a client-server model for applications/modules to connect across a wireless computer network. Any module wishing to accept network stream connections should register with the connection manager of its node, specifying its Endpoint Identifier (EndPtID). Thereafter, a "user" (e.g., an application or module) requesting a stream connection should specify the destination node and the EndPtID of the module it wishes to connect to. It can also provide its Endpoint Reference information, which should be passed along to the destination node.

Note that the EndPtld should be well known and is used to uniquely identify a registered service endpoint. This is similar to the well-known TCP server port numbers, but different in that it is not a part of a traffic header. When the connection is established, a stream identifier (ID) gets allocated for the connection and the stream ID may be used for routing the packets on the connection. The user modules may then use the stream ID to exchange any control information and data.

In one embodiment of the present scheme, a stream is unidirectional and the two ends of the stream are referred to as the source (transmit) and sink (receive) ends hereafter. However, the present connection setup process also allows for the creation of a "bi-directional connection", which essentially results in the creation of two streams (one for transmit and another for receive).

2.1 Listening for Connections

Any module wishing to listen for incoming connections must first bind with its respective connection manager. This may be done by sending a WC_Listen_Bind message to the connection manager. In such messages, the user module should specify the endpoint ID which it wants to listen to and the packet type of connections it will accept. Once the bind is successfully completed, any incoming connection request with the designated endpoint ID and packet type will be forwarded to the requesting user module.

A WCJListenJQnbind message may be sent to the connection manager when a user module wants to stop listening for any more incoming connection requests. All existing connections accepted by this endpoint should remain unaffected. Refer to Section 5.2 below for discussion of a detailed format of the WC_Listen_Bind and WCJ isten Unbind messages. 2.2 Connection Setup

The following messages may be exchanged between a user module and a connection manager for a stream connection setup. These messages are similar to the LLC primitives used for connection-oriented services specified in standards document 802.11 for Wireless Local Area Networks promulgated by the Institute for Electrical and Electronic Engineers June 26, 1997, with subsequent revisions thereafter. Figure 3 illustrates the connection setup procedure.

In the example shown in the illustration, a user module of node A 54 will connect with a similar module at node B 56 across wireless communication link 58. In the example, the user modules are audio managers 60 and 64, and the two modules interact with one another through connection managers 62 and 64 associated with their respective nodes. It should be understood that these various modules are software programs running on the node platforms.

2.2.1 WC_Connect_Request

User module 60 initiates the connection creation process by sending a WC_Connect_Request 68 to its associated connection manager 62. In this request, the user module should specify the required stream characteristics, endpoint reference, etc. Thus, fields for the connection request include:

1) Destination Node ID

2) EndPtld at the destination

3) Packet Type

4) Stream characteristics

• Throughput (Bandwidth for forward and reverse directions - bytes/sec, packets/sec, etc.)

• Maximum tolerable delay

• Retransmission required or not. If required, maximum retransmission delay.

• Delay variation

• Maximum burst size

5) EndPoint Reference - This field is used for communication between peer user modules. The connection manager does not examine/parse this field, but passes it to the user module • at the other end. For example, if the user module is an IP data manager trying to set up a stream for a TCP/IP connection, the user module could specify the TCP protocol ID and port number as the EndPoint Reference. Note that another way of doing this is to send this to the peer as control information on the stream, once the stream is created. However, this would extend the complete connection setup time.

Refer to Section 5.2.1 below for detailed format of this message.

2.2.2 WC_Connect_Indication

The connection managers 62 and 66 for both nodes check to see if network resources are available to support the new connection. If no user module is registered with the connection manager at the destination node (connection manager 66 in the illustration), with the requested EndPtld, the connection setup is aborted.

If resources are available and the connection managers decide to allow the new connection, a WC_Connect Indication message 70 is passed to the user module 64 at destination node .56. This message includes all stream characteristics requested by the user module 60 at the initiating node 54 as well as any endpoint information passed by the initiating node. The format of this message is discussed in detail in Section 5.2.2 below.

2.2.3 WC_Connect_Response

If the stream parameters are acceptable to the user module 64 at destination node 56, that user module responds with a WC_Connect_Confirm message 72. If the user module at the destination node decides not to accept the connection, a WC_Disconnect_ Request message (not shown) is send instead and the connection setup process is aborted. If the connection is to be accepted, the destination user module 64 can also specify its callback routines for data handling in this message. Section 5.2.3 describes the relevant message format in detail.

2.2.4 WC_Connect_Confirm

If the destination node 56 has accepted the connection and network resources are allocated on both nodes, the user module 60 at initiating node 54 will receive a WC_ Connect_Confirm message 74 from its connection manager 62 (such a message having been passed from the connection manager 66 at the destination node 56 over the wireless communication link 58). This message indicates that the connection setup process is complete and traffic can be sent on the specified stream. Section 5.2.4 below describes the message format in detail.

2.3 Disconnection

The disconnection procedure is similar to the connection setup procedure. The following messages exchanged between the user modules and connection managers for tearing down an existing connection. Section 5.2 describes exemplary formats of all disconnection messages in detail.

2.3.1 WC_Disconnect_Request

This message is sent by a user module to its connection manager to tear down an existing connection. It is expected that the user module will have stopped all of its data transmissions before sending this message. On receiving this message, a connection manager flushes out any queued transmit packets and deactivates the transmission stream. It then informs the peer node about the disconnection and waits for a response from the peer node before deactivating the reception stream and releasing the connection resources.

2.3.2 WC_Disconnect_Indication

This message is sent by a connection manager to a user module to notify the module that a connection is to be deleted. Many causes for a disconnection might exist, for example lack of resources or timeouts or an explicit disconnection request from a peer node.

2.3.3 WC_Disconnect_Response

This message is sent by a user module to a connection manager as a response to a disconnect indication message. The connection manager will wait for this user module response before releasing the connection's allocated resources. 2.3.4 WC_Disconnect_Confirm

This message is sent by a connection manager to a user module as a confirmation that a disconnect request was completed. This indicates that the connection deletion process is complete and no more packets will be transmitted or received on the streams.

3. Connection Manager

The upper layer interfaces of the connection managers and user modules have been discussed in the previous section. This section discusses how the connection managers coordinate with one another to setup/tear down a stream connection.

As shown in Figure 4, each connection manager 80 consists of two layers:

1) an upper 'control' layer 82 which implements the connection establishment protocol; and ^l

2) a lower 'channel interface' layer 84 which guarantees that every control message gets delivered to a peer node.

The purpose of the lower layer 84 is to provide means for a reliable delivery of all upper control layer messages. The complexity of this layer depends on the mechanism used to relay the connection messages. If a reliable network reserved stream is used, this layer will be very thin. If command packets are used to send the connection messages, this layer makes sure that the messages gets delivered, once and only once.

The upper control layer 82 implements the connection establishment protocol. A stream, by default, is unidirectional (either TX(source) or RX(sink)). A bi-directional connection implies two streams, a source stream and a sink stream.

3.1 Control Layer

3.1.1 Stream Connection Setup

The connection setup procedure is discussed with reference to Figure 5. Assume a wireless computer network where Node A is the master and Nodes B & C are client nodes. Assume Node B wants to establish a connection with Node C. The connection setup procedure remains the same, regardless of whether the setup request is for a TX stream or an RX stream or a bi-directional connection. Section 5.3 describes the various formats for the commands discussed below in detail. 3.1.1.1 STREAM_CONN_REQUEST

A connection manager 80 at Node B, upon receiving a user request 86 to create a connection, allocates the necessary local resources and forwards the request to the peer node using a STREAM_CONN_REQUEST command 88. This command indicates whether the request is for a transmit stream or receive stream or both. This command also indicates the desired stream characteristics. This may include stream quality of service (QOS) requirements specified by the user and also those parameters specified by the connection-initiating node.

With any connection request, there are certain parameters dictated by the source end of stream and certain others specified by the sink end of stream. The source end of stream always allocates the stream ID whereas the resources at the sink end of stream restrict the window size. The connection-initiating node includes these 'source-to-sink' and 'sink-to-source' parameters in the STREAM_CONN_REQUEST command 88, in addition to the requested QOS parameters.

For example if Node B's request is for a stream with Node B as the sink and Node C as the source, the relevant STREAM_CONN_REQUEST will specify all 'sink- to-source' parameters. If Node B's request is for a stream with Node B as the source and Node C as the sink, then the STREAM_CONN_REQUEST will specify all 'source- to-sink' parameters. If the request is for a bi-directional connection, the STREAM_CONN_ REQUEST will include both 'source-to-sink' and 'sink-to-source' parameters.

3.1.1.2 STREAM_CONN_ACCEPT / STREAM_CONN ABORT

A connection manager 80 at node C, upon receiving a STREAM_CONN_ REQUEST, looks up the listening endpoint specified in the command. If the endpoint exists, the corresponding user module is notified of the incoming connection request.

The user module may either accept or reject the incoming connection request. If it decides to accept the connection, the connection manager at Node C allocates the resources required and notifies the Node B connection manager using a STREAM_CONN_ACCEPT command 90. But if the connection request is rejected by user module at node C or if local resources are not available, Node C terminates the connection setup process by sending a STREAM_CONN_ABORT command to Node B (not shown). Based on the type of connection, the STREAM_CONN_ACCEPT command will include the 'source-to-sink' and 'sink-to-source' parameters. Refer to Section 5.3.3 below for the format of this command.

3.1.1.3 STREAM_CONN_COMPLETE

Once a STREAM_CONN_ACCEPT command has been sent and received, both nodes move on to the final stage of the connection establishment process. This stage involves getting the channel bandwidth for the connection from the respective DBM 92. The node at the source end of stream performs the negotiation with its respective DBM 92. If the DBM 92 determines that it has sufficient local allocated bandwidth to accommodate the new connection, the bandwidth is allocated locally. If not, the local DBM 92 negotiates with master DBM 94 for the needed additional bandwidth.

If the bandwidth allocation process is successful, a STREAM_CONN_COMPLETE command 96 is sent to the sink end of stream. Note that for a bi-directional connection, this command would be send by both the peer nodes (as shown in the illustration) as each would have a source stream. If the bandwidth allocation fails, the connection setup process is aborted and a STREAM_CONN_ABORT command is transmitted to the peer node (not shown).

3.1.2 Stream Disconnection

The disconnection mechanism is similar, but simpler. The disconnection mechanism should synchronize both ends so that the connection resources are released at both ends and any data packets in transition are not lost.

3.1.2.1 STREAM_DISCONN_REQUEST

As shown in Figure 6, upon receiving a disconnection request 98 from a user module, the connection manager 80 in Node B initiates the disconnection procedures. If Node B has a source stream, all the packets queued up on the stream for transmission are flushed and the stream is deactivated. The sink stream, if it exists, is not disturbed. Node B informs the peer node (Node C) about the disconnection by sending a STREAM_ DISCONN_REQUEST command 100.

3.1.2.2 STREAM_DISCONN_COMPLETE

When Node C receives the STREAM_DISCONNECT_REQUEST 100 it notifies its user module of the disconnection request. On receiving a response from the user module, the connection manager 80 at Node C sends a STREAM_DISCONN_

COMPLETE message 102 to Node B and deletes the source/sink stream associated with the connection.

On receiving the STREAM_DISCONNECT_COMPLETE message 102, the connection manager 80 at Node B deletes the source/sink streams associated with the connection and informs its associated user module that the disconnect operation is complete. Though the resources allocated for the connection are released, the EndPtld and Stream ED associated with the connection should be reused only after a specified time has elapsed.

3.2 Channel Intel face layer

The channel interface layer is responsible for reliable delivery of commands given by the control layer. This layer uses command packets for transmission of connection commands to peer nodes.

The channel interface layer adds a 1-byte header 104, shown in Figure 7, to every connection command received from the control layer. The header 104 consists of a 7-bit sequence number 106, which is maintained for every peer node and incremented when a new command is send to the node.

An acknowledgement (ACK) bit 108 indicates if this is a connection command or an acknowledgement for the connection command. When the channel interface layer receives a connection command (ACK bit set to 0), it immediately sends an acknowledgement to the peer node. The acknowledgement command consists of just the 1-byte channel interface header 104, with the ACK bit set to 1.

The channel interface layer makes use of a 'repeat' feature provided by the command manager to accomplish reliable delivery of connection commands. When it receives a new command from the control layer, the channel interface layer adds its header and sets the command with the command manager, also specifying the number of network frames over which the command is to be repeated. This 'repeat count' directly relates to a timeout for the command response at the control layer and is specified by control layer. The channel interface layer also maintains a mapping of the sequence number and the command handle returned by command manager in response to these actions.

When a peer node responds with an acknowledgement packet, the channel interface layer looks up the command handle based on the sequence number acknowledged, and instructs the command manager to delete this command from its 'repeat list'. If no acknowledgement is received, the command will be automatically deleted by the command manager after it has been transmitted for the specified number of network frames.

The above mechanism works best when the round-trip time is less than one network frame time. If the round-trip time is two network frames or more, duplicate commands would be received. The channel interface layer maintains the sequencing information required to identify such duplicate commands and also delivers the commands to the control layer in sequence, regardless of the order in which they were received.

The channel interface layer also defines two subcommands, which are used for handshake procedures with peer nodes. When a node is informed (e.g., via a login process) that a new node has joined the network, a 'HANDSHAKE_INITIATE' command is sent to the new node. The new node responds with a "HANDSHAKE_ACK" command. Only after this initial handshaking is complete will a connection manager will allow connections to be setup to the new node. The purpose of this handshake procedure is two-fold:

1) It ascertains that the new node is accessible for setting up connections.

2) If an existing node is suddenly restarted (without any disconnection messages), the handshake procedure allows other nodes to release their stale connections and re-establish new connections to that node.

4. Translation of stream parameters

The following Table 1 describes how stream parameters are translated:

Table 1

(1) Bmax - Maximum total radio receive buffers required

N - Maximum number of packets that can be received in a slot RTD - Round Trip Delay (in slots)

Bmax >= N * 2 * RTD

Assuming that a lost packet can be recovered in RTD slots retransmission, there should be sufficient buffer space to hold all the packets received in 2*RTD slots. This should guarantee that the window size will not be exceeded and traffic disrupted.

Be - Buffers allocated for a connection

Cmax - Maximum number of packets/slot for the connection Cav - Average number of packets/slot for the connection.

Be >= MAX (Cmax * RTD, Cav * 2* RTD)

The minimum requirement would be to have a sufficient number of buffers to hold all the packets sent before the transmit node realizes that a packet have been lost (i.e., in RTD slots). But if the window size is reached, further transmissions would have to be blocked and this would bring down the throughput. The larger the number of buffers available, the larger the window size and the lesser the chance of blocking transmissions.

5. Command Formats

This section describes the formats of all application interface messages and network commands used by a connection manager. Little endian format is implied, unless otherwise stated.

5.1 QOS parameters

The structure of packet 110, illustrated in Figure 8, defines the stream quality of service (QOS) parameters. This structure may be used in all application interface messages, as well as network commands, to specify stream QOS characteristics.

BYTES 0-3: Minimum rate - Minimum bandwidth required for stream, in bytes/sec. BYTES 4-7: Maximum rate - Maximum bandwidth required for stream, in bytes/sec. BYTES 8-11: Average rate - Average bandwidth utilized by stream, in bytes/sec.

(optional) BYTES 12-13: Average Packet Length - Average length of packets in the stream, in bytes.

BYTES 14-15: Maximum Tolerable Delay - The maximum delay tolerable for packets in the stream, in msecs. This value defines the scheduling frequency for the stream. BYTES 16-17: Maximum Burst Size - The maximum size of data burst, in bytes. BYTES 18-19: Delay Variation - The maximum variation in delay that can be tolerated, in msecs. BYTE 20:

BITS 0,1: Priority - The priority of the stream(s) requested. Exemplary values are:

00 - ISOCHRONOUS 01 - HIGH

10 - MEDIUM 11 - LOW (Best effort)

BIT 2: ReTx Flag - This field is set if retransmission is to be enabled. BYTES 21-23: Reserved. BYTES 24-27: Maximum Retransmission Delay - The maximum time period (in msecs) for which retransmission are to be attempted.

5.2 Application Interface Messages

This section describes the format of all messages exchanged on a connection manager's application interface.

5.2.1 WC_Connect_Request

This is the request issued by a user module to the connection manager to create a stream connection. An example of a packet format 112 is shown in Figure 9. BYTE 0: ConnMsg - Set to OxOC for CONNECT_REQUEST message. BYTE 1: NodeE) - The Node ID for the remote node to which the connection is requested.

BYTE 2: Pkt Type - The packet type for the new connection. BYTE 3: Conn Type - The type of connection requested for. Exemplary values are:

0x01 - Source stream alone 0x02 - Sink stream alone

0x03 - Bi-directional connection (source & sink streams) BYTES 4 - 5: Listen EndPtID - The endpoint identification of the listening entity at the remote node. BYTES 6 - 7: Reserved.

BYTES 8 - 11: Local EndPt Information - This field is passed transparently to the listening entity at the peer node. BYTES 12 - 39: SOURCE STREAM QOS PARAMS - The QOS parameters for the source stream, if the connection type requested contains source stream.

The fields of this structure are as defined in Section 5.1. BYTES 40 - 67: SINK STREAM QOS PARAMS - The QOS parameters for the sink stream, if the connection type requested contains sink stream. The fields of this structure are as defined in Section 5.1. BYTES 68 - 71: ConnMsg Update Function Pointer - This should be set to the function which is to handle all messages from the connection manager for this connection.

BYTES 72 - 75: ConnMsg Update Function Param - This value is passed as a parameter when the above function is called to deliver messages from the connection manager.

BYTES 76 - 91 : These are the functions for handling data packets on the stream, once the connection setup is complete. Only the required parameters need be set, based on whether the setup request is for a source stream, sink stream or both.

Transmit Poll Function - The function to be polled for transmit packets on the stream.

Transmit Poll Function Parameter - The parameter to be passed for the above function.

Transmit Packet Release Function - The function to be called for releasing packets transmitted on the source stream.

Receive Packet Input Function - The function to be called to deliver packets that are received.

5.2.2 WC_Connect_Indication

The is the message passed by a connection manager to the listening entity, to inform that entity (i.e., a user module) about a new incoming connection request. The packet format 114 is shown in Figure 10.

BYTE 0: ConnMsg - Set to 0x10 for CONNECTJNDICATION message. BYTE 1: NodelD - The Node ID of the remote node that initiated the connection. BYTE 2: Pkt Type - The packet type for the new connection. BYTE 3: Conn Type - The type of connection requested. Exemplary values are:

0x01 - Source stream alone

0x02 - Sink stream alone

0x03 - Bi-directional connection (source & sink streams) BYTE 4: TX Stream ID - The transmit stream id, if connection consists of a source stream.

BYTE 5: RX Stream ID - The receive stream id, if connection consists of a sink stream.

BYTES 6 - 7: Reserved.

BYTES 8 - 9: Listen EndPtID - The endpoint identification of the listening entity to which the connection is assigned. BYTES 10 - 11: Local EndPtED - The new transient endpoint id allocated for the listening entity to accept the connection. BYTES 12 - 15: Remote EndPt Information - The information passed on by the remote endpoint requesting the connection. BYTES 16 - 43: SOURCE STREAM QOS PARAMS - The QOS parameters for the source stream, if the connection type requested contains source stream.

The fields of this structure are as defined in Section 5.1. BYTES 44 - 71: SINK STREAM QOS PARAMS - The QOS parameters for the sink stream, if the connection type requested contains sink stream. The fields of this structure are as defined in Section 5.1.

5.2.3 WC_Connect_Response

A user module sends this message to its connection manager as a response to a WC_Connect_Indication message. The packet format 116 is shown in Figure 11. BYTES 0 - 7: Same as for a CONNECT NDICATION message; refer section 5.2.2. The

ConnMsg should be set to OxOD for a CONNECT_RESPONSE message. BYTES 8 - 11: Local EndPt Information - This would be passed transparently to the user module at the remote node which requested this connection. BYTES 12 - 27: These fields specify the callback routines for transmit and receive handling of packets in the stream. Refer to Section 5.2.1

(CONNECT_REQUEST message) for a detailed description. 5.2.4 WC_Connect_Confirm

This message is send by a connection manager to its user module when the connection setup is completed and the streams are activated. The packet format 118 is shown in Figure 12. BYTES 0 - 5: Same as for a CONNECTJNDICATION message; refer to section 5.2.2.

The ConnMsg should be set to 0x11 for CONNECT_CONFIRM message. BYTES 6 - 7: Local EndPtlD - The identification for the local endpoint, allocated when connection creation was initiated. BYTES 8 - 11: Remote EndPt Information - The information passed on by the remote endpoint accepting the connection.

5.2.5 WC_Disconnect_Request

This message is send by a user module to a connection manager to tear down an existing connection. The packet format 120 is shown in Figure 13. BYTES 0 - 5: Same as for a CONNECTJNDICATION message; refer to section 5.2.2.

The ConnMsg should be set to OxOE for DISCONNECTJREQUEST message. BYTES 6 - 7: Local EndPtlD - The identification for the local endpoint, allocated during connection creation (optional).

5.2.7 WC_Disconnect_Indication

This message is sent by a connection manager to a user module to inform the module of a disconnection. The packet format 122 is shown in Figure 14. BYTES 0 - 11: All the fields are the same as a DISCONNECT_REQUEST message (refer to Section 5.2.5 for a detailed description), except

ConnMsg - Set to 0x12 for DISCONNECT jNDICATION. Cause - The cause for the disconnection, refer to Section 6.2 for examples of defined values. 5.2.8 WC_Disconnect_Response

This message is sent by a user module to a connection manager as a response to the disconnection indication message. The format of this message is the same as for a DISCONNECTJREQUEST (refer to Section 5.2.5 for a detailed description). The ConnMsg field should be set to OxOF for the DISCONNECTJRESPONSE message.

5.2.9 WC_Disconnect_Confirm

This message is sent by a connection manager to a user module as a confirmation that the disconnection request was completed. The format of this message is the same as for a DISCONNECT_REQUEST (refer to Section 5.2.5 for a detailed description). The ConnMsg field should be set to 0x13 for a DISCONNECT_CONFIRM message.

5.2.10 WC_Listen_Bind

This message is sent by a user module to bind with a connection manager to listen for any incoming connection requests. The packet format 124 is shown in Figure 15.

BYTE 0: ConnMsg - Set to 0x14 for LISTEN BT D message. BYTE 1 PktType - The connection packet type for which to listen to. BYTES 2 - 3: Listen EndPtlD - The well-known endpoint identification of the listening entity. BYTES 4 - 7: ConnMsg Update Function Pointer - This should be set to the function that handles all messages from Connection Manager. This function gets called when there are any connection events for the specified endpoint. BYTES 8-11: ConnMsg Update Function Param - This value would be passed as parameter when the above function is called to deliver messages from the connection manager.

5.2.11 WC_Listen_Unbind

This message is sent by a user module to unbind with a connection manager to stop listening for any incoming connection requests. The packet format 126 is shown in Figure 16. BYTE 0: ConnMsg - Set to 0x15 for LISTEN JNBIND message.

BYTE 1: Reserved.

BYTES 2 - 3: Listen EndPtlD - The well-known endpoint identification of the listening entity.

5.3 Network Command Formats

The connection manager may have one main command ID registered, which defines subcommands for all connection manager messages. The command ID registered for the connection manager may be, for example, OxFA. The channel interface layer responsible for reliable delivery of all control layer commands, adds sequencing information as the first byte of every command. In the command formats described below, the little endian format is assumed.

5.3.1 GENERAL STRUCTURES

5.3.1.1 Sink-to-Source Parameters

These are parameters arrived at by the sink end of a stream based on stream's QOS requirements and resource availability, and are passed to the source end of the stream. The packet format 128 is shown in Figure 17 and includes a reserved window size.

5.3.1.2 Source-to-Sink Parameters

These are parameters arrived at by the source end of the stream based on resource availability, and are passed to the sink end of the stream. The packet format 130 is shown in Figure 18 and includes a Stream ID.

5.3.2 STREAM_CONN_REQUEST

The STREAM_CONN_REQUEST command structure varies depending on the connection type requested. If the request were for a source stream from a peer node (see, e.g., packet format 132 in Figure 19), this command would include the parameters specified by the sink end of stream (SNK_TO_SRC_P ARAMS) in addition to the QOS requirements. If the request is for a sink stream at the peer node (see, e.g., packet format 134 in Figure 20), this command would include the parameters specified by the source end of stream (SRC_TO_SNK_P ARAMS ) and QOS requirements. If the request to the peer node is for both source and sink streams (a bi-directional connection), then the command would include all the above (see, e.g., packet format

136 in Figure 21). The detailed descriptions of the parameters are as follows.

BYTE 0: Seq No (7 bits) - This is the sequence number assigned by the channel interface layer.

ACK (1 bit) - Set to indicate an acknowledgement packet, should be reset to 0.

BYTE 1: SubCmd - Set to 0x01 for STREAM_CONN_REQUEST command

BYTE 2: Packet Type (4 bits) - Indicates the packet type for which stream is requested.

Conn Type (4 bits) - Possible values are

0x1 - SOURCE_STREAM

0x2 - SINK_STREAM

0x3 - BIDIRECTIONAL (both source and sink streams)

BYTES 3-4: Reserved

BYTES 5-6: Requester EndPtlD - The transient identification assigned for the module initiating the connection request.

BYTES 7-8: Listen EndPtlD - The known identification for the listening module to which the connection initiator wishes to connect.

BYTES 9 - 12: Requester EndPt Info - This is the 4 byte information given by the endpoint requesting the connection and is passed transparently to the listening endpoint at the peer node.

BYTES 13 - 44: These bytes would specify SOURCE STREAM PARAMETERS if the connection request is for a source stream alone or for a bi-directional connection. This consists of SNK_TO_SRC_PARAMS and STREAM_QOS_PARAMS (refer to section 5.1) for the source stream at peer node. These bytes would specify the SINK STREAM PARAMETERS if the connection request if for a sink stream alone at the peer node. This consists of SRC_TO_SNK_P ARAMS and STREAM_QOS_P ARAMS (refer to section 5.1) for the sink stream at peer node. BYTES 45 - 76: These bytes are present in the command only when the request is for a bidirectional connection. This would then specify the SINK STREAM PARAMETES for the sink stream at peer node.

5.3.3 STREAM_CONN_ACCEPT

The structure of a STREAM_CONN_ACCEPT command also varies depending on the connection type requested. The various packet formats are illustrated as format 138 (for source streams) in Figure 22, format 140 (for sink streams) in Figure 23 and format 142 (for bi-directional streams) in Figure 24.

BYTES 0 - 4: Same as described in Section 5.3.2 for STREAM_CONN_REQUEST. The

SubCmd is set to 0x02 for the STREAM_CONNECT_ACCEPT command. BYTES 5 - 6: Requester EndPtlD: The connection identification for the endpoint requesting the connection. BYTES 7 - 8: Acceptor EndPtlD: The connection identification for the endpoint which has accepted the connection. BYTES 9 - 10: Listen EndPtlD: The listening endpoint to which the connection request was directed. BYTES 11 - 12: Reserved.

BYTES 13 - 16: Acceptor EndPt Info: This is the 4-byte information given by the endpoint accepting the connection and is passed transparently to the endpoint which initiated the connect request at the peer node. BYTES 17 - 20: These bytes would specify SNK TO_SRC_PARAMS if the connection accepted is a sink stream alone or a bi-directional connection. These bytes would specify the SRC_TO_SNK_P ARAMS if the connection accepted is a source stream only. BYTES 21 - 24: These bytes are present in the command only when the acceptance is for a bi-directional connection. This would then specify the SRC_TO_SNK_

PARAMS for the source stream.

5.3.4 STREAM_CONN_COMPLETE

This command is sent by the source end of a stream to the sink end, when channel bandwidth allocation is successful for the new stream. The packet format 144 is shown in Figure 25.

BYTES 0 - 4: Same as described in section 5.3.2 for a STREAM_CONN_REQUEST. The

SubCmd is set to 0x03 for a STREAM_CONNECT_COMPLETE command. BYTES 5 - 6: Destination EndPtlD - The connection identification for the sink end of the stream. BYTES 7 - 8: Source EndPtlD - The connection identification of the source end of the stream.

5.3.5 STREAM_CONN_ABORT

This command is sent to abort the connect setup process. The reason for connection setup failure could be a resource allocation failure, timeouts etc., the exact cause for failure will be indicated in this command, the packet format 146 of which is shown in Figure 26.

BYTE 0: Same as described in Section 3.3.2 for a STREAM_CONN_REQTJEST. BYTE 1: SubCmd - Set to 0x04 for a STREAM_CONNECT_ABORT command. BYTE 2: Cause - This field indicates the exact cause for aborting the connection setup process. Refer to section 6.2 for examples of defined values. BYTES 5 - 6: Destination EndPtlD - The connection identification of the peer endpoint for which the connection setup is being aborted. BYTES 7 - 8: Source EndPtlD - The connection identification of the endpoint aborting the connection setup. 5.3.6 STREAM_DISCONN_REQUEST / STREAM_DISCONN_COMPLETE

The STREAM_DISCONN_REQUEST command, the packet format 148 of which is shown in Figure 27, is sent to a peer node when a user module requests disconnection. On receiving this command, the peer node notifies its user module, releases the connection resources and responds with a STREAM_DISCONN_ COMPLETE command. BYTE 0 - 2: Same as described in section 5.3.2 for a STREAM_CONN_REQUEST message. BYTE 1: SubCmd - Set to 0x05 for a STREAM_DISCONN_REQUEST command.

Set to 0x06 for a STREAM_DISCONN_COMPLETE command. BYTE 3: Tx StreamlD : Set to the stream ID of the source stream from the peer node, if one exists. BYTE 4: Rx StreamlD : Set to the stream ID of the sink stream at the peer node, if one exists. BYTES 5 - 6: Destination EndPtlD: The connection identification of the peer endpoint to which disconnection command is sent. BYTES 7 - 8: Source EndPtlD: The connection identification of the endpoint sending the disconnection command.

5.3.7 NODE_HANDSHAK NΠTATE / NODE_HANDSHAKE_ACK NODE_HANDSHAKE_INITIATE command is send by the channel interface layer, when it is informed that a new node has been added to the network. The new node, on receiving this command, responds with NODE_HANDSHAKE_ACK and this completes the initial handshaking between the two nodes. The format 150 of the handshaking packets is shown in Figure 28.

BYTE 0: channel interface layer header.

BYTE 1: Subcommand: Set to 0x07 for a NODE_HANDSHAKE_INITIATE command.

Set to 0x08 for a NODE HANDSHAKE ACK command. 5.3.8 Acknowledgement

This is the acknowledgement send by channel interface layer for every connection command received from the network. The format 152 is shown in Figure

29.

BYTE 0: ACK bit set to '1' and the sequence number being acknowledged.

6. Defined Values

(5J EndPoint Indentifiers

The following are examples of endpoint identifiers which may be used: DATA_MANAGER - 0x0003

NETWORK_MANAGER - OxOOOA

6.2 Disconnection Causes

The following are examples of disconnection causes conveyed between the peer nodes and provided to the user modules.

RESOURCESJJNAVAILABLE - 0x01

NO_LISTEN_ENTITY - 0x02

INVALID_P ARAMS - 0x03

USER _RESPONSE_TIMED_ OUT - 0x04

PEER_RESPONSE_TIMED_OUT - 0x05

BANDWIDTH_ALLOC_TIMED_OUT - 0x06

. BANDWIDTH_ALLOC_FAILURE - 0x07

DISCONNECTJREQUEST - 0x08

NODE_DISCONNECTED - 0x09

6.3 Timeouts

The following are some examples of default timeout values which may be used. MAX_WAIT_FOR_UI_RESPONSE 3 // slots MAX_WAIT_FOR_CONN ACCEPT 5 // slots MAX_WAIT_FOR_DBM_RESPONSE 8 // slots MAX_WAIT_FOR_CONN_COMPLETE 8 // slots MAX_WAIT_FOR_DISC_COMPLETE 8 // slots MAX_WAIT_FOR_CONN_RELEASE 3 // slots MAX_WAIT FOR DISC INDICATION 8 // slots MAX_WAITJFOR_STRMID_REALLOC 15 // slots

MAX JW AIT JFOR_ENDPTID_RE ALLOC 15 // slots

MAX_WAIT_CONNMGR_DEFAULT 10 // slots

CONN_MGR_HANDSHAKE_MIN_TIMEGAP 800 // msecs

Thus, a stream connection management scheme for use in a wireless computer network has been described. Although discussed with reference to certain illustrated embodiments, the present invention should not be limited thereby. Instead, the present invention should only be measured in terms of the claims that follow.

Claims

CLAIMSWhat is claimed is:

1. A method comprising managing at the network data link layer level communications between two or more network components to facilitate transmitting multimedia stream data between said network components

2. The method of claim 1 wherein the network data link layer comprises a medium access control (MAC) protocol defining the multimedia stream communication management.

3. The method of claim 2 wherein the managing comprises setting up a stream data connection between said network components.

4. The method of claim 2 wherein the managing comprises tearing down a stream data connection between said network components.

5. The method of claim 2 wherein the stream data connection is bi-directional.

6. The method of claim 2 wherein the communications between two or more network components are wireless.

7. The method of claim 6 wherein the wireless communications include radio frequency communications.

8. The method of claim 7 wherein the radio frequency communications comprise direct sequence spread spectrum techniques.

9. The method of claim 7 wherein the radio frequency communications comprise frequency hopping spread spectrum techniques.

10. The method of claim 6 wherein the wireless communications comprise infra-red frequency communications.

11. The method of claim 2 wherein the network components comprise a MAC level connection manager.

12. The method of claim 11 wherein the connection manager comprises a control layer and a channel interface layer.

13. The method of claim 11 wherein the connection manager manages stream data connections.

14. A network interface comprising a connection manager that manages stream data connections at a network data link layer level.

15. The interface of claim 14 further comprising a wireless communication device.

16. A system comprising a network interface, the network interface including a connection manager that manages stream data connections at a network data link layer level.

17. The system of claim 16 wherein the network interface comprises a wireless communication device.

18. A machine-readable medium that provides instructions, which when executed by a machine, cause said machine to manage communications at a network data link layer level between said machine and one or more other machines in a computer network such that a stream data connection is established between said machines.

19. The method of claim 11 wherein the connection manager associated with a network component establishes connections with applications associated with the same network component to provide stream data from other network components to such applications.

20. The method of claim 19 wherein the connections between connection manager and applications are established with a set of application interface commands and messages.

21. The method of claim 20 wherein the application interface commands and messages comprise one or more of the following:

WC_Listen_Bind, WC_Listen_Unbind, WC_Connect_Request, WC_Connect_Indication, WC_Connect_Response, WC_Connect_Confirm, WC_Disconnect_Request, WC_Disconnect_Indication, WC_Disconnect_Response, or WC_Disconnect_Confirm.

22. The method of claim 19 wherein the application registers with the connections manager such that a unique identifier is associated to said application.

23. The method of claim 22 wherein the application requests to the connection manager a stream connection by providing its registered identifier and a data type for the data stream requested.

24. The method of claim 11 wherein the connection manager associated with a network component establishes stream data connections with one or more other connection managers associated with one or more other network components.

25. The method of claim 24 wherein the connections between connection managers are established with a set of stream commands.

26. The method of claim 25 wherein the set of stream commands comprise one or more of the following commands: a stream connection request, a stream connection acceptance, a stream connection abort, a stream connection complete, a stream disconnection request, and a stream disconnection complete.

27. The method of claim 2 wherein parameters for the transmission of multimedia stream data may be dynamically negotiated for each stream communicated between network components.

28. The method of claim 27 wherein the transmission parameters comprise one or more of the following: a rate of data traffic across the network, a maximum tolerable delay, a maximum retransmission delay, a maximum burst size, a priority of the stream, a delay variation, and an average packet length.

29. The method of claim 28 wherein the priority of the stream includes isochronous stream priority.

30. The method of claim 28 wherein the priority of the stream includes high stream priority.

31. The method of claim 28 wherein the priority of the stream includes medium stream priority.

32. The method of claim 28 wherein the priority of the stream includes low stream priority.

33. The method of claim 32 wherein the low stream priority is transported over the network on a best effort service.