Method, apparatus, and system for medium access control

[0001]

This patent priority:

Patent Application The following US patent claims

Application No. US-20030511750 entitled "Method and Apparatus for Providing Interoperability and Backward Compatibility in Wireless Communication Systems" filed October 15, 2003;

Application No. US-20030511904 entitled "Method,

Apparatus, and System for Medium Access Control in a High Performance Wireless LAN Environment "filed October 15, 2003;

Application No. US-20030513239 entitled "Peer-to-Peer Connections in MIMO WLAN System" filed October 21, 2003;

Application No. US-20030526347 entitled "Method,

Apparatus, and System for Sub-Network Protocol Stack for Very High Speed ​​Wireless LAN "filed December 1, 2003;

Application No. US-20030526356 entitled "Method,

Apparatus, and System for Multiplexing Protocol data Units in a High Performance Wireless LAN Environment "filed December 1, 2003;

Application No. US-20030532791 entitled "Wireless Communications Medium Access Control (MAC) Enhancements" filed December 23, 2003;

Application No. US-20040545963 entitled "Adaptive Coordination Function (ACF)" filed February 18, 2004; Application No. US-20040576545 entitled "Method and Apparatus for Robust Wireless Network" filed June 2, 2004;

53 / 59P25695PL00

Application No. US-20040586841 entitled "Method and Apparatus for Distribution Communication Resources Among Multiple Users" filed July 8, 2004; and

Application No. US-20040600960 entitled "Method,

Apparatus, and System for Wireless Communications "filed August 11, 2004; all assigned to the assignee of this document.

BACKGROUND OF THE INVENTION

Field of the Invention [0002] The present invention relates generally to communication, and in particular to the wireless LAN protocol stack.

Background of the Invention provides a greater number of different [0003] Wireless communication systems are widely used to provide various types of communication such as voice communication and data communication. A typical wireless data system, or network, provides users with access to one or shared resources. The system can use multi-access techniques such as frequency division multiplication (FDM), time division multiplication (TDM), code division multiplication (CDM) and others. [0004] Exemplary wireless networks include cellular data systems. A few such examples are the following systems: (1) "TIA / EIA-95-B Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum

Cellular System "(IS-95 standard

2) the standard proposed by the consortium called the "3rd Generation Partnership Project"

3GPP) contained in a set of documents including documents No. 3G TS 25.211, 3G TS 25.212, 3G TS 25.213

3G TS 25.214

(B) or (g)). achieved by (W-CDMA standard), (3) standard proposed by a consortium called "3rd Generation Partnership Project 2" (3GPP2) and included in "TR-45.5 Physical Layer Standard for cdma2000 Spread Spectrum Systems" (IS-2000 standard) and (4) high speed data transfer (HDR) system that is compliant with the standard

TIA / EIA / IS-856 (IS-856 standard).

[0005] Other examples of wireless systems include wireless local area networks (WLAN) such as IEEE 802.11 standards (i.e., 802.11 (a),

Improvements in these networks can be the use of WLAN using multi-antenna transmission on the transmitting and receiving side (MIMO: Multiple Input Multiple Output), using orthogonal frequency division multiplication (OFDM) techniques.

[0006] As wireless system designs evolved, faster data transmissions have become achievable. Faster data transmissions have opened up the possibilities of advanced applications, including voice, video, fast data transfer and various other applications. However, different applications may have different requirements for their respective data transfers. Many types of data may have requirements related to delay and bandwidth, or require a guaranteed Quality of Service (QoS). Without resource management, system bandwidth can be reduced and the system may not work efficiently.

[0007] Media Access Control (MAC) protocols are commonly used to allocate shared communication resources among a number of users. MACs usually combine higher layers with the physical layers used to transmit and receive data. To take advantage of the increase in data transfer speed, the MAC protocol must be designed to efficiently use shared resources.

[0008] Such a system is described in EP-A-1 317 110 regarding a base station for a point-to-point LMDS system describing an interlayer framer component comprising a serial combination of a queuing module and a framing module.

[0009] The high performance systems that are being developed support many transmission rates that can vary widely based on physical link characteristics. Given the changing requirements of different types of data applications and the large discrepancy of supported data transmission rates to different user terminals located in the system, improvements must also be made on how to queue different types of traffic and how to transmit them through typically different physical links. There is therefore a need in the art for MAC processing for efficient use of high throughput systems.

SUMMARY OF THE INVENTION [0010] Embodiments presented herein respond to the need for MAC processing in the prior art for efficient use of high throughput systems. In one aspect, the device includes a first layer for receiving one or more packets in one or more data flows and for generating one or more protocol data units (PDUs) from one or more packets. In another aspect, a second layer is used to generate one or more MAC frames based on the one or more MAC layer PDUs. In another aspect, a MAC frame is used to transmit one or more MAC layer PDUs. The MAC frame may include a control channel for transmitting one or more assignments. Frame

53 / 59P25695PL00

In accordance with [0011] an efficient implementation, the MAC may comprise one or more assignment traffic segments.

Other aspects and examples are also presented. These aspects have the advantage of providing media access control and are preferably with physical layers including fast data as well as slow data transmissions.

BRIEF DESCRIPTION OF THE DRAWINGS [0012] FIG. 1 depicts an example embodiment of a system comprising a fast WLAN;

[0013] FIG. 2 depicts an example embodiment of a wireless communication device that can be configured as an access point or user terminal; [0014] FIG. 3 depicts an example subnet protocol stack;

[0015] FIG. 4 illustrates a user data packet as it traverses the layers of the protocol stack;

[0016] FIG. 5 illustrates an example MAC frame;

[0017] FIG. 6 depicts an example method of performing downlink message transfer;

[0018] FIG. 7 depicts an example method of receiving a forward link message transfer;

[0019] FIG. 8 depicts an example method of performing a reverse link message transfer;

[0020] FIG. 9 depicts an example method of receiving a reverse link message transfer;

[0021] FIG. 10 depicts an example method of performing initial access and registration at a UT user terminal; [0022] FIG. 11 depicts an example method of performing initial access and registering with an AP; [0023] FIG. 12 depicts an example method 1200 for user data flow at an AP;

[0024] FIG. 13 depicts an example method 1300 for user data flow at the UT;

[0025] FIG. 14 depicts an example method of introducing physical layer feedback into the function of an adaptation layer;

[0026] FIG. 15 depicts an example method of performing adaptation layer multicast; [0027] FIG. 16 illustrates an example method of determining whether to use adaptive layer multicasting or MAC layer multicasting;

[0028] FIG. 17 illustrates an example method of performing segmentation in response to physical layer feedback;

[0029] FIG. 18 illustrates segmentation in response to a transmission rate;

[0030] FIG. 19 depicts an example method of transmitting multiple flows and commands in a single MAC frame;

[0031] FIG. 20 illustrates sequential MAC frames, including examples of transmitting various partial MUX PDUs;

[0032] FIG. 21 illustrates an example method of preparing a MAC frame using the MUX indicator;

[0033] FIG. 22 illustrates an example method of receiving a MAC frame including a MUX indicator;

[0034] FIG. 23 illustrates an example of MUX PDU formats;

[0035] FIG. 24 illustrates an example system configured for Ethernet adaptation;

[0036] FIG. 25 illustrates an example system configured for IP adaptation.

[0037] FIG. 26 illustrates example protocol stacks for Ethernet networks; and [0038] FIG. 27 illustrates sample IP protocol stacks.

53 / 59P25695PL00

DETAILED DESCRIPTION [0039] In performance protocols, this description describes a stack of subnets that supports high low latency and high bandwidth operation in conjunction with very high bit rate physical layers in a wireless WLAN (or similar applications that use emerging transmission technologies). The sample WLAN network supports data rates over 100 Mbps (million bits per second) in 20 MHz bandwidths.

[0040] Along with the protocol stack, a method of multiplexing protocol data units (PDUs) from multiple user data streams and subnet control units (MUX PDUs) into one byte stream is described. The byte stream is formatted to MAC data units (MAC PDU), each of which can be transmitted in a sequence that is contained in a single MAC frame. It can support a high performance wireless LAN subnet for high performance, low latency and high bandwidth combined with very high bit rate physical layers.

[0041] The subnet protocol stack generally supports physical layer transport mechanisms with high bandwidth and high bit rate, including, but not limited to, mechanisms based on OFDM modulation, single carrier modulation techniques, multiple transmit antenna and multiple receive antenna systems (systems MIMO, including systems using multiple transmitting antennas and one receiving antenna (MISO)) for efficient operation in very large bandwidth, systems using multiple transmit and receive antennas in combination with spatial multiplexing techniques to transmit data to or from multiple user terminals during the same

The time interval and systems employing code division multiple access (CDMA) techniques to allow simultaneous transmission to multiple users.

[0042] One or more of the exemplary embodiments described herein is explained in the context of wireless data communication systems. While the use of this context is preferred, various embodiments of the present invention may be implemented in various environments or configurations. Basically, the various systems described herein can be created using software controlled processors, integrated circuits, or discrete logic. The data, instructions, commands, information, signals, chips that can be referred to in the application are symbols and preferably represented by electromagnetic, voltage particles, or current fields, magnetic waves, particles or optical fields or a combination thereof. In addition, the blocks shown in each block diagram may represent equipment or method steps. The method steps can be exchanged without departing from the scope of the present invention. The word "exemplary" is used herein to mean "serving as an example, example, or illustration." Any embodiment described herein as "exemplary" need not necessarily be understood as being preferred or preferred over other embodiments.

[0043] FIG. 1 depicts an example embodiment of a system 100 comprising an Access Point (AP) 104 connected to one or more User Terminals (UT) 106 AN. The AP and UT terminals communicate over a Local Wireless Computer Network (WLAN) 120. In an exemplary embodiment, the WLAN 120 is a high speed MIMO OFDM system. However, the WLAN 120 can be any wireless LAN. Access point 104 communicates with any number of external devices or processes via network 102. Network 102 can be the Internet,

53 / 59P25695EN00 intranet, or any other wired, wireless or optical network. Connection 110 carries physical layer signals from the network to the access point 104. The devices or processes can be connected to the network 102 or as UT terminals (or through connections to them) in the WLAN 120. Examples of devices that can be connected to either network 102 or WLAN 120 include telephones, Personal Digital Assistants (PDAs), various types of computers (laptops, personal computers, workstations, any type of terminals), video devices such as cameras, digital cameras, webcams, and virtually any other type of data processing device. Processes can include voice, video, data, etc. communication Different data streams may have different transmission requirements that can be customized by using different Quality of Service (QoS) techniques.

[0044] System 100 is deployed with a centralized AP 104. In an exemplary embodiment, all UT 106 communicates with the AP. In an alternative embodiment, direct peer-to-peer communication between two UT terminals can be adapted, with system modifications that will be apparent to those skilled in the art. For clarity of discussion, in the exemplary embodiment, access to the physical layer transport mechanism is controlled by the AP.

[0045] In one embodiment, the AP 104 provides Ethernet adaptation, an example of which is shown in FIG. 24. In this case, an AP 2410 router can be used with the AP 104 to provide a connection (via Ethernet connection 110) to network 102. Illustrative examples of UT 106 terminals are provided, e.g. 106A mobile phone, 106B Personal Assistant (PDA) 106B, 106C laptop, 106D workstation, 106E personal computer, 106F digital video camera, and video projector

53 / 59P25695PL00

106G. Ethernet frames can be sent between the router and UT 106 terminals in the WLAN 120 subnet (described in detail below).

[0046] Adaptation of Ethernet and its connectivity are well known in the art. FIG. 26 shows stacks of 2640 and 2650 Ethernet adaptation protocols for the exemplary UT 106 terminal and AP 104 access point respectively, as integrated with the exemplary layers, which will be described in detail in the following. The 2640 UT protocol stack includes 2610 higher layers, 2615 IP layer, 2620A Ethernet MAC layer, 310A adaptation layer, 320A data link layer, and 240A physical layer (PHY). The AP stack of 2,650 protocols includes a PHY layer 240B (connected to the PHY layer 240A of the UT via RF link 120), a data link layer 320B, and an adaptation layer 310B. The Ethernet MAC 2620B layer connects the 310B adaptation layer to the PHY 2625 Ethernet layer, which is connected 110 to wired network 102.

[0047] In an alternative embodiment, the AP 104 provides IP Adaptation, an example of which is illustrated in FIG. 25. In this case, the AP 104 acts as a gateway router for the set of connected UTs (as described with reference to FIG. 24). In this case, IP datagrams can be routed through the AP 104 to and from the terminals

UT 106.

[0048] IP adaptation and connectivity are well known in the art. FIG. 27 illustrates the stacks of 2740 and 2750 IP adaptation protocols for the exemplary UT 106 terminal and AP 104 access point, respectively, as integrated with the exemplary layers, which will be described in detail in the following. The 2740 UT protocol stack includes 2710 higher layers, 2720A IP layer, 310A adaptation layer, data link layer 320A, and 240A physical layer (PHY).

53 / 59P25695PL00

The AP stack of 2,750 protocols includes a PHY 240B layer (connected to the PHY 240A layer of the UT via an RF link

120) data link layer 320B, adaptation layer 310B.

The IP 2720B layer connects the adaptation layer 310B to the Ethernet MAC 2725 layer, which is connected to the Ethernet PHY 2730 layer. The Ethernet PHY 2730 layer is connected 110 to wired network 102.

[0049] FIG. 2 shows an exemplary embodiment of a wireless communication device that can be configured as access point 104 or user terminal 106. The configuration of access point 104 is shown in FIG. 2. The transceiver 210 receives and transmits in connection 110 as required by the physical layer of network 102. Data from or to devices or applications connected to network 102 is provided to the MAC processor 220. This data is referred to as flows 260. Flows may have different characteristics and may require different processing based on the type of application associated with the flow. For example, video or characterized as voice flows may be a small delay (generally video has higher bandwidth requirements than voice). Many data applications are less sensitive to delay, but may have higher data integrity requirements (i.e. voice may be resistant to some packet loss, file transfer is generally not resistant to packet loss).

[0050] The MAC processor 220 receives flows 260 and processes them for transmission on the physical layer. The MAC processor 220 also receives physical layer data and processes the data to form packets for outgoing flows 260. Internal control and signaling are also transferred between APs and UT terminals. MAC protocol data units (MAC PDUs) are delivered to and received from the transceiver 240 of the wireless network

LAN in

53 / 59P25695PL00

Physical layer feedback, combined 270. Conversion from flows and commands to MAC PDUs, and vice versa, is described in detail below. Feedback 280 corresponding to different MAC IDs is returned from the physical layer (PHY) 240 to the MAC 220 processor for various purposes, described in detail in the following. 280 it may contain any information including the transfer rates supported by the channels (including both multicast and unicast channels), modulation format and various other parameters.

[0051] In an exemplary embodiment, the adaptive layer (ADAP) and Data Link Control (DLC) layer are implemented in a MAC 220 processor. The physical layer (PHY) is implemented in a wireless LAN transceiver 240. Those skilled in the art will recognize that segmentation of the various functions can be performed in any of the various configurations. The MAC 220 may perform partial or full processing for the physical layer. The wireless LAN transceiver may include a processor for performing MAC processing, or its subpart. Any number of processors, special purpose equipment or a combination of these can be used.

[0052] The MAC 220 may be a general purpose microprocessor, a digital signal processor (DSP) or a special purpose processor. The MAC 220 processor can be combined with special purpose equipment to support various tasks (details not shown). Various applications may be run on externally connected processors, such as externally connected computers, or, using a network connection, may be run on additional processors at the access point 104 (not shown), or may be run on the MAC 220 processor itself. MAC processor shown 220 is connected to memory 255, which can be used to store data as well as instructions for performing the various procedures described herein

53 and 59P25695EN00 and methods. It will be appreciated by those skilled in the art that memory 255 may consist of one or more memory components of various types, which may be fully or partially embedded in the MAC 220 processor.

[0053] In addition to storing instructions and data to perform the functions described herein, memory 255 can also be used to store data associated with various queues (described in detail below). Memory 255 may contain UT proxy queues (described below).

[0054] The wireless LAN transceiver 240 may be any type of transceiver. In an exemplary embodiment, the wireless LAN transceiver 240 is an OFDM transceiver that can be operated via the MIMO or MISO interface. OFDM, MIMO and MISO systems are known to those skilled in the art. Various examples of OFDM, MIMO and MISO transceivers are described in detail in U.S. Patent Application, pending, No. 10 / 650,295, entitled "FREQUENCY-INDEPENDENT SPATIALPROCESSING FOR WIDEBAND MISO AND MIMO SYSTEMS" ("Frequency-independent spatial processing for broadband MISO systems" MIMO "), filed on August 27, 2003, assigned to the assignee of the present invention.

[0055] The illustrated wireless LAN transceiver 240 is connected to 250 AN antennas. In various embodiments, any number of antennas may be supported. Antennas 250 are used to transmit and receive in the WLAN 120.

[0056] The wireless LAN transceiver 240 may include a spatial processor connected to one or more of the antennas 250. The spatial processor may process data for transmission independently for each antenna. Examples of independent processing can be based on channel estimates, UT feedback,

Bandwidth from the Time Inversion channel system or various other techniques known in the art. Processing is performed using various spatial processing techniques. Various transceivers of this type can use beam forming, beam control, proprietary control or other spatial techniques to increase throughput to and from a given user terminal. In the exemplary embodiment in which OFDM symbols are transmitted, the spatial processor may include subspace processors for processing each of the OFDM subchannels or ranges.

[0057] In the exemplary system, the AP may have N antennas and the exemplary UT may have M antennas. There are therefore M x N paths between the AP and UT antennas. Various spatial techniques are known in the art for increasing the use of these many paths. IN

Space Time Transmit Diversity (STTD) (also called "diversification"), transmission data is formatted, encoded and sent by all antennas as a single data stream. MIN (M, N) independent channels can be created for M transmit antennas and N receive antennas. Spatial multiplexing uses these independent paths and can transmit different data on each of the independent paths to increase the transmission speed.

[0058] Various techniques are known for learning or adapting to the channel characteristics between an AP and a UT. Unique pilot signals can be transmitted from each transmit antenna. Pilot signals are received by each receiving antenna and measured. The channel feedback may then be returned to the transmitting device for use in transmission. One technique is channel inversion, including pre-processing and transmission, although it may be computationally intensive. May be

In-house decomposition has been performed, and a lookup table may be used to determine the baud rate. An alternative technique to avoid channel decomposition is to use your own pilot control to simplify spatial processing. Techniques for introducing non-linearity compensation (predistortion) are also known to simplify processing at the receiver.

[0059] Thus, depending on the current channel conditions, changing transmission rates may be available for transmission to various user terminals throughout the system. In particular, a particular link between an AP and each UT may have greater performance than a link that can be shared by more than one UT. Examples of this are discussed in detail later. The wireless LAN transceiver 240 may determine the supported baud rate based on any spatial processing used for the physical link between the AP and the UT. This information can be returned in connection 280 for use in MAC processing, described in detail below.

[0060] The number of antennas that can be used depends on the UT data requirements. For example, a high-definition video display can contain, for example, four antennas, due to its high bandwidth requirements, while a PDA device has two antennas. An example access point may have four antennas.

[0061] User terminal 106 may be used in a similar manner to access point 104 shown in FIG.

2. Basically, flows 260 are received from or delivered to one or more applications or processes running in a UT terminal or device connected to it, and not connected to a LAN transceiver (though

The UT terminal may include such a wired or wireless transceiver). Higher levels connected to either AP 104 or UT 106 may be of any type. illustrative.

The layers described here are only of a nature

Protocol Stack [0062] FIG. 3 depicts an example stack of 300 subnet protocols. A stack of 300 subnet protocols can serve as an interface between the physical layer of a very high-speed wireless LAN and the network layer or the MAC layer of some other network, such as the Ethernet MAC layer or the TCP / IP network layer. Various features of the 300 protocol stack can be used to take full advantage of the very high performance wireless LAN physical layer.

An example stack of protocols can be designed to provide various benefits, examples include minimizing bandwidth, maximizing the size of the output (overhead) protocol;

units to (a) for (b) given subnets to layer frames minimizing overhead by physical packing; (c) the contribution of latency to round-trip signal delay from end to end for delay sensitive transport mechanisms such as TCP; (d) ensuring, subsequently, highly reliable delivery of subnet data units; (e) providing support for existing network layers and applications and sufficient flexibility to adapt future networks and applications; and (f) transparent integration into existing network technologies.

[0063] The stack of 300 protocols has several thin sublayers, several modes of operation, and facilitates the use of interfaces to many external networks. FIG. 3 shows the layer

FIG.

presents

53 / 59P25695PL00

MAC (for adaptation of larger adaptive network layers 310, data link control layer 320, and physical layer 240. The 380 layer manager connects to each sublayer to provide communication and control for various functions, discussed in detail below.

[0064] In FIG. 3 an example configuration of a stack of 300 protocols is shown. The dashed line indicates an example component configuration that can be used in the MAC 220 processor as described above. Adaptation layer 310, data link control layer 320 and 380 layer manager are included. In this configuration, the physical layer 240, as described above, receives and transmits MAC Protocol Data Units (PDUs) on connection 270. Reverse connection 280 is directed to the 380 layer manager to provide physical layer information for use in the various functions described in detail below. The example is illustrative only. Those skilled in the art will recognize that any number of components configured to include any combination of stack functions described can be used within the scope of the present invention.

[0065] The adaptation layer 310 provides an interface to higher layers. For example, the adaptation layer can be an interface with an IP stack (for IP adaptation), an Ethernet layer of Ethernet) or with various other Flows 260 are received from one or more higher layers for MAC processing and transmission at the physical layer 240. Flows 260 are also received via a physical layer, processed and reassembled to be delivered to one or more higher layers.

[0066] The adaptation layer 310 has the following functions: segmentation and reassembly 312, flow classification 314, multicast mapping 316. Flow classification function 314 examines header packets received from higher layers (from one or more flows)

53 / 59P25695PL00

260) maps each packet to the user terminal or MAC ID of the multicast group and classifies the packets for appropriate Quality of Service (QoS) processing. The multicast mapping function 316 determines whether the multicast user data is to be transported using the multicast MAC ID (called "MAC layer multicast") or via multiple unicast MAC IDs (called "adaptive layer multicast"), examples of which are described in detail below. The 312 Segmentation and Reassembly (SAR) function adapts each higher layer packet to the Protocol Data Unit (PDU) size appropriate for the Link mode

Logical (LL). The SAR 312 function is implemented separately for each MAC ID. Flow classification function 314 is common.

[0067] The data link control layer 320 includes a layer

330 Logical Link (LL layer 340 Link Control

Radio (RLC), system configuration control 350, MUX 360 function, and MAC 370 joint function. In FIG. 3 different sub-blocks are shown for each of these layers and will be described below in character.

The blocks shown are for illustrative purposes only. Subsets of these functions, as well as additional functions, may be used in various alternative embodiments.

[0068] The physical layer 240 may be any type of physical layer, examples of which are described in detail above. The exemplary embodiment uses the MIMO OFDM physical layer. Exemplary parameters of this embodiment are included in the description below.

[0069] Layer Manager (LM) 380 provides an interface to adaptation layer 310, data link control layer 320 and physical layer 240 to manage QoS quality, admission control and

Controlling parameters of the physical layer transmitter and receiver. It should be noted that feedback from the physical layer 280 can be used to perform the various functions described herein. For example, supported transmission rates for different UTs may be used in multicast mapping or segmentation 316 and reassembly 312.

Adaptation Layer [0070] The Flow Classification Function (FLCL) 314 examines the packet header fields for incoming packets to map them to flows. In the exemplary embodiment in which IP adaptation is performed, the following fields can be used for flow classification: (a) source and destination IP addresses; (b) source and destination IP ports; (c) IP Service Differentiation Code Point (DSCP); news of the Resource Reservation Protocol (RSVP); and (e) Real Time Transmission Control Protocol (RTCP) messages and Real Time Transmission Protocol (RTP) headers. In alternative embodiments where Ethernet adaptation is performed, the flow classification may use 802.1p and 802.1q header fields. It is also possible to use IP flow classification for Ethernet adaptation, although this would be a layer violation. Skilled artisans will recognize various other types of flow classifications that may alternatively be used.

[0071] The FLCL 314 function determines whether the identified flow 260 maps to an existing MAC ID, Logical Link (LL) mode, and stream ID (described in detail below). If the incoming packet maps the existing flow, the FLCL function forwards the packet for further processing to function 312

53 / 59P25695PL00

Segmentation and Reassembly (SAR). If a new MAC ID is required, the request is forwarded to the link control function 344 in Radio Link Control (RLC) 340.

[0072] If a new flow is identified for an existing MAC ID, the QoS Manager function 382 in the layer manager 380 determines the type of logical link mode required for the flow. If a new LL mode is to be initialized, the request is forwarded to the LLC 338 function corresponding to the MAC ID to support negotiation mode. If a new stream is to be established in the existing LL mode, the request is forwarded to the LLC 338 function. One embodiment for maintaining QoS queues is described in detail in US Patent Application No. 10 / 723,346, in parallel, titled "QUALITY OF SERVICE SCHEDULER FOR A WIRELESS NETWORK".

WIRELESS), submitted on November 26, 2003, assigned to the assignee of this document.

[0073] In examples of IP multicast or Ethernet broadcasts, the multicast mapping function 316 determines whether the packet is to be served using MAC layer multicasting by mapping to a multicast MAC ID, or whether the packet is to be served as multiple send transmissions. unit, here referred to as "Adaptive Layer Group Broadcasting". In the second case, the multicast mapping function 316 creates multiple copies of the packet, one for each MAC unicast ID to be transmitted to and forwards the packets to the Segmentation and Reassembly (SAR) function. This aspect is described in detail hereinafter with reference to FIG. 15-16.

[0074] As already described, the flow classification function 314 maps the packet to a MAC ID, LL mode, and stream ID if present. Layer segmentation function 312 (e.g., appropriate and reassembled segments a higher IP datagram packet or Ethernet frame) into segments for logical link transfer. An exemplary embodiment of this aspect is described in detail below with reference to FIG. 17-18. In this example, for each segment, a one-byte adaptation layer header, reassembly when the segments are delivered in order to the corresponding SAR function on the receiver. The Protocol Data Unit (PDU) of the adaptation layer is then forwarded to the data link control layer 320 for processing together with the classification parameters:

MAC ID, LL mode and stream ID.

it is added what enables

Data Link Control Layer [0075] FIG. 4 illustrates a user data packet 410 (i.e., IP datagram, Ethernet frame or other packet) passing through different layers. Examples of field sizes and types are described in this illustration. Those skilled in the art will recognize that various other sizes, types and configurations are contemplated within the scope of the present invention.

[0076] As shown, data packet 410 is segmented at adaptation layer 310. Each adaptive sublayer PDU 430 carries one of these segments 420. In this example, data packet 410 is split into N segments

420A - N. The adaptive sublayer PDU 430 has a payload 434 containing the corresponding segment 420. The field type 432 (one byte in this example) is attached to the adaptive sublayer PDU 430.

[0077] At Logic Link Layer 330 (LL), LL header 442 (4 bytes in this example) is attached to payload 444 which includes the unit, Example, stream identifier, sequence information information. CRC control

PDU 430 adaptive layer. for LL header 442 includes and numbers, control information and 446 is calculated based on header 442 and payload 444 and appended to form the PDU (LL PDU) 440 of the logical link sublayer. Logical Link Control (LLC) 338 and Radio Link Control (RLC) 340, described below, form the LLC PDU and RLC PDU in a similar manner. LL PDU 440 units, as well as LLC PDU and RLC PDU, are queued (i.e. queue 362 for high quality QoS services, queue 364 non-guaranteed delivery (best effort queue) or queue 366 control messages for support by the MUX 360 function. [0078] The MIX 360 function appends the MUX 452 header to each LL PDU 440. An example MUX header 452 may contain length and type (in this example, header 452 has two bytes). Similar header of the control unit The LL PDU 440 unit can be created for each

PDUs (i.e. PDUs LLC and RLC). or LLC PDU or RLC unit) creates payload 454. Header 452 and payload 454 form MUX sublayer PDU 450 (MPDU) (MUX sublayer PDUs are also referred to as MUX PDUs here).

[0079] Communication resources in the shared medium are allocated by the MAC in a series of MAC frames. The MAC 376 scheduler determines the size of the physical layer sequences allocated to one or more MAC IDs in each MAC frame, indicated as MAC frame f, where f indicates a specific MAC frame. It should be noted that not every MAC ID with data to be transmitted will necessarily be allocated space in any particular MAC frame. Any access control or scheduling scheme can be used within the scope of this

Of the invention. When the assignment is made for the MAC identifier

ID, the corresponding MUX 360 function for this MAC ID will create a MAC PDU 460, including one or more MUX PDU 450 to include in the MAC f frame. One or more MUX PDU 460, for one or more allocated MAC IDs will be included in the MAC frame (i.e., MAC frame 500, described in detail below with reference to FIG. 5).

[0080] In the exemplary embodiment, one aspect allows the transmission of a partial MPDU 450, enabling efficient packing in a MAC PDU 460. This aspect is described in detail below. In this example, the MIX 360 function maintains the number of un-transmitted bytes of any partial MPDU 450 units remaining from the previous transmission identified by the partial MPDU 464 unit. These bytes 464 will be transmitted before any new PDUs 466 (i.e. LL PDUs or control PDUs) in the current frame. Header 462 (two bytes in this example) includes a MUX pointer that indicates the beginning of the first new MPDU (MPDU 466A in this example) to be transmitted in the current frame. Header 462 may also include a MAC address.

[0081] The MAC PDU 460 unit includes the MUX 462 indicator, a possible MUX PDU 464 partial unit at the beginning (remaining from the previous allocation) followed by zero or more full MUX PDU 466A - N units, and a possible MUX PDU 468 partial unit ( current assignment) or other padding to populate the allocated portion of the physical layer sequence. The MAC PDU 460 is carried in the physical layer sequence allocated to the MAC ID.

53 / 59P25695PL00

Common MAC function, MAC frame and Transport Channels of the transport channel:

forward and reverse [0082] An example MAC frame 500 is shown in FIG.

5. The MAC 370 joint function manages the allocation of the MAC 500 frame among the following broadcast, control, traffic segments (called the downlink phase and the uplink phase respectively) and direct access. The MAC 372 function that creates frames can create a frame using various components, described below. Examples of functions, coding and durations of transport channels are described below.

[0083] In an exemplary embodiment, the MAC frame is subjected to Duplexing

Time Division

Time division

Duplex) (TDD) over a time interval of 2 ms. MAC frame

