Method and apparatus for random backoff based access priority

The present invention relates to a method and an apparatus for providing access priority in a communication system, and more specifically, to control access priority in a medium access control protocol of a next-generation mobile telecommunications system. With respect to methods and devices for providing.

[0002] [Summary of the Invention] Over the past decade, great efforts have been made to integrate multimedia functions into mobile communications. The International Telecommunication Union (ITU) and other organizations seek to develop standards and recommendations that ensure that future mobile communications are ready for multimedia applications with at least the same quality as existing fixed networks. .. In particular, many large-scale research projects are being supported to develop such next (third) generation mobile systems. European examples of such efforts include European Advanced Communication Technologies R & D, RACE-1, RACE-2, and Advanced Communications Technology and Services (ACTS) can be mentioned. It is known that high bit rate capabilities are needed to provide end users with the quality of service required for multimedia communications, Internet access, and video / picture transfer. Under these requirements, the goal of the transmission function of the 3rd generation system is 384 kbps per second (kb / s) for the entire effective range and 2 megabits per second (Mb / s) for the local effective range. It is stipulated.

[0003] The Universal Mobile Telecommunications System (UMTS) is based on 5 megahertz Wideband-Code Division Multiplex Access (W-CDMA) and includes multimedia-compatible mobile communications. A new radio access network optimized to support 3rd generation services. The main design objectives of UMTS are to provide a broadband multimedia communication system that integrates infrastructure for mobile and fixed communications, and, among other things, the same coverage provided by fixed and wireless communications networks. As it provides, UMTS must provide circuit-switched services as well as packet switch services, various mixed media traffic types, and on-demand bandwidth. However, flexibility is needed when providing multimedia support. That is, different bit rates and E_b/ N₀It is necessary to be able to support services with requirements and to be able to multiplex such services in a multi-service environment. UMTS is designed to meet such demand.

[0004] With reference to FIG. 1, an exemplary block diagram of a UMTS access network is shown. Specifically, the plurality of remote terminals 2 and 4 (for example, mobile terminals) communicate with the base station (NODE-B) 6 via the W-CDMA radio link 8. The remote terminal can be a variety of devices, such as a radiotelephone 2 or a portable personal computer 4 with an internal or external modem. In the UMTS standard, the base station is called NODE-B. These base stations communicate with network components called Remote Network Controllers (RNCs) that provide radio resource management capabilities. Since UMTS is a W-CDMA system, it supports soft handoff. In the case of soft handoff, two base stations 6 serve one remote terminal. Therefore, the remote terminal sends a frame to these two base stations. When two base stations receive frames from a remote terminal, they are selected by the Frame Selector. Send to Unit: FSU). The FSU determines which is the better frame in terms of frame quality and sends it to the core network. In UMTS, the FSU can be physically integrated with the RNC. Therefore, in FIG. 1, RNC and FSU are shown as block 10, but functionally separately, they are also shown as block 12 (FSU) and block 14 (RNC). Other elements in the UMTS network perform traditional functions. That is, an xLR database 20 that provides information on homes and places visited, and an InterWorking Function (IWF) unit.<u style="single">22</u>And so on. The Universal Mobile Switching Center (UMSC) 16 will be allowed to function as a mobile switching center for base station 6 in UMTS. Sub-network 18 is a wireless service provider network, and CN1 to CNn are core networks 24 to which remote terminals are ultimately coupled.

[0005] With reference to FIG. 2, a diagram of a typical protocol stack in UMTS is shown. In UMTS, Layer 1 (L1) is the physical layer (PHY), which supplies information transfer services to the MAC (Media Access Control) layer and higher layers. The physical layer transfer service is described by how and with what characteristics data is transferred on the transmission channel of the wireless interface. Layer 2 (L2) consists of sublayers, MAC, LAC (Link Access Control), RLC, and RLC'(Radio Link). Control: Includes wireless link control). UMTS specifies two RLC protocols (RLC and RLC') because the functions performed in RLC are divided. The RLC and MAC layers provide real-time and non-real-time services. The MAC layer controls the multiplexing of data streams originating from different services, but does not do so. That is, the MAC layer allows a large number of remote terminals to share a common physical communication channel (eg, broadcast communication channel) via a logical channel. IP (Internet Protocol) is the network layer.

[0006] Uu refers to the UMTS-dedicated interface between the remote terminal and the base station, while Iub refers to the UMTS-dedicated interface between the base station and the RNC / FSU. Layer 2 of the radio access network (ie, to the left of NODE-B in the protocol stack) is divided into RLC and MAC layers, while the layer of the core network (to the right of NODE-B in the protocol stack). 2 is more relevant to the technology used to transmit network layer frames, such as ATM (Asynchronous Transfer Mode) or Frame Relay. IP is indicated as the transmission protocol, but UMTS is not limited to this. That is, UMTS can support other transmission protocols. For more details on the protocol layer, see "UMTS / IMT-2000 Based on Wideband CDMA" (IEEE Communications) by Dahlman et al. Magazine, pp. 70-80 (September 1998)) and ETSI SMG2 / UMTS L2 &amp; L3 Expert Group, "MS-UTRAN Radio Interface Protocol Architecture; Stage 2" ) (Tdoc SMG2 UMTS-L23 172/98 (September 1998)).

[0007] UMTS needs to handle traffic for four different uses. They are (i) both delay and loss sensitive applications such as interactive video, (ii) loss sensitive but moderate delay tolerable applications such as interactive data, (iii). Includes delay-sensitive but moderate loss-tolerant applications such as voice, and (iv) delay- and loss-tolerant applications such as file transfer.

[0008] UMTS systems must be properly designed to provide different quality of service (QoS) for all of these different uses. In UMTS system design, there are several ways to satisfy QoS without wasting network resources, and to run the system in a stable area if all traffic types suddenly occur at the same time. Important issues need to be considered.

[0009] In addition, UMTS requires several components to support a variety of QoS. For example, the Internet Engineering Task, which allows different QoS requirements to be specified for different applications. It is necessary to specify service parameters such as warranty service parameters and control load service parameters specified by Force: IETF). The user can request bandwidth resources in either burst mode or connection mode. UMTS must also have a permission control component that makes a decision as to whether or not to accept the user's request. When granting new requests, even if all the granted requests peak at the same time, they must be done so as not to violate the QoS requirements of each request (unless they require the first effort). .. In addition, once the user's request is granted, the UMTS network must implement a mechanism for sending such service guarantees, such as delay requirements, packet loss requirements, etc. Mechanisms that routers can handle to provide differentiated services include scheduling algorithms at network nodes and packet marking for non-conforming user traffic.

[0010] In order to provide terminal QoS in UMTS, it is necessary to provide some mechanisms in the MAC layer to guarantee different QoS. One possible way to provide different QoS is to have a priority mechanism. The priority mechanism can be implemented with respect to access priority, service priority, or buffer management scheme. For example, there are various types of service priority mechanisms such as fixed priority and dynamic priority. Fixed priority mechanisms include, for example, strict priority and weighted round robin. Dynamic priority schemes include, for example, fair share queuing, self-clock fair share queuing, and worst case fair share queuing. (worst case fair share queuing) Includes the principle.

