TWI383302B - Wireless lan protocol stack - Google Patents

Description

Wireless area network protocol heap Priority is claimed in accordance with 35 U.S.C. §119

This patent application claims priority to the following U.S. Provisional Patent Application Serial No. 60/511,750, filed on Oct. 15, 2003, entitled "Method and Apparatus for Providing Interoperability and Backward Compatibility in Wireless Communication Systems"; Provisional Patent Application No. 60/511,904, filed on October 15, 2003, entitled "Method, Apparatus, and System for Medium Access Control in a High Performance Wireless LAN Environment"; Provisional Patent Application, filed on October 21, 2003 Case No. 60/513,239, entitled "Peer-to-Peer Connections in MIMO WEAN System"; Provisional Patent Application No. 60/526,347, filed on December 1, 2003, entitled "Method, Apparatus, and System for Sub- Provisional Patent Application No. 60/526,356, filed on December 1, 2003, entitled "Method, Apparatus, and System for Multiplexing Protocol data Units in a High Performance Wireless LAN Environment" Provisional Patent Application No. 60/532,791, dated December 23, 2003 "Wireless Communications Medium Access Control (MAC) Enhancements"; Provisional Patent Application No. 60/545,963, filed on February 18, 2004, entitled "Adaptive Coordination Function (ACF)"; provisional dated June 2, 2004 Patent Application No. 60/576,545, Standard Titled "Method and Apparatus for Robust Wireless Network"; Provisional Patent Application No. 60/586,841, filed on June 8, 2004, entitled "Method and Apparatus for Distribution Communication Resources Among Multiple Users"; and August 11, 2004 Provisional Patent Application No. 60/600,960, entitled "Method, Apparatus, and System for Wireless Communications"; these patent applications have been assigned to the same assignee as the present patent application, and The manner is explicitly incorporated herein.

The present invention is broadly related to the field of communications, and in particular, to wireless local area network (LAN) protocol stacking.

Wireless communication systems are widely deployed to provide various types of communication such as voice, data. A typical wireless data system or network provides multiple users with access to one or more shared resources. The system can use various multiple access technologies, such as Frequency Division Multiplexing (FDM), Time Division Multiplexing (TDM), and Code Division Multiplexing (CDM), among others.

An exemplary wireless network includes a cellular data system. The following are a few examples of this: (1) "TIA/EIA-95-B Mobile Station-Base Station Compatibility Standard for Dual Mode Broadband Spread Spectrum Honeycomb Systems" (TIA/EIA-95-B Mobile Station-Base) Station Compatibility standard for Dual-Mode Wideband Spread Spectrum Cellular System, that is, iS-95 standard); (2), entitled "third Generation partnership Project" (3 ^rd Generation partnership Project; standard 3GPP) of the proposed alliance, and A set of documents specific, including the number 3G TS 25.211, 3G TS 25.212, 3G TS 25.213 and 3G TS 25.214 (W-CDMA standard); (3) named "3rd Generation Partnership 2" (3 ^rd Generation Partnership The standard proposed by the Alliance 2; 3GPP2) and embodied in the "TR-45.5 Physical Layer Standard for cdma2000 Spread Spectrum Systems; IS-2000 Standard"document; And (4) a high data rate (HDR) communication system that complies with the TIA/EIA/IS-856 standard (referred to as the IS-856 standard).

Other examples of wireless systems include Wireless Local Area Network (WLAN), such as the IEEE 802.11 standard (ie, 802.11 (a), (b), or (g)). The deployment of a Multiple Input Multiple Output (MIMO) WLAN including Orthogonal Frequency Division Multiplexing (OFDM) modulation technology can improve these networks.

With the advancement of wireless system design, higher data transmission rates have become feasible. Higher data transfer rates open up advanced applications, including voice, video, fast data transfer and a variety of other applications. However, various applications may have different data transfer requirements. Many types of data will have latency and throughput requirements, or require certain Quality of Service (QoS) guarantees. In the absence of resource management, system capacity may be reduced and the system will not operate efficiently.

A Medium Access Control (MAC) protocol is typically used to configure communication resources shared between several users. MAC protocol pass Often, higher layers are interfaced to the physical layer for transmitting and receiving data. In order to benefit from increased data transmission rates, MAC agreements must be designed to use shared resources efficiently.

The highly efficient systems that have been developed support multiple transmission rates, which vary widely depending on the physical link characteristics. It is known that the requirements of different data application types are different, and the data transmission rate that can be supported by different user terminals in the system varies greatly, so it is necessary to develop a queue to handle various traffic types, and on various physical links of different heterogeneous types. Progress in transmission and other aspects. Therefore, techniques for efficient use of MAC processing of high throughput systems are needed.

The disclosed embodiments of the present invention address the need for this technology to efficiently handle MAC processing of high throughput systems. In one aspect, an apparatus includes a first layer for receiving one or more packets from one or more data streams, and for generating one or more packets from the one or more packets A layer of Protocol Data Unit (PDU). In another aspect, a second layer is deployed for receiving one or more first layer PDUs from the first layer and generating one or more from the one or more first layer PDUs Second layer PDU. In another aspect, a third layer is deployed for receiving the one or more second layer PDUs and transmitting the one or more second layer PDUs to a remote station. In another aspect, a layer administrator is deployed to receive Layer 2 feedback and pass the second layer feedback to a first layer. The layer administrator can also receive feedback from any layer and pass the feedback to any other layer. In one aspect, the feedback includes Volume feedback.

In another aspect, a protocol stack is deployed having a first layer, the first layer including logic for checking higher layer headers from one or more packets and responding to the checks The headers are classified into one or more data streams. In another aspect, a protocol stack can include logic for multicasting mapped packets that have been classified. The multicast mapping can be performed in response to entity layer feedback. In another aspect, a protocol stack can include logic for partitioning and/or reassembling the classified packets. This segmentation and/or reassembly can be performed in response to entity layer feedback. In another aspect, a protocol stack can include logic for the physical layer to transport the classified packets.

In another aspect, the present invention discloses a protocol stack including one or more of the following: an adjustment layer, a data link control layer, a physical layer, and a layer administrator. The present invention discloses a MAC sublayer protocol data unit that can be adjusted to include data from a plurality of data streams. The features and aspects are further detailed below.

In another aspect, the physical layer feedback is used to adjust layer processing. In a specific embodiment, the physical layer feedback is used for segmentation. In another specific embodiment, the entity layer feedback is for multicast mapping to one or more unicast channels. In another embodiment, a combination of unicast, multicast, or broadcast channels for performing multicast transmissions may be selected in response to entity layer feedback corresponding to various channels.

In another aspect, a data unit for transmitting from a first station to a second station includes: zero or more complete sub-data units, from the previous A transmitted zero or a local sub-data unit and zero or one local sub-data unit for filling the data unit. In a specific embodiment, an indicator is used to indicate the location of any complete sub-data unit. A partial sub-data unit can be inserted at a predetermined location. The local sub-data unit can be combined with a previously stored local sub-data unit or stored for later use. In a specific embodiment, a sub-data unit may be a MUX sub-layer protocol data unit (MUX PDU).

Various other aspects and specific embodiments have also been proposed. These aspects have the advantage of providing high-efficiency media access control and are suitable for use with physical layers that contain high data rates and low data rates.

The present invention discloses a sub-network protocol stack that supports high efficiency, low latency, and high throughput operation of a physical layer of very high bit rate in conjunction with a wireless LAN (or similar application using the latest market transmission technology). The exemplary WLAN supports a 20 MHz bandwidth exceeding 100 Mbps (million bits per second) bit rate.

In conjunction with the protocol stacking, a method for multiplexing a protocol data unit (PDU) and a subnet control entity (MAC PDU) from a plurality of user data streams into a single byte data stream is illustrated. In conjunction with the protocol stacking, a method for multiplexing a protocol data unit (PDU) and a subnet control entity (MAC PDU) from a plurality of user data streams into a single byte data stream is illustrated. This approach supports high-performance wireless LAN subnets for high-efficiency, low-latency, high-traffic operation with a very high bit rate physical layer.

Sub-network protocol stacking supports a wide data transmission rate and high-bandwidth physical layer transmission mechanism, including (but not limited to): transmission mechanism based on OFDM modulation; single-carrier modulation technology; suitable for use in extremely high-frequency and wide-efficiency operation A system for receiving antennas and multiple transmit antennas (Multiple Input Multiple Output (MIMO) systems (MIMO), including Multiple Input Single Output (MISO) systems); with space multiplexing technology a system using a plurality of receiving antennas and a plurality of transmitting antennas for transmitting data to a user terminal during the same period of time, or receiving data from a user terminal; and using code division multi-directional proximity (code division) Multiple access; CDMA) technology system for allowing multiple users to transmit simultaneously.

One or more exemplary embodiments described herein are presented in the context of a wireless data communication system. While there are many advantages to using the invention in this context, various specific embodiments of the invention may be incorporated in different environments or configurations. In general, the various systems described herein can be constructed using software controlled processors, integrated circuits, or discrete logic. The materials, instructions, commands, information, signals, symbols and wafers referred to throughout the specification are advantageously represented by voltages, currents, electromagnetic waves, magnetic fields or particles, light fields or particles, or any combination thereof. In addition, the blocks shown in each block diagram may proxy hardware or method steps. The method steps are interchangeable without departing from the scope of the invention. The term "demonstration" as used in this document means "serving as an example, instance or explanation." Any specific embodiments described herein as "exemplary" are not necessarily to be construed as preferred or preferred embodiments.

1 illustrates an exemplary embodiment of a system 100 that includes an access point (AP) 104 coupled to one or more user terminals (UTs) 106A-N. The AP communicates with the UT via a wireless local area network (WLAN) 120. In this exemplary embodiment, WLAN 120 is a high speed MIMO OFDM system. However, WLAN 120 may be any wireless LAN. Access point 104 communicates with any external device or process via network 102. Network 102 may be the Internet, an internal network, or any other wired, wireless, or optical network. Connection 110 carries the physical layer signal from the network to access point 104. The device or process can be connected to the network 102 or as a UT on the WLAN 120 (or connected thereto via a connection). Examples of connections that may be connected to network network 102 or WLAN 120 include telephones, personal digital assistants (PDAs), various similar computers (laptops, personal computers, workstations, any type of terminal), video devices (eg, cameras, Camcorders, web cameras and almost any type of data device). Processes can include voice, video, data communication, and the like. Various data streams have different transmission requirements, which can be adapted to various needs by using a variety of Quality of Service (QoS) technologies.

System 100 is deployed using centralized AP 104. In this exemplary embodiment, all UTs 106 are in communication with the AP. In an alternate embodiment, modifying the system provides for peer-to-peer communication between the UTs, as is known to those skilled in the art. Based on the clear discussion, in this exemplary embodiment, the access of the physical layer transport mechanism is controlled by the AP.

In a specific embodiment, the AP 104 provides Ethernet conditioning, Figure 24 Show examples of it. In this case, the IP 104 can be deployed using the AP 104, thereby providing a connection to the network network 102 (via the Ethernet connection 110). For example, the illustrative example UT 106 shown in the figures is a mobile phone 106A, a personal digital assistant (PDA) 106B, a laptop 106C, a workstation 106D, a personal computer 106E, a video camera 106F, and a video projector 106G. An Ethernet frame can be transmitted between the router and the UT 106 via the WLAN subnet 120 (as described in detail below).

Ethernet conditioning and connectivity capabilities are known in the art. 26 illustrates, for example, Ethernet conditioning protocol stacks 2640 and 2650 for UT 106 and AP 104, respectively, as described in the detailed description of the various example layers as follows. The UT protocol stack 2640 includes an upper layer 2610, an IP layer 2615, an Ethernet MAC layer 2620A, an adjustment layer 310A, a data link layer 320A, and a physical layer (PHY) 240A. The AP protocol stack 2650 includes a PHY 240B (connected to the UT PHY 240A via the RF link 120), a data link layer 320B, and an adjustment layer 310B. The Ethernet MAC 2620B connects the adjustment layer 310B to the Ethernet PHY 2625, and the Ethernet PHY 2625 connects to the 110 wired network 102.

In an alternate embodiment, the AP 104 provides IP conditioning, and Figure 25 depicts an example thereof. In this case, the AP 104 acts as a gateway router for the user of the set of connections (as described with reference to Figure 24). In this case, the AP 104 can route IP datagrams back and forth between the UTs 106.

IP conditioning and connectivity are techniques known in the art. 27 illustrates, for example, IP protocol stacks 2740 and 2750 for UT 106 and AP 104, respectively, as described in the detailed description of the various example layers as follows. The UT protocol stack 2740 includes an upper layer 2710, an IP layer 2720A, an adjustment layer 310A, and a data chain. Road layer 320A and physical layer (PHY) 240A. The AP protocol stack 2750 includes a PHY 240B (connected to the UT PHY 240A via the RF link 120), a data link layer 320B, and an adjustment layer 310B. The IP layer 2720B connects the adjustment layer 310B to the Ethernet MAC 2725, while the Ethernet MAC 2725 is connected to the Ethernet PHY 2730. The Ethernet PHY 2730 is connected to the 110 wired network 102.

2 illustrates an exemplary embodiment of a wireless communication device that can be configured as an access point 104 or user terminal 106. Figure 2 illustrates the configuration of the access point 104. The transceiver 210 receives and transmits on the connection 110 in accordance with the physical layer requirements of the network 102. The data received or transmitted to the device or application connected to the network 102 is passed to the MAC processor 220. These materials are referred to herein as data streams 260. Data streams can have different characteristics and require different processing depending on the type of application associated with the data stream. For example, video or speech is characterized by a low-latency data stream (generally, the video throughput requirement is higher than the voice throughput requirement). Many data applications are less susceptible to latency, but may have higher data integrity requirements (ie, voice may allow for loss of a packet, and file transfers typically do not allow for packet loss).

The MAC processor 220 receives and processes the data stream 260 to transport the data stream on the physical layer. The MAC processor 220 receives and processes the data stream 260 to transport the data stream on the physical layer. Internal control and signaling numbers are also transmitted between the AP and the UT. A MAC Protocol Data Unit (MAC PDU) is delivered to the wireless LAN transceiver 240 and receives a MAC PDU from the wireless LAN transceiver 240 over the connection 270. The following describes the conversion from data streams and commands to MAC PDUs and vice versa. Further explanation below based on each For this purpose, feedback 280 corresponding to various MAC IDs is passed back from the physical layer (PHY) 240 to the MAC processor 220. Feedback 280 can include any physical layer information, including supported channel transmission rates (including multicast channels and unicast channels), modulation formats, and various other parameters.

