CN1312885C - Flow control between transmitter and receiver entities in a communication system - Google Patents

Abstract

In a particular wireless communication system, a common channel MAC-c layer (500), a dedicated channel MAC-d layer (510), and a radio link controller are located in a radio network control, respectively. The MAC-c layer (500) is provided with a flow control mechanism (530) for managing a plurality of MAC-d entity data traffic flows directed to the MAC-c buffer (525) such that the buffer fill level and the MAC-c entity (500) can be maintained at a desired level and each of all corresponding data flows can fairly share the data rate between the MAC-c (500) and MAC-d (510) entities. The flow control operates to share MAC-c buffer space with each MAC-d entity (510) that provides an active data flow in a sequential, round-robin fashion or based on flow activity (greedy fashion). Buffer space is assigned or allocated on the basis of an upper MAC-c fill level limit, and certain embodiments are also based on an active MAC-d buffer fill level.

Description

Flow control between transmitter and receiver entities in a communication system

Cross References to Related Applications

This nonprovisional patent application claims the benefit of priority to co-pending U.S. Provisional Patent Application Serial No. 60/184,975 (Attorney's Office No. 34646-00458USPL), filed February 25, 2000, and at All disclosures thereof are hereby incorporated by reference. Commonly incorporated Serial Nos. 60/185,005 (Attorney's Office No. 34646-00459USPL) and 60/185,003 (Attorney's Office No. 34646-00460USPL) filed February 25, 2000 The entire contents of the pending US Provisional Patent Application are hereby incorporated by reference.

This nonprovisional patent application is similar in subject matter to serial numbers 09/698785 (Attorney's Office No. 34646-00459USPT) and 09/698672 (Attorney's Office No. 34646-00460USPT) filed on the same date as above U.S. nonprovisional patent application related. The entire contents of these two US non-provisional patent applications are also incorporated herein by reference.

Background of the invention

invention technical field

The present invention relates generally to the field of communication systems, and more particularly, by way of (but not limited to), to handling potential buffer overflows caused by users overloading a communication system.

Related technical description

Accessing and using wireless networks has become increasingly important and popular for business, socialization and entertainment purposes. Today, wireless network users rely on the network for voice and data communications. Moreover, the ever-increasing number of users requires an ever-increasing variety of services and capabilities, and wider bandwidth for activities such as Internet browsing. In order to address and meet the requirements of new services and wider bandwidth, the wireless communication industry needs to continuously improve the number of services and the throughput of its wireless network. Providing additional services and wider bandwidth requires expanding and improving the infrastructure, which is very expensive and labor-intensive. Moreover, users will eventually demand high-bandwidth data streams to support functions such as real-time audio-video downloads and direct audio-video communication between two or more people. Therefore, in the future, it may be necessary and/or more cost-effective to introduce next-generation wireless systems without attempting to upgrade existing systems.

To do this, the wireless communications industry intends to continue to improve the capabilities of the technologies it relies on and to deploy next-generation systems for use by its users. Protocols for next-generation standards designed to meet the evolving requirements of wireless users are being standardized by the Third Generation Partnership Project (3GPP). This set of protocols is collectively known as the Universal Mobile Telecommunications System (UMTS).

Referring now to FIG. 1 , an exemplary wireless communication system that advantageously employs the present invention is illustrated generally at 100 . In the UMTS network 100, the network 100 includes a core network 120 and a UMTS terrestrial radio access network (UTRAN) 130. UTRAN 130 consists at least in part of a plurality of Radio Network Controllers (RNCs) 140, each of which is coupled to one or more adjacent Node Bs 150. Each Node B 150 is responsible for a designated geographic cell, and the controlling RNC 140 is responsible for routing user and signaling data between the Node B 150 and the core network 120. All RNCs 140 may be directly or indirectly coupled to each other. A general overview of UTRAN 130 is given in the technical specification TS 25.401 V2.0.0 (1999-09) of the third generation cooperation project organization 3GPP, and its entire content is hereby incorporated as a reference. Also included in the UMTS network 100 is a plurality of user equipments (UEs) 110 . A UE may include, for example, a mobile station, a mobile terminal, a laptop/personal digital assistant (PDA) with a wireless link, and the like.

In the exemplary second layer of the UMTS framework structure, a set of Radio Access Bearers (RABs) is provided so that radio resources and services can be used by user applications. For each mobile station, there may be one or several RABs, and the data flow from the RABs to the various Radio Link Control (RLC) entities is given in segmented form. The RLC entity buffers the received data segments and maps RABs to logical channels. A medium access control (MAC) entity receives data transmitted in logical channels, and further maps the data in logical channels into a set of transport channels. Transport channels are in turn mapped into a single physical transport channel with a specific aggregate bandwidth allocated to it by the associated network. A MAC entity connected to a dedicated transport channel is called MAC-d, and a MAC entity connected to a common transport channel is called MAC-c. Preferably, each mobile station in UMTS has one MAC-d entity, and each cell has one MAC-c entity.

In each transmission time interval of the system, the MAC entity must decide how much data to transmit in each transmission channel connected to it. In making this decision, it is necessary to share the entire available bandwidth between the logical channels receiving information from different RABs and their respective RLCs coupled to different mobile stations. In the past, sharing resources among multiple input data streams was known as Generalized Processor Sharing (GPS). However, it has now been recognized that there are difficulties in directly utilizing GPS for bandwidth allocation within a UMTS network. More specifically, GPS assumes that data can be sent in infinitely small data blocks on the MAC physical logical channel. And this is not possible in UMTS. Accordingly, in order to share all available bandwidth between different logical channels receiving information from different RABs, it is necessary to provide other alternative designs for managing or controlling data flow within UMTS.

Summary of the invention

The methods, systems and designs of the present invention can remedy the deficiencies identified above, as well as other deficiencies associated with existing solutions. More specifically, a usable design is proposed such that data streams from multiple different MAC-d entities respectively associated with different logical channels can be shared fairly between a MAC-d entity and a common MAC-c entity data rate, but also maintain the MAC-c buffer at or near the desired fill level. This can be achieved by operating by sharing between the active data streams of the MAC-d entities according to sequential, round-robin or flow activity principles, and with available information about the buffer fill levels of the individual RLC/MAC-d entities Free space of the MAC-c buffer.

In summary, the present invention provides a method of flow control in a wireless communication system comprising the steps of: providing a receiver entity and one or more transmitter entities, when a given transmitter entity receives a credit from a receiver entity, Given transmitter entity to send. Also included in the method is the step of determining whether to grant credits to respective transmitter entities.

Specifically, the present invention provides a method for providing flow control in a wireless communication system, which includes the following steps: providing a receiver entity with a receiver buffer; providing a plurality of transmitter entities, each of which transmits The transmitter entity includes a transmitter buffer for storing packets before transmission to the receiver entity; the receiver entity determines the total available bandwidth for the packet stream entering the receiver entity; each transmitter entity is allocated A portion of the total available bandwidth; credits are issued by each receiver entity to each transmitter entity, where each credit authorizes the transmission of packets, and the number of credits issued to a given transmitter entity corresponds to a backlog counter of a transmitter buffer in the given transmitter entity; and adjusting that portion of the total available bandwidth allocated to each transmitter entity by the number of credits issued to each transmitter entity.

In a preferred embodiment of the invention, the method comprises sending data packets from each transmitter entity to the receiver entity in a sequential or cyclic manner. The receiver entity contains a common medium access control entity (MAC-c) with receiver buffer, and each transmitter entity contains a dedicated medium access control entity (MAC-d), each transmitter entity communicates with another Buffer related. In a useful embodiment, the determining step is based (at least in part) on the fill level of the receiver buffer, but also on the fill level of one or more buffers associated with the respective transmitter entity. In another useful embodiment, the determination is based (at least in part) on the fill level of a receiver buffer, but not on the fill level of any buffer associated with the transmitter entity. Another embodiment of the invention includes determining whether the first active transmitter entity has a current credit amount less than the buffer fill level of the associated buffer, and if so, setting the first active transmitter entity's current credit amount to Increment by one and decrease the amount of available credit by one. This determination step is repeated for each active transmitter entity until the available number of credits is exhausted, or all active transmitter entities have current credits corresponding to their respective buffer fill levels. Also included in this embodiment are the steps of recording the last active transmitter to receive credits and, on the next occasion to distribute credits, making another active transmitter entity following the last active transmitter in sequence become the recipient. Credits for the first active transmitter entity.

The above and other features of the invention are subsequently explained in detail with reference to the illustrative examples given in the accompanying drawings. It will be appreciated by those skilled in the art that the described embodiments are provided for purposes of illustration and understanding and that various equivalent embodiments are contemplated herein.

Brief description of the drawings

A more complete understanding of the methods, systems and designs of the present invention can be obtained by reference to the ensuing detailed description, taken in conjunction with the accompanying drawings, which include:

Figure 1 illustrates an exemplary wireless communication system that advantageously employs the present invention;

Figure 2 illustrates the protocol model of an exemplary next generation system that advantageously employs the present invention;

3 illustrates an overview of an exemplary Layer 2 architecture of an exemplary Next Generation System according to the present invention;

4 illustrates, in flow chart form, an exemplary method for allocating bandwidth resources for data flows between entities in the exemplary layer-2 architecture of FIG. 3;

FIG. 5 illustrates flow control interconnected between transmitting and receiving entities, incorporating embodiments of the present invention;

Figure 6 shows a part of the embodiment of Figure 5 in more detail;

Figure 7 illustrates the buffer of the embodiment of Figure 5;

Figure 8 illustrates the operation of the flow control of the embodiment shown in Figure 5;

Fig. 9 provides the buffer of the second embodiment of the present invention;

Fig. 10 is a schematic block diagram illustrating the operation of the second embodiment;

Fig. 11 is a schematic diagram describing the relationship between the buffer filling level and the credit amount for the second embodiment;

12 and 13 are schematic block diagrams for explaining a third embodiment of the present invention.

Detailed description of the drawings

In the following description, in order to provide a thorough understanding of the present invention, specific details are set forth for purposes of explanation (rather than limitation) such as specific circuits, logical modules (eg, software, hardware, firmware, certain components in between). combination, etc.), technology, etc. It will be apparent, however, to one of ordinary skill in the art that the present invention may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known methods, devices, logic code (eg, hardware, software, firmware, etc.), etc. are omitted so as not to obscure the description of the invention with unnecessary detail.