[0011] With respect to access priorities, some well-known channel access protocols are currently used in wireless data systems, such as Slotted Aloha and PRMA. Traditional slot aloha is a relatively simple protocol, but its theoretical capacity is only 0.37 because it does not attempt to avoid or resolve conflicts between data users.

Reservation-based protocols seek to avoid and eliminate conflicts by dynamically reserving channel bandwidth for users who need to send packets. Typically, such a protocol divides a channel into slots and groups them into frames of N slots. One slot can be further subdivided into k mini-slots. Usually slot A₁For the purpose of booking, the rest of AA₁The slot is a data slot. For users who need to send packets, B = A₁* k Send a reservation request packet in one of the minislots. If the reservation request packet is successful, the user is allocated a number of data slots until the user or base station cancels the reservation. If the reservation request packet is unsuccessful, the user retransmits the reservation request using the conflict resolution method until the transmission is successful.

One of the logical channels associated with the UTMS Medium Access Control (MAC) protocol, namely Random Access. Access priority control is especially important for CHannel: RACH). RACH is an uplink common transmission channel used to carry control information and short user packets from remote terminals. Referring to FIG. 3, a block diagram of an exemplary hardware implementation of a non-coherent RACH detection algorithm for use in a UMTS base station (NODE-B in FIG. 1) is shown. The RACH receiver 30 can provide detection, demodulation and decryption, and approval functions. The purpose of the detection is to determine if the RACH burst described below is being transmitted from a remote terminal and to determine the strongest multipath component of the incoming burst. The receiver 30 also demodulates and decodes the message contained within the corresponding RACH to verify the remote terminal identifier and required service. After decoding the RACH transmission by the remote terminal, the receiver generates an approval signal, which is transmitted by the base station to the remote terminal via the Forward Access CHannel (FACH).

[0014] The RACH receiver 30 preferably performs the above functions according to the following structure. The RACH transmit burst is received and demodulated by the mixer 32 and then filtered by the filter 34. This signal is then sampled in the sampling device 36. Despreader 38 decodes the signal according to an extended sequence, in this case 512 Gold Codes. The decoded signal is buffered (in buffer 40) and sent to the time shift device 50. The output of the despreader 38 is also supplied to the integrator 42. The output of the integrator 42 is mixed (with the mixer 44) and fed to the timing detector 46 and then to the threshold detector 48. The output of the threshold detector 48 indicates whether or not a valid signal has been received from the remote terminal. This result is supplied to the time shift device 50. If this is a valid signal (eg, the predetermined threshold mentioned above), then the decoded signal is downsampled by device 52. The signal then passes through the 16-tap filter device 54 to reach the preamble sign retrieval device 56, depending on the preamble described below. The output of the search device 56 supplies the base station with information about the remote terminal identifier and the services (groups) requested by the remote terminal.