In an exemplary embodiment, an adjustment layer (ADAP) and a data link control layer (DLC) are implemented in the MAC processor 220. The physical layer (PHY) is executed on the wireless LAN transceiver 240. Those skilled in the art should be aware that any of a variety of configurations can be used to perform the functional segmentation. The MAC processor 220 can perform some or all of the processing related to the physical layer. A wireless LAN transceiver can include a processor for performing MAC processing or a sub-portion thereof. Any number of processors, special purpose hardware, or a combination thereof can be deployed.

The MAC processor 220 may be a general purpose microprocessor, a digital signal processor (DSP) or a special purpose processor. The MAC processor 220 can be connected to a special purpose hardware (not shown in detail) for assisting various tasks. Various applications can be executed on an external processor (for example, an external computer or via a network connection), or various applications can be executed on an additional processor (not shown) in the access point 104, or Various applications can be executed on the MAC processor 220 itself. The MAC processor 220 shown in the figure is coupled to a memory 255 that can be used to store data and instructions for performing the various procedures and methods described herein. Those skilled in the art will appreciate that memory 255 may be comprised of one or more types of memory components and may be embodied in whole or in part within MAC processor 220.

In addition to storing instructions and materials that perform the functions described herein, the memory 255 can also be used to store data associated with various queues (see below) Detailed description). Memory 255 can include a UT proxy server queue (as described below).

Wireless LAN transceiver 240 may be any type of transceiver. In an exemplary embodiment, wireless LAN transceiver 240 is an OFDM transceiver that can operate in conjunction with a MIMO or MISO interface. OFDM, MIMO, and MISO are techniques known to those skilled in the art. A variety of OFDM, MIMO, and MISO transceivers are described in detail in the "FREQUENCY-INDEPENDENT SPATIAL-PROCIESSING FOR WIDEBAND MISO AND MIMO SYSTEMS", filed on August 27, 2003, in the co-pending application Serial No. 10/650,295. Transfer to the assignee of the present invention.

The wireless LAN transceiver 240 shown in the figure is connected to the antennas 250 A-N. Any number of antennas can be supported in various embodiments. Antenna 250 is used to transmit and receive on WLAN 120.

Wireless LAN transceiver 240 can include a spatial processor coupled to each antenna antenna 250. The spatial processor can process the data to be transmitted independently for each antenna. Examples of independent processing include channel based evaluation, feedback from the UT, channel reversal, or various other techniques known in the art. This processing is performed using various known spatial processing techniques. Various transceivers of this type may use beam forming, beam steering, eigen-steering, or other spatial techniques for increasing the throughput of a given user terminal. In a particular embodiment of transmitting OFDM symbols, the spatial processor may include a plurality of subspace processors for processing each OFDM subchannel or bin.

In an exemplary system, an AP may have N antennas, and an exemplary UT may have M antennas. Therefore, there are M x N paths between the antenna of the AP and the antenna of the UT. Various spatial techniques that use these multipaths to improve throughput are known in the art. In a Space Time Transmit Diversity (STTD) system (also referred to herein as "diversity"), the transmitted data is formatted, encoded, and transmitted as a single data stream using all of the antennas. Using M transmit antennas and N receive antennas, it is possible to form MIN (M, N) independent channels. Spatial multiplexing processing utilizes these independent paths and can transmit different data on each independent path.

Various techniques for knowing or adjusting the channel characteristics between the AP and the UT are known. A unique preamble can be transmitted from each transmit antenna. The preambles can be received and measured on each receive antenna. Channel feedback can then be passed back to the transmitting device for use during transmission. Channel reversal is a technique that allows for preprocessing and transmission, but is computationally intensive. An eigen decomposition can be performed, and a lookup table can be used to determine the transmission rate. To avoid channel decomposition, an alternative technique uses preamble feature import to simplify spatial processing. Pre-distortion techniques are known techniques for simplifying receiver processing.

Thus, depending on current channel conditions, the entire system can provide different data transmission rates for transmission to various user terminals. In particular, the performance of a particular link between an AP and each UT may be higher than the performance of a link that more than one UT can share. Examples are further detailed below. The wireless LAN transceiver 240 can determine the supportable transmission rate based on the spatial processing used for the physical link between the AP and the UT. This information can be fed back on connection 280. For use in MAC processing, as described in detail below.

Several antennas can be deployed according to the data needs of the UT. For example, high definition video displays may include, for example, four antennas based on high frequency bandwidth requirements, while PDAs may be satisfied using two antennas. An exemplary access point can have four antennas.

The user terminal 106 can be deployed in a manner similar to the access point 104 shown in FIG. If data stream 260 is not connected to a LAN transceiver (although the UT may include a wired or wireless transceiver), then data stream 260 is typically one or more applications or processes that are received from or transmitted to the UT or device connected to the UT. . The higher level connected to the AP 104 or UT 106 may be of any type. The items described herein are merely illustrative.

Agreement stack

FIG. 3 illustrates an exemplary sub-network protocol stack 300. The sub-network protocol stack 300 can serve as an interface between the very high bit rate LAN physical layer and the MAC layer of the network layer or other network (eg, the Ethernet MAC layer or the TCP/IP network layer). A protocol stack 300 of various features can be deployed, thereby taking advantage of the extremely efficient wireless LAN physical layer. An exemplary protocol stack can be designed to provide advantages, examples of which include: (a) minimizing the amount of throughput load consumed by the agreement; and (b) maximizing the efficiency with which the encapsulated subnet data unit becomes a physical layer frame; (c) Minimize latency for end-to-end transmission delays caused by transmission mechanisms that are susceptible to delays (eg, TCP); (d) provide highly reliable, sequential delivery of subnet data units; (e) provide support Existing network layers and applications, as well as providing full flexibility for future networks and applications; and (f) unobstructed integration of existing network technologies.

The protocol stack 300 has several thin sub-layers, several modes of operation, and facilities for supporting multiple external network interfaces. 3 illustrates an adjustment layer 310, a data link control layer 320, and a physical layer 240. Layer administrators 380 are interconnected to each sub-layer for providing communication and control of various functions, as described below.

FIG. 3 illustrates an exemplary protocol stack 300 configuration. The dashed lines indicate exemplary configurations of components that may be deployed in the MAC processor 220, as described above. The adjustment layer 310, the data link control layer 320, and the layer administrator 380 are included. As described above, in this configuration, the physical layer 240 receives and transmits MAC Protocol Data Units (PDUs) on the connection 270. Feedback link 280 is directed to layer administrator 380 to provide physical layer information for use in the various functions described below. This example is merely illustrative. Those skilled in the art will appreciate that any number of components can be deployed within the scope of the present invention and configured to include any combination of the illustrated stacking functions.

The conditioning layer 310 provides an interface that interfaces to higher layers. For example, the adjustment layer can interface with IP stacking (for IP conditioning), Ethernet MAC (for Ethernet conditioning), or various other network layers. Data stream 260 can be received from one or more higher layers for MAC processing and transmitted on physical layer 240. The data stream 260 can also be received, processed, and recombined via the physical layer for delivery to one or more higher layers.

The adjustment layer 310 includes the following functions: segmentation and reassembly 312, data stream classification 314, and multicast mapping 316. The data stream classification function 314 checks for header packets received from higher layers (from data stream 260), maps each packet to a user terminal or a multicast group MAC identification (MAC ID), and based on quality of service ( QoS) differential treatment to classify packets. Multicast mapping function 316 determines whether to use a multicast MAC ID (referred to as "MAC layer multicast") to transmit multicast data, or through multiple unicast MAC IDs (referred to as "adjustment layer multicast") Transfer multicast user data, as detailed below. The Segmentation and Reassembly (SAR) function 312 adjusts each higher layer packet to a Protocol Data Unit (PDU) size suitable for a Logical Link (LL) mode. The SAR function 312 is performed individually for each MAC ID. The data stream classification function 314 is a common function.

The data link control layer 320 includes a logical link (LL) layer 330, a Radio Link Control (RLC) layer 340, a system configuration control 350, a MUX function 360, and a common MAC function 370. Sub-blocks of each of the layers are depicted in Figure 3 and will be described in detail below. The blocks shown in the figures are only examples. A subset of their functions and additional functionality may be deployed in various alternative embodiments.

The physical layer 240 may be any type of physical layer, as described in the examples described above. An exemplary embodiment uses a MIMO OFDM physical layer. Exemplary parameters of this particular embodiment are included in the description below.

The layer administrator 380 (LM) interfaces with the conditioning layer 310, the data link control layer 320, and the physical layer 240 for managing QoS, admission control, and physical layer transmitter and receiver parameter control. Note that feedback 280 from the physical layer can be used in performing the functions described herein. For example, a supportable transmission rate suitable for various UTs can be used in the multicast map 316 or the split and reassembly 312.

Adjustment layer

The data stream classification (FLCL) function 314 checks the packet header of the incoming packet. The field, and its mapping into a stream of data. In an exemplary embodiment of performing IP conditioning, the data flow classification may use the following fields: (a) IP source address and destination address; (b) IP source port and destination port; (c) IP DiffServ Code Point (DSCP; IP DiffServ code indicator); (d) Resource Reservation Protocol (RSVP) message; and (e) Real-time Transport Control Protocol (RTCP) message and instant transmission protocol (Real) -time Transport Protocol; RTP) header. In an exemplary embodiment of performing Ethernet adjustment, the data flow classification may use 802.1p and 802.1q header fields. Ethernet traffic adjustments can also be classified using IP data streams, however this can result in layer violations. Those skilled in the art should appreciate that various other types of data stream classifications can be deployed as an alternative.

FLCL 314 determines whether an identified data stream 260 is mapped to an existing MAC ID, Logical Link (LL) mode, and data stream ID (as described in detail below). If the incoming packet is mapped to an existing data stream, the FLCL forwards the packet to be further processed to the Split and Reassembly (SAR) function 312. If a new MAC ID is required, a request is forwarded to the associated control function 344 in the Radio Link Control (RLC) 340.

If a new data stream for an existing MAC ID is identified, the QoS administrator function 382 in the layer administrator 380 determines the type of logical link mode required for the data flow. If a new LL mode is initialized, the request is forwarded to the LLC function 338 corresponding to the MAC ID to handle mode negotiation. If a new data stream is built in the existing LL mode, the request will be forwarded to the LLC function 338. The joint application of the US patent filed on November 26, 2003 A specific embodiment of the maintenance of the QoS queue is described in detail in the application Serial No. 10/723,346 entitled "QUALITY OF SERVICE SCHEDULER FOR A WIRELESS NETWORK", which is assigned to the assignee of the present invention.

In the case of IP or Ethernet multicast, the multicast mapping function 316 determines whether to process the packet using MAC layer multicast by mapping to a multicast MAC ID, or whether to packetize the packet. Processing becomes multiple unicast transmissions (referred to herein as "Adaptation Layer Multicast". If the packet is to be processed into multiple unicast transmissions, the multicast mapping function 316 will copy the Multiple copies of the packet (each copy is used for each unicast MAC ID to which the packet is to be transmitted), and the packets are forwarded to the Split and Reassembly (SAR) function 312. Reference will now be made to Figure 15 to Figure 16 illustrates this aspect in detail.

As described in the previous paragraph, the data stream classification function 314 maps a packet to a MAC ID, LL mode, and data stream ID (if any). The segmentation and reassembly function 312 partitions the higher layer packets (i.e., IP data elements or Ethernet frames) into a plurality of segments suitable for transmission over the logical link mode. Exemplary embodiments of this aspect will be described in detail below with reference to FIGS. 17 through 18. In this example, a one-bit tuple adjustment layer header per fragment is added to allow recombination when the fragments are sequentially passed to the corresponding SAR function in the receiver. Next, the adjustment layer protocol data unit (PDU) is passed to the data link control layer 320 for processing in accordance with the classification parameters: MAC ID, LL mode, and data stream ID.

Data link control layer

4 illustrates a user data packet 410 traveling through layers (ie, IP data) Yuan, Ethernet frame or other packet). Exemplary column sizes and types will be described in this illustrative description. Those skilled in the art will appreciate that a variety of other sizes, types, and configurations are considered to be within the scope of the present invention.

As shown, the data packet 410 is segmented at the adjustment layer 310 into segments. Each adjustment sublayer PDU 430 each carries one of its segments 420. In this example, data packet 410 is segmented into N segments 420A-N. A conditioning sublayer PDU 430 includes a packet payload 434 containing a corresponding segment 420. A type field 432 (one bit in this example) is attached to the adjustment sublayer PDU 430.

At logical link (LL) layer 330, an LL header 442 (4 bytes in this example) is appended to the packet bearer 434 containing the conditioning sublayer PDU 430. Exemplary information of the LL header 442 includes a data stream identification item, control information, and serial number. A header 442 and a packet bearer 444 are utilized to calculate and append a CRC 446, thereby forming a Logical Link Sublayer PDU (LL PDU) 440. In a similar manner, Logical Link Control (LLC) 338 and Radio Link Control (RLC) 340 (described in more detail below) form an LLC PDU and an RLC PDU. The LL PDU 440 and the LLC PDU and the RLC PDU are both placed in a queue (i.e., a high QoS queue 362, a best effort queue 364, or a control message queue 366) for servicing by the MUX function 360. .

MUX function 360 appends a MUX header 452 to each LL PDU 440. An exemplary MUX header 452 can include a length and a type (in this example, header 452 is 2 bytes). A similar header can be constructed for each control PDU (ie, LLC PDU and RLC PDU). The LL PDU 440 (or, LLC or RLC PDU) constitutes a packet bearer 454. Header 452 and packet bearing 454 A MUX sublayer PDU (MPDU) 450 is formed (the MUX sublayer PDU is also referred to herein as a MUX PDU).

The MAC protocol configures communication resources on the shared medium in a series of MAC frames. The MAC scheduler 376 determines the physical layer burst size configured for one or more MAC IDs in each MAC frame (labeled as MAC frame f, where f indicates a particular MAC frame). Please note that not all MAC IDs containing the material to be transmitted will be configured in the space of any particular MAC frame. Any access control or scheduling mechanism can be deployed and is within the scope of the present invention. When a configuration job is performed for a MAC ID, the MUX function 360 corresponding to the MAC ID will constitute a MAC PDU 460 containing one or more MUX PDUs 450 to be included in the MAC frame f. One or more MAC PDUs 460 of one or more configured MAC IDs are included in a MAC frame (i.e., MAC frame 500 detailed below with reference to FIG. 5).