The preferred embodiment of the present invention and its advantages are best understood by referring to the accompanying drawings 1-13, like numerals being used to indicate like and corresponding parts of the various drawings. The preferred embodiment of the present invention is described from the perspective of UMTS. However, it should be understood that the principles of the present invention are also applicable to other wireless communication standards (or systems), especially those based on packet communication.

Referring now to FIG. 2 , a protocol model for an exemplary next generation system that advantageously employs the present invention is illustrated generally at 200 . In protocol model 200 (e.g. for Forward Access Channel (FACH) transport channel type), "Uu" denotes the interface between UTRAN 130 and UE 110, and "Iub" denotes the interface between RNC 140 and Node B 150 (where "Node B " is, for example, a general term for a base transceiver station (BTS)) between interfaces. User and signaling data can be carried between the RNC 140 and the UE 110 by using a radio access bearer (RAB), which will be described below with reference to FIG. 3 . Typically, one or more RABs are allocated to UE 110, and each RAB can carry one user or signaling data flow. RABs are mapped to respective logical channels. At the medium access control (MAC) layer, a set of logical channels is in turn mapped to transport channels, which include two types: "common" transport channels shared by different UEs 110, and "dedicated" transport channels allocated to a single UE 110 Transport channel (hence the terms "MAC-c" and "MAC-d"). One type of common channel is FACH. The basic feature of FACH is that one or more fixed-size packets can be sent within each transmission time interval (eg, 10, 20, 40 or 80 ms). At the physical layer, several transport channels (eg FACH) are in turn mapped to a Secondary Common Control Physical Channel (S-CCPCH) for transmission over the air interface between Node B 150 and UE 110.