[0015] Physical RACHs are known to be designed on the basis of slot aloha techniques. As shown in Figure 4A, the remote terminal has eight clearly defined time offsets (access slots # 1, ,.) With respect to the frame boundaries of the current cell's Broadcast Control CHannel (BCCH). Random access burst 100 can be transmitted in .., access slot # i, ..., access slot # 8). As shown in FIG. 4B, the random access burst has two parts: a preamble 102 with a length of 1 millisecond (ms) and a message 104 with a length of 10 ms, and between the preamble and the message. It consists of an idle time of 106 with a length of 0.25 ms. There are a total of 16 different preamble signatures, and a 16-length Orthogonal Gold code. Based on (512 Gold Codes). Information about available signs and time offsets will be broadcast on BCCH. Based on this structure, if the receiver has 128 parallel processors (16 preamble signs multiplied by 8 time slots), 128 random access attempts can be detected simultaneously. That is, it has 128 equivalent random access channels for the base stations that are maximally configured for the current cell.

[0016] Therefore, there is a need for methods and devices for providing access priorities in UMTS that address the unique requirements associated with such broadcast multimedia communication systems. That is, there is a need for methods and devices that provide access priorities for UMTS RACH.

The present invention provides methods and devices for giving access priorities in the MAC protocol of a communication system, for example for UMTS RACH. In particular, the present invention relates to (i) Random Chip Delay Access Priority (RCDAP), (ii) Random Backoff Based Access Priority (RBBAP), (iii). ) Variable Logical Channel based Access Priority (VLCAP), (iv) UMTS-only variant of the Variable Logical Channel based Access Priority method (VLCAP'), (v) Probability-based Access Priority Adopt several access priority methodologies, including Probability Based Access Priority (PBAP) and (vi) REtransmission Based Access Priority (REBAP).

[0018] In one embodiment of the present invention, a method and apparatus for RCDAP are provided. RCDAP has the advantage of assigning different chip delays to each priority class from the chip delay distribution before presenting the access request to the base station. Preferably, the higher priority classes are given a smaller average random chip delay so that their access requests are more likely to be captured than those presented by users of the lower priority classes. To do so.

[0019] Another embodiment of the invention provides a method and apparatus for RBBAP. RBBAP has the advantage of assigning a different backoff delay to each priority class. Preferably, the requirements associated with high priority access have a smaller average backoff delay. Whenever there is a conflict, or for any other reason the access request is not successfully received at the base station, the remote terminal chooses a random delay distributed between predetermined ranges, depending on class i.

Yet another embodiment of the present invention provides methods and devices for VLCAP. In VLCAP, each subscriber is given an access priority class i. Preferably, the higher priority can access all of the logical access channels in which the base station is configured, while the lowest priority is a smaller subset of the logical access channels, eg eight. Only one preamble sign with a time offset of is allowed access. The rationale for this approach is that the more logical access channels a remote terminal has to choose from when making a choice, the more likely it is to find a channel through which the request is successfully transmitted.

[0021] Yet another embodiment of the present invention provides a UMTS-specific variant of the VLCAP method and apparatus. This VLCAP'method specifically considers a special UMTS access channel structure. That is, even if there are t time offsets for each preamble sign, the base station may not have t parallel processors to limit the processing complexity associated with the base station. .. For example, each is (i^th, (i + 4)^thThere may be only four receivers programmed to capture the time offset of). Therefore, according to the VLCAP'method, lower priority class requests can be assigned a higher numbered time offset, which allows the receiver to first capture access requests from the higher priority class. It will be possible.

Yet another embodiment of the present invention provides methods and devices for PBAP. In PBAP, each subscriber is given an access priority class i. Each access priority class i has a certain probability P_iYou can only send an access request by. The highest priority always sends an access request whenever it has one.

[0023] Yet another embodiment of the present invention provides methods and devices for REBAP. In REBAP, an access request has an Access Packet Priority (APP) associated with it. This gives the resent access request a higher priority than the new access request.

It will be appreciated that the access priority technique performed in accordance with the present invention may include a combination of two or more of the examples described above. For example, RCDAP can run with RBBAP or VLCAP and RBAP, and so on.

These and other objects, features and advantages of the present invention will become apparent by reading the following detailed description of exemplary embodiments of the present invention in association with the accompanying drawings.

Description: TECHNICAL FIELD The present invention describes the situation of access priority control in the MAC layer of UMTS, particularly with respect to access priority control in a random access channel or RACH. However, it will be acknowledged that the teachings of the invention discussed herein are not limited to this. That is, the access priority methodology of the present invention is for a remote terminal (eg, mobile or fixed) to ensure access to a communication channel associated with a base station or other communication system access point in other communication systems. It is also applicable when making random attempts. Further, it will be appreciated that the methodologies described herein for use in remote terminals or base stations are performed by one or more processors, each associated with it. As used herein, the term "processor" Contact CPU (central processing unit) is intended to include any processing device, including associated memory and. Therefore, software instructions or codes related to implementing the methodology of the present invention may be stored in the related memory, and when it is ready to be used, it may be searched and executed by an appropriate CPU. Also, the term "remote terminal" shall refer to any device capable of communicating with a base station. For example, the remote terminal can be mobile (eg, a portable personal computer with a radiotelephone or wireless modem) or fixed (eg, a fixed personal computer with a wireless modem). Also, the terms "base station" and "node_b" are used interchangeably herein.

[0027] As described above, the present invention has been filed on May 22, 1998, "Method for Access Control in a Multiple Access System for Communications Networks". With respect to the subject matter disclosed in the patent application described as US Application No. 09 / 084,072. This application describes another MAC protocol called "On-Demand Multiple Access Fair Queuing" or ODMAFQ (On-Demand Multiple Access Fair Queuing). A related MAC function will be described in the section entitled "ODMAFQ MAC Protocol Operation" that follows the detailed description of the present invention.

[0028] Return to FIG. 1 again. As mentioned earlier, it will be understood that remote terminals 2 and 4 are coupled to the UMTS access network via a wireless interface with base station 6. To establish communication, the remote terminal sends and receives medium access control (MAC) frames to and from base station 6 via a wireless interface. In the case of terminal 4, an internal or external modem can be used to provide a wireless connection to the base station. A remote terminal, such as remote terminal 2, usually has its own internal modem. However, remote terminals typically generate or receive packets randomly in bursts. The packet is buffered at the remote terminal until it is uplinked to the base station. Base station 6 provides wide area radio coverage and multiple remote terminal traffic, as is known, from each of their coverage areas to the mobile switching center of the system, eg, UMSC16 in FIG. In addition, the base station broadcasts (downlinks) packets addressed to one or more of the remote terminals in the cell.

[0029] The UMTS Multiple Access Method is a time slot system (ie, a slot aloha method) that forms a random access channel (RACH) and a packet transmission channel for each slot. The time slot duration for each channel is selected based on the particular system being implemented. Generally, a remote terminal having a packet to be sent transmits an access request to a base station via RACH. There are potentially many remote terminals compared to the relatively small number of access channels that base stations are configured to support, ensuring that network traffic is handled in an orderly and timely manner. For that purpose, an access priority method is required. That is, when many remote terminals randomly seek to ensure the use of a single communication channel (ie, demand channel bandwidth to carry packets), they are more likely than remote terminals with relatively low needs. In order to allow remote terminals with relatively high needs access to the channel bandwidth associated with the base station, methods must be implemented in the network to prioritize access requests. Thus, for example, if two remote terminals have packet data to be transmitted to the base station, the access request of the remote terminal with higher access needs may be received and acknowledged prior to the other remote terminal. Is preferably high. However, it will be appreciated that the priority class of the remote terminal is dynamic, i.e. depending on the nature and / or content of the packet to be sent and / or the nature of the remote terminal. For example, if the packet represents delay-sensitive data (eg, interactive video, audio), or is of a nature that allows immediate transmission (eg, an emergency), the remote terminal is appropriate for that situation. Select the priority, that is, the priority class with the higher priority in these cases. It also assigns different access priorities depending on the level of service the remote terminal subscribes to (eg high or normal).

[0030] First, referring to FIG. 11, a flowchart of the access priority control method 1100 in the base station according to the present invention is shown. In UMTS, a base station (eg, base station 6) is a remote terminal (Remote) within its scope. Broadcast access priority system parameters to Terminal: RT) in a beacon or pilot signal (step 1102). Access priority system parameters include parameters that the remote terminal uses in its base station access request process, as specifically described according to the access priority methodology performed on the remote terminal. That is, the base station transmits parameters for each pre-established priority class, which the remote terminal receives and stores for use during the access request. In step 1104, the base station determines if it has received an access request from a remote terminal (via its associated processor). If not, the base station waits for this reception. When the access request is received from the remote terminal, the base station sends an approval message to the remote terminal (step 1106) to indicate that the request has been successfully received. This approval signal is transmitted over the forwarding access channel (FACH) between the base station and the remote terminal. The base station then prepares to receive packet data from the access granted to the remote terminal according to the packet data reception procedure used in UMTS (step 1108).

[0031] With reference to FIG. 5, a flowchart of the access priority control method 500 in the remote terminal according to the first embodiment of the present invention is shown. It would be acceptable for this methodology to be performed on a remote terminal (eg terminal 2 or 4) that generated or received a packet that uplinked to a UMTS base station (eg base station 6). The embodiment shown in FIG. 5 is hereinafter referred to as Random Chip Delayed Access Priority (RCDAP). In general, the RCDAP approach has the advantage of assigning a different average random chip delay to each priority class before presenting the access request to the base station. Each chip is known as a constant duration, so each chip represents a constant time delay. Therefore, the duration of chip delay is directly related to the number of chips in the delay. Long delays have more chips than short delays. It would be acceptable to use chip delay in UMTS due to the use of CDMA radio interfaces (W-CDMA) between remote terminals and base stations. According to this embodiment of the invention, high priority classes are given a small average random chip delay and their access requests have a smaller time delay, thus providing lower priority classes. Make it more likely to be captured than what the user presents.

