Method and computer program product for internet protocol (IP)—flow classification in a wireless point to multi-point (PTMP) transmission system

This application is a continuation of U.S. application Ser. No. 09/350,156, filed Jul. 9, 1999, entitled IP-FLOW CLASSIFICATION IN A WIRELESS POINT TO MULTI-POINT (PtMP) TRANSMISSION SYSTEM, which issued as U.S. Pat. No. 6,452,915 on Sep. 17, 2002, and which claims the benefit of priority from U.S. Provisional Patent Application No. 60/092,452, filed Jul. 10, 1998, the disclosures of each are incorporated herein by reference thereto.

CROSS-REFERENCE TO OTHER APPLICATIONS

The following applications of common assignee contain common disclosure:

U.S. Patent Application entitled “Transmission Control Protocol/Internet Protocol (TCP/IP) Packet-Centric Wireless Point to Multi-Point (PtMP) Transmission System Architecture,” filed Jul. 9, 1999, assigned U.S. application Ser. No. 09/349,477, issued as U.S. Pat. No. 6,862,622.

U.S. Patent Application entitled “Quality of Service (QoS)—Aware Wireless Point to Multi-Point (PtMP) Transmission System Architecture,” filed Jul. 9, 1999, assigned U.S. application Ser. No. 09/349,480, now abandoned.

U.S. Patent Application entitled “Method for Providing Dynamic Bandwidth Allocation Based on IP-Flow Characteristics in a Wireless Point to Multi-Point (PtMP) Transmission System,” filed Jul. 9, 1999, assigned U.S. application Ser. No. 09/350,126, now abandoned.

U.S. Patent Application entitled “Method for Providing for Quality of Service (QoS)—Based Handling of IP-Flows in a Wireless Point to Multi-Point Transmission System,” filed Jul. 9, 1999, assigned U.S. application Ser. No. 09/350,118, now abandoned.

U.S. Patent Application entitled “IP-Flow Identification in a Wireless Point to Multi-Point Transmission System,” filed Jul. 9, 1999, assigned U.S. application Ser. No. 09/347,856, issued as U.S. Pat. No. 6,594,246.

U.S. Patent Application entitled “IP-Flow Characterization in a Wireless Point to Multi-Point (PtMP) Transmission System,” filed Jul. 9, 1999, assigned U.S. application Ser. No. 09/350,150, issued as U.S. Pat. No. 6,590,885.

U.S. Patent Application entitled “IP-Flow Prioritization in a Wireless Point to Multi-Point (PtMP) Transmission System,” filed Jul. 9, 1999, assigned U.S. application Ser. No. 09/349,476, now abandoned.

U.S. Patent Application entitled “Method of Operation for Providing for Service Level Agreement (SLA) Based Prioritization in a Wireless Point to Multi-Point (PtMP) Transmission System,” filed Jul. 9, 1999, assigned U.S. application Ser. No. 09/350,170, now abandoned.

U.S. Patent Application entitled “Method for Transmission Control Protocol (TCP) Rate Control With Link-Layer Acknowledgments in a Wireless Point to Multi-Point (PtMP) Transmission System,” filed Jul. 9, 1999, assigned U.S. application Ser. No. 09/349,481, now abandoned.

U.S. Patent Application entitled “Transmission Control Protocol/Internet Protocol (TCP/IP)—Centric QoS Aware Media Access Control (MAC) Layer in a Wireless Point to Multi-Point (PtMP) Transmission System,” filed Jul. 9, 1999, assigned U.S. application Ser. No. 350,159, now abandoned.

U.S. Patent Application entitled “Use of Priority-Based Scheduling for the Optimization of Latency and Jitter Sensitive IP Flows in a Wireless Point to Multi-Point Transmission System,” filed Jul. 9, 1999, assigned U.S. application Ser. No. 09/347,857, now abandoned.

U.S. Patent Application entitled “Time Division Multiple Access/Time Division Duplex (TDMA/TDD) Access Method for a Wireless Point to Multi-Point Transmission System,” filed Jul. 9, 1999, assigned U.S. application Ser. No. 09/349,475, now abandoned.

U.S. Patent Application entitled “Reservation Based Prioritization Method for Wireless Transmission of Latency and Jitter Sensitive IP-Flows in a Wireless Point to Multi-Point Transmission System,” filed Jul. 9, 1999, assigned U.S. application Ser. No. 09/349,483, issued as U.S. Pat. No. 6,628,629.

U.S. Patent Application entitled “Translation of Internet-Prioritized Internet Protocol (IP)-Flows into Wireless System Resource Allocations in a Wireless Point to Multi-Point (PtMP) Transmission System,” filed Jul. 9, 1999, assigned

U.S. application Ser. No. 09/349,479, now abandoned.

U.S. Patent Application entitled “Method of Operation for the Integration of Differentiated services (Diff-serv) Marked IP-Flows into a Quality of Service (QoS) Priorities in a Wireless Point to Multi-Point (PtMP) Transmission System,” filed Jul. 9, 1999, assigned U.S. application Ser. No. 09/350,162, now abandoned.

U.S. Patent Application entitled “Method for the Recognition and Operation of Virtual Private Networks (VPNs) over a Wireless Point to Multi-Point (PtMP) Transmission System,” filed Jul. 9, 1999, assigned U.S. application Ser. No. 09/349,975, issued as U.S. Pat. No. 6,680,922.

U.S. Patent Application entitled “Time Division Multiple Access/Time Division Duplex (TDMA/TDD) Transmission Media Access Control (MAC) Air Frame,” filed Jul. 9, 1999, assigned U.S. application Ser. No. 09/350,173, now abandoned.

U.S. Patent Application entitled “Application—Aware, Quality of Service (QoS) Sensitive, Media Access Control (MAC) Layer,” filed Jul. 9, 1999, assigned U.S. application Ser. No. 09/349,482, issued as U.S. Pat. No. 6,640,248.

U.S. Patent Application entitled “Transmission Control Protocol/Internet Protocol (TCP/IP) Packet-Centric Wireless Point to Point (PtP) Transmission System Architecture,” filed Jul. 9, 1999, assigned U.S. application Ser. No. 09/349,478, now abandoned.

U.S. Patent Application entitled “Transmission Control Protocol/Internet Protocol (TCP/IP) Packet-Centric Cable Point to Multi-Point (PtMP) Transmission System Architecture,” filed Jul. 9, 1999, assigned U.S. application Ser. No. 09/349,474, now abandoned.

U.S. Patent Application entitled Transmission Control Protocol/Internet Protocol (TCP/IP) Packet-Centric Wireless Point to Multi-Point (PtMP) Transmission System Architecture,” filed Feb. 28, 2005, assigned U.S. application Ser. No. 11/068,719.

U.S. Patent Application entitled “Method for Providing Dynamic Bandwidth Allocation Based on IP-Flow Characteristics in a Wireless Point to Multi-Point (PtMP) Transmission System,” filed Aug. 10, 2007, assigned U.S. application Ser. No. 11/502,331.

U.S. Patent Application entitled “Use of Priority-Based Scheduling for the Optimization of Latency and Jitter Sensitive IP Flows in a Wireless Point to Multi-Point Transmission System,” filed Aug. 10, 2007, assigned U.S. application Ser. No. 11/502,583.

U.S. Patent Application entitled “Quality of Service (QoS)—Aware Wireless Point to Multi-Point (PtMP) Transmission System Architecture,” filed Aug. 10, 2006, assigned U.S. application Ser. No. 11/502,596.

U.S. Patent Application entitled “Method for Providing for Quality of Service (QoS)—Based Handling of IP-Flows in a Wireless Point to Multi-Point Transmission System,” filed Aug. 10, 2006, assigned U.S. application Ser. No. 11/502,348.

U.S. Patent Application entitled “Transmission Control Protocol/Internet Protocol (TCP/IP)—Centric QoS Aware Media Access Control (MAC) Layer in a Wireless Point to Multi-Point (PtMP) Transmission System,” filed Aug. 10, 2006, assigned U.S. application Ser. No. 11/502,599.

U.S. Patent Application entitled “Method of Operation for the Integration of Differentiated Services (Diff-Serv) Marked IP-Flows into a Quality of Service (QoS) Priorities in a Wireless Point to Multi-Point (PtMP) Transmission System,” filed Aug. 10, 2006, assigned U.S. application Ser. No. 11/502,101.

U.S. Patent Application entitled “Time Division Multiple Access/Time Division Duplex (TDMA/TDD) Transmission Media Access Control (MAC) Air Frame,” filed Aug. 10, 2006, assigned U.S. application Ser. No. 11/502,601.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to telecommunications and, more particularly, to a system and method for implementing a QoS aware wireless point-to-multi-point transmission system.

2. Related Art

Telecommunication networks such as voice, data and video networks have conventionally been customized for the type of traffic each is to transport. For example, voice traffic is very latency sensitive but quality is less important, so voice networks are designed to transport voice traffic with limited latency. Traditional data traffic, such as, e.g., a spreadsheet, on the other hand is not latency sensitive, but error-free delivery is required. Conventional telecommunications networks use circuit switching to achieve acceptable end user quality of service (QoS). With the advent of new packet switching high bandwidth data networks, different types of traffic can be transported over a data network. Specifically, convergence of separate voice, data and video networks into a single broadband telecommunications network is enabled. To ensure end user satisfaction, a system is desired that provides QoS for various types of traffic to be transported.

Wireless networks present particular challenges over their wireline counterparts in delivering QoS. For example, wireless networks traditionally exhibit high bit error rates (BER) due to a number of reasons. Conventional wireless networks also implement circuit switched connections to provide reliable communications channels. However the use of circuit switched connections allocates bandwidth between communicating nodes whether or not traffic is constantly being transferred between the nodes. Therefore, circuit switched connections use communications bandwidth rather inefficiently.

Packet switching makes more efficient use of available bandwidth than does traditional circuit switching. Packet switching breaks up traffic into so-called “packets” which can then be transported from a source node to a destination for reassembly. Thus a particular portion of bandwidth can be shared by many sources and destinations yielding more efficient use of bandwidth.

A wireless broadband access telecommunications system is desired which can provide a QoS capability that is comparable to that delivered by wireline broadband access devices. Conventionally, one of the barriers to the deployment of wireless broadband access systems has been the absence of acceptable QoS characteristics, while at the same time delivering bandwidth sufficient to qualify as broadband. Delivery of raw bandwidth over wireless media without acceptable QoS would not benefit end users. Likewise, the delivery of a high level of QoS at the cost of sufficient bandwidth would also not benefit endusers.

Conventional efforts to provide wireless broadband access systems have not granted sufficient priority to QoS as a guiding principle in architecting the wireless systems, resulting in sub-optimal designs. With the rapid emergence of the Internet, the packet switching paradigm, and transmission control protocol/interact protocol (TCP/IP) as a universal data protocol, it has become clear that a new wireless system design has become necessary.

What is needed then is an IP-centric wireless broadband access system with true QoS capabilities.

SUMMARY OF THE INVENTION

The present invention is directed to an IP flow classification system used in a wireless telecommunications system. More specifically, the IP flow classification system groups IP flows in a packet-centric wireless point to multi-point telecommunications system.

The classification system includes: a wireless base station coupled to a first data network; one or more host workstations coupled to the first data network; one or more subscriber customer premise equipment (CPE) stations in wireless communication with the wireless base station over a shared bandwidth using a packet-centric protocol; and one or more subscriber workstations coupled to each of the subscriber CPE stations over a second network; a resource allocation device optimizes end-user quality of service (QoS) and allocates shared bandwidth among the subscriber CPE stations; an analyzing and scheduling device analyzes and schedules internet protocol (IP) flow over the shared wireless bandwidth. The analyzing device includes the above IP flow classifier that classifies the IP flow.

In one embodiment, the classifier includes a means for associating a packet of an existing IP flow with the IP flow. The classifier can include a QoS grouping device that groups a packet of a new IP flow into a QoS class grouping. The QoS grouping device can include a determining device that determines and takes into account QoS class groupings for the IP flow. The QoS grouping device can include an optional differentiated services (Diff Serv) device that takes into account an optional DiffServs field priority marking for the IP flow. The QoS grouping device can also include an optional type of service (TOS) device that takes into account any optional type of service (TOS) field priority marking for said IP flow.

The cross-referenced applications are incorporated herein by reference in their entireties.

BRIEF DESCRIPTION OF THE FIGURES

The present invention will be described with reference to the accompanying figures, wherein:

<figref idref="DRAWINGS">FIG. 1A</figref> is a block diagram providing an overview of a standard telecommunications network providing local exchange carrier services within one or more local access and transport areas;

<figref idref="DRAWINGS">FIG. 1B</figref> depicts an exemplary network including workstations coupled to a data network;

<figref idref="DRAWINGS">FIG. 1C</figref> illustrates a conventional video network, such as for example a cable television (CATV) network;

<figref idref="DRAWINGS">FIG. 2A</figref> is a block diagram illustrating an overview of a standard telecommunications network providing both local exchange carrier and interexchange carrier services between subscribers located in different local access and transport areas;

<figref idref="DRAWINGS">FIG. 2B</figref> illustrates a signaling network in detail;

<figref idref="DRAWINGS">FIG. 2C</figref> illustrates an exemplary network carrying voice, data and video traffic over a data network;

<figref idref="DRAWINGS">FIG. 2D</figref> depicts a network including a point-to-multipoint wireless network coupled via a router to a data network;

<figref idref="DRAWINGS">FIG. 3A</figref> depicts an exemplary perspective diagram of a point-to-multipoint network;

<figref idref="DRAWINGS">FIG. 3B</figref> depicts a block diagram further illustrating a wireless point-to-multipoint network;

<figref idref="DRAWINGS">FIG. 4</figref> depicts a wireless Internet protocol network access architecture of the present invention;

<figref idref="DRAWINGS">FIG. 5A</figref> depicts Internet protocol flows from a subscriber host to a wireless base station, and through a wireline connection to a destination host;

<figref idref="DRAWINGS">FIG. 5B</figref> illustrates a functional flow diagram including an example functional description of a transmission control protocol adjunct agent performing an outgoing transmission control protocol spoof function;

<figref idref="DRAWINGS">FIG. 5C</figref> illustrates a functional flow diagram including an exemplary functional description of a transmission control protocol adjunct agent performing an incoming transmission control protocol spoof function;

<figref idref="DRAWINGS">FIG. 6</figref> illustrates a block diagram representing scheduling of mixed Internet protocol flows;

<figref idref="DRAWINGS">FIG. 7</figref> illustrates packet header field information which can be used to identify Internet protocol flows and the quality of service requirements of the Internet protocol flows;

<figref idref="DRAWINGS">FIG. 8A</figref> is a block diagram summarizing an exemplary downlink analysis, prioritization and scheduling function;

<figref idref="DRAWINGS">FIG. 8B</figref> is a block diagram summarizing an exemplary uplink analysis prioritization and scheduling function;

<figref idref="DRAWINGS">FIG. 9</figref> illustrates how a downlink flow scheduler can take into account a service level agreement in prioritizing a frame slot and scheduling resource allocation;

<figref idref="DRAWINGS">FIG. 10</figref> depicts an embodiment of an inventive media access control hardware architecture;

<figref idref="DRAWINGS">FIG. 11</figref> is an exemplary software organization for a packet-centric wireless point to multi-point telecommunications system;

<figref idref="DRAWINGS">FIG. 12A</figref> illustrates an exemplary time division multiple access media access control air frame;

<figref idref="DRAWINGS">FIG. 12B</figref> illustrates an exemplary structure for a time division multiple access/time division duplex air frame;

<figref idref="DRAWINGS">FIG. 12C</figref> illustrates an exemplary downstream transmission subframe;

<figref idref="DRAWINGS">FIG. 12D</figref> illustrates an exemplary upstream acknowledgment block field of a downstream transmission subframe;

<figref idref="DRAWINGS">FIG. 12E</figref> illustrates an exemplary acknowledgment request block field of a downstream transmission subframe;

<figref idref="DRAWINGS">FIG. 12F</figref> illustrates an exemplary frame descriptor block field of a downstream transmission subframe;

<figref idref="DRAWINGS">FIG. 12G</figref> illustrates an exemplary downstream media access control payload data unit of a downstream transmission subframe;

<figref idref="DRAWINGS">FIG. 12H</figref> illustrates an exemplary command and control block of a downstream transmission subframe;

<figref idref="DRAWINGS">FIG. 12I</figref> illustrates an exemplary upstream transmission subframe;

<figref idref="DRAWINGS">FIG. 12J</figref> illustrates an exemplary downstream acknowledgment block of an upstream transmission subframe;

<figref idref="DRAWINGS">FIG. 12K</figref> illustrates an exemplary reservation request block of an upstream transmission subframe <b>1204</b>;

<figref idref="DRAWINGS">FIG. 12L</figref> illustrates an exemplary media access control payload data unit of an upstream transmission subframe;

<figref idref="DRAWINGS">FIGS. 12M, 12N and 12O</figref> illustrate an exemplary operations data block of an upstream transmission subframe;

<figref idref="DRAWINGS">FIG. 13</figref> illustrates how an exemplary flow scheduler for the present invention functions;

<figref idref="DRAWINGS">FIG. 14</figref> is an exemplary two-dimensional block diagram of an advanced reservation algorithm;

<figref idref="DRAWINGS">FIG. 15A</figref> is an exemplary logical flow diagram for a downlink flow analyzer;

<figref idref="DRAWINGS">FIG. 15B</figref> is an exemplary logical flow diagram for a downlink flow scheduler;

<figref idref="DRAWINGS">FIG. 16A</figref> is an exemplary logical flow diagram for an uplink flow analyzer;

<figref idref="DRAWINGS">FIG. 16B</figref> is an exemplary logical flow diagram for an uplink flow scheduler;

<figref idref="DRAWINGS">FIG. 17</figref> illustrates Internet protocol flow in a downlink direction, including Internet protocol security encryption; and

<figref idref="DRAWINGS">FIG. 18</figref> illustrates an uplink direction of Internet protocol security support.

In the figures, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The figure in which an element first appears is indicated by the leftmost digit(s) in the reference number.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

I. An Example Environment

The present invention is described in terms of an example environment. The example environment uses a fixed wireless point-to-multi-point (PtMP) connection to transmit packetized data information including for example, IP telephony, video, data, received from a telecommunications carrier. As used herein, a telecommunications carrier can include US domestic entities (see Definitions below at section II) such as, e.g., ILECs, CLECs, IXCs, NGTs and Enhanced Service Providers (ESPs), as well as global entities such as PTTs and NEs, recognized by those skilled in the art. In addition, as used herein a telecommunications system includes domestic systems used by entities such as, e.g., ILECs, CLECs, IXCs and Enhanced Service Providers (ESPs), as well as global systems recognized by those skilled in the art.

In the preferred embodiment, the traffic arrives from a wide area network (WAN) connection.

Data traffic is received from a data network through a network router and can be demodulated from internet protocol (IP) format to, for example, the point-to-point protocol (PPP). Network routers can include, for example, a general purpose computer, such as the SUN workstation running routing software or a dedicated routing device such as various models from CISCO of San Jose, Calif., ASCEND of Alameda, Calif., NETOPIA of Alameda, Calif., or 3COM of Santa Clara, Calif.

In the alternative, a virtual private networking protocol, such as the point-to-point tunneling protocol (PPTP), can be used to create a “tunnel” between a remote user and a corporate data network. A tunnel permits a network administrator to extend a virtual private network from a server (e.g., a Windows NT server) to a data network (e.g., the Internet).

Although the invention is described in terms of this example environment, it is important to note that description in these terms is provided for purposes of illustration only. It is not intended that the invention be limited to this example environment or to the precise inter-operations between the above-noted devices. In fact, after reading the following description, it will become apparent to a person skilled in the relevant art how to implement the invention in alternative environments.

II. Definitions

Table 1 below defines common telecommunications terminology. These terms are used throughout the remainder of the description of the invention.

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="147pt" align="left" /><thead><row><entry namest="1" nameend="2" rowsep="1">TABLE 1</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Term</entry><entry>Definition</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>access tandem (AT)</entry><entry>An AT is a class ¾ switch used to switch calls</entry></row><row><entry /><entry>between EOs in a LATA. An AT provides sub-</entry></row><row><entry /><entry>scribers access to the IXCs, to provide long dis-</entry></row><row><entry /><entry>tance calling services. An access tandem is a net-</entry></row><row><entry /><entry>work node. Other network nodes can include, for</entry></row><row><entry /><entry>example, a CLEC, or other enhanced services</entry></row><row><entry /><entry>provider (ESP), an international gateway or global</entry></row><row><entry /><entry>point-of-presence (GPOP), or an intelligent</entry></row><row><entry /><entry>peripheral (IP).</entry></row><row><entry>bearer (B) channels</entry><entry>Bearer (B) channels are digital channels used to</entry></row><row><entry /><entry>carry both digital voice and digital data infor-</entry></row><row><entry /><entry>mation. An ISDN bearer channel is 64,000 bits</entry></row><row><entry /><entry>per second, which can carry PCM-digitized</entry></row><row><entry /><entry>voice or data.</entry></row><row><entry>called party</entry><entry>The called party is the caller receiving a call sent</entry></row><row><entry /><entry>over a network at the destination or termination</entry></row><row><entry /><entry>end.</entry></row><row><entry>calling party</entry><entry>The calling party is the caller placing a call over</entry></row><row><entry /><entry>any kind of network from the origination end.</entry></row><row><entry>central office (CO)</entry><entry>A CO is a facility that houses an EO homed. EOs</entry></row><row><entry /><entry>are often called COs.</entry></row><row><entry>class 1 switch</entry><entry>A class 1 switching office, the Regional Center</entry></row><row><entry /><entry>(RC), is the highest level of local and long dis-</entry></row><row><entry /><entry>tance switching, or “office of last resort” to com-</entry></row><row><entry /><entry>plete a call.</entry></row><row><entry>class 3 switch</entry><entry>A class 3 switching office was a Primary Center</entry></row><row><entry /><entry>(PC); an access tandem (AT) has class 3 func-</entry></row><row><entry /><entry>tionality.</entry></row><row><entry>class 4 switch</entry><entry>A class 4 switching office was a Toll Center (TC)</entry></row><row><entry /><entry>if operators were present or else a Toll Point</entry></row><row><entry /><entry>(TP); an access tandem (AT) has class 4 func-</entry></row><row><entry /><entry>tionality.</entry></row><row><entry>class 5 switch</entry><entry>A class 5 switching office is an end office (EO)</entry></row><row><entry /><entry>or the lowest level of local and long distance</entry></row><row><entry /><entry>switching, a local central office. The switch</entry></row><row><entry /><entry>closest to the end subscriber.</entry></row><row><entry>competitive LEC</entry><entry>CLECs are telecommunications services providers</entry></row><row><entry>(CLEC)</entry><entry>of local services that can compete with ILECs.</entry></row><row><entry /><entry>!nterprise and Century 21 are examples. A CLEC</entry></row><row><entry /><entry>may or may not handle IXC services as well.</entry></row><row><entry>competitive access</entry><entry>Teligent and Winstar are examples.</entry></row><row><entry>providers (CAPS)</entry><entry /></row><row><entry>customer premises</entry><entry>CPE refers to devices residing on the premises</entry></row><row><entry>equipment (CPE)</entry><entry>of a customer and used to connect to a telephone</entry></row><row><entry /><entry>network, including ordinary telephones, key tele-</entry></row><row><entry /><entry>phone systems, PBXs, video conferencing de-</entry></row><row><entry /><entry>vices and modems.</entry></row><row><entry>digitized data (or</entry><entry>Digitized data refers to analog data that has been</entry></row><row><entry>digital data)</entry><entry>sampled into a binary representation (i.e., com-</entry></row><row><entry /><entry>prising sequences of 0's and 1's). Digitized data</entry></row><row><entry /><entry>is less susceptible to noise and attenuation distor-</entry></row><row><entry /><entry>tions because it is more easily regenerated to</entry></row><row><entry /><entry>reconstruct the original signal.</entry></row><row><entry>egress end office</entry><entry>The egress E0 is the node or destination E0</entry></row><row><entry /><entry>with a direct connection to the called party, the</entry></row><row><entry /><entry>termination point. The called party is “homed”</entry></row><row><entry /><entry>to the egress EQ.</entry></row><row><entry>egress</entry><entry>Egress refers to the connection from a called</entry></row><row><entry /><entry>party or termination at the destination end of a</entry></row><row><entry /><entry>network, to the serving wire center (SWC).</entry></row><row><entry>end office (EO)</entry><entry>An EO is a class 5 switch used to switch local</entry></row><row><entry /><entry>calls within a LATA. Subscribers of the LEC are</entry></row><row><entry /><entry>connected (“homed”) to EOs, meaning that EOs</entry></row><row><entry /><entry>are the last switches to which the subscribers are</entry></row><row><entry /><entry>connected.</entry></row><row><entry>Enhanced Service</entry><entry>A network services provider.</entry></row><row><entry>Provider (ESP)</entry><entry /></row><row><entry>equal access</entry><entry>1+ dialing as used in US domestic calling for</entry></row><row><entry /><entry>access to any long distance carrier as required</entry></row><row><entry /><entry>under the terms of the modified final judgment</entry></row><row><entry /><entry>(MFJ) requiring divestiture of the Regional Bell</entry></row><row><entry /><entry>Operating Companies (RBOCs) from their parent</entry></row><row><entry /><entry>company, AT&amp;T.</entry></row><row><entry>global point of</entry><entry>A GPOP refers to the location where international</entry></row><row><entry>presence (GPOP)</entry><entry>telecommunications facilities and domestic</entry></row><row><entry /><entry>facilities interface, an international gateway POP.</entry></row><row><entry>incumbent LEC</entry><entry>ILECs are traditional LECs in the US, which are</entry></row><row><entry>(ILEC)</entry><entry>the Regional Bell Operating Companies</entry></row><row><entry /><entry>(RBOCs). Bell South and US West are examples.</entry></row><row><entry /><entry>ILEC can also stand for an independent LEC such</entry></row><row><entry /><entry>as a GTE.</entry></row><row><entry>ingress end office</entry><entry>The ingress EO is the node or serving wire center</entry></row><row><entry /><entry>(SVC) with a direct connection to the calling</entry></row><row><entry /><entry>party, the origination point. The calling party is</entry></row><row><entry /><entry>“homed” to the ingress EO.</entry></row><row><entry>ingress</entry><entry>Ingress refers to the connection from a calling</entry></row><row><entry /><entry>party or origination.</entry></row><row><entry>integrated service</entry><entry>An ISDN Basic Rate Interface (BRI) line provides</entry></row><row><entry>digital network</entry><entry>2 bearer B channels and 1 data D line (known as</entry></row><row><entry>(ISDN) basic rate</entry><entry>“2B + D” over one or two pairs) to a subscriber.</entry></row><row><entry>interface (BRI) line</entry><entry /></row><row><entry>integrated services</entry><entry>ISDN is a network that provides a standard for</entry></row><row><entry>digital network</entry><entry>communications (voice, data and signaling), end-</entry></row><row><entry>(ISDN)</entry><entry>to-end digital transmission circuits, out-of-band</entry></row><row><entry /><entry>signaling, and a features significant amount of</entry></row><row><entry /><entry>bandwidth.</entry></row><row><entry>inter machine trunk</entry><entry>An inter-machine trunk (IMT) is a circuit between</entry></row><row><entry>(IMT)</entry><entry>two commonly-connected switches.</entry></row><row><entry>inter-exchange</entry><entry>IXCs are U.S. domestic long distance telecommu-</entry></row><row><entry>carrier (IXC)</entry><entry>nications services providers. AT&amp;T, MCI, Sprint,</entry></row><row><entry /><entry>are examples.</entry></row><row><entry>internet protocol (IP)</entry><entry>IP is part of the TCP/IP protocols. It is used to</entry></row><row><entry /><entry>recognize incoming messages, route outgoing</entry></row><row><entry /><entry>messages, and keep track of Internet node ad-</entry></row><row><entry /><entry>dresses (using a number to specify a TCP/IP</entry></row><row><entry /><entry>host on the Internet). IP corresponds to the net-</entry></row><row><entry /><entry>work layer of OSI.</entry></row><row><entry>Internet service</entry><entry>An ISP is a company that provides Internet access</entry></row><row><entry>provider (ISP)</entry><entry>to subscribers.</entry></row><row><entry>ISDN primary rate</entry><entry>An ISDN Primary Rate Interface (PRI) line</entry></row><row><entry>interface (PRI)</entry><entry>provides the ISDN equivalent of a T1 circuit. The</entry></row><row><entry /><entry>PRI delivered to a customer's premises can</entry></row><row><entry /><entry>provide 23B + D (in North America) or 30B + D</entry></row><row><entry /><entry>(in Europe) channels running at</entry></row><row><entry /><entry>1.544 megabits per second and 2.048 megabits</entry></row><row><entry /><entry>per second, respectively.</entry></row><row><entry>local exchange</entry><entry>LECs are local telecommunications services</entry></row><row><entry>carrier (LEC)</entry><entry>providers. Bell Atlantic and U.S. West are</entry></row><row><entry /><entry>examples.</entry></row><row><entry>local access and</entry><entry>A LATA is a region in which a LEC offers ser-</entry></row><row><entry>transport area</entry><entry>vices. There are over 160 LATAs of these local</entry></row><row><entry>(LATA)</entry><entry>geographical areas within the United States.</entry></row><row><entry>local area network</entry><entry>A LAN is a communications network providing</entry></row><row><entry>(LAN)</entry><entry>connections between computers and peripheral</entry></row><row><entry /><entry>devices (e.g., printers and modems) over a</entry></row><row><entry /><entry>relatively short distance (e.g., within a building)</entry></row><row><entry /><entry>under standardized control.</entry></row><row><entry>modified final</entry><entry>Modified final judgment (MFJ) was the decision</entry></row><row><entry>judgment (MFJ)</entry><entry>requiring divestiture of the Regional Bell Oper-</entry></row><row><entry /><entry>ating Companies (RBOCs) from their parent</entry></row><row><entry /><entry>company, AT&amp;T.</entry></row><row><entry>network node</entry><entry>A network node is a generic term for the re-</entry></row><row><entry /><entry>sources in a telecommunications network, in-</entry></row><row><entry /><entry>cluding switches, DACS, regenerators, etc. Net-</entry></row><row><entry /><entry>work nodes essentially include all non-circuit</entry></row><row><entry /><entry>(transport) devices. Other network nodes can</entry></row><row><entry /><entry>include, for example, equipment of a CLEC, or</entry></row><row><entry /><entry>other enhanced service provider (ESP), a</entry></row><row><entry /><entry>point-of-presence (POP), an international gate-</entry></row><row><entry /><entry>way or global point-of-presence (GPOP).</entry></row><row><entry>new entrant (NE)</entry><entry>A new generation global telecommunications.</entry></row><row><entry>next generation</entry><entry>A new telecommunications services provider,</entry></row><row><entry>telephone (NGT)</entry><entry>especially IP telephony providers. Examples are</entry></row><row><entry /><entry>Level 3 and Qwest.</entry></row><row><entry>packetized voice or</entry><entry>One example of packetized voice is voice over</entry></row><row><entry>voice over a</entry><entry>internet protocol (VOIP). Voice over packet</entry></row><row><entry>backbone</entry><entry>refers to the carrying of telephony or voice traffic</entry></row><row><entry /><entry>over a data network, e.g. voice over frame, voice</entry></row><row><entry /><entry>over ATM, voice over Internet Protocol (IP), over</entry></row><row><entry /><entry>virtual private networks (VPNs), voice over a</entry></row><row><entry /><entry>backbone, etc.</entry></row><row><entry>Pipe or dedicated</entry><entry>A pipe or dedicated communications facility</entry></row><row><entry>communications</entry><entry>connects an ISP to the internet.</entry></row><row><entry>facility</entry><entry /></row><row><entry>point of presence</entry><entry>A POP refers to the location within a LATA</entry></row><row><entry>(POP)</entry><entry>where the IXC and LEC facilities interface.</entry></row><row><entry>point-to-point</entry><entry>A virtual private networking protocol, point-to-</entry></row><row><entry>tunneling protocol</entry><entry>point tunneling protocol (PPTP), can be used to</entry></row><row><entry>(PPTP)</entry><entry>create a “tunnel” between a remote user and a</entry></row><row><entry /><entry>data network. A tunnel permits a network admin-</entry></row><row><entry /><entry>istrator to extend a virtual private network (VPN)</entry></row><row><entry /><entry>from a server (e.g., a Windows NT server) to a</entry></row><row><entry /><entry>data network (e.g., the Internet).</entry></row><row><entry>point-to-point (PPP)</entry><entry>PPP is a protocol permitting a computer to</entry></row><row><entry>protocol</entry><entry>establish a connection with the Internet using a</entry></row><row><entry /><entry>modem. PPP supports high-quality graphical front</entry></row><row><entry /><entry>ends, like Netscape.</entry></row><row><entry>postal telephone</entry><entry>State regulated telephone companies, many of</entry></row><row><entry>telegraph (PTT)</entry><entry>which are being deregulated. NTT is an example.</entry></row><row><entry>private branch</entry><entry>A PBX is a private switch located on the premises</entry></row><row><entry>exchange (PBX)</entry><entry>of a user. The user is typically a private company</entry></row><row><entry /><entry>which desires to provide switching locally.</entry></row><row><entry>private line with a</entry><entry>A private line is a direct channel specifically</entry></row><row><entry>dial tone</entry><entry>dedicated to a customer's use between two</entry></row><row><entry /><entry>specified points. A private line with a dial tone</entry></row><row><entry /><entry>can connect a PBX or an ISP's access concen-</entry></row><row><entry /><entry>trator to an end office (e.g. a channelized T1 or</entry></row><row><entry /><entry>PRI). A private line can also be known as a leased</entry></row><row><entry /><entry>line.</entry></row><row><entry>public switched</entry><entry>The PSTN is the worldwide switched voice net-</entry></row><row><entry>telephone network</entry><entry>work.</entry></row><row><entry>(PSTN)</entry><entry /></row><row><entry>regional Bell</entry><entry>RBOCs are the Bell operating companies</entry></row><row><entry>operating companies</entry><entry>providing LEC services after being divested</entry></row><row><entry>(RBOCs)</entry><entry>from AT&amp;T.</entry></row><row><entry>signaling system 7</entry><entry>SS7 is a type of common channel interoffice</entry></row><row><entry>(SS7)</entry><entry>signaling (CCIS) used widely throughout the</entry></row><row><entry /><entry>world. The SS7 network provides the signaling</entry></row><row><entry /><entry>functions of indicating the arrival of calls, trans-</entry></row><row><entry /><entry>mitting routing and destination signals, and</entry></row><row><entry /><entry>monitoring line and circuit status.</entry></row><row><entry>switching hierarchy or</entry><entry>An office class is a functional ranking of a tele-</entry></row><row><entry>office classification</entry><entry>phone central office switch depending on trans-</entry></row><row><entry /><entry>mission requirements and hierarchical relationship</entry></row><row><entry /><entry>to other switching centers. Prior to AT&amp;T's</entry></row><row><entry /><entry>divestiture of the RBOCs, an office classification</entry></row><row><entry /><entry>was the number assigned to offices according to</entry></row><row><entry /><entry>their hierarchical function in the U.S. public</entry></row><row><entry /><entry>switched network (PSTN). The following class</entry></row><row><entry /><entry>numbers are used: class 1 = Regional Center</entry></row><row><entry /><entry>(RC), class 2 = Sectional Center (SC), class 3 =</entry></row><row><entry /><entry>Primary Center (PC), class 4 = Toll Center (TC)</entry></row><row><entry /><entry>if operators are present or else Toll Point (TP),</entry></row><row><entry /><entry>class 5 = End Office (EO) a local central office.</entry></row><row><entry /><entry>Any one center handles traffic from one to two or</entry></row><row><entry /><entry>more centers lower in the hierarchy. Since</entry></row><row><entry /><entry>divestiture and with more intelligent software in</entry></row><row><entry /><entry>switching offices, these designations have become</entry></row><row><entry /><entry>less firm. The class 5 switch was the closest to</entry></row><row><entry /><entry>the end subscriber. Technology has distributed</entry></row><row><entry /><entry>technology closer to the end user, diffusing</entry></row><row><entry /><entry>traditional definitions of network switching</entry></row><row><entry /><entry>hierarchies and the class of switches.</entry></row><row><entry>telecommunications</entry><entry>A LEC, a CLEC, an IXC, an Enhanced Service</entry></row><row><entry>carrier</entry><entry>Provider (ESP), an intelligent peripheral (IP), an</entry></row><row><entry /><entry>international/global point-of-presence (GPOP),</entry></row><row><entry /><entry>i.e., any provider of telecommunications services.</entry></row><row><entry>transmission control</entry><entry>TCP is an end-to-end protocol that operates at the</entry></row><row><entry>protocol (TCP)</entry><entry>transport and sessions layers of OSI, providing</entry></row><row><entry /><entry>delivery of data bytes between processes running</entry></row><row><entry /><entry>in host computers via separation and sequencing</entry></row><row><entry /><entry>of IP packets.</entry></row><row><entry>transmission control</entry><entry>TCP/IP is a protocol that provides communica-</entry></row><row><entry>protocol/internet</entry><entry>tions between interconnected networks. The</entry></row><row><entry>protocol (TCP/IP)</entry><entry>TCP/IP protocol is widely used on the Internet,</entry></row><row><entry /><entry>which is a network comprising several large</entry></row><row><entry /><entry>networks connected by high-speed connections.</entry></row><row><entry>trunk</entry><entry>A trunk connects an access tandem (AT) to an</entry></row><row><entry /><entry>end office (EO).</entry></row><row><entry>wide area network</entry><entry>A WAN is a data network that extends a LAN</entry></row><row><entry>(WAN)</entry><entry>over the circuits of a telecommunications carrier.</entry></row><row><entry /><entry>The carrier is typically a common carrier. A</entry></row><row><entry /><entry>bridging switch or a router is used to connect the</entry></row><row><entry /><entry>LAN to the WAN.</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> III. Introduction <br /> A. Quality of Service (QOS) in a Wireless Environment