When the UE 110 registers with the RNC 140 via the Node B 150, the RNC 140 is (at least initially) regarded as the serving and controlling RNC 140 for the UE 110. (Then within the UMTS network 100, the Serving RNC 140 may be different from the Controlling RNC 140, but it is not particularly relevant here whether this is the case.) The RNC 140 controls the air interface radio resources and terminates layer 3 intelligent operations ( For example, the radio resource control (RRC) protocol), so that the relevant data of the UE 110 is directly routed from and to the core network 120.

It should be appreciated that the MAC-c entity within RNC 140 delivers MAC-c packet data units (PDUs) to UE 110's peers using the FACH Frame Protocol (FACH FP) entity traffic between RNC 140 and Node B 150. and other MAC-c entities. The FACH FP entity adds header information to the MAC-c PDU to form a FACH FP PDU that is transmitted to the Node B 150 over an AAL2 (or other transport mechanism) connection. The interworking function of the Node B 150 makes FACH frames received by the FACH FP entity available at the PHY entity.

In the exemplary aspect of the scheme illustrated in Figure 2, an important task of the MAC-c entity is to arrange packets (MAC PDUs) for transmission over the air interface. If all packets received by a MAC-c entity have the same priority (and thus the same size), scheduling becomes as simple as queuing the received packets and serving them on a first-come, first-accepted basis (e.g. First in first out (FIFO)) principle to send. However UMTS defines a framework in which different Quality of Service (QoS) can be assigned to different RABs. Packets corresponding to RABs assigned high QoS should be sent over the air interface with high priority, while packets corresponding to RABs assigned low QoS should be sent over the air interface with lower priority. On the basis of RAB parameters, a MAC entity (eg MAC-c or MAC-d) determines this priority.

UMTS handles the priority issue by providing a set of queues per FACH within the controlling RNC 140. Queues can be associated with various priority levels. An algorithm is implemented that is defined to select packets from a queue in such a way that packets of a higher priority queue are (on average) faster to process than packets of a lower priority queue. The nature of this algorithm is complicated by the fact that FACHs transmitted in the same physical channel are not mutually independent. More specifically, a set of transport format combinations (TFCs) are defined for each S-CCPCH, where each TFC includes the transmission time interval, the size of the packet, and the overall transmission size of each FACH (representing the number of packets in the transmission) . According to the UMTS protocol, the algorithm should select a TFC for FACH that matches a TFC present in the set of TFCs.

Packets received in the controlling RNC 140 are preferably placed in a queue (for transmission in the FACH) corresponding to the priority level attached to the packet and the size of the packet. In Node B 150 or other corresponding node in UTRAN 130, FACH is mapped to S-CCPCH. In an alternative preferred solution, the packets transmitted in the FACH are associated with a dedicated control channel (DCCH) or a dedicated traffic channel (DTCH). It should preferably be noted that each FACH is designed to carry packets of only one size. However, this is not required, and the size of a packet that a given FACH can carry may vary from one transmission time interval to another.

As alluded to above, the UE 110 can communicate with the core network 120 of the UMTS system 100 via a separate serving and controlling (or drift) RNC 140 within the UTRAN 130 (e.g. When the area moves to a new area covered by the control/drift RNC 140) (not specifically shown). Signaling and user data packets destined for the UE 110 from the core network 120 are received within the MAC-d entity of the serving RNC 140, and these data packets are "mapped" to logical channels, i.e., for example dedicated control channels (DCCH) and dedicated Traffic Channel (DTCH). The MAC-d entity constructs a MAC Service Data Unit (SDU) comprising: a payload part containing logical channel data and, inter alia, a MAC header containing a logical channel identifier. The MAC-d entity passes the MAC SDU to the FACH FP entity. This FACH FP entity in turn adds the FACH FP header to each MAC SDU, wherein the FACH FP header includes the priority level assigned to the MACS DU by the RRC entity. As the UE 110 enters the coverage area of the drift RNC 140, the RRC obtains the available priority levels, and an identification of one or more acceptable packet sizes for each priority level.

The FACH FP grouping is sent to the peer FACH FP entity in the drift RNC 140 via an AAL2 (or other) connection. The peer FACH FP entity unpacks the MAC-d SDU and identifies the priority contained in the FRAME FP header. The SDU and associated priority are passed to the MAC-c entity within the controlling RNC 140 . The MAC-c layer is responsible for arranging the transmission of SDUs in the FACH. More specifically, each SDU is placed in a queue corresponding to its priority and size. For example, if there are 16 priorities, each FACH will have 16 queue sets, and the number of queues in each of the 16 queue sets depends on the number of packet sizes accepted by the relevant priority. As mentioned above, an SDU is selected from the queue for a given FACH according to some predetermined algorithm (eg to meet the TFC requirements of the physical channel).

The schemes subsequently described with reference to Figures 3 and 4 relate to data transmission within a telecommunications network, and in particular (although not necessarily) to data transmission within UMTS.

As mentioned above, 3GPP is currently standardizing a new set of protocols for mobile telecommunication systems. This set of protocols is collectively referred to as UMTS. Referring to FIG. 3 , there is illustrated generally at 300 a schematic diagram of an exemplary layer 2 architecture of an exemplary next generation system in accordance with the present invention. In particular, by way of example only, the exemplary layer 2 architecture 300 illustrates a simplified UMTS layer 2 protocol structure that is included between a mobile station (e.g., a mobile phone), or more broadly, a UE 110 and a UMTS network. In communication between radio network controllers (RNC) 140 of 100. RNC 140 is similar to a base station controller (BSC) in an existing GSM mobile telecommunication network, and it communicates with mobile stations via Node B 150.

Included in the layer 2 structure of the exemplary layer 2 architecture 300 is a set of radio access bearers (RABs) 305 that make available radio resources (and services) to user applications. For each mobile station, there may be one or several RABs 305. Data streams emanating from the RAB 305 (eg, given in segmented form) are passed to various Radio Link Control (RLC) entities 310, which, among other things, serve to buffer received data segments. Each RAB 305 has only one RLC entity 310. At the RLC layer, RABs 305 are mapped into individual logical channels 315. A medium access control (MAC) entity 320 receives data transmitted within logical channels 315 and further maps the data from logical channels 315 to a set of transport channels 325 . Transport channel 325 is ultimately mapped to a single physical transport channel 330, which occupies all of the bandwidth allocated to it by the network (eg, less than 2 Mbit/s). Depending on whether the physical channel is dedicated to one mobile station, or shared among multiple mobile stations, it is referred to as a "dedicated physical channel" or a "common channel". A MAC entity connected to a dedicated physical channel is called MAC-d; each mobile station preferably has one MAC-d entity. A MAC entity connected to a common channel is called MAC-c; each cell preferably has one MAC-c entity.