In an exemplary embodiment, an aspect allows for transmission of a local MPDU 450, thereby allowing for efficient packaging in a MAC PDU 460. This will be explained in detail below. In this example, MUX function 360 maintains the untransmitted byte count of any local MPDUs 450 left by the previous transmission (identified by local MPDU 464). These bytes 464 are transmitted prior to any new PDUs 466 (i.e., LL PDUs or Control PDUs) of the current frame. Header 462 (2 bytes in this example) includes a MUX indicator that points to the beginning of the first new MPDU (MPDU 466A in this example) to be transmitted in the current frame. Header 462 can also include a MAC address.

The MAC PDU 460 includes the MUX indicator 462, a possible local MUX PDU 464 at the beginning (left in the previous configuration), followed by zero or A plurality of full MUX PDUs 466A-N and a possible local MUX PDU 468 (from the current configuration) or other padding for filling the configured portion of the physical layer burst. The MAC PDU 460 is shipped in the physical layer burst that has been configured for the MAC ID.

Common MAC, MAC frame and transmission channel

FIG. 5 illustrates an exemplary MAC frame 500. The common MAC function 370 manages the MAC frame 500 configuration between the following transport channel segments: broadcast, control, forward and reverse traffic (referred to as the download link phase and the upload link phase, respectively), and random access. The MAC group frame function 372 can use various components to form a frame, which will be described in detail below. Exemplary function, coding, and transmission channel durations are detailed below.

In this exemplary embodiment, a time division duplex processing (TDD)-MAC frame is performed over a 2 ms (millisecond) time interval. The MAC frame 500 is divided into five transmission channels (appearing in the order of 510-550 as shown). Alternative sequences and different frame sizes can be deployed in alternative embodiments. The duration of the configuration of the MAC frame 500 can be quantized into a small common time interval. In an exemplary embodiment, the quantization is performed in units of 800 ns (nanoseconds, which is also the cyclic prefix duration of short or long OFDM symbols, as described in more detail below). The duration of the MAC frame 500 configuration. The short OFDM symbol is 4.0 μs (microseconds) or 5 times 800 ns.

The exemplary MAC provides five transmission channels in one MAC frame: (a) Broadcast Channel (BCH) 510 for carrying a Broadcast Control Channel (BCCH); (b) Control Channel (Control) Channel; CCH) 520, used to upload a frame control channel (FCCH) and a random access feedback channel (RFCH) on the forward link; (c) a traffic channel (Traffic Channel; TCH) for carrying user data and control information, and subdivided into (i) Forward Traffic Channel (F-TCH) 530 on the forward link, and (ii) on the reverse link a reverse traffic channel (R-TCH) 540; and (d) a random access channel (RCH) 550 for carrying an access request channel (ARCH) (for UT access requirements). A pilot beacon is also transmitted in segment 510.

The frame 500 of the download link phase includes segments 510-530. The upload link phase includes segments 540-550. Fragment 560 indicates the start of a subsequent MAC frame.

Broadcast Channel (BCH)

The broadcast channel (BCH) and the pilot signal 510 are transmitted by the AP. The first portion of BCH 510 includes a common physical layer overhead, such as a preamble, including timing and frequency acquisition preambles. In an exemplary embodiment, the beacon is composed of two short OFDM symbols used by the UT for frequency and timing acquisition; followed by a common MIMO used by the UT to evaluate the channel. The leading 8 short OFDM symbols.

The second part of the BCH 510 is the data section. The BCH data portion defines the MAC frame configuration for the transmission channel segments: CCH 520, F-TCH 530, R-TCH 540, and RCH 550, and also defines CCH combinations for the subchannels. In this example, BCH 510 defines the coverage of wireless LAN 120, It will also be transmitted in most of the robust data transfer modes available. The length of the entire BCH is fixed. In an exemplary embodiment, the BCH defines the coverage of the MIMO-WLAN and uses a ratio of 1/4 code Binary Phase Shift Keying (BPSK) in space time transmission diversity (Space Time). Transmit Diversity; STTD) mode is transmitted. In this example, the length of the BCH is fixed to 10 short OFDM symbols.

Control channel (CCH)

The Control Channel (CCH) 520 is transmitted by the AP and defines the combination of the remainder of the MAC frame. The control channel function 374 of the common MAC function 370 generates a CCH. Exemplary embodiments of the CCH are described in detail below. The CCH 520 is transmitted in a plurality of subchannels using a high-strength transmission mode, each of which has a different data transmission rate. The first subchannel is the strongest and expects all UTs to be decoded. In an exemplary embodiment, a ratio 1/4 code BPSK is used for the first CCH subchannel. Several other subchannels can also be used, and the robustness of their subchannels will be decremented (and the efficiency will increase). In an exemplary embodiment, up to three additional subchannels will be used. Each UT will attempt to decode all subchannels in sequence until the decoding fails. The CCH transmission channel segment in each frame is variable length, and the length depends on the number of CCH messages in each subchannel. An acknowledgement (acknowledgment) of the reverse link random access burst is sent on the most robust (first) subchannel of the CCH.

The CCH contains physical layer burst assignments for the forward and reverse links. The assignment may be for transmitting data on the forward link or the reverse link. general For example, a physical layer burst assignment includes: (a) a MAC ID; (b) a value for indicating the start time of the configuration in the frame (in F-TCH or R-TCH); (c) configured Length; (d) the length of the special entity layer addition; (e) the transmission mode; and (f) the coding and modulation mechanism for the physical layer burst. A MAC ID identifies a single UT for multiple unicast transmissions or a set of UTs for multicast transmissions. In this exemplary embodiment, a unique broadcast MAC ID for transmission to all UTs is also assigned. In an exemplary embodiment, the physical layer addition includes a MIMO preamble consisting of 0, 4, or 8 short OFDM symbols. In this example, the transmission mode is STTD or spatial multiplexing.

Other exemplary type assignments for CCH include: an assignment for a reverse link for transmitting a dedicated preamble from a UT; or a reverse link for transmitting a buffer and link state information from a UT Assignment. The CCH can also define the unused portion of the frame. The UT can use the unused portions of the frame to perform noise floor (and interference) evaluation and to measure the pilot signals of adjacent systems. Exemplary embodiments of the control channel are described in detail below.

Random access channel (RCH)

Random Access Channel (RCH) 550 is a reverse link channel that the UT can use to transmit a random access burst. The RCH variable length of each frame is specified in the RCH. In an exemplary embodiment, a primary feature modality (eigenmode) of a ratio 1/4 code BPSK is used to transmit random access bursts.

Two types of random access bursts are defined in this exemplary embodiment. When the AP must use a sliding correlator to detect When accessing the beginning of a burst, the UT uses a long burst to initiate the access. Once the UT registers with an AP, both ends of the link complete a timing adjustment procedure. After timing adjustment, the UT can transmit its random access bursts in a manner synchronized to the time slot timing on the RCH. Next, the UT uses a short burst for random access. In an exemplary embodiment, a long burst is 4 short OFDM symbols and a short burst is 2 short OFDM symbols.

Forward traffic channel (F-TCH)

Forward Traffic Channel (F-TCH) 530 includes one or more physical layer bursts transmitted from AP 104. Each burst is directed to a special MAC ID as indicated in the CCH assignment. Each burst includes a dedicated entity layer addition (e.g., a preamble (if any)) and a MAC PDU transmitted in accordance with the transmission mode and the coding and modulation mechanisms indicated in the CCH assignment. F-TCH is variable length. In an exemplary embodiment, the dedicated physical layer addition may include a dedicated MIMO preamble.

In an exemplary embodiment, in STTD mode, the performance of a peer-level spatial diversity channel will be 12 bits per short OFDM symbol (a ratio of 1/2 codes RPSK for 48 tones) ) varies from 1344 bits per long OFDM symbol (ratio of 7/8 codes 256 QAM for 192 audio). This translates to a factor of 33 (or 3-99 Mbps in this example) over the peak physical layer data rate.

In this example, a spatial multiplex mode of one to four parallel spatial channels can be used. Each spatial channel uses an appropriate coding and modulation mechanism with an efficiency of 12 bits per short OFDM symbol and each long OFDM The symbol is between 1344 bits. Therefore, the peak physical layer data transmission rate range in the spatial multiplex mode is between 3 and 395 Mbps. Due to space processing constraints, not all parallel space channels can operate at maximum efficiency, so the most practical limit on the peak physical layer data transfer rate may be 240 Mbps, which in this example is between the lowest transfer rate and the highest 80 factors between transmission rates.

Reverse Traffic Channel (R-TCH)

Reverse Traffic Channel (R-TCH) 540 includes physical layer burst transmissions transmitted from one or more UTs 106. Each burst is transmitted by a special UT as indicated in the CCH assignment. Each burst includes a pilot preamble (if any) and a MAC PDU transmitted in accordance with the transmission mode and the coding and modulation mechanisms indicated in the CCH assignment. R-TCH is variable length. In an exemplary embodiment, like the F-TCH, the data transfer rate in the STTD mode ranges from 3 to 98 Mbps, and the data transfer rate in the spatial multiplex mode ranges from 3 to 395 Mbps, perhaps 240 Mbps. It is the most practical limit.

In this exemplary embodiment, either F-TCH 530, R-TCH 540, or both may use spatial multiplexing or code division multi-directional proximity techniques, thereby allowing simultaneous transmission of MAC PDUs associated with different UTs. A field containing the MAC ID associated with the MAC PDU (i.e., the sender on the upload link, or the intended recipient on the download link) may be included in the MAC PDU header. This field can be used to address the ambiguity of addressing when using spatial multiplexing or CDMA. In an alternative embodiment, if the multiplex system is strictly based on the time-sharing technique, then a timing slot is used in the configuration of the MAC frame. Address information is included in the CCH message for a specific MAC ID, so the MAC ID is not required in the MAC PDU header. Space multiplex, code division multiplexing, time division multiplexing, and any other techniques known in the art can be deployed.

During the initial registration period, each active UT is assigned a MAC ID. The MAC ID assignment is handled by the Association Control (AC) function 344 of the RLC 340. A unique MAC ID is configured for broadcast transmissions on the forward link. The broadcast transmission is part of the Forward Transport Channel (F-TCH) and is assigned using the Control Channel (CCH) by using a unique broadcast MAC ID. In this example, a broadcast MAC ID configuration is used, and a system identification message is broadcast every 16 frames. The broadcast data ID can also be used for the user profile broadcast.

A set of one or more MAC IDs can be configured for broadcast transmissions on the forward link. Multicast transmissions are part of the F-TCH and are assigned using the CCH by using a specific multicast MAC ID assigned to a particular multicast group. Assigning a MAC ID to a group of UT groups is handled by the Association Control (AC) function 344 of the RLC 340.

The common MAC 370 shown in Fig. 3 will now be re-explained. The random access control function 378 located at the AP handles access burst approvals from the user. Along with this approval, the AP must immediately perform an R-TCH configuration to obtain buffer status information from the UT. This request is forwarded to scheduler 376.

At the UT, a random access administrator decides when to transmit an access burst based on the data in its MUX queue and its existing configuration. When the UT has a periodic configuration due to an existing LL connection, the existing R-TCH configuration can be used to provide burst status information.

Based on the information contained in the buffer and link state messages received from the UT, the corresponding MUX function 360 located at the AP updates the UT proxy server. The UT proxy server maintains the UT's MUX function buffer status, and scheduler 376 uses these states for R-TCH configuration. The UT proxy server also maintains the maximum transfer rate that the AP transmits to the UT on the F-TCH.

The common MAC function 370 located at the AP implements scheduler 376 to arbitrate the configuration between UTs while efficiently utilizing each MAC frame. In order to limit the additions, it is not necessary to configure a physical layer burst for all active UTs in each frame.

Scheduler 376 can be configured in each MAC frame using the following information:

1. The nominal configuration of each MAC ID. It is possible that only a subset of the active UTs in any frame will be assigned a nominal configuration. For example, only one frame or every fourth frame, etc., will provide a nominal configuration for some UTs. The nominal configuration is determined by the admission control function 384 in the layer administrator 380. In an exemplary embodiment, the nominal configuration will be made in terms of the number of OFDM symbols.

2. Dedicated entity layer add-on (for example, preamble) configuration. The Radio Resource Control (RRC) 342 in the RLC 340 determines the necessary length and periodicity of the dedicated entity layer addition. In an exemplary embodiment, the dedicated physical layer addition includes a dedicated MIMO preamble.

3. Transmission mode and transmission rate. This is determined by the RRC 342 for the R-TCH and is provided to the scheduler 376. For F-TCH, this information is obtained from the UT link and buffer status messages and is attached to the UT proxy server. Be maintained.

4. The data backlog of each MAC ID. Scheduler 376 can obtain this information from the MUX function 360 for each MAC ID of the forward link; and the UT proxy for the reverse link.

In addition, the scheduler also configures the duration of the RCH and determines the duration of the CCH. Each assignment is transmitted on the CCH using one of four encoding mechanisms (according to the channel quality of the UT). Thus, the duration of the CCH is a function of the number of assignments and the encoding mechanism used to transport each assignment.

According to the configuration determined by the scheduler, the MAC entity located in the AP populates each assigned parameter to construct the BCH and CCH. The BCH defines the MAC frame configuration for the transmission channel segments: CCH, F-TCH, R-TCH, and RCH, and also defines CCH combinations for the subchannels, as described above with reference to FIG. An exemplary CCH is described in detail below.

In an exemplary embodiment, each assignment is transmitted on the CCH in one of up to four subchannels (using a different encoding and modulation mechanism for each subchannel, depending on the channel quality of the UT). Multicast and broadcast assignments are transmitted using the strongest encoding mechanism (the first subchannel or subsegment). The MAC entity located on the UT reads the CCH to determine the forward link and reverse link configurations for the frame itself.

At the transmitter, the MAC function is configured to transmit a MAC PDU associated with the particular MAC ID to the physical layer of a particular MAC ID at the F-TCH (at the AP) or R-TCH (at the UT). At the receiver, the MAC function retrieves the MAC PDU corresponding to a MAC ID according to the CCH assignment and passes it to the MUX function of the MAC ID.

MUX

The MUX function 360 will be described in detail below with reference to FIGS. 19 through 23. At the receiver, the MUX function fetches the PDU from the byte stream consisting of consecutive MAC PDUs and routes it to the associated LL, LLC or RLC entity. The path selection is based on the type field (logical channel) contained in the MUX PDU header.

Radio Link Control (RLC)

