Patent Application
20060176845
1. Field of the Invention
The present invention relates to managing network resources. More particularly, the present invention relates to managing network resources using user equipment to inform a network controller that resources are ready to be released.
2. Description of Related Art
As wireless communications become more prevalent, high speed data transmission between network resources is being addressed for various wireless network protocols and other standards. For example, a high-speed data channel having a high speed downlink packet access (HSDPA) allows user data transmission to occur in a downlink. A high peak rate in the channels may reach approximately 14.4 Mbit/sec, in a downlink direction. This peak rate may be higher than the support capability of current user equipment dedicated channels. Further, the trend of further defining high speed data rate channels seems to be continuing. For example, a new channel, referred to as high speed uplink packet access (HSUPA), may be provided. As HSDPA supports high peak data rates in the downlink channel, HSUPA and other newly defined channels should support high peak data rates in the uplink channel.
Channels having high peak data rates may seek to share air capacity between users or user equipment. User equipment accessing these channels also desire dedicated resources from UMTS terrestrial radio access network elements, including a radio network controller and base stations, from appropriate interfaces and from the base station. These resources may be reserved for the user equipment and applicable radio bearers until the call is considered finished and any resource release procedures have been performed. The resource release procedures ensure that proper utilization of the network resources is maintained.
Conventional control and release of resources include triggering the release of the resource in the radio network controller (RNC). This action may be an internal implementation within the RNC. The trigger uses an inactivity timer, or counter, in the RNC to detect inactive use of the assigned resources and channels, and to release any resources in those cases where the uplink and downlink channels are not being used. Timers, however, may not be suitable for high bit rate channels due to difficulty defining the optimal timer length and the burstness nature of packet-switched traffic.
Further, timers and counters may cause additional delays in releasing resources, which may lead to inefficient use of the resources in high bit rate channels. Moreover, when the utilization rate of the network is high, all additional delays to release unused resources may block the acceptance of new resource requests from new radio bearers that are assigned for other user equipments. This inefficiency may especially be true for air interface, base station and radio network controller resources.
A conventional approach to save resources on a high bit rate channel may assign normal data channel resources to an inactive radio access bearer. The assignment may occur when traffic on one or more channels drop under a certain level. The radio network controller, however, is forced to establish a new resource for the applicable user equipment, which results in an additional signal load on the network or system.
An example of the preferred embodiments of the present invention includes a method for managing network resources. The method may include receiving an indication of a termination of a data transmission in an uplink from a user equipment. The method also may include determining a status for a downlink to the user equipment. The method also includes releasing a resource in response to the indication and the traffic status.
An embodiment of the invention includes a method for releasing a resource in a network. The method includes receiving a field in a packet from a controller. The method also includes determining the field indicates a termination of a channel from the controller to user equipment. The method also includes detecting a traffic status in a downlink within the channel. The method also includes starting a resource release procedure according to the termination and traffic status.
An embodiment of the invention includes a system for releasing resources in a network. The system includes receiving means for receiving a field in a packet data from a controller. The system also includes determining means for determining the field indicates a termination of a channel from the controller to user equipment. The system also includes detecting means for detecting a traffic status in a downlink within the channel. The system also includes starting means for starting a resource release procedure according to the termination and traffic status.
An embodiment of the invention includes a controller having means for receiving an indication of a termination of a data transmission in an uplink from user equipment. The controller also includes determining means for determining a traffic status for a downlink to the user equipment. The controller also includes releasing means for releasing a resource in response to the indication and traffic status.
An embodiment of the invention includes a system for controlling resource in a network. The system includes a controller to manage a resource in a network. The system also includes user equipment to exchange data with the controller over an uplink and a downlink. The resource is assigned to the user equipment. The system also includes an indicator to indicate a termination in the uplink. The controller releases the resource from the user equipment upon receipt of the indicator and a determination of a traffic status in the downlink.
An embodiment of the invention includes a method for releasing a resource. The method includes detecting an error in user equipment using a channel to exchange data with a controller. A resource is assigned to the user equipment. The method also includes generating a packet at the user equipment to indicate a termination of the channel based on the error. The method also includes sending the packet to the controller. The method also includes releasing the resource from the user equipment.
For proper understanding of the invention, reference should be made to the accompanying drawings, wherein:
Reference will now be made to the preferred embodiments of the present invention. Examples of the preferred embodiments are illustrated by the accompanying drawings.
User equipment 104 may establish channel 120 with controller 102. Channel 120 may include downlink channel path 120 and uplink channel path 124. Controller 102 may establish other channels with other user equipment, such as user equipment 106. Channel 120 may perform at a high peak data rate, such as approximately 14.4 Mbit/sec. Alternatively, channel 120 may perform at other data rates, greater or less than the example given above.
Network 100 may allow user equipment 104 to use an indication 126 to inform controller 102, or any other applicable controller, when an uplink data transmission is finished or completed. The uplink may be part of the data transmission channel between user equipment 104 and controller 102. Methods and processes may be defined to facilitate this communication from user equipment 104 to controller 102. After reception of indication 126 from user equipment 104, controller 102 may check the status of the downlink traffic in downlink channel path 122. If both the uplink and downlink directions are detected to be unused, then controller 102 may start resource release procedures immediately for resource 110. Alternatively, the traffic in the uplink and the downlink directions may be at a level acceptable for terminating the transmission or channel.
By receiving and using indication 126 from user equipment 104, controller 102 may optimize the use of resource 110. For example, resource 110 may be a radio access bearer-related resource. Resource 110 may be released from a radio bearer (RB) that does not desire resource 110 any longer. Controller 102 may assign resource 110, or any other applicable resource, to waiting RAB/RBs that are waiting to have access to network 100.
In order to release resource 110 immediately after the last uplink packet is sent from user equipment 104, user equipment 104 may use a method or process to inform controller 102 about the last packet in the uplink direction. This method or process may be defined to the corresponding user plane radio link control (RLC) layer that is capable of exchanging L2 level control information between peer RLC entities. Network 100, user equipment 104 and controller 102 may use different processes and methods to use the capability of the RLC layer to send control frames to inform network 100 and controller 102 about the ending of the uplink data transmission.
For example, a new uniform file identifier, or SUFI, may be defined to indicate the termination or ending of the uplink data transmission. Alternatively, the identifier may be known as a field with the last data packet or any other configuration, means, structure and the like to pass along information from user equipment 104 to controller 102. In the example, the SUFI may be referred to as an “END.” A currently used identifier, or field, such as “NO MORE” may be modified to incorporate the SUFI, and sent to controller 102 as a status packet data unit. Once received, controller 102 may analyze and determine that user equipment 104 has finished the uplink data transmission. According to the example, a new field may be added to the SUFI. Alternatively, a currently-used SUFI, such as “WINDOW,” may be used with value of 0 to indicate the end of the uplink data transmission.
Once controller 102 detects indication 126, information may be sent to a radio resource manager within network 100, or elsewhere, for further actions. If the radio resource manager or controller 102 determines that both directions of channel 120 are indicated to be inactive, then resources, such as resource 110, may be released without any additional delays. Thus, network resources may be released quickly due to user inactivity in the uplink, even though the downlink may still be open.
Controller 102 may determine whether downlink channel path, or downlink, 122 is unused. If so, no traffic should be present in the uplink or downlink direction of channel 120. Alternatively, resource 110 may be released or reconfigured even if existing data is detected in the downlink direction to user equipment 104. For example, an error may be detected in user equipment 104 that calls for a restart or reconfiguration. Any data received at or from user equipment may be corrupt. Thus, according to this example, even if traffic exists on downlink 122, transmission is terminated to user equipment 104.
Different values also may be defined into fields of the SUFI to provide information to controller 102, or commands from user equipment 104. Moreover, indication 126 may be used to request reconfiguration of channel 120, uplinks/downlinks to user equipment 104 and the like, especially if user equipment 104 has suffered an error that may not be recovered from with the reconfiguration. Thus, indication 126 and the sending of the SUFI from user equipment are not dependent on a lack of data transmission in the downlink direction, and may be used during other operations between controller 102 and user equipment 104. A fast reconfiguration may be started according to the present invention by user equipment 104 sending indication 126 that includes the proper commands, fields, and the like to request resource 110 be released.
Alternatively, the present invention may be applicable in cases where an error is detected or occurs with regard to user equipment 104. For example, a radio link may still be working, but for some reason, user equipment 104 does not want to continue the data transmission on channel 120. This kind of error case may be applicable in protocol layer error cases, on PDCP layer cases where the PDCP layer may not recover without a reset, and the like. In these instances, the layer on top of controller 102 may not work properly and, therefore, the correctness or integrity of the data may not be guaranteed. These situations may be resolved favorably by cutting the connection and forcing the subscriber or user or the system to re-establish the connection with a new configuration.
Thus, in the error case example, user equipment 104 may send indication 126 to controller 102, as discussed above. In the example, however, indication 126 may not correspond to a final data packet or end of transmission, but to the fact that an error has occurred and link should be cut. Instead of waiting for inactivity timers or other delays, controller 102 and network 100 may start resource release procedures immediately. Channel 120 may not be a high peak rate channel. A new SUFI also may be used in this example, because from the point of view of controller 102, the result is the same in that resources may be released upon receipt of an indication. The SUFI may include a field wherein the error indication is included.
User equipment 104 may desire an internal implementation to generate indication 126. For example, the RLC layer in user equipment 104 should be able to inform network 100 that transmission has finished. Thus, a procedure may be defined between an application server or network application server based on which the closing of the application may be detected. This feature may be useful when the use of an application, service or resource is totally finished. Another example may be when data transmission is stopped temporarily, such as due to a reading process. In this instance, it may be desirable to have a timer in user equipment 104 to trigger the transmission of indication 126, or another applicable indication, as soon as uplink traffic if finished. Thus, user equipment 104 may be changed faster to a specified state, and valuable DCH/HSDPA/HSUPA resources may be allocated to other users, user equipments, and the like.
Another aspect of managing network 100 may be when network 100 may have to take into account a plurality of the RLC entities configured in network 100 before making a decision if the uplink data transmission has stopped. For example, if there are 2 RLC entities or units, then the “END” indication may have to come from both entities. Each RLC, however, may send this indication separately because one RLC may serve one RAB and may have dedicated resources from controller 102 and other components, such as interfaces, within network 102. Further, because an RAB may have separate interface resources and RNC resources, these resources may be released upon receipt at the RNC, such as controller 102 from the appropriate user equipment. These resources then may be available to other users or user equipment.
Network 100 also may include user equipment 106. User equipment 106 may be a different type of user equipment from user equipment 104. For example, user equipment 106 may be from a different manufacturer than user equipment 104. Further, user equipments 104 and 106 may include different timers having periods of different lengths for inactivity. If these timer lengths in the user equipments are too long, then controller 102 may start the resource release based on its internal timers. Thus, current release procedures may not be necessarily removed from existing networks, but may be improved by implementing the present invention as discussed. Therefore, the present invention may be compatible with existing networks, controllers, user equipments and the like.
Time point, or time, 202 indicates when the last packet of a data transmission is received at a controller in the uplink direction. At time 202, a timer may start due to the inactivity on the link. The inactivity may continue for period 204. Period 204 may be the inactivity period or time delay between when the last packet is received, and when resources are starting to be released. Resources are reserved for the uplink despite not being used during period 204. Time point, or time, 206 indicates when the timer expires and a trigger for releasing resources to the uplink. Resources may not be released prior to time 206.
Time 226 indicates when the release status PDU is received with the indication that the uplink communication has terminated. Time 226 also indicates when the resources may start to be released. Time period 224 may be smaller than time period 204 because time 226 occurs without waiting on a timer, either in the controller or the user equipment. Time period 224 may be as long as it takes the user equipment to send back the indication that transmission is terminated. Timelines 200 and 220 may occur simultaneously such that resource release procedures are still started if there is a substantial delay in receiving the indication from the user equipment. Thus, resources are released even if no information is received from the user equipment based on a timer period or a timer expiring.
Step 306 executes by transmitting data between the user equipment and the controller. Data may be exchanged as packets having a source and destination. The packets of data may include fields that carry different types of information according to where a field is located within the packet. The packets may be of any length, and are not limited in the number of fields. Step 308 executes by generating a packet to be exchanged over the channel. The packet may be generated by the user equipment to be sent to the controller in the uplink direction. The generated packet may include data to inform the controller about the status of the user equipment.
Step 310 executes by determining whether the packet is the last packet in the transmission. If no, then the packet is transmitted, and the process returns back to step 306. If step 310 is yes, then step 312 executes by generating an indicator of a termination of the uplink transmission. The indicator may be any value or field within the packet that is read by the controller to acknowledge that no further transmissions will be sent from the user equipment. Step 312 may modify an existing field within the packet, or add a new field. Further, a bit may be set within the packet to provide the indicator. For example, indicator 126 may be generated within user equipment 104 by setting a bit within the packet.
Step 314 executes by sending the packet with the indicator to the controller. Referring back to
Step 318 executes by determining a downlink traffic status. For example, controller 102 of
Step 332 executes by starting resource release within the controller. Resource release may be started once the controller determines that traffic in the downlink is almost non-existent, or below a level acceptable for termination. The controller also may wait to receive termination or indicators from other user equipments, as desired. For example, controller 102 may have to receive indicators from user equipments 104 and 106 before releasing resource 110. Step 324 executes by releasing the resource from the user equipment by the controller. The resource, such as resource 110, may be reassigned to additional user equipment. Thus, the resource is not wasted on a dead channel or during times when the channel must be taken down.
Step 404 executes by generating an indicator. As discussed above, a field in a packet being sent to the controller may be modified to indicate that transmission should be terminated. The indicator may be the field, or a bit set in the field. Alternatively, a field may be added to the packet. As long as the controller can recognize that transmission is to be terminated, then the indicator is acceptable. Step 406 executes by sending the packet with the indicator to the controller from the user equipment. For example, referring to
Step 408 executes by receiving the packet including the indicator at the controller. Step 410 executes by determining whether a traffic status of the downlink is needed prior to termination. The traffic status may indicate, for example, that no traffic exists on the downlink and data transmission may not be compromised by terminating the channel. The controller also may desire to terminate the downlink and release the resource during a transmission, regardless of traffic. For example, the error condition may not allow for consideration of the downlink transmission, and the channel must be terminated immediately. Thus, if step 410 is no, then the flowchart proceeds to step 416, as discussed below.
If step 410 is yes, then step 412 is executed by determining a traffic status of the downlink. As discussed above, the traffic status may correspond to the amount of traffic on the downlink. Step 414 executes by determining whether the traffic status determined on the downlink is acceptable for termination. For example, the traffic status may indicate that no data traffic exists on the downlink and the transmission is not interrupted by terminating the link and releasing the resource. If no, then the flowchart returns back to step 412.
If step 414 is yes, then step 416 executes by starting the release resource procedures, for example, in the controller. Step 416 also may be executed if no traffic status is needed to be determined, as indicated in step 410. Step 418 executes by releasing the resource from being assigned to the user equipment. Referring back to
Thus, resources may be released in those networks having high bit rate channels so that the resources are not wasted by being assigned to unused channels or inactive user equipment. Further, the network resources may be saved in error cases without waiting for timers to terminate the channel. As discussed above, a network may use a timer concurrently with the processes described in
The preferred embodiments of the present invention enable optimization of network resources. User equipment may inform the controller when the uplink data transmission is finished. This feature may be merged into the radio link control layer to promote increased simplicity in implementation. Further, reception of the termination, or end, of the service in the uplink direction allows the controller to release resources more quickly than conventional or known processes. If a resource is reserved for active radio access bearers, then limited resources in a network or system may be used more efficiently because resource release occurs as rapidly as possible.
The preferred embodiments, and the examples described above, of the present invention may be applicable for all channel types and not only for high bit rate channels. For instance, dedicated channels may be applicable that are managed by controllers. In error cases, user equipment may stop data transmission at any time and request termination and that a resource be released. Other applicable implementations may include any instance where user equipment may communicate directly with a controller to release a resource without waiting for a timer or inactivity period.
One having ordinary skill in the art will readily understand that the invention, and the preferred embodiments, as discussed above may be practiced with steps in a different order, or with hardware elements in configurations that are different than those that are disclosed. Therefore, although the invention has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the invention. In order to determine the metes and bounds of the invention, therefore, reference should be made to the appended claims and their equivalents.
This patent application claims priority under 35 USC § 119(e) to the following co-pending patent application: U.S. Provisional Patent Application Ser. No. 60/641,149, filed Jan. 5, 2005, entitled “User Equipment-Based Resource Management Method and System,” the contents of which are hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60641149 | Jan 2005 | US |