The bandwidth of the transport channel 325 is not directly limited by the capabilities of the physical layer 330, but is configured by a radio resource controller (RRC) entity 335 using a transport format (TF). For each transport channel 325, the RRC entity 335 defines the size of one or several transport blocks (TB). The size of each transport block directly corresponds to the allowed MAC protocol data unit (PDU), and tells the MAC entity what packet size it can use to deliver data to the physical layer. In addition to the block size, the RRC entity 335 informs the MAC entity 320 of the transport block set (TBS) size, which is the total number of bits that the MAC entity can send to the physical layer in a single transmission time interval (TTI). The size of the TB and the size of the TBS, together with some other information related to the allowed physical layer configuration, constitute the TF. An example of TF is (TB = 80 bits, TBS = 160 bits), which means that the MAC entity 320 can send two 80-bit packets within a single TTI. Thus, such a TF can be written as TF=(80, 160). The RRC entity 335 also notifies the MAC entity of all possible TFs for a given transport channel. This combination of TFs is called Transport Format Combination (TFC). An example of TFC is {TF1=(80, 80), TF2=(80, 160)}. In this example, the MAC entity can choose to send one or two PDUs within one TTI in the particular transport channel in question; in both cases the PDUs have a size of 80 bits.

In each TTI, the MAC entity 320 has to determine how much data to transmit in each transport channel 325 connected to it. These transport channels 325 are not independent of each other and are then multiplexed at the physical layer 330 to form a single physical channel 330 (as discussed above). The RRC entity 335 has to ensure that the total transmission capacity in all transport channels 325 does not exceed the transmission capacity of the underlying physical channel 330 . This can be done by assigning the MAC entity 320 a Transport Format Combination Set (TFCS) containing the transport format combinations allowed for all transport channels.

By way of example, consider the MAC entity 320, which has two transmission channels 325, which are further multiplexed into a single physical channel 330, which has a transmission capacity of 160 bits per transmission time interval (it should be understood that in practice In this capacity should be greater than 160). The RRC entity 335 can determine to allocate three transport formats TF1 = (80, 0), TF2 = (80, 80) and TF3 = (80, 160) for the two transport channels 325 . However, it is obvious that the MAC entity 320 cannot choose to use TF3 to transmit in the two transmission channels 325 at the same time, because this will result in the need to transmit 320 bits in the physical channel 330, and the physical channel is only capable of transmitting 160 bits. The RRC entity 335 has to limit the total transmission rate by not allowing all combinations of TFs. Such an instance could be TFCS[{(80,0),(80,0)},{(80,0),(80,80)},{(80,0),(80,160)} as follows , {(80, 80), (80, 0)}, {(80, 80), (80, 80)}, {(80, 160), (80, 0)}], where the transmission channel "1" The transport format of is given by the first element of each element pair, and the transport format of transport channel "2" is given by the second element. Since the MAC entity 320 can only select one of these allowed transport format combinations from the set of transport format combinations, it is not possible to exceed the capabilities of the physical channel 330 .

Elements of a TFCS are indicated by a Transport Format Combination Indicator (TFCI), which is an index of the corresponding TFC. For example, in the above example, there are 6 different TFCs, which means that the TFCI can take any value from 1 to 6. TFCI=2 corresponds to the second TFC, namely {(80, 0), (80, 80)}, which means that no information is transmitted in the first transport channel, and a single 80 grouping of bits.

Of course it is necessary to share all available bandwidth among logical channels 315 . The decision to distribute the bandwidth to the different transport channels is made for each transmission time interval by the MAC entity 320 by selecting the appropriate TFCI. This bandwidth sharing can be achieved in several ways, such as assigning absolute priority to flows that are considered more important than others. This would be the easiest way to implement, but it could result in a very unfair distribution of bandwidth. In particular, streams with lower priority may not be allowed to transmit for an extended period of time. If the flow control mechanism for lower priority streams works like this, it will result in poor performance. A typical example of this flow control mechanism can be found in the Transmission Control Protocol (TCP) protocol currently used by the Internet. In prior art, eg Internet Protocol (IP) and Asynchronous Transfer Mode (ATM) networks, provisions have been made for allocating resources in a single output channel to multiple input streams. However, the algorithms used in such systems for sharing resources cannot be directly used for UMTS, where multiple input streams are transmitted on separate logical output channels.

Sharing resources among multiple input data streams is called general purpose processor sharing (GPS). When GPS is used in a system with only a single output channel, GPS is called Weighted Fair Queuing (WFQ), and is described by A.K. Parekh, R.G. Gallager in IEEE/ACMTransaction on Networking (June 1993, Vol. 1 , No.3, pp. 344-357), entitled "A Generalized Processor Sharing Approachto Flow Control in Integrated Services Networks: The Single Node Case (A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks : single node case)" is described in the article. In short, GPS involves calculating GPS weights for each incoming stream based on stream-specific parameters. The weights computed for all input streams are added together, and all available output bandwidth is allocated among the input streams according to the proportion of each stream's weight to the total weight. GPS can be used by the MAC entity within UMTS to determine the weight of each incoming stream (by the RRC entity) on the basis of the specific RAB parameters assigned by the network to the corresponding RAB. In particular, the RAB parameter may be equal to Quality of Service (QoS), or the guaranteed rate allocated to a user for a particular network traffic.

Continuing to refer to the solutions described in Figures 3 and 4, it can be recognized that it is difficult to directly utilize GPS for bandwidth allocation within a UMTS network because GPS assumes that infinitely small data blocks can be transmitted in the MAC physical logical channel. This is not possible within UMTS since UMTS relies on Transport Format Combination Sets (TFCS) as the basic mechanism for defining how much data can be sent within each TTI. If GPS is to be employed within UMTS, it is necessary to select (from the TFCS) the TFC that best matches the bandwidth allocated by GPS to the incoming stream. The result of this scheme is that the actual amount of data sent for the input stream in a given frame is either below or above the optimal rate. In the former case, a backlog of unsent data needs to be constructed for the input stream.