The concept of quality of service (QoS) is one of the most difficult and least understood topics in data networking. Although a common term in data networking, there are many different usages and definitions for QoS, leading to confusion regarding an exact meaning in precise or quantitative terms. Even further confusion is found when attempts are made to measure or specify numeric quantities sufficient to allow comparison of equipment or network performance with respect to QoS.

The confusion about QoS in general data networking is transferred and magnified when applied to wireless data communications. Wireless transmission has a higher inherent bit error rate (BER) than does wireline transmission. The addition of, e.g., a point-to-multipoint (PtMP) topology for multiple users sharing a wireless medium makes it desirable that QoS be defined in a manner that specifically addresses the multiple complicating factors in wireless data communications.

To provide a non-ambiguous definition of QoS that applies to wireless data communications, the nature of the problem that QoS is meant to solve is helpful. Many of the problems of data communications over wireless are unique and distinct from those of wireline data communications, while some are in fact shared. For wireless broadband access systems, the problems of quality delivery are somewhat more complex than for the wireline analog. Like its wireline counterpart, the problems encountered in wireless delivery of data include, e.g., slow peripheral access, data errors, “drop-outs,” unnecessary retransmissions, traffic congestion, out-of-sequence data packets, latency, and jitter. In addition to these problems, wireless delivery adds problems including, e.g., high inherent bit error rates(BERs), limited bandwidth, user contention, radio interference, and TCP traffic rate management. A QoS-aware wireless system is desired to address all these problems.

There are a number of ways in which users or subscribers to a data network experience difficulties. One network difficulty is due to a lack of network availability. Depending on the access technology being used, this can include a “modem no-answer” condition, “network busy” condition, or a sudden unexpected “drop” of a network connection. These conditions would not be described as being consistent with high QoS. Once network connectivity is achieved, slow traffic caused by congestion, local access bottlenecks, and network failures can be experienced as slow web page loading, slow file transfers, or poor voice/video quality in streaming multimedia applications. Poor quality in streaming multimedia applications can instead result from high “jitter,” or large and rapid variations in latency, leading to interruptions, distortion, or termination of session. Many different conditions can lead to actual data errors, which in some contexts can be catastrophic, such as in the file transfer of a spreadsheet. It is desirable that these problems of a data communications network be minimized or eliminated.

1. Quality

In data networking, quality usually implies the process of delivering data in a reliable and timely manner. What is reliable and timely is dependent on the nature of the traffic being addressed. These terms may include references to limitations in data loss, expectations of data accuracy, limitations of data latency variations (also known as jitter), and limitations of data retransmissions and limitations of data packet order inversions. Therefore, QoS is a complex concept, which can require a correspondingly complex mechanism to implement it.

QoS can be a relative term, finding different meanings for different users. A casual user doing occasional web browsing, but no file transfer protocol (FTP) file downloads or real time multimedia sessions may have different a different definition of QoS than a power user doing many FTP file downloads of large database or financial files, frequent H.323 video conferencing and IP telephony calls. Also, a user can pay a premium rate (i.e. a so-called service level agreement (SLA)) for high network availability, low latency, and low jitter, while another user can pay a low rate for occasional web surfing only, and on weekends only. Therefore, perhaps it is best to understand QoS as a continuum, defined by what network performance characteristic is most important to a particular user and the user's SLA. Maximizing the end-user experience is an essential component of providing wireless QoS.

2. Service

In data networking, a service can be defined as a type of connection from one end of a network to another. Formerly, this could have been further defined to be protocol specific, such as, e.g., IBM's systems network architecture (SNA), Novell's IPX, Digital's DECnet. However, it appears that TCP/IP (i.e. including user datagram protocol(UDP)) has evolved to become the overwhelming protocol of choice, and will continue to be in the foreseeable future. Therefore, service can be defined to be a particular type of TCP/IP connection or transmission. Such service types might include, e.g., FTP file transfers, e-mail traffic, hypertext transfer protocol (HTTP) traffic, H.323 videoconferencing sessions. It is desirable that a QoS mechanism deal with these differing types of service, in addition to dealing with the different types of quality as discussed previously.

3. QOS as a Mechanism

QoS can be thought of as a mechanism to selectively allocate scarce networking, transmission and communications resources to differentiated classes of network traffic with appropriate levels of priority. Ideally, the nature of the data traffic, the demands of the users, the conditions of the network, and the characteristics of the traffic sources and destinations all modify how the QoS mechanism is operating at any given instant. Ultimately, however, it is desirable that the QoS mechanism operate in a manner that provides the user with optimal service, in whatever manner the user defines it.

a. Circuit-Switched QoS

In legacy networks created primarily for voice traffic by telephone companies, data transmission was accomplished with reference to a circuit-centric definition of QoS. In this definition, QoS implied the ability to carry asynchronous (i.e. transmission of data through start and stop sequences without the use of a common clock) as well as isochronous (i.e. consistent timed access of network bandwidth for time-sensitive voice and video) traffic. Circuit-switched QoS was accomplished by dedicating an end-to-end circuit for each connection or service, whether it was voice (see <figref idref="DRAWINGS">FIG. 1A</figref>) or data. The circuit-centric QoS mechanism was simply the provision of this circuit for exclusive use by the user. Of course, this approach dedicates the circuit, all transmission channels associated with the circuit, and the transport media itself to a single user for the entire duration of the session, regardless of whether data is actually being transmitted every instant of the session. It was generally believed that only in this manner could true QoS be achieved. Therefore, traditional designs for wireless broadband access systems (see <figref idref="DRAWINGS">FIG. 2A</figref>) also used this approach, dedicating a wireless radio channel to each particular data connection, regardless of the application or whether indeed any data was being transmitted at any given moment. This circuit-centric approach to QoS is fairly expensive, in terms of the cost of the equipment, and the utilization factors for the transmission media itself.

b. Asynchronous Transfer Mode (ATM) QoS

With ATM networking, telephone companies could continue to provide a circuit-centric QOS mechanism with the establishment of permanent virtual connections (PVCs) (i.e. a virtual path or channel connection (VPC or VCC) provisioned for indefinite use) and switched virtual connections (SVCs) (i.e. a logical connection between endpoints established by an ATM network on demand based upon signaling messages received from the end user or another network) in an analogous manner to the legacy voice circuit mechanism. However, several new concepts were needed, including admission policy, traffic shaping, and mechanisms such as, e.g., leaky-buckets, in order to handle traffic that was now categorized as variable bit rate (VBR), constant bit rate (CBR), and unspecified bit rate (UBR).

Virtual circuits were to be established for data transmission sessions, again regardless of the data application or whether data was being transmitted at any given moment. Although ATM provides QoS for broadband network traffic, the underlying assumptions of ATM design include the low BER characteristic of wireline networks, not the high BER of the wireless medium. Without a recognition of the characteristics of the traffic that is being carried by the ATM mechanism and the high inherent BER of wireless, true QoS can not be provided. ATM QoS mechanisms do not address the unique challenges associated with wireless communication.

c. Packet-Switched QoS

Packet-switching is revolutionizing data communications, so conventional circuit-switch and ATM networking concepts and their legacy QoS mechanisms are in need of update. With packet-switched data communications, one cannot dedicate a circuit to a particular data communications session. Indeed, a strength of packet-switching lies in route flexibility and parallelism of its corresponding physical network. Therefore, the QoS mechanism cannot work in the same manner as the legacy circuit-centric QoS mechanism did.

Simply providing “adequate” bandwidth is not a sufficient QoS mechanism for packet-switched networks, and certainly not for wireless broadband access systems. Although some IP-flows are “bandwidth-sensitive,” other flows are latency- and/or jitter-sensitive. Real time or multimedia flows and applications cannot be guaranteed timely behavior by simply providing excessive bandwidth, even if it were not cost-prohibitive to do so. It is desirable that QoS mechanisms for an IP-centric wireless broadband access system recognize the detailed flow-by-flow requirements of the traffic, and allocate system and media resources necessary to deliver these flows in an optimal manner.

d. Summary—QoS Mechanisms

Ultimately, the end-user experience is the final arbiter of QoS. It is desirable that an IP-centric wireless broadband access system assign and regulate system and media resources in a manner that can maximize the end-user experience. For some applications such as an initial screen of a Web page download, data transmission speed is the best measure of QoS. For other applications, such as the download or upload of a spreadsheet, the best measure of QoS can be the minimization of transmission error. For some applications, the best measure of QoS can be the optimization of both speed and error. For some applications, the timely delivery of packets can be the best measure of QoS. It is important to note that fast data transmission may not be the same as timely delivery of packets. For instance, data packets that are already “too old” can be transmitted rapidly, but by being too old can be of no use to the user. The nature of the data application itself and the desired end-user experience then can provide the most reliable criteria for the QoS mechanism. It is desired that an IP-centric wireless broadband access system provide a QoS mechanism that can dynamically optimize system behavior to each particular IP flow, and can also adapt to changes with changing network load, congestion and error rates.

4. Service Guarantees and Service Level Agreements (SLAs)

Service guarantees can be made and service level agreements (SLAs) can be entered into between a telecommunications service provider and a subscriber whereby a specified level of network availability can be described, and access charges can be based upon the specified level. Unfortunately, it is difficult to quantify the degree of network availability at any given time, and therefore this becomes a rather crude measure of service performance. It is desired that data delivery rate, error rate, retransmissions, latency, and jitter be used as measures of network availability, but measuring these quantities on a real-time basis can be beyond the capability of conventional network service providers (NSPs).

Another level of service discrimination desired by network service providers is a service level agreement (SLA) that provides for differing traffic rates, network availability, bandwidth, error rate, latency and jitter guarantees. It is desired that an IP-centric wireless broadband access system be provided that can provide for SLAs, enabling service providers to have more opportunities for service differentiation and profitability.

5. Class of Service and Quality of Service

In order to implement a practical QoS mechanism, it is desired that a system be able to differentiate between types of traffic or service types so that differing levels of system resources can be allocated to these types. It is customary to speak of “classes of service” as a means of grouping traffic types that can receive similar treatment or allocation of system and media resources.

Currently, there are several methods that can be used in wireline network devices to implement differentiated service classes. Example methods include traffic shaping, admission control, IP precedence, and differential congestion management. It is desired that an IP-centric wireless broadband access system use all of these methods to differentiate traffic into classes of service, to map these classes of service against a QoS matrix, and thereby to simplify the operation and administration of the QoS mechanism.

B. QoS and IP-Centric Wireless Environment

In a point-to-multipoint (PtMP) wireless system like the present invention, it is desirable that the QoS mechanism cope not only with wireline networking considerations, but also with considerations particular to the wireless environment. As stated earlier, it is desired that the inherent BER of wireless be handled. The high BER can require that error detection, correction, and re-transmission be done in an efficient manner. It is desired that a BER handling mechanism also work efficiently with the re-transmission algorithms of TCP/IP so as to not cause further unnecessary degradation of bandwidth utilization. An additional challenge of wireless is contention among users for limited wireless bandwidth. It is desirable that the system handle service requests from multiple users in a radio medium subject to interference and noise, which can make efficient allocation of radio bandwidth difficult.

As discussed above, the change from circuit-switched and ATM data networks to packet-switched data networks has impacted the definition of QoS mechanisms. The present invention provides a novel QoS mechanism in a point-to-multi-point IP-centric wireless system for packet-switched network traffic. In order for the system to provide optimal QoS performance, it desirable that it include a novel approach to QoS mechanisms. The use of QoS as the underlying guide to system architecture and design constitutes an important, substantial and advantageous difference of the IP-centric wireless broadband access system of the present invention over existing wireless broadband access systems designed with traditional circuit-centric or ATM cell circuit-centric approaches such as those used by Teligent and Winstar.

C. IP-Centric Wireless Broadband Access QoS and Queuing Disciplines

1. Managing Queues

Queuing is a commonly accepted tool required for manipulating data communications flows. In order for packet headers to be examined or modified, for routing decisions to made, or for data flows to be output on appropriate ports, it is desirable that data packets be queued. However, queuing introduces, by definition, a delay in the traffic streams that can be detrimental, and can even totally defeat the intent of queuing. Excessive queuing can have detrimental effects on traffic by delaying time sensitive packets beyond their useful time frames, or by increasing the RTT (Round Trip Time), producing unacceptable jitter or even causing the time-out of data transport mechanisms. Therefore, it is desired that queuing be used intelligently and sparingly, without introducing undue delay in delay-sensitive traffic such as real-time sessions.

In a wireless environment where time division multiple access (TDMA), forward error detection (FEC), and other such techniques can be necessary, it is desirable that queuing be used merely to enable packet and radio frame processing. However, in the case of real-time flows, the overall added delay in real-time traffic can preferably be held to below approximately 20 milliseconds.

The use of queue management as the primary QoS mechanism in providing QoS-based differentiated services is a simple and straight forward method for wireless broadband systems. However, wireless systems are usually more bandwidth constrained and therefore more sensitive to delay than their wireline counterparts. For this reason, it is desirable that QoS-based differentiated services be provided with mechanisms that go beyond what simple queuing can do. However, some queuing can still be required, and the different queuing methods are now discussed.

2. First in, First out (FIFO) Queuing

First in, first out (FIFO) queuing can be used in wireless systems, like wireline systems, in buffering data packets when the downstream data channel becomes temporarily congested. If temporary congestion is caused by bursty traffic, a FIFO queue of reasonable depth can be used to smooth the flow of data into the congested communications segment. However, if the congestion becomes severe in extent, or relatively long in duration, FIFO can lead to the discarding of packets as the FIFO queues are filled to capacity and the network is not capable of accepting additional packets causing discarding of packets, i.e. so-called “packet-tossing.” Although this can have a detrimental effect on QoS in and of itself, the discarding of packets may cause future problems with traffic flow as the TCP protocol causes the retransmission of lost packets in the proper sequence, further exacerbating the problem. The problem of packet discards can be minimized by increasing the size of the FIFO buffers so that more time can pass before discards occur. Unfortunately, eventually the FIFO can become large enough that packets can become too old and the round-trip time (RTT) can increase to the point that the packets are useless, and the data connection is virtually lost.

In a wireless broadband environment, the requirement for FIFO queuing is partially dependent upon the type of RF access method being used. For time division multiple access/time division duplex (TDMA/TDD), it can be desirable that data be queued even for collecting enough data for the construction of data frames for transmission. Frequency division multiple access (FDMA) and code-division multiple access (CDMA) are not as “sequential” in nature as TDMA, and therefore have less of a requirement for FIFO queuing. However, generally for all wireless access techniques, noise and interference are factors that can lead to retransmissions, and therefore further delays and consequent adverse effect on QoS.

Using FIFO queuing, shared wireless broadband systems can uniformly delay all traffic. This can seem to be the “fairest” method, but it is not necessarily the best method if the goal is to provide high QoS to users. By using different types of queue management, a much better base of overall QoS can be achieved.

3. Priority Queuing

The shared wireless broadband environment can include a constricted bandwidth segment as data is transmitted over the RF medium. Therefore, regardless of access technique, these systems can require some amount of queuing. However, using FIFO queuing can result in a constant delay to all traffic, regardless of the priority or type of traffic. Most data communications environments can consist of a mixture of traffic, with combinations of real time interactive data, file and data downloads, web page access, etc. Some of these types of traffic are more sensitive to delay, and jitter, than others. Priority queuing simply reorders data packets in the queue based on their relative priorities and types, so that data from more latency- and jitter-sensitive traffic can be moved to the front of the queue.

Unfortunately, if there is downlink data channel congestion, or congestion caused by an overabundance of high priority traffic, the condition of “buffer starvation” can occur. Because of the relative volume of high priority packets consuming a majority of buffer space, little room is left for lower priority packets. These lower priority packets can experience significant delays while system resources are devoted to the high priority packets. In addition to low priority packets being held in buffers for long periods of time, or never reaching the buffers, resulting in significantly delayed data flows for these packets, the actual applications corresponding to these low priority packets can also be disrupted, and stop working. Because of the nature of this queuing approach, overall latency and jitter and RTT for lower priority packets can be unpredictable, having an adverse effect on QoS.

If queue sizes are small, reordering data within the queues can have little beneficial effect on the QoS. In fact, processing required to examine packet headers in order to obtain the information necessary to reorder the queues may itself add significant delay to the data stream. Therefore, particularly for wireless broadband data environments, priority queuing can be not much better than FIFO queuing as a QoS mechanism.

4. Classed Based Queuing

By allocating queue space and system resources to packets based on the class of the packets, buffer starvation can be avoided. Each class can be defined to include of data flows with certain similar priorities and types. All classes can be given a certain minimum level of service so that one high priority data flow cannot monopolize all system resources. With the classification approach, because no data flow is ever completely shut off, the source application can receive information about the traffic rate, and can be able to provide TCP-mediated transmission rate adjustment supporting smooth traffic flow.

Although this approach can work better than FIFO queuing in wireless broadband systems, latency and jitter sensitive flows can still be adversely affected by high priority flows of large volume.

5. Weighted Fair Queuing

A weighted fair queuing method can attempt to provide low-volume flows with guaranteed queuing resources, and can then allow remaining flows, regardless of volume or priority, to have equal amounts of resource. Although this can prevent buffer starvation, and can lead to somewhat better latency and jitter performance, it can be difficult to attain stable performance in the face of rapidly changing RF downlink channel bandwidth availability.

Providing a high quality of service can require a QoS mechanism that is more sophisticated than simple queue management.

D. IP-Centric Wireless Broadband Access QoS and TCP/IP

1. TCP/IP

The TCP/IP protocol stack has become the standard method of transmitting data over the Internet, and increasingly it is becoming a standard in virtual private networks (VPNs). The TCP/IP protocol stack includes not only internet protocol (IP), but also transmission control protocol (TCP), user datagram protocol (UDP), and internet control message protocol (ICMP). By assuming that the TCP/IP protocol stack is the standard network protocol for data communications, the creation of a set of optimal QoS mechanisms for the wireless broadband data environment is more manageable. QoS mechanisms can be created that can span the entire extent of the network, including both the wireline and the wireless portions of the network. These mechanisms can integrate in a smooth and transparent manner with TCP rate control mechanisms and provide end-to-end QoS mechanisms that are adaptive to both the wireline and wireless portions of the network. Of course, segments of the wireline network that are congested or are experiencing other transport problems cannot be solved by a wireless QoS mechanism. However, a wireless QoS mechanism can optimize data flows in a manner that can enhance the end user experience when there is no severe wireline network congestion or bottleneck present.

2. Differentiation by Class

Data traffic can be handled based on classes of service, as discussed above. To differentiate traffic by class, data traffic (or a sequence of data packets associated with a particular application, function, or purpose) can be classified into one of several classes of service. Differentiation can be done on the basis of some identifiable information contained in packet headers. One method can include analyzing several items in, e.g., an IP packet header, which can serve to uniquely identify and associate the packet and other packets from that packet flow with a particular application, function or purpose. As a minimum, a source IP address, a source TCP or UDP port, a destination IP address, and a destination IP or UDP port can serve to associate packets into a common flow, i.e. can be used to classify the packets into a class of service.

By creating a finite and manageable number of discrete classes of service, multiple IP flows can be consolidated and handled with a given set of QoS parameters by the QoS mechanisms. These classes can be defined to provide common and useful characteristics for optimal management in the combined wireline and wireless network segments.

3. Per-Flow Differentiation

A finite and discrete set of classes of service, can enable QoS mechanisms to be less compute-intensive, to use less memory, fewer state machines, and therefore have better scaleability than having individual QoS mechanisms (or sets of parameters) for each individual IP flow. However, in a network access device such as, e.g., a point to multi-point (PtMP) wireless broadband access system, the total number of simultaneous IP flows typically will not exceed the range of 1000, and therefore the amount of processing overhead that could be required could permit a per-flow QoS differentiation without resorting to classes of service. However, class of service consolidation of IP flows provides advantages related to marketing, billing and administration.

Prior to the present invention, per-flow differentiation has not been used in a wireless environment (including radio frequencies transmitted over coaxial cables and satellite communications).

4. Using IP Precedence for Class of Service

IP precedence bits in a type of service (IP TOS) field, as described in Internet Engineering Task Force (IETF)1992b, can theoretically be used as a means to sort IP flows into classes of service. IETF RFC1349 proposed a set of 4-bit definitions with 5 different meanings: minimize delay; maximize throughput; maximize reliability; minimize monetary cost; and normal service.

These definitions could add significantly to networks, routers and access devices in differentiating different types of flow so that resources could be appropriately allocated, resulting in improved QoS. However, the proposal has not been widely used. Several proposals in the IETF could make use of this field, along with resource reservation protocol (RSVP), to improve network handling of packets.

Although the type of service (TOS) field has been an integral component of the TCP/IP specification for many years, the field is not commonly used. Absent appropriate bits in the field being set by a source processor, the access devices, the network and network routers cannot implement QoS mechanisms.

5. TCP-Mediated Transmission Rate Mechanisms

The manner in which TCP governs transmission rate can be incorporated and managed by an IP-centric wireless QoS mechanism. If a TCP mechanism is not managed, any wireless QoS mechanism can be overwhelmed or countered by wireless bandwidth factors. Before addressing the specific wireless factors that can impact TCP transmission speed, a review of TCP transmission rate mechanism is needed.

TCP can control transmission rate by “sensing” when packet loss occurs. Because TCP/IP was created primarily for wireline environment with its extremely low inherent BER, such as those found over fiber optic lines, any packet loss is assumed by TCP to be due to network congestion, not loss through bit error. Therefore, TCP assumes that the transmission rate exceeded the capacity of the network, and responds by slowing the rate of transmission. However, packet loss in the wireless link segment is due primarily to inherently high BER, not congestion. The difference turns out to be not insubstantial.

TCP can initially cause the transmission rate to ramp-up at the beginning of a packet flow, and is called slow-start mode. The rate can be continuously increased until there is a loss or time-out of the packet-receipt acknowledgment message. TCP can then “back-off”, can decrease the transmission window size, and then can retransmit lost packets in the proper order at a significantly slower rate. TCP can then slowly increase the transmission rate in a linear fashion, which can be called congestion-avoidance mode.

If multiple users share a wireless radio link as with the present invention, the inherently high BER of the medium could potentially cause frequent packet loss leading to unproductive TCP retransmission in congestion avoidance mode. Because wireless bandwidth can be a precious commodity, a IP-centric wireless QoS mechanism preferably provides for packet retransmission without invoking TCP retransmission and consequent and unnecessary “whipsawing” of the transmission rate. This, along with several other factors, makes desirable creation of an IP-centric wireless media access control (MAC) layer. One function of an IP-centric MAC layer can be to mediate local retransmission of lost packets without signaling TCP and unnecessarily altering the TCP transmission speed. A primary task of the IP-centric wireless MAC layer is to provide for shared access to the wireless medium in an orderly and efficient manner. The MAC layer according to the present invention, Proactive Reservation-based Intelligent Multimedia-aware Media Access (PRIMMA) layer, available from Malibu Networks Inc., of Calabasas, Calif., can also schedule all packet transmissions across the wireless medium on the basis of, e.g., IP flow type, service level agreements (SLAs), and QoS considerations.

6. TCP Congestion Avoidance in an IP-Centric Wireless System

a. Network Congestion Collapse, Global Synchronization and IP-Centric Wireless TCP Congestion Avoidance

The inherently high bit error rate (BER) of wireless transmission can make an occurrence of problems known as congestion collapse or global synchronization collapse more likely than in a wireline environment. When multiple TCP senders simultaneously detect congestion because of packet loss, the TCP senders can all go into TCP slow start mode by shrinking their transmission window sizes and by pausing momentarily. The multiple senders can then all attempt to retransmit the lost packets simultaneously. Because they can all start transmitting again in rough synchrony, a possibility of creating congestion can arise, and the cycle can start all over again.

In the wireless environment, an occurrence of burst noise can cause packet loss from many IP streams simultaneously. The TCP transmission rate mechanisms of the TCP senders can assume that packet loss was due to congestion, and they can all back-off in synchrony. When the TCP senders restart, the senders can restart in rough synchrony, and indeed can now create real congestion in the wireless link segment. This cyclical behavior can continue for some time, and can possibly cause unpredictable system performance. This can be due in part to overflowing system queues which can cause more packets to be dropped and can cause more unproductive retransmissions. This can degenerate into a “race” state that could take many minutes before re-establishing stability; this can have an obvious negative impact on QoS.

In the wireline world, random early detection (RED) can be used to circumvent global synchronization. By randomly selecting packets from randomly selected packet flows before congestion collapse occurs, global synchronization can be avoided. Queues can be monitored, and when queue depth exceeds a preset limit, RED can be activated, activating asynchronously the TCP senders' transmission rate controllers. This can avoid the initial congestion which would otherwise result in collapse and then global synchronization.

Instead of purely random packet discards, the packets to be discarded can be done with consideration to packet priority or type. While still random, the probability of discard for a given flow can be a function of the by packet priority or type. In a wireless system, weighted random early detection (WRED) can be used without the concern of retransmission and TCP rate reset by preferentially selecting UDP packets of real time IP flows such as streaming audio, and H.323 flows with a more critical packet Time-to-Live parameter. These IP flows are more sensitive to latency and jitter, and less sensitive to packet loss.

In the wireless environment, with an appropriately designed MAC layer, packet loss due to BER that might otherwise trigger congestion collapse and global synchronization can best be managed with local retransmission of lost packets according to the present invention and without RED and the unnecessary retransmission of packets by the TCP sender and the resulting reset of TCP transmission rate. The IP-centric wireless system separately manages the TCP transmission window of the TCP sender remotely by transmitting a packet receipt-acknowledgment before the TCP sender detects a lost packet and initiates retransmission along with an unnecessary reset of the transmission rate. This IP-centric wireless system TCP transmission window manager communicates with the MAC layer in order to be aware of the status of all packets transmitted over the wireless medium.

b. The Effect of Fractal Self-Similar Network Traffic Characteristics vs. Poisson Distributions on Network Congestion

Conventionally, it has been believed that network traffic can be modeled with a Poisson distribution. Using this distribution leads to the conclusion, through system simulations, that the sum of thousands of individual traffic flows with Poisson distributions results in a uniform overall network traffic distribution. In other words, the overall network can “average-out” the burstiness of individual traffic flows. Using this model, network congestion behavior, burst behavior, and dynamic traffic characteristics have been used to create conventional congestion avoidance strategies, design queue buffer sizes in network devices, and traffic and capacity limitation predictions.

More recent studies have demonstrated that TCP/IP-based traffic causes networks to behave in a fractal, or self-similar fashion. With this model, when the burstiness of individual traffic flows is summed for the entire network, the entire network becomes bursty. The bursty nature of network traffic flow is seen over all time scales and flow scales of the network. This has huge implications both in design of an IP-centric wireless broadband system according to the present invention, and in the design of congestion avoidance strategies in the network as a whole. With this new perspective on network behavior, it has become clear that network routers, switches and transmission facilities in many cases have been “under-engineered.” This under-engineering has led to a further exacerbation of the congestion behavior of the network.

The implications for IP-centric wireless system architecture and design range from queue buffer capacity to local congestion avoidance strategies. Because wireless systems have the added burden of a high inherent BER, the effect of network-wide congestion behavior on local (wireless media channel) congestion avoidance strategies must be properly gauged and countered. For this reason, it is desirable that congestion avoidance algorithms of the IP-centric wireless system be crafted to optimize traffic flow with new mathematical and engineering considerations that until very recently were not apparent or available to system designers.

With these considerations in mind, IP-centric wireless system design cannot be done with the conventional wireline system design approaches without resulting in very low system performance characteristics. With traditional design approaches of a circuit-centric wireless system, bandwidth utilization, real time multimedia quality, and overall system QoS provide for a dramatically lower end-user experience.

7. Application-Specific Flow Control in an IP-Centric Wireless System

With a range of data flows, each having different bandwidth, latency and jitter requirements, for the achievement of high QoS as perceived by the end user, it is desirable that the IP-centric wireless system be able to manage QoS mechanism parameters over a wide range, and in real time. The QoS mechanism must be able to alter system behavior to the extent that one or more data flows corresponding to specific applications be switched on and off from appropriate end users in a transparent manner. This approach is in contrast to other QoS mechanisms that seek to achieve high QoS by establishing circuit-centric connections from end to end without regard for an underlying application's actual QoS requirements. By using the present invention, providing a QoS mechanism that is application-specific rather than circuit-specific, scarce wireless bandwidth can be conserved and dynamically allocated where needed by the QoS mechanisms associated with each application type.

B. QoS and IP-Centric Wireless Media Access Control

1. Proactive Reservation-based Intelligent Multimedia-aware Media Access (PRIMMA) MAC Layer

The present invention's proactive reservation-based intelligent multimedia-aware media access (PRIMMA) media access control (MAC) layer provides an application switching function of the IP-centric wireless QoS mechanism. Once the nature and QoS requirements of each IP stream are determined by other portions of the system, this information is communicated to the PRIMMA MAC layer so that the IP flows of each application can be switched to appropriate destinations in a proper priority order.

2. PRIMMA IP Protocol Stack Vertical Signaling

For IP streams that originate from a local user's CPE, application-level information about the nature of the application can be used by the system to assign appropriate QoS mechanism parameters to the IP stream. For IP streams that originate from a non-local host, information about the IP streams for use in configuring the appropriate QoS mechanism parameters can be extracted from packet headers. The information about the IP streams is communicated “vertically” in the protocol stack model from the application layer (i.e. OSI level 7) to the PRIMMA MAC layer (i.e. OSI level 2) for bandwidth reservation and application switching purposes. Although this violates the conventional practice of providing isolation and independence to each layer of the protocol stack, thereby somewhat limiting the degree of interchangeability for individual layers of the stack, the advantages far outweigh the negatives in an IP-centric wireless broadband access system.

3. PRIMMA IP Flow Control and Application Switching

Based on a specific set of QOS requirements of each IP application flow in the IP-centric wireless system, applications are switched in a “proactive” manner by appropriate reservations of bandwidth over the wireless medium. The wireless transmission frames in each direction are constructed in a manner dictated by the individual QoS requirements of each IP flow. By using QoS requirements to build the wireless transmission frames, optimal QoS performance can result over the entire range of applications being handled by the system. For example, latency and jitter sensitive IP telephony, other H.323 compliant IP streams, and real-time audio and video streams can be given a higher priority for optimal placement in the wireless transmission frames. On the other hand, hypertext transport protocol (HTTP) traffic, such as, e.g., initial web page transmissions, can be given higher bandwidth reservation priorities for that particular application task. Other traffic without latency, jitter, or bandwidth requirements such as, e.g., file transfer protocol (FTP) file downloads, email transmissions, can be assigned a lower priority for system resources and placement in the wireless transmission frame.

4. PRIMMA TCP Transmission Rate Agent

Wireless end users are separated from a high speed, low BER wireline backbone by a lower speed, high BER wireless segment which can be subject to burst error events. TCP/IP traffic that traverses the wireless segment can experience frequent packet loss that, without intervention, can create congestion collapse and global synchronization as previously discussed. Therefore, it is desirable that the present invention's IP-centric wireless system make use of a TCP transmission rate agent that can monitor packet loss over the wireless segment, and can manage the remote TCP transmission rate function by recreating and transmitting any lost packet acknowledgments. The PRIMMA MAC layer can itself retransmit any lost packets over the wireless medium.

The IP-centric wireless TCP transmission rate agent or “adjunct” can also flow-control the IP streams when necessary, and in accordance with the QoS requirements of the IP flows. All IP-centric wireless TCP transmission rate agent functionality can be transparent to both local and remote hosts and applications.

F. Telecommunications Networks

1. Voice Network

a. Simple Voice Network

<figref idref="DRAWINGS">FIG. 1A</figref> is a block diagram providing an overview of a standard telecommunications network <b>100</b> providing local exchange carrier (LEC) services within one or more local access and transport areas (LATAs). Telecommunications network <b>100</b> can provide a switched voice connection from a calling party <b>102</b> to a called party <b>110</b>. <figref idref="DRAWINGS">FIG. 1A</figref> is shown to also include a private branch exchange <b>112</b> which can provide multiple users access to LEC services by, e.g., a private line. Calling party <b>102</b> and called party <b>110</b> can be ordinary telephone equipment, key telephone systems, a private branch exchange (PBX) <b>112</b>, or applications running on a host computer. Network <b>100</b> can be used for modem access as a data connection from calling party <b>102</b> to, for example, an Internet service provider (ISP) (not shown). Network <b>100</b> can also be used for access to, e.g., a private data network. For example, calling party <b>102</b> can be an employee working on a notebook computer at a remote location who is accessing his employer's private data network through, for example, a dial-up modem connection.