500 is divided into below [0084] five transport channel segments 510-550 that appear in the order shown. In alternative embodiments, reordered and different frame sizes can be used. Assignment durations in the MAC 500 frame can be quantized to several small common time intervals. In the exemplary embodiment, the assignment durations in the MAC frame are quantized to a multiple of 800 ns (which is also the duration of the cyclic prefix for either the short or long OFDM symbol, as described in detail later The short OFDM symbol lasts 4.0 μs or 5 times 800 ns. An example of the MAC function provides five transport channels in the MAC frame: (a) Broadcast Channel (BCH) 510 that carries the Broadcast Control Channel (BCCH); (b) Channel

Steering

CCH) 520, which carries the FCCH Control Channel) and Control Return Channel

Frames (Frame Control Channel

Random Access Feedback Channel (RFCH) on the forward link; (c) Traffic Channel (TCH), which

53 / 59P25695EN00 carries user data and control information, and is divided into (i) Forward Traffic Channel (F-TCH) 530 on the forward link and (ii) Reverse Traffic Channel (R-TCH) ) 540 on the reverse link; and (d) a Direct Access Channel (RCH) 550 that carries an Access Request Channel (ARCH) (for UT access requests). Pilot beacon in segment 510 is also transmitted.

[0085] The receive phase of the frame 500 comprises segments 510-530. The forward link phase comprises segments 540-550. Segment 560 indicates the beginning of the next MAC frame.

The Broadcast Channel (BCH) [0086] The Broadcast Channel (BCH) and beacon 510 are transmitted by an AP. The first part of the BCH 510 channel includes common physical layer overhead such as pilots, including timing and frequency acquisition pilot. In the exemplary embodiment, the beacon consists of 2 short OFDM symbols used for frequency acquisition and timing by the UT terminals, followed by 8 short OFDM symbols of the common MIMO pilot used by the UT terminals to estimate the channel.

[0087] The second part of the BCH 510 is part of the data. Part of the BCH channel data determines the MAC frame allocation to the transport channel segments: CCH 520, F-TCH 530, R-TCH 540 and RCH 550, and also determines the composition of the CCH channel relative to the subchannels. In this example, the BCH 510 determines the wireless coverage and is transmitted in data transmission. The length of LAN 120, the strongest possible mode of the entire BCH channel is the constant execution, the BCH channel determines the coverage of the MIMO-WLAN, and is transmitted in the Time-Spatial Diversification mode

In the example variant

53 / 59P25695PL00

Transmitting (STTD) using Binary Phase Keying (BPSK) coded with a correction rate (code rate) of 1/4. In this example, the length of the BCH channel is set to 10 short OFDM symbols.

Control Channel (CCH) [0088] Control Channel (CCH) 520, transmitted by the AP, determines the composition of the rest of the MAC frame. Channel control function 374 of the MAC 370 common function generates a CCH channel. An exemplary embodiment of the CCH channel is described in detail below. The CCH 520 channel is transmitted using very strong transmission modes across multiple subchannels, with each subchannel having a different data rate. The first subchannel is the strongest and is expected to be decodable across all UT terminals. In the exemplary embodiment, BPSK coding with a correction factor of 1/4 is used for the first subchannel in the CCH channel. Several other sub-channels with decreasing strength (and increasing performance) are also available. In the example embodiment, up to three additional subchannels are used. Each UT terminal tries to decode all subchannels in turn until the decoding fails. The transport channel segment in the CCH channel in each frame is different in length, the length depending on the number of CCH messages in each subchannel. Confirmations for a reverse link direct access sequence are carried over the strongest (first) subchannel on the CCH.

[0089] The CCH includes physical layer sequence assignments on the forward and reverse links. The assignments can be for data transfer on the forward or reverse link. Basically, physical layer sequence mapping