During system initialization, a Radio Link Control (RLC) function 340 consisting of system identification control functions 346 is initialized. When the UT initiates access to the system using the MAC ID from the access pool, the RLC function assigns a new MAC ID to the UT. Then, if the UT joins a multicast group, an additional multicast MAC ID can be configured.

When a new MAC ID is assigned to a UT, the RLC function initializes an instance of each of the following functions: Association Control (AC) Function 344, Radio Resource Control (RRC) 342, and Logical Link Control (LLC) ) 338. When assigning a new multicast MAC ID, the RLC function initializes a new AC executive and the LLC for the LL multicast mode.

In this exemplary embodiment, the AP uses the broadcast MAC ID to transmit a system identification parameter message every 16 MAC frames. The system identification parameter message contains the network and AP ID and the agreement version number. In addition, the system identification parameter message also contains a list of access MAC IDs used by the UT to initiate access to the system.

AC function 344(a) provides UT authentication; (b) manages UT registration (attach/discharge) function (as for multicast MAC ID, AC function manages multicasting) Group attachment/detachment (attach/detach); and (c) encryption key exchange for LL.

An RRC Execution Individual 342 will be initialized at each UT. An RRC executor of each active UT is initialized at the AP. The RRC functions located at the AP and UT can share forward and reverse link channel metrics (if needed).

RRC(a) manages the calibration of the transmission and reception chains at the AP and UT (the spatial multiplexing transmission mode may require this calibration); (b) determines the transmission mode and transmission rate control for transmissions to the UT And providing the decision result to the MAC scheduler 376; (c) determining the periodicity of the dedicated entity layer addition (eg, the dedicated preamble required for the physical layer burst transmission on the R-TCH and the F-TCH) And length; (d) managing power control to and from the transmission of a UT, and providing power control to the PHY administrator; and (e) determining timing adjustments for R-TCH transmissions from the UT.

Logical link (LL)

The adjustment layer PDU consisting of the user profile is provided to the DLC layer 320 along with the associated MAC ID, LL mode, and data stream ID (if any). The LL mode function 330 adds an LL header and a 3-bit CRC calculated using the entire LL PDU. Several modes are supported in the exemplary embodiment. Deployable Approval 336 and Negative Approval 334 features are available. Accessible broadcast/multicast/unicast function 332 can also be deployed. Based on the illustration, the following four LL modes are listed (the mode format details within the MUX PDU are detailed in Figure 23).

1. Non-connected negative recognition mode (mode 0). In this case, the LL header is null (null). This mode can be used to transfer the adjustment layer PDU in an unobstructed manner. LL mode 0 can be implemented as policing. Broadcast and multicast MAC IDs only provide a non-wired negative recognition (accessibility) mode.

2. Non-wired approval mode (mode 1). This mode is applied to the Transport Adjustment Layer PDU without the additions and delays associated with the LL Mode 3 connection setup. The LL Mode 1 header includes the sequence number of the transmitted LL PDU or the sequence number of the acknowledged PDU. Since the conditioning layer channel is expected to operate in a low random LL PDU loss probability mode and in a low round trip delay mode, a simple Go-Back-N ARQ mechanism is used.

3. Connection-oriented negative recognition mode (mode 2). The LL connection-oriented negative recognition mode allows multiple data streams to be processed by using a stream ID. LL mode 2 can be implemented as the principle of each stream ID. The LL Mode 2 header packet includes the data stream ID and the 12-bit number.

4. Connection-oriented approval mode (mode 3). The LL connection-oriented approval mode allows multiple data streams to be processed by using a stream ID. LL mode 3 can be implemented as the principle of each stream ID. The LL Mode 3 header consists of a stream ID that identifies multiple streams of data transmitted over a reliable connection. A 12-bit serial number identifies the LL PDU, and an ACK field indicates the highest received sequence number that is accepted. As with the discussion of LL Mode 1, a simple Go-Back-N ARQ mechanism is used since the conditioning layer channel is expected to operate in a low random LL PDU loss probability mode and in a low round trip delay mode. However, an alternative repeat ARQ mechanism can also be used.

Logical Link Control (LLC) function 338 manages logical link mode control. When a new LL mode is established, the LLC function provides mode negotiation, including: (a) QoS: guaranteed transmission rate; (b) mode setting; (c) mode deletion (mode) Teardown); (e) mode reset; (f) assignment of data stream IDs in LL modes 2 and 3. The mapping of the end-to-end data stream to an LL mode is determined by the QoS administrator function 382 in the layer administrator 380. The requirements for initializing a new LL mode or adding a data stream to an existing LL mode are from the adjustment layer 310, as described above.

The System Configuration Control 350 manages the configuration of the TDD MAC frame, including the contents of the Beacon and BCH and the length of the RCH.

Layer administrator

The QoS administrator 382 interprets network QoS protocols, including RSVP and RTCP. If the QoS is based on the data stream classification of the IP header, the QoS administrator decides which data classifier to use to identify the different services (ie, IP source and destination addresses, IP source, and destination). Cellar). The QoS administrator assists the adjustment layer by mapping the data stream to the LL mode.

The admission control function 384 receives requests from the LLC for allowing new data streams containing transmission rate requirements. The license control function maintains a database of approved nominal configurations and a set of regulations and thresholds. The admission control function determines whether a data flow can be permitted based on thresholds and regulations, determines the nominal configuration of the data flow (in terms of the amount of transmission time configured per m MAC frames) and provides this information to the common MAC. Scheduler in .

The physical layer administrator uses the physical layer metrics collected at the AP and UT to control the transmitter and receiver parameters of the physical layer. The remote metric can be obtained through the RRC message.

Illustrative procedure

According to the various layer entities described above, using several programs to describe WLAN 120 operates. These programs are not exhaustive programs, but rather illustrate the various functions and components described in this article.

6 illustrates an exemplary method 600 of transmitting a forward link message transmission from an AP. At step 610, the RLC function (association control, radio resource control or logical link control) at the AP places a message (RLC PDU) in the control message queue. Or the LL mode at the AP places an LL PDU into a high QoS queue or a best effort queue.

At step 620, the scheduler configures F-TCH resources for transmitting PDUs in the three MUX queues. At step 640, the assignment is indicated by the MAC on the CCH. At step 650, the MAC located at the AP transmits the message in the MAC PDU in the configured physical layer burst.

FIG. 7 illustrates an exemplary method 700 of receiving a forward link message transmission at a UT. At step 710, the UT monitors the CCH. The UT identifies a configured burst that is directed to the UT. At step 720, the UT retrieves the MAC PDU according to the identification in the CCH. At step 730, the UT reassembles the data stream packet, which contains the fragments retrieved in the MAC PDU and processed in the MAC processor.

8 illustrates an exemplary method 800 of transmitting a reverse link message transmission from a UT. At step 810, the RLC function (association control, radio resource control or logical link control) at the UT places a message (RLC PDU) in the control message queue. Or the LL mode at the UT places an LL PDU into a high QoS queue or a best effort queue. In decision step 820, if the UT has an existing R-TCH configuration, then proceed to step 870. Otherwise, proceed to step 830.

At step 830, the UT transmits a short access burst on the RCH. In the steps 840. The UT receives the RCH access burst grant and access grant configuration on the CCH. At step 850, the UT transmits a link and buffer status message to the AP. At step 860, the UT monitors whether the CCH has an R-TCH grant configuration. At step 870, a configuration is received (or already exists in decision step 820). The UT groups the MUX PDU into a MAC PDU and transmits the MAC PDU in the configured physical layer burst.

9 illustrates an exemplary method 900 of receiving a reverse link message transmission at an AP. At step 910, the AP receives and monitors the RCH. At step 920, the AP identifies a short access burst from the UT. At step 930, the scheduler configures an access grant. At step 940, the AP transmits an admission and access grant on the CCH. At step 950, the AP receives the link and buffer status message on the R-TCH in response to the grant grant. At step 960, the AP uses the buffer status to update the UT proxy server. The scheduler has access to this information. At step 970, the scheduler configures the R-TCH resource. At step 980, the AP receives the MAC PDU as configured. At step 990, the AP responds to one or more received MAC PDUs to perform reassembly of a data stream packet.

10 illustrates an exemplary method 1000 in which a UT performs initial access and registration. In step 1010, the UT acquires a preamble from the frequency on the BCH to obtain the frequency and timing. At step 1020, the UT receives system identification information from the RLC broadcast message. At step 1030, the UT uses the long burst from the BCH to determine the RCH configuration for (non-time slot) random access. At step 1040, the UT randomly selects a MAC ID from the set of starting MAC IDs. At step 1050, the UT transmits a long random access burst on the RCH using the starting MAC ID. At step 1060, the UT receives an acknowledgement, a MAC ID in the subsequent MAC frame. Assignment and a timing adjustment. At step 1070, the UT association control function and the AP association control function complete the authentication and key exchange sequence. The control message transmission on the forward and reverse links follows the low level messaging procedure described above with reference to Figures 6-9.

11 illustrates an exemplary method 1100 for an AP to perform initial access and registration. At step 1110, the AP receives a long random access burst from the UT on the RCH. At step 1120, the AP assigns a MAC ID to the UT. The MAC ID pool is managed by the radio link control function. At step 1130, the AP assigns a timing adjustment to the UT. At step 1140, the AP transmits an acknowledgement, MAC ID, and timing adjustment on the CCH. At step 1150, the AP association control function and the UT association control function complete the authentication and key exchange sequence. The control message transmission on the forward and reverse links follows the low level messaging procedure described above with reference to Figures 6-9.

FIG. 12 illustrates an exemplary method 1200 of an AP user data stream. In step 1210, the QoS administrator in the layer administrator fills in the data flow classification function into the data flow classification function. A specific combination of parameters and values can indicate the arrival of a new data stream. These parameters may include: IP DiffSery Code Point (DSCP), IP source address or IP port. The Ethernet parameters may include: 802.1Q VLAN ID or 802.1p priority indication. The specific IP threshold may indicate a control agreement message (eg, RSVP or RTCP) to be forwarded to the QoS administrator.

At step 1215, the AP determines the license parameters. When a packet arrives at the AP adjustment layer and is classified as a new data stream by the data flow classification, the data flow classification works with the QoS administrator to determine the license parameters, including configuring the data flow. QoS class (high QoS or best operation), LL mode and nominal transmission rate. In decision step 1220, the admission control in the layer administrator determines whether the data flow can be permitted based on their permission parameters. If not allowed, the program stops. Otherwise, proceed to step 1225.

At step 1225, the data flow classification requires the LLC to construct a new data stream. In this discussion, the case of high QoS and LL mode 3 connections will be considered. At step 1230, the LLC located at the AP communicates with the LLC located at the UT to establish a connection (or, if the applicable connection already exists, establish a new data stream ID). In this example, their LLC will attempt to build an LL Mode 3 connection (or, if the applicable LL Mode 3 connection already exists, a new Stream ID). At step 1235, the nominal transmission rate configured for the data stream is communicated to the scheduler. In the case of LL mode 3, the nominal transmission rate is configured on the forward channel and the reverse channel.

At step 1240, the data flow classification is performed: classifying the packet of the data stream; identifying the MAC ID, the LL mode, and the data stream ID; implementing the data flow principle; and forwarding the conforming packet to the SAR function. At step 1245, the SAR split packet becomes a fragment and the adjustment layer PDU is forwarded along with the LL mode and the stream ID to the LL function of the MAC ID. At step 1250, the LL function appends the LL header and CRC and places the LL PDU in the appropriate queue. In this example, the LL Mode 3 function appends the LL header and CRC and places the LL PDU in the high QoS queue of the MUX.

At step 1255, the MUX prepares the MUX PDU by appending a MUX header for identifying the LL mode and length. The MUX establishes a MUX indicator for indicating the number of bytes to the beginning of the first new MUX PDU.

At step 1260, the scheduler determines the F-TCH (physical layer burst) configured for the MAC ID. The scheduler knows which transmission mode to use (from RRC) and the transmission rate (from the UT proxy). Note that a reverse link configuration can also be included. At step 1265, the configuration is transmitted on the CCH.

At step 1270, the MAC transmits a MAC PDU. The MAC PDU consists of the following items: the MUX indicator, followed by a possible local MUX PDU at the beginning, followed by zero or more complete MUX PDUs, and finally a possible locality at the end of the physical layer. MUX PDU.

FIG. 13 illustrates an exemplary method 1300 of a UT user data stream. At step 1310, the UT receives the configuration on the CCH. At step 1320, the UT receives the MAC PDU in accordance with the configuration. At step 1330, the MUX at the UT retrieves the MUX PDU by using the MUX indicator and the length field in the MUX header, and prepares the LL PDU. At step 1340, the MUX transfers the LL PDU to the appropriate LL function (LL mode 3 in this example) according to the type field in the MUX header. At step 1350, LL Mode 3 performs an ARQ Receiver and calculates the CRC for each LL PDU. At step 1360, LL Mode 3 at the UT must transmit ACK/NAK to the LL Mode 3 ARQ located at the AP. The ACK/NAK is placed in the high QoS queue at the UT MUX. Please note that other LL modes may not include approval as described above.

At step 1370, the AP transmits the ACK/NAK on the R-TCH in accordance with the configuration. As mentioned above, the scheduler configures the R-TCH resource for the MAC ID based on the nominal configuration of the reverse link. The ACK/NAK message is transmitted in the MAC PDU on the reverse link physical layer burst from the UT. At step 1380, the UT may transmit any other queues that have been queued in the remaining configurations. Reverse link data.

Referring again to FIG. 3, as described above, the data stream 260 is received at the AP MAC processor 220, and the corresponding data and signaling numbers travel down through the conditioning layer 310, the data link control layer 320, and the physical layer so that Transfer to UT. The physical layer 240 located at the UT receives the MAC PDU, and the corresponding data and signaling numbers travel upward through the data link control layer 320 and the adjustment layer 310 physical layer in the UT MAC processor 220, and the reorganized data stream is transmitted to One or more layers of a higher level (ie, various processing sequences, including data, voice, video, etc.). For data streams originating from the UT and transmitted to the AP, similar processing sequences occur in reverse order.

The respective layer administrators 380 can be deployed in the AP and UT, thereby controlling how information flows up and down to each MAC sublayer. In general, layer administrator 380 can use any type of feedback 280 from physical layer 240 to perform various sub-layer functions, and physical layer administrator 386 interfaces with physical layer 240. Any of the layers administrators (examples include license control function 384 and QoS administrator 382). Then, their functions can interact with any of the sub-layer functions described above.