In the access priority embodiment of FIG. 5, in step 501, the remote terminal receives and stores (in its memory) the following access priority system parameters that the base station broadcasts. The parameters are M, which is the number of logical access channels existing between the remote terminal and the base station, and K, which is the maximum number of retransmission attempts for each class i._i, And (RN_i, ..., RN_i') Random chip delay for each class i distributed between. Where RN_i&lt;RN_{i + 1}, RN_i'&lt;RN_{i + 1}'For example, RN₀&lt;RN₁, RN₀'&lt;RN₁'. It can be acknowledged that i = 0,1, ..., etc. Therefore, when selecting the chip delay associated with access priority class 0 (highest priority), it is on average smaller than the chip delay in the distribution associated with lower access priority classes, such as class 1. Make a selection from the distribution of random chip delays. Therefore, the remote terminal set as class 0 has a higher priority than the remote terminal set as class 1.

[0033] Therefore, in step 502, the remote terminal determines whether a new class request is needed to receive the packet to be transmitted (via its associated processor). If necessary, in step 504, the remote terminal selects a logical access channel (1, ..., M). Then, in step 506, based on the required priority class (eg, depending on the nature or content of the data to be transmitted) or based on the priority class belonging to the remote terminal (eg, the user of the remote terminal is specific. Levels, eg, if you subscribe to services such as high, remote terminals are distributed (RN)_i, ..., RN_iSelect a random chip delay from'). If the transmission priority is high, the remote terminal chooses from the lowest random chip delay distribution, which increases the chances of a successful request. If the transmission priority is low, the remote terminal chooses from the highest random chip delay distribution, so the request is less likely to succeed than a remote terminal requesting access in a higher priority class. Become. Of course, depending on the priority, the remote terminal can select from any random chip delay distribution in between. Then, in step 508, an access request is sent on the selected logical access channel according to the selected chip delay.

[0034] In step 510, the terminal then determines whether the access request has been successfully received by the base station. This can be done by the base station sending an access request approval message to the terminal (step 1106 in FIG. 11). If the access request is successful, the access priority control method ends (block 512) and the remote terminal can transmit the packet according to the packet forwarding method used in UMTS.

However, if the request is unsuccessful, in step 514 the terminal increments a variable called no_tx by 1 (no_tx ++). It will be appreciated that the variable no_tx represents the number of times the remote terminal has sent an access request (this value is stored in the memory associated with the remote terminal's processor). In step 516, change no_tx to K_iCompare with (maximum number of class i retransmission attempts). no_tx is K_iIf greater than, the current access request is withdrawn (step 518). Large K for high priority classes_i(Ie K_i K_{i + 1}It will be understood that you can assign) to make more retransmission attempts. If the maximum number of retransmissions has not been reached, the backoff process is performed in step 520. It is preferable to adopt a backoff procedure, because assuming that several remote terminals attempted to send an access request signal at about the same time but were unsuccessful (the reason for the failure is, for example, between requests. It can be acknowledged that it is not desirable for each remote terminal to attempt to retransmit at about the same time (which can be a collision). Therefore, each terminal delays its retransmission by a randomly selected amount of time to reduce the possibility of conflicting access requests being resent. In an alternative embodiment, the backoff can be performed according to the procedure of the invention described below with respect to FIG. After the backoff, at step 522, the remote terminal waits for the next available access slot and then returns to step 504 to repeat the process.

[0036] With reference to FIG. 6, a flowchart of the access priority control method 600 in the remote terminal according to the second embodiment of the present invention is shown. Again, it would be acceptable for this methodology to be performed on a remote terminal (eg terminal 2 or 4) that generated or received a packet to be transmitted uplink to a UMTS base station (eg base station 6). The embodiment shown in FIG. 6 is hereinafter referred to as access priority (RBBAP) based on random backoff. In general, the RBBAP approach has the advantage of assigning a different average backoff delay to each priority class. Requests associated with high access priorities have a low average backoff delay. Whenever there is a conflict, or for any other reason the access request is not successfully received at the base station, the remote terminal is in range (D), depending on class i._i, ..., D_i'), Select the random delay distributed between. D_i D_i', D_i D_{i + 1}, D_i'D_{i + 1}'And here class i has a higher priority than class i + 1.

[0037] In the access priority embodiment of FIG. 6, in step 601, the remote terminal receives and stores (in its memory) the following access priority system parameters that the base station broadcasts. The parameters are M, which is the number of logical access channels existing between the remote terminal and the base station, and K, which is the maximum number of retransmission attempts for each class i._i, And (D_i, ..., D_iIt is a random delay distributed between'). D_i D_i', D_i D_{i + 1}, D_i'D_{i + 1}', And class i has a higher priority than class i + 1. Therefore, when choosing a backoff delay associated with a higher access priority, choose from a random backoff delay distribution that is on average smaller than the backoff delay in the distribution associated with a lower access priority class. I do. For example, a remote terminal set as class 0 has a higher priority than a remote terminal set as class 1.

[0038] Therefore, in step 602, the remote terminal determines whether a new access request is needed to receive the packet to be transmitted (via its associated processor). If necessary, in step 604, the remote terminal selects a logical access channel (1, ..., M). Then, in step 606, an access request is sent on the selected logical access channel. Next, in step 608, the terminal determines whether the access request has been successfully received by the base station. This can also be done by the base station sending an access request approval message to the terminal (step 1106 in FIG. 11). If the access request is successful, the access priority control method ends (step 610), and the remote terminal can transmit the packet according to the packet forwarding method used in UMTS.

[0039] However, if the request is unsuccessful, in step 612, the terminal increments the variable no_tx by one. In step 614, K no_tx_iCompare with. no_tx is K_iIf greater than, the current access request is withdrawn (step 616). If the maximum number of retransmissions has not been reached, a backoff process is performed in step 618. In step 618, the remote terminals are distributed (D) based on the required priority class or the priority class that belongs to the remote terminal._i, ..., D_iSelect a random backoff delay from'). Therefore, if the transmission priority is high, the remote terminal chooses from the lowest random backoff delay distribution, which increases the chances of a successful request. That is, the backoff delay is relatively short so that retransmissions occur relatively faster than in lower classes. If the transmission priority is low, the remote terminal chooses from the highest random backoff delay distribution, so the request is less likely to succeed than a remote terminal requesting access in a higher priority class. Become. Of course, depending on the priority, the remote terminal can select from any random backoff delay distribution in between. After the backoff, at step 620, the remote terminal waits for the next available access slot and then returns to step 604 to repeat the process.

[0040] With reference to FIG. 7, a flowchart of the access priority control method 700 in the remote terminal according to the third embodiment of the present invention is shown. Again, it would be acceptable for this methodology to be performed on a remote terminal (eg terminal 2 or 4) that generated or received a packet to be uplinked to a UMTS base station (eg base station 6). The embodiment shown in FIG. 7 is hereinafter referred to as access priority (VLCAP) based on variable logical channels. In general, the VLCAP method gives each subscriber an access priority class i. The one with the highest priority (class 0) has access to all logical access channels (eg 16x8) in which the base station is configured, while the one with the lowest priority is the logical access channel. Only a small subset of, eg, only one preamble sign with eight time offsets, is allowed to be accessed. The rationale for this approach is that the greater the number of logical access channels that a remote terminal chooses, the more likely it is to find a channel through which access requests are successfully transmitted.

[0041] In the access priority embodiment of FIG. 7, in step 701, the remote terminal receives and stores (in its memory) the following access priority system parameters that the base station broadcasts. The parameters are M, which is the number of logical access channels existing between the remote terminal and the base station, and N, which is the maximum number of logical access channels that class i can access._i(N_i&gt; N_{i + 1}And N₀= M), and K, which is the maximum number of retransmission attempts for each class i_iIs.

[0042] Therefore, in step 702, the remote terminal determines whether a new access request is needed to receive the packet to be transmitted (via the processor with which it is associated). If necessary, in step 704, the remote terminal has a logical access channel (1, ..., N)._i) Is selected. That is, the logical channels are selected from a set of logical channels, the size of which set depends on the priority class of the request. If the request is of the highest priority class, the remote terminal can make a choice from all M logical access channels, but as the request priority decreases, the size of the subset of choices decreases. .. In an alternative embodiment, the remote terminal can store the random chip delay at this point and then select it according to the RCDAP approach in FIG. Then, in step 706, an access request is transmitted on the selected logical access channel. Next, in step 708, the terminal determines whether the access request has been successfully received by the base station. This can also be done by the base station sending an access request approval message to the terminal (step 1106 in FIG. 11). If the access request is successful, the access priority control method ends (block 710) and the remote terminal can transmit the packet according to the packet forwarding method used in UMTS. However, if the request is unsuccessful, in step 712 the terminal increments the variable no_tx by one. In step 714, set no_tx to K_iCompare with. no_tx is K_iIf greater, the current access request is withdrawn (step 716). If the maximum number of retransmissions has not been reached, the backoff process is performed in step 718. In an alternative embodiment, the backoff process is the same as described above in step 618 of FIG. After the backoff, at step 720, the remote terminal waits for the next available access slot and then returns to step 704 to repeat the process.

[0043] With reference to FIG. 8, a flowchart of the access priority control method 800 in the remote terminal according to the fourth embodiment of the present invention is shown. It will be understood that Method 800 is a variant of the VLCAP method of Figure 7. This variant is called VLCAP'and specifically takes into account the special UMTS access channel structure. That is, even if there are eight time offsets for each preamble sign, the base station does not have eight parallel processors due to the limited processing complexity associated with the base station. There is. For example, each is (i^th, (i + 4)^thThere may be only four receivers programmed to capture the time offset of). However, it will be acknowledged that the time offsets do not have to be continuous. That is, the receiver may capture the first four time offsets received, such as time offsets 1, 3, 5 and 6. Therefore, according to the VLCAP'method, requests in the lower priority class are assigned a higher numbered time offset, which allows the receiver to first capture access requests from the higher priority class. it can. That is, for higher priority classes, they are assigned a lower numbered time offset (eg 1-4), from which they make a choice, while lower priority classes are assigned higher numbered times. -Slots are assigned (eg 5-8) and you can make a selection from them. Therefore, a high priority access request is more likely to be received than a low priority access request.

[0044] In the access priority embodiment of FIG. 8, in step 801 the remote terminal receives and stores (in its memory) the following access priority system parameters that the base station broadcasts. The parameters are P, which is the maximum number of preamble signs (for example, P 16), and T, which is the number of time offsets (for example, T &lt;8). The total number of logical access channels (PxT) representing the split function) and the maximum number of retransmission attempts for each class i K_iIs.

[0045] Therefore, in step 802, the remote terminal determines whether a new access request is needed to receive the packet to be transmitted (via its associated processor). If necessary, in step 804, the remote terminal selects a preamble from (1, ..., P). Then in step 806, for class i, the remote terminal is (T)._i, ..., T_iSelect one time offset from'). T_i&lt;T_{i + 1}, T_i'&lt;T_{i + 1}', T₀= 0, T_max'= 8. For example, class 0 (the highest priority class) can choose from a set of time offsets in the range between time offset 0 and time offset 4. In an alternative embodiment, the remote terminal can store the random chip delay at this point and then select it according to the RCDAP approach in FIG. Then, in step 808, an access request is sent on the selected access channel.

[0046] Next, in step 810, the terminal determines whether or not the access request has been successfully received by the base station. This can also be done by the base station sending an access request approval message to the terminal (step 1106 in FIG. 11). If the access request is successful, the access priority control method ends (block 812) and the remote terminal can transmit the packet according to the packet forwarding method used in UMTS.

However, if the request is unsuccessful, in step 814 the terminal increments the variable no_tx by one. In step 816, change no_tx to K_iCompare with. no_tx is K_iIf greater than, the current access request is withdrawn (step 808). If the maximum number of retransmissions has not been reached, the backoff process is performed in step 820. In an alternative embodiment, the backoff process is the same as described above in step 618 of FIG. After the backoff, at step 822, the remote terminal waits for the next available access slot and then returns to step 804 to repeat the process.

[0048] With reference to FIG. 9, a flowchart of the access priority control method 900 in the remote terminal according to the fifth embodiment of the present invention is shown. Again, it will be appreciated that this methodology is performed on a remote terminal (eg terminal 2 or 4) that generated or received a packet uplinked to a UMTS base station (eg base station 6). The embodiment shown in FIG. 9 is hereinafter referred to as a probability-based access priority (PBAP). In general, the PBAP method gives each subscriber an access priority class i. Each access priority class i has a certain probability P_iIt is only possible to send an access request with. Those with the highest priority (class 0) will always send their access requests whenever they have them. For example, P₀= 1 (high priority), P₁= 0.5 (low priority). Also, each access priority class has a different maximum number of retries. Classes with lower access priority have a smaller maximum number of retries.

In the access priority embodiment of FIG. 9, in step 901, the remote terminal receives and stores (in its memory) the following access priority system parameters that the base station broadcasts. The parameters are M, which is the number of logical access channels existing between the remote terminal and the base station, and the probability P for each class i._i, And the maximum number of send attempts associated with class i, K_iIs. Where P_i= 1 and P_i&lt;P_{i + 1}, K₀= K_maxAnd K_{i + 1}&lt;K_iIs.

[0050] Therefore, in step 902, the remote terminal determines whether a new access request is needed to receive the packet to be transmitted (via its associated processor). If necessary, in step 904, the remote terminal sets the variable no_tx = 0. This is a retransmission attempt variable. Then, in step 906, the remote terminal is x&gt; (1-P_i) Is determined. It can be acknowledged that x is a random variable that is evenly distributed between 0 and 1. x is (1-P_i) The remote terminal waits for the next available access slot in step 908 and then returns to step 904 to repeat the process. x&gt; (1-P_i), The remote terminal selects the logical access channel (1, ..., M). Then, in step 912, an access request is sent on the selected logical access channel. Next, in step 914, the terminal determines whether the access request has been successfully received by the base station. This can also be done by the base station sending an access request approval message to the terminal (step 1106 in FIG. 11). If the access request is successful, the access priority control method ends (block 916) and the remote terminal can transmit the packet according to the packet forwarding method used in UMTS.

However, if the request is unsuccessful, in step 918 the terminal increments the variable no_tx by 1. In step 920, set no_tx to K_iCompare with. no_tx is K_iIf greater than, the current access request is withdrawn (step 922). If the maximum number of retransmissions has not been reached, the backoff process is performed in step 924. In an alternative embodiment, the backoff process is the same as described above in step 618 of FIG. After the backoff, the remote terminal waits for the next available access slot in step 908 and then returns to step 904 to repeat the process.

[0052] With reference to FIG. 10, a flowchart of the access priority control method 1000 in the remote terminal according to the sixth embodiment of the present invention is shown. It will be appreciated that this methodology is performed on a remote terminal (eg terminal 2 or 4) that generated or received a packet uplinked to a UMTS base station (eg base station 6). The embodiment shown in FIG. 10 is hereinafter referred to as a retransmission-based access priority (REBAP). In general, the REBAP approach assumes that every access request has its associated access packet priority (APP). In the REBAP method, the retransmitted access request is given a higher priority than the new access request. Such a mechanism is smaller than the smaller average access delay for all successful trials 95^thOr 99^thIt is attractive for some applications that require percentile access delays. The lowest APP class (n) for all new access requests_max-1) is given. They are then dynamically adjusted based on the number of retransmissions. Access packets are accessible to all M logical access channels, but choose different random chip delays depending on the access packet priority class. The lowest APP class chooses from the highest average random chip delay distribution. Access requests that fail and require retransmissions preferably adjust their APP class. Note that in addition to the APP mechanism, access service priority (ASP) classes can also be specified. Requests with the highest ASP, eg class 0, automatically increase the APP of failed access requests on each retry. If ASP is lower than this, do not aggressively adjust the APP for failed trials. For example, ASP class 1 can only increase the APP of an access request after two failures.

[0053] In the access priority embodiment of FIG. 10, in step 1001, the remote terminal receives and stores (in its memory) the following access priority system parameters that the base station broadcasts. The parameters are M, which is the number of logical access channels existing between the remote terminal and the base station, and APP for each class i. APP is two numbers, the maximum number of retries for each class i, K_iAnd RN representing the random chip delay for each class i_iRelated to. Also, APP is 0, ..., n_maxAssumed to be in the range of -1, 0 has a higher priority. When using ASP, parameters ASP and S_jIs also transmitted by the base station and received and stored by the remote terminal. S_jRepresents the number of retransmissions required for class j before updating the APP of access requests from class j. For this reason, K_iIs related to the APP priority class, S_jIs related to the ASP priority class. For example, ASP = 0,1,2 and S₀= 1, S₁= 3, S₂= 5.

[0054] Therefore, in step 1002, the remote terminal determines whether a new access request is needed to receive the packet to be transmitted (via its associated processor). If necessary, in step 1004, the remote terminal has APP = n_maxSet to -1, ASP = j, no_tx = 0, and adj = 0 (adj will be explained below). Then, in step 1006, the remote terminal is distributed (RN)._i, ..., RN_iSelect a random chip delay from'). In step 1008, the remote terminal selects a logical access channel (1, ..., M). Then, in step 1010, an access request is sent on the selected logical access channel according to the chip delay. Next, in step 1012, the terminal determines whether the access request has been successfully received by the base station. This can also be done by the base station sending an access request approval message to the terminal (step 1106 in FIG. 11). If the access request is successful, the access priority control method ends (block 1014) and the remote terminal can transmit the packet according to the packet forwarding method used in UMTS.

However, if the request is unsuccessful, in step 1016 the terminal increments the variables no_tx and adj by one. The variable no_tx represents the number of times the remote terminal sent an access request, and adj is S._jRepresents a variable used to check if has been reached. In step 1018, set no_tx to K_iCompare with. no_tx is K_iIf so, the current access request is withdrawn (step 1020). However, no_tx is K_iIf the remote terminal has adj S_jIt is determined whether or not the above is the case (step 1022). adj is S_jIf not, APP stays at the same value set in step 1004. Then, in step 1024, a backoff process is performed. The backoff process may be the same as described above in step 618 of FIG. After the backoff, at step 1026, the remote terminal waits for the next available access slot and then returns to step 1006 to repeat the process. However, adj is S_jIf so, the APP is decremented by 1 (APP = n-1), which raises the priority of the retransmitted request (step 1028). Also, in step 1028, adj is reset to zero. Then, in step 1024, a backoff process is performed. After the backoff, at step 1026, the remote terminal waits for the next available access slot, then returns to step 1006 and repeats the process.

It will be appreciated that the use of the access priority methodology of the present invention can be beneficial and advantageous in a variety of applications, as described herein. The following are just a few examples of such applications. Existing wireless access systems have not been addressed to allow users with urgent needs to gain access with a higher priority than other types of users. One possible embodiment of access priorities according to the invention is to reserve some logical access channels so that only urgent users can access them. In another situation, the service provider can differentiate different types of customers based on the service fees paid by the customer in accordance with the present invention. The CEO may want to reduce access latency so that his message can traverse the network faster than others. Preferably, this service is combined with a service priority to allow the user to perceive better terminal delays. This object can also be achieved by using the access priority mechanism of the present invention to reduce access delays for some real-time services, such as interactive video. Furthermore, the present invention provides a new access mechanism included in UMTS MAC. Access priorities can be used with scheduling algorithms to provide customers with a variety of quality of service based on either service charges, urgent needs, or delay requests.

Although exemplary embodiments of the invention have been described herein with reference to the accompanying drawings, the invention is not limited to these explicit embodiments, but from the scope and spirit of the invention. It will be appreciated that various other changes and modifications can be made by those skilled in the art without deviation. For example, although some modifications of the embodiments shown in the flowchart have been described above, the present invention considers combining any of the embodiments or variants thereof with one or more other embodiments or variants thereof. It will be admitted that there is.

[ODMAFQ MAC Protocol Operation] The overall operation of the ODMAFQ MAC protocol is shown in the flowcharts of FIGS. 12A and 12B. Figure 12A is a view from a remote host (terminal). After establishing the power level of uplink transmission (1210), the remote host participates in the uplink initial conflict (1215), during which time each remote with packets to send access the AP (base station). Send a request. Some of these access requests are the same reserved minislot (reservation) When a conflict occurs because it is presented in (minislots) (1220), the conflicting remote host is involved in resolving the uplink conflict (1225). Otherwise, the AP goes ahead and allocates uplink bandwidth between the remote hosts requesting access (1230) and then allocates bandwidth for its own downlink transmission (1235). Each remote host receives a transmit permission (1237) during subsequent downlink transmissions, which in turn sends a waiting packet from its queue. If the remote queue is not empty at that time (1238), the remote returns and waits for another send permission (1237), otherwise it waits for the arrival of a new packet (1239).

[0059] As shown in FIG. 12B, the AP monitors the activity in the received conflict resolution slot (1260). Upon receiving a successful access request (1265), the AP issues an ACK knowledge (1270) and adds the newly successful remote to the schedule list (1275). With or without a new successful access request (1265), the AP also monitors the uplink data slot (1280) unless the schedule list is empty, and when it receives a successfully transmitted packet (1285), the data ACK Respond by (1290). The AP then schedules its downlink packet (1240), schedules the uplink transmission of the distant host with a successful conflict (1245), issues the associated transmit permission (1250), and then the downlink data. Sends a packet (1255) and then returns to monitoring activity in the conflict resolution slot (1260).

An optional channel retention mechanism is provided that allows each queue to remain empty for a short period of time without the access point unreserving bandwidth. It may be desirable. This allows high priority users to stay in the base station reserved bandwidth list for the allotted amount of time before the base station is unreserved, which is required for channel reservation. By avoiding all setup signaling message transmissions, it helps reduce latency for real-time packets (ie, for time-sensitive data packets such as voice communications, with little or no delay). This mechanism is used to trigger a timer in the wireless modem when the queue is empty. As long as a new packet arrives at the wireless modem before the timer expires, the wireless modem does not need to make a new access request. When this mechanism is turned on in the AP, the AP will identify this every other uplink frame, even if the latest uplink data transmission from the wireless modem indicates that the queue is empty. Assign permission to send one data slot to your wireless modem. The AP also starts the timer. If the timer expires and the AP is not receiving new packets from that wireless modem, the AP removes this wireless modem from the reserved bandwidth list. This channel retention mechanism is especially useful when the bandwidth reservation process requires a certain amount of time to complete, where real-time packets do not arrive continuously, but due to contention for each data packet. The latency can be reduced if they are not far enough apart to allow separate bandwidth reservation requests. However, for bursty sources that do not require this channel retention mechanism, if a packet arrives and finds an empty buffer, the modem will still send an access request to the AP through one of the competing minislots.

FIG. 13A shows an example of an access control method. Configure N competing reserved minislots in each uplink frame (1310). The N time slots are organized into multiple access priority classes, each with a different priority. The AP is configured to allow m access priority classes (1315). Each access priority class i remote host randomly selects one competing minislot (1320) and sends an access request. The selected competing minislots are 1 to N_iIs in the range of, where N_{(i + 1)}&lt;N_iAnd N₁= N. The base station receives the access request (1325) and sequentially examines the received competing minislots. If the minislot currently being examined contains a non-collision request (1330), the AP grants access to the remote host corresponding to the non-collision access request (1835). If the minislot currently being examined contains a conflicting request (1330), the AP does not send an ACK and causes the associated remote node to perform conflict resolution (1340). After the conflict resolution period, the AP gives access to the remote host that won the conflict (1345). In the meantime, if there are other minislots left to look for (1350), the AP will continue to look for minislot collisions (1330), giving access to the host of the successful requester (1335), or resolving the conflict. Wait for the result (1340).

[0062] FIG. 13B is a flowchart showing an alternative embodiment of the access control method. Organize N minislots into multiple access priority classes, each with a different priority. Configure N competing reserved minislots in each uplink frame (1310). Organize N minislots into multiple access priority classes, each with a different priority. The AP is configured to allow m access priority classes (1315). Each remote host with a stack level equal to access priority classes i and 0 has a probability P_iSend an access request for. Where P_{(i + 1)}&lt;P_iAnd P₁= 1 (1360). The base station receives the access request (1325) and sequentially examines the received competing minislots. If the minislot currently being examined contains a non-collision request (1330), the AP grants access to the remote host corresponding to the non-collision access request (1335). If the minislot currently being examined contains a conflicting request (1330), the AP does not send an ACK and causes the associated remote node to perform conflict resolution (1340). After the conflict resolution period, the AP gives access to the remote host that won the conflict (1345). If there are other minislots left to look for (1350), the AP will continue to look for minislot collisions (1330), give access to the host of the successful requester (1335), or wait for the result of conflict resolution. (1340).

[0063] IDLE, SUCCESS and COLLISION status information is returned to the wireless modem. The AP distributes this slot status information in the downlink reservation approval field. Three alternative conflict resolution methods can be used. The first method is proposed in the IEEE802.14 standard and is described with the following two new methods. Simulation results show that the second method described below provides better access latency.

[0064] In the first conflict resolution method proposed in IEEE Standard 802.11, each radio node wishing to transmit randomly selects one of the reserved minislots. If a collision is indicated, the modem affected by this collision will retransmit based on a random binary exponential backoff method. This backoff method is performed according to the following.

[0065] 1. The modem is 0 to 2.^jGenerates a random number I that is evenly distributed between -1. Where j is the number of collisions the modem has experienced with respect to the packet being attempted to send. 0 to 2 if j is greater than 10¹⁰Select I from a uniform distribution between -1. 2. The modem skips the opportunity for the next I-1 conflict slot of the same type (mini slot or data conflict slot) and retransmits the previously collided packet at the opportunity for the immediately following conflict slot.

FIG. 14A shows the operation of this method. A radio node waiting to access the AP randomly selects a reserved minislot to send an access request (1402). If this node is affected by a collision (1404), the node generates a random number I (1408), skipping the opportunity for the next I-1 competing slot of the same type (1410). The node resends the access request for the conflicting packet at the opportunity of the conflicting slot immediately after (1412). If the node is unaffected by the collision (1404), if the queue at the node is empty (1405), the node sends a packet (1406) and returns to the wait state (1402). If the queue on the node is not empty (1405), after receiving permission to send from the AP, the node sends the current packet with a reservation request attached to that queue to send the next packet (1407). After receiving the send permission, the node continues to send packets with the added reservation request 1407 (1407) until the queue is empty (1405), and after sending the last packet (1406), the node returns to the wait state. (1402).

[0067] In the second and third methods, the AP broadcasts the result of each conflict in the reserved minislot to all radio nodes via a downlink broadcast message. In the second method, the modem at each radio node is characterized by a stack level, and only radio nodes with a stack level equal to zero are allowed to send access request packets. Modems with stack levels greater than zero are considered unprocessed. For example, if there are M reserved minislots, each remote node at stack level 0 can randomly select one of the M minislots. At the end of the time slot, radio node i changes the stack level based on the result of transmission in that time slot. This method allows the newly activated radio node to join an existing radio node with stack level 0 during a particular conflict resolution period. Each radio node in the request state increments the stack level by 1 if it receives a negative authorization (eg, a collision) from the base station (AP) without sending an access request packet. On the other hand, the radio node reduces its stack level by 1 when it receives a positive approval from the base station indicating the successful transmission of the access request. Each radio node involved in sending an access request makes a random selection to determine if its stack level remains level 0 or if it receives a negative approval from the base station and increments by 1. ..

[0068] The rules of the second method are as follows. 1. If a wireless node wants to gain access to the network first, or if it has already gained access and wants to send out new data, it is put in a request state and assigned a stack level of zero. 2. If there are M reserved minislots, each requesting radio node randomly selects one of the M reserved minislots as an allocated minislot for sending access request packets. 3. If the radio node is characterized by a stack level equal to zero, send an access request packet. However, if the remote node is characterized by a stack level greater than zero, it will not send access request packets. 4. At the end of the time slot, each radio node changes its stack level based on the result of the access request (either COLLIDED, IDLE or SUCCESS). This is reported for the allocated minislot in the booking approval field of the downlink message from the access point. A. The radio node that sent the access request and received the SUCCESS result is removed from the request state. B. The radio node that sends the access request and receives the COLLIDED result either increments the stack level by 1 or leaves the stack level at zero depending on the result of the random draw. C. A radio node that is in a request state but did not send an access request (that is, an unprocessed node with stack level&gt; 0) has a COLLIDED result reported in the reservation approval field for the allocated minislot. Increment the stack level by 1. D. Radio nodes that are in the request state but did not send an access request (ie, unprocessed nodes with stack level&gt; 0) are stacked if the result reported in the reservation approval field for the allocation minislot is SUCCESS. Decrease the level by 1.

FIG. 14B shows the operation of this method. Radio nodes waiting to access the AP or send new data set the stack level to 0 and enter the request state (1432). If the node has a stack level of 0 (1434), the node randomly selects a reserved minislot for sending the access request and sends this access request (1436). If the result of the request is SUCCESS (1438) and the queue at the node is empty (1439), the node sends the current packet, exits the request state (1440), and returns to the wait state (1432). If the queue on the node is not empty (1439), after receiving permission to send from the AP, the node sends the current packet with a reservation request for sending the next packet attached to that queue (1441). After receiving the send permission, the packet continues to be sent with the added reservation request (1441) until the queue is empty (1439). At this point, it sends the remaining packets, exits the request state (1440), and returns to the wait state (1402).

If the result of the reservation request (1436) is not SUCCESS (1438), the node participates in a random draw (1444) and either increments its stack level by 1 (1448) or increments its stack level. Know if you want to leave it at 0 (1446). If the stack level remains 0 (1446), the node again randomly selects a reserved minislot for sending the access request and sends the access request (1436). When incrementing the stack level (1448), the stack level is no longer 0 (1434). If the stack level of any remote node is non-zero (1434) and the result of a previous reservation request is COLLIDED (1450), the node increments the stack level by 1 (1452). If the result of the previous reservation request is not COLLIDED (1450), the node decrements the stack level by 1 (1454).

The third conflict resolution method is a modification of the second method. The third conflict resolution method also characterizes the modem at each radio node by stack level, and only radio nodes with a stack level equal to zero are allowed to send access request packets. Modems with stack levels greater than zero are considered unprocessed. The rules of the third method are as follows.

1. If a wireless node wants to gain access to the network first, or if it has already gained access and wants to send out new data, it is put in a request state and assigned a stack level of zero. Be done. 2. If there are M reserved minislots, each requesting radio node randomly selects one of the M reserved minislots as an allocated minislot for sending access request packets. 3. If the radio node is characterized by a stack level equal to zero, send an access request packet. However, if the remote node is characterized by a stack level greater than zero, it will not send access request packets. 4. At the end of the time slot, each radio node changes its stack level based on the result of all access requests (either COLLIDED, IDLE or SUCCESS). This is reported in the booking approval field of the downlink message from the access point. A. The radio node that sent the access request and received the SUCCESS result is removed from the request state. B. The radio node that sends the access request and receives the COLLIDED result either increments the stack level by 1 or leaves the stack level at zero depending on the result of the random draw. C. Radio nodes in the request state but not sending access requests (ie, unprocessed nodes with stack level&gt; 0) report at least 80% of the reservation approval field (or some other predetermined threshold). If the result of all access requests made is SUCCESS or IDLE, the stack level is decremented by 1. Otherwise, the remote node increments the stack level by 1. D. If unprocessed modem = s, the stack level is reduced to zero and the modem retransmits the request, so M minislots (or I if increasing access priority)._iRandomly select one of the mini slots).