53 / 59P25695EN00 includes: (a) MAC ID; (b) a value indicating the initial allocation time in the frame (on the F-TCH or R-TCH); (c) the length of the assignment; (d) the length of the separated physical layer markup; (e) transmission mode; and (f) the coding and modulation scheme to be used for the physical layer sequence. The MAC ID identifies a single UT for unicast transmissions or a set of UT for multicast transmissions. In the exemplary embodiment, the unique MAC broadcast ID is also assigned for transmission to all UT terminals. In the exemplary embodiment, the physical layer overhead includes a dedicated MIMO pilot consisting of 0, 4 or 8 short OFDM symbols. In this example, the transmission mode is alternatively STTD or spatial multiplexing.

[0090] Other exemplary types of assignments on the CCH include: uplink assignments for a dedicated pilot transmission from the UT or uplink assignments for the transmission of buffer and link state information from the UT. The CCH may also specify portions of the frame to be left unused. These unused portions of the frame can be used by UTs to produce noise (and interference) estimates, to measure neighboring beacon signals. An example embodiment of the control channel is described in detail below.

and also in systems. is

Direct Access Channel (RCH) [0091] Direct Access Channel (RCH) 550 is a reverse link channel in which the UT can transmit a direct access sequence. The variable length of the RCH channel is specified for each frame in the BCH channel. In the exemplary embodiment, the direct access sequences are

53 / 59P25695EN00 transmitted using the main proprietary module with BPSK coding with a correction factor of 1/4.

[0092] In the exemplary embodiment, two types of direct access sequences are specified. The long sequence is used by UTs for initial access when the AP needs to detect the beginning of the access sequence using a sliding correlator. When the UT is registered to the AP, the two ends of the link complete the timing matching procedure. After timing adjustment, the UT may transmit its own direct access sequences synchronized with the slot timing on the RCH. He can then use the short sequence for direct access. In the exemplary embodiment, the long sequence contains 4 short OFDM symbols and the short sequence contains two short OFDM symbols.

Transmission Traffic Channel (F-TCH) [0093] Transmission Traffic Channel (F-TCH) 530 includes one or more physical layer sequences transmitted from AP 104. Each sequence is directed to a specific MAC ID according to the CCH assignment indication . Each sequence contains a separate physical layer overhead such as a pilot signal (if present) and a MAC PDU transmitted according to the transmission mode and the coding and modulation scheme indicated in the CCH assignment. The F-TCH has a variable length. In the exemplary embodiment, the dedicated physical layer overhead may include a dedicated MIMO pilot.

[0094] In the exemplary embodiment, in STTD mode there is only one equivalent spatial diversification channel whose performance may vary between

53 / 59P25695EN00 bits (BPSK keying coded with a correction factor of 1/2, on 48 tones) per short OFDM symbol, and 1344 bits (QAM 256 coded with a correction factor of 7/8, on 192 tones) per long symbol OFDM. This translates into a factor of 33 in the peak physical layer data rates (or 3-99 Mbps in this example).

[0095] In this example, a spatial multiplexing mode comprising up to four parallel spatial channels may be used. Each spatial channel uses a corresponding coding and modulation scheme whose performance is between 12 bits per short OFDM symbol and 1344 bits per long OFDM symbol. Thus, the peak range of physical layer data rates in spatial multiplexing mode is between 3 and 395 Mbps. Due to spatial processing restrictions, not all parallel spatial channels may be able to operate at the highest performance, so a more practical limitation of the peak physical layer data rate may be 240 Mbps, a factor of 80 between the lowest and highest bit rates in this example.

Reverse Traffic Channel (R-TCH) [0096] Reverse Traffic Channel (R-TCH) 540 includes transmission of physical layer sequences from one or more UT 106 terminals. Each sequence is transmitted via a particular UT as indicated in the CCH assignment . Each sequence may include a dedicated pilot preamble (if present) and a MAC PDU transmitted in accordance with the transmission mode and the coding and modulation scheme indicated in the CCH channel assignment. The R-TCH has

Variable length. In the exemplary embodiment, as in the F-TCH channel, the data rate range in the STTD mode is 3-98 Mbps, and in the spatial multiplexing mode is 3-395 Mbps, with 240 Mbps being probably a more practical limitation.

[0097] In an exemplary embodiment, the F-TCH 530 channel, the R-TCH 540 channel, or both, can use spatial multiplexing or code-split multi-access techniques to enable simultaneous transmission of MAC PDUs associated with different UTs. The field containing the MAC ID to which the MAC PDU is associated (i.e. the sender on the forward link, or the intended recipient on the downlink) can be included in the header of the MAC PDU. This can be used to resolve any addressing ambiguities that may occur when spatial multiplexing or CDMA is used. In alternative embodiments, when the multiplexing is strictly based on time sharing techniques, a MAC ID is not required in the header of the MAC PDU because the addressing information is contained in the CCH channel message allocating the given time slot in the MAC frame for the specific MAC ID. Any combination of spatial multiplexing, code division multiplexing, time division multiplexing, or any other technique known in the art may be used.

each pre-registration is assigned an ID

Assigning the MAC ID to the 344 Association Control (AC) function of the RLC 340 control. A unique MAC ID is assigned for broadcasts on the forward link. The broadcast transmission is part of the Transmission Traffic Channel (F-TCH) and is assigned using the Control Channel (CCH) by [0098] During the UT the active MAC ID. is supported by

53 / 59P25695EN00 using the unique MAC ID of the broadcast. In this example, the system identification message is broadcast once every 16 frames using the MAC ID of the broadcast ID. The broadcast MAC ID can also be used to broadcast user data.

[0099] A set of one or more MAC IDs may be assigned for multicast transmission on a forward link. Multicast transmission is part of the F-TCH and is assigned in the CCH by using the specific multicast MAC ID assigned to the specific multicast group. The assignment of a multicast MAC ID to a group of UT terminals is supported by the 344 Association Control (AC) function of the RLC 340 control.

[0100] Let us now return to the description of the common MAC function 370 shown in FIG. 3. The direct access control function 378 on the AP supports the acknowledgment for the access sequence from the UT terminals. Together with the confirmations, the AP must make an immediate allocation on the R-TCH to obtain buffer status information from the UT. This request is forwarded to scheduler 376.

[0101] At the UT, the direct access manager determines when to transmit the access sequence based on data in its MUX queues, as well as existing allocation. When the UT has a periodic allocation due to an existing LL connection, buffer status information may be provided using the existing R-TCH allocation.

[0102] Based on the information contained in the buffer and link state messages received from the UT, the corresponding MUX 360 function on the AP accesses the UT intermediate terminal. The UT intermediary terminal maintains its status

The MUX function buffers in the UT terminal that are used by scheduler 376 to create R-TCH allocations. The UT proxy also maintains the maximum transmission rates at which the AP can transmit to the UT on the F-TCH.

[0103] The MAC common function 370 at the AP implements scheduler 376 to resolve the allocation between UTs while making efficient use of each MAC frame. To limit overhead, not all active UTs may be allocated a physical layer sequence in each frame.

[0104] The following information may be used by scheduler 376 to create an allocation in each MAC frame:

[0105] 1. Nominal allocation to each MAC ID. It can happen that only a subset of active UTs can be allocated in any frame. For example, some UT terminals may be provided with a nominal allocation only every second frame, every fourth frame, and so on. The nominal allocation is determined by the function 384 of receiving requests in the layer 384 manager. In the exemplary embodiment, the nominal allocation is created in terms of the number of OFDM symbols.

[0106] 2. Allocation for dedicated physical layer overhead such as pilot signals. Radio Resource Control (RRC) 342 in the RLC 340 control determines the required length and periodicity of the separated physical layer overhead. In an exemplary embodiment, the physical layer overhead includes a dedicated MIMO pilot.

[0107] 3. Transmission mode and rate. This is determined by the RRC 342 control for the R-TCH and provided to scheduler 376. For the F-TCH, this information is obtained from the UT in the link and buffer status message and maintained at the UT Intermediate Terminal.

[0108] 4. Outstanding data for each MAC ID. This information is available to scheduler 376 from the MUX 360 function for each MAC ID for the forward link, and from the UT proxy for the reverse link.

[0109] In addition, the scheduler allocates the duration of the RCH and determines the duration of the CCH. Each assignment in the CCH channel is transmitted using one of four coding schemes (based on the channel quality to the UT). Thus, the CCH duration is a function of the number of assignments and the coding scheme used to transmit each assignment.

[0110] Based on the allocation determined by the scheduler, the MAC entity at the AP completes the parameters for each assignment to form the BCH and CCH. The BCH channel determines the allocation of the MAC frame in terms of transport channel segments: CCH, F-TCH, R-TCH and RCH, and also determines the composition of the CCH channel in terms of subchannels (or subsegments) as described above with reference to FIG. . 5. An example of a CCH channel is described in detail below.

[0111] In the example embodiment, each assignment on the CCH is transmitted in one to four subchannels (or sub-segments), each of which uses a different coding and modulation scheme (based on channel quality to the UT terminal). Multicast and broadcast assignments are transmitted using the strongest encoding scheme (first subchannel or subsegment). The MAC entity in the UT reads the CCH to determine its allocation on the forward and reverse links for this frame.

[0112] In the transmitter, the MAC function transmits the MAC PDU associated with the specified MAC ID in the physical layer sequence allocated on the F-TCH (at

Access AP) or R-TCH (in UT terminal) to this MAC ID. In the receiver, the MAC function extracts the MAC PDU corresponding to the MAC ID based on the CCH channel assignment and forwards it to the MUX function for that MAC ID.

MUX [0113] The MUX 360 function is described in detail below with reference to FIG. 19-23. In the receiver, the MUX function extracts PDUs from the byte stream consisting of successive MAC PDUs and routes them to the LL, LLC or RLC unit to which it belongs. The redirection is based on the type field (logical channel) contained in the header

MUX PDU.

Radio Link Control (RLC) [0114] During system initialization, the Radio Link Control (RLC) 340 broadcast function of system identification control function 346 is initiated. When the UT initially accesses the system using the MAC ID from the access pool, the RLC function assigns the UT the new unicast MAC ID. Then, if the UT joins the multicast group, it may be assigned additional MAC multicast IDs.

[0115] When the UT terminal is assigned a new unicast MAC ID, the RLC control initiates one instance of each of the functions: Link Control (AC) 344, Radio Resource Control (RRC) 342 and Logical Link Control (LLC) 338. When assigned is the new MAC multicast ID, RLC control

53 / 59P25695EN00 initializes a new AC instance and LLC control for LL link multicast mode.

[0116] In an exemplary embodiment, a message regarding system identification parameters is transmitted by the AP once every 16 MAC frames using the broadcast MAC ID. The message regarding the system identification parameters contains the IDs of the network and AP, as well as the revision numbers of the protocols. In addition, it contains a list of MAC access IDs for use by UTs for initial system access.

[0117] The AC 344 (a) function provides UT authentication; (b) manages the registration (add / remove) functions for the UT (in the case of the MAC multicast ID, the AC function manages adding / subtracting from the multicast group); and (c) exchanging the encryption key for the LL link.

[0118] One RRC instance 342 is initialized at each UT. One RRC instance per active UT is initialized at the AP. The RRC functions at the AP and UT may share forward and reverse link channel measurements (if necessary).