The principles described in this article can be deployed in conjunction with any physical layer specification that supports multiple transport formats. For example, many physical layer formats allow for multiple transfer rates. The amount of delivery of any given physical link can be determined by available functions, channel interference, supported modulation formats, and the like. Exemplary systems include OFDM systems and CDMA systems that employ MIMO technology. In these systems, closed loop techniques are used to determine the transmission rate and format. The closed loop can use various messages or signals to indicate channel metrics, support transmission rates, and the like. Those skilled in the art can easily adjust these and other systems to deploy this The technique described in the text.

Physical layer feedback can be used in the adjustment layer 310. For example, transmission rate information can be used in split and reassemble, data stream classification, and multicast mapping. 14 illustrates an exemplary method 1400 of incorporating physical layer feedback into an adjustment layer function. This method is described in terms of access points, but this method can be applied in a similar manner to the user terminal. The process begins in step 1410, where the data stream packet to be transmitted to the user terminal is received. At step 1420, the adjustment layer function is performed in response to the physical layer feedback of the respective user terminal. To further illustrate this aspect, exemplary embodiments of exemplary multicast mapping and segmentation are described in detail below. At step 1440, physical layer feedback of one or more user terminals is monitored. The process returns to step 1410 to repeat the procedure for the additionally received data stream packets in response to the updated entity layer feedback.

In an alternate embodiment, transmission rate information fed back by other entity layers may be used in the admission control decision process. For example, a high QoS data stream is not granted unless the target MAC ID entity layer is capable of supporting a sufficiently high efficiency level of transmission rate. This level can be adjusted based on system load (including the nominal configuration of existing streams, the number of registered UTs, and the like). For example, a UT with a relatively high quality link is more likely to be configured to a high QoS data stream than a MAC ID associated with a lower quality link. If the system is under a small load, the threshold requirement can be reduced.

Adjustment layer multicast

FIG. 15 illustrates an exemplary method 1500 of performing an adjustment layer multicast. Tuning layer multicasting is an example of method 1400 for incorporating physical layer feedback To the adjustment layer function. As described above, a multicast transmission, MAC layer multicast method provides a common MAC ID corresponding to a list of user terminals, the common or multicast MAC ID being distinguished from the user terminal MAC ID. Thus, when a UT is assigned to one or more multicast groups, the UT will monitor whether the CCH is directed not only to the associated MAC ID but also to one or more multicasts associated with the UT. The transmission of the MAC ID. Thus, a multicast multicast MAC ID may be associated with one or more higher layer data streams, thereby allowing a single data stream to be transmitted to multiple user terminals.

In the adjustment layer multicast, one or more additional transmission multicast data may be performed to their user terminals if a single transmission for receiving by all user terminals in a multicast list is not performed. One or more user terminals. In a particular embodiment, the adjustment layer multicasts a unicast transmission to be transmitted to each of the user terminals in the multicast group. In an alternate embodiment, the adjustment layer multicast may perform one or more MAC layer multicast transmissions using one or more MAC IDs associated with a subset of the multicast groups. The unicast transmissions can be directed to user terminals not included in one of their subgroups. Any combination as described above can be deployed. At step 1510, a multicast data stream directed to a list of user terminals is received. In a specific embodiment, a MAC ID is associated with the list of user terminals.

At decision step 1520, it is determined whether the efficiency of the unicast transmission is higher than the efficiency of the multicast transmission (i.e., multiple users receive a single transmission) for the user terminal transmitted to the list. If the efficiency of the unicast transmission is higher than the efficiency of the multicast transmission, then at step 1530, in two or two The unicast transmission is transmitted on the above channel. Two or more of these channels may include unicast channels, other multicast channels, or a combination of both. At decision step 1520, if the multicast transmission is more efficient, the multicast MAC ID is used to broadcast the multicast material to the members of the multicast group in a single transmission.

In general, the format used for multicast transmissions must be suitable for transmission on the weakest physical link among the user terminal entity link groups in the multicast group. In some systems, the minimum common denominator transmission is still necessary to be delivered to the user terminal using the lowest quality physical link, so in fact, it is better to benefit from higher transmission rates and higher throughput. The user terminal in the situation does not affect the system throughput. However, in other cases, it will not remain applicable. For example, consider the spatial processing used in MIMO systems. Multicast group members may be scattered throughout the coverage area, and two or more members will have very different channel characteristics. Consider an illustrative example of a multicast group containing two user terminals. By cooperating with the transmission format of each user terminal, a high throughput for unicast transmission to each user terminal can be achieved. However, since the two channel environments for each physical link are completely different, the transmission format suitable for transmitting a single multicast message to each user terminal may be lower than that of any unicast channel. . When the difference between the multicast channel and the unicast channel throughput is large enough, the system transmits two multicast data using less resources than the single message that the two parties can receive.

Figure 16 shows whether to decide whether to use the adjustment layer multicast or use MAC multipoint An exemplary method of broadcasting, the method is suitable for deployment in step 1520. At step 1610, the link parameters for each user terminal in the multicast list are received. In a specific embodiment, a transmission rate parameter can be used. At step 1620, a link parameter for a multicast channel suitable for transmission to a user terminal in the multicast list is received. The link parameters of the multicast channel may be different from the link parameters for any and all individual channels of the user terminal in the multicast group. At step 1630, the system resource requirements for the sum of the system resource requirements (i.e., the single transmission uses the multicast MAC ID) and the individual unicast transmissions for transmission on the multicast channel are compared. The lowest system resource requirements can be used to determine the most efficient choice.

In an alternate embodiment, step 1610 can be modified to include link parameter MAC layer multicast channels (including sub-groups of multicast group user terminals). It can compare the combination of multicast and unicast and pure MAC layer multicast. These and other modifications of the invention will be apparent to those skilled in the art.

Physical layer feedback segmentation

FIG. 17 illustrates an exemplary method 1700 of performing segmentation in response to entity layer feedback. This is another example of method 1400 for incorporating physical layer feedback to the adjustment layer function. This procedure can be implemented in the segmentation and reassembly function 312 in the adjustment layer 310 in response to the entity layer feedback provided by the layer administrator 380.

At step 1710, a data stream packet to be transmitted to the corresponding MAC ID is received. At step 1720, the transmission rate information corresponding to the MAC ID is retrieved. At step 1730, the packet is split into segments to respond to the MAC ID transmission rate. In one In an exemplary embodiment, the splitting operation produces a plurality of segments 420 that are used to generate an entity sub-layer PDU 430, as described above with reference to FIG.

FIG. 18 illustrates an exemplary method of segmentation in response to a transmission rate. This method is suitable for deployment in step 1730 as explained in the previous paragraph. The program begins at decision step 1810. If the transmission rate has changed, proceed to decision step 1820. If the transfer rate has not changed, the program stops and the split size remains unchanged.

At decision step 1820, if the transmission rate change is an increase in the transmission rate, there may be a gain associated with increasing the fragment size. For example, as shown in Figure 4, each segment receives a layer of add-ons as it travels to the stack. Reducing the number of clips reduces the amount of added items you need. In addition, higher transmission rates usually mean higher quality channels. When a channel changes eagerly over time, it is possible that the average value of a channel remains relatively constant during a certain segment time. The transmission rate increases and the fragment size increases correspondingly, allowing an amount of time to transmit a segment to be about the same as the smaller segment size of the slower transmission rate. If this amount of time is proportional to the time when a channel tends to remain relatively stable (ie, the supported transmission rate is unchanged), increasing the fragment size may allow for increased efficiency and there may be no negative impact of increased fragment size.

Another consideration is to choose a fragment size when a physical layer transfer rate change has occurred. The change in transmission rate causes the fragment size to be changed, and the service delay condition constraint of the shortest delay condition constraint requirement (or control message queue) is satisfied by the non-preemptive priority order in the MUX function. Referring to FIG. 19 to FIG. 23 will be explained in detail.

Various techniques for selecting fragment sizes can be incorporated within the scope of the present invention. Referring back to FIG. 18, in this exemplary embodiment, in decision step 1820, when a transmission rate change occurs, proceeding to step 1830 to increase the adjustment sub-layer PDU size. At decision step 1820, if the transmission rate change is a decrease in transmission rate, then proceed to step 1840 where the adjustment sub-layer PDU size is reduced in accordance with any of the techniques discussed in the preceding paragraph.

The method shown in FIG. 18 is mainly used to illustrate a feasible mechanism for performing segmentation using a relationship between a physical layer transmission rate and a segmentation segment size. In an alternate embodiment, a segment size table can be generated, each segment size being associated with a transmission rate or transmission rate range. In another embodiment, a function can be deployed, an operand transfer rate of the function, and the output of the function produces a fragment size table. According to the content of this article, those who are familiar with this technology should understand that there are other feasible solutions. Note that as described in the previous paragraphs, the segmentation may be combined with a multicast mapping technique (as described above with reference to Figures 14-16), as well as any other layer adjustment functions performed in response to entity layer feedback.

Multiple processing

In an exemplary high efficiency wireless LAN subnet (e.g., wireless network 120), all communication occurs between the AP 104 and one or more UTs 106. As mentioned above, the nature of these communications may be unicast or multicast. In unicast communication, user data or control data is transmitted from the AP to a single UT or from the UT to the AP. Each UT has a unique MAC ID, so all unicast communication between the UT and the AP is associated with the unique MAC ID. In multicast communication, user profile or Control data is transmitted from the AP to multiple UTs. A MAC ID pool will be set up as a multicast address. There may be one or more multicast groups defined to be associated with an access point, and each group is assigned a unique multicast MAC ID. Each UT may belong to one or more of its multicast groups (or not belong to any group) and will receive transmissions associated with each multicast group to which it belongs. For the purpose of multiplex processing discussion, the adjustment layer multicast is considered as unicast. In this example, the UT does not transmit multicast material.

An access point receives user data from an external network (ie, network 102) addressed to a UT within its coverage area, and receives information from the UT within the coverage area that is directed to other devices (possibly the coverage area) User data within the UT, or UT attached via the network. An access point may also generate predetermined or multiple UTs within its coverage area from Radio Link Control (RLC) function 340, Logical Link Control (LLC) function 330, and other entities. The user data addressed to a single UT can be segregated into several data streams based on QoS considerations or other considerations (eg, source applications), as described above.

As mentioned above, finally, the access point aggregates all data destined for a single MAC ID from all sources into a single byte data stream, which is then formatted into several MAC PDUs, each MAC PDUs are transmitted in a single MAC frame. The access point may transmit one or more MAC PDUs of the MAC ID in a single MAC frame (ie, on the forward link).

Similarly, the UT can have a payload to be transmitted that can be isolated into several streams. User information. The UT may also generate control information associated with RLC 340, LLC 330, or other entities. The UT aggregates the user data and the control data into a tuple stream, and then the byte stream is formatted into a number of MAC PDUs, each of which is transmitted to the AP in a single MAC frame. One or more UTs may transmit a MAC PDU (ie, on the reverse link) in a single MAC frame.

The MUX function 360 is implemented by pressing the MAC ID at the AP. Each UT is initially assigned a MAC ID for unicast transmission. If the UT belongs to one or more multicast groups, an additional MAC ID can be assigned. The MUX function permits (a) to treat a contiguous entity layer burst configuration configured for a MAC ID as a one-tuple data stream; and (b) multiplex PDU processing from one or more LL or RLC entities into a MAC. The byte stream.

FIG. 19 illustrates an exemplary method 1900 of transmitting multiple data streams and commands in a single MAC frame. This method is suitable for deployment in an access point or user terminal. The program begins at decision step 1910. If one or more packets of one or more data streams destined for a MAC ID are received, proceed to step 1920 where the MUX associated with the MAC ID is prepared for each one or more data streams. PDU. In this exemplary embodiment, the MUX PDU is prepared in accordance with the MAC protocol described above, but alternative MAC protocols may be deployed within the scope of the present invention. The MUX PDUs can be placed in an appropriate queue (in an exemplary embodiment, a high QoS queue or a best working queue). If the data stream of the MAC ID is not received in step 1910, then after the MUX PDU has been prepared in step 1920, proceed to decision step 1930.

At decision step 1930, if one or more from RLC 340 or LLC 330 The commands are to be transmitted to the UT associated with the MAC ID, then proceed to step 1940 and prepare a MUX PDU for each command PDU. If there is no command to the MAC ID, or if the MUX PDU has been prepared in step 1940, then proceed to decision step 1950.

Decision step 1950 illustrates a repetitive process for continuously monitoring the flow of data destined for a MAC ID. Alternate embodiments may place a loop function in the entire access point or any other portion of the user terminal processing sequence. In an alternate embodiment, the program 1900 repeats repeatedly or is included in other repetitive processing sequences. This processing sequence is described in terms of a single MAC ID for illustrative purposes only. Obviously, multiple MAC IDs can be processed simultaneously in an access point. These and other modifications of the invention will be apparent to those skilled in the art.

When there are no commands or streams ready to be processed, in this example, the processing loop will return to decision step 1910 to repeat the loop. Please note that in the user terminal, the request to initiate a MAC frame configuration must be presented to the access point, as described above. Any such technology can be deployed. No details are included in Figure 19. Obviously, if there are no commands or data streams waiting to be transmitted, no request is required, so no MAC frame configuration will arrive. When a command or data stream is waiting for transmission, the scheduler will perform a MAC frame configuration at any time, as described above. In this exemplary embodiment, an access point scheduler 376 performs a forward link MAC frame configuration in response to a MAC ID queue in the UT-specific MUX function 360 and performs a reverse link MAC. The frame is configured to respond to requests for RCH or UT proxy servers, as described above. In any case, execute method 1900 The communication device will wait for a MAC frame configuration at decision step 1950.

When a MAC frame configuration is performed in decision step 1950, one or more MUX PDUs are placed in a single MAC PDU in step 1960. The MAC PDU may include a local MUX PDU 464 remaining from the previous MAC frame, a MUX PDU from one or more data streams, one or more command MUX PDUs, or any combination thereof. If any of the configured space is still unused, a partial MUX PDU can be inserted into the MAC frame (or any type of padding can be inserted to fill the configured MAC frame).

At step 1970, the MAC PDU is transmitted on the physical link at the location indicated by the configuration. Note that the MAC PDU may include MUX PDUs from any combination of one or more data streams or command PDUs.