<figref idref="DRAWINGS">FIG. 1A</figref> includes end offices (EOs) <b>104</b> and <b>108</b>. EO <b>104</b> is called an ingress EO because it provides a connection from calling party <b>102</b> to public switched telephone network (PSTN) facilities. EO <b>108</b> is called an egress EO because it provides a connection from the PSTN facilities to a called party <b>110</b>. In addition to ingress EO <b>104</b> and egress EO <b>108</b>, the PSTN facilities associated with telecommunications network <b>100</b> include an access tandem (AT) (not shown) at points of presence (POPs) <b>132</b> and <b>134</b> that can provide access to, e.g., one or more inter-exchange carriers (IXCs) <b>106</b> for long distance traffic, see <figref idref="DRAWINGS">FIG. 2A</figref>. Alternatively, it would be apparent to a person having ordinary skill in the art that IXC <b>106</b> could also be, for example, a CLEC, or other enhanced service provider (ESP), an international gateway or global point-of-presence (GPOP), or an intelligent peripheral (IP).

<figref idref="DRAWINGS">FIG. 1A</figref> also includes a private branch exchange (PBX) <b>112</b> coupled to EO <b>104</b>. PBX <b>112</b> couples calling parties <b>124</b> and <b>126</b>, fax <b>116</b>, client computer <b>118</b> and associated modem <b>130</b>, and local area network <b>128</b> having client computer <b>120</b> and server computer <b>122</b> coupled via an associated modem <b>130</b>. PBX <b>112</b> is a specific example of a general class of telecommunications devices located at a subscriber site, commonly referred to as customer premises equipment (CPE).

Network <b>100</b> also includes a common channel interactive signaling (CCIS) network for call setup and call tear down. Specifically, <figref idref="DRAWINGS">FIG. 1</figref> includes a Signaling System 7 (SS7) signaling network <b>114</b>. Signaling network <b>114</b> will be described further below with reference to <figref idref="DRAWINGS">FIG. 2B</figref>.

b. Detailed Voice Network

<figref idref="DRAWINGS">FIG. 2A</figref> is a block diagram illustrating an overview of a standard telecommunications network <b>200</b>, providing both LEC and IXC carrier services between subscribers located in different LATAs. Telecommunications network <b>200</b> is a more detailed version of telecommunications network <b>100</b>. Calling party <b>102</b>a and called party <b>110</b>a are coupled to EO switches <b>104</b>a and <b>108</b>a, respectively. In other words, calling party <b>102</b>a is homed to ingress EO <b>104</b>a in a first LATA, whereas called party <b>110</b>a is homed to an egress EO <b>108</b>a in a second LATA. Calls between subscribers in different LATAs are long distance calls that are typically routed to IXCs. Sample IXCs in the United States include AT&amp;T, MCI and Sprint.

Telecommunications network <b>200</b> includes access tandems (AT) <b>206</b> and <b>208</b>. AT <b>206</b> provides connection to points of presence (POPs) <b>132</b>a, <b>132</b>b, <b>132</b>c and <b>132</b>d. IXCs <b>106</b>a, <b>106</b>b and <b>106</b>c provide connection between POPs <b>132</b>a, <b>132</b>b and <b>132</b>c (in the first LATA) and POPs <b>134</b>a, <b>134</b>b and <b>134</b>c (in the second LATA). Competitive local exchange carrier (CLEC) <b>214</b> provides an alternative connection between POP <b>132</b>d and POP <b>134</b>d. POPs <b>134</b>a, <b>134</b>b, <b>134</b>c and <b>134</b>d, in turn, are connected to AT <b>208</b>, which provides connection to egress EO <b>108</b>a. Called party <b>110</b>a can receive calls from EO <b>108</b>a, which is its homed EO.

Alternatively, it would be apparent to a person having ordinary skill in the art that an AT <b>206</b> can also be, for example, a CLEC, or other enhanced service provider (ESP), an international gateway or global point-of-presence (GPOP), or an intelligent peripheral.

Network <b>200</b> also includes calling party <b>102</b>c homed to CLEC switch <b>104</b>c. Following the 1996 Telecommunications Act in the U.S., CLECs gained permission to compete for access within the local RBOCs territory. RBOCs are now referred to as incumbent local exchange carriers (ILECs).

i. Fixed Wireless CLECs

Network <b>200</b> further includes a fixed wireless CLEC <b>209</b>. Example fixed wireless CLECs are Teligent Inc., of Vienna, Va., WinStar Communications Inc., Advanced Radio Telecom Corp. And the BizTel unit of Teleport Communications Group Inc. Fixed wireless CLEC <b>209</b> includes a wireless transceiver/receiver radio frequency (RF) tower <b>210</b> in communication over an RF link to a subscriber transciever RF tower <b>212</b>. Subscriber RF tower <b>212</b> is depicted coupled to a CPE box, PBX <b>112</b>b. PBX <b>112</b>b couples calling parties <b>124</b>b and <b>126</b>b, fax <b>116</b>b, client computer <b>118</b>b and associated modem <b>130</b>b, and local area network <b>128</b>b having client computer <b>120</b>b and server computer <b>122</b>b coupled via an associated modem <b>130</b>b.

Network <b>200</b> also includes called party <b>110</b>a, a fax <b>116</b>a, client computer <b>118</b>a and associated modem <b>130</b>a, and cellular communications RF tower <b>202</b> and associated cellular subscriber called party <b>204</b>, all coupled to EO <b>108</b>a, as shown.

EO <b>104</b>a, <b>108</b>a and AT <b>206</b>, <b>208</b> are part of a switching hierarchy. EO <b>104</b>a is known as a class 5 office and AT <b>208</b> is a class 3/4 office switch. Prior to the divestiture of the regional Bell Operating Companies (RBOCs) from AT&amp;T following the modified final judgment, an office classification was the number assigned to offices according to their hierarchical function in the U.S. public switched network (PSTN). An office class is a functional ranking of a telephone central office switch depending on transmission requirements and hierarchical relationship to other switching centers. A class 1 office was known as a Regional Center (RC), the highest level office, or the “office of last resort” to complete a call. A class 2 office was known as a Sectional Center (SC). A class 3 office was known as a Primary Center (PC). A class 4 office was known as either a Toll Center (TC) if operators were present, or otherwise as a Toll Point (TP). A class 5 office was an End Office (EO), i.e., a local central office, the lowest level for local and long distance switching, and was the closest to the end subscriber. Any one center handles traffic from one or more centers lower in the hierarchy. Since divestiture and with more intelligent software in switching offices, these designations have become less firm. Technology has distributed functionality closer to the end user, diffusing traditional definitions of network hierarchies and the class of switches.

ii. Connectivity to Internet Service Providers (ISPs)

In addition to providing a voice connection from calling party <b>102</b>a to called party <b>110</b>a, the PSTN can provide calling party <b>102</b>a a data connection to an ISP (i.e. similar to client <b>118</b>b).

Network <b>200</b> can also include an Internet service provider (ISP) (not shown) which could include a server computer <b>122</b> coupled to a data network <b>142</b> as will be discussed further below with reference to <figref idref="DRAWINGS">FIG. 1B</figref>. The Internet is a well-known, worldwide network comprising several large networks connected together by data links. These links can include, for example, Integrated Digital Services Network (ISDN), T1, T3, FDDI and SONET links. Alternatively, an internet can be a private network interconnecting a plurality of LANs and/or WANs, such as, for example, an intranet. An ISP can provide Internet access services for subscribers such as client <b>118</b>b.

To establish a connection with an ISP, client <b>118</b>b can use a host computer connected to a modem (modulator/demodulator) <b>130</b>b. The modem can modulate data from the host computer into a form (traditionally an analog form) for transmission to the LEC facilities. Typically, the LEC facilities convert the incoming analog signal into a digital form. In one embodiment, the data is converted into the point-to-point protocol (PPP) format. (PPP is a well-known protocol that permits a computer to establish a connection with the Internet using a standard modem. It supports high-quality, graphical user-interfaces.) As those skilled in the art will recognize, other formats are available, including, e.g., a transmission control program, interact protocol (TCP/IP) packet format, a user datagram protocol, internet protocol (UDP/IP) packet format, an asynchronous transfer mode (ATM) cell packet format, a serial line interface protocol (SLIP) protocol format, a point-to-point (PPP) protocol format, a point-to-point tunneling protocol (PPTP) format, a NETBIOS extended user interface (NETBEUI) protocol format, an Appletalk protocol format, a DECnet, BANYAN/VINES, an Internet packet exchange (IPX) protocol format, and an internet control message protocol (ICMP) protocol format.

iii. Communications Links

Note that <figref idref="DRAWINGS">FIGS. 1A, 2A</figref> and other figures described herein include lines which may refer to communications lines or which may refer to logical connections between network nodes, or systems, which are physically implemented by telecommunications carrier devices. These carrier devices include circuits and network nodes between the circuits including, for example, digital access and cross-connect system (DACS), regenerators, tandems, copper wires, and fiber optic cable. It would be apparent to persons having ordinary skill in the art that alternative communications lines can be used to connect one or more telecommunications systems devices. Also, a telecommunications carrier as defined here, can include, for example, a LEC, a CLEC, an IXC, an Enhanced Service Provider (ESP), a global or international services provider such as a global point-of-presence (GPOP), and an intelligent peripheral.

EO <b>104</b>a and AT <b>206</b> are connected by a trunk. A trunk connects an AT to an EO. A trunk can be called an inter machine trunk (IMT). AT <b>208</b> and EO <b>108</b>a are connected by a trunk which can be an IMT.

Referring to <figref idref="DRAWINGS">FIG. 1A</figref>, EO <b>104</b> and PBX <b>112</b> can be connected by a private line with a dial tone. A private line can also connect an ISP (not shown) to EO <b>104</b>, for example. A private line with a dial tone can be connected to a modem bay or access converter equipment at the ISP. Examples of a private line are a channelized T1 or integrated services digital network (ISDN) primary rate interface (PRI). An ISP can also attach to the Internet by means of a pipe or dedicated communications facility. A pipe can be a dedicated communications facility. A private line can handle data modem traffic to and from an ISP.

Trunks can handle switched voice traffic and data traffic. For example, trunks can include digital signals DS1-DS4 transmitted over T1-T4 carriers. Table 2 provides typical carriers, along with their respective digital signals, number of channels, and bandwidth capacities.

<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="35pt" align="center" /><colspec colname="2" colwidth="35pt" align="center" /><colspec colname="3" colwidth="77pt" align="center" /><colspec colname="4" colwidth="70pt" align="center" /><thead><row><entry namest="1" nameend="4" rowsep="1">TABLE 2</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>Digital</entry><entry>Number of</entry><entry /><entry>Bandwidth in Megabits</entry></row><row><entry>signal</entry><entry>channels</entry><entry>Designation of carrier</entry><entry>per second (Mbps)</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="35pt" align="center" /><colspec colname="2" colwidth="35pt" align="char" char="." /><colspec colname="3" colwidth="77pt" align="center" /><colspec colname="4" colwidth="70pt" align="char" char="." /><tbody valign="top"><row><entry>DS0</entry><entry>1</entry><entry>None</entry><entry>0.064</entry></row><row><entry>DS1</entry><entry>24</entry><entry>T1</entry><entry>1.544</entry></row><row><entry>DS2</entry><entry>96</entry><entry>T2</entry><entry>6.312</entry></row><row><entry>DS3</entry><entry>672</entry><entry>T3</entry><entry>44.736</entry></row><row><entry>DS4</entry><entry>4032</entry><entry>T4</entry><entry>274.176</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Alternatively, trunks can include optical carriers (OCs), such as OC-1, OC-3, etc. Table 3 provides typical optical carriers, along with their respective synchronous transport signals (STSs), ITU designations, and bandwidth capacities.

<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="56pt" align="center" /><colspec colname="2" colwidth="56pt" align="center" /><colspec colname="3" colwidth="63pt" align="center" /><colspec colname="4" colwidth="42pt" align="center" /><thead><row><entry namest="1" nameend="4" rowsep="1">TABLE 3</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry>Electrical signal,</entry><entry>International</entry><entry>Bandwidth in</entry></row><row><entry>Optical carrier</entry><entry>or synchronous</entry><entry>Telecommunications</entry><entry>Megabits</entry></row><row><entry>(OC)</entry><entry>transport</entry><entry>Union (ITU)</entry><entry>per second</entry></row><row><entry>signal</entry><entry>signal (STS)</entry><entry>terminology</entry><entry>(Mbps)</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="56pt" align="center" /><colspec colname="2" colwidth="56pt" align="center" /><colspec colname="3" colwidth="63pt" align="center" /><colspec colname="4" colwidth="42pt" align="char" char="." /><tbody valign="top"><row><entry>OC-1 </entry><entry>STS-1 </entry><entry /><entry>51.84</entry></row><row><entry>OC-3 </entry><entry>STS-3 </entry><entry>STM-1</entry><entry>155.52</entry></row><row><entry>OC-9 </entry><entry>STS-9 </entry><entry>STM-3</entry><entry>466.56</entry></row><row><entry>OC-12</entry><entry>STS-12</entry><entry>STM-4</entry><entry>622.08</entry></row><row><entry>OC-18</entry><entry>STS-18</entry><entry>STM-6</entry><entry>933.12</entry></row><row><entry>OC-24</entry><entry>STS-24</entry><entry>STM-8</entry><entry>1244.16</entry></row><row><entry>OC-36</entry><entry>STS-36</entry><entry> STM-12</entry><entry>1866.24</entry></row><row><entry>OC-48</entry><entry>STS-48</entry><entry> STM-16</entry><entry>2488.32</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

As noted, a private line is a connection that can carry data modem traffic. A private line can be a direct channel specifically dedicated to a customer's use between two specified points. A private line can also be known as a leased line. In one embodiment, a private line is an ISDN/primary rate interface (ISDN PRI) connection. An ISDN PRI connection can include a single signal channel (called a data or D channel) on a T1, with the remaining 23 channels being used as bearer or B channels (Bearer channels are digital channels that bear voice and data information.) If multiple ISDN PRI lines are used, the signaling for all of the lines can be carried over a single D channel, freeing up the remaining lines to carry only bearer channels.

iv. Telecommunications Traffic

Telecommunications traffic can be sent and received from any network node of a telecommunications carrier. A telecommunications carrier can include, for example, a LEC, a CLEC, an IXC, and an Enhanced Service Provider (ESP). In an embodiment, this traffic can be received from a network node which is, for example, a class 5 switch, such as EO <b>104</b>a, or from a class 3/4 switch, such as AT <b>206</b>. Alternatively, the network system can also be, for example, a CLEC, or other enhanced service provider (ESP), an international gateway or global point-of-presence (GPOP), or an intelligent peripheral.

Voice traffic refers, for example, to a switched voice connection between calling party <b>102</b>a and called party <b>110</b>a. It is important to note that this is on a point-to-point dedicated path, i.e., that bandwidth is allocated whether it is being used or not. A switched voice connection is established between calling party <b>102</b>a and EO <b>104</b>a, then to AT <b>206</b> then over an IXC's network such as that of IXC <b>106</b>a to AT <b>208</b> and then to EO <b>108</b>a and over a trunk to called party <b>110</b>a. In another embodiment, AT <b>206</b> or IXC <b>106</b>a can also be, for example, a CLEC, or other enhanced service provider (ESP), an international gateway or global point-of-presence (GPOP), or an intelligent peripheral.

It is possible that calling party <b>102</b>a is a computer with a data connection to a server over the voice network. Data traffic refers, for example, to a data connection between a calling party <b>102</b>a (using a modem) and a server <b>122</b>b that could be part of an ISP. A data connection can be established, e.g., between calling party <b>102</b>a and EO <b>104</b>a, then to AT <b>206</b>, then to CLEC <b>214</b>, then over a fixed wireless CLEC <b>209</b> link to PBX <b>112</b>b to a modem <b>130</b>b associated with server <b>122</b>b.

c. Signaling Network

<figref idref="DRAWINGS">FIG. 2B</figref> illustrates signaling network <b>114</b> in greater detail. Signaling network <b>114</b> is a separate network used to handle the set up, tear down, and supervision of calls between calling party <b>102</b> and called party <b>110</b>. Signaling network <b>114</b> in the given example is the Signaling System 7 (SS7) network. Signaling network <b>114</b> includes service switching points (SSPs) <b>236</b>, <b>238</b>,<b>240</b> and <b>242</b>, signal transfer points (STPs) <b>222</b>, <b>224</b>, <b>226</b>, <b>228</b>, <b>230</b> and <b>232</b>, and service control point (SCP) <b>234</b>.

In the SS7 network, the SSPs are the portions of the backbone switches providing SS7 functions. The SSPs can be, for example, a combination of a voice switch and an SS7 switch, or a computer connected to a voice switch. The SSPs communicate with the switches using primitives, and create packets for transmission over the SS7 network.

EOs <b>104</b>a, <b>108</b>a and ATs <b>206</b>, <b>208</b> can be respectively represented in SS7 signaling network <b>114</b> as SSPs <b>236</b>, <b>238</b>, <b>240</b> and <b>242</b>. Accordingly, the connections between EOs <b>104</b>a, <b>108</b>a and ATs <b>206</b>, <b>208</b> (presented as dashed lines) can be represented by connections <b>254</b>, <b>256</b>, <b>258</b> and <b>268</b>. The types of these links are described below.

The STPs act as routers in the SS7 network, typically being provided as adjuncts to in-place switches. The STPs route messages from originating SSPs to destination SSPs. Architecturally, STPs can and are typically provided in “mated pairs” to provide redundancy in the event of congestion or failure and to share resources (i.e., load sharing is done automatically). As illustrated in <figref idref="DRAWINGS">FIG. 2B</figref>, STPs can be arranged in hierarchical levels, to provide hierarchical routing of signaling messages. For example, mated STPs <b>222</b>, <b>224</b> and mated STPs <b>226</b>, <b>228</b> are at a first hierarchical level, while mated STPs <b>230</b>, <b>232</b> are at a second hierarchical level.

SCPs provide database functions. SCPs can be used to provide advanced features in an SS7 network, including routing of special service numbers (e.g., 800 and 900 numbers), storing information regarding subscriber services, providing calling card validation and fraud protection, and offering advanced intelligent network (AIN) services. SCP <b>234</b> is connected to mated STPs <b>230</b> and <b>232</b>.

In the SS7 network, there are unique links between the different network elements. Table 4 provides definitions for common SS7 links.

Referring to <figref idref="DRAWINGS">FIG. 2B</figref>, mated STP pairs are connected by C links. For example, STPs <b>222</b>, <b>224</b>, mated STPs <b>226</b>, <b>228</b>, and mated STPs <b>230</b>, <b>232</b> are connected by C links (not labeled). SSPs <b>236</b>, <b>238</b> and SSPs <b>240</b>, <b>242</b> are connected by F links <b>262</b> and <b>264</b>.

Mated STPs <b>222</b>, <b>224</b> and mated STPs <b>226</b>, <b>228</b>, which are at the same hierarchical level, are connected by B links <b>270</b>,<b>272</b>,<b>244</b> and <b>282</b>. Mated STPs <b>222</b>,<b>224</b> and mated STPs <b>230</b>,<b>232</b>, which are at different hierarchical levels, are connected by D links <b>266</b>,<b>268</b>,<b>274</b> and <b>276</b>. Similarly, mated STPs <b>226</b>, <b>228</b> and mated STPs <b>230</b>, <b>232</b>, which are at different hierarchical levels, are connected by D links <b>278</b>, <b>280</b>, <b>246</b> and <b>248</b>.

SSPs <b>236</b>, <b>238</b> and mated STPs <b>222</b>, <b>224</b> are connected by A links <b>254</b> and <b>256</b>. SSPs <b>240</b>, <b>242</b> and mated STPs <b>226</b>, <b>228</b> are connected by A links <b>258</b> and <b>260</b>.

SSPs <b>236</b>, <b>238</b> can also be connected to mated STPs <b>230</b>, <b>232</b> by E links (not shown). Finally, mated STPs <b>230</b>, <b>232</b> are connected to SCP <b>234</b> by A links <b>250</b> and <b>252</b>.

For a more elaborate description of SS7 network topology, the reader is referred to Russell, Travis, Signaling System #7, McGraw-Hill, New York, N.Y. 10020, ISBN 0-07-054991-5, which is incorporated herein by reference in its entirety.

<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="77pt" align="left" /><colspec colname="2" colwidth="140pt" align="left" /><thead><row><entry namest="1" nameend="2" rowsep="1">TABLE 4</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>SS7 link terminology</entry><entry>Definitions</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Access (A) links</entry><entry>A links connect SSPs to STPs, or SCPs to</entry></row><row><entry /><entry>STPs, providing network access and database</entry></row><row><entry /><entry>access through the STPs.</entry></row><row><entry>Bridge (B) links</entry><entry>B links connect mated STPs to other mated</entry></row><row><entry /><entry>STPs.</entry></row><row><entry>Cross (C) links</entry><entry>C links connect the STPs in a mated pair to one</entry></row><row><entry /><entry>another. During normal conditions, only net-</entry></row><row><entry /><entry>work management messages are sent over</entry></row><row><entry /><entry>C links.</entry></row><row><entry>Diagonal (D) links</entry><entry>D links connect the mated STPs at a primary</entry></row><row><entry /><entry>hierarchical level to mated STPs at a secondary</entry></row><row><entry /><entry>hierarchical level.</entry></row><row><entry>Extended (E) links</entry><entry>E links connect SSPs to remote mated</entry></row><row><entry /><entry>STPs, and are used in the event that the A links</entry></row><row><entry /><entry>to home mated STPs are congested.</entry></row><row><entry>Fully associated</entry><entry>F links provide direct connections between</entry></row><row><entry>(F) links</entry><entry>local SSPs (bypassing STPs) in the event</entry></row><row><entry /><entry>there is much traffic between SSPs, or if a</entry></row><row><entry /><entry>direct connection to an STP is not available.</entry></row><row><entry /><entry>F links are used only for call setup and call</entry></row><row><entry /><entry>teardown.</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

d. SS7 Signaled Call Flow

To initiate a call in an SS7 telecommunications network, a calling party using a telephone connected to an ingress EO switch, dials a telephone number of a called party. The telephone number is passed from the telephone to the SSP at the ingress EO of the calling party's local exchange carrier (LEC). First, the SSP can process triggers and internal route rules based on satisfaction of certain criteria. Second, the SSP can initiate further signaling messages to another EO or access tandem (AT), if necessary. The signaling information can be passed from the SSP to STPs, which route the signals between the ingress EO and the terminating end office, or egress EO. The egress EO has a port designated by the telephone number of the called party. The call is set up as a direct connection between the EOs through tandem switches if no direct trunking exists or if direct trunking is full. If the call is a long distance call, i.e., between a calling party and a called party located in different local access transport areas (LATAs), then the call is connected through an inter exchange carrier (IXC) switch. Such a long distance call is commonly referred to as an inter-LATA call. LECs and IXCs are collectively referred to as the public switched telephone network (PSTN).

Passage of the Telecommunications Act of 1996, authorizing competition in the local phone service market, has permitted CLECs to compete with ILECs in providing local exchange services. This competition, however, has still not provided the bandwidth necessary to handle the large volume of voice and data communications. This is due to the limitations of circuit switching technology which limits the bandwidth of the equipment being used by the LECs, and to the high costs of adding additional equipment.

e. Circuit-Switching

Circuit switching dedicates a channel to a call for the duration of the call. Thus, using circuit switching, a large amount of switching bandwidth is required to handle the high volume of voice calls. This problem is compounded by the use of voice circuits to carry data communications over the same equipment that were designed to handle voice communications.

i. Time Division Multiplexed (TDM) Circuit Switching

TDM circuit switching creates a full-time connection or a dedicated circuit between any two attached devices for the duration of the connection. TDM divides the bandwidth down int fixed time slots in which there can be multiple time slots, each with its own fixed capacity, available. Each attached device on the TDM network is assigned a fixed portion of the bandwidth using one or more time slots depending on the need for speed. When the device is in transmit mode, the data is merely placed in this time slot without any extra overhead such as processing or translations. Therefore, TDM is protocol transparent to the traffic being carried. Unfortunately, however, when the device is not sending data, the time slots remain empty, thereby wasting the use of the bandwidth. A higher-speed device on the network can be slowed down or bottled up waiting to transmit data, but the capacity that sits idle cannot be allocated to this higher priority device for the duration of the transmission. TDM is not well suited for the bursts of data that are becoming the norm for the data needs in today's organization.

2. Data Network

<figref idref="DRAWINGS">FIG. 1B</figref> depicts an example network <b>148</b> including workstations <b>144</b> and <b>146</b> coupled to data network <b>142</b>. Data network <b>142</b> can act as a wide area network (WAN) for coupling a plurality of local area networks (LANs) together. Network <b>148</b> includes an example local area network including a plurality of host computers such as, e.g., client workstation <b>138</b> and server <b>136</b>, coupled together by wiring including network interface cards (NICs) and a hub, such as, e.g., an Ethernet hub. The LAN is coupled to data network <b>142</b> by a network router <b>140</b> which permits data traffic to be routed to workstations <b>144</b> and <b>146</b> from client <b>138</b> and server <b>136</b>.

a. Packet-Switching

Unlike voice networks <b>100</b> and <b>200</b> described above with reference to <figref idref="DRAWINGS">FIGS. 1A and 2A</figref> which transport traffic over circuit-switched connections, data network <b>148</b> transports traffic using packet switching.

Currently, internets, intranets, and similar public or private data networks that interconnect computers generally use packet switching technology. Packet switching provides for more efficient use of a communication channel than does circuit switching. Packet switched networks transport packets of information which can include various types of data such as, e.g., digitized voice, data, and video. With packet switching, many different calls can share a communication channel rather than the channel being dedicated to a single call. During a voice call, for instance, digitized voice information might be transferred between the callers only 60% of the time, with silence being transferred the other 40% of the time. With a circuit switched connection, the voice call could tie-up a communications channel that could have 50% of its bandwidth, unused because of the silence. For a data call, information might be transferred between two computers only 10% of the time. With the data call, 90% of the channel's bandwidth may go unused. In contrast, a packet-switched connection would permit the voice call, the data call and possibly other call information to all be sent over the same channel.

Packet switching breaks a media stream into pieces known as, for example, packets, cells or frames. Each packet can then be encoded with address information for delivery to the proper destination and can be sent through the network. The packets can be received at the destination and the media stream is reassembled into its original form for delivery to the recipient. This process is made possible using an important family of communications protocols, commonly called the Internet Protocol (IP).

In a packet-switched network, there is no single, unbroken physical connection between sender and receiver. The packets from many different calls share network bandwidth with other transmissions. The packets can be sent over many different routes at the same time toward the destination, and can then be reassembled at the receiving end. The result is much more efficient use of a telecommunications network's bandwidth than could be achieved with circuit-switching.

b. Routers

Data network <b>142</b> can include a plurality of network routers <b>140</b>. Network routers are used to route information between multiple networks. Routers act as an interface between two or more networks. Routers can find the best path between any two networks, even if there are several different networks between the two networks.

Network routers can include tables describing various network domains. A domain can be thought of as a local area network (LAN) or wide area network (WAN). Information can be transferred between a plurality of LANs and/or WANs via network routers. Routers look at a packet and determine from the destination address in the header of the packet, the destination domain of the packet. If the router is not directly connected to the destination domain, then the router can route the packet to the router's default router, i.e. a router higher in a hierarchy of routers. Since each router has a default router to which it is attached, a packet can be transmitted through a series of routers to the destination domain and to the destination host bearing the packet's final destination address.

c. Local Area Networks (LANs) and Wide Area Networks (WANs)

A local area network (LAN) can be thought of as a plurality of host computers interconnected via network interface cards (NICs) in the host computers. The NICs are connected via, for example, copper wires so as to permit communication between the host computers. Examples of LANs include an ethernet bus network, an ethernet switch network, a token ring network, a fiber digital data interconnect (FDDI) network, and an ATM network.

A wide area network (WAN) is a network connecting host computers over a wide area. In order for host computers on a particular LAN to communicate with a host computer on another LAN or on a WAN, network interfaces interconnecting the LANs and WANs must exist. An example of a network interface is a router discussed above.

A network designed to interconnect multiple LANs and/or WANs is known as an internet (with a lower case “i”). An internet can transfer data between any of a plurality of networks including both LANs and WANs. Communication occurs between host computers on one LAN and host computers on another LAN via, for example, an internet protocol (IP) protocol. The IP protocol is used to assign each host computer of a network, a unique IP address enabling packets to be transferred over the internet to other host computers on other LANs and/or WANs that are connected to the internet. An internet can comprise a router interconnecting two or more networks.

The “Internet” (with a capital “I”) is a global internet interconnecting networks all over the world. The Internet includes a global network of computers which intercommunicate via the internet protocol (IP) family of protocols.

An “intranet” is an internet which is a private network that uses internet software and internet standards, such as the internet protocol (IP). An intranet can be reserved for use by parties who have been given the authority necessary to use that network.

d. Switching vs. Routing

Routing is done at the middle network architecture levels on such protocols as IPX or TCP/IP. Switching is done at a lower level, at layer 2 of the OSI model, i.e. the media access control (MAC) layer.

e. TCP/IP Packet-Centric vs. ATM Circuit-Centric Data Networks

Asynchronous Transfer Mode (ATM) is a fixed- size cell switched circuit-centric data network. ATM implements virtual circuits (VCs), virtual paths (VPs) and transmission paths (TPs). A circuit-centric network like ATM sets up virtual circuits between source and destination nodes which provide QoS by dedicating the virtual circuit to a specific traffic type.

Some networks are packet-centric networks. Unlike a circuit-centric network, a packet-centric network does not use dedicated circuits through which to transfer packets. TCP/IP performs a packetization of user data to be sent between and among the various systems on the IP network. When a large file is sent down the protocol stack, the IP function is responsible for segmentation and packetization of the data. Then a header is placed on the packet for delivery to the data link The routing and switching of this data is handled at the IP (i.e. network) layer. IP is in a sense a dumb protocol. When a packet is prepared for transmission across the medium, IP does not specifically route the call across a specific channel. Instead, it places a header on the packet and lets the network deal with it. Therefore, the outward bound packets can take various routes to get from a source to a destination. This means that the packets are in a datagram form and not sequentially numbered as they are in other protocols. IP makes its best attempt to deliver the packets to the destination network interface; but it makes no assurances that data will arrive, that data will be free of errors, and that nodes along the way will concern themselves with the accuracy of the data and sequencing, or come back and alert the originator that something is wrong in the delivery mechanism. It is possible that in IP routing of a packet, the packet can be sent along the network in a loop, so IP has a mechanism in its header information to allow a certain number of “hops” or what is called “time to live” on the network. Rather than permit an undeliverable pack to loop around the network, IP has a counter mechanism that decrements every time the packet passes through a network node. If the counter expires, the node will discard the packet. Working together with IP is TCP which provides controls to ensure that a reliable data stream is sent and delivered. At the sending end, TCP puts a byte count header on information that will be delivered to the IP protocol layer and encapsulates it as part of the packet. The receiving end, when it gets packets is responsible for resequencing the packets and ensuring its accuracy. If all of the IP flow is not received correctly, the byte count acknowledgment or nonacknowledgment message can be sent back to the sending end, prompting the sending end to resend the bytes necessary to fill in the remaining portions of the packet flow. TCP buffers additional packets until after resending the nonacknowledged packet.

3. Video Network

<figref idref="DRAWINGS">FIG. 1C</figref> illustrates a conventional video network <b>150</b> such as, e.g., a cable television (CATV) network. Video network <b>150</b> can include video network <b>160</b> coupled to various video capture, distribution links and video output monitors. Video input devices can include, e.g., conference cameras <b>154</b> and <b>158</b>. Video output devices can include, e.g., televisions <b>152</b> and <b>156</b>. Video network <b>160</b> can include a variety of head end (i.e. the serving end of the cable) and distribution link equipment such as, e.g., coaxial cable television (CATV) and national television standard code (NTSC) tuner equipment for multiplexing various video signals. Standard cable systems have an immense amount of bandwidth available to them.

It is important to note that CATV is a wireless communication method. The frequencies of many video signals are distributed along the cable at the same time. A television tuner selects a particular channel by tuning into a specific frequency or a “frequency band.”

Although a cable television CATV video network often includes only one physical cable, a number of channels can simultaneously be present on the cable. This accomplished by sharing the frequency spectrum of the cable and assigning different frequency ranges to different channels using frequency division multiplexing (FDM). A broadband cable communications system can operate exactly like a CATV system. A counter to this FDM technique is division of the cable not divided into frequency bands but into time slots using time-division multiplexing (TDM). With TDM, each transmitting video station can grab the entire bandwidth of the cable,but only for a very short period of time. The cable is currently capable of carrying up to 750 MHz. FDM techniques can be used to divide the channels into a number of dedicated logical channels. Innovations have allowed a time division multiple access (TDMA) within an FDM channel.

A cable system can allow multiplexing on two separate dimensions to achieve data channels over a cable. The channels can be separated by FDM, and in a frequency band the channel can then be shared via TDMA among multiple users. The most common of the TDMA access methods on broadband cable is CSMA/CD developed by XEROX for Ethernet.

Using a single cable, a midsplit arrangement can accommodate two-way simultaneous transmission. Another way to accomodate this is to use a dual cable system.

Broadband is inherently an analog signaling method. Because video cameras, e.g., are also analog devices, a signal from a video camera (or video recorder) can be directly transmitted onto a broadband cable channel in red/green/blue (RGB) format.

G. Convergence of Voice/Data/Video Networks

Recognizing the inherent efficiency of packet-switched data networks such as the Internet, attention has recently focused on the digitization and transmission of voice, data, video and other information over converged packet-switched data networks. In order to deliver a high quality of service (QoS) end-user experience, the data networks attempt to provide mechanisms to deliver the different types of information timely and with appropriate bandwidth to provide an acceptable end-user experience.

<figref idref="DRAWINGS">FIG. 2C</figref> illustrates an example network <b>286</b> carrying voice, data and video traffic over a data network. Network <b>286</b> includes calling party <b>102</b>b homed to EO <b>104</b>b, where EO <b>104</b>b is linked to a telephony gateway <b>288</b>b. Network <b>286</b> also includes called party <b>110</b>c homed to EO <b>108</b>c, where EO <b>108</b>c is linked to a telephony gateway <b>288</b>c. EOs <b>104</b>b and <b>108</b>c and telephony gateways <b>288</b>b and <b>288</b>c can be linked to signaling network <b>114</b>. Telephony gateways <b>288</b>b and <b>288</b>c can also be coupled to data network <b>142</b> via routers <b>140</b>b and <b>140</b>c, respectively.

