This invention relates generally to communication within a mobile telecommunications system, and more particularly this invention relates to communication between a base station (Node B) and a radio network controller (RNC) in order to enhance call control and resource management.
The telecommunications industry is in the process of developing a new generation of flexible and affordable communications that includes high-speed access while also supporting broadband services. Many features of the third generation mobile telecommunications system have already been established, but many other features have yet to be perfected.
One of the most important systems within the third generation of mobile communications is the Universal Mobile Telecommunications System (UMTS) which will deliver voice, data, multimedia, and wideband information to stationary as well as mobile customers. UMTS is designed to accommodate increased system capacity and data capability (UMTS is synonymous with WCDMA or wideband code division multiple access). Efficient use of the electromagnetic spectrum is vital in UMTS. It is known that spectrum efficiency can be attained using frequency division duplex (FDD) or with time division duplex (TDD) schemes, and these schemes can be employed in the context of UMTS and WCDMA.
As can be seen in FIG. 1, the UMTS architecture consists of user equipment 102 (UE), the UMTS Terrestrial Radio Access Network 104 (UTRAN), and the Core Network 126 (CN). The air interface between the UTRAN and the UE is called Uu, and the interface between the UTRAN and the Core Network is called Iu.
The UTRAN consists of a set of Radio Network Subsystems 128 (RNS), each of which has geographic coverage of a number of cells 110 (C), as can be seen in FIG. 1. The interface between the subsystems is called lur.
Each Radio Network Subsystem 128 (RNS) includes a Radio Network Controller 112 (RNC) and at least one Node B 114, each Node B having geographic coverage of at least one cell 110. As can be seen from FIG. 1, the interface between an RNC 112 and a Node B 114 is called Iub, and the Iub is hard-wired rather than being an air interface. For any Node B 114 there is only one RNC 112. A Node B 114 is responsible for radio transmission and reception to and from the UE 102 (Node B antennas can typically be seen atop towers or preferably at less visible locations). The RNC 112 has overall control of the logical resources of each Node B 114 within the RNS 128, and the RNC 112 is also responsible for handover decisions which entail switching a call from one cell to another or between radio channels in the same cell.
The FDD method uses separate frequency bands for uplink and downlink transmissions over the Uu interface (i.e. over the air interface between UTRAN 104 and the User Equipment 102). In contrast, the TDD method allocates different time slots (compared to different frequencies) for these uplink and downlink communications. Generally, TDD is very flexible regarding the allocation of time slots, and therefore is very well-suited to applications that are asymmetric with respect to uplink and downlink data volume (e.g. web browsing entails a much higher downlink than uplink data volume). Combining FDD and TDD modes provides maximum efficiency and flexibility for third generation networks.
In order for the RNC 112 to provide effective call control and resource management to each Node B 114, it must receive information from the Node B 114 about Node B""s time-dependent resources. The problem of obtaining appropriate resource information from Node B 114 has not been adequately addressed by the related art, especially with regard to TDD (as compared to FDD), and therefore the ability of an RNC 112 to provide call control and resource management has suffered.
A particularly important piece of information for the RNC 112 to receive is information about the currently available processing capacity at Node B 114. Processing capacity is to be distinguished from air interface capacity. Air interface capacity is limited by factors such as noise and interference, whereas processing capacity refers to the capacity of the Node B 114 itself to process calls. When the RNC 112 does not accurately know the processing capacity of Node B 114 that is currently available, it is very difficult or impossible for the RNC 112 to accurately allocate call traffic to the Node B 114.
It is important to understand that the processing capacity at Node B 114 varies from time to time even if the number of user equipments 102 (UE) remains the same. This variation is due to the fact that the required processing per UE 102 depends upon how the logical resources of Node B resources are used for each of the particular UEs. The required processing for a particular user can depend upon what kind of coding a user has, how many multicodes are involved, how the users are divided in different time slots (TDD only), the number of users involved in a handover (FDD only), how the user""s data stream is divided if there are multiple channel elements, the quality of service assigned to a call, et cetera. Thus, it is not adequate for the RNC 112 to simply know the number of UE""s that a Node B 114 is handling, because each Node B 114 may require a different type of implementation. Rather, the RNC 112 should ideally receive from the Node B 114, over the Iub interface, a simple and accurate measure of the Node B""s available processing capacity without any need for specifying the particular implementations that Node B 114 is providing to each UE 102. In TDD, no adequate solution to this problem has been developed. In FDD, the problem has been partially addressed by using the spreading factor of Node B 114 as an indicator of processing capacity, and reporting this spreading factor over the Iub.
With WCDMA, information bits are spread over an artificially broadened bandwidth. This task is accomplished by multiplying the bits, using a pseudorandom bit stream. The bits in the pseudorandom bit stream are referred to as chips, so the stream is known as a chipping, or spreading, code. This spreading increases the bit-rate of the signal, and increases the amount of bandwidth occupied by the signal, by a ratio known as the spreading factor, namely, the ratio of the chip rate to the original information rate.
The spreading factor can be used with limited success to indicate processing capacity in FDD, but the spreading factor is almost completely insufficient in TDD, because the TDD spreading factor is substantially constant in the downlink to the UE 102, and furthermore the TDD spreading factor range is very narrow as compared with the FDD spreading factor range (e.g. 1-16 in TDD as compared with 4-512 in FDD). In particular cases, the spreading factor might vary between two values in TDD, but such a rough measurement would not allow the RNC 112 to meaningfully model the processing capacity of Node B 114, and thus the processing capacity parameter is currently undefined in TDD. Even in FDD, using the spreading factor is not an ideal solution, because the FDD spreading factor becomes imprecise at the start of the 4-512 scale (e.g. the spreading factor between 4 and 8 corresponds to a very large difference in processing capacity).
Information about the use of the spreading factor as an indicator of FDD processing capacity can be found, for example, in publications of the 3rd Generation Partnership Project (3GPP). In particular, 3GPP TS 25.433 xe2x80x9cUTRAN Iub Interface NBAP Signalingxe2x80x9d (Version 3.3.0, September 2000) describes how the RNC 112 audits resources at the Node B 114, which then reports processing capacity by way of an audit response (section 8.2.7). The 3GPP TS 25.433 publication also describes how the Node B 114 may report to the RNC 112 at the Node B""s own initiative by way of a resource status indication (section 8.2.15). These are the only two instances in which the prior art suggests reporting processing capacity from the Node B 114 to the RNC 112, and this fact unnecessarily limits the accuracy of the processing capacity of Node B 114, as perceived by the RNC 112. The 3GPP TS 25.433 publication also describes various exchanges of signal between the RNC 112 and the Node B 114 that do not involve processing capacity (see section 8.2.17 on radio link setup, section 8.3.1 on radio link addition, and section 8.3.6 on radio link deletion). Publication 3GPP TS 25.433 furthermore describes that the spreading factor is the parameter which is used to tell the RNC 112 how much capacity is being consumed by the Node B 114 (see especially sections 9.2.2.3 and 9.2.2.6).
The presently disclosed method is based upon a system structure similar or identical to the prior art Universal Mobile Telecommunications System (UMTS) architecture shown in FIG. 1, but the present invention solves the problem of how to report the amount of processing capacity that is currently available at a Node B 114 to an RNC 112. This invention may occur in the context of UMTS, utilizing wideband code division multiple access (WCDMA) as well as UMTS terrestrial radio access (UTRA).
The presently disclosed method, which enables the RNC 112 to enhance call control and resource management, begins with generation of a processing capacity inquiry signal. Then, a processing capacity report signal is generated and sent from the Node B 114 to the RNC 112, in response to the processing capacity inquiry signal. The processing capacity report signal has a magnitude indicative of available bit rate (ABR) associated with the base station.
Thus, the present invention utilizes the available bit rate (ABR) as a measure of processing capacity, whereas the prior art only utilizes the spreading factor for this purpose. As described previously, the spreading factor is generally not a good measure of processing capacity, especially when using TDD.
Using the available bit rate (ABR) as the TDD capacity parameter is the optimal solution to this problem. The ABR addresses the fundamental gap in the capacity modelling of Node B 114, inasmuch as a capacity parameter is currently undefined for TDD.
According to the present invention, processing capacity information is not sent from Node B 114 to the RNC 112 on a dynamic basis, but rather is sent at discrete times, and the RNC 112 uses this discrete processing capacity information to model the actual continuous processing capacity at Node B 114. When the RNC 112 inputs the ABR into its capacity model for Node B 114, the RNC 112 obtains a vastly more accurate characterization of Node B""s processing capacity (in TDD) than would be obtained by inputting the Node B""s spreading factor into the capacity model of Node B 114. Available bit rate (ABR) can provide for transport of traffic at the bit rate available at a given time, and therefore ABR is well-suited as a processing capacity parameter in TDD.
Even in FDD, the ABR is an excellent alternative (or supplement) to the spreading factor, for the purpose of communicating processing capacity from the Node B 114 to the RNC 112. The ABR provides better granularity than the spreading factor parameter, especially at the low end of spreading factor values where a unit change in spreading factor means a difference in spreading factor on the order of 100%. Furthermore, this ABR parameter is appropriate for FDD because it can be used independently of whichever radio transmission technology resources are being used by the system, and independent of hardware.
The present method can be used if Node B 114 utilizes an FDD system or a TDD system, or both. Likewise, the ABR may include an uplink ABR or a downlink ABR, or both. Furthermore, in FDD, the ABR can be used as the sole parameter indicative of processing capacity, or the ABR can be used in conjunction with the spreading factor to indicate processing capacity.
The capacity inquiry signal can be provided either by the RNC 112 or by a component of Node B 114 itself, as in the prior art. However, the present invention discloses additional ways by which the capacity inquiry signal can be provided by the RNC 112, and thus the present invention remedies the prior art situation in which the accuracy of the Node B""s processing capacity, as perceived by the RNC 112, is unnecessarily limited. These additional ways of providing the capacity inquiry signal can be employed regardless of whether the processing capacity parameter is the spreading factor or is the available bit rate.
At a Node B 114 utilizing TDD, different bit rates occur when more codes are allocated to a user or when more time slots are allocated to the user. The Node B 114 processing resource is thus likely to be utilized at a higher rate when one time slot is allocated to multiple users as opposed to being allocated to a single user, and when one user has been allocated several time slots as opposed to a single time slot. Whatever the allocations may be, the present invention ensures that the processing capacity parameter is reported by the Node B 114 to the RNC 112 independently of the particular hardware and software implementations that each UE 102 is using.