The solution described here with reference to Figures 3 and 4 aims at overcoming, or at least alleviating, the disadvantages mentioned in the preceding paragraphs. This and other objects may be achieved, at least in part, by maintaining a backlog counter for tracking the backlog of unsent data for a given input flow of the MAC entity. This backlog needs to be taken into account when determining the appropriate TFC for subsequent frames of the input stream. According to a first aspect of the solution, there is provided a method for allocating transmission resources in a Media Access Control (MAC) entity of a Universal Mobile Telecommunications System (UMTS) node, the method comprising the following steps for each frame of an outgoing data stream: Each input flow of the MAC entity calculates a fair share of the available output bandwidth of the MAC entity; based on the calculated shared bandwidth, a transport format combination (TFC) is selected for the input flow from the TFC set (TFCS), where the TFC includes the allocation to each the transport format of the input streams; and for each input stream, if the allocated TF results in a data transfer rate less than the determined fair allocation, the difference is added to the backlog counter for that input stream, where when the output data stream When selecting a TFC for subsequent frames, the value of the backlog counter should be considered. Embodiments of the present invention allow the TFC selection process for subsequent frames to take into account the backlog of any existing input streams. The intent of this is to tune the selected TFCs to reduce the backlog. This backlog may exist due to the fact that TFCS can only provide a limited number of data transfer possibilities. Nodes adopting the method of this solution may include mobile stations (such as mobile phones and communicator-type devices) (or more generally, UEs) and radio network controllers (RNCs).

The incoming streams of the MAC entities are preferably provided by respective Radio Link Control (RLC) entities. Furthermore, each RLC entity preferably provides a buffer for the associated data stream. Furthermore, the step of computing a resource fair share for the incoming stream is preferably performed by a Radio Resource Control (RRC) entity. Furthermore, preferably, the step of calculating a fair share of resources for an input stream also includes the step of determining the ratio of the weight assigned to the stream to the sum of the weights assigned to all input streams. Fair share is then determined by multiplying the total output bandwidth by the determined ratio. Moreover, it is preferable to utilize the general processor sharing (GPS) mechanism in this step. The weight of a data flow may be defined by one or more Radio Access Bearer (RAB) parameters assigned by the UMTS network to a RAB associated with each MAC input flow. Furthermore, preferably in case the backlog counter for a given input flow has a positive value, the method further comprises the step of adding the value of the backlog counter to the fair share computed for that flow, and adding Based on the sum, select TFC.

In a particular embodiment of the scheme described with reference to Figures 3 and 4, wherein for a given input flow, if the allocated TF would result in a data transmission rate higher than the determined fair allocation, then the backlog counter Subtract the difference from . According to a second aspect of the solution, there is provided a Universal Mobile Telecommunications System (UMTS) node comprising: a Media Access Control (MAC) entity for receiving a plurality of input data streams; computing a fair share of output bandwidth available to a MAC entity for an input flow, and first processor means for selecting a Transport Format Combination (TFC) from a set of TFCs (TFCS) on the basis of the bandwidth share computed for the input flow, Among them, the TFC includes the transmission format assigned to each input stream; if the data transmission rate is lower than the determined fair share, it is used to compare the data transmission rate of the stream obtained by the selected TFC with the determined fair share. The difference of is added to the second processor means of the backlog counter associated with each input stream, wherein the first processor means is designed to take into account the value of the backlog counter when selecting the TFC for the subsequent frame of the output data stream . The first and second processor means are preferably provided by a Radio Resource Control (RRC) entity.

As described herein with reference to FIG. 3 , the simplified UMTS layer 2 includes a radio resource control (RRC) entity, a medium access control (MAC) entity for each mobile station, and each radio access bearer (RAB) radio link control (RLC) entity. The MAC entity is responsible for arranging output data packets, while the RLC entity provides buffers for the respective input streams. The RRC entity can set an upper limit on the maximum amount of data that can be transmitted in each stream by assigning each MAC a set of allowed Transport Format Combinations (TFCs) (referred to as a TFC set or TFCS), but each MAC must pass The best available Transport Format Combination (TFC) is selected from the TFCS, independently determining how much data is transmitted from each stream.

Referring now to FIG. 4 , there is illustrated generally at 400 an exemplary method (in flowchart form) for allocating bandwidth resources for data flows between entities located in the exemplary second layer architecture of FIG. 3 . Flowchart 400 is, for example, a flowchart of a method for allocating bandwidth resources for an incoming flow of a MAC entity in layer 2 of FIG. 3 . Generally, the exemplary method according to flowchart 400 may follow the following steps. First, the RLC receives the input stream and buffers the data (step 405). Buffer fill level information is passed to the MAC entity (step 410). After the buffer fill level information is communicated, a fair MAC bandwidth share for each input flow is calculated (step 415). The calculated fair share for each flow is then adjusted by adding the contents of the relevant backlog counter to the respective calculated fair share (step 420). Once the calculated fair share is adjusted, the TFC that best matches the adjusted fair share is selected from the set of TFCs (step 425). Then, according to the selected TFC, the RLC is instructed to deliver the packet to the MAC entity (step 430). The MAC entity may also arrange packets according to the selected TFC (step 435). After packet scheduling is complete, the traffic channel may be transmitted on the physical channel (step 440). Once the packet traffic is delivered, the backlog counter should be updated (step 445). The process continues (via arrow 450) when the RLC receives a new incoming stream and buffers the data (step 405).

Furthermore, certain embodiments of the present scheme operate in such a way that on a per-transmission time interval (TTI) basis, the MAC entity utilizes a general purpose processor sharing (GPS) scheme to calculate the optimal distribution of available bandwidth (see above reference article by A.K. Parekh et al.). And use its own backlog counter to track how far each flow is from optimal bandwidth allocation. A standard GPS weight is used to distribute the available bandwidth for the flow, and the weight can be calculated by RRC using the RAB parameter.