[0119] The RRC (a) function manages the calibration of transmit and receive chains at the AP and UT (this calibration may be required for the spatial multiplexing transmission mode; (b) specifies the transmission mode and rate control for the transmission to the UT and provides to the 376 MAC scheduler; (c) determines the periodicity and length of the separated physical layer overhead, such as the dedicated pilot required for physical layer sequence transmissions on the R-TCH and in the F-TCH; (d) manages the power control for transmission to and from the UT terminal and

It provides it to the PHY Manager and (e) determines the timing match for R-TCH transmission from the UT.

Logical Link (LL) [0120] Adaptive Layer PDUs consisting of user data segments are provided to DLC layer 320 together with associated MAC ID, LL link mode and stream ID, if any. LL mode function 330 adds an LL header and a 3-byte CRC control calculated based on the entire LL PDU. There are several types supported in the example embodiment. Functions with 336 confirmations and without 334 confirmations can be used. The transparent function 332 broadcast / multicast / unicast can also be used. For illustration, four LL modes are shown (details of their formats in MUX PDUs are shown in FIG. 23):

[0121] 1. Connectionless Mode Without Confirmation (Mode 0). The LL header is empty in this case. This mode can be used to transparently pass adaptive layer PDUs. Mode 0 LL can implement policing. Only connectionless unacknowledged (transparent) mode is available for broadcast and multicast MAC IDs.

[0122] 2. Connectionless Confirmation Mode (Mode 1). This mode is used for Adaptive Layer PDU confirmation transmissions without having to associate the overhead and delay with establishing a LL Mode 3 connection. The LL Mode 1 header contains the sequence number of the transmitted LL PDU or the sequence number of the confirmed PDU. Because physical layer channels are expected to operate with a low probability of random unit loss

53 / 59P25695PL00

LL PDU and a small delay transmission both ways, a simple Go-Back-N ARQ scheme is used.

No Confirmation Mode (Mode 2). without confirmation allows flows through the use of can implement stream ID.

[0123] 3. Connection

Connection LL mode multiplexing several stream IDs. LL Mode 2 supervision per ID LL Mode 2 header contains stream ID and 12 bit sequence number.

Confirmation Mode (Mode 3) with confirmation allows flows through

LL 3 mode [0124] 3. Connection

The LL connection mode multiplexing several stream IDs supervision per use may implement the stream ID.

The Mode 3 LL header consists of a stream ID to identify multiple flows carried in a reliable connection. The 12-bit sequence number identifies the LL PDU and the ACK field indicates the highest received sequence number that is being confirmed. As in the case of LL Mode 1, because the physical layer channels are expected to operate with a low probability of random LL PDU loss and low round trip delay, a simple Go-Back-N ARQ scheme is used. However, an ARQ scheme with selective repetition can also be used.

[0125] Logical Link Control (LLC) function 338 manages logical link mode control. When a new LL mode is to be established, the LLC function provides a negotiation mode including: (a) QoS Quality of Service: guaranteed transmission speed; (b) setting the mode; (c) cancellation of the procedure; (e) mode reset; and (f) assigning stream IDs in LL modes 2 and 3. End-to-end flow mapping to LL mode is determined by the QoS manager function 382 on layer 380 manager. Request

Initializing a new LL mode or adding a stream to an existing LL mode is derived from adaptation layer 310 as described above.

[0126] Control 350 System Configuration manages TDD MAC Frame configuration, including Navigation Signal and BCH channel content and RCH channel length.

Layer Manager [0127] QoS Manager 382 interprets network QoS protocols, including RSVP and RTCP. When QoS Quality of Service is based on the classification of IP header flows, the QoS manager determines which flow classifiers (i.e. source and destination IP addresses, source and destination IP ports) to use to identify flows corresponding to different services. QoS Manager supports the adaptive layer by mapping flows to LL modes.

[0128] The request receipt control function 384 receives requests from the LLC function to allow new flows with transmission rate requirements. The receipt control function maintains a database of admitted nominal assignments and a set of rules and threshold values. Based on the thresholds and rules, the receipt control determines whether the flow can be allowed, defines the nominal flow allocation (in terms of the amount of transmission time allocated to each MAC frame), and provides this information to the scheduler in a common MAC function.

[0129] The physical layer manager uses the physical layer measurements collected by the AP and the UT to control the transmitter and receiver parameters in the physical layer. Remote measurements can be obtained via RRC messages.

53 / 59P25695PL00

Illustrative Procedures [0130] Based on the described layer units, several procedures may be used to describe the operation of the WLAN 120. These procedures are not exhaustive, but serve to illustrate the various functions and components described herein. [0131] FIG. 6 illustrates an example method 600 for performing a forward link transfer from an AP. In block 610, the RLC (bind control, radio resource control or logical link control) function in the AP places the message (RLC PDU) in the control message queue. Or, the LL mode at the AP places the LL PDU in the QoS High Quality queue or unguaranteed delivery queue. [0132] At block 620, the scheduler allocates resources on the F-TCH for transmitting PDUs in three MUX queues. In block 640, the assignment is indicated on the CCH by MAC control. In block 650, the MAC control at the AP transmits the message in the MAC PDU in the allocated physical layer sequence.

[0133] FIG. 7 depicts an example method 700 for receiving a forward link message transfer at the UT. In block 710, the UT controls the CCH. The UT identifies the allocated sequence directed to the UT. In block 720, the UT receives the MAC PDU identified on the CCH. At block 730, the UT again assembles the flow packet containing the segments recovered in MAC PDUs and processed in the MAC processor.

[0134] FIG. 8 depicts an example method 800 for performing uplink message transfer from the UT. In block 810, the RLC function (association control, radio resource control or logical link control) in the UT places the message (RLC PDU) in the Control Message queue. Or LL mode in the UT terminal places

In decision-making 820 MAC unit, LL PDU in the QoS High Quality Queue or unguaranteed delivery queue. In decision block 820, if the UT has an existing R-TCH allocation, it goes to block 870. If not, it goes to block 830.

[0135] At block 830, the UT transmits a short access sequence on the RCH. In block 840, the UT receives confirmation of the RCH access sequence and grant access grant on the CCH. In block 850, the UT transmits a link and buffer status message to the AP. In block 860, the UT controls the CCH in terms of granting the R-TCH assignment. In block 870, an allocation is received (or was already present in the block. The UT block from the MUX PDUs forms the PDU and transmits the MAC PDU in the allocated physical layer sequence.

[0136] FIG. 9 depicts an example method 900 for receiving a uplink message transfer on an AP. In block 910, the AP receives and controls the RCH. In block 920, the AP identifies the short access sequence from the UT. In block 930, the scheduler allocates access. In block 940, the AP transmits acknowledgment and grant access on the CCH. In block 950, in response to the grant of access, the AP receives a link and buffer status message on the R-TCH. In block 960, the access point updates the UT proxy according to the buffer status. The scheduler has access to this information. In block 970, the scheduler allocates resources on the R-TCH. In block 980, the AP receives MAC PDUs according to the allocations made. At block 990, the access point reassembles the flow packet in response to one or more received MAC PDUs.

The system from the message the UT determines with the function Transmissions [0137] FIG. 10 depicts an example method 1000 for performing initial access and registration at a UT. In block 1010, the UT acquires frequency and timing from the frequency acquisition pilot on the BCH channel. At block 1020, the UT receives RLC broadcast identification information. In block 1030, an RCH channel assignment for (not partitioned) direct access using long BCH sequences. In block 1040, the UT selects the MAC ID randomly from the set of initial MAC IDs. At block 1050, the UT transmits a long direct access sequence on the RCH using the initial MAC ID. In block 1060, the UT receives confirmation, assignment of the MAC ID and timing adjustment in the next MAC frame. In block 1070, the UT binding control function completes the authentication and the AP key binding control control key exchange sequences of the forward and reverse link control message follow the low level message transfer procedures described above with reference to FIG. 6 - 9.

[0138] FIG. 11 depicts an example method 1100 for performing initial access and registering with an AP. In block 1110, the AP receives a long direct access sequence from the UT on the RCH. In block 1120, the AP assigns the UT the MAC ID. The MAC ID pool is managed by the radio link control function. In block 1130, the AP assigns the timing adjustment to the UT. At block 1140, the AP transmits acknowledgment, MAC ID and timing matching on the CCH. In block 1150, the AP binding control function completes authentication and key exchange sequences with the UT binding control function.

53 / 59P25695PL00

Control message transmissions on the forward and reverse links follow the low-level message transfer procedures described above with respect to FIG. 6 - 9.

[0139] FIG. 12 depicts an example method 1200 for user data flow at an AP. In block 1210, the QoS manager in the layer manager populates the flow classification parameters as a function of flow classification. A particular combination of parameters and values ​​may indicate the arrival of a new flow. These parameters may include: IP Service Differentiation Code Point (DSCP) or source IP address or IP port. Ethernet parameters may include: 802.1Q VLAN ID or 802.1q priority indication. Certain IP port values ​​may indicate a control protocol message (e.g., RSVP or RTCP) to be forwarded to the QoS manager.

[0140] In block 1215, the AP determines the access parameters. When the packet arrives at the AP adaptation layer and is determined by the flow classification as a new flow, the flow classification works with the QoS manager to determine the access parameters, including the QoS class (high QoS or unguaranteed delivery), LL mode and nominal transmission rate, to be allocated to the flow. In decision block 1220, based on the access parameters, the control of receiving requests in the layer manager determines whether the flow can be allowed. If not, the process may stop. Otherwise, proceed to block 1225.

[0141] At block 1225, flow classification requests the LLC to establish a new stream. In this discussion, the case of high quality QoS services, connection in 3 LL mode is considered. In block 1230, the LLC control at the AP communicates with the LLC control at the UT to establish a connection (or a new stream ID if a corresponding one already exists)

Connection). In this example, LLC controls will attempt to establish a connection in 3 LL mode (or a new stream ID if a connection in 3 LL mode already exists). At block 1235, the nominal baud rate allocated to the flow is reported to the scheduler. For LL mode 3, the nominal allocation is made on both the send and return channels.

[0142] At block 1240, the flow classification classifies packets for flow, identifies MAC IDs, LL mode and stream ID, performs flow supervision and forwards compatible packets to the SAR function. In block 1245, the SAR function segments packets and forwards the adaptation layer PDUs to the LL function for MAC ID along with LL mode and ID stream ID. In block 1250, the LL function appends the LL header and CRC control and places the LL PDUs in the appropriate queue. In this example, the LL mode 3 function appends the LL header and CRC control, and places LL PDUs in the MUX QoS High Quality Services queue.

[0143] In block 1255, the MUX function prepares the MUX PDU by adding a MUX header identifying the LL mode and length. The MUX function creates a MUX indicator indicating the number of bytes to the beginning of the first new MUX PDU.

[0144] At block 1260, the scheduler determines the allocation of the F-TCH (physical layer sequence) for the MAC ID. The scheduler recognizes the transmission mode (from RRC control) and the baud rate to be used (from the UT Intermediate Terminal). Note that a reverse link allocation may also be included. In block 1265, the allocation is transmitted on the CCH channel.

[0145] In block 1270, the MAC function transmits a MAC PDU. The MAC PDU consists of the MUX Indicator followed by a possible partial MUX PDU at the beginning followed by zero or more filled MUX PDUs,

And finally, possible partial MUX PDU unit at the end

<td>sequence</td><td>physical layer.</td><td></td><td></td><td></td><td></td>

<td> [0146]</td><td>FIG. 13 presents</td><td colspan="2">example way</td><td> 1300</td><td>for</td>

<td>flow</td><td>user data in</td><td>UT terminal.</td><td>IN</td><td>block</td><td> 1310</td>

<td>terminal</td><td>UT receives the assignment</td><td>in the CCH channel.</td><td>IN</td><td>block</td><td> 1320</td>

<td>terminal</td><td colspan="2">UT receives the MAC PDU in accordance with</td><td colspan="3">allotment. IN</td>

of block 1330, the MUX function in the UT terminal extracts MUX PDUs by using the MUX indicator and length field in the MUX header and prepares LL PDUs. In block 1340, based on the type field in the MUX header, the MUX function sends LL PDUs to the appropriate LL function, mode 3 LL in this example. In block 1350, LL mode 3 starts the ARQ receiver and calculates CRC checks for each LL PDU. In block 1360, mode 3 LL at the UT must send an ACK / NAK message to the mode 3 LL ARQ at the AP. The ACK / NAK message is placed in the QoS High Quality Services queue at the UT MUX. Note that other LL modes may not include confirmation as described above.

[0147] In block 1370, the AP transmits the message

ACK / NAK on the R-TCH as allocated. It should be recalled that the scheduler allocates R-TCH resources for the MAC ID based on the nominal allocation for the reverse link. The ACK / NAK message is transmitted in the MAC PDU in the reverse link physical layer sequence from the UT. In block 1380, the UT may transmit any other uplink queue data in the remaining allocation.

[0148] Returning again to FIG. 3, as described above, flows 260 are received at the AP's MAC 220, and the appropriate data and signaling pass down through the adaptation layer 310, data link control layer 320 and physical layer for transmission to the UT. The physical layer 240 at the UT receives the MAC PDUs and corresponding data, and the signaling goes up through

Data link control layer 320 and adaptation layer 310 in the UT MAC processor 220, re-complex flows for delivery to one or more higher level layers (i.e., for various processes, including data, voice, video, etc.) . A similar process is in the opposite direction for flows originating from the UT and transmitted to the AP.

[0149] At both the AP and the UT, the appropriate layer manager 380 may be used to control how information flows up and down through the various MAC sublayers. Generally speaking, any type of feedback 280 from physical layer 240 can be used in layer manager 380 to perform various sublayer functions. The physical layer manager 386 provides the interface of physical layer 240. The feedback is provided to any function in the layer manager, examples include the 384 receipt control function and QoS 382 manager. These functions in turn can interact with any of the sublayer functions described above. [0150] The principles described herein can be used with any physical layer specification supporting multiple transmission formats. For example, many physical layer formats allow for many transmission speeds. Bandwidth for any given physical link may be determined by available power, channel interference, supported modulation format and the like. Exemplary systems include OFDM and CDMA systems that can use MIMO techniques. These systems use closed loop techniques to determine the baud rate and formats. Closed loop can use different messages or signals to indicate channel measurements, supported baud rates, etc. Those skilled in the art will readily adapt these and other systems to implement the techniques described herein.

[0151] Physical layer feedback can be used in the adaptation layer 310. For example, information about the rate can be used in segmentation and reassembly, flow classification, and multicast mapping. FIG. 14 depicts an example method 1400 for introducing physical layer feedback into an adaptation layer function. This method is described with reference to the access point, but can be used in an analogous manner in the user terminal. The process starts at block 1410, where flow packets are received for transmission to one or more user terminals. In block 1420, the functions of the adaptive layer are implemented in response to physical layer feedback for the respective user terminals. To further illustrate this aspect, embodiments of the exemplary multicast mapping and segmentation mapping are described in detail below. In block 1440, physical layer feedback is controlled for one or more user terminals. The process may return to block 1410 to repeat for the additional flow packets received, in response to the updated physical layer feedback.

[0152] In an alternative embodiment, information about the transmission rate of the other physical layer feedback may be used when making decisions for receiving requests. For example, a high QoS Service flow may not be granted access until the target physical ID MAC link is able to support a sufficiently high rate of transmission. This level can be adjusted based on system load, including nominal allocations to existing flows, the number of registered UTs, and the like. For example, a UT terminal with a relatively high quality link may be

53 / 59P25695EN00 more likely to allocate a high QoS Quality service flow than a MAC ID associated with a lower quality link. When the system is lightly loaded, the threshold requirements can be lowered.

Adaptive Layer Group Broadcasting [0153] FIG. 15 depicts an example method 1500 for performing adaptation layer multicast. The multicast of the adaptive layer is an example of a method 1400 of introducing physical layer feedback into the function of an adaptive layer. It should be recalled that one method of multicast transmission, MAC layer multicast, provides a common MAC ID corresponding to the list of user terminals, a common MAC ID or MAC ID for multicast, distinct from any of the user's terminal MAC IDs. Thus, the UT, when assigned to one or more multicast groups, will control the CCH channel in terms of transmissions not only directed to its individual MAC ID, but also transmissions directed to one or more multicast MAC IDs, with which the UT is associated with. Thus, the multicast MAC ID may be associated with one or more higher layer flows to allow transmission of a single flow to multiple user terminals.

[0154] In multicasting of the adaptation layer, instead of performing a single transmission for reception by all user terminals in the multicast list, one or more additional multicast data transmissions may be made to one or more user terminals. In the example

In an embodiment, the multicast of the adaptation layer performs unicast transmission to each user terminal in an alternative example of a multicast group. In an embodiment, the adaptation layer multicast can perform one or more MAC layer multicast transmissions using one or more MAC IDs associated with subsets of multicast groups. Unicast transmissions can be directed to user terminals that are not included in one of the subgroups. Any combination of the above may be used. In block 1510, a multicast flow directed to the list of user terminals is received. In one embodiment, the MAC ID is associated with a list of user terminals.

[0155] Decision block 1520 determines whether unicast transmission is more efficient than multicast transmission (i.e., a single transmission received by multiple users) to user terminals in the list. If so, at block 1530 the multicast flow is transmitted on two or more channels. Two or more channels may include unicast channels, other multicast channels, or a combination of both. In decision block 1520, if the unicast channel is more efficient, then the multicast data is broadcast to the users of the multicast group in a single transmission using the multicast MAC ID.

[0156] In general, multicast transmission must use a format suitable for transmission at the weakest physical link in the physical link group of user terminals in the multicast group. On some systems, the fact that a better-located user terminal could benefit from a higher transmission speed and higher bandwidth does not affect system bandwidth because

In spite of this, the transmission with the lowest common denominator must still be carried out to reach the user terminal with the lowest quality physical link. However, in other situations this may not be an example, the use will apply. You can consider spatial processing in the MIMO system. The members of a multicast group can be scattered over a coverage area, and two or more users can have very different channel characteristics. An illustrative example of a multicast group containing two user terminals may be considered. By adjusting the transmission format for each user terminal, high unicast rates to each of them can be obtained. However, since the two channel environments for each physical link are completely different, the transmission format reaching each user terminal suitable for using a single multicast message can be have a lower bandwidth than unitary. When the multicast size is large enough, by creating any of the send channels, the difference between the bandwidth of the channel and the unicast channel is the system can use less resources of two independent multicast data transmissions than by transmitting a single message that can be received by both.

[0157] FIG. 16 illustrates an example determination method suitable for used in decision block 152 whether to use adaptive layer multicasting or MAC layer multicasting. In block 1610, the link parameters for each user terminal in the multicast list are received. In one embodiment, a baud rate parameter may be used. In block 1620, the link parameters for the multicast channel suitable for transmission to the user terminals on the multicast list are received. Link parameters

The multicast channel may be different than the link parameters for any individual channels for user terminals in the multicast group. In block 1630, the system resource requirements for the multicast channel are compared (i.e., using the multicast MAC ID for a single transmission) with the system resource requirements for the sum of individual unicast transmissions. The lowest system resource requirements can be used to determine the most efficient choice.

[0158] In an alternative embodiment, block 1610 may be modified to include MAC layer multicast channel link parameters containing subgroups of group multicast user terminals. The combination of multicast and unicast can be compared with pure MAC layer multicast. These and other modifications will be understood by those skilled in the art.

Physical Layer Feedback Segmentation [0159] FIG. 17 depicts an example method 1700 of performing segmentation in response to physical layer feedback. This serves as another example of a method 1400 for introducing physical layer feedback into an adaptive layer function. This process may be performed as a segmentation and reassembly function 312 at adaptation layer 310 in response to physical layer feedback provided by layer manager 380.

[0160] At block 1710, a flow packet is received for transmission to the appropriate MAC ID. In block 1720, the baud rate information for the corresponding MAC ID is recovered. In block 1730, packet segmentation occurs in response to the MAC ID baud rate. In the example variant

In embodiment, this segmentation creates segments 420 that are used to form the adaptation sublayer PDUs 430 as described above with reference to FIG. 4. [0161] FIG. 18 is an exemplary embodiment of the method illustrating segmentation in response to a transmission rate. This method is suitable for use in block 1730, which has just been described. The process begins in decision block 1810. If there is a change in transmission speed, it goes to decision block 1820. If there is no change in transmission rate, the process may stop and the size of the segmentation may remain unchanged. [0162] In decision block 1820, if the change in transmission speed consisted of an increase in transmission speed, then gains associated with increasing segment size may occur. For example, as shown above in FIG. 4, each segment receives overhead layers when passing through the protocol stack. Reducing the number of segments reduces the amount of overhead required. In addition, the higher bit rate generally indicates higher channel quality. It may be that while channels can change over time, even very rapidly, on average, the channel remains relatively constant for a particular time segment. An increase in transmission speed with a corresponding increase in segment size may allow segment transmission in approximately the same time period as in a smaller segment at a lower speed

If this time period is proportional to which the channel tends to remain in a relatively stable state (i.e., the serviceable transmission speed has not changed), then increasing the segment size may allow for increased performance with the unlikely negative effects of increasing segment size.

[0163] Another consideration of segment size selection occurs when a change in physical layer transmission rate occurs. Changing the transmission speed may result in the need for a time transmission, in

Resizing the segment so that the delay limitation for the service with the least delay limitation or control message queue requirements is met by priority without pre-emption in the MUX function, as will be described in detail below with reference to FIG. 19-23.

[0164] Various techniques for selecting segment size may be used within the scope of the present invention. Returning to FIG. 18, in an exemplary embodiment, when the rate of change is changed in decision block 1820, proceed to block 1830 to increase the size of the adaptive sublayer PDU. In decision block 1820, if the change in baud rate was to reduce the baud rate, then proceeds to block 1840 to reduce the size of the adaptive sublayer PDU, according to any technique just discussed.

[0165] The method of FIG. 18 is mainly used to illustrate one possible mechanism for segmentation using the relationship between the physical layer transmission rate and segmentation size. In an alternative embodiment, a segmentation size table may be generated, each segmentation size being associated with a baud rate or range of baud rates. In yet another embodiment, a function may be used whose one argument is the baud rate and the output of the function giving the size of the segmentation. Countless other options will be apparent to those skilled in the art in the context of this description. It should be noted that segmentation, as already described, can be combined with multicast mapping techniques as described above with reference to FIG. 14-16, as well as any other adaptive layer function performed in response to physical layer feedback.

53 / 59P25695PL00

Multiplexing [0166] In an exemplary high performance wireless LAN subnet such as 120 wireless network, all communication may take place between the AP and one or more UT 106 terminals. As described above, this communication may be of either unicast nature or multicast. In uplink-based communication, user data or control data is sent from the AP to a single UT or from the UT to an AP. Each UT terminal has a unique MAC ID, so all communication based on unicast between the UT and the AP is associated with this unique MAC ID. In group-based communication, user data or control data is transmitted from the AP to multiple UTs. There is a pool of MAC IDs reserved for use as multicast addresses. There can be one or more multicast groups defined so as to be associated with an access point, and each of these groups is assigned a unique MAC ID. Each UT may belong to one or more (or none) of these multicast groups, and will receive transmissions associated with each multicast group to which it belongs. For the purposes of multiplexing discussion, multicast adaptation layer is considered as unicast. In this example, UTs do not transmit multicast data.

[0167] The access point receives user data from external networks (i.e. networks 102) addressed to UT terminals in its coverage area and from UT terminals in its coverage area, directed to other devices or UT terminals in the coverage area, or connected through the network 102. Point

The access can also generate control data, provided for single or multiple UT terminals in the coverage area, from Radio Link Control Function 340 (RLC), Logical Link Control Function 330 (LLC), as well as other units. User data addressed to a single UT can then be segregated into multiple streams based on consideration of QoS Quality Services or other aspects, such as the source application, as described above.

[0168] As described in detail above, the access point eventually collects all data from all sources destined for a single MAC ID into a single byte stream, which is then formatted into MAC PDUs, each of which is transmitted in a single MAC frame. The access point may send MAC PDUs for one or more MAC IDs in a single MAC frame (i.e., on the forward link).

[0169] Similarly, the UT may have user data to send, which may be segregated into multiple streams. UTs can also generate control information associated with RLC 340 control, LLC 330 control or other units. The UT collects user data and control data into a single byte stream, which is then formatted into MAC PDUs, each of which is sent to the AP in a single MAC frame. One or more UTs may send a MAC PDU in a single MAC frame (i.e. on a reverse link).

[0170] The MUX 360 function is implemented such that it falls on the MAC ID at the AP. Each UT is initially assigned one MAC ID for unicast transmissions. Additional MAC IDs can be assigned if the UT belongs to one or more multicast groups. The MUM function allows (a) subsequent assignments of the physical layer sequence to the MAC ID be

Treated as a byte stream, and (b) for multiplexing PDUs from one or more LL units or

RLC in byte stream in MAC.

[0171] FIG. 19 depicts an example method 1900 transmitting multiple flows and commands in a single MAC frame. This method is suitable for use either at the access point or at the user terminal. The process begins with decision block 1910. If one or more packets from one or more flows destined for the MAC ID are received, then proceed to block 1920 to compare MUX PDUs associated with the MAC ID for the respective one or more flows. In the exemplary embodiment, MUX PDUs are prepared according to the MAC protocol detailed above, but alternative MAC protocols may be used within the scope of the present invention. MUX PDUs can be placed in the appropriate queue (high Quality of QoS Services or unguaranteed delivery in an exemplary embodiment). If no flows are received in the decision block 1910 for the MAC ID, or after preparing the MUX PDUs in block 1920, the transition to decision block 1930 takes place.

[0172] In decision block 1930, if one or more commands from the RLC 340 or LL 330 control, for example, are to be transmitted to the UT terminal associated with the MAC ID, then proceed to block 1940 and prepare the MUX PDU for each unit PDU command. If no commands are intended for the MAC ID, or if MUX PDUs were prepared in block 1940, the transition to decision block 1950 follows.

[0173] Decision block 1950 illustrates a repetitive process for continuously controlling flows intended for

53 / 59P25695EN00 MAC ID. Alternative embodiments may include looping in any other part of the entire user terminal access point process. In an alternative embodiment, the 1900 process repeats iteratively or is included in another repetitive process. For illustration only, this process is described for a single MAC ID. It will be obvious that multiple MAC IDs can be processed simultaneously at the access point. These and other modifications will be understood by those skilled in the art.

[0174] When no commands or flows are ready for processing, in this example, the process returns in loop to decision block 1910 to repeat the loop. Note that at the user terminal, there may be a need to issue a request to the access point to initiate MAC frame allocation as described above. Any such technique can be used. Details are not included in FIG. 19. Of course, if no commands or flows are waiting for transmission, there is no need to issue any requests, and therefore no MAC frame allocation will come. When the command or flow is waiting for transmission, the scheduler may perform MAC frame allocation at any time, as described above. In the exemplary embodiment, the access point scheduler 376 performs uplink MAC frame assignments in response to MAC ID queues in UT-specific MUX 360 functions, and uplink MAC frame allocations in response to requests on the RCH channel or UT intermediate terminal queue as detailed above. In any case, the communication device implementing method 1900 is waiting for MAC frame allocation in decision block 1950.

[0175] When MAC frame allocation is made in decision block 1950, one or more MUX PDUs

One or more or any combination is placed in a single MAC PDU in block 1960. The MAC PDU may include the partial MUX PDU unit remaining from the previous MAC frame, the MUX PDU unit from one or more flows, MUX PDU command units , listed. A partial MUX PDU can be placed in a MAC frame if any allocated space remains unused (or any type of padding can be placed to fill the allocated MAC frame).

[0176] In block 1970, the MAC PDU is transmitted on the physical link at the position indicated by the allocation. Note that the MAC PDU may contain MUX PDUs with any combination of one or more flows or command PDUs.

[0177] As described in detail above, in the exemplary embodiment, the MAC PDU is a transmission unit that falls within the physical layer sequence assigned to the MAC ID on the channel either F-TCH or R-TCH. FIG. 20 illustrates an example scenario. The MAC PDU 460 includes the header MAC 462 followed by a possible partial MUX PDU 464 at the beginning, followed by zero or more full MUX PDU 466, and finally, the possible partial MUX PDU 468 at the end of the physical layer sequence. It should be noted that the corresponding parts of two successive MAC 460A and 460B frames are illustrated. The subcomponents of the MAC 460A frame, transmitted during the f frame, are identified by the attached "A". The subcomponents of the MAC 460B frame, transmitted during the f + 1 frame, are identified by the attached "B". When MUX PDUs are combined in a MAC PDU to fully utilize the allocation, a partial MUX PDU can be transmitted at the end of the MAC PDU, where the remainder of the MUX PDU is transmitted at the beginning of the MAC PDU sent in the next MAC frame. This is illustrated on

53 / 59P25695PL00

FIG. 20 by the partial MUX PDU 468A unit transmitted in the MAC 460A FRAME. The remainder of this MUX PDU 464B unit is transmitted during the next MAC 460B FRAME.

[0178] The MAC header consists of the MUX 2020 Indicator, and possibly the MAC ID 2010 associated with the MAC PDU. A MAC ID may be required when spatial multiplexing is used, and there may be more than one MAC PDU transmitted simultaneously. Experts recognize when the MAC ID 2010, shown shaded to indicate that it is optional, should be used.

[0179] In an exemplary embodiment, the 2-byte MUX 2020 indicator per MAC PDU is used to identify the location of any MUX PDUs transmitted in the MAC FRAME (as indicated by the arrow from the MUX 2020 indicator to MUX PDU 466A ba FIGs . twenty). The MUX 2020 indicator is used for each MAC PDU. The MUX indicator indicates the beginning of the first MUX PDU in the MAC PDU. The MUX indicator along with the length field contained in each MUX PDU header allows the receiving MUX layer to extract LL PDUs and RLC PDUs from the byte stream consisting of subsequent physical layer sequences from

to the assigned MAC ID. Those skilled in the art will recognize various alternative means for using indicators within the scope of the present invention. For example, the MAC frame may be packaged in an alternative order to the example described above. The remaining partial MUX PDU can be placed at the end of the MAC frame allocation, and the indicator indicates the beginning of the residue, not the new MUX PDU. Thus, new PDUs, if present, are placed first. Any number of indicator techniques (i.e. index value identifying a byte, time value, value) can be used

Base and offset, or any of many variations that will be apparent to those skilled in the art).

