Packet switched radio channel admission control in a cellular telecommunications system

Background of the Invention The present invention relates to a packet-switched communication system, and more particularly to a method and a system for controlling access to a packet-switched radio channel of a cellular communication system. History of prior art Packet-switched services will play an increasingly important role in the field of cellular communications as the ability of cellular communication systems to provide a larger number and variety of services develops. Let's go. To apply many computers and related data services to a cellular system, one or more data packets must be forwarded through the wireless link of the cellular communication system. Some of these services, such as email and telebanking, can be performed with shops and can forward short message services. However, other services such as terminal emulation, local area networks, bank server access and credit card identification need to be interactive and vary in short delay and length. You also need the ability to handle changing data packets. There is no doubt that future cellular systems will have to support these services with efficient packet data services. As a result of the recognition of the importance of packet data services, the European Institute of Technology Standards (ETSI) is currently striving to develop the above services for the European 2+ Group Special Mobility (GSM) cellular systems. There is. In addition, as a result of the above recognition, RACE Efforts are being made to introduce packet data service capabilities into the UMTS, which is currently under development in the II Code Split Testbed (CODIT) Project R2020. The CODIT project was designed by the Commission of the European Community to define future mobile communication systems that use Code Division Multiple Access (CDMA) technology. A feature of packet-switched data services in cellular remote networks is that calls from users of the network to the mobile station are sent to the packet-switched mobile station through the shared downlink (DL) of the packet-switched radio channel (PRCH). And one or more mobile station users share the PRCH uplink (UL). DL PRCH is shared by network users according to the queue. The DL PRCH is shared by each mobile station user, who randomly accesses the channel to send data to the system as needed by the mobile station user. The usual way to allow access to PRCH is to use packet-switched connection mode. Currently defined CODIT The UMTS packet data service is based on a line competition method. In the case of the packet-switched line scramble method, the mobile station user transmits the data packet through PRCH when the data needs to be transferred. The identification of the transmitting mobile station user is included in each data packet. Data packets can be sent by the mobile station user at random, or when the packet data channel detects a free signal indicating that it is not currently in use by another mobile station. it can. If two or more mobile station users vie for a free data channel at the same time, the system only grants one access to that channel. Mobile station users who are unable to access the channel must iteratively send data packets until accepted by the system. System users who are sending data packets to mobile station users must also enter the queue and compete for downlinks. In the above system, each user randomly accesses a packet-switched channel, so that the flow to and from the packet-switched radio channel of the cellular system and between the channels must be controlled. There is a risk of delay in packet transmission. The delay can occur both by the mobile station user on the uplink and by the network user transmitting to the mobile station user via the downlink. As the number of packet-switched pagers on a packet-switched channel increases, the average transmission delay for each packet-switch increases. In some cases, the delay becomes too long, which causes a problem in use. Therefore, a method and system for controlling the delay of packet transmission on one or more packet-switched radio channels of the cellular system is needed. Select to allow competing packet calls to enter the packet radio channel according to predefined criteria If possible, delays for packet-switched channel users, which would be hindered by long packet delay times, can be avoided or reduced. Priority users using each packet-switched radio channel with maximum permissible packet-transmission delay, to or from one or more packet-switched radio channels, or between these channels. Any method and system for managing the flow of the above can be met. Outline of the Invention The present invention provides a method and a system for performing ingress control to a packet-switched radio channel in a cellular communication system. Using the present invention, the system operator can set the maximum average delay time that occurs during a packet call for a user who is authorized to access the packet switching radio channel (PRCH). By setting a maximum average delay time for one or more PRCHs in the system, the system operator can ensure that PRCH users do not suffer unbearable packet transmission delays. .. Higher priority packet calls that do not allow long packet delays can enter the PRCH before lower priority packet calls. By doing so, it is possible to avoid problems related to the conventional competing packet switching channel in which each user randomly competes for the use of PRCH. In the above-mentioned conventional system, as the number of users competing for PRCH increases, an average delay time for data packet transmission occurs. In the case of one embodiment of the invention, the invention includes a PRCH approach control function for each PRCH of the system. The entry control function receives an entry request from the PRCH manager requesting the use of PRCH for packet invocation. After that, the entry control function generates an entry permission message or an entry refusal message to the PRCH manager. The PRCH approach control function is by calling a packet. By determining whether the requested estimated data traffic plus the traffic from the current packet call with a priority higher than or equal to that packet call is less than the maximum allowed traffic. , Evaluate the user's entry request for a packet call to PRCH. Separate and comprehensive assessments can be made for both uplinks and downlinks. If the result of the judgment is yes, the entry control function issues an entry permission message to the PRCH manager, and the packet call enters the PRCH.