Still referring to <figref idref="DRAWINGS">FIG. 2C</figref>, telephony gateways <b>288</b>b and <b>288</b>c can be used to packetize voice traffic and signaling information into a form appropriate for transport over data network <b>142</b>. It would be apparent to those skilled in the art that telephony gateways <b>288</b>b and <b>288</b>c can include various computer devices designed for controlling, setting up and tearing down calls. Voice calls delivered over the data network can include, e.g., voice over packet (VoP), voice over data (VoD), voice over internet protocol (VoIP), voice over asynchronous transfer mode (VoATM), voice over frame (VoF). An example of a telephony gateway <b>288</b>b and <b>288</b>c is a media gateway control protocol (MGCP) compliant gateway available from various vendors such as, e.g., Lucent, of Parsippany, N.J., and CISCO of Palo Alto, Calif. It is important to note that other network devices such as a softswitch available from several member companies of the SoftSwitch Consortium, including Level 3 Communications of Louisville, Colo., could also be necessary to enable transport of, e.g., VoIP.

Network <b>286</b> is depicted to include other devices coupled to data network <b>142</b>. First, an H.323 compliant video-conferencing system <b>289</b> is illustrated including a camera <b>154</b>g and television <b>152</b>g and router <b>140</b>g. Second, a local area network (LAN) <b>128</b>a including a client workstation <b>138</b>a and a server <b>136</b>a are coupled to data network <b>142</b> via network router <b>140</b>a. Similarly, LAN <b>128</b>f having a client workstation <b>138</b>f and a server <b>136</b>f are coupled via network router <b>140</b>f to data network <b>142</b>.

Data Network <b>142</b> can provide for routing of packets of information through network routing devices from source locations to destination locations coupled to data network <b>142</b>. For example, data network <b>142</b> can route internet protocol (IP) packets for transmission of voice and data traffic from telephony gateway <b>288</b>b to telephony gateway <b>288</b>c. Data Network <b>142</b> represents any art-recognized packet centric data network. One well-known data network is the global Internet. Other examples include a private intranet, a packet-switched network, a frame relay network, and an asynchronous transfer mode (ATM) circuit-centric network.

In an example embodiment, data network <b>142</b> can be an IP packet-switched network. A packet-switched network such as, e.g., an IP network, unlike a circuit-switched network, does not require dedicated circuits between originating and terminating locations within the packet switched network. The packet-switched network instead breaks a message into pieces known as packets of information. Such packets can then be encapsulated with a header which designates a destination address to which the packet must be routed. The packet-switched network then takes the packets and routes them to the destination designated by the destination address contained in the header of the packet.

Routers <b>140</b>a, <b>140</b>b, <b>140</b>c, <b>140</b>d, <b>140</b>e, <b>140</b>f and <b>140</b>g can be connected to one another via physical media such as, for example, optical fiber link connections, and copper wire connections. Routers <b>140</b>a-g transfer information between one another and intercommunicate according to routing protocols.

Data network <b>142</b> could be implemented using any data network such as, e.g., IP networks, ATM virtual circuit-centric networks, frame relay networks, X.25 networks, and other kinds of LANs and WANs. Other data networks could be used interchangeably for data network <b>142</b> such as, for example, FDDI, Fast Ethernet, or an SMDS packet switched network. Frame relay and ATM are connection-oriented, circuit-centric services. Switched multi-megabyte data service (SMDS) is a connection-oriented mass packet service that offers speeds up to 45 Mbps.

1. Example Data Networks

a. Asynchronous Transfer Mode (ATM)

ATM is a high-bandwidth, low-delay, fixed-sized cell-based multiplexing network technology. Bandwidth capacity is segmented into 53-byte cells, having a header and payload fields. ATM uses fixed-length cells with the belief that the fixed length cells can be switched more easily in hardware than variable size packets and thus should result in faster transmissions in certain environments.

The ATM environment sets up virtual circuits in a circuit-centric manner. Thus, ATM segments variable length IP packet flows into fixed size cells using a segmentation and resequencing algorithm (SAR).

Each ATM cell contains a 48-byte payload field and a 5-byte header that identifies the so-called “virtual circuit” of the cell. ATM is thought suitable for high-speed combinations of voice, data, and video services. Currently, ATM access can perform at speeds as high as 622 Mbps or higher. ATM has recently been doubling its maximum speed every year.

ATM is defined by a protocol standardized by the International Telecommunications Union (ITU-T), American National Standards Institute (ANSI), ETSI, and the ATM Forum. ATM comprises a number of building blocks, including transmission paths, virtual paths, and virtual channels. Asynchronous transfer mode (ATM) is a cell based switching and multiplexing technology designed to be a general purpose connection-oriented transfer mode for a wide range of telecommunications services. ATM can also be applied to LAN and private network technologies as specified by the ATM Forum.

ATM handles both connection-oriented traffic directly or through adaptation layers, or connectionless traffic through the use of adaptation layers. ATM virtual connections may operate at either a constant bit rate (CBR) or a variable bit rate (VBR). Each ATM cell sent into an ATM network contains a small header including information that establishes a virtual circuit-centric connection from origination to destination. All cells are transferred, in sequence, over this virtual connection. ATM provides either permanent or switched virtual connections (PVCs or SVCs). ATM is asynchronous because the transmitted cells need not be periodic as time slots of data are required to be in synchronous transfer mode (STM).

ATM uses an approach by which a header field prefixes each fixed-length payload. The ATM header identifies the virtual channel (VC). Therefore, time slots are available to any host which has data ready for transmission. If no hosts are ready to transmit, then an empty, or idle, cell is sent.

ATM permits standardization on one network architecture defining a multiplexing and a switching method. Synchronous optical network (SONET) provides the basis for physical transmission at very high-speed rates. ATM can also support multiple quality of service (QoS) classes for differing application requirements by providing separate virtual circuits for different types of traffic, depending on delay and loss performance. ATM can also support LAN-like access to available bandwidth.

Cells are mapped into a physical transmission path, such as the North American DS1, DS3, and SONET; European, E1, E3, and E4; ITU-T STM standards; and various local fiber and electrical transmission payloads. All information is multiplexed and switched in an ATM network via these fixed-length cells.

The ATM cell header field identifies cell type, and priority, and includes six portions. An ATM cell header includes a generic flow control (GFC), a virtual path identifier (VPI), a virtual channel identifier (VCI), a payload type (PT), a call loss priority (CLP), and a header error check (HEC). VPI and VCI hold local significance only, and identify the destination. GFC allows a multiplexer to control the rate of an ATM terminal. PT indicates whether the cell contains user data, signaling data, or maintenance information. CLP indicates the relative priority of the cell, i.e., lower priority cells are discarded before higher priority cells during congested intervals. HEC detects and corrects errors in the header.

The ATM cell payload field is passed through the network intact, with no error checking or correction. ATM relies on higher-layer protocols to perform error checking and correction on the payload. For example, a transmission control protocol (TCP) can be used to perform error correction functions. The fixed cell size simplifies the implementation of ATM switches and multiplexers and enables implementations at high speeds.

When using ATM, longer packets cannot delay shorter packets as in other packet-switched networks, because long packets are separated into many fixed length cells. This feature enables ATM to carry CBR traffic, such as voice and video, in conjunction with VBR data traffic, potentially having very long packets, within the same network.

ATM switches take traffic and segment it into the fixed-length cells, and multiplex the cells into a single bit stream for transmission across a physical medium. As an example, different kinds of traffic can be transmitted over an ATM network including voice, video, and data traffic. Video and voice traffic are very time-sensitive, so delay cannot have significant variations. Data, on the other hand, can be sent in either connection-oriented or connectionless mode. In either case, data is not nearly as delay-sensitive as voice or video traffic. Data traffic, as e.g., spread sheet data requires accurate transmission. Therefore, ATM conventionally must discriminate between voice, video, and data traffic. Voice and video traffic requires priority and guaranteed delivery with bounded delay, while data traffic requires, simultaneously, assurance of low loss. In a converged data network, data traffic can also carry voice traffic, making it also time-dependent. Using ATM, in one embodiment, multiple types of traffic can be combined over a single ATM virtual path (VP), with virtual circuits (VCs) being assigned to separate data, voice, and video traffic.

A transmission path can include one or more VPs. Each VP can include one or more VCs. Thus, multiple VCs can be trunked over a single VP. Switching can be performed on a transmission path, VPs, or at the level of VCs.

The capability of ATM to switch to a virtual channel level is similar to the operation of a private or public branch exchange (PBX) or telephone switch in the telephone world. In a PBX switch, each channel within a trunk group can be switched. Devices which perform VC connections are commonly called VC switches because of the analogy to telephone switches. ATM devices which connect VPs are commonly referred to as VP cross-connects, by analogy with the transmission network. The analogies are intended for explanatory reasons, but should not be taken literally. An ATM cell-switching machine need not be restricted to switching only VCs and cross-connection to only VPs.

At the ATM layer, users are provided a choice of either a virtual path connection (VPC) or a virtual channel connection (VCC). Virtual path connections (VPCs) are switched based upon the virtual path identifier (VPI) value only. Users of a VPC can assign VCCs within a VPI transparently, since they follow the same route. Virtual channel connections (VCCs) are switched upon a combined VPI and virtual channel identifier (VCI) value.

Both VPIs and VCIs are used to route calls through a network. Note that VPI and VCI values must be unique on a specific transmission path (TP).

It is important to note that data network <b>142</b> can be any of a number of other data-type networks, including various packet-switched data-type networks, in addition to an ATM network.

b. Frame Relay

Alternatively, data network <b>142</b> can be a frame relay network. It would be apparent to persons having ordinary skill in the art, that a frame relay network could be used as data network <b>142</b>. Rather than transporting data in ATM cells, data could be transported in frames.

Frame relay is a packet-switching protocol used in WANs that has become popular for LAN-to-LAN connections between remote locations. Formerly frame relay access would top out at about 1.5 Mbps. Today, so-called “high-speed” frame relay offers around 45 Mbps. This speed is still relatively slow as compared with other technology such as ATM.

Frame relay services employ a form of packet-switching analogous to a streamlined version of X.25 networks. The packets are in the form of frames, which are variable in length. The key advantage to this approach it that a frame relay network can accommodate data packets of various sizes associated with virtually any native data protocol. A frame relay network is completely protocol independent. A frame relay network embodiment of data network <b>142</b> does not undertake a lengthy protocol conversion process, and therefore offers faster and less-expensive switching than some alternative networks. Frame relay also is faster than traditional X.25 networks because it was designed for the reliable circuits available today and performs less-rigorous error detection.

c. Internet Protocol (IP)

In an embodiment, data network <b>142</b> can be an internet protocol (IP) network over an ATM network. It would be apparent to those skilled in the art, that an internet protocol (IP) network over various other data link layer network such as, e.g., Ethernet, could be used as data network <b>142</b>. Rather than transporting data in fixed length ATM circuit-centric cells, data could be transported in variable length IP datagram packet-centric packets as segmented by TCP. The IP data network can lie above any of a number of physical networks such as, for example, a SONET optical network.

2. Virtual Private Networks (VPNs)

A virtual private network (VPN) is a wide area communications network operated by a telecommunications carrier that provides what appears to be dedicated lines when used, but that actually includes trunks shared among all customers as in a public network. Just as a VPN can be provided as a service through a wireline network, a VPN can be provided in a wireless network. A VPN can allow a private network to be configured within a public network.

VPNs can be provided by telecommunications carriers to customers to provide secure, guaranteed, long-distance bandwidth for their WANs. These VPNs generally use frame relay or switched multi-megabyte data service (SMDS) as a protocol of choice because those protocols define groups of users logically on the network without regard to physical location. ATM has gained favor as a VPN protocol as companies require higher reliability and greater bandwidth to handle more complex applications. VPNs using ATM offer networks of companies with the same virtual security and QoS as WANs designed with dedicated circuits.

The Internet has created an alternative to VPNs, at a much lower cost, i.e. the virtual private Internet. The virtual private Internet (VPI) lets companies connect disparate LANs via the Internet. A user installs either a software-only or a hardware-software combination that creates a shared, secure intranet with VPN-style network authorizations and encryption capabilities. A VPI normally uses browser-based administration interfaces.

3. H.323 Video Conferencing

The H.323 Recommendation for video conferencing will now be briefly overviewed. The H.323 standard provides a foundation for, for example, audio, video, and data communications across IP-based networks, including the Internet. By complying with the H.323 Recommendation, multimedia products and applications from multiple vendors can inter-operate, allowing users to communicate without concern for compatibility. H.323 promises to be the foundation of future LAN-based products multimedia applications.

H.323 is an umbrella recommendation from the International Telecommunications Union (ITU) that sets standards for multimedia communications over Local Area Networks (LANs) that do not provide a guaranteed Quality of Service (QoS). These networks dominate today's corporate desktops and include packet-switched TCP/IP and IPX over Ethernet, Fast Ethernet and Token Ring network technologies. Therefore, the H.323 standards are important building blocks for a broad new range of collaborative, LAN-based applications for multimedia communications.

The H.323 specification was approved in 1996 by the ITU's Study Group 16. Version 2 was approved in January 1998. The standard is broad in scope and includes both stand-alone devices and embedded personal computer technology as well as point-to-point and multipoint conferences. H.323 also addresses call control, multimedia management, and bandwidth management as well as interfaces between LANs and other networks.

H.323 is part of a series of communications standards that enable videoconferencing across a range of networks. Known as H.32X, this series includes H.320 and H.324, which address ISDN and PSTN communications, respectively.

The H.323 architecture defines four major components for network-based communications, including terminals, gateways, gatekeepers, and multipoint control units (MCUs).

Terminals are client endpoints on the LAN that provide real-time, two-way communications. All terminals support voice communications; video and data are optional. H.323 specifies the modes of operation required for different audio, video, and/or data terminals to work together. H.323 is the standard of next generation Internet phones, audio conferencing terminals, and video conferencing technologies.

All H.323 terminals also support H.245, which is used to negotiate channel usage and capabilities. Three other components are required: Q.931 for call signaling and call setup, a component called Registration/Admission/Status (RAS), which is a protocol used to communicate with a gatekeeper; and support for RTP/RTCP for sequencing audio and video packets.

Optional components in an H.323 terminal are video codecs, T.120 data conferencing protocols, and MCU capabilities.

A gateway is an optional element in an H.323 conference. An H.323 gateway can provide many services, the most common being a translation function between H.323 conferencing endpoints and other terminal types. This function includes translation between transmission formats (i.e. H.225.0 to H.221) and between communications procedures (i.e. H.245 to H.242). In addition, a gateway also translates between audio and video codecs and performs call setup and clearing on both the LAN side and the switched-circuit network side.

In general, the purpose of the H.323 gateway is to reflect characteristics of a LAN endpoint to an SCN endpoint and vice versa. The primary applications of gateways are likely to be establishing links with analog PSTN terminals, establishing links with remote H.320 compliant terminals over ISDN-based switched-circuit networks, and establishing links with remote H.324-compliant terminals over PSTN networks.

Gateways are not required if connections to other networks are not needed, since endpoints may directly communicate with other endpoints on the same LAN. Terminals communicate with gateways using the H.245 and Q.931 protocols.

With the appropriate transcoders, H.323 gateways <b>5806</b> can support terminals that comply with H.310, H.321, H.322, and V.70.

Many gateway functions are left to the designer. For example, the actual number of H.323 terminals that can communicate through the gateway is not subject to standardization. Similarly, the number of SCN connections, the number of simultaneous independent conferences supported, the audio/video/data conversion functions, and inclusion of multipoint functions are left to the manufacturer. By incorporating H.323 gateway technology into the H.323 specification, the ITU has positioned H.323 as the means to hold standards-based conferencing endpoints together.

The gatekeeper is the most important component of an H.323 enabled network. It can act as the central point for all calls within its zone and provides call control services to registered endpoints. In many ways, an H.323 gatekeeper acts as a virtual switch.

Gatekeepers perform two important call control functions. The first is address translation from LAN aliases for terminals and gateways to IP or IPX addresses, as defined in the RAS specification. The second function is bandwidth management, which is also designated within RAS. For instance, if a network manager has specified a threshold for the number of simultaneous conferences on the LAN, the gatekeeper can refuse to make any more connections once the threshold is reached. The effect is to limit the total conferencing bandwidth to some fraction of the total available; the remaining capacity is left for e-mail, file transfers, and other LAN protocols. A collection of all terminals, gateways, and multipoint control units which can be managed by a single gatekeeper are known as an H.323 Zone.

An optional, but valuable feature of a gatekeeper is its ability to route H.323 calls. By routing a call through a gatekeeper, it can be controlled more effectively. Service providers need this ability in order to bill for calls placed through their network. This service can also be used to re-route a call to another endpoint if a called endpoint is unavailable. In addition, a gatekeeper capable of routing H.323 calls can help make decisions involving balancing among multiple gateways. For instance, if a call is routed through a gatekeeper, that gatekeeper can then re-route the call to one of many gateways based on some proprietary routing logic.

While a gatekeeper is logically separate from H.323 endpoints, vendors can incorporate gatekeeper functionality into the physical implementation of gateways and MCUs.

A gatekeeper is not required in an H.323 system. However, if a gatekeeper is present, terminals must make use of the services offered by gatekeepers. RAS defines these as address translation, admissions control, bandwidth control, and zone management.

Gatekeepers can also play a role in multipoint connections. To support multipoint conferences, users would employ a gatekeeper to receive H.245 control channels from two terminals in a point-to-point conference. When the conference switches to multipoint, the gatekeeper can redirect the H.245 Control Channel to a multipoint controller, the MC. A gatekeeper need not process the H.245 signaling; it only needs to pass it between the terminals or between the terminals and the MC.

LANs which contain gateways could also contain a gatekeeper to translate incoming E.164 addresses into Transport Addresses. Because a Zone is defined by its gatekeeper, H.323 entities that contain an internal gatekeeper can require a mechanism to disable the internal function so that when there are multiple H.323 entities that contain a gatekeeper on a LAN, the entities can be configured into the same Zone.

The Multipoint Control Unit (MCU) supports conferences between three or more endpoints. Under H.323, an MCU consists of a Multipoint Controller (MC), which is required, and zero or more Multipoint Processors (MP). The MC handles H.245 negotiations between all terminals to determine common capabilities for audio and video processing. The MC also controls conference resources by determining which, if any, of the audio and video streams will be multicast.

The MC does not deal directly with any of the media streams. This is left to the MP, which mixes, switches, and processes audio, video, and/or data bits. MC and MP capabilities can exist in a dedicated component or be part of other H.323 components.

The present invention supports multicast for wireless base station <b>302</b>, including providing: compatibility with RFC 1112, <b>1584</b>; recognition and support of multicasting applications, including: multimedia, teleconferencing, database, distributed computing, real-time workgroups; support of broadcasting function over wireless link; preserves bandwidth, retains QoS latency performance; support of IPv6 IGMP and IPv4 IGMP multicast; group membership query, group membership report messages.

Approved in January of 1998, version 2 of the H.323 standard addresses deficiencies in version 1 and introduces new functionality within existing protocols, such as Q.931, H.245 and H.225, as well as entirely new protocols. The most significant advances were in security, fast call setup, supplementary services and T.120/H.323 integration.

G. Packet-Centric QoS-Aware Wireless Point-to-MultiPoint (PtMP) Telecommunications System

1. Wireless Point-to-MultiPoint Telecommunications System

<figref idref="DRAWINGS">FIG. 2D</figref> depicts network <b>296</b> including a point-to-multipoint (PtMP) wireless network <b>298</b> coupled via router <b>140</b>d to data network <b>142</b>. It is important to note that network <b>296</b> includes network <b>286</b> from <figref idref="DRAWINGS">FIG. 2C</figref>, plus PtMP wireless network <b>298</b>. PtMP wireless network <b>298</b> enables customer premise equipment (CPE) at a subscriber location to gain access to the various voice, data and video resources coupled to data network <b>142</b> by means of wireless connectivity over a shared bandwidth. The wireless PtMP network <b>298</b> is a packet switched network which is TCP/IP packet-centric (i.e. no dedicated circuit is created in delivering a communication IP flow) and QoS aware.

Specifically, PtMP wireless network <b>298</b> includes a wireless access point (WAP) <b>290</b>d coupled to router <b>140</b>d by, e.g., a wireline connection. A wireless access point <b>290</b>e can be similarly coupled to router <b>140</b>e by a wireline connection. WAP <b>290</b>d is in wireless communication, such as, e.g., radio frequency. (RF) communication, with one or more wireless transciever subscriber antennae <b>292</b>d and <b>292</b>e. It would be apparent to those skilled in the art that various wireless communication methods could be used such as, e.g., microwave, cellular, spread spectrum, personal communications systems (PCS), and satellite.

In an alternative embodiment, RF communication is accomplished over cable television (CATV) coaxial cable. As those skilled in the relevant art will understand, a coaxial cable functions as a waveguide over which RF waves propagate. Accordingly, it is possible for the communications link between RF transceiver subscriber antenna <b>292</b>d and WAP <b>290</b>d to be a coaxial cable. Therefore, a coaxial cable connection is analogous to a wireless connection, and is referred to as an alternative form of wireless connection in the present invention.

In another alternative embodiment, RF communication is accomplished over a satellite connection, such as, e.g., a low earth orbit (LEO) satellite connection or a high earth orbit satellite. Taking the example of an LEO satellite connection, WAP <b>290</b>d and RF transceiver subscriber antenna <b>292</b>d function as satellite gateways, with the additional functionalities described in the present invention.

As would be apparent to those skilled in the art, although the present invention has been described in the context of a point-to-multi-point network, the invention is equally applicable to a point-to-point network environment.

Referring to <figref idref="DRAWINGS">FIG. 3A</figref>, in an embodiment of the invention, WAPs <b>290</b>d and <b>290</b>e can be coupled to a wireless base station <b>302</b> where “IP flow” traffic can be queued, analyzed, characterized, classified, prioritized and scheduled, as described more fully below with reference to the ensuing figures.

Referring to <figref idref="DRAWINGS">FIG. 3B</figref>, one embodiment of the invention, antennae <b>292</b>d and <b>292</b>e are coupled to subscriber customer premise equipment (CPE) stations <b>294</b>d and <b>294</b>e, respectively (also referred to as CPEs <b>294</b>d, <b>294</b>e). Subscriber CPE stations <b>294</b>d and <b>294</b>e are coupled to various other CPE equipment via wireline or wireless connections. For example, CPE stations <b>290</b>d and <b>290</b>e can be coupled to voice calling parties <b>124</b>d, <b>124</b>e, <b>126</b>d and <b>126</b>e, fax machines <b>116</b>d and <b>116</b>e, video conferencing equipment including video monitors <b>152</b>d and <b>152</b>e, and cameras <b>154</b>d and <b>154</b>e, host computers including client computers <b>120</b>d and <b>120</b>e and servers <b>122</b>d and <b>122</b>e. Various legacy devices such as PBXs can be coupled to CPEs <b>294</b>d and <b>294</b>e. In addition, next generation technologies such as Ethernet phones available from Selsius, a subsidiary of CISCO Systems from San Jose, Calif. and other Internet appliances can be coupled via LAN connections to CPEs <b>294</b>d and <b>294</b>e. Other video conferencing equipment as well as H.323 compliant conferencing equipment can also be coupled to CPEs <b>294</b>d and <b>294</b>e.

In an embodiment of the invention, either of antennae <b>292</b>d and <b>292</b>e can communicate with both WAPs <b>290</b>d and <b>290</b>e for alternate or backup wireless communications paths.

Returning to <figref idref="DRAWINGS">FIG. 3A</figref>, it depicts an example perspective diagram <b>300</b> of a PtMP network of the present invention. Diagram <b>300</b> includes a wireless base station <b>302</b> shown in wireless communication with subscriber locations <b>306</b>a, <b>306</b>b, <b>306</b>c, <b>306</b>d, <b>306</b>e, <b>306</b>f, <b>306</b>g, <b>306</b>h, <b>306</b>i and <b>306</b>j. Specifically, wireless base station <b>302</b> communicates via wireless access point <b>290</b>d to subscriber antennae <b>292</b>a-j of subscriber locations <b>306</b>a-j.

Wireless base station <b>302</b> is coupled at interface <b>320</b> to network router <b>140</b>d by, e.g., a wireline connection. Network router <b>140</b>d is coupled to data network <b>142</b> which includes various other network routers <b>140</b>b for routing traffic to other nodes on data network <b>142</b> such as, e.g., telephony gateway <b>288</b>b.

Returning to <figref idref="DRAWINGS">FIG. 3B</figref>, it depicts block diagram <b>310</b> further illustrating the wireless PtMP of the present invention. Diagram <b>310</b> includes wireless base station <b>302</b> coupled at interface <b>320</b> to data network <b>142</b>. Also coupled to data network <b>142</b> are router <b>140</b>d and telephony gateway <b>288</b>b which is in turn coupled to a class 5 central office (CO) switch at EO <b>104</b>b. IP telephony gateway <b>288</b>b can terminate telephony traffic to PSTN facilities by, e.g., translating packets into time domain multiplexed (TDM) standard telephone signals. Wireless base station <b>302</b> is in communication with wireless CPE <b>294</b>d at subscriber location <b>306</b>d via antenna WAP <b>290</b>d and <b>292</b>d. It would be apparent to those skilled in the art that other configurations of CPE <b>294</b>d are possible, such as, e.g., one or more host computers with no telephone devices, one or more telephones with no host computers, one or more host computers and one or more telephone devices, and one or more H.323 capable video-conferencing platforms which could include a host computer with monitor and camera.

CPE <b>294</b>d is shown with several telephone devices <b>124</b>d and <b>126</b>d, e.g., analog phones, and host computers, client <b>120</b>d and server <b>122</b>d. Client <b>120</b>d and server <b>122</b>d can be coupled to CPE <b>294</b>d via a LAN connection such as, e.g., an Ethernet LAN, or via a legacy V.35 device <b>322</b>d providing a high speed data connection. Other Internet appliances capable of attachment to a data network can also be coupled to CPE <b>294</b>d.

2. Networking Protocol Stack Architecture—Wireless IP Network Access Architecture (WINAAR)

<figref idref="DRAWINGS">FIG. 4</figref> depicts the wireless IP network access architecture (WINAAR) <b>400</b> of the present invention. Architecture <b>400</b> illustrates the networking protocol stack which is a version of a TCP/IP protocol stack enhanced to support IP-centric, QoS over a packet switched, shared bandwidth, wireless PtMP connection. The networking protocol stack will be described in terms of the Open Systems Interconnect (OSI) 7 layer networking protocol stack standard which includes physical layer (OSI layer 1) <b>402</b>, data link layer (OSI layer 2) <b>404</b>, network layer (OSI layer 7) <b>406</b> and <b>408</b>, transport layer (OSI layer 4) <b>410</b> and applications layer (OSI layer 7) <b>412</b>.

a. Physical Layer

In an example embodiment, physical layer <b>402</b> can be implemented using several wireless application specific integrated circuits (wASICs), an off-the-shelf 16QAM/QPSK <b>416</b> ASIC; an Interference Mitigation and Multipath Negation (IMMUNE)/RF <b>418</b> algorithm ASIC for minimizing and/or eliminating harmful interference; and a frequency hopping (FH) <b>419</b> ASIC for providing dynamic and adaptive multi-channel transmission that optimizes data link integrity by changing frequency levels depending on the noise level of a given frequency. Physical layer <b>402</b> can include the radio frequency (RF) signal <b>415</b>.

b. Data Link Layer

Data link layer <b>404</b> lies on top of physical layer <b>402</b>. Data link layer <b>404</b> can include a media access control (MAC) layer <b>414</b> which is depicted graphically in diagram <b>400</b> as MAC layer portion <b>414</b>a and proactive reservation-based intelligent multi-media access (PRIMMA) technology portions <b>414</b>b and <b>414</b>c. Arrows <b>426</b>, <b>428</b> and <b>430</b>, respectively, illustrate that MAC layer <b>414</b> can read header information from data and multimedia applications <b>425</b>, TCP/UDP <b>427</b> and IP <b>429</b> layers to analyze and schedule an IP packet of an “IP flow.” IP packets of the IP flow are identified by analyzing the header information to determine QoS requirements of the IP flow, so that the IP flow can be characterized, classified, presented, prioritized and scheduled.

c. Network Layer

1. Internet Protocol (IP)

Network layer <b>408</b> is the Internet protocol (IP) <b>429</b>. As will be discussed further below and as already discussed above with reference to data network <b>142</b>, IP is a standard protocol for addressing packets of information. Referring now to <figref idref="DRAWINGS">FIG. 7</figref>, IP header fields <b>702</b> can include, e.g., source and destination IP addresses, IP type of service (TOS), IP time to live (TTL), and protocol fields. IP is a datagram protocol that is highly resilient to network failures, but does not guarantee sequence delivery. Routers send error and control messages to other routers using the Internet control message protocol (ICMP). ICMP can also provide a function in which a user can send a “ping” (echo packet) to verify reachability and round trip delay of an IP-addresse host. Another OSI layer 3 protocol is address resolution protocol (ARP) which can directly interface to the data link layer. ARP maps a physical address, e.g., an Ethernet MAC address, to an IP address.

2. Internet Protocol (IP)v4 and IPv6

IP <b>429</b> of network layer <b>408</b> can be, e.g., an IP version 4 (IPv4) or an IP version 6 (IPv6). IPv6 (sometimes called next-generation internet protocol or IPng) is a backward-compatible extension of the current version of the Internet protocol, IPv4. IPv6 is designed to solve problems brought on by the success of the Internet (such as running out of address space and router tables). IPv6 also adds needed features, including circuiting security, auto-configuration, and real-time services similar to QoS. Increased Internet usage and the allocation of many of the available IP addresses has created an urgent need for increased addressing capacity. IPv4 uses a 32-byte number to form an address, which can offer about 4 billion distinct network addresses. In comparison, IPv6 uses 128-bytes per address, which provides for a much larger number of available addresses.

3. Resource Reservation Protocol (RSVP)

IP <b>429</b> of network layer <b>408</b> can have RSVP enhancement. Developed to enhance IPv4 with QoS features, RSVP is supposed to let network managers allocate bandwidth based on the bandwidth requirements of an application. Basically, RSVP is an emerging communications protocol that is hoped to signal a router to reserve bandwidth for real-time transmission of data, video, and audio traffic.

Resource reservation protocols that operate on a per-connection basis can be used in a network to elevate the priority of a given user temporarily. RSVP runs end to end to communicate application requirements for special handling. RSVP identifies a session between a client and a server and asks the routers handling the session to give its communications a priority in accessing resources. When the session is completed, the resources reserved for the session are freed for the use of others.

RSVP unfortunately offers only two levels of priority in its signaling scheme. Packets are identified at each router hop as either low or high priority. However, in crowded networks, two-level classification may not be sufficient. In addition, packets prioritized at one router hop might be rejected at the next.

Accepted as an IETF standard in 1997, RSVP does not attempt to govern who should receive bandwidth, and questions remain about what will happen when several users all demand a large block of bandwidth at the same time. Currently, the technology outlines a first-come, first-served response to this situation. The IETF has formed a task force to consider the issue.

Because RSVP provides a special level of service, many people equate QoS with the protocol. For example, Cisco currently uses RSVP in its IPv4-based internetwork router operating system to deliver IPv6-type QoS features. However, RSVP is only a small part of the QoS picture because it is effective only as far as it is supported within a given client/server connection. Although RSVP allows an application to request latency and bandwidth, RSVP does not provide for congestion control or network-wide priority with the traffic flow management needed to integrate QoS across an enterprise. Further, RSVP does not address the particular challenges related to delivering packets over a wireless medium.

The present invention supports RSVP by providing: (1) compatibility with RFC 2205; (2) recognition and support of RSVP messages, including: Path messages, Reservation (Resv), Path teardown messages, Resv teardown messages, Path error messages, Resv error messages, and Confirmation messages; (3) recognition and support of RSVP objects, including: Null, Session, RSVP_Hop, Time_Values, Style, Flowspec, Sender_Template, Sender_Tspec, Adspec, Error_Spec, Policy_Data, Integrity, and Scope, Resv Confirm; (4) configurable translation of RSVP Flowspecs for QoS resource allocation in wireless base station <b>302</b>.

The present invention provides support of DiffServ and RSVP/int-serv by providing: (1) support of RFC 2474 and 2475; (2) DiffServ in the core of Internet; (3) RSVP/int-serv for hosts and edge networks; (4) admission control capability for DiffServ compatibility; (5) differentiated services (DSs) (a field marking supported for use by DiffServ, and translation into a wireless base station <b>302</b> resource allocation); and (6) support for binding of multiple end-to-end sessions to one tunnel session.

4. Real-time Transport Protocol (RTP) and Real-time Control Protocol (RTCP)

TCP of transport layer <b>410</b> can have a RTP and RTCP enhancement. Real-time transport protocol (RTP) is an emerging protocol for the Internet championed by the audio/video transport workgroup of the IETF. Referring to <figref idref="DRAWINGS">FIG. 7</figref>, RTP and RTCP header fields <b>708</b> can include several sub fields of information. RTP supports real-time transmission of interactive voice and video over packet-switched networks. RTP is a thin protocol that provides content identification, packet sequencing, timing reconstruction, loss detection, and security. With RTP, data can be delivered to one or more destinations, with a limit on delay.

RTP and other Internet real-time protocols, such as the Internet stream protocol version 2 (ST2), focus on the efficiency of data transport. RTP and other Internet real-time protocols like RTCP are designed for communications sessions that are persistent and that exchange large amounts of data. RTP does not handle resource reservation or QoS control. Instead, RTP relies on resource reservation protocols such as RSVP, communicating dynamically to allocate appropriate bandwidth.

RTP adds a time stamp and a header that distinguishes whether an IP packet is data or voice, allowing prioritization of voice packets, while RSVP allows networking devices to reserve bandwidth for carrying unbroken multimedia data streams.

Real-time Control Protocol (RTCP) is a companion protocol to RTP that analyzes network conditions. RTCP operates in a multi-cast fashion to provide feedback to RTP data sources as well as all session participants. RTCP can be adopted to circumvent datagram transport of voice-over-IP in private IP networks. With RTCP, software can adjust to changing network loads by notifying applications of spikes, or variations, in network transmissions. Using RTCP network feedback, telephony software can switch compression algorithms in response to degraded connections.

5. IP Multi-Casting Protocols

IP <b>429</b> of network layer <b>408</b> can also support multi-casting protocols. Digital voice and video comprise of large quantities of data that, when broken up into packets, must be delivered in a timely fashion and in the right order to preserve the qualities of the original content. Protocol developments have been focused on providing efficient ways to send content to multiple recipients, transmission referred to as multi-casting. Multi-casting involves the broadcasting of a message from one host to many hosts in a one-to-many relationship. A network device broadcasts a message to a select group of other devices such as PCS or workstations on a LAN, WAN, or the Internet. For example, a router might send information about a routing table update to other routers in a network.

Several protocols are being implemented for IP multi-casting, including upgrades to the Internet protocol itself. For example, some of the changes in the newest version of IP, IPv6, will support different forms of addressing for uni-cast (point-to-point communications), any cast (communications with the closest member of a device group), and multi-cast. Support for IP multi-casting comes from several protocols, including the Internet group management protocol (IGMP), protocol-independent multi-cast (PIM) and distance vector multi-cast routing protocol (DVMRP). Queuing algorithms can also be used to ensure that video or other multi-cast data types arrive when they are supposed to without visible or audible distortion.