[0180] In an exemplary embodiment, the MUX 2020 pointer comprises a single 16-bit field whose value is one, plus an offset from the end of the MUX pointer, in bytes, of the beginning of the first MUX PDU that begins in the frame. If the value is zero, no MUX PDU unit begins in the frame. If the value is one, the MUX PDU begins immediately after the MUX Indicator. If n&gt; 1, the first n-1 bytes in the MAC PDU are the end of the MUX PDU that started in the previous frame. This information helps the MUX receiver (i.e. the MUX 360 function) fix errors in previous frames that result in a loss of synchronization with the boundaries of the MUX PDU, as an example is described below. Those skilled in the art will recognize that any number of alternative indexing techniques can be used.

[0181] The MUX header including the type field (logical channel) and the length field is appended to each LL PDU or RLC PDU provided for the MUX function. The type field (logical channel) identifies the LL or RLC unit to which the PDU belongs. The length field is used together with the MUX indicator just described to enable the receiving MUX layer to extract LL PDUs and RLC PDUs from the byte stream consisting of consecutive physical layer sequences allocated to the MAC ID.

[0182] As described in detail above, the MUX 360 function maintains 3 queues for the data to be transmitted. Queue 362 with high QoS Services may contain LL PDUs that are associated with the negotiated service to which the guaranteed transmission rate has been allocated by controlling 384 receipt of requests. The unguaranteed delivery queue 364 may contain LL PDUs that are not associated with a guaranteed baud rate.

53 / 59P25695PL00

The control message queue 366 may contain RLC units

PDU and LLC PDU.

[0183] Alternative embodiments may include more than one QoS queue. However, efficient use of high-speed WLANs as described herein allows a single QoS queue to achieve very high QoS performance. In many cases, the efficient use of available channel bandwidth by the MAC protocol means that additional queues and associated complexity are unnecessary.

[0184] At the AP, the overdue data in each of these queues are made available to the scheduler 376 in the common MAC 370 function. The overdue data in these queues at the UT is maintained at the AP in the intermediate terminal to note that

UT in a common MAC 360 function. UT proxy queues should be, for clarity, not independently identified in FIG. 3. Queues 362, 364 and 366 may be treated as containing both forward link and reverse link queues (i.e. UT Intermediate queues) for each MAC ID, regardless of whether the queues are deployed in shared equipment or in separate components. It should also be noted that the number and type of queues supported for the forward link and reverse link need not be the same. UT proxy queues do not have to be matched equally with UT queues. For example, the UT may maintain a command queue to give priority to specific time-sensitive commands within other high quality QoS PDUs. At the AP, a single high QoS Quality of Service can be used to indicate the request for both UT terminal traffic types. Thus, the allocation made for the UT may be filled with the priority specified in the UT. As another example, changing QoS queues can be held either at the UT or at the point

The function is AP access queues that are not maintained on the AP or UT, respectively.

[0185] The scheduler 376 resolves competing requirements from all MAC IDs and assigns the physical layer sequence on the F-TCH or R-TCH to one or more selected MAC IDs. In response to the allocation, the corresponding MUX 360 function packs the LL PDUs and RLC PDUs into the MAC PDU payload as described above. In the exemplary embodiment, each MUX 360 supports PDUs from the following (complete) in the following order with no pre-emption priority: queue 366 control messages, queue 362 high quality QoS Services and queue 364 unguaranteed delivery. Any partial PDU from the previous MC PDU (even if it comes from a lower priority queue) is filled first before new PDUs from higher priority queues are served. In alternative embodiments, preemption may be applied at one or more levels, as will be apparent to those skilled in the art.

[0186] At the receiver, the MUX function extracts PDUs from the byte stream consisting of successive MAC PDUs and routes them to the LL or RLC unit to which it belongs. Routing is based on the type field in the MUX PDU header.

[0187] In an exemplary embodiment, the structure of the MUX function, when the transmission of the MUX PDU unit is started, it will be terminated before the next MUX PDU unit starts. Thus, if the transmission of the MUX PDU from the non-guaranteed delivery queue began in the MAC frame, it will end in the next MAC frame (or frames) before the next MUX PDU from the control message queue or the high quality QoS Services queue is transmitted. In other words, during the logical channel) contained implementation, according to

The classes have implementation, or in normal operation, of a higher queue not disparaging priority.

[0188] In alternative examples, specific cases, in an exemplary embodiment, preemption may be desirable. For example, if the physical layer data rates have changed, it may be necessary to urgently send a control message requesting an expropriating priority in transmission within the MUX PDU with non-guaranteed delivery or high quality QoS Services. This is acceptable. An incompletely transmitted MUX PDU will be detected and rejected by the receiving MUX function, as detailed in the following. [0189] A case of expropriation (i.e., change of physical layer transmission rate) may also cause the need to change the size of the segment to be used for this UT. The segment size for the UT may be that the delay for the service with the lowest delay or control message queue is met by a non-exclusive priority in the MUX function. These techniques may be combined with the segmentation techniques described above with respect to the chosen restriction

FIG. 17-18.

[0190] FIG. 21 illustrates an example method 2100 for preparing a MAC frame using a MUX pointer. This method can be used either at the AP or at the UT. Those skilled in the art will readily adapt this illustrative example to many embodiments, an AP or UT, in the light of the present description. The process starts at block 2110, where the allocation for the MAC PDU is received.

[0191] In decision block 2120, if the partial MUX PDU remains from the previous transmission of the MAC frame, the transition to decision block 2130 occurs. If not

53 / 59P25695EN00 remains no partial MUX PDU, followed by block 2150.

[0192] In decision block 2130, if pre-emption is desired, transmitted.

partial

The unit follows

MUX

PDU will not pass

In the exemplary embodiment, in some cases pre-emption may be used to send the time-sensitive MUX PDU command. Other examples of expropriation are described in detail above. Any expropriation condition can be used when it is desirable to skip transmitting the remainder of the MUX PDU. The MAC frame receiver can simply discard earlier parts of the MUX PDU. An example receiver function is described in detail below. And an alternative embodiment, pre-emption may be specified to enable the pre-emptive partial MUX PDUs to be transmitted at a later time. Alternative embodiments may use any number of pre-emption rules for use in decision block 2130. If pre-emption is not desired, the transition to block

2150.

block 2140.

[0193] In block 2140, the partial MUX PDU is first placed in the MAC PDU. If the allocation is smaller than the partial MUX PDU, the allocation may be filled by the MUX PDU in the amount desired, and the remainder may be retained for transmission in the next MAC frame assignment.

[0194] At block 2150, any new MUX PDUs may be located in the MAC PDU. The MUX function can specify the priority for placing MUX PDUs from any of the available queues. Examples of priority schemes have been described above, although any priority scheme may be used.

[0195] In block 2160, the MUX indicator is set to the location of the first new MUX PDU. In the exemplary embodiment, a MUX indicator of zero indicates that no MUX PDU is included in the assignment. A MUX pointer of one indicates that the first byte following the MAC header is the start of the next new MUX PDU (i.e. there is no ML1X PDU partial at the beginning of the MAC PDU). Other MUX values ​​indicate an appropriate demarcation between the remaining partial MUX PDUs and the beginning of any new MUX PDUs). In alternative embodiments, other special MUX indicator values ​​may be specified, or other indicator schemes may be used.

[0196] In block 2170, if space remains in the allocated MAC PDU, the partial MUX PDU may be placed in the remainder. Alternatively, any type of filling may be used in the remaining space. The remainder of the partially placed MUX PDU can be saved for transmission in the next frame assignment.

[0197] FIG. 22 illustrates an example method 2200 of receiving a MAC frame including a MUX indicator. This method can be used either at the AP or at the UT. Those skilled in the art will readily adapt this illustrative example to many embodiments, an AP or UT, in the light of the present description.

[0198] The process starts at block 2210, where the MAC PDU is received. In block 2215, the MUX indicator is extracted from the MAC PDU. In decision block 2220, if the MUX pointer is greater than 1, then proceeds to block 2225. In the exemplary embodiment, if the MUX pointer is 0 or 1, no partial MUX PDU exists at the beginning of the MAC frame. A MUX indicator of 0 indicates that no MUX PDUs are present at all

53 / 59P25695PL00 occurs. In each case, there is a transition to decision block 2230.

[0199] In decision block 2230, if there is a partial MUX PDU saved from the previous MAC frame, proceed to block 2235 and discard the stored previous frame. The remainder of the saved frame has been expropriated in this example. Alternative embodiments may allow subsequent transmissions of the remainder of the stored frame, in which case the earlier partial MUX PDU may be retained (details are not shown in the illustrative example method 2200). If no partial MUX PDU has been retained in decision block 2230 or no subsequent servicing of the saved earlier MUX PDU has occurred, then proceeds to block 2240.

[0200] In block 2240, new MUX PDUs, if any, start recovering at the location indicated by the MUX indicator. It should be noted that in the exemplary embodiment, a MUX indicator of 0 indicates that there are no new MUX PDUs in the MAC PDU. Any new MUX PDUs can be recovered, including the new partial MUX PDU. As described above, the length field in the MUX PDU header can be used to specify the boundaries of MUX PDUs. [0201] In decision block 2245, if a partial MUX PDU has been included in the MAC PDU, it proceeds to block 2250 to preserve the partial MUX PDU. The stored partial MUX PDU may be combined with the remainder of the future MAC PDU (unless it is later determined that the partial MUX PDU should be discarded, as described above). If no new partial MUX PDU was included in the MAC PDU in decision block 2245, or if a partial

53 / 59P25695EN00 MUX PDU has been saved to block 2250, it goes to block 2255.

[0202] At block 2255, any full MUX PDUs may be provided for subsequent processing, including reassembly, as appropriate, in the protocol stack as detailed above.