BRIEF DESCRIPTION OF THE DRAWINGS If you read the following detailed description with reference to the accompanying drawings, you will be able to better understand the method and system of the present invention. FIG. 1 is a block diagram of a cellular communication system capable of carrying out the present invention. FIG. 2 is a control plane protocol architecture for the packet switching function of a cellular communication system that can carry out the present invention. 3A and 3B are the exchange of signals on the downlink and uplink of the cellular system packet radio channel, operating according to embodiments of the present invention. FIG. 4 is a functional block diagram of a packet radio traffic management function of a cellular system operating according to an embodiment of the present invention. 5A and 5B are flowcharts of processing steps performed by the packet radio channel management function according to an embodiment of the present invention. FIG. 6 is a flowchart of processing steps performed by the packet radio channel controller traffic supervision function according to the embodiment of the present invention. FIG. 7 is a flowchart of processing steps performed by the packet radio channel controller entry control function according to the embodiment of the present invention. FIG. 8 is a flowchart of processing steps performed by the packet radio channel controller congestion control function according to the embodiment of the present invention. Detailed Description of the Invention FIG. 1 is a block diagram of a cellular communication system 100 capable of carrying out the present invention. The cellular system includes a mobile station control node (MCN) 102, a wireless network controller (RNC) 104 and 106, a base station (BS) 108, 110, 112, 114, 116 and 118, and a mobile station (MS) 120. , 122 and 124. Each base station 108, 110, 112, 114, 116 and 118 controls system radio communication with a mobile station within a radio coverage area called the base station cell. Mobile stations 120, 122 and 124 are located in the notification area of which base station the mobile station is in. Communicates with specific base stations among base stations 108, 110, 112, 114, 116 and 118, depending on their location. In the case of FIG. 1, mobile stations 120, 122 and 124 communicate with base stations 108, 112 and 116 through radio interfaces 128, 130 and 132. Base stations 108, 110, and 112 are connected to the wireless network controller 104, and base stations 114, 116, and 118 are connected to the wireless network controller 106. The wireless network controllers 104 and 106 are connected to the mobile control node 102. The mobile control node 102 is a switching center that supports the interconnection of cellular systems to the fixed network 126. The mobile control node 102 can be connected to the fixed network 126 by a terrestrial communication cable or other similar connecting device. The fixed network 126 is an Internet network, a public telephone network (PSTN), an integrated services digital network (ISDN), a packet-switched public data network (PSPDN), or X. Can include 25 systems. Although the cellular communication system of FIG. 1 has a special configuration, the block diagram of the figure is only for showing an exemplary configuration of a system capable of carrying out the present invention. The present invention can be applied to any packet-switched radio system in which a user competes for a packet-switched radio channel (PRCH). In the case of one embodiment of the invention, the cellular system 100 has a code split testbed (CODIT) with PRCH contention access designated for CODIT / UMTS, controlled by the PRCH traffic management features of the invention. ) Operates according to the protocol developed for the UMTS Project. UMTS is a mobile communication system that uses direct sequence code division multiple access (DS-CDMA) with a multi-speed radio interface architecture. In the case of CODIT / UMTS systems, packet radio services are supplied to mobile stations 120, 122 and 124 through one or more PRCHs. Each base station 108, 110, 112, 114, 116 and 118 establishes and terminates one or more PRCHs when requested by network controllers 104 and 106, or mobile control node 102. PRCH is up to 9. Full-duplex, asymmetric, capable of operating independently on both uplink (UL) and downlink (DL) at variable mobile station data rates up to 6kbps (narrowband channel) or 64kbps (mediumband channel) Control node 102. The MCN102 can connect a plurality of mobile stations to one PRCH in one cell. To distinguish between several mobile stations on the PRCH, the MCN102 assigns each mobile station to a Virtual Connection Identification Device (VCI) when access is granted. The VCI is expressed in k bits and acts as a unique address within the area controlled by the MCN102. The PRCH is configured in a 10ms time slot for carrying split packets between mobile stations 120, 122 and 124 and the network. On the DL, the mobile control node 102 can send mobile station data packets and information for controlling access and data transfer on UL to one mobile station or multiple mobile stations at the same time. On UL, if within the notification range area of the same base station, the mobile station will be UL. You can share access to PRCH. After accessing the PRCH, the mobile station sends the packet to the system through a physical channel. The logical channel PRCH can be mapped on two physical channels, including a physical data channel (PDCH) and a physical control channel (PCCH). Two base station transceivers are needed to support one RPCH. To explain FIG. 2, this figure is a protocol stack 200 for the packet switching function of CODIT / UMTS. In mobile stations, the mobile station protocol stack (MS / PS) 218 consists of network layer 202, data link control (DLC) layer 204, medium access control (MAC) layer 206, and physical layer 208. On the network side, the network protocol stack (NW / PS) 220 consists of network layer 210 and DLC layer 212, located within the MCN or RNC, respectively, and the medium access layer (MAC) 214 is the base station and Located at MCN or RNC, and physical layer 216. The disconnected packet service (CLPS) component of network layer 202 provides packet service to the mobile station. The CLPS at Network Layer 210 provides the functionality of VCI registration, identification, allocation and management, and an interface to the packet data network. During a packet call, the CLPS component uses a logical link administrator (LLA) to first forward the packet service configuration signal through dedicated control channels (DCCH and CC). After the packet service configuration is complete, the mobile station is connected to the CLPS and all messages between CLPS, including mobile station data packets, are sent through the DLC to the packet radio (PR) control component. The PR component also manages normal mobile phone system functions such as handover, reconnection, etc. Through PRCH Packets sent are split, protected by a block code (BC) to detect transmission errors on the receiving side, coded as before, interleaved (IL), and switched through a multiplexer (MUX). And sent through PDCH. For example, control information such as power control can also be transferred through the PCCH. On the receiving side, the fragmented packet is reassembled from the received sample, reassembled into packets, and forwarded to the Disconnected Packet Service (CLPS) component. When the receiving block decoder detects the reception of a fragmented packet containing an error, the packet radio control function requests its retransmission. The cellular system 100 can be equipped with several PRCHs distributed between cells controlled by base stations 108, 110, 112, 114, 116 and 118. Explaining FIGS. 3A and 3B, this figure shows the exchange of signals on the uplink (UL) and downlink (DL) of the cellular system PRCH operating according to the present invention, respectively. 3A and 3B show the signal exchange between the mobile station (MS) 300 and the network (NW) 302. The mobile station 300 is functionally illustrated as a mobile station protocol stack (MS / PS) 218 and a mobile station system manager (MS / SM) 220. Network 302 is functionally illustrated as Network Protocol Stack (NW / PS) 222 and Network System Manager (NW / SM) 224. The protocol stack manages the transmission of data, and the system manager controls and supervises the connection between the network and the mobile station. The following scheme is used for sending and receiving uplink (UL) packets. (Steps correspond to the arrow numbers in Figure 3A.) 1U. The MS / PS218 can send three different types of packets to the NW / PS222. Two types of packets in it require an acknowledgment. Packets that require an acknowledgment Packets that contain user data, and packets that have piggyback downlink reporting (DLR) and contain user data b. Packets that do not require an acknowledgment DLR only When sending a packet that requires a packet acknowledgment including, a timer is set in the MS / SM220. If the timer expires before it receives an acknowledgment, the packet is considered lost. 2U. For all UL data packets, a quality sample is sent to the NW / SM224. At the end of the UL packet, a packet stop signal is sent to the NW / SM224 indicating that the last quality sample was sent for that particular packet. After receiving the 3U.UL packet, the UL packet report is sent to the NW / SM224. This report contains the information needed for Trahic. If the 4U.UL packet contains a piggyback DLR, or if the packet is an independent DLR, the DLR quality estimate is extracted and forwarded to the NW / SM224. 5U. If the UL data packet sent requires an acknowledgment, an acknowledgment message is sent from NW / PS222 to MS / PS218. The above message may be an independent type or a piggyback type on the DL mobile station information packet. 6 When an acknowledgment is received on the U.MS / PS218, a packet reception notification signal is sent to the MS / SM220. If an acknowledgment is received before the timer introduced in step 1 above expires, a packet loss message is sent to the MS / SM220. The following schemes are used when sending and receiving DL packets. (Steps correspond to arrow numbers in Figure 3B.) 1D. The MS / PS222 can send three different types of packets to the NW / PS218. Two types of packets in it require an acknowledgment. Packets containing packet user data that requires an acknowledgment, and user data with piggyback acknowledgment / non-acknowledgement (ack / nack) information for previously received UL packets. Included packets b. Packets that do not require an acknowledgment-Packets that include only ack / nack for previously received UL packets A timer is sent when sending a packet that requires an acknowledgment. If the timer expires before it receives an acknowledgment, the packet is considered lost. When sending a 2D.DL data packet, a DL packet report is sent to the NW / SM224. This report contains the information needed for Trahic. When a DL data packet is received by 3D.MS / PS218, a quality sample is extracted for each frame and sent to MS / SM220. At the end of the UL packet, a packet stop signal is sent to the NW / MS220 indicating that the last quality sample was sent for that particular packet. After receiving the 4D.UL packet, the quality estimate is sent to MS / PS218. This estimate is a measure of the quality of all packets sent by DL. A downlink report (DLR) containing 5D.ack / nack messages and quality estimates is sent to the NW / PS222 for each received DL packet containing user data. The DLR can be sent as a stand-alone type or as a piggyback type by UL user data packets. After receiving the DLR on the NW / PS222, the quality estimate is transferred to the NW / SM224. 6D. If the DLR ack / nack information contains an acknowledgment, a packet reception notification signal is sent to the NW / SM224. If the timer introduced in step 1 above receives an acknowledgment before it expires, a packet loss message is sent to the MS / SM224. FIG. 4 will be described. This figure is a block diagram of the packet radio traffic management function of the cellular system of the present invention. The packet radio traffic management function, which is logically located within the NW / SM224, consists of three main blocks. That is, the PRCH manager 402, the resource manager 404, and the PRCH controllers 406a, 406b, 406c, and 406d. There is usually one PRCH manager 402 for each base station in the system. The base station supports one or more cells. The number of PRCH controllers 406a, 406b, 406c and 406d depends on the PRCH required for packet-switched traffic in the cell and the number of resources available. In the case of the embodiment of FIG. 4, there are four PRCHs in the cell. Each PRCH controller controls one PRCH. PRCH manager 402 is called when the user needs to access the PRCH of the cell. When a service request is received through NW / PS222, PRCH manager 402 is called. The PRCH manager 402 is also called when the packet call is discharged from the PRCH due to the traffic jam and the packet call discharge is received from the PRCH controller. Furthermore, the PRCH manager 402 is also called when an internally generated approach queue signal, a PRCH setup allow / deny signal, or a release allow / deny signal is received from the resource manager. Service requests can be received under any of the following situations: 1) When a new user wants to access PRCH to start a packet switching service. 2) The user can use the PRCH of another cell to PR of the cell where the PRCH manager 402 is located. When you want to hand over to CH. 3) When the user wants to make a lost PRCH connection again. 4) If the user wants to update the traffic requirements. See below. When the above traffic event occurs, the service request is forwarded to the PRCH manager. The service request contains information necessary for evaluation by the service request evaluation function 408 of PRCH manager 402. The above information includes: · Request type · Required estimated average user data traffic (for maximum user bit rate of PRCH) P_aveContains individual parameters for each UL and DL. · Required estimated maximum user data traffic (relative to PRCH maximum user bit rate), P_maxContains individual parameters for each UL and DL. -Priority, Pri: This parameter is the interval (0, Pri_max) Can be taken. Priority can be assigned based on the mobile station that initiated the call or is being called, or based on other criteria. The service request is evaluated by the service request evaluation function 408. During service request evaluation, the PRCH manager 402 sends a PRCH entry request for a packet call to the PRCH controllers 406a, 406b, 406c or 406d. The PRCH manager 402 consults with each PRCH controller 406a, 406b, 406c or 406d until entry is allowed or the packet call is unacceptable to any PRCH. If the packet call is not accepted by any of the current PRCHs (if the PRCH ingress request is rejected by all PRCH controllers 406a, 406b, 406c and 406d), the PRCH manager 402 is in the ingress queue. The processing function 420 is used to determine whether to insert the service request into the ingress queue 420. Package calls inserted in the entry queue are temporarily hibernated. That is, information cannot be exchanged between users. If the packet call is not inserted into the ingress queue, a denial of service signal is sent to the user. When a packet call needs to be inserted into the ingress queue, the PRCH manager sends a packet call pause indication signal to notify the user. When a packet call is discharged from the PRCH due to traffic congestion, a packet call discharge display signal is received from the PRCH controller by the PRCH manager 402. The packet call discharge display signal is evaluated by the packet call discharge evaluation function 422. In the packet call discharge evaluation function 422, the PRCH manager 402 sends a PRCH entry request for the exclusion packet call to one of the PRCH controllers 406a, 406b, 406c and 406d. PRCH manager 402 accepts packet calls to any PRCH until entry is allowed. Consult each PRCH controller 406a, 406b, 406c or 406d until the condition is not met. If the packet call is not accepted by any of the current PRCHs, the PRCH manager 402 should use the ingress queue processing function 40 to decouple the exclusion packet call or ingress queue 420 for the egress packet call. Decide if it should be inserted into. When the ejected packet call is inserted into the ingress queue 420, the packet call is temporarily hibernated and a packet call stop indication signal is sent to the user through the NW / PS222. If the ejected packet call is not inserted into the ingress queue, a packet call disconnection display signal is sent to the NW / PS222. The packet call ingress queue signal indicates that the ingress queue 420 needs to be checked. The entry queue signal can be generated by a timer set by the system operator as needed. The packet call incoming queue signal is evaluated by the incoming queue processing function 410. In the entry queue processing function, the PRCH manager 402 sends a PRCH entry request for a packet call of the entry queue with the highest priority to one of the PRCH controllers 406a, 406b, 406c, and 406d. The PRCH manager 402 sends an entry request to each PRCH controller 406a, 406b, 406c or 406d until the entry is allowed or the packet call is unacceptable to any PRCH. If the packet call is accepted in any of the PRCHs, a packet call resume indication signal is sent to the user through the NW / PS222. The PRCH manager 402 also decides to set up a new PRCH or release the current PRCH with the PRCH management function 412, if necessary. For both PRCH setup and PRCH release, the setup request signal or release request signal is the system resource for PRCH. Sent to resource manager 404, which controls the allocation of sources. The resource manager 404 either rejects the request by sending a setup request permission signal or a setup request denial signal to the PRCH manager 402, or by sending a release request permission signal or a release request denial signal to the PRCH manager 402. Do you allow it? Each PRCH controller 406a, 406b, 406c and 406d oversees traffic on one PRCH of the cell. There is one PRCH controller for each PRCH in the cell. Each PRCH controller 406a, 406b, 406c and 406d receives information about the PRCH it controls from the packet reporting NW / PS222. The packet report is evaluated by the PRCH traffic supervisory function 414a, 414b, 414c or 414d for the relevant PRCH. When an entry request is received from the PRCH manager 402, the information contained in the packet report determines whether the PRCH entry control function 416a, 416b, 416c or 416d can accept a new packet call to the PRCH. Used for. The information contained in the packet report also determines whether the PRCH congestion control functions 418a, 418b, 418c or 418d should be used to eject packets that have already been accepted because the PRCH is overloaded. Can be used for. In this case, the packet call discharge display signal is sent to the PRCH manager. The PRCH manager then uses the packet call discharge evaluation function 422 to determine whether the packet call should be temporarily hibernated or disconnected. According to this decision, the user is notified by the packet call suspension display signal or the packet call disconnection display signal. Resource manager 404 controls the allocation of system resources for packet radio channels. PRCH manager 402 sends a PRCH setup / release request to resource manager 404. This allows you to request the setup or release of a new PRCH. The PRCH resource manager 404 continuously monitors the size of the entry queue 420. Entry queue P_qWhenever the total amount of request traffic for all packet calls in exceeds the limit set for the ingress queue, Plim PRCH, a PRCH setup request is sent to a higher level resource manager 404. Be done. P_newIf the PRCH is set to zero, the PRCH manager will always request more resources as soon as the current PRCH is full. As soon as the number of users connected to the PRCH reaches zero, a PRCH release request is sent to the resource manager 404. If permitted, PRCH will be released. The PRCH manager 402, and PRCH controllers 406a, 406b, 406c, and 406d can run within base stations, wireless network controllers, and mobile control nodes such as cellular systems such as the system in Figure 1. The actual execution is done with hardware or software, or a combination of hardware and software that works with one or more processors. Processors and software for performing these types of functions are well known to those of skill in the art.Explaining FIGS. 5A, 5B, 5C and 5D, these figures are the service request evaluation, packet call discharge evaluation, ingress queuing and PRCH management process performed by the PRCH manager 402 according to an embodiment of the present invention. It is a traffic flow chart which shows each step. The PRCH manager 402 receives the input while waiting in step 502 of FIG. 5A. This input may be either a service request, a packet call discharge display, an internally generated ingress queue signal, or a PRCH setup allow or deny signal, or a release allow or deny signal received from the resource manager 404. In step 504, it is determined whether the service request was received from the NW / PS222. If no service request has been received, the process proceeds to step 534 in Figure 5B. However, if the service request has been received, the process proceeds to step 506 and the service request evaluation is started. The service requirement evaluation in step 506 includes the PRCH entry request in steps 508, 510, 512, 514, 516, 518 and 520. The service requirement evaluation is repeated sequentially for each PRCH controller 406a, 406b, 406c and 406d until all PRCH information is exhausted until entry into the PRCH is allowed. In step 508, the PRCH manager 402 sends a PRCH entry request to one of the PRCH controllers 406a, 406b, 406c and 406d. The process then proceeds to step 510 while PRCH Manager 402 is waiting for a response. The PRCH manager 402 periodically checks in step 512 to determine if a response has been received from the PRCH controller 406a, 406b, 406c or 406d. If no response has been received, the process reverts and waits for step 510. However, in step 512, the PRCH If it is determined that a response has already been received from the controller 406a, 406b, 406c or 406d, the PRCH entry request process is terminated and the process proceeds to step 514 to determine if the response is entry permission. Is done. If the response is an entry permit, the service request evaluation process ends at step 520 and the process proceeds to step 522. However, if in step 514 it is determined that the response is not an entry permit, it is an entry denied response and the process proceeds to step 516, where the current response is the last PRCH in which the entry request can be sent. It is determined whether it was sent from the controller. If it was not the last PRCH controller, the process proceeds to step 518 and continues the service requirement evaluation process of step 506 for the next PRCH. The service request evaluation process of step 506 is repeated until an entry permit response is received from the PRCH controllers 406a, 406b, 406c or 406d, or until all PRCH controllers deny entry. When the service requirement evaluation process is complete, the process proceeds to step 522. In step 522, it is determined whether the entry permission response has been received from any PRCH controller. If an entry permit has been received from the PRCH controller, the process proceeds to step 524, where a service permit signal is sent to the user through the NW / PS308. The process then proceeds from step 524 to step 534 in FIG. 5B. However, if it is determined in step 522 that no entry permission has been received from any PRCH controller, the process proceeds to step 528. In step 528, the PRCH manager 402 uses the ingress queue processing function 410 to determine whether the packet call should be inserted into the PRCH ingress queue. If the following criteria are met, a package will be placed in the approach queue 420. A decision is made to insert a call. P_ave(r) + P_q(r) &lt;P_max(r) P_ave(r) is the estimated average data traffic for the user as a function of the service request r. P_q(r) is the request traffic of all packet calls in the ingress queue of service request type r. This is a measure of the current size of the queue. P_max(r) is the maximum permit request traffic of the entry queue 420 as a function of the service request. Different P for different types of service request r_maxCan have Thereby, different service requests can be prioritized. For example, P when requesting PRCH during handoff_max(r) is P when the access request is first requested to PRCH._maxIt may be higher than (r). If at step 528 a decision is made that the packet call should be inserted into the PRCH entry queue, the call identity is inserted into the entry queue 420 and the process proceeds to step 531 where service is performed. The authorization signal is sent to the user through the NW / PS222. The process then proceeds to step 532, where a packet call pause display signal is sent to the user through the NW / PS308. The process then proceeds to step 534 in Figure 5B. However, if in step 528 it is determined that the packet call should not be inserted into the PRCH entry queue 420, the process proceeds to step 530 and a denial of service signal 428 is sent to the user. The process then proceeds to step 534 in Figure 5B. In step 534 of FIG. 5B, it is determined whether or not the packet call discharge display has been received. If the input was not a packet call discharge display, the process proceeds to step 562 in Figure 5C. However, if it is determined in step 534 that the packet call discharge display has not been received, the process proceeds to step 536. In step 536, a PRCH entry request for the ejected packet call is sent from the PRCH manager 402 to the PRCH controller 406a, 406b, 406c or 406d. The entry request process of step 536 includes steps 538, 540, 542, 544, 546, 548 and 550. Step 536 is repeated for each PRCH controller 406a, 406b, 406c or 406d until entry is required for all PRCHs. In step 538, the PRCH manager 402 sends a PRCH entry request to the PRCH controller 406a, 406b, 406c or 406d. The process then proceeds to step 540 while the RRCH manager 402 is waiting for a response. PRCH manager 402 receives a response from PRCH controller 406. A periodic check is performed in step 542 to determine if this is the case. If no response has been received, the process reverts to step 540. However, in step 542, if it is determined that the response has already been received from the PRCH controller that has already sent the entry request, the process proceeds to step 544, where it is determined whether the response is entry permission. .. If the response is an entry permit, the packet call discharge evaluation ends at step 550 and the process proceeds to step 552. However, if in step 544 it is determined that the response is not an entry permit, it is an entry denied response and the process proceeds to step 546, where the entry denied response may be where the current response sends an entry request. It is determined whether it was sent from the last PRCH controller that was created. If it was not the last PRCH controller, the process proceeds to step 566 and iterates through the entry request process of step 536 for the next PRCH. The packet call discharge evaluation of step 536 is repeated until an entry permit response is received from the PRCH controller or until all PRCH controllers 406a, 406b, 406c and 406d reject the entry. When the packet call discharge evaluation process of step 536 is completed, the process proceeds to step 552. In step 552, it is determined whether the entry permission response was received from any PRCH controller during step 536. If the entry permission has been received from the PRCH controller, the process proceeds to step 554, where a packet call update display signal is sent to the user through the NW / PS222. The process proceeds from step 554 to step 562 in FIG. 5C. However, if it is determined in step 552 that no entry permission has been received, the process proceeds to step 556. In step 556, the PRCH manager 402 is the entry queue processor. Use function 410 to determine if a packet call should be inserted into the PRCH entry queue. The same criteria as described in step 528 of Figure 5A are used. If in step 556 a decision is made that the eliminated packet call should be inserted into the PRCH entry queue 420, the process proceeds to step 560 and the packet call pause indication signal is NW / It is sent to the user through PS222. The process then proceeds from step 560 to step 562 in FIG. 5C. However, if in step 556 it is determined that the excluded packet call should not be inserted into the PRCH entry queue, the process proceeds to step 558 and the packet call disconnect display signal is NW / It is sent to the user through PS222. The process then proceeds from step 558 to step 562 in FIG. 5C. In step 562 of FIG. 5C, it is determined whether or not the approach queue signal has been received. If no entry queue has been received from the PRCH controller, the process proceeds to step 584 in Figure 5D. However, if it is determined that an entry queue signal has been received, the process proceeds to step 563. At step 563, a determination is made as to whether any packet call is included in the PRCH entry queue. If it is determined in the PRCH ingress queue 420 that no packet call is included, the process goes into the wait state in step 502 of FIG. 5A, in step 502 the process waits for input. However, if in step 563 it is determined that the PRCH entry queue 420 contains a packet call, the process proceeds to step 564. In step 564, the PRCH entry request for the highest priority packet call in the entry queue 420 is sent from the PRCH manager 402 to the PRCH controller 406a, 406b, 406c or 406d. The entry request process of step 564 is step 56. Includes 6, 568, 570, 574, 576 and 578. Step 564 is repeated for each PRCH controller 406a, 406b, 406c or 406d until entry into the PRCH is allowed or all PRCHs are required to enter. In step 566, the PRCH manager 402 sends a PRCH entry request to the PRCH controller 406a, 406b, 406c or 406d. The process then proceeds to step 568 while PRCH Manager 402 is waiting for a response. The PRCH manager 402 periodically checks in step 570 to determine whether a response has been received from the PRCH controller 406. If no response has been received, the process reverts and waits for step 568. However, in step 570, if it is determined that the response has already been received from the PRCH controller that has already sent the entry request, the process proceeds to step 572, where it is determined whether the response is entry permission. It is said. If the response is an entry permit, step 578 ends the entry request process and the process proceeds to step 586. However, if in step 572 it is determined that the response is not an entry permit, it is an entry denied response and the process proceeds to step 574, where the entry denied response is the last PRCH in which the entry request can be sent. It is determined whether it was sent from the controller. If it was not the last PRCH controller, the process proceeds to step 566 and iterates through the entry request process of step 564 for the next PRCH. The entry request process of step 564 is repeated until an entry permit response is received from the PRCH controllers 406a, 406b, 406c and 406d, or until all PRCH controllers 406a, 406b, 406c and 406d refuse entry. When the entry request process in step 564 is complete, The process proceeds to step 580. At step 580, it is determined whether the entry permit response was received from any PRCH controller during step 564. If an ingress permit response was received from the PRCH controller, the highest priority packet call in the ingress queue 420 is removed from the queue and the process proceeds to step 582, where the packet call resume display signal. Is sent to the user through NW / PS222. The process proceeds from step 582 to step 584 in FIG. 5D. However, if it is determined in step 580 that no entry permission has been received, the process goes directly to step 584 in FIG. 5D. In step 584 of FIG. 5D, it is determined whether the PRCH setup permission has been received from the resource manager 402. If the PRCH setup permission is received from resource manager 402, the process proceeds to step 586, where the PRCH manager creates a new PRCH controller. The process then proceeds to step 592. However, if it is determined in step 584 that the PRCH release permission has not been received, the process proceeds to step 588, where it is determined whether the PRCH release permission has been received from the resource manager 402. If the PRCH setup permission has been received, the process proceeds to step 590, where the PRCH manager cancels the resource allocation from the PRCH controller that sent the release request. The process then proceeds to step 592. However, in step 590, if the PRCH setup permission has not been received, the process goes directly to step 592. At step 592, the request traffic for all packet calls in the ingress queue is evaluated. Then, in step 594, it is determined whether a new PRCH is needed. Entry queue P During 4, it is determined whether or not it was received from any PRCH controller. If an ingress permit response was received from the PRCH controller, the highest priority packet call in the ingress queue 420 is removed from the queue and the process proceeds to step 582, where the packet call resume display signal. Is sent to the user through NW / PS222. The process proceeds from step 582 to step 584 in FIG. 5D. However, if it is determined in step 580 that no entry permission has been received, the process goes directly to step 584 in FIG. 5D. In step 584 of FIG. 5D, it is determined whether the PRCH setup permission has been received from the resource manager 402. If the PRCH setup permission is received from resource manager 402, the process proceeds to step 586, where the PRCH manager creates a new PRCH controller. The process then proceeds to step 592. However, if it is determined in step 584 that the PRCH release permission has not been received, the process proceeds to step 588, where it is determined whether the PRCH release permission has been received from the resource manager 402. If the PRCH setup permission has been received, the process proceeds to step 590, where the PRCH manager cancels the resource allocation from the PRCH controller that sent the release request. The process then proceeds to step 592. However, in step 590, if the PRCH setup permission has not been received, the process goes directly to step 592. At step 592, the request traffic for all packet calls in the ingress queue is evaluated. Then, in step 594, it is determined whether a new PRCH is needed. Entry queue P During 4, it is determined whether or not it was received from any PRCH controller. If an ingress permit response was received from the PRCH controller, the highest priority packet call in the ingress queue 420 is removed from the queue and the process proceeds to step 582, where the packet call resume display signal. Is sent to the user through NW / PS222. The process proceeds from step 582 to step 584 in FIG. 5D. However, if it is determined in step 580 that no entry permission has been received, the process goes directly to step 584 in FIG. 5D. In step 584 of FIG. 5D, it is determined whether the PRCH setup permission has been received from the resource manager 402. If the PRCH setup permission is received from resource manager 402, the process proceeds to step 586, where the PRCH manager creates a new PRCH controller. The process then proceeds to step 592. However, if it is determined in step 584 that the PRCH release permission has not been received, the process proceeds to step 588, where it is determined whether the PRCH release permission has been received from the resource manager 402. If the PRCH setup permission has been received, the process proceeds to step 590, where the PRCH manager cancels the resource allocation from the PRCH controller that sent the release request. The process then proceeds to step 592. However, in step 590, if the PRCH setup permission has not been received, the process goes directly to step 592. At step 592, the request traffic for all packet calls in the ingress queue is evaluated. Then, in step 594, it is determined whether a new PRCH is needed. Entry queue P The packet call with the rank is removed from the queue and the process proceeds to step 582, where a packet call resume indication signal is sent to the user through the NW / PS222. The process proceeds from step 582 to step 584 in FIG. 5D. However, if it is determined in step 580 that no entry permission has been received, the process goes directly to step 584 in FIG. 5D. In step 584 of FIG. 5D, it is determined whether the PRCH setup permission has been received from the resource manager 402. If the PRCH setup permission is received from resource manager 402, the process proceeds to step 586, where the PRCH manager creates a new PRCH controller. The process then proceeds to step 592. However, if it is determined in step 584 that the PRCH release permission has not been received, the process proceeds to step 588, where it is determined whether the PRCH release permission has been received from the resource manager 402. If the PRCH setup permission has been received, the process proceeds to step 590, where the PRCH manager cancels the resource allocation from the PRCH controller that sent the release request. The process then proceeds to step 592. However, in step 590, if the PRCH setup permission has not been received, the process goes directly to step 592. At step 592, the request traffic for all packet calls in the ingress queue is evaluated. Then, in step 594, it is determined whether a new PRCH is needed. Entry queue P The packet call with the rank is removed from the queue and the process proceeds to step 582, where a packet call resume indication signal is sent to the user through the NW / PS222. The process proceeds from step 582 to step 584 in FIG. 5D. However, if it is determined in step 580 that no entry permission has been received, the process goes directly to step 584 in FIG. 5D. In step 584 of FIG. 5D, it is determined whether the PRCH setup permission has been received from the resource manager 402. If the PRCH setup permission is received from resource manager 402, the process proceeds to step 586, where the PRCH manager creates a new PRCH controller. The process then proceeds to step 592. However, if it is determined in step 584 that the PRCH release permission has not been received, the process proceeds to step 588, where it is determined whether the PRCH release permission has been received from the resource manager 402. If the PRCH setup permission has been received, the process proceeds to step 590, where the PRCH manager cancels the resource allocation from the PRCH controller that sent the release request. The process then proceeds to step 592. However, in step 590, if the PRCH setup permission has not been received, the process goes directly to step 592. At step 592, the request traffic for all packet calls in the ingress queue is evaluated. Then, in step 594, it is determined whether a new PRCH is needed. Entry queue P Proceed to. In step 584 of FIG. 5D, it is determined whether the PRCH setup permission has been received from the resource manager 402. If the PRCH setup permission is received from resource manager 402, the process proceeds to step 586, where the PRCH manager creates a new PRCH controller. The process then proceeds to step 592. However, if it is determined in step 584 that the PRCH release permission has not been received, the process proceeds to step 588, where it is determined whether the PRCH release permission has been received from the resource manager 402. If the PRCH setup permission has been received, the process proceeds to step 590, where the PRCH manager cancels the resource allocation from the PRCH controller that sent the release request. The process then proceeds to step 592. However, in step 590, if the PRCH setup permission has not been received, the process goes directly to step 592. At step 592, the request traffic for all packet calls in the ingress queue is evaluated. Then, in step 594, it is determined whether a new PRCH is needed. Entry queue P Proceed to. In step 584 of FIG. 5D, it is determined whether the PRCH setup permission has been received from the resource manager 402. If the PRCH setup permission is received from resource manager 402, the process proceeds to step 586, where the PRCH manager creates a new PRCH controller. The process then proceeds to step 592. However, if it is determined in step 584 that the PRCH release permission has not been received, the process proceeds to step 588, where it is determined whether the PRCH release permission has been received from the resource manager 402. If the PRCH setup permission has been received, the process proceeds to step 590, where the PRCH manager cancels the resource allocation from the PRCH controller that sent the release request. The process then proceeds to step 592. However, in step 590, if the PRCH setup permission has not been received, the process goes directly to step 592. At step 592, the request traffic for all packet calls in the ingress queue is evaluated. Then, in step 594, it is determined whether a new PRCH is needed. Entry queue P Cancel resource allocation from the resource. The process then proceeds to step 592. However, in step 590, if the PRCH setup permission has not been received, the process goes directly to step 592. At step 592, the request traffic for all packet calls in the ingress queue is evaluated. Then, in step 594, it is determined whether a new PRCH is needed. Entry queue P Cancel resource allocation from the resource. The process then proceeds to step 592. However, in step 590, if the PRCH setup permission has not been received, the process goes directly to step 592. At step 592, the request traffic for all packet calls in the ingress queue is evaluated. Then, in step 594, it is determined whether a new PRCH is needed. Entry queue P_qAll request traffic for all packet calls in the limit set for the ingress queue, P_newIf the PRCH is exceeded, a new PRCH is required and the process proceeds to step 596. At step 596, a PRCH setup request is sent to the resource manager 404. The process returns from step 596 to the waiting state of step 502. However, if in step 594 it is determined that a new PRCH is not needed, the process proceeds to step 597. At step 597, the number of packet calls on each PRCH is checked. Next, in step 598, it is determined whether or not there is a PRCH that does not include a packet call. If it is determined that there is no PRCH that does not contain a packet call, the process returns to step 502 in Figure 5A. However, if in step 598 it is determined that there is a PRCH that does not contain one or more packet calls, the process proceeds to step 599, where the PRCH release request is a resource for each PRCH that does not contain a packet call. Sent to manager 404. The process returns from step 599 to the wait state of step 502 of FIG. 5A. Explaining FIGS. 6, 7 and 8, these diagrams show the PRCH controllers 406a, 406b, 406c or 406d for the PRCH traffic supervision, PRCH approach control and PRCH congestion control processes, respectively, according to embodiments of the present invention. It is a flowchart which shows the step to perform. The PRCH controllers 406a, 406b, 406c and 406d continuously supervise data traffic and average packet delay, respectively, and receive incoming requests for PRCH. When the input from the PRCH manager 402 is received and it is activated for the first time, the process is in the waiting state of step 602 of FIG. While waiting in step 602, each PRCH controller 406a, 406b, 406c and 406d needs to make an input in the form of packet information from the NW / PS222, an entry request from the PRCH manager 402, or a PRCH congestion check. Internally indicating that A live operation signal can be received. Upon receiving the above input, the process proceeds to step 604, where it is determined whether a packet report has been received. If it determines that it did not receive the packet report, the process goes directly to step 708 in Figure 7. However, if in step 604 it is determined that a packet report has been received, the process proceeds to step 606, where the PRCH traffic supervisor function 428 includes packet delays for the associated PRCH and load on the PRCH, traffic statistics. To update. The above traffic statistics are updated using the information contained in the packet report. Each packet report contains the following information: 1) Identity of the mobile station user sending to UL or network user sending to DL 2) Packet size 3) Timestamp (indicating when the packet was generated) 4) Using the information contained in the packet type (UL or DL) packet report, the PRCH controller calls each packet P._iCalculate the average packet delay T estimate and the data traffic estimate from. These numbers are used for the approach control process (Figure 7) and the congestion control process (Figure 8). After updating the traffic statistics, the process proceeds to step 708 in Figure 7. FIG. 7 shows the steps performed by the packet radio channel ingress control function of the present invention. At step 708, it is determined whether the input was an entry request. If no entry request has been received, the process goes directly to step 818 in FIG. However, if it is determined in step 708 that the entry request has been received, the process proceeds to step 710 where the entry request is evaluated. If the following criteria are met, the PRCH entry control function 416 permits the PRCH entry request. P_ave+ ΣP_i&lt;P_tol, i U (Pri) P_aveIs the average data traffic required for new packet calls. P_iIs the estimated data traffic from the packet call i. -U (pri) is a packet call with a priority equal to or higher than Pri. In this case, Pri is the priority of the requested packet call. P_tolIs the maximum permissible data traffic on PRCH. From the above equation, the traffic from a packet call with a priority higher than or equal to the priority of the new packet call is the maximum allowable traffic P._tolMust be smaller. Therefore, high-priority packet calls (including all packet calls of any priority) have the maximum allowed traffic P._tolPRCH can be used even if the value is exceeded. In this case, the congestion control function (Fig. 8) ejects low priority packet calls, resulting in all traffic being the maximum allowed traffic P._tolIt becomes as follows. Maximum permissible traffic P_tolIs the maximum permissible delay T due to the relationship of the following equation_tolRelated to.<img file="JP4195086B2_D0001.tif" />However, f is a function having the same sign as its argument, and T is an estimated value of the average packet delay calculated by the PRCH traffic supervision function. The PRCH controller traffic supervision function continuously monitors T, so P_tolIs continuously updated according to the above formula. P_tolIs the maximum allowable delay T_tolCorresponds to the traffic level that becomes. Next, in step 712, it is determined whether the entry to the PRCH is permitted or denied. If entry is allowed, the process proceeds to step 714, where entry permission is sent to PRCH Manager 402. If the entry is not allowed, the process proceeds to step 716, where the denied entry is sent to PRCH Manager 402. After the PRCH entry control function 416 sends an entry permit or deny in step 714 or 716, respectively, the process proceeds to step 818 of FIG. In step 818, the PRCH congestion control function 418 checks for congestion on the PRCH. If it is determined that there is no congestion on the PRCH, the process returns to the waiting state in step 602 of FIG. However, if it is determined in step 820 that congestion is occurring, the process proceeds to step 822, where a decision is made as to which one or more packet calls should be ejected. The average packet delay T is checked to determine congestion. Delay alert level T set by the system operator_conIs used to know when a congestion situation, i.e., when one or more packet calls must be excluded from the PRCH in order to recover the permissible average packet delay. T &lt;T_conIf it is determined that there is no congestion on the PRCH, the process returns to the waiting state in step 602 of FIG. However, in step 820, T T_conIf so, the process proceeds to step 822, where it is determined which one or more packet calls should be eliminated. The judgment of step 822 is made by the following method. 1) Starting from a packet call with a low priority, the following checks are performed for all packet calls. P_i P_max(i) However, P_iIs the estimated traffic for packet call i, P_max(i) is the maximum required data traffic. If the above equation is not satisfied, the packet call i is ejected from the PRCH. 2) If the above equation is satisfied for all packet calls, one or more of the lowest priority packet calls are ejected. Therefore, a packet call with an estimated traffic above the maximum number given by the service request is ejected first. If the estimated traffic of all packet calls is below that limit, one or more of the lowest priority packet calls are ejected. When a packet call is ejected from the PRCH due to traffic congestion, a packet call indication (restart request) indicating which packet call should be ejected from the PRCH is sent to the PRCH manager 402 in step 824. After the packet call discharge indication is sent, the PRCH controller process returns to the wait state in step 602 of Figure 6. FIG. 9 will be described. This figure is a flowchart showing the process steps performed by the resource manager function according to the embodiment of the present invention. The resource manager process is waiting in step 902 when it receives input from PRCH manager 402. The above input may be a PRCH setup request or a PRCH release request. Upon receiving the input, the process proceeds to step 904. At step 904, a determination is made as to whether the input is a PRCH setup request. If the input is a PRCH setup request, the process proceeds to step 906. At step 906, the PRCH setup request is evaluated. The resource manager evaluates the setup request by determining if there are suitable resources in the cell that can set up a new PRCH. The process proceeds from step 906 to step 910. At step 910, a determination is made as to whether the setup request evaluation indicates that a new PRCH can be set up. new If it determines that the PRCH can be set up, the process proceeds to step 916, where the PRCH setup permission is sent to the PRCH manager 402. Then, in step 918, resource manager 404 allocates resources for the new PRCH. The process returns from step 918 to the wait state of step 902. However, if in step 910 it is determined that the setup request evaluation indicates that a new PRCH cannot be set up, the process proceeds to step 914 where the PRCH setup denial is made by the PRCH manager. Sent to 402. The process returns from step 914 to the wait state of step 902. If it is determined in step 904 that the input is not a PRCH setup request, then that input is a PRCH release request. In this case, the process proceeds from step 904 to step 912. The resource manager evaluates the PRCH release request by determining whether it can accept the release of the PRCH from a system-wide perspective. For example, the traffic load on the PRCH of the surrounding cells can be taken into account. The process proceeds from step 912 to step 920. At step 920, a determination is made as to whether the PRCH release request evaluation indicates that the PRCH can be released. If it determines that the PRCH can be released, the process proceeds to step 922, where the PRCH release permission is sent to the PRCH manager 402. Then, in step 926, the resource manager releases the PRCH. The process returns to the wait state of step 902. However, if at step 920 it is determined that the PRCH release request evaluation indicates that the PRCH cannot be released, the process proceeds to step 924, where the PRCH release refusal is performed by the PRCH manager 402. Will be sent to. The process goes from step 924 to step 902 Return. As can be understood from the above description, the system operator can use the methods and systems of the invention to manage packets for prioritized users on the PRCH of one or more of the cellular communication systems. Can be used. The system operator can set the maximum average time delay for PRCH. Users can be prioritized according to the level of service they have subscribed to, or users can be automatically assigned priorities according to the type of call they are currently making, or they can choose for themselves. You can also. The higher the priority, the higher the system usage fee. By paying a higher fee, a user can have a higher priority than other users who have a lower priority when they are in a traffic jam and trying to access the system. By making packet traffic decisions based on the estimated data traffic required by the packet call and the packet call priority, the system operator ensures that the PRCH user does not suffer an unacceptable PRCH delay. Can be done. From the above description, the operation and structure of the present invention will be clear. The invention illustrated and described herein is a particular embodiment in which various modifications and modifications can be made without departing from the spirit and scope of the invention as defined in the claims below. .. The higher the value, the higher the system usage fee. By paying a higher fee, a user can have a higher priority than other users who have a lower priority when they are in a traffic jam and trying to access the system. By making packet traffic decisions based on the estimated data traffic required by the packet call and the packet call priority, the system operator ensures that the PRCH user does not suffer an unacceptable PRCH delay. Can be done. From the above description, the operation and structure of the present invention will be clear. The invention illustrated and described herein is a particular embodiment in which various modifications and modifications can be made without departing from the spirit and scope of the invention as defined in the claims below. .. The higher the value, the higher the system usage fee. By paying a higher fee, a user can have a higher priority than other users who have a lower priority when they are in a traffic jam and trying to access the system. By making packet traffic decisions based on the estimated data traffic required by the packet call and the packet call priority, the system operator ensures that the PRCH user does not suffer an unacceptable PRCH delay. Can be done. From the above description, the operation and structure of the present invention will be clear. The invention illustrated and described herein is a particular embodiment in which various modifications and modifications can be made without departing from the spirit and scope of the invention as defined in the claims below. ..