As described above, in this exemplary embodiment, on an F-TCH or R-TCH, the MAC PDU is a transmission unit suitable for assignment to a physical layer of a MAC ID. Figure 20 depicts an exemplary case. A MAC PDU 460 is comprised of the following items: a MUX indicator 462, followed by a possible local MUX PDU 464 at the beginning, followed by zero or more full MUX PDUs 466, and finally a physical layer burst. A possible local MUX PDU 468 at the end. Please note that the respective portions of two consecutive MAC frames 460A and 460B are shown. The sub-portions of the MAC frame 460A transmitted during the frame f are identified by an additional "A". The sub-portions of the MAC frame 460B transmitted during frame f+1 are identified by an additional "B". When multiple MUX PDUs are serially connected in a MAC PDU, a partial MUX PDU may be transmitted at the end of the MAC PDU. In this case, The remainder of the MUX PDU is transmitted at the beginning of the MAC PDU transmitted in the next MAC frame. The partial MUX PDU 468A transmitted in the MAC frame 460A is illustrated in FIG. The remainder of the MUX PDU 464B will be transmitted during the next MAC frame 460B.

The MAC header consists of a MUX indicator 2020 and a MAC ID 2010 that may be associated with a MAC PDU. When space multiplex is being used, a MAC ID may be required and there may be more than one MAC PDU transmitted simultaneously. Those familiar with this technology should know when to deploy MAC ID 2010, which is shaded to indicate these options.

In this exemplary embodiment, a 2-bit MUX indicator 2020 per MAC PDU is deployed to identify the location of any MUX PDUs transmitted in the MAC frame (as in Figure 20 from MUX Indicator 2020 to MUX PDU 466A). The arrow shows). The MUX indicator 2020 is used for every MAC PDU. The MUX indicator points to the beginning of the first MUX PDU in the MAC PDU. The MUX metric, along with the length field included in each MUX PDU, allows the recipient MUX layer to retrieve LL and PLC PDUs from the byte data stream (composed of contiguous entity layer bursts configured to the MAC ID). Those skilled in the art will appreciate that various alternative means for deploying indicators are within the scope of the present invention. For example, from the examples described above, the MAC frame can be encapsulated in an alternate order. A number of local MUX PDUs can be placed at the end of the MAC frame configuration, and the indicator points to the beginning of the remainder, rather than to the new MUX PDU. Therefore, new PDUs (if any) are placed at the beginning. Several indicator techniques can be deployed (ie, an index value for identifying a tuple, a time value, a base value plus a displacement, or any knowledge known to the skilled artisan Multiple change programs).

In this exemplary embodiment, the MUX indicator 2020 includes a single 16-bit field, the value of the field being 1 plus the end of the MUX indicator starting at the beginning of the first MUX PDU at the beginning of the frame. Displacement (in bytes). If the value is 0, there is no MUX PDU for the start frame. If the value is 1, the MUX PDU will immediately start after the MUX indicator. If the value is n>1, the first n-1 bytes in the MAC PDU are the end of the MUX PDU starting at the previous frame. This information helps the receiver MUX (i.e., MUX function 360) to recover from previous frame errors that result in synchronization of the MUX PDU boundary loss. Those skilled in the art should understand that any number of alternative indexing techniques can be deployed.

A MUX header containing a type (logical channel) field and a length field is appended to all LL or RLC PDUs provided to the MUX. This type (logical channel) field identifies the LL or RLC entity to which the PDU belongs. As explained in the previous paragraph, the length field is used in conjunction with the MUX indicator to allow the receiver MUX layer to retrieve LL and PLC from the byte data stream (consisting of a contiguous entity layer configuration configured to the MAC ID). PDU.

As described above, the MUX function 360 maintains three queues for the data to be transmitted. The high QoS queue 362 can include an LL PDU associated with a negotiated service that has configured a guaranteed transmission rate for the negotiated service. The best working queue 364 may contain LL PDUs associated with a transmission rate guarantee. Control message queue 366 can include RLC and LLC PDUs.

Alternate embodiments may include more than one QoS queue. However, as described herein, high efficiency using high transmission rate WLANs allows for a single QoS queue. Achieve excellent QoS performance. In this case, the efficient use of the available channel bandwidth by the MAC protocol provides unnecessary extra queues and associated complexity.

At the AP, the backlog in each queue is made available to scheduler 376 in the common MAC function 370. At the AP, the backlogs in the queues at the UT are maintained in the UT proxy server of the MUX function 360. Please note that, based on simplicity and clarity, the UT proxy server queues are not independently depicted in Figure 3.伫 362, 364, and 366 can be considered to include a forward link queue and a reverse link queue for each MAC ID (ie, a UT proxy queue), whether shared FW or separate. Whether or not they are deployed in the component. Note that the number and type of supported forward link queues and reverse link queues do not need to be identical. The UT proxy server (proxy) queue does not need to match the UT queue exactly. For example, the UT can maintain a command queue to prioritize certain time-sensitive commands over other high QoS PDUs. At the AP, a single high QoS can be used to indicate the requirements for both types of UT traffic. Therefore, the configuration of the UT can be padded using the priority order determined at the UT. As another example, different QoS queues can be maintained at the UT or AP, and the QoS queue of the other party is not maintained at the AP or UT.

Scheduler 376 arbitrates the contention requirements from all MAC IDs and configures a physical layer burst to one or more selected MAC IDs on the F-TCH or R-TCH. In response to a configuration, the corresponding MUX function 360 encapsulates the LL and RLC PDUs into a MAC PDU packet bearer, as described above. In this exemplary embodiment, each MUX function 360 will be in the following non-preemptive priority order. (Completely) Serving the PDUs from the following queues: Control Message Array 366, High QoS Array 362, and Best Operation Queue 364. Any local PDUs from previous MAC PDUs are completed prior to servicing new PDUs from the higher priority queue (even if the local PDUs are from a lower priority queue). In an alternate embodiment, preemptive prioritization may be deployed at one or more levels, as is known to those skilled in the art.

At the receiver, the MUX function retrieves the PDU from the byte stream consisting of consecutive MAC PDUs and routes it to the associated LL or RLC entity. The path selection is based on the type field (logical channel) contained in the MUX PDU header.

In this exemplary embodiment, according to the design of the MUX function, once the MUX PDU has been transmitted, the transmission is completed before another MUX PDU can be started. Therefore, if a MUX PDU from the best working queue is started to be transmitted in a MAC frame, the transmission will be completed in a subsequent MAC frame (or multi-frame) before the control message is transmitted. Other MUX PDUs in the queue or high QoS queue. In other words, in normal operation, the higher category queue has a non-preemptive priority.

In an alternate embodiment, or in certain instances of this exemplary embodiment, it may be desirable to use preemptive prioritization. For example, if the physical layer data transfer rate has changed, it may be necessary to urgently transmit a control message, which requires prioritization over the best work or high QoS MUX PDUs. This is a permitted practice. The receiver MUX will detect and discard the MUX PDUs that are not fully transmitted, as described in further detail below.

Preemptive events (ie, physical layer transfer rate changes) can also trigger changes The fragment size used by the UT. The fragment size used by the UT can be selected to facilitate the service delay condition constraint of the shortest delay condition constraint or control message queue by non-preemptive priority order in the MUX function. These techniques can be combined with the segmentation techniques described above with reference to Figures 17-18.

21 illustrates an exemplary method 2100 of preparing a MAC frame using MUX metrics. This method can be deployed in an AP or UT. This illustrative example can be readily adapted to fit a number of specific embodiments (AP or UT) in light of the teachings herein. The process begins in step 2110 where a configuration for a MAC PDU is received.

At decision step 2120, if the local MUX PDU from the previous MAC frame is still present, then proceed to decision step 2130. If no local MUX PDU exists, then go to step 2150.

At decision step 2130, if a preemptive priority order is desired, the local MUX PDU is not transmitted. The program proceeds to step 2150. In this exemplary embodiment, preemptive priority order may be used in some cases to transmit a time-sensitive command MUX PDU. Other examples of preemptive prioritization have been detailed above. Any preemptive condition can be used when it is desired to abandon the remainder of the transmission of the MUX PDU. The receiver of the MAC frame can directly discard the front part of the MUX PDU. Exemplary receiver functions are described in detail below. In an alternate embodiment, preemptive priority may be defined to allow MUX PDUs with preemptive priority to be transmitted at a later time. Any number of preemptive priority specifications may be deployed in place of the specific embodiment for use in decision step 2130. If the preemption priority is not desired, then go to step 2140.

At step 2140, the local MUX PDU is first placed in the MAC PDU. If the configuration is less than the local MUX PDU, the configuration can be padded with the desired number of MUX PDUs and the remainder can be stored for transmission in subsequent MAC frame configurations.

At step 2150, any new MUX PDUs can be placed in the MAC PDU. The MUX function determines the priority order for placing MUX PDUs from any available queue. An exemplary prioritization mechanism has been described above, however any prioritization mechanism can be deployed.

At step 2160, the MUX indicator is set to the location of the first new MUX PDU. In this exemplary embodiment, a zero value MUX indicator means that no MUX PDUs are included in the configuration. The 1-value MUX indicator means that the first byte following the MUX header is the beginning of the next new MUX PDU (ie, there are no local MUX PDUs at the beginning of the MAC PDU). Other MUX indicator values indicate the appropriate boundary between a remainder of the local MUX PDU and the beginning of any new MUX PDU. In alternative embodiments, other special MUX indicator values may be defined, or an indicator value indicator mechanism may be deployed.

At step 2170, if there is still space in the configured MAC PDU, then a partial MUX PDU can be placed in the remaining space. Alternatively, any class class fill item can be inserted in the remaining space. The remainder of a partially placed MUX PDU can be stored for transmission in subsequent frame configurations.

22 illustrates an exemplary method 2200 of receiving a MAC frame containing MUX metrics. This method can be deployed in an AP or UT. This illustrative example can be readily adapted to fit a number of specific embodiments (AP or UT) in light of the teachings herein.

The program begins at step 2210 where a MAC PDU is received. At step 2215, the MUX indicator is retrieved from the MAC PDU. At decision step 2220, if the MUX indicator is greater than 1, then proceed to step 2225. In this exemplary embodiment, if the MUX indicator is 0 or 1, there are no local MUX PDUs at the beginning of the MAC frame. The 0 value MUX indicator indicates that there are no MUX PDUs. In either case, proceed to decision step 2230.

At decision step 2230, if a local MUX PDU from the previous MAC frame is stored, then proceed to step 2235 and discard the previous frame. In this example, the remainder of the stored frame has been prioritized. Alternate embodiments may allow for subsequent transmission of the remainder of the stored frame, in which case the previous partial MUX PDU may be stored (details not shown in detail in the illustrative exemplary method 2200). At decision step 2230, if no local MUX PDUs are stored, or if the stored previous partial MUX PDUs are to be subsequently processed, then proceed to step 2240.

At step 2240, a new MUX PDU is retrieved at the beginning of the location indicated by the MUX indicator. Please note that in this exemplary embodiment, the zero value MUX indicator means that there are no new MUX PDUs in the MAC PDU. Any new MUX PDUs can be retrieved, including a new local MUX PDU. As described above, the length field in the MUX PDU header can be used to define the boundaries of the MUX PDU.

At decision step 2245, if a partial MUX PDU is included in the MAC PDU, then proceed to step 2250 to store the local MUX PDU. The stored local MUX PDU may be combined with the remainder from a future MAC PDU (unless it is later determined that the local MUX PDU should be discarded, as described above). in Decision step 2245, if no new local MUX PDUs are included in the MAC PDU, or if the local MUX PDU has been stored in step 2250, proceed to step 2255.

At step 2255, any complete MUX PDUs may be passed for further processing in the contract heap, including reorganization (if appropriate), as described above.

As mentioned above, the MUX function allows multiplexing to process logical channels (F-TCH and R-TCH) within the traffic channel segment defined on the MAC frame. In this exemplary embodiment, the logical channel processed by the MUX function is identified by the 4-bit message type field in the MUX header. Table 1 details this example.

FIG. 23 illustrates exemplary MUX PDUs of several MUX types listed in Table 1. User data channel PDUs (UDCH0 2310, UDCH1 2320, UDCH2 2330, UDCH3 2340) can be used to transmit and receive user data. The PDU can be formed as described above with reference to FIG. Each PDU includes a MUX header containing a type and length field. The items following the MUX header are: LL header, 1-bit AL header, up to 4087 byte data, and a 3-bit CRC. For UDCH0 2310, LL standard The header is 1 byte. For UDCH1 2320, the LL header is 2 bytes. For UDCH2 2330, the LL header is 3 bytes. For UDCH3 2340, the LL header is 4 bytes. The logical layer functions for handling the types of their LL PDUs have been detailed above.

Various control message PDUs 2350-2370 are also depicted in FIG. Each PDU includes a MUX header containing a type field, a reserved field, and a length field. The item following the MUX header is a variable length data field, which may be between 4 and 255 bytes and includes the RLC message packet bearer. A Radio Link Broadcast Channel (RBCH) PDU 2350, a Dedicated Control Channel PDU (DCCH) PDU 2360, and a Logical Link Control Channel (LLCH) PDU 2370 are shown in FIG. . The format of the User Broadcast Channel (UBCH) PDU and the User Multicast Channel (UMCH) PDU is exactly the same as the UDCH0 PDU 2310. The type field of UBCH is set to 0111. The type field of the UMCH is set to 1000.

Those skilled in the art should understand that their PDUs are for illustrative purposes only. A variety of additional PDUs as well as a subset of the illustrated PDUs can also be supported. In an alternate embodiment, each of the fields depicted may have an alternate width. Other PDUs also contain additional fields.

Exemplary Radio Link Control (RLC)

Radio link control 340 has been described above, and exemplary embodiments are further detailed in this paragraph. Table 2 presents a set of exemplary RLC messages. The exemplary messages described are merely demonstrations, A subset of their messages and additional messages can be deployed in the example. The size and type of fields in each message are also exemplary. According to the content of this article, those skilled in the art can easily adjust many alternative message formats.

In this example, all RLC messages have a common structure, but they can be uploaded on one of several transmission channels. The RLC PDU structure includes: an octet type field for identifying a specific RLC message; a packet consisting of 0 to 251 bytes; and a CRC field consisting of 3 bytes. . Table 3 illustrates the use of the bit portion in the type field to indicate a type of RLC message. The most significant bit (MSB) 0 or 1 indicates a forward link message or a reverse link message, respectively. When the second MSB is set, the message is a negative acknowledgement (NACK) or rejection message.

During system initialization, the broadcast RLC function consisting of the system identification control function 346 is initialized. When the UT initiates access to the system using the MAC-ID from the access pool, the RLC function assigns a new MAC-ID to the UT. Then, if the UT joins a multicast group, an additional multicast MAC-ID can be configured. When a new MAC-ID is assigned to a UT, the RLC function initializes an instance of each of the following functions: AC 344, RRC 342, and LLC 338, as described above. When assigning a new multicast MAC-ID, the RLC function initializes a new AC executive and the LLC for the LL multicast mode.