[0203] As described above, the MUX function allows multiplexing of logical channels in traffic channel segments (F-TCH and R-TCH) specified in the MAC frame. In the exemplary embodiment, the logical channels multiplexed by the MUX function are identified by a 4-bit message type field in the MUX header, examples of which are described in detail in Table 1.

Table 1. Logical Channel Type fields

<td>Logical Channel</td><td>MUX Type Field (hex)</td>

<td>UDCH0</td><td>0x0</td>

<td>UDCH1</td><td>0x1</td>

<td>UDCH2</td><td>0x2</td>

<td>UDCH3</td><td>0x3</td>

<td>RBCH</td><td>0x4</td>

<td>DCCH</td><td>0x5</td>

<td>LCCH</td><td>0x6</td>

<td>UBCH</td><td>0x7</td>

<td>UMCH</td><td>0x8</td>

[0204] FIG. 23 illustrates example MUX PDUs for several types of MUX units shown in Table 1.

User data channel PDUs, UDCH0 2310, UDCH1 2320, UDCH2 2330, UDCH3 2340 can be used to transmit and receive user data. PDUs may be created as described above with reference to FIG.

4. Each PDU contains a MUX header with the type field i

53 units.

length shown. The MUX header is followed by the LL header, the 1-byte AL header, up to 4087 bytes of data, and the 3-byte CRC control. For UDCH0 2310, the LL header has 1 byte. For UDCH1 2320, the LL header has 2 bytes. For UDCH2 2330, the LL header has 3 bytes. For UDCH3 2340, the LL header has 4 bytes. The functions of the logical layer for processing these types of LL PDUs are described in detail above.

[0205] In FIG. 23, various control message PDUs 2350-2370 are also illustrated. Each PDU contains a MUX header containing a type field, reserved field, and length field. The MUX header is followed by a variable-length data field, which can contain between 4 and 255 bytes, which contains the RLC message payload. The Radio Link Broadcast Channel (RBCH) 2350 PDU, the Control Channel PDU 2360 (DCCH) and the Logical Link Control Channel (LLCH) 2370 are shown in FIG. 23. The format for the User Broadcast Channel PDU (UBCH) and for the User Group Broadcast Channel PDU (UMCH) is the same as for the PDU 2310 of the UDCH0 channel. The Type field for UBCH is set to 0111. The Type field for the UMCH channel is set to 1000.

[0206] Those skilled in the art will recognize that these PDUs are illustrative only. Various additional PDUs may also be supported, as well as subsets of the alternate embodiments, each field may have alternative widths. Other PDUs may also contain additional fields.

Radio Link Control (RLC) Example [0207] Control 340 above, and an example in detail hereinafter

A radio link has been described, the variant is described in the description part. Sample set

RLC messages are shown in Table 2. The described example messages are only an example, subsets of these messages, as well as additional messages, may be used in an alternative embodiment. These fields and field sizes in each message are also examples. Those skilled in the art will readily adapt many alternative message formats in the light of this description.

Table 2. RLC Message Types

<td>Message Type</td><td>Message</td>

<td></td><td>RLCSystemConfigurationParameters</td>

<td>0x00</td><td>RLCRegChallengeACK</td>

<td>0x01</td><td>RLCHdwrIDReq</td>

<td>0x02</td><td>RLCSystemCapabilities</td>

<td>0x04</td><td>RLCCalibrationReqACK</td>

<td>0x05</td><td>RLCRLCalibrationMeasurementResult</td>

<td>0x40</td><td>RLCRegChallengeRej</td>

<td>0x44</td><td>RLCCalibrationReqRej</td>

<td>0x80</td><td>RLCRegChallenge</td>

<td>0x81</td><td>RLCHdwrIDReqACK</td>

<td>0x82</td><td>RLCSystemCapabilitiesACK</td>

<td>0x84</td><td>RLCCalibrationReq</td>

<td>0x85</td><td>RLCCalibrationMeasurementReq</td>

<td>0x87</td><td>RLCUTLinkStatus</td>

<td>0xc5</td><td>RLCRLCalibrationMeasurementResultNACK</td>

[0208] In this example, all RLC messages have a common structure, although they can be carried on one of several transport channels. The structure of the RLC PDU includes an 8-bit Type field that identifies a specific RLC message, a payload of 0 to 251 bytes, and a CRC control field of 3 bytes. Table 3 illustrates the use of bit positions in a type field to indicate specific RLC message classes. The most-significant bit (MSB) indicates the link message

Forward or reverse link, 0 or 1, respectively. When the second MSB is set, the message is an NACK message or a reject message.

Table 3. Meaning of Bit Position in the RLC Message Type Field

<td>Bit position</td><td>Importance</td>

<td>0ΧΧΧΧΧΧΧ</td><td>Forward Link Message</td>

<td>1xxxxxxx</td><td>Reverse Link Message</td>

<td>x1xxxxxx</td><td>Message NACK / Reg</td>

[0209] During system initialization, an RLC Broadcast function may be initiated, including the System Identification Control function 346. When the UT initially accesses the system using the MAC-ID from the access pool, the RLC function assigns a new unicast MAC-ID to the UT. Then, if the UT joins the multicast group, it may be assigned additional MAC-IDs. When a new unicast MAC-ID is assigned to the UT, the RLC control initiates one instance for each of the functions: AC 344, RRC 342 and LLC 338, as described above. When a new multicast MAC-ID is assigned, the RLC control initiates a new AC function instance and LLC control for the LL link multicast mode.

[0210] The System Identification Parameters message shown in Table 4 is transmitted by the AP once every 16 MAC frames using the broadcast MAC ID. The System Identification Parameters message contains the IDs of the network and AP, as well as the protocol version number. In addition, the message contains a list of MAC-ID access IDs for use by UT terminals for initial access to

53 / 59P25695EN00 system. Other sample parameters are shown in the Table

4.

Table 4. Message of System Identification Parameters in a channel

RBCH

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>RLC Message Type</td><td> 8</td><td>0x3F</td>

<td>Net ID</td><td> 10</td><td>Network ID</td>

<td>AP ID</td><td> 6</td><td>Point ID access</td>

<td>Pilot Cover Code</td><td> 4</td><td>Pilot's Walsh code index</td>

<td>Level of Reduction (Backoff Level)</td><td> 4</td><td>The scheme used power reduction (one of 16 possible)</td>

<td>AP Rev. Level</td><td> 4</td><td>AP version software level and system capabilities</td>

<td>RCH channel reduction (RCH Backoff)</td><td> 4</td><td>Random ratio reduction of the RCH channel</td>

<td>Neighbors list</td><td> 120</td><td>ID and Assignment Neighbor frequencies Access Point</td>

<td>Pool of IDs access</td><td> 4</td><td>Access ID pool</td>

<td>Message Length</td><td> 164</td><td></td>

[0211] The Association Control Function (AC) provides UT authentication. The AC function manages the registration functions (i.e. add / remove) for the UT terminal. For the MAC-Multicast ID, the AC function manages the addition / removal of a UT from the multicast group. The AC function also manages the exchange of keys for encryption for controlling the LL link.

[0212] The Request for Registration message, shown in Table 5, is sent on the reverse link from the UT. The UT terminal contains a 24-bit random number to enable the AP to distinguish multiple UTs that

53 / 59P25695EN00 could simultaneously access and download the same MAC-ID.

Table 5. Registration request message

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>RLC Message Type</td><td> 8</td><td>0x80</td>

<td>MAC ID</td><td> 10</td><td>Temporary MAC ID ID assigned to the UT terminal</td>

<td>Random ID</td><td> 24</td><td>Random call to differentiate access: collisions</td>

<td>Reserved</td><td> 6</td><td>Future usage</td>

<td>CRC</td><td> 24</td><td>Cyclic redundancy check</td>

<td>Message Length</td><td> 72</td><td></td>

[0213] The Request for Registration Confirmation message, shown in Table 6, is transmitted by the AP in response to the Request for Registration Message. The AP opens the Random ID that was sent by the UT. This allows for collision resolution between UT terminals that may have downloaded the same MAC-ID and slot for access.

Table 6. Confirmation request for registration message

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>RLC Message Type</td><td> 8</td><td>0x00</td>

<td>MAC ID</td><td> 10</td><td>Temporary MAC ID assigned to the UT terminal</td>

<td>Random ID</td><td> 24</td><td>Random call to distinguish between access collisions</td>

<td>Reserved</td><td> 6</td><td>Reserved for future use</td>

<td>CRC</td><td> 24</td><td>Cyclic redundancy check</td>

<td>Message Length</td><td> 72</td><td>9 bytes</td>

[0214] The Registration Request Rejection message shown in Table 7 is sent by the AP to the UT to reject the temporary allocation of the MAC ID, for example when two or more

UTs randomly selects the same temporary MAC ID.

Table 7. Rejection request for registration message

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>RLC Message Type</td><td> 8</td><td>0x40</td>

<td>MAC ID</td><td> 10</td><td>Temporary MAC ID assigned to the UT terminal</td>

<td>Reserved</td><td> 6</td><td>Future Use</td>

<td>CRC</td><td> 24</td><td>Cyclic redundancy check</td>

<td>Message Length</td><td> 48</td><td>6 bytes</td>

[0215] The Equipment ID Request Message, shown in Table 8, is transmitted by the AP to obtain the Equipment ID from the UT.

Table 8. Hardware ID Request Message

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>RLC Message Type</td><td> 8</td><td>0x01</td>

<td>MAC ID</td><td> 10</td><td>Temporary MAC ID assigned to the UT terminal</td>

<td>Reserved</td><td> 6</td><td>Future Use</td>

<td>CRC</td><td> 24</td><td>Cyclic redundancy check</td>

<td>Message Length</td><td> 48</td><td>6 bytes</td>

[0216] The Equipment ID Request Confirmation message, shown in Table 9, is transmitted by the UT in response to the Equipment ID Identifier Request Message and contains the 48-bit Equipment ID of the UT Terminal. (In particular, the 48-bit IEEE MAC Address of the UT terminal may be used).

Table 9. Confirmation Message Request for Equipment ID

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>RLC Message Type</td><td> 8</td><td>0x81</td>

53 / 59P25695PL00

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>MAC ID</td><td> 10</td><td>Temporary MAC ID assigned to the UT terminal</td>

<td>Equipment ID</td><td> 48</td><td>Equipment ID number UT terminal</td>

<td>Reserved</td><td> 6</td><td>Future Use</td>

<td>CRC</td><td> 24</td><td>Cyclic redundancy check</td>

<td>Message Length</td><td> 96</td><td>12 bytes</td>

[0217] The System Capability message, shown in Table 10, is transmitted to the newly registered UT to indicate to the UT the capabilities of the access point.

AP.

Table 10. System Capability message

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>RLC Message Type</td><td> 8</td><td>0x02</td>

<td>MAC ID</td><td> 10</td><td>Temporary MAC ID assigned to the UT terminal</td>

<td>nant</td><td> 2</td><td>Number of access point antennas. AP</td>

<td>Nal</td><td> 8</td><td>The number of supported adaptation layers</td>

<td>LISTal</td><td>8 * Nal</td><td>List of adaptation layer indexes supported by the AP</td>

<td>tbd</td><td></td><td></td>

<td>tbd</td><td></td><td></td>

<td>Reserved</td><td> 4</td><td>Future Use</td>

<td>CRC</td><td> 24</td><td>Cyclic redundancy check</td>

<td>Message Length</td><td>Variables</td><td>Variable number of bytes</td>

[0218] The System Capability Confirmation message, shown in Table 11, is transmitted by the UT in response to the System Capability Message to indicate to the UT the capabilities of the AP.

Table 11. System Capability confirmation message

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>RLC Message Type</td><td> 8</td><td>0x82</td>

<td>MAC ID</td><td> 10</td><td>Temporary MAC ID ID assigned to the UT terminal</td>

53 / 59P25695PL00

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>nant</td><td> 2</td><td>Number of UT antennas</td>

<td>Nal</td><td> 8</td><td>The number of supported adaptation layers</td>

<td>LISTal</td><td>8 * Nal</td><td>List of layer indexes adaptive devices supported by the AP and UT terminal</td>

<td>Reserved</td><td> 4</td><td>Future Use</td>

<td>CRC</td><td> 24</td><td>Cyclic redundancy check</td>

<td>Message Length</td><td>Variables</td><td>Variable number of bytes</td>

[0219] One RRC Radio Resource Control instance is initialized at each UT. One RRC control instance per active UT is initialized at the AP. The RRC control functions at the AP and UT can share downlink and uplink channel measurements (as needed). RRC control manages the calibration of send and receive chains at the AP and UT. In this example, calibration is useful for spatial multiplexing transmission mode.

[0220] The RRC control determines the transmission mode, the rate control for transmission to the terminal provides it to the MAC Scheduler. RRC control determines the periodicity and length of the dedicated MIMO pilot required for physical layer sequence (PHY) transmission on the R-TCH, and (if necessary) on the F-TCH. The RRC control manages the power control for transmission in the Time-Spatial Transmission Diversification (STTD) mode to and from the UT terminal and delivers it to the PHY Manager. The RRC control determines the timing matching for R-TCH transmission from the UT.

[0221] Calibration Request message, shown in the Table

12, is transmitted through a calibration request point with the UT terminal and

UT and AP access to the Calibration Type field (CalType) indicates the set of calibration tones, number of symbols

Calibrations per antenna that will be used for the calibration procedure.

Table 12. Calibration Request message

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>RLC Message Type</td><td> 8</td><td>0x84</td>

<td>MAC ID</td><td> 10</td><td>Temporary MAC ID ID assigned to the UT terminal</td>

<td>nant</td><td> 2</td><td>Liczbaanten UT terminal</td>

<td>Calibration Type (CalType)</td><td> 4</td><td>Selects the procedure calibration</td>

<td>Reserved</td><td> 4</td><td>Future Use</td>

<td>CRC</td><td> 24</td><td>Cyclical control redundant</td>

<td>Message Length</td><td> 56</td><td>6 bytes</td>

[0222] Calibration type (CalType) values ​​are illustrated in Table 13. Each calibration type corresponds to a set of OFDM tones and the number of calibration symbols per antenna that are required for calibration. The Calibration Pilot symbols use Walsh sequences to achieve orthogonality among Tx transmit antennas.

Table 13. Calibration Type values

<td>Calibration Type Value</td><td>Calibration tones</td><td>Number of Calibration Pilot Symbols</td>

<td> 0000</td><td> ±7, ±21</td><td> 4</td>

<td> 0001</td><td> ±3, ±7, ±11, ±15, ±18, ±21, ±24, ±26</td><td> 4</td>

<td> 0010</td><td> ±1 ,±2, ..., ±25, ±26</td><td> 4</td>

<td> 0011</td><td>RSVD</td><td> 4</td>

<td> 0100</td><td> ±7, ±21</td><td> 8</td>

<td> 0101</td><td> ±3, ±7, ±11, ±15, ±18, ±21, ±24, ±26</td><td> 8</td>

<td> 0110</td><td> ±1 ,±2, ..., ±25, ±26</td><td> 8</td>

<td> 0111</td><td>RSVD</td><td> 8</td>

<td> 1000</td><td> ±7, ±21</td><td> 16</td>

53 / 59P25695PL00

<td>Calibration Type Value</td><td>Calibration tones</td><td>Number of Calibration Pilot Symbols</td>

<td> 1001</td><td> ±3, ±7, ±11, ±15, ±18, ±21, ±24, ±26</td><td> 16</td>

<td> 1010</td><td> ±1 ,±2, ..., ±25, ±26</td><td> 16</td>

<td> 1011</td><td>RSVD</td><td> 16</td>

<td> 1100</td><td> ±7, ±21</td><td> 32</td>

<td> 1101</td><td> ±3, ±7, ±11, ±15, ±18, ±21, ±24, ±26</td><td> 32</td>

<td> 1110</td><td> ±1 ,±2, ..., ±25, ±26</td><td> 32</td>

<td> 1111</td><td>RSVD</td><td> 32</td>

[0223] The Calibration Request Rejection message, shown in Table 14, is sent by the UT to reject the Calibration Request from the AP.

Table 14. Calibration Request Rejection Message

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>RLC Message Type</td><td> 8</td><td>0x44</td>

<td>MAC ID</td><td> 10</td><td>Temporary MAC ID assigned to the UT terminal</td>

<td>Reserved</td><td> 6</td><td>Future Use</td>

<td>CRC</td><td> 24</td><td>Cyclic redundancy check</td>

<td>Message Length</td><td> 48</td><td>6 bytes</td>

[0224] A Calibration Measurement Request message, shown in Table 15, is sent by the UT to the AP. Contains Calibration Pilot symbols that will be used by the AP to measure the channel between the UT and the AP.

Table 15. Calibration Measurement Request Message

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>RLC Message Type</td><td> 8</td><td>0x85</td>

<td>MAC ID</td><td> 10</td><td>Temporary MAC ID assigned to the UT terminal</td>

<td>Calibration Type (CalType)</td><td> 4</td><td>Calibration procedure</td>

53 / 59P25695PL00

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>Baud rate</td><td> 4</td><td>Highest speed supported broadcasts combine FL in diversification mode</td>

<td>Reserved</td><td> 6</td><td>Future Use</td>

<td>CRC</td><td> 24</td><td>Cyclic redundancy check</td>