This method may first compute the GPS distribution for the input stream, and add the current respective backlogs to the GPS values. This operation is performed every 10ms TTI and results in a fair transfer rate for each flow. However, this rate may not be optimal since it may occur that there is not enough data in all buffers to be sent. For best throughput and fairness, the fair GPS distribution is reduced such that the current buffer fill level or the maximum allowed rate of any logical channel is not exceeded. A two-step evaluation process is then performed.

First, a set of fair rates computed for all input streams is sequentially compared to possible Transport Format Combinations (TFCs), with each TFC being scored based on how close it is to the best outgoing rate. In practice, this can be achieved simply by counting how many fair configurations a TFC fails to send (a given TFC has a score of zero if it is able to send all packets at a fair rate), and then only considering TFC with the lowest score. The closest match is chosen and used to determine the number of packets to send out of each queue. A bonus score is assigned based on how many additional bits a TFC with the same score can still send (this can be further weighted by the quality of service assessment in order to ensure that the excess capacity goes to the bearer with the highest quality class). The final selection is based on two levels of scoring: the TFC with the lowest score is chosen. If there are several TFCs with the same score, the TFC with the highest bonus score is selected. This ensures that the rate of each TTI can be maximized. Fairness can be achieved by checking that if the selected TFC cannot provide at least its determined fair rate for all flows, the missing bits are added to the backlog counter for the corresponding flow and repeated in the next TTI Make a selection. The backlog is set to zero if there is no information to send for any stream. Given this algorithm, it is possible to provide similar bandwidth (and delay bounds under certain assumptions) as GPS. However it still maintains fairness and maintains independence between all streams. Since the algorithm takes advantage of the fact that the MAC layer can simultaneously transmit in several transport channels, it is computationally simpler than the weighted fair queuing algorithm. This can lead to optimal or near optimal utilization of the radio interface in the UMTS radio link. The following pseudocode is an overview of an exemplary algorithm for implementing the scheme described above with reference to Figures 3 and 4:

/*

*GPS based TFC selection. Scheduling packets by optimizing throughput

* while still maintaining that fairness (i.e. guaranteed rate)

int sched_gpsO{

double weight, weight_sum;

double score, bonus_score;

double min_score=HUGE_NUMBER;

double max_bonus_score=0;

int maxrate;

int i,j;

int tfc, tfci, qf, rate, trch;

int tfc_to_use;

double backlog[MAX_TRCH];

double gps_req[MAX_TRCH];

double gps_req_comp[MAX_TRCH];

/* First calculate the weighted sum of all active queues */

weight_sum=0;

for(trch=0; trch<MAX_TRCH; trch++){

If(queue_fill_state[trch]＞0){

weight_sum.+=weight_vector[trch];

}

}

/* Then use GPS to calculate a fair distribution of available bandwidth.

* If there is not enough data in the buffer or if scheduled

* rate is higher than the maximum rate for a given logical channel, then modify

*Change the GPS schedule, reduce the rate

*/

int gps_rate = 0;

for(trch=0; trch<MAX_TRCH; trch++){

If(queue_fill_state[trch]=0){

backlog[trch]=0;

}

∥ Here we calculate what we should be on each channel via GPS

∥ how many bits to send

gps_req[trch]=0;

gps_req_comp[trch]=0;

If(queue_fill_state[trch)＞0){

weight = weight_vector[trch];

  gps_req[trch]＝weight/weight_sum*maxrate+

backlog[trch];

gps_req_comp[trch]=gps_req[trch];

If(gps_req_comp[trch]＞queue_fill_state[trch]){

gps_req_comp[trch]=queue_fill_state[trch];

}

If(gps_req_comp[trch]＞trch_max_rate[trch]){

gps_rsq_comp[trch}=trch_max_rate[trch];

}

}

}

/* Now we have our ground rules for selecting TFC.

* Modified GPS results by calculating all available TFC distances

* How far to rate them. If there are several can send the whole

The TFC of the first GPS result (or equivalently close) is chosen

* TFC that maximizes throughput for the highest QoS class. Notice

*TFCI is assumed to be in ascending order of relative bandwidth usage

*/

for(tfci=o; tfci<MAX_TPCI; tfci++){

rate=score=bonus-score=0;

for(trch=0; trch<MAX_TRCH; trch+-+){

int tbs = tfcs[trch][tfci][0];

int tbss = tfcs[trch][tfci][1];

rate+=tbss;

If(tbss<gps_req_comp[trch]){

Score+=gps_req_comp[trch]-tbss;

}else{

If(tbss<=queue_fill_state(trch]){

Bonus_score+＝QoS_vector[trch]*(tbss-gps_req_comp[trch]);

}

}

}

if(score<min_score){

tfc_to_use=tfci;

min_score = tfcScore;

max_bonus_score=bonus_score;

}

If(score==min_score&&bonus_score＞max-bonus-score){

tfc_to_use=tfci;

min_score=score;

  max_bonus_score = bonus_score;

}

}

/* Now we have selected TFC to use. update the backlog

* and output the appropriate TFCI

*/

for(trch=0; trch<MAX_TRCH; trch++){

tbss = tfcs[trch][tficToUse][1];

If(tbss<queue_fill_state){

If(gps_req[trch]-gps_req_comp[trch]){

backlog[trch]=gpsReq[trch]-tbss;

If(backlog[trch]<0)backlog[trch]=0;

}else{

backlog[trchG1]=0;

}

}

return tfc_to_use;

}

Referring now to FIG. 5, a portion of the second layer architecture described in FIG. 3 is shown. More specifically, the MAC entity 320 in which Figure 3 is given contains within it a MAC-c entity 500 as described above, which is connected to a dedicated MAC-d entity 510 also as described above. FIG. 5 also shows an RLC entity 515 which receives data in segmented format from each RAB and maps the data into corresponding logical channels 315 . Each RLC 515 is equipped with a buffer 520 for buffering received data segments including PDUs. The MAC-d entity 510 serves a single mobile station (not shown), and the data transmitted by the MAC-d entity is delivered via the transport channel 325 to the dedicated physical channel DPCH.