The AP will use the broadcast MAC-ID to transmit a system identification parameter message (listed in Table 4) once every 16 MAC frames. The system identification parameter message contains the network and AP ID and the agreement version number. In addition, the system identification parameter message also contains a list of access MAC-IDs used by the UT to initiate access to the system. Table 4 lists other exemplary parameters.

The Association Control (AC) function provides UT authentication. The AC function manages the registration (ie, attach/detach) function of the UT. As for the multicast MAC-ID, the AC function manages a UT add/drop multicast group. The AC function also manages the encryption key exchange for LL control.

A Registration Challenge Message is transmitted on the reverse link from the UT, as shown in Table 5. The UT includes a 24-bit random number to allow the AP to distinguish between multiple UTs that have access rights and pick the same MAC-ID.

The Registration Challenge Acknowledgement Message (as shown in Table 6) is transmitted by the AP in response to the registration challenge message. The AP includes a random ID transmitted by the UT. This allows for resolution of conflicts between UTs that have picked the same MAC-ID and access slot.

A Registration Challenge Reject Message (as shown in Table 7) is transmitted by the AP to a UT to reject the temporary MAC ID assignment, for example, when two or more UTs randomly select the same temporary MAC ID.

The hardware ID Request Message (as shown in Table 8) is transmitted by the AP to obtain the hardware ID from the UT.

The Hardware ID Request Acknowledgment Message (as shown in Table 9) is transmitted by the UT in response to the hardware ID. Request message and include the 48-bit hardware ID of the UT. (In particular, the 48-bit IEEE MAC address that the UT can use).

A System Capabilities Message (as shown in Table 10) is transmitted to the newly registered UT to indicate the AP function to the UT.

A System Capabilities Acknowledgment Message (as shown in Table 11) is transmitted by the UT in response to the system function message, thereby indicating the UT function to the AP.

A radio resource control RRC enforcement entity will be initialized at each UT. An RRC executor of each active UT is initialized at the AP. The RRC functions located at the AP and UT can share forward and reverse link channel metrics (if needed). The RRC manages the calibration of the transmission and reception chains at the AP and UT. In this example, calibration is helpful for spatial multiplex transmission mode.

The RRC decides the transmission mode and transmission rate control for the transmission to the UT, and provides the decision result to the MAC scheduler. The RRC determines the periodicity and length of the dedicated MIMO preamble required for the physical layer (PHY) burst transmission on the R-TCH and on the F-TCH (if needed). The RRC manages the power control transmitted to and from a UT in Space Time Transport Diversity (STTD) mode and provides power control to the PHY administrator. The RRC determines the timing adjustment of the R-TCH transmission from the UT.

A Request Request Message (as shown in Table 12) is transmitted by the AP to request calibration to the UT. The CalType field indicates the calibration tone set and the number of daily line calibration symbols that will be used in the calibration procedure.

The calibration type (CalType) values are listed in Table 13. Each CalType corresponds to a set of OFDM audio sets and the number of daily line calibration symbols required for calibration. The Calibration Pilot Symbol uses the Walsh sequence to establish orthogonality across the transmit antenna.

A Request Request Reject Message (as shown in Table 14) is transmitted by the UT to reject the calibration request message from the AP.

The Measure sends a Request Measurement Request Message (as shown in Table 15) to the AP. This message includes the calibration Pilot symbol used by the AP to measure the channel between the UT and the AP.

A Request Measurement Result Message (shown in Table 16) is sent by the AP to provide the channel measurement result performed by the AP for the calibration symbol transmitted by the UT in the calibration request message to the UT. .

In this example, each calibration measurement result message carries a channel response value of 4 audios of 4x4 channels, a channel response value of up to 8 audios of 2x4 channels, or a channel of up to 16 audios of 1x4 channels. Response. Up to 13 messages may be required to carry 4x4 channels with 52 audio measurements The measurement data, so a sequence number is also used to track the sequence of their messages. If there is not enough data to fill the entire data field, the unused portion of the data field will be set to zero.

A Calibration Measurement Result Acknowledgement Message (as shown in Table 17) is transmitted to acknowledge the fragment of the calibration measurement result message.

Similarly, the calibration measurement result approval message may not be recognized, in which case a Calibration Measurement Result NACK Message may be transmitted on the reverse link (as shown in Table 18). By means of a negative acknowledgement (NACK) a fragment of the calibration measurement result message.

The calibration measurement result message may be negatively recognized based on go-back-N (return to N) or selective repetition. The SEQ field consists of four consecutive 4-bit segments, each of which represents a message sequence number. For the go-back-N mode, the MODE bit is set to 0, and the first fragment 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 are ignored. For the selective repeat mode, the MODE bit is set to 1, and the SEQ field holds the sequence number of up to four messages that must be repeated. If fewer than four messages must be repeated, then only segments with non-zero values are meaningful. All zero value fragments are ignored.

The UT Link Status Message (as shown in Table 19) is transmitted by the AP to request the UT to provide feedback. In this example, the UT must provide feedback on the buffer status (the amount of data accumulated and the QoS class) and the link quality (the forward link transmission rate supported by the MIMO and control channels).

UT_BUF_STAT indicates the UT radio link buffer size (in increments of four bytes). A value of 0xFFFF indicates a buffer size greater than or equal to 262, 140 bytes. FL_RATE_STAT provides the maximum forward link transmission rate per mode (4 bits per mode). For the diversity mode, only the first four most significant bits are used. The remaining 12 bits are set to zero. QOS_FLAG indicates whether the RL buffer contains high priority data. The value QOS_FLAG is defined in Table 20.

At the UT, the UT link status message is established by RRC. At the AP, the UT link state message is forwarded to the RRC for providing a value to the UT proxy server.

The exemplary RRC embodiments described in this paragraph can be deployed in conjunction with the specific embodiments detailed throughout the specification. Familiar with this technology It is understood that this exemplary embodiment is for illustrative purposes only and that many alternative embodiments are apparent in light of the teachings herein. Exemplary embodiments of the control channel are described in this next paragraph, which are suitable for deployment together with the specific embodiments detailed in the entire specification.

Exemplary Control Channel (CCH)

As described above, accessing the MAC frame and assigning resources are controlled by a Control Channel (CCH), which assigns F-TCH and R-TCH resources to the MAC ID in accordance with instructions from the scheduler. These resource grants may be a response to a known state of one or more queues associated with the AP of the particular MAC ID, or a queue for one or more queues at the UT associated with the MAC ID. The response to the known state is reflected in the information in the corresponding UT proxy server. The resource grant may also be a response to an access request received on an Access Request Channel (ARCH) or to some other stimulus or information available to the scheduler. Exemplary embodiments of the CCH are described in detail below. This exemplary CCH is exemplified as various control mechanisms that can be deployed in a high performance WLAN as described above. Alternative embodiments may include additional functionality, as well as a subset of the functionality described below. The field names, field widths, parameter values, and the like described below are merely illustrative. It will be readily apparent to those skilled in the art that the described principles can be modified to configure many alternative embodiments that are within the scope of the invention.