FIG. 14C shows the operation of this method. This is similar to the operation of the method of FIG. 14B. Radio nodes waiting to access the AP or send new data set the stack level to 0 and enter the request state (1432). If the node has a stack level of 0 (1434), the node randomly selects a reserved minislot for sending the access request and sends this access request (1436). If the result of the request is SUCCESS (1438) and the queue at the node is empty (1439), the node sends the current packet, exits the request state (1440), and returns to the wait state (1432). If the queue on the node is not empty (1439), after receiving permission to send from the AP, the node sends the current packet with a reservation request attached to that queue to send the next packet (1441). After receiving the send permission, the packet continues to be sent with the added reservation request (1441) until the queue is empty (1439). After sending the remaining packets, it exits the request state (1440) and returns to the wait state (1402).

If the result of the reservation request (1436) is not SUCCESS (1438), the node participates in a random draw (1444) and increments its stack level by 1 (1448) or its. Know if you want to leave the stack level at 0 (1446). If the stack level remains 0 (1446), the node again randomly selects a reserved minislot for sending the access request and sends the access request (1436). When incrementing the stack level (1448), the stack level is no longer 0 (1434). If the stack level of any remote node is not 0 (1434), and if the result of all reservation requests during the previous cycle is COLLIDED above a certain threshold (1460), then the node has only 1 stack level. Increment (1462). If the result of the previous reservation request is not COLLIDED (1460), the node decrements the stack level by 1 (1464).