Referring again to FIG. 5 , there is shown a common MAC-c entity 500 provided with a buffer 525 and connected to receive data, in particular PDUs, from the MAC-d entity 510 as well as other MAC-d entities not shown. According to the present invention, it is desirable to provide a flow control mechanism 530 between each private MAC-d entity and the common MAC-c entity 500 . By selectively managing the flow of traffic from a MAC-d entity to the buffer 525 of the MAC-c entity 500, flow control 530 enables multiple different MAC-d entities each in active data flow mode to share the MAC-c buffer 525 free space available. Flow control is designed to provide each active MAC-d entity with a "fair share" of the excess data flow capacity given by the free space in the MAC-d buffer, which ensures that all active MAC-d entities are allocated a reasonable opportunities to use this buffer capacity to increase their respective data flow rates. In this way, the available common delivery channel data rate is shared among all active dedicated logical channels. Flow control is also designed to maintain the fill level of the MAC-c physical buffer at or close to the optimum fill level.

Referring to FIG. 5 again, it can be seen that the data transmitted by the MAC-c entity 500 is sent to the transport channel FACH.

Referring to FIG. 6, there is shown a flow control 530 coupled to manage data flow from each RLC to a MAC-c PDU buffer 525 of a plurality of RLCs 515, each RLC 515 being coupled to a different mobile station or other user equipment 1 -n. In a useful embodiment of the invention, flow control operates according to a "round robin" or some other principle, i.e. each MAC-d entity connected to a given MAC-c entity can be sequential or sequential, or according to flow activity ( greedy way) to pass data to it. In this embodiment, credits are assigned to individual MAC-d entities according to criteria described in further detail below. After receiving the credit, the MAC-d entity is authorized to send a packet data unit to the MAC-c buffer 525 .

Referring to Figure 7, there is shown a MAC-c buffer 525 available for dedicated channels associated with MAC-d entities. The MAC-c buffer has an optimum level Q _copt , which is related to the latency and throughput requirements of the buffer operation. Flow Control 530 tries to maintain this level using feedback information received from the MAC-d entity. Flow control is also responsible for keeping the MAC-c buffer as low as possible so that the delays associated with using a common channel can be evenly distributed among the different MAC-d users. If at a particular time, the level of buffer 525 is _Qc , then the available buffer space _Qcdiff is equal to _Qcopt - _Qc . Flow control 530 operates to share this space among MAC-d users by allocating the same amount of credits to users if they have PDUs available for transmission. Flow control calculates credits for each MAC-d entity based on the buffer fill levels of the MAC-d and MAC-c. More specifically, flow control establishes credit allocation criteria related to the buffer level Q _copt and the levels Q _cmax and Q _cun also given in FIG. 7 . These guidelines are as follows:

(1) If the MAC-c buffer fill level Q _c is less than Q _cun , assign unlimited or unlimited credits to the MAC-d entity.

(2) If the current MAC-c buffer fill level Q _c is greater than Q _cun but less than Q _copt , the difference (Q _copt −Q _cun ) is distributed among the active MAC-d entities.

(3) If the current MAC-c buffer fill level Q _c is greater than Q _copt , no new credits will be granted other than the initial credits. If credits were previously set to "unlimited", they are cleared to zero by sending "zero" credits to the appropriate MAC-d entity.

We expect algorithms to be easily generated to operate flow control 530 to distribute or assign credits according to the above criteria. Helpfully, when a particular user becomes inactive, the algorithm continues to allocate remaining credits to the remaining users. It can be understood that an active user is a dedicated channel service connected to a common channel and has data in its RLC-d buffer. An active user becomes a passive user when its RLC-d buffer becomes empty. Algorithms may provide for a fair sharing of all available bandwidth among active users with available bandwidth. The algorithm also minimizes packet delay, which is especially important for users operating with small packets when other users have large-sized packets.

In an overload situation, the flow control algorithm separates the different data and only increases the RLC buffer fill level of the dedicated channel with the highest rate. The RLC buffer fill level for other channels whose rate remains the same will not be increased. In this way, the algorithm supports the operation of the channel switching function, which is able to identify overloaded channels and switch the overloaded channels to dedicated transmission channels. The algorithm stores the user identification at its termination computation, and when the flow control algorithm is used again, continues from the next user identification.

FIG. 8 illustrates the process of transferring data from the buffer of the dedicated channel to the buffer 525 of the MAC-c entity 510, and the process of allocating or distributing credits for each dedicated channel in a sequential or round-robin manner. More specifically, step 600 is given in FIG. 8, respectively numbered 1-18, which describes the relationship between credits of several dedicated channels respectively incorporated into radio link control RLC-1, RLC-2 and RLC-3 Sequential allocation and corresponding data transfer. Each step in steps 1-12 displays a sign indicating the step number, and also gives certain counting information in parentheses. As indicated by item 620 in Figure 8, the count information includes the MAC-c buffer fill level _Qc , corresponding to a dedicated channel buffer fill level _Qd , and the available credit count at the end of the step. By way of illustration, item 620 gives a note for step 2.

Referring again to FIG. 8, its entry 610 is given to indicate that at the beginning of the process shown in FIG. 8, the available data space Q _cdiff in the MAC-c buffer 525 is equal to 12 credits. As mentioned above, assigning credits to a dedicated channel enables the channel to deliver a certain amount of data (eg, one PDU) to the MAC-c buffer. Thus, at step 1 of FIG. 8, the channel of RLC-1 receives a credit. As a result, the available space of the MAC-c buffer is reduced from 12 to 11, and one PDU corresponding to one credit can be sent from the RLC-1 buffer to the MAC-c buffer. Accordingly, the data content of the RLC-1 buffer with an initial value equal to 2 credits can be reduced to a _Qd count of one.

Referring again to Fig. 8, it can be seen that in subsequent step 2, the RLC-2 channel has received a credit, the available _Q count is reduced to 10, and the buffer RLC-2 count Q _is also Reduced from initial count of 4 to 3. The process of step 3 is similar and related to the RLC-3 buffer. However, step 4 illustrates the round robin process of the embodiment of the present invention, where given the next credit is assigned to the RLC-1 channel again. After receiving the credit, the Q _d count value counted by RLC-1 reaches zero, indicating that the channel has no more available PDUs. In this way, according to step 5, for the RLC-2 channel, as indicated in step 7, the next credit is allocated to the RLC-2 channel. This is according to criterion (2) above. Similarly, according to step 9, the Q _d count value of the RLC-2 channel becomes zero, wherein all subsequent credits are allocated to the RLC-3 channel.