The exemplary CCH system consists of four separate sub-channels, each operating at a different data transmission rate, as shown in Table 21. The terms used in Table 21 are well known in the art (SNR stands for Signal to Ratio (Signal to Noise Ratio), and FER represents the Forward Error Rate, which is well known in the art. CCH combines STTD to use short OFDM symbols. This means that each logical channel is composed of an even number of short OFDM symbols. Messages transmitted on the Random Access Feedback Channel (RFCH) and Frame Control Channel (FCCH) are formatted as Information Elements (IEs) and transmitted on one of the CCH subchannels.

The BCCH indicates whether there is a predetermined CCH subchannel present or absent in the CCH_MASK parameter. Each of the CCH subchannels is provided in Table 22 below (where N indicates the subchannel end codes 0 to 3). The format includes multiple fields for indicating the number of IEs, the IE itself, the CRC, the zero padding (if required), and the trailing bit. The AP decides which subchannel to use for each IE. The IE type unique to the User Terminal (UT) is transmitted on the CCH subchannel for maximizing the transmission efficiency of the UT. CCH_0 can be used if the AP cannot accurately determine the transmission rate associated with a given UT. The broadcast/multicast IE type is transmitted on CCH_0.

CCH is transmitted at the lowest to highest transmission rate. A CRC for each CCH subchannel is provided. All UTs will attempt to decode each CCH that starts transmitting at the lowest transmission rate CCH. Failure to correctly decode CCH_N means that the decoded higher transmission rate CCH has an error. Each CCH subchannel can transmit up to 32 IEs.

The CCH transmission channel is mapped to two logical channels. The RFCH includes an acknowledgement of the access attempt received on the RCH. FCCH includes resource configuration (ie, physical layer frame assignment on F-TCH and R-TCH), physical layer control functions (including physical layer data rate control on F-TCH and R-TCH, R-TCH dedicated preamble) Insert, R-TCH timing, and R-TCH power control. The FCCH may also include an R-TCHR-TCH to request a buffer and link status update to a UT.

In general, in this particular embodiment, the information transmitted on the CCH is time critical information and will be used by recipients within the current MAC frame.

Table 23 lists the CCH information element types and their respective type values. The information element format is further detailed below. In the table below, all displacement values are in units of 800 nm.

Table 24 shows the format of the Registration Request Acknowledgment IE (RFCH) (labeled as RegistrationReqACK in Table 23). The registration request authorization is used to respond to registration requests received from a UT on the RCH. The format includes an IE type, a time slot ID, the access ID (selected by the UT and included in its registration request), the MAC ID assigned to the UT, and a timing advance value.

Table 25 shows the format of the F-TCH Diversity Mode Assignment IE (FCCH) (labeled FwdDivModeAssign in Table 23). The F-TCH diversity mode assignment is used to indicate that the diversity mode will be used MAC PDU transmitted on the F-TCH. Diversity is another STTD deadline included. The format includes an IE type, a MAC ID, an F-TCH offset (used to indicate the location of the MAC PDU in the MAC frame), the used transmission rate, the number of OFDM symbols in the packet, and the type of the preamble (described in detail below). And the number of short OFDM symbols in the packet.

Table 26 shows the format of the F-TCH Diversity Mode Assignment IE (FCCH) containing the R-TCH state (labeled FwdDivModeAssignStat in Table 23). This IE is used to indicate the MAC PDU to be transmitted on the F-TCH using the diversity mode, and will configure the R-TCH space for responding to a state request. The format includes the FwdDivModeAssign field. In addition, the format includes a configuration shift for the UT to report its buffer status on the R-TCH. The configuration of the link state message for the R-TCH specifies the R-TCH preamble type, as well as the reverse parameters, including the transmission rate, timing adjustment, status message request bits, and long and short types in the link state packet. The number of OFDM symbols.

The FWD_PREAMBLE and REV_PREAMBLE fields provide the length of the preamble used on the reverse link and the status message transmitted on the reverse link, respectively. The preamble consists of the number of short OFDM symbols provided in Table 27, carrying only the steered reference for the main feature mode (eigenmode).

Table 28 shows the F-TCH Spatial Multiplex Mode Assignment IE (FCCH) (labeled in Table 23 as The format of FwdSpaModeAssign). This IE field is similar to FwdDivModeAssign except that space multiplex is used instead of using diversity.

Table 29 shows the format of the F-TCH Spatial Multiplex Mode Assignment IE (FCCH) with the R-TCH state (labeled FwdSpaModeAssignStat in Table 23). This IE field is similar to FwdDivModeAssignStat except that space multiplex is used instead of using diversity.

Table 30 shows the format of the R-TCH Diversity Mode Assignment IE (FCCH) (labeled RevDivModeAssign in Table 23). This IE is used to signal a R-TCH configuration for a MAC PDU using a diversity mode. This IE includes the MAC ID field as described above. This IE also includes the reverse link fields (FwdDivModeAssignStat and FwdSpaModeAssignStat) included in the status request message as described above. This IE further includes a reverse transmission power adjustment field.

Table 31 shows the format of the R-TCH Spatial Multiplex Mode Assignment IE (FCCH) (labeled RevSpaModeAssign in Table 23). This IE field is similar to RevDivModeAssign except that space multiplex is used instead of using diversity.

Table 32 shows the format of the TCH Div Mode Assignment IE (FCCH) (labeled as DivModeAssign in Table 23). This IE is used to configure forward link and reverse link MAC PDUs. The field combination of the fields PwdDivModeAssign and RevDivModeAssign of this IE.

Table 33 shows the format of the TCH Spatial Mul Mode Assignment IE (FCCH) (labeled as SpaModeAssign in Table 23). This IE field is similar to DivModeAssign except that space multiplex is used instead of using diversity.

Table 34 shows the format of the Buffer and Link Status Request IE (RFCH or FCCH) (labeled as LinkStatusReq in Table 23). The AP uses this IE to request the current buffer state and the current state of the physical link to the UT to the UT. A reverse link configuration for providing a response is performed in conjunction with this requirement. In addition to the type and MAC ID fields, the reverse link configuration also includes the types described above. The field of the reverse link configuration.

Table 35 shows the format of the Calibration Request Acknowledgment IE (FCCH) (labeled as CalRequestAck in Table 23). This IE is transmitted to recognize the calibration requirements of a UT. Calibration is usually performed immediately after registration, and calibration is rarely performed afterwards. Although the TDD radio channel is symmetric, the transmission and reception chains at the AP and UT may have unequal gains and phases. Calibration is performed to rule out this asymmetry. This IE includes a type field, a MAC ID field (containing the temporary MAC ID assigned to the UT), the number of antennas of the UT, and the approval of the desired type of calibration. The 4-bit calibration type field specifies the audio combination used for calibration and the number of training symbols transmitted based on the calibration usage.

Table 36 shows the format of the Calibration Request Reject IE (FCCH) (labeled as CalRequestRej in Table 23). This IE rejects calibration requirements from a UT. This IE includes a type field, a MAC ID field, and a calibration requirement type field, just like CalRequestAck. In addition, a reason field is provided to explain the reason for rejecting the calibration request.

The reason for the calibration requirement is referenced by the cause value. The cause and cause values are detailed in Table 37.

Table 38 shows the format of the Request Message (ARCH). The request message is considered a registration request at the time of initial access. The accessing UT randomly picks an access ID from a set of IDs set for initial access and published in the BCCH message. If the request message is continuously received, the AP will use the registration request approval IE on the RFCH to acknowledge the request message and assign a temporary MAC ID to the UT.

The registered UT will use the same message on the ARCH, but will request the service using the MAC ID assigned in the Access ID field. If the request message is continuously received, the AP transmits an R-TCH link state request IE to obtain the type and size of the configuration desired by the UT.

Those skilled in the art will appreciate that any of a variety of different terms or techniques can be used to represent information and signals. For example, data, instructions, commands, information, signals, bits, symbols, and wafers are advantageously represented by voltages, currents, electromagnetic waves, magnetic fields or particles, light fields or particles, or any combination thereof.

Those skilled in the art should further appreciate that the various illustrative logic blocks, modules, circuits, and algorithm steps described in connection with the specific embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations thereof. In order to clearly illustrate the interchangeability of hardware and software, the various components, blocks, modules, circuits, and steps of the various figures are described above in terms of functionality. The functionality is implemented as hardware or software depending on the particular application and the design constraints that affect the overall system. Those skilled in the art can implement the described functions in different ways for each particular application, but such implementation decisions are not considered to be a departure from the scope of the present invention.

Use general purpose processors, digital signal processors (DSPs), dedicated integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other programmable Programmatic logic device (PLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof, to perform the functions described herein to implement or perform various illustrative logic in conjunction with the specific embodiments disclosed herein. Blocks, modules and circuits. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller or state machine. The processor can be implemented as a combination of computer devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors connected to a DSP core, or any other such configuration.

The method or algorithm steps described in connection with the specific embodiments disclosed herein may be embodied directly by hardware, a software module executed by a processor, or a combination of software and hardware. The software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, scratchpad, hard disk, removable disk, CD-ROM, or well known in the art. Any other form of storage medium. An exemplary storage medium is coupled to the processor such that the processor can read information from the storage medium and write information to the storage medium. In the alternative, the storage medium can be integrated into the processor. The processor and storage medium can reside in the ASIC. The ASIC can reside in a user terminal. In the alternative, the processor and the storage medium may reside as a separate component in the user terminal.

The headings listed herein are for reference and assist in finding the paragraphs. These headings are not intended to limit the scope of the concepts described herein. These concepts can be applied in the entire specification.

The foregoing description of the specific embodiments of the invention is intended to be illustrative Those skilled in the art should understand these specifics. The various modifications of the embodiments, and the general principles defined herein, may be applied to other specific embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the details of the embodiments disclosed herein, but the scope of the invention.

100‧‧‧ system

102‧‧‧Network

104‧‧‧Access Point (AP)

106A-N‧‧‧User Terminal (UT)

110,270‧‧‧ Connection

120‧‧‧Wireless Local Area Network (WLAN) (Figure 1)

120‧‧‧RF link (Figure 26)

210‧‧‧ transceiver

220‧‧‧MAC processor

240‧‧‧LAN transceiver (Figure 2)

250A-N‧‧‧Antenna

255‧‧‧ memory

260‧‧‧ data flow

280‧‧‧Feedback

300‧‧‧Subnet Protocol Stacking (Figure 3)

310A, 310B‧‧‧ adjustment layer

312‧‧ Division and Reorganization (SAR)

314‧‧‧ Data stream classification

316‧‧‧Multicast mapping

320A, 320B‧‧‧ data link layer

240A, 240B‧‧‧ Physical Layer (PHY)

320‧‧‧Data Link Control Layer (Figure 3)

330‧‧‧Logical Link (LL) Layer

332‧‧‧Accessible Broadcast/Multicast/Unicast

334‧‧‧Negative recognition

336‧‧ ‧Approved

340‧‧‧ Radio Link Control (RLC) layer

342‧‧‧ Radio Resource Control (RRC)

344‧‧‧Association control function

350‧‧‧System configuration control

360‧‧‧MUX function

370‧‧‧Common MAC function

372‧‧‧MAC group frame function

374‧‧‧Control channel function

376‧‧‧MAC Scheduler

378‧‧‧ Random access control

380‧‧ ‧ layer administrator

382‧‧‧QoS administrator function

384‧‧‧License Control Function

386‧‧‧Physical layer administrator

410‧‧‧User data package

420A-N‧‧‧ fragment

430‧‧‧Adjust sublayer PDU

434,444,454‧‧‧Package (payload)

440‧‧‧ Logical Link Sublayer PDU (LL PDU)

442‧‧‧LL header

450‧‧‧MUX Sublayer PDU (MPDU)

452‧‧‧MUX header

462‧‧‧MUX indicator

464‧‧‧Local MPDU

466‧‧‧New PDU

466A‧‧‧MPDU

468‧‧‧Local MUX PDU

500‧‧‧MAC frame

510‧‧‧Broadcast Channel (BCH)

520‧‧‧Control Channel (CCH)

530‧‧‧ Forward Traffic Channel (F-TCH)

540‧‧‧Reverse Traffic Channel (F-TCH)

550‧‧‧ Random Access Channel (RCH)

560‧‧‧frag

2410‧‧‧IP router

2610, 2710‧‧‧ upper level

2615,2720A‧‧‧IP layer

2620A‧‧‧Ethernet MAC layer

2620B‧‧‧Ethernet MAC

2640‧‧‧Ethernet adjustment protocol heap (UT protocol heap)

2650‧‧‧Ethernet adjustment protocol stacking (AP protocol stacking)

2740‧‧‧IP adjustment protocol heap (UT protocol heap)

2750‧‧‧IP adjustment protocol stacking (AP protocol stacking)

1 illustrates an exemplary embodiment of a system including a high speed WLAN; FIG. 2 illustrates an exemplary embodiment of a wireless communication device that can be configured as an access point or user terminal; 3 illustrates an exemplary sub-network protocol stack; FIG. 4 illustrates a user data packet traveling through the protocol stacking layers; FIG. 5 illustrates an exemplary MAC frame; FIG. 6 illustrates an exemplary method of transmitting forward link message transmission FIG. 7 illustrates an exemplary method of receiving forward link message transmission; FIG. 8 illustrates an exemplary method of transmitting reverse link message transmission; FIG. 9 illustrates an exemplary method of receiving reverse link message transmission; 10 illustrates an exemplary method for the UT to perform initial access and registration; FIG. 11 illustrates an exemplary method for the AP to perform initial access and registration; FIG. 12 illustrates an exemplary method 1200 for AP user data flow; FIG. An exemplary method 1300 for mapping a UT user data stream; FIG. 14 illustrates an exemplary method of incorporating a physical layer feedback into an adjustment layer function; FIG. 15 illustrates an exemplary method of performing an adjustment layer multicast; FIG. Determine whether to use the adjustment layer multi-cast Send or use MAC multipoint An exemplary method of broadcasting; FIG. 17 illustrates an exemplary method of performing segmentation in response to entity layer feedback; FIG. 18 illustrates segmentation by response to transmission rate; and FIG. 19 illustrates transmission in a single MAC frame. An exemplary method of multiple data streams and commands; FIG. 20 illustrates a continuous MAC frame, including an example of transmitting various local MUX PDUs; FIG. 21 illustrates an exemplary method of preparing a MAC frame using MUX indicators; An exemplary method of including a MAC frame of a MUX indicator; FIG. 23 illustrates an exemplary MUX PDU format; FIG. 24 illustrates an exemplary system configured for Ethernet adjustment; FIG. 25 is configured to apply An exemplary system for IP conditioning; FIG. 26 depicts an exemplary Ethernet protocol stack; and FIG. 27 depicts an exemplary IP protocol stack.

300‧‧‧Subnet Protocol Stacking (Figure 3)

312‧‧ Division and Reorganization (SAR)

314‧‧‧ Data stream classification

316‧‧‧Multicast mapping

320‧‧‧Data Link Control Layer (Figure 3)

330‧‧‧Logical Link (LL) Layer

332‧‧‧Accessible Broadcast/Multicast/Unicast

334‧‧‧Negative recognition

336‧‧ ‧Approved

340‧‧‧ Radio Link Control (RLC) layer

342‧‧‧ Radio Resource Control (RRC)

344‧‧‧Association control function

350‧‧‧System configuration control

360‧‧‧MUX function

370‧‧‧Common MAC function

372‧‧‧MAC group frame function

374‧‧‧Control channel function

376‧‧‧MAC Scheduler

378‧‧‧ Random access control

380‧‧ ‧ layer administrator

382‧‧‧QoS administrator function

384‧‧‧License Control Function

386‧‧‧Physical layer administrator

Claims (28)

A media access control method includes: receiving a packet addressed to a multicast group, the multicast group comprising two or more remote stations; comparing multicast transmissions on a single channel a first resource configuration required to the multicast group, and a second resource configuration required for unicast transmission to the multicast group on two or more channels; and when the first When a resource configuration is less than the second resource configuration, the packet is transmitted on one channel; otherwise, the packet is transmitted on two or more channels. The method of claim 1, wherein: each of the remote stations in the multicast group can receive a lowest supportable transmission rate of one of the multicast channels to determine the first resource configuration; and based on the two Or the supported transmission rate of the unicast channel that can be received by each of the two or more channels to determine the second resource configuration. The method of claim 2, wherein receiving the supportable transmission rate as entity layer feedback. The method of claim 1, further comprising: determining whether the unicast transmission is more efficient than the multicast transmission based on the comparison. The method of claim 1, further comprising: receiving link parameters of each of the remote stations of the multicast group; and receiving, for transmission to all remote stations in the multicast group The link parameters of a multicast channel. The method of claim 5, wherein the comparing comprises comparing a system resource requirement of the multicast transmission of the packet to the multicast group on the multicast channel, and to the multicast group to the multicast group A sum of system resource requirements for individual unicast transmissions of the packet for each station in the remote station. The method of claim 1, wherein transmitting the packet on two or more channels comprises transmitting at least one multicast packet to a subset of the multicast group. A computer readable medium comprising an instruction code that, when executed by a machine, causes the machine to perform operations, the operations comprising the steps of: receiving a packet addressed to a multicast group, A multicast group includes two or more remote stations; comparing a first resource configuration required for multicast transmission to the multicast group on a single channel, with two or more Transmitting, by the channel, a second resource configuration required for transmission to the multicast group; and when the first resource configuration is less than the second resource configuration, transmitting the packet on one channel; otherwise, The packet is transmitted on one or more channels. The computer readable medium of claim 8, wherein: each of the remote stations in the multicast group can receive a lowest supportable transmission rate of one of the multicast channels to determine the first resource configuration; The second resource configuration is determined based on the supportable transmission rate of the unicast channel that can be received by each of the two or more channels. The computer readable medium of claim 9, wherein the operations further comprise receiving a supportable transmission rate as entity layer feedback. The computer readable medium of claim 8, wherein the operations further comprise: determining whether the unicast transmission is more efficient than the multicast transmission based on the comparison. The computer readable medium of claim 8, wherein the operations further comprise: receiving a link parameter of each of the remote stations of the multicast group; and receiving the suitable transmission to the multicast group Link parameters of a multicast channel of all remote stations. The computer readable medium of claim 12, wherein the comparing comprises comparing a system resource requirement of the multicast transmission of the packet to the multicast group on the multicast channel, and to the multicast group A sum of system resource requirements for the individual unicast transmissions of the packet for each of the remote stations in the group. The computer readable medium of claim 8, wherein transmitting the packet on two or more channels comprises transmitting at least one multicast packet to a subset of the multicast group. A wireless communication device, comprising: a receiving component, configured to receive a packet addressed to a multicast group, the multicast group comprising two or more remote stations; Comparing means for comparing a first resource configuration required for multicast transmission to the multicast group on a single channel, and unicast transmission to the multicast on two or more channels a second resource configuration required by the group; and for transmitting the packet on one channel when the first resource configuration is less than the second resource configuration, otherwise transmitting the packet on two or more channels The component of the package. The wireless communication device of claim 15, wherein: each of the remote stations in the multicast group can receive a lowest supportable transmission rate of one of the multicast channels to determine the first resource configuration; and based on the The supported transmission rate of the unicast channel that can be received by each of the two or more channels determines the second resource configuration. The wireless communication device of claim 16, further comprising means for receiving a supportable transmission rate as entity layer feedback. The wireless communication device of claim 15, further comprising: means for determining whether the unicast transmission is more efficient than the multicast transmission based on the comparing. The wireless communication device of claim 15, further comprising: means for receiving link parameters of each of the remote stations of the multicast group; and for receiving for transmission to the multicast group A component of a link parameter of a multicast channel of all remote stations. The wireless communication device of claim 19, wherein the comparison component comprises Comparing the system resource requirements of the multicast transmission of the packet to the multicast group on the multicast channel, and to each of the remote stations in the multicast group A component of the system resource requirements of a sum of individual unicast transmissions of packets. The wireless communication device of claim 15, wherein the means for transmitting the packet on two or more channels comprises transmitting at least one multicast packet to a subset of the multicast group. An apparatus for processing a stream of communication data, the apparatus comprising: at least one antenna; and at least one processor configured to: receive, via the at least one antenna, a packet addressed to a multicast group, the plurality of A point-to-speech group includes two or more remote stations; comparing a first resource configuration required for multicast transmission to the multicast group on a single channel, with two or more channels Transmitting, by a single point, a second resource configuration required for transmission to the multicast group; and when the first resource configuration is less than the second resource configuration, transmitting the channel over the at least one antenna Packet; otherwise the packet is transmitted over two or more channels via the at least one antenna. The device of claim 22, wherein: each of the remote stations in the multicast group can receive a lowest supportable transmission rate of one of the multicast channels to determine the first resource configuration; The second resource configuration is determined based on the supportable transmission rate of the unicast channel that can be received by each of the two or more channels. The device of claim 23, wherein the at least one processor is further configured to receive the supportable transmission rate as physical layer feedback via the at least one antenna. The device of claim 22, wherein the at least one processor is further configured to determine whether the unicast transmission is more efficient than the multicast transmission based on the comparison. The device of claim 22, wherein the at least one processor is further configured to: receive, via the at least one antenna, link parameters of each of the remote stations in the multicast group and to transmit to the multi-cast The link parameters of a multicast channel of all remote stations in the group. The device of claim 26, wherein the at least one processor is configured to compare system resource requirements for the multicast transmission of the packet to the multicast group on the multicast channel, and to the multi-cast A sum of system resource requirements for a single unicast transmission of the packet of each of the remote stations in the group. The device of claim 22, wherein the at least one processor is configured to transmit the packet on two or more channels by transmitting at least one multicast packet to the multicast group A subset.