BRIEF DESCRIPTION OF THE DRAWINGS [Fig. 1] Fig. 1 is a block diagram of a UMTS access network.

FIG. 2 is a diagram of a protocol stack associated with UMTS.

FIG. 3 is a block diagram of a non-coherent RACH receiver for use in UMTS.

FIG. 4A shows access slots used in UMTS RACH.

FIG. 4B shows the structure of a random access burst used in UMTS RACH.

FIG. 5 is a diagram showing a flowchart of an access priority control method in a remote terminal according to the first embodiment of the present invention.

FIG. 6 is a diagram showing a flowchart of an access priority control method in a remote terminal according to a second embodiment of the present invention.

FIG. 7 is a diagram showing a flowchart of an access priority control method in a remote terminal according to a third embodiment of the present invention.

FIG. 8 is a diagram showing a flowchart of an access priority control method in a remote terminal according to a fourth embodiment of the present invention.

FIG. 9 is a diagram showing a flowchart of an access priority control method in a remote terminal according to a fifth embodiment of the present invention.

FIG. 10 is a diagram showing a flowchart of an access priority control method in a remote terminal according to a sixth embodiment of the present invention.

FIG. 11 is a diagram showing a flowchart of an access priority control method in a base station according to the present invention.

FIG. 12A shows a flowchart showing the overall ODMAFQ protocol operation as seen from the remote host side.

FIG. 12B is a diagram showing a flowchart showing the overall ODMAFQ protocol operation as seen from the base station side.

FIG. 13A is a diagram showing a flowchart showing an embodiment of an ODMAFQ access control method.

FIG. 13B shows a flowchart showing an alternative embodiment of the ODMAFQ access control method.

FIG. 14A shows a flowchart showing one of the three ODMAFQ conflict resolution methods.

FIG. 14B shows a flowchart showing one of the three ODMAFQ conflict resolution methods.

[Fig. 14C] Fig. 14C is a diagram showing a flowchart showing one of three ODMAFQ conflict resolution methods.