Real-time transport protocol (RTP) is currently an IETF draft, designed for end-to-end, real-time delivery of data such as video and voice. RTP works over the user datagram protocol (UDP), providing no guarantee of in-time delivery, quality of service (QoS), delivery, or order of delivery. RTP works in conjunction with a mixer and translator and supports encryption and security. The real-time control protocol (RTCP) is a part of the RTP definition that analyzes network conditions. RTCP provides mandatory monitoring of services and collects information on participants. RTP communicates with RSVP dynamically to allocate appropriate bandwidth.

Internet packets typically move on a first-come, first-serve basis. When the network becomes congested, Resource Reservation Protocol (RSVP) can enable certain types of traffic, such as video conferences, to be delivered before less time-sensitive traffic such as E-mail for potentially a premium price. RSVP could change the Internet's pricing structure by offering different QoS at different prices. Using SLAs, different QoS levels can be provided to users at CPE location stations depending on SLA subscription level.

The RSVP protocol can be used by a host, on behalf of an application, to request a specific QoS from the network for particular data streams or flows. Routers can use the RSVP protocol to deliver QoS control requests to all necessary network nodes to establish and maintain the state necessary to provide the requested service. RSVP requests can generally, although not necessarily, result in resources being reserved in each node along the data path.

RSVP is not itself a routing protocol. RSVP is designed to operate with current and future uni-cast and multi-cast routing protocols. An RSVP process consults the local routing database to obtain routes. In the multi-cast case for example, the host sends IGMP messages to join a multi-cast group and then sends RSVP messages to reserve resources along the delivery paths of that group. Routing protocols determine where packets are forwarded. RSVP is concerned with only the QoS of those packets as they are forwarded in accordance with that routing. The present invention delivers QoS-aware wireless PtMP access to users over a shared wireless bandwidth, and can take into account priority information provided within packet headers of packets in IP flows received for transmission over the wireless base station's bandwidth.

d. VPN Networks (Example Optional Protocols) at Network Layer

Also at network layer <b>406</b> are depicted example optional virtual private network (VPN) protocols point to point protocol (PPP) <b>420</b> and IPsec <b>422</b>, discussed below.

A plurality of protocol standards exist today for VPNs. For example, IP security (IPsec), point-to-point tunneling protocol (PPTP), layer 2 forwarding protocol (L2F) and layer 2 tunneling protocol (L2TP). The IETF has proposed a security architecture for the Internet protocol (IP) that can be used for securing Internet-based VPNs. IPsec facilitates secure private sessions across the Internet between organizational firewalls by encrypting traffic as it enters the Internet and decrypting it at the other end, while allowing vendors to use many encryption algorithms, key lengths and key escrow techniques. The goal of IPsec is to let companies mix-and-match the best firewall, encryption, and TCP/IP protocol products.

IPsec is designed to link two LANs together via an encrypted data stream across the Internet.

1. Point-to-Point Tunneling Protocol (PPTP)

Point-to-point tunneling protocol (PPTP) provides an alternate approach to VPN security than the use of IPsec. Unlike IPsec, which is designed to link two LANs together via an encrypted data stream across the Internet, PPTP allows users to connect to a network of an organization via the Internet by a PPTP server or by an ISP that supports PPTP. PPTP was proposed as a standard to the IETF in early 1996. Firewall vendors are expected to support PPTP.

PPTP was developed by Microsoft along with 3Com, Ascend and US Robotics and is currently implemented in WINDOWS NT SERVER 4.0, WINDOWS NT WORKSTATION 4.0, WINDOWS 95 via an upgrade and WINDOWS 98, available from Microsoft Corporation of Redmond, Wash.

The “tunneling” in PPTP refers to encapsulating a message so that the message can be encrypted and then transmitted over the Internet. PPTP, by creating a tunnel between the server and the client, can tie up processing resources.

2. Layer 2 Forwarding (L2F) Protocol

Developed by Cisco, layer 2 forwarding protocol (L2F) resembles PPTP in that it also encapsulates other protocols inside a TCP/IP packet for transport across the Internet, or any other TCP/IP network, such as data network <b>112</b>. Unlike PPTP, L2F requires a special L2F-compliant router (which can require changes to a LAN or WAN infrastructure), runs at a lower level of the network protocol stack and does not require TCP/IP routing to function. L2F also provides additional security for user names and passwords beyond that found in PPTP.

3. Layer 2 Tunneling Protocol (L2TP)

The layer 2 tunneling protocol (L2TP) combines specifications from L2F with PPTP. In November 1997, the IETF approved the L2TP standard. Cisco is putting L2TP into its Internet operating system software and Microsoft is incorporating it into WINDOWS NT 5.0. A key advantage of L2TP over IPsec, which covers only TCP/IP communications, is that L2TP can carry multiple protocols. L2TP also offers transmission capability over non-IP networks. L2TP however ignores data encryption, an important security feature for network administrators to employ VPNs with confidence.

4. IPsec

IP flows using the security encryption features of IPsec <b>422</b> are supported by the present invention. The integration of IPsec <b>422</b> flows of WINAAR architecture <b>400</b> are described below in the downlink and uplink directions with reference to <figref idref="DRAWINGS">FIGS. 17A and 17B</figref>, respectively. Wireless base station <b>302</b> supports prioritization of IPsec encrypted streams by placing the firewall at the wireless base station and unencrypting the datastream and packet header information prior to identification analysis. Through the wireless transmission medium, the frame stream already includes encryption of the frame data and implements frequency hopping.

IPsec provides for secure data transmission for, e.g., VPNs and eCommerce security. IPsec is compatible with RFC 2401-2407. IPsec is supported with IPv4 and IPv6, and also IPsec tunnel mode. Wireless base station <b>302</b> security protocol support includes authentication header (AH) and encapsulating security payload (ESP). Wireless base station <b>302</b> supports IPsec authentication (MD<b>5</b>), encryption algorithms, and automatic key management (IKE and ISAKMP/Oakley). Wireless base station <b>302</b> provides for a choice of transport mode or tunnel mode and selectable granularity of security service, such as, e.g., providing a single encrypted tunnel for all traffic between two hosts, or providing separate encrypted tunnel for each TCP connection between hosts.

e. Transport Layer

1. Transmission Control Protocol/Internet Protocol (TCP/IP) and User Datagram Protocol/Internet Protocol (UDP/IP)