<td>Message Length</td><td> 56</td><td>7 bytes</td>

[0225] The Calibration Result Message, shown in Table 16, is sent by the AP to provide to the UT the results of the channel measurement completed by the AP, carried out on the calibration symbols transmitted by the UT in the Calibration Request message.

[0226] In this example, each Calibration Result message carries channel response values ​​for 4 tones for a 4x4 channel, up to 8 tones for a 2x2 channel or up to 16 tones for a 1x4 channel. Up to 13 such messages may be required to transfer all measurement data for a 4x4 channel with 52 measured tones, so the sequence number is also used to track the sequence of such messages. In cases where there is not enough data to fill the entire data field, the unused portion of the data field will be set to all zeros.

Table 16. Calibration Measurement Message

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>RLC Message Type</td><td> 8</td><td>0x05</td>

<td>MAC ID</td><td> 10</td><td>Temporary MAC ID ID assigned to the UT terminal</td>

<td>SEQ</td><td> 4</td><td>Message sequence number (up to 13 messages)</td>

<td>Data field</td><td> 1536</td><td>Channel response values ​​for 4 tones</td>

<td>Reserved</td><td> 2</td><td>Future Use</td>

<td>CRC</td><td> 24</td><td>Cyclic redundancy check</td>

<td>Message Length</td><td> 1584</td><td>198 bytes</td>

[0227] A Calibration Measurement Result Confirmation message, shown in Table 17, is sent to confirm fragments of a Calibration Measurement result message.

Table 17. Calibration Measurement Confirmation Message

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>RLC Message Type</td><td> 8</td><td>0x04</td>

<td>MAC ID</td><td> 10</td><td>Temporary MAC ID assigned to the UT terminal</td>

<td>SEQ</td><td> 4</td><td>Confirmed sequence number messages</td>

<td>Reserved</td><td> 2</td><td>Future Use</td>

<td>CRC</td><td> 24</td><td>Cyclic redundancy check</td>

<td>Message Length</td><td> 48</td><td>6 bytes</td>

[0228] Similarly, a Calibration Result Message may not be confirmed, in which case the Negative Confirmation Message (NACK) of the Calibration Measurement Result, as shown in Table 18, may be sent on the reverse link to negatively confirm (NACK) portions of the message Result of the Measurement calibration.

Table 18. Negative Confirmation Message (NACK) Calibration Measurement Result

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>RLC Message Type</td><td> 8</td><td>0xc5</td>

<td>MAC ID</td><td> 10</td><td>Temporary MAC ID assigned to the UT terminal</td>

<td>MODE</td><td> 1</td><td>Negative confirmation mode (NACK) (0 = return-N; 1 = selective repetition)</td>

<td>SEQ</td><td> 16</td><td>Sequence numbers for up to 4 messages with negative confirmation</td>

<td>Reserved</td><td> 5</td><td>Future Use</td>

<td>CRC</td><td> 24</td><td>Cyclic redundancy check</td>

<td>Message Length</td><td> 64</td><td>8 bytes</td>

[0229] Calibration Measurement Result messages can be negatively confirmed either on a back-N or selective repetition basis. The SEQ field consists of consecutive four-bit segments, each representing a message sequence number. For return-N mode, the MODE bit is set to 0, and the first segment of the SEQ field indicates the sequence number of the first message in the sequence that must be repeated. In this case, the remaining 12 bits in the SEQ field are set to 0 and ignored. For the selective repetition mode, the MODE bit is set to 1, and the SEQ field holds sequence numbers for up to four messages that must be repeated. If less than four messages need to be repeated, only the segment containing non-zero values ​​matters. All segments filled with all zeros are ignored.

[0230] The UT Link State Message, shown in Table 19, is sent by the AP to request UT to provide feedback. In this example, the UT must provide feedback for the buffer status (backlog data and QoS class) as well as for link quality (downlink rate that can be maintained for MIMO and control channel).

Table 19. Message about the UT Terminal Link Status

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>RLC Message Type</td><td> 8</td><td>0x87</td>

<td>MAC ID</td><td> 10</td><td>Temporary MAC ID assigned to the UT terminal</td>

<td>UT BUF STAT</td><td> 16</td><td>Indicates the state of the Radio Link buffer UT terminal</td>

<td>FL RATE STAT</td><td> 16</td><td>Maximum speed supported FL uplink transmission per mode (tbd values)</td>

<td>QOS FLAG</td><td> 2</td><td>Indicates that the RL reverse link contains high priority data</td>

<td>CCH SUB CHAN</td><td> 2</td><td>Indicates the preferred channel subchannel CCH</td>

53 / 59P25695PL00

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>Reserved</td><td> 2</td><td>Future Use</td>

<td>CRC</td><td> 24</td><td>Cyclic redundancy check</td>

<td>Message Length</td><td> 80</td><td>10 bytes</td>

[0231] The UT_BUF_STAT parameter indicates the size of the UT Radio Link buffer in 4-byte increments. A value of 0xFFFF indicates a buffer size greater than or equal to 262140 bytes. The FL_RATE_STAT parameter represents the maximum forward link transmission rate per mode with four bits per mode. For the diversification mode, only the four most significant bits are used. The other twelve bits are set to 0. The QOS_FLAG parameter indicates whether the reverse link buffer contains high priority data. The values ​​of the QOS_FLAG parameter are defined in Table 20.

Table 20. Values ​​of the QOS_FLAG parameter

<td>Value</td><td>Importance</td>

<td> 00</td><td>No priority data</td>

<td> 01</td><td>Priority data</td>

<td> 10-11</td><td>Reserved</td>

[0232] At the UT, the Link Status Message of the UT is created by the RRC control. At the AP, it is passed to the RRC control, which provides values ​​to the UT intermediate terminal.

[0233] The exemplary embodiment of RRC control described in this chapter may be used in conjunction with the various embodiments described in detail herein. Those skilled in the art will recognize that this exemplary embodiment is for illustration only and many alternative embodiments will be apparent from the present description. In the next chapter, an example variant is described

A control channel embodiment suitable for use in connection with the various embodiments described herein.

Exemplary Control Channel (CCH) [0234] As described above, MAC frame access and resource assignment are controlled using a control channel (CCH), which assigns resources to MAC IDs on the F-TCH and R-TCH based on instructions from planning program. These resource assignments can be a response to the known state of one or more queues at an AP associated with a specific MAC ID, or the known state of one or more queues at a UT associated with a MAC ID, which is reflected in the information at the specified Intermediary Terminal UT. Resource grants may also be a response to an access request received on an Access Request Channel (ARCH), or some other stimulus or information available to a scheduler. An example of an embodiment of the CCH channel is described in detail below. This example serves as an illustration of various mechanisms that can be used in high performance WLANs as described above. Alternative embodiments may include additional functionality as well as subsets of the functions described below. The field names, field widths, parameter values, etc. described below are for illustration only. Those skilled in the art will readily adapt the principles described to many alternative embodiments within the scope of the present invention.

[0235] An exemplary CCH channel consists of 4 separate subchannels, each of which operates at a different data rate, as indicated in Table 21. The names used in Table 21 are well known in the art (SNR means control CCH channel,

Signal to Noise Ratio, and FER stands for Forward

53 / 59P25695PL00

Error Rate, also well known in the art). The CCH channel uses short OFDM symbols in combination with the STTD mode. This means that each of the logical channels consists of an even number of short OFDM symbols. Messages sent on the Reverse Access Channel (RFCH) and the Frame Control Channel (FCCH) are formatted into Information Elements (IE) and are transmitted in one of the subchannels of the CCH channel.

Table 21. Structure of Data Transmission Rate for CCH Logical Channels

<td>Channel CCH</td><td>Performance (Bps / Hz)</td><td>Correction factor (Code rate)</td><td>Modulation</td><td>beaten information per STDD OFDM symbol</td><td>Total SNR for 1% FER</td>

<td>CCH 0</td><td> 0,25</td><td> 0,25</td><td>BPSK</td><td> 24</td><td>-0.2 dB</td>

<td>CCH 1</td><td> 0,5</td><td> 0,5</td><td>BPSK</td><td> 48</td><td>2.0 dB</td>

<td>CCH 2</td><td> 1</td><td> 0,5</td><td>QPSK</td><td> 96</td><td>5.0 dB</td>

<td>CCH 3</td><td> 2</td><td> 0,5</td><td>16 QAM</td><td> 192</td><td>11.0 dB</td>

[0236] The BCCH indicates the presence or absence of a given CCH subchannel in the CCH_MASK parameter. The format for each CCH subchannel (where N is the subchannel suffix 0 - 3) is shown below in Table 22. The format contains fields indicating the number of IE elements, IE elements themselves, CRC control, zero padding if necessary, and end bits. The AP indicates which subchannel to use for each IE element. Types of IE elements that are specific to the user terminal (UT) are transmitted in the CCH subchannel, which maximizes the transmission performance for this UT. If the AP is not able to accurately determine the transmission rate associated with the UT, the CCH_0 channel may be used. IE element types broadcast / multicast are transmitted on the CCH_0 channel.

53 / 59P25695PL00

Table 22. Structure of the CCH Subchannel

<td>CCH N fields</td><td>beaten</td>

<td>The number of IE elements of the CCH N subchannel</td><td> 8</td>

<td>IE elements of the CCH N subchannel</td><td>Variables</td>

<td>CRC control for the CCH N subchannel</td><td> 16</td>

<td>Zero filling</td><td>Variables</td>

<td>Final part</td><td> 6</td>

the CCH subchannel. The UT transmitted terminals take up the CCH channel. [0237] The CCH channels are transmitted in order from the lowest to the highest transmission rate. CRC control is provided for everyone. All attempts to demodulate each starting from the CCH channel with the lowest bit rate. Lack of correct decoding of CCH_N channel causes that CCH channels with higher transmission speed will be decoded incorrectly. Each CCH subchannel has the ability to transmit a maximum of 32 IE elements.

[0238] The CCH transport channel is mapped to two logical channels. The RFCH channel contains confirmations for access attempts received on the RCH channel. The FCCH includes resource allocation (i.e., physical layer frame allocations on the F-TCH and R-TCH), physical layer control functions including controlling the physical layer data rate on the F-TCH and R-TCH, inserting a dedicated RTCH channel pilot , R-TCH timing and RTCH power control. The FCCH may also include an R-TCH assignment to request the UT to update the buffer and link status.

[0239] Basically, in this embodiment, the information sent on the CCH is critically time-dependent and will be used by the recipient in the current MAC frame.

[0240] Table 23 lists the types of CCH channel information elements together with the values ​​corresponding to these types. Information item formats are in detail

53 / 59P25695EN00 described later below. In the following tables, all offset values ​​are given in units of 800 nanoseconds.

Table 23. CCH IE Type Element Assignments

<td>IE element type</td><td>Information Item</td>

<td>0x0</td><td>RegistrationReqACK</td>

<td>0x1</td><td>FwdDivModeAssign</td>

<td>0x2</td><td>FwdDivModeAssignStat</td>

<td>0x3</td><td>FwdSpaModeAssign</td>

<td>0x4</td><td>FwdSpaModeAssignStat</td>

<td>0x5</td><td>RevDivModeAssign</td>

<td>0x6</td><td>RevSpaModeAssign</td>

<td>0x7</td><td>DivModeAssign</td>

<td>0x8</td><td>SpaModeAssign</td>

<td>0x9</td><td>LinkStatusReq</td>

<td>0xA</td><td>CalRequestAck</td>

<td>0XB</td><td>CalRequestRej</td>

[0241] The format of the IE Registration Request Confirmation (RFCH) element (designated in Registration 23 as RegistrationReqACK) is shown in Table 24. The Registration Request Confirmation is used to respond to the Registration Request from the UT received on the RCH. The format includes the IE element type, slot ID, access ID that was selected by the UT and included in its Registration Request, MAC ID assigned to the UT, and timing advance.

Table 24. IE Element Confirmation Registration Request

<td>Field</td><td>beaten</td><td>Function</td>

<td>TYPE IE</td><td> 4</td><td>0x0</td>

<td>SLOT ID</td><td> 5</td><td>The slot ID used by the UT in RCH Access</td>

<td>ACCESS ID</td><td> 10</td><td>Access ID used through the UT terminal</td>

53 / 59P25695PL00

<td>Field</td><td>beaten</td><td>Function</td>

<td>MAC ID</td><td> 10</td><td>Temporary MAC ID assigned to the UT terminal</td>

<td>REV TIMING ADV</td><td> 7</td><td>Advance of TX transmission timing R-TCH in samples</td>

<td>Together</td><td> 36</td><td></td>

[0242] The format of the IE element of the F-TCH Channel Assignment (FCCH) (designated in Table 23 as FwdDivModeAssign) is shown in Table 25. The assignment of the F-TCH Channel Diversification Mode is used to indicate that the MAC PDU will be transmitted in F-TCH channel, using the diversification mode. Diversification is another name that includes the STTD mode. The format includes the IE element type, MAC ID, F-TCH channel offset identifying the position of the MAC PDU in the MAC frame, the baud rate used, the number of OFDM symbols in the packet, the preamble type (described in detail below) and the number of short OFDM symbols in the packet .

Table 25. Element IE Assigning Diversification Mode to the F-TCH channel

<td>Field</td><td>beaten</td><td>Function</td>

<td>TYPE IE</td><td> 4</td><td>0x1</td>

<td>MAC ID</td><td> 10</td><td>MAC ID assigned to UT terminal</td>

<td>FWD OFFSET</td><td> 12</td><td>F-TCH channel offset</td>

<td>FWD RATE</td><td> 4</td><td>Transmission speed in the F-TCH channel</td>

<td>FWD PREAMBLE</td><td> 2</td><td>F-TCH preamble type</td>

<td>FWD N LONG</td><td> 7</td><td>Number of OFDM Long Symbols in package</td>

<td>FWD N SHORT</td><td> 2</td><td>Number of OFDM Short Symbols in package</td>

<td>Together</td><td> 41</td><td></td>

[0243] Format of IE element Assigning Diversification Mode to F-TCH Channel with R-TCH Channel Status (FCCH) (marked in

Table 23 as FwdDivModeAssignStat) is presented in

53 / 59P25695PL00

Table 26. This IE element is used to indicate that the MAC PDU will be transmitted on the F-TCH, using the diversification mode, and allocates space on the R-TCH for response to a state request. The format includes fields for the FwdDivModeAssign element. In addition, the format includes an allocation offset for the UT to report its buffer state on the R-TCH. The allocation for Link State messages on the R-TCH channel specifies the preamble type of the R-TCH channel and the return parameters including transmission rate, timing matching, status message request bit and the number of long and short OFDM symbols in the link state packet.

Table 26. Element IE Assigning Diversification Mode to the F-TCH channel with the R-TCH Channel Status

<td>Field</td><td>beaten</td><td>Function</td>

<td>TYPE IE</td><td> 4</td><td>0x2</td>

<td>MAC ID</td><td> 10</td><td>MAC ID assigned to the UT terminal</td>

<td>FWD OFFSET</td><td> 12</td><td>F-TCH channel offset</td>

<td>FWD RATE</td><td> 4</td><td>Transmission speed in the F-TCH channel</td>

<td>FWD N LONG</td><td> 7</td><td>Number of Long OFDM Symbols in the package</td>

<td>FWD PREAMBLE</td><td> 2</td><td>F-TCH preamble type</td>

<td>FWD N SHORT</td><td> 2</td><td>Number of OFDM Short Symbols in package</td>

<td>REV OFFSET</td><td> 12</td><td>R-TCH channel offset</td>

<td>REV PREAMBLE</td><td> 2</td><td>R-TCH Channel Preamble Type</td>

<td>REV RATE</td><td> 4</td><td>Transmission rate in the R-TCH channel</td>

<td>REV TIMING</td><td> 2</td><td>RTCH channel timing adjustment</td>

<td>REV STATUS REQ</td><td> 1</td><td>R-TCH Status Message Request</td>

<td>REV N LONG</td><td> 7</td><td>Number of OFDM Long Symbols in Link State packet</td>

<td>REV N SHORT</td><td> 2</td><td>Number of OFDM Short Symbols in Link State packet</td>

<td>Together</td><td> 71</td><td></td>

[0244] The FWD_PREAMBLE and REV_PREAMBLE fields indicate, respectively, the preamble length to be used on the forward link and the status message sent on the reverse link. The preamble consists of a specific number of short OFDM symbols, shown in Table 27, transferring the controlled reference only for the main own mode.

Table 27. FWD_PREAMBLE, REV-PREAMBLE field values

<td>Value</td><td>Importance</td>

<td> 00</td><td>No preamble</td>

<td> 01</td><td>Four symbols</td>

<td> 10</td><td>Eight symbols</td>

<td> 11</td><td>Reserved</td>

[0245] The format of the IE element Assigning Spatial Multiplexing Mode to the F-TCH (FCCH) Channel (designated in Table 23 as FwdSpaModeAssign) is shown in Table 28. The fields for this IE element are similar to the fields for the FwdDivModeAssign element, except instead of diversification, spatial multiplexing is used.

Table 28. Element IE Assigning Spatial Multiplexing Mode to an F-TCH channel

<td>Field</td><td>beaten</td><td>Function</td>