In a second embodiment of the invention, flow control 530 again operates according to a credit algorithm based on round robin or flow activity (greedy approach). Referring to Figure 9, there is shown the MAC-c buffer 525 again used by the dedicated channel. The Qoptimal ( _Qcopt ) dashed line in Figure 9 represents the optimum level with respect to undesired buffer overflow, delay variance, and good throughput. Flow control tries to maintain the buffer at Q by means of current buffer queue fill level (Q _c ) and queue maximum (Q _cmax ) threshold values, and by means of information belonging to active users connected to the MAC-c buffer. _Copt level. As mentioned above, an active user is a dedicated channel traffic connected to a common channel and has data in its RLC-d buffer. An active user becomes a passive user when its RLC-d buffer becomes empty.

In order to construct the flow control algorithm of the second embodiment, the credit amount C is calculated according to the following formula:

$f=\min (1,\frac{{(Q_{c\max }-Q_c)}^2}{{Q_{\mathrm{copt}}}^2})$ Equation (1)

Q _copt ＝T _h +R _cmax (2*T _d )equation (2)

$C=f\frac{Q_{\mathrm{copt}}}{N_{\mathrm{mac}.d}}$ Equation (3)

In the above equation, T _h is the operation delay/processing delay, T _d is the transmission delay, and R _cmax is the maximum rate of the FACH transmission channel of this buffer. N _mac-d is the number of active MAC-d entities, and Q _cmax is the buffer high level. The default value of Q _cmax may be 2×Q _copt .

Flow control has associated preprocessing functions that can be triggered by incoming PDUs, timers, or both. The preprocessor checks the user's credit status, the value of _Qc and the number of active users in the buffer. If the credit is greater than zero or other predetermined value, the flow control algorithm is not started.

Referring to Fig. 10, there is shown the general operation of the flow control of the second embodiment of the present invention. Initially at 0 milliseconds, the credit (C) is equal to 2, and the user at dedicated MAC-d has three PDUs to deliver to MAC-c. If there are two available credits, then two PDUs can be delivered, after which the credit (C) becomes zero. In this way, the flow control algorithm is started, and according to the calculation of formula (3), four credits as shown in FIG. 10 are provided. The flow control process is no longer performed until after 20 milliseconds, the value of the credit amount becomes zero again, or other predetermined values.

Fig. 11 shows the relationship between Q _c and the credit amount according to formulas (1) to (3). The dashed line shows the adjustments made to limit C to the maximum value.

Referring to Figure 12, therein is shown a modification which may usefully be employed in any of the above-described embodiments of the invention.

Packets from the RLC-d buffers are first passed through the MAC-d to the appropriate buffers of the MAC-c and then passed to the FACH transport channel. As indicated by path 700 of FIG. 12, MAC-d packets are sent together with data frames that also contain RLC-d buffer fill level information. MAC-c uses control frames containing credits to control user data flow from MAC-d. Credits are the number of packets a user can transmit, represented by path 710 in FIG. 12 .

When the MAC-d user sends its last packet to MAC-c, as shown by path 720, the packet is delivered with a data frame indicating "buffer empty". Correspondingly, the MAC-c entity will set the credit amount of the MAC-d user as an initial value. Thus, after receiving the last packet from the user, as shown by path 730, MAC-c will send a control frame message with the initial credit parameter to the MAC-d user. However, sending such a message after receiving the last packet from the user increases the transmission delay of the next arriving packet and also increases the number of control frame messages, as shown in Figure 12.

In order to keep the delay of the user's next packet low after its buffer temporarily becomes empty, and at the same time reduce the number of control messages, an early initial credit grant design is required. Accordingly, when the flow control algorithm shows that the calculated credit is equal to or greater than the number of packets remaining in a particular RLC-d buffer, the flow control algorithm in the MAC-c should add the initial credit to the calculated credit In the forehead. In this way, the initial credit should be sent to MAC-d in advance, and it is not necessary to send any new credit parameters to it after the last packet has been received. This is illustrated in Figure 13, where the additional control frames of path 730 in Figure 12 are omitted by utilizing the control frames of path 740 (credits and initial credits).

While preferred embodiments of the methods, systems and designs of the present invention have been described in the description of the drawings and in the foregoing detailed description, it is to be understood that the invention is not limited to the disclosed embodiments, but can be embodied in many forms redesigns, modifications and substitutions without departing from the spirit and scope of the invention as set forth and defined by the following claims.

Claims (5)

1. method that in wireless communication system, is used to provide current control, comprising following steps:

Receiver with receiver buffer is provided;

A plurality of transmitters are provided, and wherein each transmitter comprises a transmitter buffer, is used in transmitted in packets stores packets before the receiver;

Be identified for entering total available bandwidth of the stream of packets of this receiver by receiver;

Based on the weights of distributing to each transmitter and all weights of distributing to all transmitters and comparison, an and part of distributing this total available bandwidth for each transmitter;

By this receiver line of credit is issued each transmitter, each line of credit mandate transmission packets wherein, and the quantity of line of credit of issuing a given transmitter is corresponding to the overstocked counter of transmitter buffer in this given transmitter; And

Adjust that part of this total available bandwidth of distributing to each transmitter by the line of credit quantity of issuing each transmitter, wherein the content of the overstocked counter of transmitter buffer is added to the portions of bandwidth of distributing to this given transmitter in given transmitter.

2. also comprise the steps: according to the process of claim 1 wherein

In response to receiving a line of credit, and send grouping to this receiver from each transmitter from this receiver.

3. according to the process of claim 1 wherein that this receiver comprises media access control MAC-c module, and each transmitter comprises the MAC-d module, and this wireless communication system comprises Universal Mobile Telecommunications System UMTS.

4. distribute the step of the part of this total available bandwidth also to comprise according to the process of claim 1 wherein to each transmitter: to distribute a part based on the service quality that each transmitter is guaranteed.

5. according to the method for claim 2, the step of wherein issuing line of credit comprises: issue the enough line of credits of each transmitter, overflow to prevent the transmitter buffer in each transmitter.

Images