As already discussed, interne protocol (IP) has become the primary networking protocol used today. This success is largely a part of the Internet, which is based on the transmission control protocol/internet protocol (TCP/IP) family of protocols. TCP/IP is the most common method of connecting PCs, workstations, and servers. TCP/IP is included as part of many software products, including desktop operating systems (e.g., Microsoft's Windows 95 or Windows NT) and LAN operating systems.

The most pervasive LAN protocol to date, has been IPX/SPX from Novell's NetWare network operating system (NOS). However, IPX/SPX is losing ground to TCP/IP. Novell now incorporates native IP support into NetWare, ending NetWare's need to encapsulate IPX packets when carrying them over TCP/IP connections. Both UNIX and Windows NT servers can use TCP/IP. Banyan's VINES, IBM's OS/2 and other LAN server operating systems can also use TCP/IP.

Transport layer four <b>410</b> can include transmission control protocol (TCP) or user datagram protocol (UDP) <b>427</b> part of the standard TCP/UDP/IP protocol family suite of networking protocols. As will be discussed further below and as already mentioned briely above with reference to data network <b>142</b>, TCP is a standard protocol for segmenting traffic into packets, transmitting, reassembling and retransmitting packets of information between a source and destination IP address. Referring now to <figref idref="DRAWINGS">FIG. 7</figref>, TCP header fields <b>706</b> can include, e.g., source and destination port numbers, window size, urgent pointer, flags (SYN, ISN, PSH, RST, FIN), and maximum segment size (MSS). Both TCP and UDP provide a capability for the TCP/IP host to distinguish among multiple applications through port numbers. TCP can provide for a reliable, sequenced delivery of data to applications. TCP can also provide adaptive flow control, segmentation, and reassembly, and prioritization of data flows. UDP only provides unacknowledged datagram capability. The recently defined real time protocol (RTP), RFC 1889, can provide real time capabilities in support of multimedia applications, for example.

TCP uses a window-based flow control. Each TCP source has a dynamically changing transmit window that determines how many packets it can transmit during each successive round-trip time (RTT). The TCP source can continue increasing its transmit window if no packets were lost within the last RTT. Once congestion is detected, the source TCP throttles back its transmission, i.e. it “backs-off,” via a multiplicative decrease. An increasing width of the so-called TCP window versus time corresponds to increasingly longer bursts of packets. TCP's window flow-controlled protocol exhibits this effect of increasing throughput and buffer utilization until terminated by loss, followed by a period of rapid backoff.

TCP works over IP to provide end-to-end reliable transmission of data across data network <b>142</b>. TCP controls the amount of unacknowledged data in transit by dynamically reducing either window size or segment size. The reverse is also true in that increased window or segment size values achieve higher throughput if all intervening network elements have low error rates, support the larger packets, and have sufficient buffering to support larger window sizes.

f. Application Layer

Applications layer seven <b>412</b> can include applications <b>426</b> such as, e.g., over TCP, hypertext transport protocol (HTTP), file transfer protocol (FTP), TELNET remote terminal login, and simple simple mail transfer protocol (SMTP); and over UDP, simple network management protocol (SNMP), RPC, NFS, and TFTP. Other applications can also run over the network stack such as, e.g., a world wide web browser such as NETSCAPE NAVIGATOR available from AOL of Reston, Va., a spreadsheet application program such as LOTUS 123 available from IBM of Armonk, N.Y. or a video teleconferencing program such as MS NetMeeting available from MICROSOFT of Redmond, Wash. Packets transmitted from such applications could require special handling and prioritization to achieve an appropriate end-user QoS.

3. PRIMMA-System IP Flow Prioritization

a. Scheduling of Mixed IP Flows

<figref idref="DRAWINGS">FIG. 6</figref> illustrates block diagram <b>600</b> representing scheduling of mixed IP flows. Block diagram <b>600</b> shows the scheduling of wireless base station <b>302</b>. The functionality of block diagram <b>600</b> includes PRIMMA management of Internet, VPN, and realtime IP flows. Referring back to <figref idref="DRAWINGS">FIG. 3A</figref>, wireless IP flows are coming from data network <b>142</b> via network router <b>140</b>d to interface <b>320</b> of wireless base station <b>302</b>. IP flows are then scheduled for transmission from wireless base station <b>302</b> via antenna <b>290</b>d through subscriber location <b>306</b>d via antenna <b>292</b>d.

Referring back to block diagram <b>600</b> of <figref idref="DRAWINGS">FIG. 6</figref>, illustrated therein are the downlink and uplink flows between interface <b>320</b> and wireless base station antenna <b>290</b>d. An IP flow, as described herein, refers to a series of related packets of data transmitted from a source to a destination post computer. IP flow <b>630</b> from data network <b>142</b> (over interface <b>320</b>) comprises Internet IP flows <b>608</b>, VPN IP flows <b>610</b>, and realtime IP flows <b>612</b>. IP flow <b>630</b> is in the downlink direction.

Downlink IP flow analyzer <b>602</b> (hereinafter downlink flow analyzer <b>602</b>) analyzes Internet IP flow <b>608</b>, VPN IP flow <b>610</b> and realtime IP flow <b>612</b>. IP flow analyzer <b>602</b> is described further below with reference to <figref idref="DRAWINGS">FIGS. 8A and 15A</figref>. IP flow analyzer <b>602</b> receives packets and analyzes packet header fields to identify new or existing IP flows. IP flow analyzer <b>602</b> can also characterize QoS requirements for the IP flow depending on packet header field contents. IP flow analyzer <b>602</b> can classify the IP flow and associate a given packet with other packets from an existing IP flow and can group together IP flows with similar QoS requirements. IP flow analyzer <b>602</b> can also present the IP flows to a flow scheduler.

Downlink PRIMMA MAC IP flow scheduler <b>604</b> (hereinafter downlink flow scheduler <b>604</b>) schedules received IP flows <b>608</b>, <b>610</b>, and <b>612</b> for transmission in the downlink direction. Downlink flow scheduler <b>604</b> can prioritize the different classes of IP flows. For example, scheduler <b>604</b> can reserve slots in downlink frames for latency sensitive IP flows; for FTP type IP flows <b>608</b>, scheduler <b>604</b> can allocate large amounts of bandwidth for file transfer; and for e-mail type IP flows <b>608</b>, a lower priority can be given to packets. In prioritizing allocation of wireless bandwidth frame slots, downlink flow scheduler <b>604</b> can take into account the fact that an IP flow <b>630</b> is a VPN IP flow <b>610</b> from a virtual private network (VPN), such as, e.g., a remote branch office tieing into a corporate network. All traffic from a VPN can be given a higher priority or specific types of VPN traffic can request particular service levels. Downlink flow scheduler <b>604</b> can prioritize realtime IP flows <b>612</b> such that their arrival at CPEs <b>294</b> at CPE subscriber locations <b>306</b> will occur as required.

Downlink PRIMMA MAC segmentation and resequencing (SAR) and framer <b>606</b> (hereinafter downlink SAR and framer <b>606</b>) segments and frames the data packets of received IP flows into frames for transmission over the wireless medium to CPEs <b>294</b> at CPE subscriber locations <b>306</b>. For example IP flow <b>616</b>, <b>624</b> can be transmitted to CPE <b>294</b>d at CPE subscriber location <b>306</b>d, via base station antenna <b>290</b>d over a wireless medium to subscriber antenna <b>292</b>d and CPE <b>294</b>d at CPE subscriber location <b>306</b>d. In the present invention, the term wireless medium is used to broadly encompass not only propagation of RF transmissions over cellular communications, but also RF transmissions over satellite communications and cable (e.g., coaxial cable) communications.

In the uplink direction, IP flow <b>626</b> from CPE <b>294</b>d at CPE subscriber station <b>306</b>d is received at wireless base station antenna <b>290</b>d. IP flow <b>626</b> can include Internet IP flow <b>618</b>, VPN IP flow <b>620</b> and realtime IP flow <b>622</b>. Uplink IP flow analyzer <b>632</b> (hereinafter uplink flow analyzer <b>632</b>) analyzes Internet IP flow <b>618</b>, VPN IP flow <b>620</b> and realtime IP flow <b>622</b>. Uplink flow analyzer <b>632</b> is described further below with reference to <figref idref="DRAWINGS">FIGS. 8B and 15B</figref>. In one embodiment, the functionality of IP flow analyzer <b>632</b> occurs at the CPE <b>294</b>d at subscriber CPE location <b>306</b>d and sends a request to transmit data up to wireless base station <b>302</b>, including information about an IP flow for which CPE <b>294</b>d would like to schedule an uplink slot.

Uplink PRIMMA MAC IP flow scheduler <b>634</b> (hereinafter uplink flow scheduler <b>634</b>) can schedule the requested IP flow. In one embodiment, the functionality of scheduler <b>634</b> can be performed at CPE <b>294</b>d at subscriber CPE location <b>306</b>d. In another embodiment, the functionality of scheduler <b>634</b> can be performed at the wireless base station <b>302</b>. An advantage of placing uplink flow scheduler <b>634</b> at the wireless base station is that this provides efficiencies particularly in a point-to-multi-point architecture. It is more efficient to have one centralized scheduler at the base station <b>302</b> rather than to place multiple uplink flow schedulers <b>634</b> at CPEs <b>294</b> of subscriber CPE locations <b>306</b>.

Uplink PRIMMA MAC segmentation and resequencing (SAR) and framer <b>636</b> (hereinafter SAR and framer <b>636</b>) can segment and frame the data packets of IP flows into frames for transmission over the wireless medium from CPE <b>294</b> at CPE subscriber locations <b>306</b> to wireless base station <b>302</b> for further transmission over data network <b>142</b>. IP flow <b>626</b> from CPE <b>294</b>d at CPE subscriber location <b>306</b>d can be transmitted to base station antenna <b>290</b>d over a wireless medium such as, e.g., RF communication, cable modem and satellite communication, from subscriber antenna <b>292</b>d coupled to CPE <b>294</b>d at CPE subscriber location <b>306</b>d.

b. Summary of Downlink and Uplink SubFrame Prioritization

Block diagram <b>800</b> of <figref idref="DRAWINGS">FIG. 8A</figref> summarizes an exemplary downlink analysis, prioritization and scheduling function. Similarly, block diagram <b>830</b> of <figref idref="DRAWINGS">FIG. 8B</figref> summarizes an exemplary uplink analysis prioritization and scheduling function. Block diagram <b>800</b> and <b>830</b> are more detailed views of the function of block diagram <b>600</b> of <figref idref="DRAWINGS">FIG. 6</figref>.

Beginning with block diagram <b>800</b> (of <figref idref="DRAWINGS">FIG. 8A</figref>), it depicts how IP flow prioritization and scheduling of a shared wireless bandwidth is performed in the downlink path, from data network <b>142</b>—to router <b>140</b>d—to interface <b>320</b>—to wireless base station <b>302</b>—WAP <b>290</b>d—over a wireless medium—to wireless transceiver subscriber antenna <b>292</b>d—to subscriber CPE station <b>294</b>d at subscriber CPE location <b>306</b>d.

IP flow analyzer <b>602</b> performs the function of identifying, characterizing, classifying, and presenting data packets to a downlink frame scheduler. The functions of identifying, characterizing, classifying and presenting the data packets are described with respect to <figref idref="DRAWINGS">FIG. 15A</figref>.

During identification, it is determined whether a data packet of an incoming IP data flow is known to the system, i.e. is an “existing IP flow”, or rather is the first data packet of a new IP data flow, based on fields in a packet header section. Identification can also include, e.g., determining the source of the packet in order to extrapolate the type of information in the packet payload.

During characterization, a new data packet (of a new IP data flow) previously unknown to the system is characterized based on the packet header information to determine the QoS requirements for the IP data flow, and to identify the subscriber CPE station that will receive the IP data flow.

During classification, the new IP data flow is classified into a communications priority class. Classification can also include grouping together packets from different IP flows having similar characteristics into a single class. Example class groupings of IP flows <b>630</b> are illustrated as IP classes <b>810</b>a-<b>810</b>g.

During presentation, the new IP data flow is initialized and presented to a downlink flow scheduler <b>604</b>.

Downlink flow scheduler places the data packets of an IP data flow into a class queue based on class queue priorities, and using a set of rules, schedules the data packets for transmission over a wireless medium to a subscriber CPE station <b>294</b> at subscriber CPE location <b>306</b> with an advanced reservation algorithm. The rules are determined by inputs to the downlink flow scheduler based on, e.g., a hierarchical class-based prioritization, a virtual private network (VPN) directory enabled data priority (such as, for example, directory enabled networking (DEN)), and a service level agreement priority. The advanced reservation algorithm for use in scheduling, e.g., isochronous traffic, is described with respect to <figref idref="DRAWINGS">FIG. 14</figref> below.

SAR and framer <b>606</b> breaks up, sequences, and frames the data packets for wireless transmission from WAP <b>290</b>d over the wireless medium to a wireless transceiver subscriber antenna <b>292</b>. Illustrated in block diagram <b>800</b> are a number of subscriber applications <b>820</b>a-<b>820</b>e running on devices such as, e.g., subscriber workstation <b>120</b>d (not shown), connected to subscriber CPE stations <b>294</b>a-e (not shown) located at subscriber CPE locations <b>306</b>a-<b>306</b>e. Each subscriber CPE location <b>306</b> can house one or more subscriber CPE stations <b>294</b>, and each subscriber CPE station <b>294</b> can receive and transmit one or more IP data flows to and from one or more subscriber workstations <b>120</b>. In fact, each application connected to a single CPE station can receive or transmit multiple IP data flows.

Referring to subscriber CPE location <b>306</b>a of <figref idref="DRAWINGS">FIG. 8A</figref>, a CPE SAR and framer <b>814</b>a resequences the received data and transmits it through CPE flow scheduler <b>816</b>a, and CPE IP flow analyzer <b>818</b>a, to subscriber application <b>820</b>a. CPE IP flow schedulers <b>816</b>a-<b>816</b>e can perform the same function as downlink flow scheduler <b>604</b> for uplink traffic. Similarly, CPE IP flow analyzers <b>818</b>a-<b>818</b>e perform the same function as downlink flow analyzer <b>602</b>.

In an embodiment of the invention, in downlink mode, CPE IP flow schedulers <b>816</b>a-<b>816</b>e and CPE IP flow analyzers <b>818</b>a-<b>818</b>e perform no function.

Block diagram <b>800</b> illustrates the logical functions performed on the downlink path, not necessarily the physical locations of these functions.

The functions of subscriber applications <b>820</b>a-<b>820</b>e, and CPE SAR and framers <b>814</b>a-<b>814</b>e can be performed in the actual subscriber CPE stations <b>294</b> connected over a wireless connection to wireless base station <b>302</b>.

Block diagram <b>800</b> lists an exemplary set of priorities <b>812</b> used by downlink flow scheduler <b>604</b> to place received data packets into priority class queues. Listed are the following set of example priorities: latency-sensitive UDP prority <b>812</b>a, high priority <b>812</b>b, intermediate priority <b>812</b>c, initial hypertext transfer protocol (HTTP) screens priority <b>812</b>d, latency-neutral priority <b>812</b>e, file transfer protocol (FTP), simple mail transfer protocol (SMTP) and other e-mail traffic priority <b>812</b>f and low priority <b>812</b>g. Persons skilled in the art will recognize that many different priority classes are possible, depending upon the QoS requirements of the end-users. Latency-sensitive UDP priority data can refer to data that has the highest priority because it is sensitive to jitter (i.e., time synchronization is important) and latency (i.e., the amount of time passage between IP data flows in reverse directions). High priority <b>812</b>b can refer to, e.g., premium VPN service, and a high priority SLA service. Intermediate priority <b>812</b>c can refer to, e.g., a value VPN service level and an intermediate level SLA service. HTTP screens priority <b>812</b>d can refer to the download of HTTP data, for example, an initial HTTP screen, which is important for making an Internet user feel as if he has a great deal of bandwidth available for his Internet session. Latency-neutral priority <b>812</b>e can refer to data that is neutral to latency, such as, e.g., e-mail traffic. FTP, SMTP priority <b>812</b>f data includes data that is insensitive to latency and jitter, but requires a large amount of bandwidth to be downloaded accurately because of the size of a transmission. Finally, low priority data <b>812</b>g can refer to data that can be transmitted over a long period of time, as when one network device transmits its status information to another network device on a 24 hour basis.

Block diagram <b>830</b> (of <figref idref="DRAWINGS">FIG. 8B</figref>) depicts how IP flow analysis, prioritization and scheduling of the shared wireless bandwidth is performed in the uplink path, from subscriber CPE station <b>294</b>d—to wireless transceiver subscriber antenna <b>292</b>d—over the wireless medium—to WAP <b>290</b>d—to wireless base station <b>302</b>—to interface <b>320</b>—to router <b>140</b>d—to data network <b>140</b>.

Block diagram <b>830</b> includes uplink flow analyzer <b>632</b>, uplink flow scheduler <b>634</b> and uplink SAR and framer <b>636</b>. These components are similar in function to downlink flow analyzer <b>602</b>, downlink flow scheduler <b>604</b> and downlink SAR and framer <b>606</b>, but instead analyze, schedule and sequence and frame data packets being transmitted from subscriber workstations <b>120</b> of subscriber CPE stations <b>294</b> (at subscriber CPE locations <b>306</b>a-<b>306</b>e) over the wireless medium, and transmit the data packets to interface <b>320</b> for transmission to data network <b>142</b>.

Illustrated in <figref idref="DRAWINGS">FIG. 8B</figref> are subscriber applications <b>820</b>a-<b>820</b>e, which are the same applications shown in <figref idref="DRAWINGS">FIG. 8A</figref>. Also shown therein are CPE IP flow analyzers <b>819</b>a-<b>819</b>e, CPE IP flow schedulers <b>817</b>a-<b>817</b>e, and CPE SAR and framers <b>815</b>a-<b>815</b>e. These components function analogously to subscriber applications <b>820</b>a-<b>820</b>e, CPE IP flow analyzers <b>818</b>a-<b>818</b>e, CPE IP flow schedulers <b>816</b>a-<b>816</b>e, and CPE SAR and framers <b>814</b>a-<b>814</b>e. However, these components function to analyze, schedule and transmit IP flows in the uplink path, from subscriber CPE stations (at subscriber CPE locations <b>306</b>a-<b>306</b>e) to wireless base station <b>302</b> for routing to destination host workstations <b>136</b> (not shown).

As noted, multiple applications can be connected to one or more subscriber CPE stations at subscriber CPE locations <b>306</b>a-<b>306</b>e. To prevent collisions between multiple applications contending for a fixed number of bandwidth allocations for uplink communication, in one embodiment of the present invention a reservation scheduling system is used. The bandwidth allocations for data packets are called frame slots, and are described below with respect to <figref idref="DRAWINGS">FIGS. 12A-12Q, 14, 16A and 16B</figref>.

Block diagram <b>830</b> illustrates the logical functions performed on the uplink path, not necessarily the physical locations of these functions.

For example, in one embodiment, the analysis function of IP flow analyzer <b>632</b> which identifies a packet for uplink, characterizes and classifies the packet, can occur in a preferred embodiment in CPE IP flow analyzers <b>819</b>a-<b>819</b>e at the CPE subscriber stations <b>294</b>a-<b>294</b>e (not shown) at subscriber locations <b>306</b>a-<b>306</b>e.

Also, one embodiment, the functions of CPE IP flow schedulers <b>817</b>a-<b>817</b>f for scheduling uplinks subframe slots can be performed in wireless base station <b>302</b> for each of the subscriber CPE stations <b>294</b> connected over the wireless connection to wireless base station <b>302</b>.

In this embodiment, the scheduling function is performed at uplink flow scheduler <b>634</b> at wireless base station <b>302</b> based on classification information provided to the wireless base station <b>302</b> through an uplink IP flow reservation request from the CPE station. By placing all scheduling function at the wireless base station <b>302</b>, overall system quality of service can be optimized by centralizing the control of scheduling.

In another embodiment, however, their respective functions can be performed in the actual subscriber CPE stations.

In the reservation scheduling function of this embodiment, each subscriber CPE station requests the reservation of frame slots for its uplink transmissions using a reservation request block (RRB) of the TDMA airframe, described further below with reference to <figref idref="DRAWINGS">FIGS. 12A-12O</figref>, before it is permitted to communicate in the uplink path with interface <b>320</b>. After the reservation request, uplink flow scheduler <b>634</b> transmits, as indicated by line <b>640</b>, to the requesting subscriber CPE station <b>294</b> a description of one or more slots which the CPE station <b>294</b> can use to transmit its uplink data packets from source subscriber workstations <b>120</b>, over the wireless medium, which are directed toward destination host workstations <b>136</b>, over data network <b>142</b>.

c. Service Level Requests

<figref idref="DRAWINGS">FIG. 9</figref> illustrates how PRIMMA MAC IP flow scheduler <b>604</b> can also take into account a Service Level Agreement in prioritizing frame slot scheduling and resource allocation. <figref idref="DRAWINGS">FIG. 9</figref> depicts SLA-mediated IP flow management diagram <b>900</b> including prioritization of uplink traffic being transmitted to wireless base station <b>302</b> from CPE subscriber locations <b>306</b>a, <b>306</b>b, <b>306</b>c and <b>306</b>d. For example, suppose subscribers of telecommunications services have subscribed to one of four SLA levels, P<b>1</b><b>902</b>a, P<b>2</b><b>904</b>a, P<b>3</b><b>906</b>a and P<b>4</b><b>908</b>a. In the illustrated example, suppose IP flows <b>902</b>b are being sent to a subscriber at CPE location <b>306</b>a and have an SLA priority level of P<b>1</b><b>902</b>a. Similarly, IP flows <b>904</b>b, <b>906</b>b and <b>908</b>b are being sent to subscribers at CPE locations <b>306</b>b, <b>306</b>c and <b>306</b>d and have SLA priority levels of P<b>2</b><b>904</b>a, <b>906</b>a and <b>908</b>a, respectively. PRIMMA MAC scheduler <b>604</b>, <b>634</b> of wireless base station <b>302</b> can take into account SLA-based priorities in allocating available bandwidth to the subscriber CPE IP flows <b>902</b>b, <b>904</b>b, <b>906</b>b and <b>908</b>b. In the example illustration, IP flow <b>902</b>b can be allocated frame slot <b>902</b>c based on SLA priority <b>902</b>a. Frame slots <b>904</b>c, <b>906</b>c and <b>908</b>c can be similarly scheduled taking into account SLA priorities. Uplinked IP flow traffic can then be transmitted on to data network <b>142</b>.

SLA-based prioritization can provide a valuable means for a telecommunications provider to provide differentiated services to a variety of customers. For example, it is possible that low priority traffic from a subscriber who has purchased a premium SLA service agreement, can be scheduled at a higher priority than high priority traffic from a subscriber which has only signed up for a value level or low cost SLA service priority.

d. Identification of Headers

<figref idref="DRAWINGS">FIG. 7</figref> illustrates packet header field information <b>700</b> which can be used to identify IP flows and the QoS requirements of the IP flows. Specifically, IP header fields <b>702</b> can include, e.g., source and destination IP addresses, helpful in providing application aware preferential resource allocation; IP type of service (TOS), a useful field for assisting PRIMMA MAC in classifying a packet or IP flow; IP time to live (TTL), a useful field for anticipating application packet discards; and protocol fields which can be used in identifying IP flows.

Packet header information <b>700</b> also includes UDP header fields <b>704</b>. Included in UDP packet header fields <b>704</b> are source and destination port numbers.

Packet header information <b>700</b> also includes TCP header fields <b>706</b>. Included in TCP packet header fields <b>706</b> are source and destination port numbers; TCP sliding window size; urgent pointer; SYN, ISN, PSH, RST and FIN flags; and maximum segment size (MSS).

Packet header information <b>700</b> also includes realtime protocol RTP and RTCP header fields <b>708</b>.

It would be apparent to those skilled in the art that other packet header fields could be useful in identifying an IP flow. The fields have been given by way of example and are not intended to be an exhaustive list of useful packet header fields. Other fields, such as, e.g., fields from IP v6 relating to differentiated services (DIFF SERV) could also be useful to IP flow analyzer <b>602</b> and <b>632</b> of wireless base station <b>302</b>.

e. TDMA MAC Air Frame

<figref idref="DRAWINGS">FIGS. 12A-12O</figref> illustrate an exemplary time domain multiple access (TDMA) media access control (MAC) transmission air frame. The fields described herein merely refer to one embodiment for the present invention, and are not limiting to the numerous implementations of the present invention.

<figref idref="DRAWINGS">FIG. 12A</figref> illustrates an entire TDMA MAC transmission air frame. Air frame <b>1202</b> includes downstream transmission subframe <b>1202</b> and upstream transmission subframe <b>1204</b>.

The TDMA MAC air frame of <figref idref="DRAWINGS">FIG. 12A</figref> includes upstream acknowledgment block (UAB) <b>1206</b>, acknowledgment request block (ARB) <b>1208</b>, frame descriptor block (FDB) <b>1210</b>, data slot (DS)₁<b>1212</b>a, DS₂<b>1212</b>b, DS₃<b>1212</b>c, DS₄<b>1212</b>d, DS₅<b>1212</b>e, DS₆<b>1212</b>f, DS₇<b>1212</b>g, DS₈<b>1212</b>h, DS₉<b>1212</b>i, DS₁₀<b>1212</b>j, DS₁₁<b>1212</b>k, DS_m<b>1212</b>l, downstream acknowledgment block (DAB) <b>1214</b>, reservation request block (RRB) <b>1216</b>, UA₁<b>1218</b>a, UA₂<b>1218</b>b, UA₃<b>1218</b>c, UA₄<b>1218</b>U, UA₅<b>1218</b>e, UA₆<b>1218</b>f, UA₇<b>1218</b>g, UA₈<b>1218</b>h, UA₉<b>1218</b>i, UA₁₀<b>1218</b>j, UA₁₁<b>1218</b>k, UA₁₂<b>1218</b>l, and UA_n<b>1218</b>m.

In the embodiment described herein, the type of TDMA used is TDMA/time division duplex (TDMA/TDD). In TDMA/TDD, for one interval of time, transmission is from a CPE station <b>294</b> to a wireless base station <b>302</b>, and in another instance of time, it is from a wireless base station <b>302</b> to a CPE station <b>194</b>. Any number of slots can be used for the uplink or for the downlink. The number of slots is dynamically assigned for both the uplink and the downlink. However, because the downlink data rate is usually higher than the uplink data rate, more slots are assigned to the downlink. Although distribution of slots between the downlink and uplink is dynamically assigned, the total number of slots for a frame is fixed in this embodiment.

<tables id="TABLE-US-00005" num="00005"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="28pt" align="center" /><colspec colname="2" colwidth="21pt" align="center" /><colspec colname="3" colwidth="28pt" align="left" /><colspec colname="4" colwidth="56pt" align="left" /><colspec colname="5" colwidth="84pt" align="left" /><thead><row><entry namest="1" nameend="5" rowsep="1">TABLE 5</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row><row><entry>MAC</entry><entry /><entry>Block/</entry><entry /><entry /></row><row><entry>Air</entry><entry /><entry>Sub-</entry><entry /><entry /></row><row><entry>Frame</entry><entry>Slots</entry><entry>Frame</entry><entry>Name</entry><entry>Description</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>0</entry><entry>1-8</entry><entry>DAB/</entry><entry>Downstream</entry><entry>Acknowledgments from</entry></row><row><entry /><entry /><entry>Up-</entry><entry>Acknowledgment</entry><entry>subscribers CPE stations to</entry></row><row><entry /><entry /><entry>stream</entry><entry>Request Block</entry><entry>wireless base station of</entry></row><row><entry /><entry /><entry /><entry /><entry>receipt of downstream slots</entry></row><row><entry /><entry /><entry /><entry /><entry>in previous downstream</entry></row><row><entry /><entry /><entry /><entry /><entry>subframe</entry></row><row><entry>0</entry><entry>1-8</entry><entry>RRB/</entry><entry>Reservation</entry><entry>Requests from subscriber</entry></row><row><entry /><entry /><entry>Up-</entry><entry>Request Block</entry><entry>CPE stations for trans-</entry></row><row><entry /><entry /><entry>stream</entry><entry /><entry>mission reservations in</entry></row><row><entry /><entry /><entry /><entry /><entry>later frames with</entry></row><row><entry /><entry /><entry /><entry /><entry>dynamically adjustable</entry></row><row><entry /><entry /><entry /><entry /><entry>number of contention slots</entry></row><row><entry>0</entry><entry>up to</entry><entry>US₁-</entry><entry>Upstream Slot</entry><entry>Data slots in the upstream</entry></row><row><entry /><entry>16 </entry><entry>US₁₆/</entry><entry>Transmissions</entry><entry>subframe, which is a</entry></row><row><entry /><entry /><entry>Up-</entry><entry /><entry>variable number per frame</entry></row><row><entry /><entry /><entry>stream</entry><entry /><entry>(up to 16 in one</entry></row><row><entry /><entry /><entry /><entry /><entry>embodiment)</entry></row><row><entry>0</entry><entry>1-3</entry><entry>ODB/</entry><entry>Operations Data</entry><entry>OA&amp;MP data from</entry></row><row><entry /><entry /><entry>Up-</entry><entry>Block</entry><entry>subscribers sequenced by a</entry></row><row><entry /><entry /><entry>stream</entry><entry /><entry>subscriber CPE station per</entry></row><row><entry /><entry /><entry /><entry /><entry>frame</entry></row><row><entry>0</entry><entry>0</entry><entry>UAB/</entry><entry>Upstream</entry><entry>Acknowledgments from</entry></row><row><entry /><entry /><entry>Down-</entry><entry>Acknowledgment</entry><entry>wireless base station to</entry></row><row><entry /><entry /><entry>stream</entry><entry>Block</entry><entry>subscriber CPE stations of</entry></row><row><entry /><entry /><entry /><entry /><entry>receipt of upstream slots in</entry></row><row><entry /><entry /><entry /><entry /><entry>a previous subframe</entry></row><row><entry>0</entry><entry>0</entry><entry>ARB/</entry><entry>Acknowledgment</entry><entry>Acknowledgments of</entry></row><row><entry /><entry /><entry>Down-</entry><entry>Request Block</entry><entry>subscriber CPE requests of</entry></row><row><entry /><entry /><entry>stream</entry><entry /><entry>having received reservation</entry></row><row><entry /><entry /><entry /><entry /><entry>requests in a previous</entry></row><row><entry /><entry /><entry /><entry /><entry>subframe</entry></row><row><entry>0</entry><entry>0</entry><entry>FD/</entry><entry>Frame Descriptor</entry><entry>Describes the contents of</entry></row><row><entry /><entry /><entry>Down-</entry><entry>Block for current</entry><entry>the downstream</entry></row><row><entry /><entry /><entry>stream</entry><entry>frame</entry><entry>transmission subframe</entry></row><row><entry>0</entry><entry>up to</entry><entry>DS₁-</entry><entry>Downstream Slot</entry><entry>Data slots in the down-</entry></row><row><entry /><entry>16 </entry><entry>DS₁₆/</entry><entry>Transmissions</entry><entry>stream subframe, which is</entry></row><row><entry /><entry /><entry>Down-</entry><entry /><entry>variable per frame (up to</entry></row><row><entry /><entry /><entry>stream</entry><entry /><entry>16 in one embodiment)</entry></row><row><entry>0</entry><entry>0</entry><entry>CCB/</entry><entry>Command and</entry><entry>OA&amp;MP commands</entry></row><row><entry /><entry /><entry>Down-</entry><entry>Control Block</entry><entry>sequenced by subscribers</entry></row><row><entry /><entry /><entry>stream</entry><entry /><entry>per frame and frame</entry></row><row><entry /><entry /><entry /><entry /><entry>synchronization</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

<figref idref="DRAWINGS">FIG. 12B</figref> is a symbolic illustration of an exemplary TDMA/TDD air frame <b>1220</b> of the present invention. TDMA/TDD air frame structure <b>1220</b> depicts a frame of frame size <b>1228</b>, which can be, e.g., 16 slots or 32 slots. It would be apparent to those skilled in the art that frame structures <b>1220</b> having other numbers of slots could be used without departing from the spirit and scope of the invention. Frame structure <b>1220</b> includes, e.g., various TDMA slots <b>1222</b>a, <b>1222</b>b, <b>1222</b>c and <b>1222</b>d. Within each TDMA slot <b>1222</b>a-c, can be included a data slot <b>1224</b>a, <b>1224</b>b, <b>1224</b>c and <b>1224</b>d which in turn can contain a control packet <b>1226</b>a, or a data packet <b>1226</b>b-d, respectively.

In the present embodiment the sum of all TDMA slots <b>1222</b> within a frame of frame size <b>1228</b> is fixed. However, as noted, using the resource allocation methodologies of the present invention it is possible to dynamically allocate a subset of the entire number of TDMA slots <b>1222</b> to an uplink direction, where all the uplink TDMA slots are known collectively as an uplink subframe or an upstream transmission subframe <b>1204</b>, and to dynamically allocate a subset of the entire number of TDMA slots <b>1222</b> to a downlink direction, where all the downlink TDMA slots are known collectively as a downlink subframe or an downlink transmission subframe <b>1202</b>. Using the resource allocation method of the present invention, it is possible to allocate all TDMA slots <b>1222</b> to a given upstream or downstream direction. It is further possible to allocate all data slots <b>1224</b> to a single CPE station. The wireless base station <b>302</b> has a state machine, and knows the state of each CPE station <b>294</b> having a connection therewith (i.e., having an IP flow recognized by the wireless base station <b>294</b>).

Downstream transmission subframe <b>1202</b> and upstream transmission subframe <b>1204</b> are described in detail below.

1. Downstream Transmission SubFrames

<figref idref="DRAWINGS">FIG. 12C</figref> depicts an exemplary downstream transmission subframe <b>1202</b>. The downstream transmission subframe of <figref idref="DRAWINGS">FIG. 12C</figref> includes transmitter turnaround time <b>1230</b>, UAB <b>1206</b>, ARB <b>1208</b>, FDB <b>1210</b>, a variable number of DSs per frame (e.g., 16) <b>1212</b>, and command and control block (CCB) <b>1232</b>. The DS transmissions <b>1212</b> include DS₁<b>1212</b>a, DS₂<b>1212</b>b, DS₃<b>1212</b>c, DS₄<b>1212</b>d, DS₅<b>1212</b>e, DS₆<b>1212</b>f, DS₇<b>1212</b>g, DS₈<b>1212</b>h, DS₉<b>1212</b>i, DS₁₀<b>1212</b>j, DS₁₁<b>1212</b>k, and DS_m<b>1212</b>l.

<figref idref="DRAWINGS">FIG. 12D</figref> depicts an exemplary UAB <b>1206</b> of a downstream transmission subframe <b>1202</b>. The downstream transmission subframe of <figref idref="DRAWINGS">FIG. 12D</figref> includes UAB <b>1206</b>, ARB <b>1208</b>, FDB <b>1210</b>, DS₁<b>1212</b>a, DS₂<b>1212</b>b, DS₃<b>1212</b>c, DS₄<b>1212</b>d, DS₅<b>1212</b>e, DS₆<b>1212</b>f, DS₇<b>1212</b>g, DS_n<b>1212</b>h, DS₉<b>1212</b>i, DS₁₀<b>1212</b>j, DS₁₁<b>1212</b>k, DS_m<b>1212</b>l, and CCB <b>1232</b>.

UAB <b>1206</b> includes subslots UAB₁<b>1206</b>a, UAB₂<b>1206</b>b, UAB₃<b>1206</b>c, UAB₄<b>1206</b>d, UAB₅<b>1206</b>e, UAB₆<b>1206</b>f, UAB₇<b>1206</b>g, and UAB_n<b>1206</b>h. UAB₁<b>1206</b>a includes a preamble <b>1234</b>a, subscriber ID <b>1234</b>b, IP-flow identifier <b>1234</b>c, slot sequence number <b>1234</b>d, and cyclical redundancy check (CRC) <b>1234</b>e.

The UAB field is an acknowledgment by a wireless base station <b>302</b> to a CPE station <b>294</b> that the slots (e.g., US₁-US₁₆) of an upstream transmission subframe have been received. The reader is referred to the discussion of the upstream transmission subframe below.

In subslot UAB₁<b>1206</b>a of ARB <b>1206</b>: preamble <b>1234</b>a includes data used for link integrity purposes; subscriber ID <b>1234</b>b identifies which CPE station <b>294</b> is making the reservation request; IP-flow identifier <b>1234</b>c identifies the IP data flow;quality of service data class <b>1234</b>a identifies the priority class of the IP data flow, if known to the CPE station <b>294</b>; IP-flow priority and type <b>1234</b>b is an indicator of a new IP data flow; and CRC <b>1234</b>e, which stands for cyclic redundancy code, provides error checking bits for subslot RRB, <b>1216</b>a.

<figref idref="DRAWINGS">FIG. 12E</figref> depicts an exemplary ARB <b>1208</b> of a downstream transmission subframe <b>1202</b>. The downstream transmission subframe of <figref idref="DRAWINGS">FIG. 12E</figref> includes UAB <b>1206</b>, ARB <b>1208</b>, FDB <b>1210</b>, DS₁<b>1212</b>a, DS₂<b>1212</b>b, DS₃<b>1212</b>c, DS₄<b>1212</b>d, DS₅<b>1212</b>e, DS₆<b>1212</b>f, DS₇<b>1212</b>g, DS_n<b>1212</b>h, DS₉<b>1212</b>i, DS₁₀<b>1212</b>j, DS₁₁<b>1212</b>k, DS_m<b>1212</b>l, and CCB <b>1232</b>.

ARB <b>1208</b> includes subslots ARB₁<b>1208</b>a, ARB₂<b>1208</b>b, ARB₃<b>1208</b>c, ARB₄<b>1208</b>d, ARB₅<b>1208</b>e, ARB₆<b>1208</b>f, ARB₇<b>1208</b>g, and ARB_n<b>1208</b>h. ARB₁<b>1208</b>a includes a preamble <b>1234</b>a, subscriber ID <b>1234</b>b, IP-flow identifier <b>1234</b>c, slot sequence number <b>1234</b>d, and CRC <b>1234</b>e.

The ARB field is an acknowledgment by a wireless base station <b>302</b> to a CPE station <b>294</b> that the wireless base station <b>302</b> has received an upstream reservation request from the CPE station <b>294</b>. The reader is referred to the discussion of the upstream transmission subframe below.

In subslot ARB, <b>1208</b>a of ARB <b>1208</b>: preamble <b>1234</b>a includes data used for link integrity purposes; subscriber ID <b>1234</b>b identifies which CPE station <b>294</b> is making the reservation request; IP-flow identifier <b>1234</b>c identifies the IP data flow;quality of service data class <b>1234</b>a identifies the priority class of the IP data flow, if known to the CPE station <b>294</b>; IP-flow priority and type <b>1234</b>b is an indicator of a new IP data flow; and CRC <b>1234</b>e, which stands for cyclic redundancy code, provides error checking bits for subslot RRB₁<b>1216</b>a.

<figref idref="DRAWINGS">FIG. 12F</figref> depicts an exemplary FDB <b>1210</b> of a downstream transmission subframe <b>1202</b>. The downstream transmission subframe of <figref idref="DRAWINGS">FIG. 12F</figref> includes UAB <b>1206</b>, ARB <b>1208</b>, FDB <b>1210</b>, DS₁<b>1212</b>a, DS₂<b>1212</b>b, DS₃<b>1212</b>c, DS₄<b>1212</b>d, DS₅<b>1212</b>e, DS₆<b>1212</b>f, DS₇<b>1212</b>g, DS_n<b>1212</b>h, DS₉<b>1212</b>i, DS₁₀<b>1212</b>j, DS₁₁<b>1212</b>k, DS_m<b>1212</b>l, and CCB <b>1232</b>.

The FDB includes detailed information pertaining to the slots (e.g., DS₂-DS₁₆) of the downstream transmission subframe.

FDB <b>1210</b> includes a preamble subslot <b>1236</b>a, number of downstream slots subslot, <b>1236</b>b, IP-flow ID for upstream reservation <b>1</b> subslot <b>1236</b>c, IP-flow ID for upstream reservation <b>2</b> subslot <b>1236</b>d, IP-flow ID for upstream reservation n subslot <b>1236</b>e, and contention slot count for next upstream subframe subslot <b>1236</b>f.

In FDB <b>1210</b>, the fields are defined as follows: preamble subslot <b>1236</b>a includes data used for link integrity purposes; number of downstream slots subslot <b>1236</b>b includes the number of downstream slots (DSs), IP-flow ID for downstream reservation subslot <b>1236</b>c includes an IP flow identification for DS₁; IP-flow ID for downstream reservation subslot <b>1236</b>d includes a second IP flow identification for DS₂; IP-flow ID for downstream reservation n subslot <b>1236</b>e includes another IP flow identification for DS_m; contention slot count for next upstream subframe subslot <b>1236</b>f provides a count for the next available upstream subframe.

<figref idref="DRAWINGS">FIG. 12G</figref> depicts an exemplary downstream MAC payload data unit (PDU). The downstream MAC PDU includes information regarding the actual structure of the payload. The downstream MAC PDU of <figref idref="DRAWINGS">FIG. 12G</figref> includes MAC linked list sequence number <b>1238</b>a (the sequence number of the MAC linked list), reservation request index number <b>1238</b>b (an index to the downstream IP flow), compressed IP-flow identifier <b>1238</b>c, compressed IP-flow priority and type <b>1238</b>d (identifying the priority and type of a compressed IP flow), slot payload <b>1238</b>e (the amount of data in a downstream data slot), and CRC <b>1234</b>e (error checking information).

<figref idref="DRAWINGS">FIG. 12H</figref> depicts an exemplary CCB of a downstream transmission subframe <b>1202</b>. The CCB comprises OAM&amp;P commands sequenced by subscriber CPE station <b>294</b> per frame and frame synchronization. CCB <b>1232</b> includes a mode command subslot <b>1240</b>a (includes options of what mode the CPE station is to take), profile command subslot <b>1240</b>b (includes specific system commands, such as a patch for a module), control data index subslot <b>1240</b>c (including download locations and memory requirements or other information needed by the CPE stations to download data), datablock <b>1</b> subslot <b>1240</b>d (includes specific system data), datablock <b>2</b> subslot <b>1240</b>e (same), datablock n subslot <b>1240</b>f (same), and CRC subslot <b>1234</b>e (error checking information).

2. Upstream Transmission SubFrames

<figref idref="DRAWINGS">FIG. 12I</figref> depicts an exemplary upstream transmission subframe <b>1204</b>. The upstream transmission subframe of <figref idref="DRAWINGS">FIG. 12I</figref> includes transmitter turnaround time <b>1230</b>, DAB <b>1214</b>, RRB <b>1216</b>, a variable number of USs per frame, e.g., 16, <b>1218</b>, and operations data block (ODB) <b>1242</b>, consisting of OAM&amp;P data from subscribers, sequenced by subscriber per frame. The US transmissions <b>1218</b> include US₁<b>1218</b>a, US₂<b>1218</b>b, US₃<b>1218</b>c, US₄<b>1218</b>d, US₅<b>1218</b>e, US₆<b>1218</b>f, US₇<b>1218</b>g, US₈<b>1218</b>h, US₉<b>1218</b>i, US₁₀<b>1218</b>j, US₁₁<b>1218</b>k, US₁₂<b>1218</b>l, and US_n<b>1218</b>m.

<figref idref="DRAWINGS">FIG. 12K</figref> depicts an exemplary RRB <b>1216</b> of an upstream transmission subframe <b>1204</b>. The upstream transmission subframe of <figref idref="DRAWINGS">FIG. 12K</figref> also shows DAB <b>1214</b>, RRB <b>1216</b>, US₁<b>1218</b>a, US₂<b>1218</b>b, US₃<b>1218</b>c, US₄<b>1218</b>d, US₅<b>1218</b>e, US₆<b>1218</b>f, US₇<b>1218</b>g, US₈<b>1218</b>h, US₉<b>1218</b>i, US₁₀<b>1218</b>j, US₁₁<b>1218</b>k, US₁₂<b>1218</b>l, US_n<b>1218</b>m, and ODB <b>1242</b>.

RRB <b>1216</b> includes subslots RRB₁<b>1216</b>a, RRB₂<b>1216</b>b, RRB₃<b>1216</b>c, RRB₄<b>1216</b>d, RRB₅<b>1216</b>e, RRB₆<b>1216</b>f, RRB₇<b>1216</b>g, and RRB_n<b>1216</b>h. RRB₁<b>1216</b>a includes a preamble <b>1234</b>a, subscriber ID <b>1234</b>b, IP-flow identifier <b>1234</b>c, quality of service data class <b>1244</b>a, IP-flow priority and type <b>1244</b>b, and CRC <b>1234</b>e.

A CPE station <b>294</b> uses one of the subslots (RRB₁<b>1216</b>a, RRB₂<b>1216</b>b, RRB₃<b>1216</b>c, RRB₄<b>1216</b>d, RRB₅<b>1216</b>e, RRB₆<b>1216</b>f, RRB₇<b>1216</b>g, and RRB_n<b>1216</b>h) of RRB <b>1216</b> to make a reservation request, which is a request by the CPE station <b>294</b> for bandwidth in a future uplink transmission subframe. If two CPE stations <b>294</b>d, <b>294</b>e attempt to access the same subslot in RRB <b>1216</b>, which can occur because their pseudorandom number generators select the same subslot, then a “collision” occurs and the data is not readable by wireless base station <b>302</b>. The two CPE stations <b>294</b>d, <b>294</b>e are required to try again.

Reservation request slots can be provided on an IP flow basis. Rather than allocate a reservation request slot to every CPE subscriber station, a default number (e.g., 5) are made available as contention slots. If collisions are detected by a greater number of requesting subscribers than the number of reservation request slots, then the slots allocated can be dynamically varied to provide additional RRB slots. (Collisions are analogous to CSMA/CD collisions in Ethernet, where colliding devices on an Ethernet network attempt to retransmit over the bus architecture by retrying at a random time.)

The radio contention method of the present invention builds upon aspects of the “Slotted Aloha” method developed by L. Roberts in 1972, as a refinement of the “Aloha” method developed by N. Abramson in the early 1970's, and so-called bit-mapped reservation protocols. Like the Slotted Aloha method, the present invention provides for discrete slots for transmission of data, rather than allowing the transmission of data at any point. However, instead of transmitting the actual “payload” of data, the present invention advantageously transmits only a “reservation request” describing the actual data payload contents. Also, the number of slots for reservation requests can advantageously be dynamically altered according to the frequency of detected collisions in the recent past.

Unlike various Carrier Sense Multiple Access (CSMA) techniques previously used in wireless, both persistent and non-persistent, the present method advantageously does not require that subscriber CPE station <b>294</b>d “sense” the carrier (the radio channel) before transmission. Instead, a subscriber CPE station <b>294</b>d selects a “subslot” to transmit through a pseudo-random number selection, without a prior carrier sense. If a collision is detected, the subscriber CPE station <b>294</b>d will try again in the next frame using the pseudo-random number process.

Instead of using a bit-map protocol for the resolution of contention, as is used in some reservation protocols, the wireless base station can explicitly grant reservation requests. The standard bit-map protocol can require that all stations can receive signals from all other stations so that the subsequent order of transmission can be implicitly determined from the resulting bit-map pattern. The present method advantageously does not require the receipt of reservation request signals from other CPE subscriber stations <b>294</b>d. This is advantageous because, at higher frequencies (such as, e.g., 2 GHz to 30 GHz) where there may be line-of-sight and distance constraints, the requirement for receipt of the transmissions of other CPE subscriber stations <b>294</b>d could unduly constrain the topology, locations and distances of CPE subscriber stations.

Advantageously, by allowing the wireless base station <b>302</b> to explicitly grant the requested reservation, other factors such as relative or dynamic CPE subscriber station <b>294</b>d (or IP-flow) priority factors can be considered. Therefore, the present invention's reservation protocol with a dynamically adjustable number of contention subslots and explicit wireless base station reservation grants, allows a more optimal means of providing for the allocation of wireless, such as, e.g., radio, bandwidth in response to QoS requirements of IP-flows than any prior method.

As noted, RRB₁<b>1216</b>a includes the following fields: a preamble <b>1234</b>a, subscriber ID <b>1234</b>b, IP-flow identifier <b>1234</b>c, quality of service data class <b>1244</b>a, IP-flow priority and type <b>1244</b>b, and CRC <b>1234</b>e. In subslot RRB₁<b>1216</b>a of RRB <b>1216</b>: preamble <b>1234</b>a includes data used for link integrity purposes; subscriber ID <b>1234</b>b identifies which CPE station <b>294</b> is making the reservation request; IP-flow identifier <b>1234</b>c identifies the IP data flow;quality of service data class <b>1234</b>a identifies the priority class of the IP data flow, if known to the CPE station <b>294</b>; IP-flow priority and type <b>1234</b>b is an indicator of a new IP data flow; and CRC <b>1234</b>e, which stands for cyclic redundancy code, provides error checking bits for subslot RRB₁<b>1216</b>a. Optionally, an additional field can be provided in subslot RRB₁<b>1216</b>a which includes the number of data packets CPE station <b>294</b> will transmit in its IP data flow.

<figref idref="DRAWINGS">FIG. 12J</figref> depicts an exemplary DAB <b>1214</b> of an upstream transmission subframe <b>1204</b>, where a CPE acknowledges receipt of a slot from base. The DAB is an acknowledgment from a subscriber CPE station <b>294</b> to the wireless base station that downstream slots have been received in a previous subframe.

The DAB <b>1214</b> includes subslots DAB₁<b>1214</b>a, DAB₂<b>1214</b>b, DAB₃<b>1214</b>c, DAB₄<b>1214</b>d, DAB₅<b>1214</b>e, DAB₆<b>1214</b>f, DAB₇<b>1214</b>g, and DAB_n<b>1214</b>h. Subslot DAB₁<b>1214</b>a includes a preamble <b>1234</b>a, subscriber ID <b>1234</b>b, IP-flow identifier <b>1234</b>c, slot sequence number <b>1234</b>d, and CRC <b>1234</b>e. (These fields have the same information as described with respect to the RRB.)

<figref idref="DRAWINGS">FIG. 12L</figref> depicts an exemplary MAC PDU upstream slot. The MAC PDU upstream slot of <figref idref="DRAWINGS">FIG. 12L</figref> includes a CPE linked-list sequence number <b>1246</b>, reservation request index number <b>1236</b>b, compressed IP-flow identifier <b>1238</b>c, compressed IP-flow priority and type <b>1238</b>d, slot payload <b>1238</b>e, and CRC <b>1234</b>e. The upstream MAC PDU is similar to the downstream MAC PDU, but is used instead for upstream subframe payload information.

<figref idref="DRAWINGS">FIGS. 12M, 12N and 12O</figref> depict an exemplary ODB <b>1242</b> in detail. This field is used to store information regarding the connection between the wireless base station <b>302</b> and the CPE station <b>294</b>. ODB <b>1242</b> includes preamble <b>1234</b>a (including link integrity data), subscriber ID <b>1234</b>b (identifies which CPE station <b>294</b> is making the reservation request), system state <b>1248</b>a (information about the status of the CPE station <b>294</b>), performance data <b>1248</b>b (how full the buffer statistics, cpe processor performance statistics, system state), antenna data <b>1248</b>c (information pertaining to the antenna), CRC <b>1234</b>e (error checking information) and synchronization pattern <b>1248</b>d (error checking information).

Referring to <figref idref="DRAWINGS">FIG. 12M</figref>, system state subslot <b>1248</b>a comprises system mode <b>1250</b>a (the mode of the CPE station, e.g., command mode, operations mode, or initialization mode of the system), system status <b>1250</b>b (the status of the CPE station), system resources <b>1250</b>a (the mode of the CPE station), system power <b>1250</b>b (the mode of the CPE station), system temperature <b>1250</b>a (the temperature of the CPE station). The CPE stations <b>294</b> are required to take turns using ODB <b>1242</b> to transmit their information.

Referring to <figref idref="DRAWINGS">FIG. 12N</figref>, performance data <b>1248</b>a comprises the number of comrepeats <b>1252</b>a (the number of repeats of communication attempts), number of frameslips <b>1252</b>b (the number of frames that have slipped), waitstate index <b>1252</b>c (an index to the waiting state).

f. Exemplary Class-based Frame Prioritization

<figref idref="DRAWINGS">FIG. 13</figref> shows block diagram <b>1300</b>, illustrating how an exemplary flow scheduler for the present invention functions to schedule products. Block diagram <b>1300</b> includes: flow scheduler <b>604</b>, <b>634</b> (which is a combination of downlink flow scheduler <b>604</b> and uplink flow scheduler <b>634</b>), downlink transmission subframe <b>1202</b> (i.e., the next MAC downstream subframe), uplink transmission subframe <b>1204</b> (i.e., the current MAC upstream subframe). Block diagram <b>1300</b> also includes the following downstream components: downstream reservation first-in-first-out queue <b>1322</b>, class 1 downstream queue <b>1302</b>, class 2 downstream queue <b>1304</b>, and class 3 downstream queue <b>1306</b>. Block diagram <b>1300</b> also includes the following upstream reservation components: current upstream subframe <b>1344</b> (with the current upstream subframe <b>1204</b> about to be stored in it), previous upstream subframes <b>1346</b>, <b>1348</b>, <b>1350</b>, class 1 upstream reservation request queue <b>1308</b>, class 2 upstream reservation request queue <b>1310</b>, and class 3 upstream reservation request queue <b>1312</b>.

In the downlink path, an IP flow QoS class queuing processor (described below with respect to <figref idref="DRAWINGS">FIGS. 15A and 15B</figref>) queues the received data packets into class 1 packet flow queues <b>1324</b>, <b>1326</b> and <b>1328</b>, class 2 packet flow queues <b>1330</b>, <b>1332</b>, <b>1334</b>, and class 3 packet flow queues <b>1336</b>, <b>1338</b>, <b>1340</b> and <b>1342</b>.

Based on inputs from a hierarchical class-based priority processor, a virtual private network (VPN) directory enabled (DEN) data table and a service level agreement (SLA) priority data table (described below with respect to <figref idref="DRAWINGS">FIGS. 15A and 15B</figref>), the class 1, class 2, and class 3 packet flow queues are respectively assigned to class 1 downstream queue <b>1302</b>, class 2 downstream queue <b>1304</b>, and class 3 downstream queue <b>1306</b>. Flow scheduler <b>604</b>, <b>634</b> schedules these downlink data packets onto the downlink transmission subframe <b>1202</b>.

In one embodiment, additional processing is used to minimize latency and jitter. For example, suppose the data packets of class 1 packet flow queue <b>1324</b> require jitter-free and latency-free delivery, i.e., delivery of packets must be at constant time intervals and in real-time. Packet flow queue <b>1324</b> creates, e.g., 4 equal time spaced slot reservations in future frames, as shown in class 1 downstream queue <b>1302</b> and described with respect to <figref idref="DRAWINGS">FIG. 14</figref> below. The reservations are fed to downstream reservation first-in-first-out queue <b>1322</b>, and are scheduled onto a future downstream frame <b>1202</b> by flow scheduler <b>604</b>, <b>634</b>.

In the uplink path, reservation requests for future upstream slots arrive at wireless base station <b>302</b> as part of the current upstream subframe <b>1204</b> received from CPE subscriber stations <b>294</b> over the wireless medium. Current upstream subframe <b>1344</b> can temporarily store reservation requests for analysis and scheduling of uplink packets in accord with the description of <figref idref="DRAWINGS">FIG. 8B</figref> above. Previous upstream subframes <b>1346</b>, <b>1348</b>, <b>1350</b> include upstream reservation requests awaiting upstream frame slot allocations in future upstream subframes <b>1204</b>. Reservation request blocks (RRBs), described further above with reference to <figref idref="DRAWINGS">FIG. 12</figref>***, include a request for a number of slots for a single IP flow with an IP flow identifier # and class of the flow. The upstream reservation requests (by IP flow and class) are queued onto class 1 upstream reservation request queue <b>1308</b>, class 2 upstream reservation request queue <b>1310</b>, and class 3 upstream reservation request queue <b>1312</b> by an IP flow QoS class queuing processor (described below with respect to <figref idref="DRAWINGS">FIGS. 16A and 16B</figref>). Flow scheduler <b>604</b> and <b>1566</b>, and <b>634</b> and <b>1666</b>, uses these downstream reservations and upstream reservation requests to assign slots to data packets in the next downstream transmission subframe <b>1202</b> and upstream transmission subframe <b>1204</b>, respectively.

<figref idref="DRAWINGS">FIG. 14</figref> is an exemplary two-dimensional block diagram <b>1400</b> of the advanced reservation algorithm. <figref idref="DRAWINGS">FIG. 14</figref> includes MAC subframe scheduler <b>1566</b>, <b>1666</b>, frames current frame, n <b>1402</b>, and future frames, n+1 <b>1404</b>, n+2 <b>1406</b>, n+3 <b>1408</b>, n+4 <b>1410</b>, n+5 <b>1412</b>, n+6 <b>1414</b> . . . n+x <b>1416</b>, representing frames of data packets to be transmitted at times n, n+1, n+2 . . . n+x. Each frame is divided into a variable length downlink subframe <b>1202</b> and a variable length uplink subframe <b>1204</b>. The lengths of downlink subframe <b>1202</b> and uplink subframe <b>1204</b> together comprise the length of an entire frame.

Each frame n <b>1402</b> includes a number of slots (<b>1418</b>-<b>1478</b>). Slots <b>1418</b>-<b>1446</b> comprise the downlink subframe <b>1202</b>, and slots <b>1448</b>-<b>1478</b> comprise the uplink subframe <b>1204</b>. In one embodiment, the slots are fixed in length, with each slot capable of storing a single data packet. The total number of frame slots in a frame remains constant. For example, if a given frame includes 64 frame slots, the slots can be allocated dynamically in either the uplink or downlink directions, such as, e.g., 32 up and 32 down, 64 up and 0 down, 0 up and 64 down. Block diagram <b>1400</b> can be thought of as a two dimensional matrix with each slot having a time value (i.e., a slot-to-slot time interval), e.g., 0.01 ms, and each frame having a total frame interval time value (i.e., a frame-to-frame time interval), e.g., 0.5 ms.

In the present invention, an advanced reservation algorithm assigns future slots to data packets based on the priority of the IP data flow with which the packet is associated. Exemplary priorities are described above with respect to <figref idref="DRAWINGS">FIGS. 8A and 8B</figref>. For calls that are sensitive to jitter, meaning calls that are time sensitive, it is important to maintain an isochronous (i.e., in phase with respect to time) connection. With such signals, it is important that the data be dispersed in the same slot between frames, or in slots having a periodic variation between frames. For example, vertical reservation <b>1480</b> shows a jitter sensitive signal receiving the same slot for downlink communications in each frame. Specifically, the signal is assigned slot <b>1422</b> in frames <b>1402</b>-<b>1416</b>. If the frame-to-frame interval is 0.5 ms, then a slot will be provided to the IP flow every 0.5 ms. As another example, diagonal reservation <b>1482</b> shows a jitter sensitive signal receiving a slot varying by a period of one between sequential frames. Specifically, the signal is assigned slot <b>1440</b> in frame <b>1402</b>, slot <b>1438</b> in slot <b>1404</b>, . . . slot <b>1426</b> in frame <b>1416</b>, to create a “diagonal.” If the frame-to-frame interval is 0.5 ms and the slot-to-slot interval is 0.01 ms, then a slot can be provided to the IP flow every 0.5 minus 0.01, equals 0.49 mms. Thus, to decrease the frame interval, a diagonal reservation of positive slope can be used. To obtain an increased frame interval, a diagonal of negative slope such as, e.g., negative slope diagonal uplink reservation <b>1486</b>. The diagonal reservation <b>1482</b> can also be more pronounced (i.e., using a greater or lesser slope), depending on the period between sequential frames desired. Reservation patterns <b>1480</b>, <b>1482</b>, <b>1484</b> and <b>1486</b> are useful patterns for jitter sensitive communications. Also illustrated is a vertical reservation <b>1486</b>, similar to vertical reservation <b>1480</b>, useful for a jitter sensitive communication in the uplink direction.

For latency sensitivity, one or more slots can be guaranteed in each frame. For example, for a call that is latency sensitive, but not jitter sensitive, each frame can be assigned one (or more) slots for communications. However, the slot(s) need not be periodic between frames, as with jitter sensitive calls. The greater the number of slots allocated per frame to an IP flow, the greater total bandwidth per frame rate for the IP flow.

For calls that are less latency sensitive, fewer slots per frame can be assigned for the communication. For example, a communication that is less latency sensitive can receive a guaranteed bandwidth of one slot every four frames. A call that is even less latency sensitive can receive, e.g., a single slot every ten frames.

Using these principles, the advanced reservation algorithm can assign the slots from highest priority to lowest priority, exhausting the number of available slots in future frames. IP data flows that are both jitter and latency sensitive can be assigned slots with periodic patterns first (e.g., patterns <b>1480</b>, <b>1482</b>, <b>1484</b> and <b>1486</b>), followed by flows that are highly latency sensitive (but not jitter sensitive), et cetera, until the flows of lowest latency sensitivity are assigned to slots. Prioritization of different classes of IP flows by scheduler <b>604</b>, <b>634</b>, <b>1566</b>, <b>1666</b> is described further below with reference to <figref idref="DRAWINGS">FIGS. 15A, 15B, 16A and 16B</figref>.

g. Downlink SubFrame Prioritization

1. Overview

<figref idref="DRAWINGS">FIGS. 15A and 15B</figref> are exemplary logical flow diagrams for analysis and scheduling of the shared wireless bandwidth for the downlink direction. The logical flow pertains to IP packet flows arriving from data network <b>140</b>, at the wireless base station <b>302</b>, for transmission down to a subscriber CPE station <b>294</b>d over the wireless medium. <figref idref="DRAWINGS">FIG. 15A</figref> is an exemplary logical flow diagram <b>1500</b> for downlink IP analyzer <b>602</b>. <figref idref="DRAWINGS">FIG. 15B</figref> is an exemplary logical flow diagram <b>1560</b> for the downlink flow scheduler <b>604</b>.

The functional components for <figref idref="DRAWINGS">FIGS. 15A and 15B</figref> are explained by way of method modules, which can be viewed as physical units (e.g., comprising software, hardware, or a combination thereof) or logical vehicles (e.g., used for explanatory purposes only). Those skilled in the art will recognize that the modules are used only to explain an exemplary embodiment, and are not to be considered limiting.

The exemplary logical flow diagram <b>1500</b> for downlink IP flow analyzer of <figref idref="DRAWINGS">FIG. 15A</figref> includes packet header identification component <b>1502</b>, packet characterization component <b>1504</b>, packet classification component <b>1506</b>, and IP flow presentation component <b>1508</b>. The functions of these components are explained in detail below.

In one embodiment, downlink IP flow analyzer <b>602</b> is physically located in wireless base station <b>302</b>, although those skilled in the art will recognize that the same functionality can be located remotely from wireless base station <b>302</b>.

<figref idref="DRAWINGS">FIGS. 2D, 3A and 3B</figref> are helpful to the reader for an understanding of the downlink IP flow analyzer.

2. Introduction

IP flow analyzer <b>602</b> performs the function of identifying, characterizing, classifying, and presenting data packets to a downlink frame scheduler <b>604</b>. The functions of identifying, characterizing, classifying and presenting the data packets are respectively performed by packet header identification component <b>1502</b>, packet characterization component <b>1504</b>, packet classification component <b>1506</b> and IP flow presentation component <b>1508</b> of downlink IP flow analyzer <b>602</b>.

Packet header identification component <b>1502</b> determines whether a data packet of an incoming IP data flow is part of an IP flow that is known to the system, or is the first data packet of a new IP data flow, based on the contents of fields of the packet header section. Packet header identification component <b>1502</b> also identifies, e.g., the source of the packet using the packet header field contents. Packet characterization component <b>1504</b> characterizes a new data packet (of a new IP data flow) to determine the QoS requirements for the IP data flow, and identifies the subscriber CPE station associated with the subscriber workstation that will receive the IP data flow. Packet classification component <b>1506</b> classifies the new IP data flow into a communications priority class, grouping the packet together with similar type IP flows. IP data flow presentation <b>1508</b> initializes the new IP data flow and presents it to downlink flow scheduler <b>604</b>.

Downlink flow scheduler <b>604</b> places the data packets of an IP data flow into a class queue, and based on a set of rules, schedules the data packets for transmission over the wireless medium to a subscriber CPE station using, e.g., an advanced reservation algorithm. The rules can be determined by inputs to the downlink flow scheduler from a hierarchical class-based priority processor module <b>1574</b>, a virtual private network (VPN) directory enabled (DEN) data table <b>1572</b>, and a service level agreement (SLA) priority data table <b>1570</b>. The advanced reservation algorithm is described further above with respect to <figref idref="DRAWINGS">FIG. 14</figref>.

3. Identification

Packet header identification component <b>1502</b> identifies the IP flow received from data network <b>142</b> at data interface <b>320</b> based on the packet header.

An IP flow packet stream from data network <b>142</b>, including packets from various IP flows (where each IP flow is associated with a single data “call”) is received at packet header identification component <b>1502</b>. An IP flow can include packetized data including any type of digital information such as, e.g., packetized voice, video, audio, data, IP flows, VPN flows, and real time flows. The IP flow is transmitted over data network <b>142</b> from, e.g., a host workstation <b>136</b>d and arrives at interface <b>302</b> of wireless base station <b>320</b>. Interface <b>302</b> transmits the packets of the IP flow to packet header identification component <b>1502</b>. At module <b>1510</b>, the received packets are buffered into a storage area. At module <b>1520</b>, the contents of the packet header fields are extracted and parsed.

For IP flows known to the system, so-called “existing IP flows,” there are entries in a table <b>1526</b>. An IP flow is in the system if there is an existing characterized IP data call. In module <b>1522</b>, it is determined if there is a match between the incoming packet and an existing IP flow call in an entry in existing IP flow identification table <b>1526</b>. If so, then the IP flow is known to the system, and control passes to module <b>1530</b> of the packet characterization component <b>1504</b>.

If not, meaning that the IP flow is a new IP data flow, then control passes to module <b>1524</b>, where the packet header fields are analyzed. Module <b>1524</b> analyzes the packet header source field and determines from source application packet header data table <b>1528</b> the type of source application making the data call or transmitting the IP packet. The application can be any of the applications described with respect to <figref idref="DRAWINGS">FIG. 2D</figref> or known to those skilled in the art. Examples include a file transfer protocol (FTP) download from another client workstation <b>138</b>f, an IP voice telephony call (over telephony gateway <b>288</b>b), a voice telephony call from a caller <b>124</b>d (connected over a modem), an e-mail from a LAN <b>128</b>a attached host workstation <b>136</b>a, a fax machine call, and a conference call from multiple callers <b>124</b>d and <b>126</b>d (connected over a modem), to name a few. If the IP flow is not known to the system, then the IP flow is given an IP flow identifier number, and control passes to module <b>1526</b> where the IP flow identifier number is added to the existing IP flow identification table <b>1526</b>.

Once the type source application has been determined by packet header information or by another means, such as direct application identification, then control passes from module <b>1524</b> to module <b>1532</b> of the packet characterization component <b>1504</b>. In order to identify the type of source application of the IP flow, any type of service (TOS) or differentiated service (DiffServ) field can also be analyzed.

4. Characterization

Packet characterization component <b>1504</b> characterizes new IP flows and passes them to packet classification component <b>1506</b> for classification.

For an existing IP flow, control passes to module <b>1530</b> from module <b>1522</b> of the packet header identification component <b>1502</b>. If in module <b>1522</b> it is determined that the IP data flow is known to the system, in module <b>1530</b> it is determined whether the packet is old (i.e., stale). This can include, e.g., determining from a time-to-live field (a field in the IP packet header) the age of the packet, and comparing the field to a threshold age value. If the packet is determined to be stale, it can be discarded. Based on the age of the packet, client application discards can be anticipated. Otherwise, control can pass to module <b>1540</b> of the packet classification component <b>1506</b>.

For a new IP flow, control passes to module <b>1532</b> from module <b>1524</b> of the packet header identification component <b>1502</b>. If in module <b>1524</b> it is determined that the IP flow is not known to the system, in module <b>1532</b> the QoS requirements for the application are determined using the source application information identified in modules <b>1524</b> and <b>1528</b>. Module <b>1532</b> performs this operation by looking up the QoS requirements for the identified source application in the QoS requirement table <b>1534</b>. Different applications have different QoS requirements in order to provide an acceptable end-user experience. For example, bandwidth allocation (i.e., allocating an appropriate amount of bandwidth) is important to an application performing FTP file transfer downloads, and not jitter (i.e., time synchronizing the received data) and latency (i.e., the amount of time passage between responses). On the other hand, jitter and latency are important to voice telephony and conference calls, while bandwidth allocation is not.

After processing by module <b>1532</b>, in module <b>1536</b> a destination CPE subscriber station ID lookup from subscriber CPE IP address table <b>1538</b>, is performed for the IP flow. Each subscriber CPE station <b>294</b>d can have one or more applications, running on one or more subscriber workstations <b>120</b>d, homed to it. Accordingly, the IP flows can be directed to one or more applications on one or more subscriber workstations of one or more CPE stations <b>294</b>d. A subscriber workstation can be any device coupled to a subscriber CPE station <b>294</b>d. Module <b>1536</b> looks up the IP flow in table <b>1538</b>, to determine the identity of the subscriber CPE station <b>294</b>d that will receive the packets of the new IP flow from data network <b>142</b>. Control then passes from module <b>1536</b> to module <b>1542</b> of the packet classification component <b>1506</b>.

5. Classification

Packet classification component <b>1506</b> classifies the IP flow and passes it to IP flow presentation component <b>1508</b> for presentment.

For an existing IP flow, control passes to module <b>1540</b> from module <b>1530</b> of the packet characterization component <b>1504</b>. If in module <b>1530</b> it is determined that the packet is not stale, then in module <b>1540</b> the packet is associated with its existing IP flow. As illustrated in <figref idref="DRAWINGS">FIG. 15A</figref>, the packet processed herein was determined to be a portion of an IP flow known to the system. Therefore, the QoS processing of modules <b>1532</b>, <b>1536</b> and <b>1542</b> are unnecessary, because the QoS requirements of the present packet are assumed to be the same as for its IP flow. In another embodiment, all packets are characterized and classified. From module <b>1540</b>, control can continue with module <b>1546</b> of IP flow presentation <b>1508</b>.

For the new IP flow, control passes to module <b>1542</b> from module <b>1536</b> of the packet characterization component <b>1504</b>. In module <b>1542</b> the packet is classified into a QoS class by performing a table lookup into IP flow QoS class table module <b>1544</b>, where the types of QoS classes are stored depending on the QoS requirements for packets. Similar IP flows, (i.e., IP flows having similar QoS requirements) can be grouped together in module <b>1542</b>. In classifying packets and IP flows, QoS class groupings, any DiffServ priority markings, and any TOS priority markings can be taken into account. From the module <b>1542</b>, control passes to module <b>1548</b> of IP flow presentation component <b>1508</b>.

6. IP Flow Presentation

IP flow presentation component <b>1508</b> prepares and presents the IP flow packets to downlink flow scheduler <b>604</b>.

For existing IP flows, control passes to module <b>1546</b> from module <b>1540</b> of the packet classification component <b>1540</b>. In module <b>1546</b> the packet is added to the associated existing IP flow queue, which is the queue for the current IP flow. From module <b>1546</b>, control passes to IP flow QoS class queuing processor module <b>1562</b> of downlink flow scheduler <b>604</b>.

For the new IP flow, control passes to module <b>1548</b> from module <b>1542</b> of the packet classification component <b>1506</b>. In module <b>1548</b>, this new IP flow can be initialized for presentation to module <b>1552</b>. In module <b>1550</b>, the IP flow QoS class is presented to frame scheduler <b>604</b> to be placed in an appropriate class queue. Module <b>1552</b> presents the IP flow (in particular, the data packet) and IP flow identifier to IP flow QoS class queuing processor module <b>1562</b> of downlink flow scheduler <b>604</b>.

7. Downlink Flow Scheduler

The exemplary logical flow diagram <b>1560</b> for the downlink flow scheduler <b>604</b> of <figref idref="DRAWINGS">FIG. 15B</figref> comprises IP flow QoS class queuing processor module <b>1562</b>, MAC downlink subframe scheduler module <b>1566</b>, hierarchical class-based priority processor module <b>1574</b>, VPN DEN data table module <b>1572</b>, SLA priority data table <b>1570</b>, CPE IP flow queue depth status processor <b>1582</b> and link layer acknowledgment processor module <b>1578</b>.

Downlink flow scheduler <b>604</b> of <figref idref="DRAWINGS">FIG. 15B</figref> also includes QoS class queues as follows: class 1, <b>1564</b>a; class 2, <b>1564</b>b; class 3, <b>1564</b>c; class 4, <b>1564</b>d; class 5, <b>1564</b>e; and class 6, <b>1564</b>f; and MAC downlink subframes: frame n, <b>1568</b>a; frame n+1, <b>1568</b>b; frame n+2, <b>1568</b>c; frame n+3, <b>1568</b>d; . . . frame n+p, <b>1568</b>k.

In one embodiment, downlink flow scheduler <b>604</b> is physically located in wireless base station <b>302</b>, although those skilled in the art will recognize that the same functionality can be located remotely from wireless base station <b>302</b>.

Downlink flow scheduler <b>604</b> is used to schedule the downlink subframe. An entire frame can be divided into an uplink portion (called an uplink subframe) for transmitting uplink frames, and a downlink portion (called a downlink subframe) for transmitting downlink frames.

Also illustrated on <figref idref="DRAWINGS">FIG. 15B</figref> are WAP antenna, the wireless medium, <b>290</b>d, RF transceiver subscriber antenna <b>292</b>d, subscriber CPE station <b>294</b>d and subscriber workstation <b>120</b>d. WAP antenna <b>290</b>d and RF transceiver subscriber antenna <b>292</b>d respectively provide a wireless connection between wireless base station <b>302</b> (where downlink flow scheduler <b>604</b> resides in one embodiment) and subscriber CPE station <b>294</b>d, which can transmit an IP flow to an application running on subscriber workstation <b>120</b>d. WAP antenna <b>290</b>d serves as a wireless gateway for data network <b>142</b>, and RF transceiver subscriber antenna serves as a wireless gateway for subscriber CPE station <b>294</b>d. The connection is also illustrated in <figref idref="DRAWINGS">FIGS. 2D and 3B</figref>.

IP flow QoS class queuing processor module <b>1562</b> receives the packets from IP flow presentation component <b>1508</b>. Module <b>1562</b> then creates class queues <b>1564</b>a-<b>1564</b>f, which is a variable number of queues, and places the packets in these class queues. How packets are placed in class queues <b>1564</b>a-<b>1564</b>f is determined by the inputs to module <b>1562</b>.

Module <b>1562</b> can receive inputs from hierarchical class-based priority processor module <b>1574</b>, VPN DEN data table <b>1572</b> and service level agreement (SLA) priority data table <b>1570</b>. The queuing function of module <b>1562</b> can be based on these inputs.

SLA priority data table <b>1570</b> can use predetermined service level agreements for particular customers to affect the queuing function. A customer can be provided a higher quality of telecommunications service by, for example, paying additional money to receive such premium service. An algorithm running on module <b>1562</b> can increase the queuing priority for messages transmitted to such customers.

Virtual private network (VPN) directory enabled networking (DEN) data table <b>1572</b> can provide prioritization for a predetermined quality of service for a VPN for a company that pays for the VPN function. A VPN is understood by those skilled in the relevant art to be a private network, including a guaranteed allocation of bandwidth on the network, provided by the telecommunications service provider. VPN DEN data table <b>1572</b> permits module <b>1562</b> to provide higher quality of service for customer-purchased VPNs. As with SLA priority data table <b>1570</b>, the queuing priority can be increased for such VPNs. For example, a platinum level VPN's lowest priority IP flow classes could also be given a higher priority than a high priority brass level VPN.

Both SLA priority data table <b>1570</b> and VPN DEN data table <b>1572</b> receive input from operations, administration, maintenance and provisioning (OAM&amp;P) module <b>1108</b>. This is a module that is kept off-line, and includes storage and revision of administrative information regarding new customers, or updates of information pertaining to existing customers. For example, the SLA priority of the customers and VPN information is updated from OAM&amp;P module <b>1108</b>.

Hierarchical class-based priority processor module <b>1574</b> is a module that operates under the principles of hierarchical class-based queuing. Hierarchical class-based queuing was created by Sally Floyd and Van Jacobson, considered early architects of the Internet.

Hierarchical class-based queuing classifies different types of IP flows using a tree structure at the edge access device routers. Each branch of the tree signifies a different class of IP flows, and each class is dedicated a set limited amount of bandwidth. In this manner, different classes of flows are guaranteed minimum bandwidth, so that no single IP data flow within a class, and no single class of IP flows, can use up all available bandwidth. The present invention adds a prioritization feature enabling class based priority reservations to be made using the hierarchical class queue concept, as discussed above with respect to <figref idref="DRAWINGS">FIGS. 13 and 14</figref>.

MAC downlink subframe scheduler <b>1566</b> is a processor module that takes the packets queued in class queues <b>1564</b>a-<b>1564</b>f, and can make frame slot reservations to fill up subframes <b>1568</b>a-<b>1568</b>k based on priorities <b>1570</b>, <b>1572</b> and <b>1574</b>, which is a variable number of frames. In one embodiment, each subframe is scheduled (filled) with up to a predetermined number of packets from each of the classes <b>1564</b>a-<b>1564</b>f according to priorities <b>1570</b>, <b>1572</b> and <b>1574</b>. In another embodiment, the subframes are scheduled according to the inventive advanced reservation algorithm method described with respect to <figref idref="DRAWINGS">FIGS. 13 and 14</figref> for isochronous reservations. In yet another embodiment, the subframes are scheduled according to a combination of known methods and the advanced reservation algorithm method of the present invention.

The subframes can then be sent to WAP antenna <b>290</b>d for wireless transmission over the wireless medium to RF transceiver subscriber antenna <b>292</b>d coupled to subscriber CPE station <b>294</b>d, which in turn can send the packets contained in the subframes to subscriber workstation <b>120</b>d at CPE subscriber location <b>306</b>d. The subframes can be scheduled from highest priority to lowest priority.

Hierarchical class-based priority (HCBP) processor module <b>1574</b> receives as input the subframes that have been scheduled and transmitted from WAP antenna <b>290</b>d. By maintaining awareness of the status of the packets (i.e., by knowing which packets have been sent out), HCBP processor module <b>1574</b> knows which packets from which class queues <b>1564</b>a-<b>1564</b>f must yet be scheduled.

Every once in a while, a packet is lost through, e.g., noise. When this situation arises, the subscriber CPE station <b>294</b>d sends a retransmit request <b>1576</b> to WAP <b>290</b>d, which transmits the request to link layer acknowledgment (ARQ) processor <b>1578</b>. ARQ processor <b>1578</b> informs MAC downlink subframe scheduler <b>1566</b> of this condition, which in turn reschedules the requested packets from the appropriate class queues <b>1564</b>a-<b>1564</b>f for retransmission. Link layer acknowledgment ARQ processor <b>1578</b> also awaits positive acknowledgments from subscriber CPE station <b>294</b>d, to determine that the data packets have been properly received. Only after receiving a positive receipt acknowledgment does MAC downlink subframe scheduler <b>1566</b> remove the packet from class queues <b>1564</b>a-<b>1564</b>f.

Each subscriber CPE station <b>294</b>d has a limited amount of memory available for received data packets in an IP flow. When, for example, the devices coupled to the subscriber CPE station <b>294</b>d (e.g., subscriber workstation <b>120</b>d) stop receiving IP data flows (e.g., subscriber workstation <b>120</b>d goes down), the CPE data packet queues in CPE subscriber station <b>294</b>d are quickly filled up. In this scenario, subscriber CPE station <b>294</b>d transmits a CPE IP flow queue depth message <b>1580</b> indicating that the queue is filled up, which can be received by CPE IP flow queue depth status processor <b>1582</b>. CPE queue depth processor <b>1582</b> informs MAC downlink subframe scheduler <b>1566</b> of this condition, which stops scheduling downlink subframes directed to subscriber CPE station <b>294</b>d. Processor <b>1582</b> can also send messages to MAC downlink subframe scheduler <b>1566</b> to flush particular IP flows from class queues <b>1564</b>a-<b>1564</b>f.

h. Uplink SubFrame Prioritization

1. Overview

<figref idref="DRAWINGS">FIGS. 16A and 16B</figref> are exemplary logical flow diagrams for the uplink. The logical flow pertains to analysis and scheduling of shared wireless bandwidth to IP packet flows from a subscriber workstation <b>120</b>d coupled to a subscriber CPE station <b>294</b>d, being transmitted over the wireless medium up to the wireless base station <b>302</b>, and on to data network <b>142</b> for transmission to a destination host workstation <b>136</b>a. <figref idref="DRAWINGS">FIG. 16A</figref> is an exemplary logical flow diagram <b>1600</b> for uplink IP flow analyzer <b>632</b>. <figref idref="DRAWINGS">FIG. 16B</figref> is an exemplary logical flow diagram <b>1660</b> for the uplink flow scheduler <b>634</b>.

The functional components for <figref idref="DRAWINGS">FIGS. 16A and 16B</figref> are explained by way of method modules, which can be viewed as physical units (e.g., comprising software, hardware, or a combination thereof) or logical vehicles (e.g., used for explanatory purposes only). Those skilled in the art will recognize that the modules are used only to explain an exemplary embodiment, and are not to be considered limiting.

The exemplary logical flow diagram <b>1600</b> for uplink IP flow analyzer <b>632</b> of <figref idref="DRAWINGS">FIG. 16A</figref> includes packet header identification component <b>1602</b>, packet characterization component <b>1604</b>, packet classification component <b>1606</b>, and IP flow presentation component <b>1608</b>. The functions of these components are explained in detail below.

In one embodiment, uplink IP flow analyzer <b>632</b> is physically located in wireless base station <b>302</b>, although those skilled in the art will recognize that the same functionality can be located remotely from wireless base station <b>302</b>. In a preferred embodiment of the present invention, the function of IP flow analyzer <b>632</b> is performed at a subscriber CPE station <b>294</b>d desiring an uplink reservation slot for uplinking a packet/IP flow up to base station <b>302</b>. A reservation request block (RRB) request detailing the IP flow identifier, number of packets and classification of the IP flow can be created then by IP flow analyzer <b>632</b> and can be uplinked via preferably a contention RRB slot for scheduling by uplink frame scheduler <b>634</b> in future uplink subframe slots up at wireless base station <b>302</b>.

<figref idref="DRAWINGS">FIGS. 2D, 3A and 3B</figref> are helpful to the reader for an understanding of the uplink IP flow analyzer.

2. Introduction

IP flow analyzer <b>632</b> performs the function of identifying, characterizing, classifying, and presenting data packets to an uplink frame scheduler <b>634</b>. The functions of identifying, characterizing, classifying and presenting the data packets can be respectively performed by packet header identification component <b>1602</b>, packet characterization component <b>1604</b>, packet classification component <b>1606</b> and IP flow presentation component <b>1608</b> of uplink IP flow analyzer <b>632</b>.

Packet header identification component <b>1602</b> determines whether a packet of an incoming IP flow is known to the system (i.e. is an existing IP flow), or if it is the first data packet of a new IP data flow, and determines the source application based on fields in the header section of the packet. Identification <b>1602</b> can include buffering packets and extracting and parsing the header contents. Packet characterization component <b>1604</b> characterizes a new data packet (of a new IP flow) to determine the QoS requirements for the IP flow based on the source application, and to identify the subscriber CPE station that will receive the IP flow. Packet classification component <b>1606</b> classifies the new IP data flow into one of several priority classes. Classification <b>1606</b> can include, e.g., grouping packets having similar QoS requirements. IP data flow presentation <b>1608</b> initializes the new IP data flow and presents it to uplink flow scheduler <b>634</b>.

Each time a subscriber CPE station <b>294</b>d attempts to communicate in the uplink direction with wireless base station <b>302</b>, it requests a reservation by inserting an RRB in the uplink subframe. Uplink frame scheduler <b>634</b> then schedules the reservation request in a future uplink subframe and notifies the CPE station <b>294</b>d of the reservation. In a downlink signal, uplink flow scheduler <b>634</b> located preferably at wireless base station <b>302</b>, transmits a reservation slot in a particular future frame for the requesting subscriber CPE station <b>294</b>d to transmit its uplink data. Uplink flow scheduler <b>634</b> assigns the reservation based on the same parameters as the downlink flow scheduler <b>604</b> uses in the downlink. In other words, uplink flow scheduler <b>634</b> determines the reservation slots based on the queue class priority and based on a set of rules, schedules the reservations for uplink transmissions from subscriber CPE station <b>294</b>d using, e.g., an advanced reservation algorithm. The rules are determined by inputs to the uplink flow scheduler <b>634</b> from a hierarchical class-based priority processor module <b>1674</b>, a virtual private network (VPN) directory enabled (DEN) data table <b>1672</b>, and a service level agreement (SLA) priority data table <b>1670</b>. The advanced reservation algorithm is described with respect to <figref idref="DRAWINGS">FIG. 14</figref>.

3. Identification

Packet header identification component <b>1602</b> identifies the IP flow received from a subscriber CPE station <b>294</b>d based on the packet's header contents.

A stream of packets, also known as packets from several IP flows (i.e. each IP flow is associated with a single “call”) is received at packet header identification component <b>1602</b>. The IP flow in one embodiment is transmitted to subscriber CPE station <b>294</b>d from one or more subscriber workstations <b>120</b>d for uplink to host computers <b>136</b>a coupled to wireless base station <b>302</b> by data network <b>142</b>. Subscriber CPE station <b>294</b>d can transmit the data packets of the IP flow to packet buffer module <b>1610</b> of packet header identification component <b>1602</b>. In one embodiment, packet header identification component is within CPE subscriber station <b>294</b>d. At module <b>1610</b>, the received packets are buffered in a storage area for transfer to header extraction module <b>1620</b>. At module <b>1620</b>, the packet header files are extracted and parsed to obtain the contents of the packet header fields.

Relevant fields can include, e.g., source, destination, type of service (TOS) and differentiated service (DiffServ) markings, if any exist.

For IP flows known to the system, there are entries in existing IP flow identification table <b>1626</b>. An IP flow is in the system if a previous packet of the IP flow of the existing IP data call has already been identified. In module <b>1622</b>, it is determined if there is a match between the incoming IP flow and an entry in table <b>1626</b>. If so, then the IP flow is known to the system, and control passes to module <b>1630</b> of the packet characterization component <b>1604</b>.

If the IP flow is not an existing flow known to the system, meaning that the IP flow is a new IP flow, then control passes to module <b>1624</b>, where the packet header fields are analyzed to identify the source application of the IP flow.

Packet header analysis module <b>1624</b> determines from source application packet header table <b>1628</b> the type of source application making the IP flow. The application can be any of the types of applications described with respect to <figref idref="DRAWINGS">FIG. 2D</figref> or known to those skilled in the art. Examples include a file transfer protocol (FTP) download from another client workstation <b>138</b>f, a voice telephony call from a caller <b>124</b>d (connected over a modem), a fax machine call, and a conference call from multiple callers <b>124</b>d and <b>126</b>d (connected over a modem), to name a few. If the IP flow is a new IP flow, then the identification information about the new IP flow is added to table <b>1626</b>, and control passes from analysis module <b>1624</b> to module <b>1632</b> of the packet characterization component <b>1604</b>.

4. Characterization

Packet characterization component <b>1604</b> characterizes the IP flow and passes it to packet classification component <b>1606</b> for classification.

If the IP flow is an existing IP flow, control passes to module <b>1630</b> from module <b>1622</b> of the packet header identification component <b>1602</b>. If in module <b>1622</b> it is determined that the IP data flow is known to the system, in module <b>1630</b> it is determined whether the packet is old (i.e., stale). This can include determining from a time-to-live field (a field in the IP packet header) the age of the packet, and comparing the field to a threshold age value. If the packet is determined to be stale, it is discarded. Module <b>1630</b> can anticipate application packet discards. From module <b>1630</b>, control passes to module <b>1640</b> of the packet classification component <b>1606</b>.

If the IP flow is new, control passes to module <b>1632</b> from module <b>1624</b> of the packet header identification component <b>1602</b>. If in module <b>1624</b> it is determined that the application associated with the IP flow application is not known to the system, in IP flow QoS requirements lookup module <b>1632</b> the QoS requirements for the application associated with the IP flow are determined. Module <b>1632</b> performs this operation by looking up the application in IP flow QoS requirement table <b>1634</b>. Different applications have different requirements. For example, bandwidth allocation (i.e., allocating an appropriate amount of bandwidth) is important to an application performing FTP downloads, and not jitter (i.e., time synchronizing the received data) and latency (i.e., the amount of time passage between responses). On the other hand, jitter and latency are important to voice telephony and conference calls, and bandwidth allocation is not.

After processing by module <b>1632</b>, control passes to module <b>163</b>b. In CPE subscriber station identifier (ID) lookup module <b>1636</b> a subscriber CPE ID lookup is performed for the new IP data flow. Each subscriber CPE station <b>294</b>d can have one or more applications, running on one or more subscriber workstations <b>120</b>d, homed to it. Accordingly, one or many subscribers can generate or receive an IP flow directed from or at a subscriber CPE station <b>294</b>d. A subscriber workstation <b>120</b>d can be any device coupled to a subscriber CPE station <b>294</b>d. Module <b>1636</b> looks up the CPE station identifier for the IP flow in table <b>1638</b>, to provide the CPE ID in the reservation request block (RRB). Control then passes from module <b>1636</b> to module <b>1648</b> of the packet classification component <b>1606</b>.

5. Classification

Packet classification component <b>1606</b> classifies the IP flow and passes it to IP flow presentation component <b>1608</b> for presentment.

For existing IP flows, control passes to module <b>1640</b> from module <b>1630</b> of the packet characterization component <b>1604</b>. If in module <b>1630</b> it is determined that the packet is not stale, then in module <b>1640</b> the packet is associated with its IP flow. As illustrated in <figref idref="DRAWINGS">FIG. 16A</figref>, the packet processed herein was determined to be a portion of an IP flow known to the system. Therefore, the QoS processing of modules <b>1632</b>, <b>1636</b> and <b>1642</b> are unnecessary, because the QoS requirements of the present packet are the same as for its IP flow.

For new IP flows, control passes to module <b>1642</b> from module <b>1636</b> of the packet characterization component <b>1604</b>. In module <b>1642</b> the packet is classified or grouped into a QoS class by performing an IP flow QoS requirement table <b>1644</b> lookup where the QoS classes are stored depending on the QoS requirements for packets. From module <b>1642</b>, control passes to module <b>1648</b> of IP flow presentation component <b>1608</b>.

6. IP Flow Presentation

IP flow presentation component <b>1608</b> prepares and presents the IP data flow packets to flow scheduler <b>634</b>. In one embodiment of the uplink direction, a reservation request block (RRB) is created and uplinked via a contention slot to the wireless base station <b>302</b> for scheduling by IP flow scheduler <b>634</b>. In another embodiment, the scheduler is located at the CPE station <b>294</b>d so no reservation request is needed.

For existing IP flows, control passes to module <b>1646</b> from module <b>1640</b> of the packet classification component <b>1640</b>. In module <b>1646</b>, the packet is added to the IP flow queue, which is the queue for the current existing IP flow. In one embodiment, this can include preparation of a RRB. From module <b>1646</b>, control passes to module <b>1662</b> of uplink flow scheduler <b>634</b>. In one embodiment, this can include uplink of the RRB from CPE <b>294</b>d to wireless base station <b>302</b>.

For a new IP flow, control passes to module <b>1648</b> from module <b>1642</b> of the packet classification component <b>1606</b>. In initialize IP flow module <b>1648</b>, this new IP flow is initialized for presentation to module <b>1652</b>. Module <b>1652</b> presents the IP data flow (in particular, the reservation request block data packet) to module <b>1662</b> of uplink flow scheduler <b>634</b>. In module <b>1650</b>, the QoS class for the IP flow is presented to scheduler <b>634</b>, preferably by inclusion in a RRB.

7. Uplink Flow Scheduler

The exemplary logical flow diagram for the uplink flow scheduler <b>634</b> of <figref idref="DRAWINGS">FIG. 16B</figref> comprises IP flow QoS class queuing processor module <b>1662</b>, MAC uplink subframe scheduler module <b>1666</b>, hierarchical class-based priority processor module <b>1674</b>, VPN DEN data table module <b>1672</b>, SLA priority data table <b>1670</b>, CPE IP flow queue depth status processor <b>1682</b> and link layer acknowledgment processor module <b>1678</b>.

Uplink flow scheduler <b>634</b> of <figref idref="DRAWINGS">FIG. 16B</figref> also includes QoS class queues for class 1, <b>1664</b>a; class 2, <b>1664</b>b; class 3, <b>1664</b>c; class 4, <b>1664</b>d; class 5, <b>1664</b>e; and class 6, <b>1664</b>f; and MAC uplink subframes: frame n <b>1668</b>a; frame n+1, <b>1668</b>b; frame n+2, <b>1668</b>c; frame n+3, <b>1668</b>d, . . . frame n+p, <b>1668</b>k.

In one embodiment, uplink flow scheduler <b>634</b> is physically located in wireless base station <b>302</b>, although those skilled in the art will recognize that the same functionality can be located remotely from wireless base station <b>302</b>. For example, in another embodiment, uplink flow scheduler <b>634</b> can be located at CPE station <b>294</b>d and is in communication with other CPE stations <b>294</b> and the wireless base station <b>302</b>.

Uplink flow scheduler <b>634</b> is used to schedule the uplink subframe. The entire frame is divided into an uplink portion (called an uplink subframe) for transmitting uplink frames, and a downlink portion (called a downlink subframe) for transmitting downlink frames.

Illustrated in <figref idref="DRAWINGS">FIG. 16B</figref> are WAP antenna <b>290</b>d, the wireless medium, RF transceiver subscriber antenna <b>292</b>d, subscriber CPE station <b>294</b>d and subscriber workstation <b>120</b>d. WAP <b>290</b>d and RF transceiver subscriber antenna <b>292</b>d respectively provide a wireless connection between wireless base station <b>302</b> (where uplink flow scheduler <b>634</b> resides in one embodiment) and subscriber CPE station <b>294</b>d, which can transmit upstream an IP flow from an application running on client computer <b>120</b>d. WAP <b>290</b>d serves as a wireless gateway for data network <b>142</b>, and RF transceiver subscriber antenna <b>292</b>d serves as a wireless gateway for subscriber CPE station <b>294</b>d to uplink the IP flow packet data.

Also illustrated in <figref idref="DRAWINGS">FIG. 16B</figref> is data interface <b>320</b>, which provides a connection from uplink flow scheduler <b>634</b> for sending uplinked IP flow packets on to data router <b>140</b>d of data network <b>142</b> and on to a destination host computer <b>136</b>a. These connections are also illustrated in <figref idref="DRAWINGS">FIGS. 2D and 3B</figref>.

The previous frame includes an uplink reservation request which is received by the wireless base station from a subscriber CPE station <b>294</b>d. At this point, the reservation request block has been identified, characterized, classified, and presented, preferably at the CPE station <b>294</b>d, and has been transmitted to uplink flow scheduler <b>634</b> from uplink flow analyzer <b>632</b> at the CPE <b>294</b>d. In particular, the reservation request block is presented to IP flow QoS class queuing processor module <b>1662</b> from module <b>1650</b>. Module <b>1662</b> informs MAC uplink subframe scheduler <b>1666</b> of the reservation.

In turn, MAC uplink subframe scheduler <b>1666</b> uses a slot in the subframe to acknowledge receipt of the request called the acknowledgment request block (ARB). An exemplary slot used to convey the frame, slot, and IP flow identifier for this reservation is described with respect to <figref idref="DRAWINGS">FIG. 12</figref>. Scheduler <b>1666</b> transmits in this reservation slot the CPE identification data, along with which future slot(s) and frame(s) the requesting subscriber CPE station <b>294</b>d is permitted to use for uplink of the requested data packet IP flow transmissions.

The future slot(s) in the future frame(s) are assigned, e.g., based on inputs from hierarchical class-based priority processor module <b>1674</b>, VPN DEN data table <b>1672</b> and service level agreement (SLA) priority data table <b>1670</b>. These components function in a similar manner to hierarchical class-based priority processor module <b>1574</b>, VPN DEN data table <b>1572</b> and service level agreement (SLA) priority data table <b>1570</b>, described with respect to the downlink flow scheduler <b>604</b>.

When IP flow QoS class queuing processor module <b>1662</b> receives packets of an existing or new IP flow from IP flow presentation module <b>1608</b>, it then creates class queues <b>1664</b>a-<b>1664</b>f, which is a variable number of queues, and places the packets in these class queues. In a preferred embodiment there are between 3 and 10 classes. These queues hold reservation request packets for scheduling. Packets are placed in class queues <b>1664</b>a-<b>1664</b>f according to the contents of the reservation request block for input to module <b>1662</b>.

Module <b>1662</b> receives inputs from hierarchical class-based priority processor module <b>1674</b>, VPN DEN data table <b>1672</b> and service level agreement (SLA) priority data table <b>1670</b>. The queuing function of module <b>1662</b> is based on these inputs. These components function analogously to their counterparts in the downlink flow scheduling method. SLA priority data table <b>1670</b> and VPN DEN data table <b>1672</b> receive input from operations, administration, maintenance and provisioning (OAM&amp;P) module <b>1108</b>. OAM&amp;P module <b>1108</b> provides updates to priorities when, e.g., a subscriber modifies its service level agreement or a VPN subscription is changed.

MAC uplink subframe scheduler <b>1666</b> takes the requests queued in class queues <b>1664</b>a-<b>1664</b>f, and schedules reservations of slots in frames <b>1668</b>a-<b>1668</b>k, which is a variable number of frames. In one embodiment, each frame is scheduled with up to a predetermined number limit or percentage limit of packets from each of the classes <b>1664</b>a-<b>1664</b>f. The requests can be scheduled as shown in <figref idref="DRAWINGS">FIG. 13</figref>, taking into account certain priorities. In another embodiment, the frames are scheduled according to the inventive advanced reservation algorithm method for scheduling isochronous type traffic described with respect to <figref idref="DRAWINGS">FIG. 14</figref>. In yet another embodiment, the frames are scheduled according to a combination of known methods and the advanced reservation algorithm method of the present invention.

The reservation slot schedule can then be sent down to the CPE stations <b>294</b> using, e.g., FDB slots such as <b>1236</b>g and <b>1236</b>h of <figref idref="DRAWINGS">FIG. 12F</figref>. The uplink slots can then be inserted by CPE station <b>294</b>d into the uplink subframe as scheduled. The frame slots are then transmitted up from CPE station <b>294</b>d to wireless base station <b>302</b> and are then sent on as packets to their destination addresses. For example, from wireless base station <b>302</b> the packets can be transmitted over data network <b>142</b> to a host computer <b>136</b>a.

After the uplink packets are received by the wireless base station <b>302</b>, the wireless base station <b>302</b> sends an upstream acknowledgment data block (UAB) message back down to the transmitting subscriber CPE station <b>294</b>d, to acknowledge receipt of the transmitted data packets.

Every once in a while, a packet is lost through noise or other interference in the wireless medium. When this situation arises, the subscriber CPE station <b>294</b>d determines that it has not received a UAB data acknowledgment, so it sends a retransmit request requesting another uplink reservation slot to wireless base station <b>302</b> via WAP <b>290</b>d, which transmits the request to link layer acknowledgment (ARQ) processor <b>1678</b>. ARQ processor <b>1678</b> informs MAC uplink subframe scheduler <b>1666</b> of the need of retransmission (i.e. the need of a frame slot reservation for resending the uplink packet). CPE subscriber station <b>294</b>d can also send to ARQ processor <b>1678</b>, other data messages about nonreceipt of uplink transmission acknowledgments. The ARQ <b>1678</b> can forward such messages on to the uplink subframe scheduler <b>1666</b>. The uplink subframe scheduler <b>1666</b> in turn reschedules the requested uplink reservation from the appropriate class queues <b>1664</b>a-<b>1664</b>f. Alternatively, in another embodiment, link layer acknowledgment processor <b>1678</b> can also send a positive UAB acknowledgment to the subscriber CPE station <b>294</b>d, to indicate that the data packets have been properly received. Thus uplink scheduler <b>1666</b> in addition to scheduling first time reservations, also can schedule repeat reservations for lost packets.

Each subscriber CPE station <b>294</b>d has a limited amount of memory space available for queuing packets received from subscriber workstations <b>120</b>d awaiting reservation slots of uplink from the CPE <b>294</b>d to wireless base station <b>302</b>. When, for example, the the queue of subscriber CPE station <b>294</b>d becomes full from a backup of packets awaiting upstream reservations, IP data flows can potentially be lost, or packets may become stale. In this scenario, subscriber CPE station <b>294</b>d transmits a CPE IP flow queue depth message <b>1680</b> to the wireless base station <b>302</b> indicating that the queue is filled up, which can be received by CPE IP flow queue depth status processor <b>1682</b>. Processor <b>1682</b> can inform MAC uplink subframe scheduler <b>1666</b> of this condition, which can, e.g., increase temporarily the priority of IP flows at subscriber CPE station <b>294</b>d to overcome the backlog or can, e.g., stop transmitting additional downlink packets to the CPE station <b>294</b>d until the queue depth backlog is decreased to an acceptable level again. Processor <b>1682</b> can also send messages to MAC uplink subframe scheduler <b>1666</b> to flush reservation requests from the subscriber CPE station <b>294</b>d in class queues <b>1664</b>a-<b>1664</b>f.

4. TCP Adjunct Agent

TCP is a reliable transport protocol tuned to perform well in traditional networks where congestion is the primary cause of packet loss. However, networks with wireless links incur significant losses due to bit-errors. The wireless environment violates many assumptions made by TCP, causing degraded end-to-end performance. See for example, Balakrishnan, H., Seshan, S. and Katz, R. H., “Improving Reliable Transport and Handoff Performance in Cellular Wireless Networks,” University of California at Berkeley, Berkeley, Calif., accessible over the Internet at URL, http://www.cs.berkeley.edu/˜ss/papers/winet/html/winet.html, dealing more directly with handoffs and bit errors in a narrowband wireless environment, the contents of which are incorporated by reference. Attempts to address this problem have modified TCP in order to overcome it. However, this is not a commercially feasible means of overcoming this challenge. It is impracticable to implement any solution that requires a change to the standard operation of TCP.

The present invention uses an enhanced MAC layer which interfaces with a TCP adjunct agent to intercept TCP layer requests to manipulate the TCP layers at either a source or destination end of a transmission, to modify TCP behavior at the source and destination of the TCP/IP transmission which includes an intermediary wireless link. Packets can be queued at the wireless base station awaiting receipt acknowledgment and the base station can perform local retransmissions across the wireless link to overcome packet loss caused by high bit-error rates. Communication over wireless links is characterized by limited bandwidth, high latencies, sporadic high bit-error rates and temporary disconnections which must be dealt with by network protocols and applications.

Reliable transport protocols such as TCP have been tuned for traditional wired line networks. TCP performs very well on such networks by adapting to end-to-end delays and packet losses caused by congestion. TCP provides reliability by maintaining a running average of estimated round-trip delay and mean deviation, and by retransmitting any packet whose acknowledgment is not received within four times the deviation from the average. Due to the relatively low bit-error rates over wired networks, all packet losses are correctly assumed to be caused by congestion.

In the presence of the high bit-error rates characteristic of wireless environments, TCP reacts to packet losses as it would in the wired environment, i.e. it drops its transmission window size before retransmitting packets, initiates congestion control or avoidance mechanisms (e.g., slow start) and resets its retransmission timer. These measures result in an unnecessary reduction in the link's bandwidth utilization, thereby causing a significant degradation in performance in the form of poor throughput and very high interactive delays.

The present invention maintains packets in class queues awaiting acknowledgment of receipt from the subscriber CPE stations. Unacknowledged data slots can then be resent by having the wireless base station perform local retransmissions to the subscriber CPE station. By using duplicate acknowledgments to identify a packet loss and performing local retransmissions as soon as the loss is detected, the wireless base station can shield the sender from the inherently high bit error rate of the wireless link. In particular, transient situations of very low communication quality and temporary disconnectivity can be hidden from the sender.

For transfer of data from a CPE subscriber host to a wireless base station host, missing packets are detected at the wireless base station and negative acknowledgments can be generated for them. The negative acknowledgments can request that the packet be resent from the CPE subscriber host (the sender). The CPE subscriber host can then process the negative acknowledgment and retransmit corresponding missing packets. Advantageously, no modifications to the sender TCP or receiver TCP is necessary, since the present invention places TCP aware functionality in the MAC layer.

<figref idref="DRAWINGS">FIG. 5A</figref> illustrates flow <b>500</b> depicting IP flows from a source TCP at a subscriber host, down a protocol stack for transmission through a CPE subscriber station, through a wireless medium to a wireless base station, up and through a protocol stack at the wireless base station having an example TCP adjunct agent, then through a wireline connection and through a protocol stack to a destination host. The adjunct TCP agent modifies operation of a TCP sliding window algorithm at the transmitting TCP and in cooperation with proactive reservation-based intelligent multi-media access technology (PRIMMA) media access control (MAC) enables local retransmission over the wireless medium in accord with the present invention.

Specifically, flow <b>500</b> illustrates IP packet flow from subscriber workstation <b>120</b>d, through CPE subscriber station <b>294</b>d at CPE subscriber location <b>306</b>d, then over a wireless transmission medium to wireless base station <b>302</b>, and eventually over a wireline link over data network <b>142</b> to host workstation <b>136</b>a.

TCP adjunct agent <b>510</b>e makes sure transport is reliable by modifying operation of the TCP sliding window algorithm at the transmitting TCP in a manner that optimizes the window for the wireless medium. TCP adjunct agent <b>510</b>e advantageously is transparent to industry standard protocols as agent <b>510</b>e does not require modification of the standard TCP/UDP layer of client subscriber workstation <b>120</b>d or host workstation <b>136</b>a.

Flow <b>500</b> includes IP flows from application layer <b>512</b>a, down the protocol stack through TCP/UDP layer <b>510</b>a, through IP layer <b>508</b>a, then through point-to-point (PPP) layer <b>520</b>a, then through data link Ethernet layer <b>504</b>a, then through 10 BaseT Ethernet network interface card (NIC) physical layer <b>502</b>a, over a wire line connection to 10 BaseT Ethernet NIC physical layer <b>502</b>b of subscriber CPE <b>294</b>d.

Subscriber CPE <b>294</b>d flows packets coming in from NIC <b>502</b>b, back up its protocol stack through Ethernet layer <b>504</b>b, through PPP layers <b>520</b>b and <b>520</b>c, back down through PRIMMA MAC <b>504</b>c to wireless physical layer <b>502</b>c including antenna <b>292</b>d, then over the wireless medium to antenna <b>290</b>d of wireless base station <b>302</b>.

Wireless base station <b>302</b> flows packet IP flows up from antenna <b>290</b>d at physical layer <b>502</b>d through PRIMMA MAC layer <b>504</b>d, through PPP layer <b>520</b>a, through IP layer <b>508</b>d to TCP adjunct agent <b>510</b>e, which can flow IP flows down through IP layer <b>508</b>e, through PPP layer <b>520</b>e, through wide area network (WAN) layer <b>504</b>e, through wireline physical layer <b>502</b>e, through interface <b>320</b>, over routers <b>140</b>d, through data network <b>142</b>, via wireline connections to wireline layer <b>502</b>f of WAN host workstation <b>136</b>a.

Host workstation <b>136</b>a flows IP flows from wireline layer <b>502</b>f, up through its protocol stack through WAN layer <b>504</b>f, through PPP layer <b>520</b>f, through IP layer <b>508</b>f, to TCP/UDP layer <b>510</b>f and on to application layer <b>512</b>f.

TCP/UDP layers <b>510</b>a and <b>510</b>f act to provide such transport functions as, e.g.,segmentation, managing a transmission window, resequencing, and requesting retransmission of lost packet flows. Normally TCP layers <b>510</b>a and <b>510</b>f would send a window of packets and then await acknowledgment or requests for retransmission. A TCP sliding window algorithm is normally used to vary the transmission flow to provide optimized transport and to back off when congestion is detected by receipt of requests for retransmission. Unfortunately in the wireless environment, due to high bit error rates, not all packets may reach the destination address, not because of congestion, but rather because of high bit error rates, so as to prompt a retransmission request from the destination IP host to the source. Rather than slow transport, TCP adjunct agent <b>510</b>e modifies operation of the TCP sliding window algorithm to optimize operation over wireless. PRIMMA MAC layer <b>504</b>d interacts with TCP adjunct agent <b>510</b>e permitting the agent to intercept, e.g., retransmission requests, from TCP layer <b>510</b>a of subscriber workstation <b>120</b>d intended for host <b>136</b>a, and allowing the wireless base station to retransmit the desired packets or flows to subscriber workstation <b>120</b>d rather than forwarding on the retransmission request to host <b>136</b>a, since the packets could still be stored in the queue of PRIMMA <b>504</b>d and would not be discarded until an acknowledgment of receipt is received from the subscriber CPE. Since retransmission can be performed according to the present invention at the PRIMMA MAC data link layer, i.e. layer 2, retransmission can occur from the base station to the CPE subscriber, rather than requiring a retransmission from all the way over at the transmitting source TCP which would cause TCP to backoff its sliding window algorithm. Thus, by having wireless base station <b>302</b> retransmit until receipt is acknowledged over the wireless link, the inherently high bit error rate can be overcome, while maintaining an optimal TCP window.

Recall, a TCP transmitter transmits a TCP sliding window block of packets and alters the size of the window upon detection of congestion. The TCP transmitter transports a block of packets in a window, and then awaits acknowledgment from the receiver. If transmission is going smoothly, i.e. no congestion or lost packets occur, then the transmitter TCP ramps up the transmission rate. This increased transmission rate continues until the transmitting TCP detects congestion or packet loss. When notified of congestion, the transmitting TCP stops transmitting, backs off and sends a smaller block (i.e. a smaller window) of packets.

TCP adjunct agent modifies normal TCP operation by tricking the transmitting TCP and its transmitting window algorithm. The TCP adjunct agent prevents the transmitter from being notified of loss, i.e. receiving congestion notification, from the receiving TCP by, e.g., preventing duplicate retransmission requests. Since the transmitting TCP does not receive such notification, it does not modify the TCP sliding window and transmission continues at the higher rate.

In the event that real congestion occurs, i.e. if the TCP adjunct agent recognizes packets really were lost, then the TCP adjunct agent can let the retransmission request go through to the transmitting TCP. This is advantageously accomplished because the MAC link layer of the present invention is in communication with the higher protocol layers, it is application aware, transport aware and network aware. In this case, because the MAC layer is transport layer aware, PRIMMA MAC layer <b>504</b>d communicates with the TCP adjunct agent <b>510</b>e at layer 4. Since the MAC requires acknowledgment of receipt of wireless transmissions sent to the CPE subscriber station <b>294</b>d for every packet sent from the wireless base station <b>302</b>, the MAC layer <b>504</b>d knows whether an inter-TCP layer communication, e.g., a request for retransmission, is sent from a client computer TCP at the CPE station is created because the lost packet was lost in wireless transmission, or because of real congestion.

If PRIMMA MAC <b>504</b>d does not receive an acknowledgment from <b>504</b>c, then the PRIMMA MAC <b>504</b>d of wireless base station <b>302</b> can retransmit the contents of the lost packet to the subscriber CPE station <b>294</b>d. If the PRIMMA MAC <b>504</b>c of the subscriber CPE station <b>294</b>d acknowledges receipt and still requests a retransmission, then real congestion could have occurred and the PRIMMA MAC <b>504</b>d of the wireless base station <b>302</b> can let the TCP adjunct agent <b>510</b>e know that it should allow the retransmission request to be sent to the transmitting TCP <b>510</b>f of host workstation <b>136</b>a.

Thus, TCP adjunct agent <b>510</b>e of the present invention can modify operation of the TCP sliding window algorithm in a manner that is optimal for the wireless medium, without requiring any change to commercially available TCP layers <b>510</b>a and <b>510</b>f at the receiver and sender hosts. In an embodiment, TCP adjunct agent <b>510</b>e obviates the need for any modification of the TCP layers at either the sending (i.e. transmitting) host or client. In another embodiment the host and client TCP layers are unaware of the modification of operation by the TCP adjunct agent, i.e. it is transparent to source and destination TCP layers. In another embodiment, TCP adjunct agent <b>510</b>e intercepts retransmission requests between a TCP layer of the client computer coupled to the subscriber CPE station and the TCP layer of the host workstation coupled to the data network.

<figref idref="DRAWINGS">FIG. 5B</figref> illustrates functional flow diagram <b>522</b> including an example functional description of TCP adjunct agent <b>510</b>e performing an outgoing TCP spoof function. Referring to <figref idref="DRAWINGS">FIG. 5B and 5A</figref>, diagram <b>522</b> assumes that a TCP layer <b>510</b>f at a transmitting host <b>136</b>a has transmitted a windowful of packet data to subscriber workstation <b>120</b>d, and awaits acknowledgment. Diagram <b>522</b> illustrates receipt of an outgoing TCP message <b>524</b> in TCP adjunct agent <b>510</b>e at wireless base station <b>302</b> which has been sent from subscriber workstation <b>120</b>d via subscriber CPE station <b>294</b>d.

In step <b>526</b>, the TCP header contents of outgoing TCP message <b>524</b> is parsed in order to reveal the contents of the message being sent from subscriber workstation <b>120</b>d through the wireless network toward the transmitting host <b>136</b>a.

In step <b>528</b>, it is determined whether the TCP header contents includes a duplicate acknowledgment message from the CPE station. Receiving a duplicate acknowledgment request from the CPE subscriber location could be indicative of a lost message in the wireless medium, or a real congestion problem. If in step <b>528</b> the TCP packet is determined to be a duplicate acknowledgment message, then processing can continue with step <b>532</b>, if not, then processing can continue with step <b>530</b>.

In step <b>530</b>, it is determined that there was real congestion, i.e., this was not a duplicate acknowledgment message caused by retransmission attempts at the wireless link layer. Thus, in step <b>530</b>, the TCP message is permitted to pass through TCP adjunct <b>510</b>e without modification, and can continue through flow <b>500</b> to TCP layer <b>510</b>f of <figref idref="DRAWINGS">FIG. 5A</figref>.

In step <b>532</b>, since there was a duplicate acknowledgment detected in step <b>528</b>, it is determined whether the packet was successfully transmitted, or not. Step <b>532</b> is performed via intercommunication between TCP adjunct agent <b>510</b>e and PRIMMA MAC layer <b>504</b>d. This is an example of the interactivity between PRIMMA MAC and higher layer protocols illustrated as line <b>428</b> in <figref idref="DRAWINGS">FIG. 4</figref>. PRIMMA MAC layer <b>504</b>d can identify whether a packet was successfully sent from wireless base station <b>302</b> to CPE station <b>294</b>d since, as illustrated in <figref idref="DRAWINGS">FIG. 15B</figref>, requests for retransmission <b>1576</b> are received from CPE station <b>294</b>d at link layer acknowledgment (ARQ) processor <b>1578</b> to MAC downlink subframe scheduler <b>1566</b> alerting the scheduler <b>1566</b> to retransmit the lost packet in a future frame <b>1568</b>. If in step <b>532</b>, it is determined that the packet was successfully transmitted, then processing can continue with step <b>530</b>, as described above. If however it is determined that the packet was not successfully transmitted, then processing continues with step <b>534</b>.

In step <b>534</b>, since the packet was not successfully transmitted, TCP adjunct agent <b>510</b>e can suppress transmission of TCP message <b>524</b> since it can be assumed that the packet was lost in the wireless medium. Processing can continue with step <b>536</b>.

In step <b>536</b>, TCP adjunct agent <b>510</b>e can wait for notification from PRIMMA MAC <b>504</b>d that a successful link layer retransmission of the lost packet was received at link layer acknowledgment processor <b>1578</b>. From step <b>536</b>, processing can continue with step <b>538</b>.

In step <b>538</b>, upon receipt of acknowledgment of a successful PRIMMA MAC <b>504</b>d link layer retransmission, then normal TCP messages can be resumed.

In another step (not shown), TCP adjunct agent and PRIMMA MAC layers can set a limit of a threshold number of retransmission attempts, and if that threshold is reached, then processing can continue with step <b>530</b> to permit the TCP message to pass without modification.

<figref idref="DRAWINGS">FIG. 5C</figref> illustrates functional flow diagram <b>540</b> including an example functional description of TCP adjunct agent <b>510</b>e performing an incoming TCP spoof function. Referring to <figref idref="DRAWINGS">FIG. 15C and 5A</figref>, diagram <b>540</b> assumes that a TCP layer <b>510</b>a at a transmitting subscriber workstation <b>120</b>d has transmitted a windowful of packet data to host <b>136</b>a, and awaits acknowledgment. Diagram <b>544</b> illustrates receipt of an incoming TCP message <b>542</b> in TCP adjunct agent <b>510</b>e at wireless base station <b>302</b> which has been sent from host workstation <b>136</b>a via data network <b>142</b> for transmission over the wireless medium to subscriber CPE <b>294</b>d to subscriber workstation <b>120</b>d.

In step <b>544</b>, the TCP header contents of ingoing TCP message <b>542</b> is parsed in order to reveal the contents of the message being sent from host <b>136</b>a through the wireless network toward the transmitting subscriber workstation <b>120</b>d.

In step <b>546</b>, it is determined whether the TCP header contents includes a duplicate acknowledgment message from host <b>136</b>a. Receiving a duplicate acknowledgment request from the host could be indicative of a lost message in the wireless medium, or a real congestion problem. If in step <b>546</b> the TCP packet is determined to be a duplicate acknowledgment message, then processing can continue with step <b>550</b>, if not, then processing can continue with step <b>548</b>.

In step <b>548</b>, it is determined that there was real congestion, i.e., this was not a duplicate acknowledgment message caused by retransmission attempts at the wireless link layer. Thus, in step <b>548</b>, the TCP message is permitted to pass through TCP adjunct <b>510</b>e without modification, and can continue through flow <b>500</b> to TCP layer <b>510</b>a of <figref idref="DRAWINGS">FIG. 5A</figref>.

In step <b>550</b>, since there was a duplicate acknowledgment detected in step <b>546</b>, it can be determined whether the packet was successfully transmitted, or not. Step <b>550</b> can be performed via intercommunication between TCP adjunct agent <b>510</b>e and PRIMMA MAC layer <b>504</b>d. This is an example of the interactivity between PRIMMA MAC and higher layer protocols illustrated as line <b>428</b> in <figref idref="DRAWINGS">FIG. 4</figref>. PRIMMA MAC layer <b>504</b>d can identify whether a packet was successfully sent from CPE station <b>294</b>d to wireless base station <b>302</b>, as illustrated in <figref idref="DRAWINGS">FIG. 16B</figref>, requests for retransmission <b>1676</b> are received from CPE station <b>294</b>d at link layer acknowledgment (ARQ) processor <b>1678</b> to MAC downlink subframe scheduler <b>1666</b> alerting the scheduler <b>1666</b> to retransmit the lost packet in a future frame <b>1668</b>. If in step <b>550</b>, it is determined that the packet was successfully transmitted, then processing can continue with step <b>548</b>, as described above. If however it is determined that the packet was not successfully transmitted, then processing continues with step <b>552</b>.

In step <b>552</b>, since the packet was not successfully transmitted, TCP adjunct agent <b>510</b>e can suppress transmission of TCP message <b>542</b> since it can be assumed that the packet was lost in the wireless medium. Processing can continue with step <b>554</b>.

In step <b>554</b>, TCP adjunct agent <b>510</b>e can wait for notification from PRIMMA MAC <b>504</b>d that a successful link layer retransmission of the lost packet was received at link layer acknowledgment processor <b>1678</b>. From step <b>554</b>, processing can continue with step <b>556</b>.

In step <b>556</b>, upon receipt of acknowledgment of a successful PRIMMA MAC <b>504</b>d link layer retransmission, then normal TCP messages can be resumed.

In another step (not shown), TCP adjunct agent and PRIMMA MAC layers can set a limit of a threshold number of retransmission attempts, and if that threshold is reached, then processing can continue with step <b>548</b> to permit the TCP message to pass without modification.

5. Wireless QoS Aware PRIMMA Media Access Control (MAC) Hardware Architecture

<figref idref="DRAWINGS">FIG. 10</figref> illustratively depicts an embodiment of PRIMMA MAC hardware architecture <b>1000</b>. Architecture <b>1000</b> shows data network <b>142</b> coupled by a wireline bidirectional connection to WAN interface <b>320</b>.

WAN interface <b>320</b> is bidirectionally linked to a bidirectional data frame FIFO <b>1002</b> which is bidirectionally coupled to both segmentation and resequencing (SAR) <b>1004</b> and QoS/SLA rules engine and processor <b>1008</b>.

QoS/SLA rules engine and processor <b>1008</b> is also bidirectionally coupled to IP flow buffers <b>1014</b> and flash random access memory (RAM) <b>1010</b>.

SAR <b>1004</b> is bidirectionally coupled to IP flow buffers <b>1014</b>, flash RAM <b>1010</b>, QoS/SLA rules engine and processor <b>1008</b> and PRIMA MAC scheduler ASIC <b>1012</b>.

PRIMA MAC scheduler ASIC <b>1012</b> is also bidirectionally coupled to an RF interface <b>290</b>, a static RAM (SRAM) radio cell buffer <b>1018</b> and IP blow buffer <b>1014</b>.

6. Wireless Base Station Software Organization

<figref idref="DRAWINGS">FIG. 11</figref> is an exemplary software organization for a packet-centric wireless point to multi-point telecommunications system. The software organization of <figref idref="DRAWINGS">FIG. 11</figref> includes wireless transceiver and RF application specific integrated circuit (ASIC) module <b>290</b>, IP flow control component <b>1102</b>, WAN interface management component <b>1104</b>, QoS and SLA administration component <b>1106</b>, system and OAM&amp;P component <b>1108</b>, customer billing and logging component <b>1110</b>, directory enabled networking (DEN) component <b>1112</b>, and wireless base station <b>320</b>.

IP flow control module <b>1102</b> includes transmission queuing control module <b>1102</b>a, TCP rate control and class of service module <b>1102</b>b, wireless PRIMMA MAC layer engine <b>1102</b>c and IP flow identification and analysis module <b>1102</b>d.

WAN interface management component <b>1104</b> includes WAN ingress/egress queuing control module <b>1104</b>a, WAN interface ports (e.g., for T1, T3, OC3 ports) <b>1104</b>b, firewall and security module <b>1104</b>c, and WAN traffic shaping module <b>1104</b>d.

The IP Flow control component <b>1102</b> and WAN interface management component <b>1104</b> represent the “core” of the system, where the packet processing, MAC layer scheduling, TCP proxy agent, and WAN I/F control functions are located. Much of the activities of the “non-core” components described above support and control these core components.

QoS and SLA administration component <b>1106</b> includes includes QoS performance monitoring and control module <b>1106</b>a, service level agreements module <b>1106</b>b, policy manager module <b>1106</b>c and encryption administration module <b>1106</b>d.

The QoS and SLA administration component <b>1106</b> provides the static data needed by the system in order to properly group particular IP-flows into QoS classes. Typically, during the provisioning phase of installing the system, the service provider will (remotely) download pertinent information about the subscriber CPE station <b>294</b>, including the subscriber CPE stations's SLA, any policy-based information (such as hours of operation or peak data transmission rate allowance.). Encryption keys or “strengths” can also be downloaded, which may be subscriber CPE station or service provider specific.

System OAM&amp;P component <b>1108</b> includes SNMP proxy client for WAP module <b>1108</b>a, SNMP proxy clients for CPE module <b>1108</b>b, and system operations, administration, management and provisioning module <b>1108</b>c.

The OAM&amp;P component <b>1108</b> allows remote service personnel and equipment to monitor, control, service, modify and repair the system. System performance levels can be automatically monitored, and system traps and traces can be set. Subscriber complaints can be addressed with the use of remote test and debug services controlled by OAM&amp;P component <b>1108</b>. System capacity limits can be monitored, and proactive provisioning of additional WAN connectivity can occur, as the result of automatic trend analysis functions in OAM&amp;P component <b>1108</b>.

Customer billing and logging module <b>1110</b> includes account logging and database management module <b>1110</b>a, transaction query and processing control module <b>1110</b>b, billing and account control module <b>111</b>c, and user authentication module <b>1110</b>d.

The customer billing and logging component <b>1110</b> allows the service provider to receive account, billing and transaction information pertaining to subscribers in the system. For service providers who bill on the basis of usage, cumulative system resource utilization data can be gathered. For specific types of activities (eg. video conferencing, multi-casting, etc.) there may be special billing data that is collected and transmitted to the service provider. This component also controls the availability of the system to subscribers through the operation of the subscriber authentication function. Once a subscriber is authorized to use the system, a new subscriber authentication entry is made (remotely) by the service provider. Likewise, a subscriber can be denied further access to the system for delinquent payment for services, or for other reasons. The service provider can also remotely query the system for specific account-related transactions.

Directory Enabled Networking (DEN) component <b>1112</b> includes DEN QoS <b>1112</b>a module, DEN management and provisioning <b>1112</b>b module, DEN IPSEC module <b>1112</b>c and IP-based VPN control and administration module <b>1112</b>d.

The DEN component <b>1112</b> allows the service provider the means to input into the system relevant information regarding the operation of DEN-based VPN's of subscribers. Subscriber VPNs need to be “initialized” and “provisioned” so that the system properly allocates system resources to subscribers with these VPNs, and provides for the recognition and operation of these VPNs. Data from DEN component <b>1112</b> are utilized by the system to apply the appropriate priorities to IP-flows of the subject subscribers.

The invention's packet-centric wireless base station supports directory enabled networking (DEN), a MICROSOFT, INTEL and CISCO standard for providing a standard structure for how distributed sites manage IP flows. The present invention prioritizes VPN traffic in a lightweight directory access protocol (LDAP)-compliant (LDAP is available from MICROSOFT of Redmond, Wash.) manner which allows remote administration, provisioning and management. The present invention is also LDAP version 2 compliant. The present invention also complies with the X.500 standard promulgated by the international telecommunications union/telecommunications section (ITU/T), and with the RFC 1777.

In one embodiment, DEN provides policy-based network management, IPsec compatible network security, and IPsec based VPNs. The DEN of the wireless base station <b>302</b> is planned to be common information model (CIM) 3.0 compatible (once the specification is finalized). The wireless base station <b>302</b> can provide native DEN support and supports directory based DEN QoS mechanisms including reservation model (i.e. RSVP, per-flow queuing), and precedence/priority/differentiated model (i.e. packet marking). Wireless base station <b>302</b> can plan support of DEN network policy QoS, and until DEN is complete, can support internal QoS and network extensions.

6. IPsec Support

IPsec is introduced above with reference to <figref idref="DRAWINGS">FIG. 4</figref>. IPsec provides a standard method of encrypting packets. In VPN tunnel mode, an entire header can be encoded, i.e. encrypted. In order for the present invention to be able to implement its packet-centric, QoS aware prioritization, during identification of a packet/IP flow, the wireless base station needs to be able to analyze the contents of header fields of the packets. Therefore, analysis of unencrypted packets is desirable.

The present invention already encrypts the data stream prior to transmitting frames over the wireless medium, so IPsec does not really need to be used over the wireless link to provide for encrypted transmission. Where a service provider finds it desirable to use IPsec, IPsec can be used for authentication and secure encapsulation of the header and payload, or just the payload data. IPsec is normally integrated at a firewall. If a service provider desires to implement the present invention and IPsec, then the present invention should be implemented behind the firewall, i.e. the firewall can be moved to the wireless base station. This permits ending the IPsec stream at the base station which can provide the base station access to packet header fields.

<figref idref="DRAWINGS">FIG. 17</figref> illustrates IP flow in the downlink direction including IPsec encryption. Similarly, <figref idref="DRAWINGS">FIG. 18</figref> illustratively depicts an uplink direction of IPsec support of the present invention.

<figref idref="DRAWINGS">FIG. 17</figref> illustrates downlink flow <b>1700</b> depicting downlink direction IP flows from a source host workstation <b>136</b>a, down a protocol stack which supports IPsec, for transmission up and through wireless base station <b>302</b> which is coupled to data network <b>142</b>, through encryption layers, then through the wireless link to subscriber CPE <b>294</b>d, up and through a protocol stack at the subscriber CPE <b>294</b>d, then through a wireline connection to data network <b>142</b> and up through the protocol stack to the destination subscriber workstation <b>120</b>d at subscriber location <b>306</b>d.

Specifically, flow <b>1700</b> illustrates IP packet flow from host workstation <b>136</b>a, through wireless base station <b>302</b>, then over a wireless transmission link to subscriber CPE <b>294</b>d, and over a wireline link to subscriber workstation <b>120</b>d.

Host workstation <b>136</b>a flows IP flows down from application layer <b>1712</b>h, down through TCP/UDP layer <b>1705</b>h, through IP layer <b>1708</b>h, through optional PPP layer <b>1706</b>h, through Ethernet layer <b>1705</b>h, down through 10BaseT layer <b>1702</b>h, over data network <b>142</b> to 10BaseT layer <b>1702</b>g, then up through Ethernet <b>1704</b>g, up its protocol stack through optional PPP layer <b>1706</b>g to IP layer <b>1708</b>g and <b>1708</b>h, back down through Internet firewall and IPsec security gateway <b>1706</b>f, down through WAN layer <b>1704</b>f, to wireline layer <b>1702</b>f to data network <b>142</b> to wireline physical layer <b>1702</b>e.

Wireline physical layer <b>1702</b>e of wireless base station <b>302</b>, flows IP flows up the protocol stack through WAN layer <b>1704</b>e through IPsec security gateway <b>1706</b>e and firewall to IP network layer <b>1708</b>e and <b>1708</b>d and then down through encryption layer <b>1706</b>d, PRIMMA MAC layer <b>1704</b>d and down to wireless link to subscriber CPE <b>294</b>d.

Subscriber CPE <b>294</b>d flows packet IP flows up from antenna <b>292</b>d at physical wireless layer <b>1702</b>c up through MAC layer <b>1704</b>c, through encryption layer <b>1706</b>c, through IP layers <b>1708</b>b and <b>1708</b>c, then down through optional layer <b>1706</b>b to Ethernet layer <b>1704</b>b to 10BaseT connection <b>1702</b>b to 10BaseT connection.

Subscriber workstation <b>120</b>d flows IP flows up from 10BaseT layer <b>1702</b>a up through its protocol stack through Ethernet layer <b>1704</b>a, through optional PPP layer <b>1706</b>a, through IP layer <b>1708</b>a, to TCP/UDP layer <b>1710</b>a and on up to application layer <b>1712</b>a.

<figref idref="DRAWINGS">FIG. 18</figref> illustrates uplink flow <b>1800</b> depicting uplink direction IP flows from a source TCP at subscriber workstation <b>120</b>d at CPE location <b>306</b>d, down a protocol stack for transmission through Ethernet coupled CPE subscriber station <b>294</b>d through wireless medium to wireless base station <b>302</b>, up and through a protocol stack at the wireless base station <b>302</b> which supports IPsec, then through a wireline connection to data network <b>142</b> and through a protocol stack to a destination host.

Specifically, flow <b>1800</b> illustrates IP packet flow from subscriber workstation <b>120</b>d, through subscriber CPE <b>294</b>d, then over a wireless transmission medium to wireless base station <b>302</b>, and eventually over a wireline link to host workstation <b>136</b>a.

Flow <b>1800</b> includes IP flows from application layer <b>1812</b>a, down the protocol stack through TCP/UDP layer <b>1810</b>a, through IP layer <b>1808</b>a, then through optional point-to-point (PPP) layer <b>1806</b>a, then through data link Ethernet layer <b>1804</b>a, then through 10BaseT Ethernet network interface card (NIC) physical layer <b>1802</b>a, over a wire line connection to 10BaseT Ethernet NIC physical layer <b>1802</b>b of subscriber CPE <b>294</b>d.

Subscriber CPE <b>294</b>d flows packets coming in from NIC <b>1802</b>b, back up its protocol stack through Ethernet layer <b>1804</b>b, through optional PPP layer <b>1806</b>b to IP layer <b>1808</b>b and <b>1808</b>c, back down through an Internet firewall and IPsec security gateway <b>1806</b>c, down through PRIMMA MAC <b>1804</b>c to wireless physical layer <b>1802</b>c including antenna <b>292</b>d, then over the wireless medium, such as, e.g., RF communication, cable RE, and satellite link, to antenna <b>290</b>d of wireless base station <b>302</b> at wireless physical layer <b>1802</b>d.

Wireless base station <b>302</b> flows packet IP flows up from antenna <b>290</b>d at physical wireless layer <b>1802</b>d up through MAC layer <b>1804</b>d, through IPsec layers <b>1806</b>d and <b>1806</b>d, which can encapsulate packets and encrypt them. From IPsec layer <b>1806</b>e, IP flows can flow down through WAN layer <b>1804</b>e and through wireline physical layer <b>1802</b>e over data network <b>142</b>.

Wireline physical layer <b>1802</b>f flows IP flows up the protocol stack through WAN layer <b>1804</b>f through IPsec security gateway <b>1806</b>f and firewall to IP network layer <b>1808</b>f and <b>1808</b>g and then down through optional PPP layer <b>1806</b>h, Ethernet layer <b>1804</b>h and down through 10BaseT layer <b>1802</b>g, through interface <b>320</b>, over routers <b>140</b>d, through data network <b>142</b>, via wireline connections to 10BaseT physical layer <b>1802</b>h of host workstation <b>136</b>a.

Host workstation <b>136</b>a flows IP flows up from 10BaseT layer <b>1802</b>h up through its protocol stack through Ethernet layer <b>1805</b>h, through optional PPP layer <b>1806</b>h, through IP layer <b>1808</b>h, to TCP/UDP layer <b>1810</b>h and on to application layer <b>1812</b>h.

IV. Conclusion

While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.