<td>TYPE IE</td><td> 4</td><td>0x3</td>

<td>MAC ID</td><td> 10</td><td>MAC ID assigned to UT terminal</td>

<td>FWD OFFSET</td><td> 12</td><td>F-TCH channel offset</td>

<td>FWD RATE</td><td> 16</td><td>Transmission rate for 0-3 spatial modes F-TCH</td>

<td>FWD PREAMBLE</td><td> 2</td><td>F-TCH preamble type</td>

<td>FWD N LONG</td><td> 7</td><td>Number of Long OFDM Symbols in the package</td>

<td>FWD N SHORT</td><td> 2</td><td>The number of Short OFDM Symbols in the package</td>

<td>Together</td><td> 53</td><td></td>

[0246] The format of the IE element Assigning Spatial Multiplexing Mode to an F-TCH Channel with the R-TCH Channel Status (FCCH) (designated in Table 23 as FwdSpaModeAssignStat) is shown in Table 29. The fields for this IE element are similar to fields for the FwdDivModeAssign element, except that spatial multiplexing is used instead of diversification.

Table 29. Element IE Assigning Spatial Multiplexing Mode to an F-TCH channel with R-TCH Channel Status

<td>Field</td><td>beaten</td><td>Function</td>

<td>TYPE IE</td><td> 4</td><td>0x4</td>

<td>MAC ID</td><td> 10</td><td>MAC ID assigned to UT terminal</td>

<td>FWD OFFSET</td><td> 12</td><td>F-TCH channel offset</td>

<td>FWD RATE</td><td> 16</td><td>Transmission rate for 0-3 spatial modes F-TCH</td>

<td>FWD PREAMBLE</td><td> 2</td><td>F-TCH preamble type</td>

<td>FWD N LONG</td><td> 7</td><td>Number of Long OFDM Symbols in the package</td>

<td>FWD N SHORT</td><td> 2</td><td>The number of Short OFDM Symbols in the package</td>

<td>REV OFFSET</td><td> 12</td><td>R-TCH channel offset</td>

<td>REV PREAMBLE</td><td> 2</td><td>R-TCH Channel Preamble Type</td>

<td>REV RATE</td><td> 4</td><td>Transmission rate in the R-TCH channel</td>

<td>REV TIMING</td><td> 2</td><td>Timing adjustment for transmission R-TCH channel</td>

<td>REV STATUS REQ</td><td> 1</td><td>R-TCH Status Message Request</td>

<td>REV N LONG</td><td> 7</td><td>Number of Long OFDM Symbols in the Link State packet</td>

<td>REV N SHORT</td><td> 2</td><td>Number of Short OFDM Symbols in the Link State packet</td>

<td>Together</td><td> 83</td><td></td>

[0247] The format of the IE element of the Assignment of Diversification Mode to the R-TCH (FCCH) channel (designated in Table 23 as RevDivModeAssign) is shown in Table 30. This IE element is used to signal RTCH channel assignment for the MAC PDU, using the diversification mode . This IE element contains the type field and MAC ID as before. It also contains fields

Uplink included in the status request messages described in detail above (FwdDivModeAssignStat and FwdSpaModeAssignStat). It also contains a reverse power control field.

Table 30. Element IE Assigning Diversification Mode to the R-TCH channel

<td>Field</td><td>beaten</td><td>Function</td>

<td>TYPE IE</td><td> 4</td><td>0x5</td>

<td>MAC ID</td><td> 10</td><td>MAC ID assigned to UT terminal</td>

<td>REV OFFSET</td><td> 12</td><td>R-TCH channel offset</td>

<td>REV PREAMBLE</td><td> 2</td><td>R-TCH Channel Preamble Type</td>

<td>REV RATE</td><td> 4</td><td>Transmission rate in the R-TCH channel</td>

<td>REV TIMING</td><td> 2</td><td>Timing adjustment for TX transmissions R-TCH channel</td>

<td>REV STATUS REQ</td><td> 1</td><td>R-TCH Status Message Request</td>

<td>REV N LONG</td><td> 7</td><td>Number of Long OFDM Symbols in the package</td>

<td>REV N SHORT</td><td> 2</td><td>The number of Short OFDM Symbols in the package</td>

<td>REV POWER</td><td> 2</td><td>TX Transmission Power Control in the channel R-TCH</td>

<td>Together</td><td> 46</td><td></td>

[0248] The format of the IE element of Assigning Spatial Multiplexing Mode to the R-TCH (FCCH) Channel (designated in Table 23 as RevSpaModeAssign) is shown in Table 31. The fields for this IE element are similar to the fields for the RevDivModeAssign element, except that instead of diversification, spatial multiplexing is used.

Table 31. Element IE Assigning Spatial Multiplexing Mode to the R-TCH channel

<td>Field</td><td>beaten</td><td>Function</td>

<td>TYPE IE</td><td> 4</td><td>0x6</td>

<td>MAC ID</td><td> 10</td><td>MAC ID assigned to UT terminal</td>

<td>REV OFFSET</td><td> 12</td><td>R-TCH channel offset</td>

<td>REV PREAMBLE</td><td> 2</td><td>R-TCH preamble type</td>

53 / 59P25695PL00

<td>Field</td><td>beaten</td><td>Function</td>

<td>REV RATE</td><td> 16</td><td>Transmission rate in the R-TCH channel</td>

<td>REV TIMING</td><td> 2</td><td>Timing Adjustment for TX Transmission of the R-TCH</td>

<td>REV STATUS REQ</td><td> 1</td><td>R-TCH Status Message Request</td>

<td>REV N LONG</td><td> 7</td><td>Number of Long OFDM Symbols in the package</td>

<td>REV N SHORT</td><td> 2</td><td>The number of Short OFDM Symbols in the package</td>

<td>REV POWER</td><td> 2</td><td>TX Transmission Power Control in the channel R-TCH</td>

<td>Together</td><td> 58</td><td></td>

[0249] The format of the IE element of the TCH (FCCH) Diversification Mode Assignment (denoted DivModeAssign in Table 23) is shown in Table 32. This IE element is used to allocate MAC PDUs on both the forward and reverse link. The fields for this IE element are a combination of fields for the FwdDivModeAssign and RevDivModeAssign elements.

Table 32. Element IE Assigning Diversification Mode to the TCH channel

<td>Field</td><td>beaten</td><td>Function</td>

<td>TYPE IE</td><td> 4</td><td>0x7</td>

<td>MAC ID</td><td> 10</td><td>MAC ID assigned to UT terminal</td>

<td>FWD OFFSET</td><td> 12</td><td>FCH channel offset</td>

<td>FWD PREAMBLE</td><td> 2</td><td>F-TCH preamble type</td>

<td>FWD RATE</td><td> 4</td><td>Transmission speed in the F-TCH channel</td>

<td>FWD N LONG</td><td> 7</td><td>Number of Long OFDM Symbols in the package</td>

<td>FWD N SHORT</td><td> 2</td><td>The number of Short OFDM Symbols in the package</td>

<td>REV OFFSET</td><td> 12</td><td>R-TCH channel offset</td>

<td>REV PREAMBLE</td><td> 2</td><td>R-TCH preamble type</td>

<td>REV RATE</td><td> 4</td><td>Transmission rate in the R-TCH channel</td>

<td>REV TIMING</td><td> 2</td><td>Timing Adjustment for Transmission TX of the R-TCH channel</td>

<td>REV STATUS REQ</td><td> 1</td><td>RTCH Status Message Request</td>

<td>REV N LONG</td><td> 7</td><td>Number of Long OFDM Symbols in the package</td>

53 / 59P25695PL00

<td>Field</td><td>beaten</td><td>Function</td>

<td>REV N SHORT</td><td> 2</td><td>Number of OFDM Short Symbols in package</td>

<td>REV POWER</td><td> 2</td><td>TX Transmission Power Control in the channel R-TCH</td>

<td>Together</td><td> 73</td><td></td>

[0250] The format of the IE element Assigning Spatial Multiplexing Mode to the TCH (FCCH) Channel (designated in Table 23 as SpaModeAssign) is shown in Table 33. This IE element is similar to the DivModeAssign element, except that spatial multiplexing is used instead of diversification .

Table 33. Element IE Assigning Spatial Multiplexing Mode to the TCH channel

<td>Field</td><td>beaten</td><td>Function</td>

<td>TYPE IE</td><td> 4</td><td>0x8</td>

<td>MAC ID</td><td> 10</td><td>MAC ID assigned to UT terminal</td>

<td>FWD OFFSET</td><td> 12</td><td>FCH channel offset</td>

<td>FWD RATE</td><td> 16</td><td>Transmission speed in the F-TCH channel</td>

<td>FWD PREAMBLE</td><td> 2</td><td>F-TCH preamble type</td>

<td>FWD N LONG</td><td> 7</td><td>Number of Long OFDM Symbols in the package</td>

<td>FWD N SHORT</td><td> 2</td><td>The number of Short OFDM Symbols in the package</td>

<td>REV OFFSET</td><td> 12</td><td>R-TCH channel offset</td>

<td>REV PREAMBLE</td><td> 2</td><td>R-TCH preamble type</td>

<td>REV RATE</td><td> 16</td><td>Transmission rate in the R-TCH channel</td>

<td>REV TIMING</td><td> 2</td><td>Timing Adjustment for TX Transmission of the R-TCH</td>

<td>REV STATUS REQ</td><td> 1</td><td>R-TCH Status Message Request</td>

<td>REV N LONG</td><td> 7</td><td>Number of Long OFDM Symbols in the package</td>

<td>REV N SHORT</td><td> 2</td><td>The number of Short OFDM Symbols in the package</td>

<td>REV POWER</td><td> 2</td><td>TX Transmission Power Control in the channel R-TCH</td>

<td>Together</td><td> 97</td><td></td>

[0251] The format of the IE Link and Buffer State Request Element (RFCH or FCCH) (designated in Table 23 as LinkStatusReq) is shown in Table 34. This IE element is used

53 / 59P25695EN00 through the AP to request the current buffer state and the current physical link state from the UT with that UT. A reverse link allocation is made with the request to provide a response. In addition to fields of type and

<td colspan="2">MAC ID</td><td>ID included</td><td colspan="2">there are link allocation fields</td>

<td>return,</td><td>similarly</td><td>for assignments</td><td>link</td><td>feedback described</td>

<td>in detail</td><td>above.</td><td></td><td></td><td></td>

<td>Table 34.</td><td>Element</td><td>IE State Requests</td><td>links</td><td>and Buffer for the channel</td>

<td></td><td></td><td>R-TCH</td><td></td><td></td>

<td>Field</td><td>beaten</td><td>Function</td>

<td>TYPE IE</td><td> 4</td><td>0x9</td>

<td>MAC ID</td><td> 10</td><td>MAC ID assigned to UT terminal</td>

<td>REV OFFSET</td><td> 12</td><td>R-TCH channel offset</td>

<td>REV PREAMBLE</td><td> 2</td><td>R-TCH preamble type</td>

<td>REV TIMING</td><td> 2</td><td>Timing Adjustment for TX Transmission R-TCH channel</td>

<td>RBV STATUS REQ</td><td> 1</td><td>R-TCH Status Message Request</td>

<td>REV N LONG</td><td> 7</td><td>Number of Long OFDM Symbols in the Link State package</td>

<td>REV N SHORT</td><td> 2</td><td>The number of Short OFDM Symbols in the package Link state</td>

<td>Together</td><td> 40</td><td></td>

Format of IE Confirmation Request Calibration element [0252] (FCCH) marked

Table 23 as CalReqestAck) is shown in Table 35. This IE element is transmitted to confirm the calibration request. Calibration is usually

Registration occasionally. symmetrical, access AP gain and and so on Although the transmission strings for the UT terminal. carried out immediately after the time the TDD wireless channel can be carried out is the receiving point and the UT terminal may have a different phase. Calibration is carried out to eliminate this asymmetry. This IE element contains a type field, MAC ID field (containing temporary

MAC ID assigned to the UT terminal), number of UT antennas and confirmation of the desired calibration type. The 4 bit calibration type field specifies the combination of tones to be used for calibration and the number of training symbols to send for calibration.

Table 35. IE Confirmation Request Calibration item

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>TYPE IE</td><td> 4</td><td>0xA</td>

<td>MAC ID</td><td> 10</td><td>Temporary MAC ID assigned to the UT terminal</td>

<td>nant</td><td> 2</td><td>Number of UT antennas</td>

<td>CalType</td><td> 4</td><td>Confirms the requested procedure calibration</td>

<td>Message Length</td><td> 20</td><td></td>

[0253]

The format of the IE Rejecting Calibration Request (FCCH) element (designated as CalReqestRej in Table 23) is shown in Table 36. This IE element rejects the calibration request from the UT. This IE element contains a type field, a MAC ID field, and a type of calibration request, as in the case of CalRequestAck. In addition, a justification field is provided to determine why the calibration request is rejected.

Table 36. IE Element Reject Calibration Request

<td>Parameter Name</td><td>beaten</td><td>Goal</td>

<td>TYPE IE</td><td> 4</td><td>0XB</td>

<td>MAC ID</td><td> 10</td><td>Temporary MAC ID assigned to the UT terminal</td>

<td>CalType</td><td> 4</td><td>Calibration procedure requested</td>

<td>Substantiation</td><td> 4</td><td>Justification for rejecting the request calibration.</td>

<td>Message Length</td><td> 22</td><td></td>

[0254] Calibration request justifications are mapped by a justification value. The justifications and their values ​​are described in detail in Table 37.

53 / 59P25695PL00

Table 37. Meaning of value for justifications

<td>Value</td><td>Substantiation</td>

<td> 0000</td><td>Calibration is not required</td>

<td> 0001</td><td>The requested procedure is not supported</td>

<td> 0010</td><td>The calibration process has expired</td>

<td> 0011-1111</td><td>Reserved</td>

[0255] The Request Message Format (ARCH) is shown in Table 38. During the initial access , the Request Message is treated as a registration request. The UT accessing terminal randomly retrieves the Access ID from the set of IDs intended for initial access and announced in the BCCH message. If the Request message is successively received, the AP confirms it using the IE Request Registration Confirmation element on the RFCH channel and assigning a temporary MAC ID to the UT.

[0256] The registered UT uses the same message on the ARCH, but uses its assigned MAC ID in the Access ID field to request the service. If the Request message is successively received, the AP transmits the IE of the Link State Request R-TCH in order to obtain information about the type and size of the assignment required by the UT.

Table 38. Request messages in the ARCH channel

<td>Field</td><td>beaten</td><td>Function</td>

<td>Preamble</td><td>Variables</td><td>Short or Long</td>

<td>SLOT ID</td><td> 5</td><td>The Slot ID is used by the UT terminal in RCH Access</td>

<td>ACCESS ID</td><td> 10</td><td>Access ID used through the UT terminal</td>

<td>Together</td><td> 15</td><td></td>

[0257] Those skilled in the art will recognize that information and signals may be represented using any of a variety of technologies and techniques. For example, data, instructions, orders, information, signals, bits, symbols and chips, which may be recalled by the above description, may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles or combinations thereof are present.

[0258] Those skilled in the art will recognize that various illustrative logic blocks, modules, circuits, and algorithm steps described in connection with the embodiments described herein can be implemented as electronic equipment, computer software or a combination thereof. To clearly display the interchangeability of hardware and software, various illustrative components, blocks, modules, circuits and steps have been described above essentially in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and design constraints imposed on the entire system. Skilled artisans may implement the described functionality in various ways for each particular application, but such implementation decisions should not be interpreted as departing from the scope of the present invention.

[0259] The various illustrative logical blocks, modules and systems described in connection with the embodiments described herein may be implemented or implemented by a general purpose processor, digital processor (DSP), integrated circuit designed for specific applications (ASIC), programmable gate matrix ( FPGA) or other programmable logic device, logic circuits with discrete gates or transistors, discrete hardware components or any combination of the listed components intended to perform the functions described herein. General signal implementation processor

The processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microprocessor or state machine. The processor can also be implemented as a combination of computing devices, e.g., a combination of DSP and microprocessor, multiple microprocessors, one or more microprocessors in combination with a DSP core, or any other configuration of this type.

[0260] The method or algorithm steps described in connection with the embodiments described herein can be implemented directly in hardware, in a software module executed by a processor, or in a combination thereof. The software module may be located in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM or in any other form of storage medium known in the art. An exemplary storage medium is connected to the processor in such a way that the processor can read and write information from the storage medium. Alternatively, the storage medium may be integrated into the processor. The processor and storage media may be in an ASIC. The ASIC may be in the user terminal. Alternatively, the processor and storage medium may reside in the user terminal as discrete components.

[0261] In the present description, headers are incorporated by reference and to facilitate locating various parts of the description. These headlines are not intended to limit the scope of the concepts described in relation to them. Such concepts may apply throughout the whole description.

[0262] The above description of the disclosed embodiments of the invention is provided to enable any person skilled in the art to make or use the present invention. Various modifications of these embodiments will be readily apparent to those skilled in the art, and the basic principles set out herein may be

53 may be used in other embodiments without departing from the scope of the present invention. Thus, the intention of the present invention is not to be limited to the embodiments set forth herein, but to give it the widest scope in accordance with the principles and new features set forth herein.