Patent Publication Number: US-2005141450-A1

Title: Method and system for integrating resource allocation between time division duplex and frequency division duplex in wireless communication systems

Description:
CROSS REFERENCE TO RELATED APPLICATIONS  
      This application claims priority from U.S. Provisional Application No. 60/506,428 filed on Sep. 26, 2003 and is a continuation-in-part of U.S. patent application Ser. No. 10/828,665 filed Apr. 21, 2004, which in turn claims priority from U.S. Provisional Application No. 60/464,668 filed on Apr. 22, 2003, which are incorporated by reference as if fully set forth. 
    
    
     FIELD OF INVENTION  
      The present invention is related to wireless communication systems. More particularly, the present invention relates to integrating resource allocation between time division duplex (TDD) and frequency division duplex (FDD) in wireless communication systems.  
     BACKGROUND  
      Wireless communication systems are well known in the art. In order to provide global connectivity for wireless systems, standards have been developed and are being implemented. One current standard in widespread use is known as Global System for Mobile Telecommunications (GSM). This is considered a so-called Second Generation mobile radio system standard (2G) and was followed by its revision (2.5G). GPRS and EDGE are examples of 2.5G technologies that offer relatively high speed data service on top of (2G) GSM networks. Each one of these standards sought to improve upon the prior standard with additional features and enhancements. In January 1998, the European Telecommunications Standard Institute—Special Mobile Group (ETSI SMG) agreed on a radio access scheme for Third Generation Radio Systems called Universal Mobile Telecommunications Systems (UMTS). To further implement the UMTS standard, the Third Generation Partnership Project (3GPP) was formed in December 1998. 3GPP continues to work on a common third generational mobile radio standard.  
      A typical UMTS system architecture in accordance with current 3GPP specifications is depicted in  FIG. 1 . The UMTS network architecture includes a Core Network (CN) interconnected with a UMTS Terrestrial Radio Access Network (UTRAN) via an interface known as Iu which is defined in detail in the current publicly available 3GPP specification documents. The UTRAN is configured to provide wireless communication services to users through wireless transmit receive units (WTRUs), known as User Equipments (UEs) in 3GPP, via a radio interface known as Uu. The UTRAN has one or more Radio Network Controllers (RNCs) and base stations, known as Node Bs in 3GPP, which collectively provide for the geographic coverage for wireless communications with UEs. One or more Node Bs are connected to each RNC via an interface known as Iub in 3GPP. The UTRAN may have several groups of Node Bs connected to different RNCs; two are shown in the example depicted in  FIG. 1 . Where more than one RNC is provided in a UTRAN, inter-RNC communication is performed via an Iur interface.  
      Communications external to the network components are performed by the Node Bs on a user level via the Uu interface and the CN on a network level via various CN connections to external systems.  
      In general, the primary function of base stations, such as Node Bs and access points, is to provide a wireless connection between the base stations&#39; network and the WTRUs. Typically a base station emits common channel signals allowing non-connected WTRUs to become synchronized with the base station&#39;s timing. In 3GPP, a Node B performs the physical radio connection with the UEs. The Node B receives signals over the Iub interface from the RNC that control the signals transmitted by the Node B over the Uu interface.  
      A CN is responsible for routing information to its correct destination. For example, the CN may route voice traffic from a UE that is received by the UMTS via one of the Node Bs to a public switched telephone network (PSTN) or packet data destined for the Internet. In 3GPP, the CN has six major components: 1) a serving General Packet Radio Service (GPRS) support node; 2) a gateway GPRS support node; 3) a border gateway; 4) a visitor location register; 5) a mobile services switching center; and 6) a gateway mobile services switching center. The serving GPRS support node provides access to packet switched domains, such as the Internet. The gateway GPRS support node is a gateway node for connections to other networks. All data traffic going to other operator&#39;s networks or the Internet goes through the gateway GPRS support node. The border gateway acts as a firewall to prevent attacks by intruders outside the network on subscribers within the network realm. The visitor location register is a current serving networks ‘copy’ of subscriber data needed to provide services. This information initially comes from a database which administers mobile subscribers. The mobile services switching center is in charge of ‘circuit switched’ connections from UMTS terminals to the network. The gateway mobile services switching center implements routing functions required based on the current location of subscribers. The gateway mobile services switching center also receives and administers connection requests from subscribers to external networks.  
      The RNCs generally control internal functions of the UTRAN. The RNCs also provide intermediary services for communications having a local component via a Uu interface connection with a Node B and an external service component via a connection between the CN and an external system, for example overseas calls made from a cell phone in a domestic UMTS.  
      Typically an RNC oversees multiple base stations, manages radio resources within the geographic area of wireless radio service coverage serviced by the Node Bs and controls the physical radio resources for the Uu interface. In 3GPP, the Iu interface of an RNC provides two connections to the CN: one to a packet switched domain and the other to a circuit switched domain. Other important functions of the RNCs include confidentiality and integrity protection.  
      In communication systems such as Third Generation Partnership Project (3GPP) Time Division Duplex (TDD) and Frequency Division Duplex (FDD) systems, multiple shared and dedicated channels of variable rate data are combined for transmission. Background specification data for such systems are publicly available and continue to be developed.  
      Almost all wireless communication systems use two different channels for UL and DL traffic. In TDD type systems, UL and DL channels exist in the same frequency band. Separation between the UL and DL channels occurs in the time domain. Therefore, for a particular frequency carrier, the particular link direction of that frequency carrier alternates between UL and DL depending on whether UL or DL traffic is currently being handled on that single frequency carrier. In contrast, in FDD type systems, two frequency bands are used for UL and DL connections. Most systems, including conventional cordless phones, North American cellular radios, microwave point-to-point radios and satellite systems implement FDD type technology.  
      With the development of wireless communication systems, the type of traffic carried over such systems has developed to not only include voice communications, but also various types of data transmissions. For example, multimedia data transmissions over wireless communication systems often result in asymmetric traffic load between UL and DL connections. Additionally, there is increasing overlap in coverage areas wherein both a TDD type system and a FDD type system are available to wireless users.  
      As is known to those skilled in the art, in TDD type systems, the number of UL channels and DL channels may be dynamically adjusted in accordance with traffic conditions at a particular time and place. Therefore, TDD type systems are better suited to handle asymmetrical (or otherwise unbalanced) traffic having high data rates. FDD systems, however, have an advantage over TDD type systems in that FDD systems are better suited for handling constant data rate services having low to moderate data rates such as voice traffic because of the predetermined allocation of UL and DL resources.  
      Radio resource management between TDD type systems and FDD type systems is individually performed in each system type according to their own allocation methods. This arrangement precludes potential optimizations that may be achieved by integrating resource allocation between time division duplex (TDD) and frequency division duplex (FDD) in wireless communication systems. There is a need therefore to integrate radio resource management between TDD and FDD in wireless communication systems.  
     SUMMARY  
      The present invention integrates resource allocation between time division duplex (TDD) and frequency division duplex (FDD) in wireless communication systems. A radio network controller (RNC) receives a radio access bearer (RAB) request from a core network or a wireless receive/transmit unit (WTRU). The RNC utilizes a TDD-FDD selector to assign radio resources in response to the request. The TDD-FDD selector evaluates various parameters regarding the received RAB request and determines whether it is preferable to assign TDD resources or FDD resources and whether such resources are currently available. Once resources are assigned, system conditions are evaluated to determine whether optimizations may be made to a current resource allocation. 
    
    
     BRIEF DESCRIPTION OF THE DRAWING(S)  
       FIG. 1  is a diagram of a typical wireless communication system.  
       FIG. 2  is a diagram illustrating an embodiment of the present invention wherein a TDD-FDD selector is provided for TDD and FDD type radio network controllers (RNCs).  
       FIG. 3  is a diagram illustrating an embodiment of the present invention wherein a TDD-FDD selector is provided for an integrated TDD/FDD RNC.  
       FIG. 4  is a method wherein wireless resources are assigned in accordance with the present invention.  
       FIG. 5  is a diagram illustrating an embodiment of the present invention wherein TDD and FDD type service may be provided with a single Iu connection between a core network and a FDD RNC.  
       FIG. 6  is a diagram illustrating the configuration of the RNCs shown in  FIG. 5 .  
       FIG. 7  is a block diagram of an RNC including a TDD-FDD selector having a policy server.  
       FIG. 8  is a flow chart of a process for handover between communication modes wherein a RNC is configured with a TDD-FDD selector having a policy server. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S)  
      The present invention will be described with reference to the drawing figures wherein like numerals represent like elements throughout.  
      Hereafter, the terminology “WTRU” includes but is not limited to a user equipment, mobile station, a fixed or mobile subscriber unit, a pager, or any other type of device capable of operating in a wireless environment. When referred to hereafter, the terminology “base station” includes but is not limited to a Node-B, a site controller, an access point, or any other interfacing device in a wireless environment.  
      Referring now to  FIG. 2 , there is shown a wireless communication system  200  in accordance with the present invention. The system  200  includes a TDD radio network controller (RNC)  204  and a FDD RNC  208  connected to a core network  202 . Each RNC  204 ,  208  controls at least one base station. For example, the TDD RNC  204  controls base station  212 . Base station  212  in turn provides a coverage area  210  wherein WTRUs  228 ,  230  operating within coverage area  210  may be assigned resources from TDD RNC  204 . Similarly, the FDD RNC  208  controls base station  216  which in turn provides coverage area  214 . WTRUs  220 ,  222  may be assigned resources from FDD RNC  208 . In area  218 , there is both TDD and FDD service available to WTRUs  224  and  226 . Overlapping coverage areas such as area  218  may be of any size and the particular arrangement shown in  FIG. 2  is purely by way of example.  
      When a radio access bearer (RAB) request (i.e. a call-setup request) is transmitted from a core network or WTRU to an RNC, it is typically transmitted along with a plurality of parameters that provide information regarding how the requested connection will be utilized. Examples of such parameters include, but are not limited to, the degree of symmetry between the uplink and downlink (i.e. symmetry or symmetry status of the requested connection), data transfer rate, frame size, application type, and whether the requested connection is point-to-point, point-to-multipoint, or broadcast. The aforementioned parameters are purely by way of example, as any type of parameter providing information regarding the requested connection may be utilized.  
      RNCs  204 ,  208  of the present invention are configured with TDD-FDD selectors  206 ,  210 , respectively. The TDD-FDD selectors  206 ,  210  may be one or more processors, as desired, for determining the optimal technology type for a received RAB request. That is, based on, for example, parameters provided regarding a RAB request, resource availability, and/or any other relevant considerations, the TDD-FDD selectors  206 ,  210  work in conjunction with an RNC&#39;s existing functionality including its radio resource manager (RRM) to assign resources so that connection requests are assigned resources based on the most efficient system technology type for handling the particular type of connection request. For example, assuming symmetry is the primary consideration, connection requests having symmetrical traffic (i.e. a similar amount of traffic in both the uplink and downlink) are preferably handled by the FDD RNC  208  which, of course, implements FDD technology and is more efficient at handling such traffic. Similarly, connection requests having asymmetrical traffic (i.e. a larger amount of traffic in one direction than the other) are preferably handled by the TDD RNC  204  which, of course, implements TDD technology and is more efficient at handling such traffic.  
      For example, again where symmetry is the primary consideration, to determine the preferred technology type for a particular received RAB request, a TDD-FDD selector  206 ,  210  may estimate data rates in the uplink and downlink for the received RAB request. The estimated uplink and downlink data rates may be estimated based on, for example, requested data rate, current traffic conditions, current interference levels, or any other relevant parameters. The TDD-FDD selector  206 ,  210  may then compare the difference between the estimated uplink and downlink data rates versus a predetermined threshold. If the difference between the estimated uplink and downlink data rates is equal to or above the threshold, the RAB request may be considered asymmetrical (i.e. has an asymmetrical symmetry status) and resources from a TDD RNC  204  may be assigned. If the difference between the estimated data rates is below the threshold, the RAB request may be considered symmetrical (i.e. has a symmetrical symmetry status) and resources from a FDD-RNC  208  may be assigned.  
      As mentioned above, other parameters including application type and data rate may be evaluated, individually or in combination with symmetry, when determining the optimal technology type for assigning resources based on a received RAB request. For example, where a requested connection is for a voice application requiring real-time transmission, it is preferable for the connection to be provided using the FDD RNC  208 . Similarly, for a data application not requiring real-time transmission, it is preferable for the connection to be provided using the TDD RNC  204 . In general, if the traffic is very asymmetrical with a high data rate, TDD is preferable. If the traffic is very symmetrical with a fairly low data rate, FDD is preferable. Anything in between may be sent to either TDD or FDD depending on the situation. For example, if TDD cells are congested, it may be desirable to assign a RAB request to FDD regardless of other parameters.  
      It is noted that, in this embodiment, a RAB request may originate through either a TDD RNC  204  or a FDD RNC  208 . In either case, the RNC that received the request makes the decision regarding resource assignment and, where necessary, forwards the RAB request to another RNC type as appropriate so that resources are allocated by an appropriate type of RNC. For example, where a TDD RNC  204  receives a RAB request and determines that it should be handled using FDD type technology, the TDD RNC  204  will transfer the request to a FDD RNC  208  via an Iur interface. The FDD RNC  208  will then handle the request in a normal fashion.  
      Referring now to  FIG. 3 , in another embodiment of the present invention, an integrated TDD-FDD RNC  304  is provided. The integrated TDD-FDD RNC  304  integrates the conventional functionality of a TDD RNC and a FDD RNC. In this embodiment, therefore, a single TDD-FDD selector  306  is provided. The TDD-FDD selector  306  operates as explained above and determines whether received RAB requests should be handled in TDD mode or FDD mode. As explained above, the TDD-FDD selector may evaluate symmetry, data rate, application type, resource availability, and any other relevant parameters when determining which mode is appropriate for a particular RAB request. For example, since WTRUs  320  and  322  are in a joint coverage area  324 , WTRUs  320  and  322  may be assigned resources in either TDD mode or FDD mode, as appropriate.  
      Referring now to  FIG. 4 , there is shown a method  400  for assigning system resources in accordance with the present invention. The method  400  begins in step  402  when a radio access bearer (RAB) request is received. The request may be received by either a TDD or FDD RNC or, in the case where an integrated TDD/FDD RNC is provided, the request may be received in either FDD mode or TDD mode. Then, in step  404 , parameters regarding the received request are evaluated. As explained above, the parameters may be any parameters that provide information regarding the received RAB. Typically, the parameters that are preferably evaluated include symmetry, data rate, and application type.  
      In step  406 , it is determined based on the parameters evaluated in step  404  whether it is preferable to handle the requested service in a TDD type cell or a FDD type cell (i.e. in TDD mode or FDD mode). As previously explained, it is preferable to handle high data rate asymmetrical connections in TDD (i.e. in a TDD cell) while symmetrical lower data rate connections are preferably handled in FDD (i.e. in a FDD cell).  
      If it is determined that the requested service is preferably handled in a TDD cell, the method  400  proceeds from step  406  to step  408 . In step  408 , it is determined whether the WTRU that requires the RAB is within a TDD cell. That is, although it has been determined in step  406  that TDD is preferable, step  408  is a confirmation of whether TDD service is in fact currently available. For example, if the received RAB request was issued by a WTRU operating within a TDD cell and it is determined that the request should be handled within a TDD cell, TDD service is obviously available. However, where the received RAB request is issued by a WTRU operating within a FDD cell and it is determined that the request should be handled within a TDD cell, the present invention confirms that TDD service is also available prior to handing the WTRU over from FDD to TDD. Therefore, if in step  408  it is determined that the WTRU is within a TDD cell, the requested service is provided in a TDD cell in step  410 . However, if it is determined that the WTRU is not within a TDD cell (i.e. TDD service is not available), the requested service is provided to the WTRU in a FDD cell (step  414 ). Note in this situation that although the WTRU is not being serviced in a preferred cell (i.e. in a TDD cell), the WTRU will be provided with its requested service in FDD which is the system in which the WTRU was operating when the RAB was requested.  
      Similar to the above, if in step  406  it is determined that the requested service is preferably handled in a FDD cell, the method  400  proceeds from step  406  to step  412 . In step  412 , it is determined whether the WTRU that requires the RAB is within a FDD cell. That is, although it has been determined in step  408  that FDD is preferable, step  412  is a confirmation of whether FDD service is in fact currently available. For example, if the received RAB request was issued by a WTRU operating within a FDD cell and it is determined that the request should be handled within a FDD cell, FDD service is obviously available. However, where the received RAB request is issued by a WTRU operating within a TDD cell and it is determined that the request should be handled within a FDD cell, the present invention confirms that FDD service is also available prior to handing the WTRU over from TDD to FDD. Therefore, if in step  412  it is determined that the WTRU is within a FDD cell, the requested service is provided in a FDD cell in step  414 . However, if it is determined that the WTRU is not within a FDD cell (i.e. TDD service is not available), the requested service is provided to the WTRU in a TDD cell (step  410 ). Note in this situation that although the WTRU is not being serviced within a preferred cell (i.e. a FDD cell), the WTRU is provided with its requested service in TDD which is the system in which the WTRU was operating when the RAB was requested.  
      As mentioned above, once service is being provided to a WTRU in a particular type of cell, that cell will be either a preferred cell or a non-preferred cell with respect to that WTRU. Therefore, once the requested service is being provided, the method  400  proceeds from either step  410  or  414  to step  416 . In step  416 , parameters regarding the established connection are evaluated to determine whether any optimizations may be performed. For example, where a WTRU was assigned to a TDD cell, but had previously requested a service where it was determined that a FDD cell is preferred, WTRU location may be monitored to determine whether the WTRU moves into a FDD cell or FDD service otherwise becomes available. Existing connections may also be evaluated in step  416  with respect to symmetry (i.e. the connection&#39;s symmetry status), data rate, application type, and/or any other relevant parameters to determine whether the type of cell a WTRU is currently operating in, is still the WTRU&#39;s preferred cell. That is, while an initial evaluation may lead to a determination that a TDD cell is preferred, conditions or usage may change causing a FDD cell to become preferred. Based on the evaluation(s) performed in step  416 , if it is possible to perform any type of optimization (i.e. move a WTRU from one type of cell to another, for example), the method  400  proceeds from step  418  to step  420  and reallocates the current cell allocation as appropriate. Once the reallocation is complete, the method  400  may return to step  416  to look for additional optimizations. If, based on the evaluations of step  416 , no optimizations are currently possible, the method  400  may return to directly to step  416  and continue monitoring and evaluating existing connections for purposes of detecting any possible optimizations.  
      Referring now to  FIG. 5 , another embodiment of the present invention is shown. In this embodiment, TDD and FDD RNCs may be provided, but only a single Iu connection to a core network is needed. The Iu connection is provided between the core network and an RNC belonging to the RNC type (i.e. either TDD or FDD) that is the dominant type of technology in the system. That is, the majority of coverage provided by the system may be TDD in which case TDD is the dominant system type and the Iu connection is provided between the core network and a TDD RNC. For purposes of explaining the invention, the system  500  shown in  FIG. 5  is a FDD system having a wide area of coverage  550  wherein FDD is the dominant type of technology. Within the FDD coverage area  550  are a plurality of TDD hotspots  552 ,  554 ,  556 ,  558  wherein higher data rates are available.  
      In system  500 , all connections are set up and ended by FDD RNC  508  thereby allowing a single Iu connection to be provided to the core network  502 . Therefore, all RAB requests are received by FDD RNC  508  and evaluated by TDD-FDD selector  510 , as explained above. Where the selector  510  determines that a particular request should be handled in TDD and TDD service is available (eg. WTRU  524 ), the connection is transferred to TDD RNC  504  and is handled within the TDD portion (eg. RNC  504 , base stations  570 ,  572 ) of system  500 . That is, typical TDD radio resource management may be used while a WTRU  524  is operating within the TDD portion of system  500 . Similarly, where FDD service is preferred or is the only service that is available, typical FDD radio resource management may be used.  
      To initiate and end all traffic (TDD and FDD) through the FDD RNC  508  as explained above, additional functionality is preferably provided in the FDD RNC  508 . In a preferred embodiment, the FDD RNC  508  is configured as shown in  FIG. 6 . The FDD RNC  508  includes a FDD RRM  604  and is configured to perform Iu protocols  602 , FDD Iub protocols  606 , and FDD Iur protocols  610 , as normal. Additionally, the FDD RNC  508  includes a TDD serving radio network controller (S-RNC) radio resource manager (RRM)  608  and is configured to perform TDD Iur protocols  610 . It is noted that the additional functionality added to FDD RNC  508  (i.e. TDD SRNC RRM  608  and TDD Iur protocols  610 ) is similar to the functionality already performed in a typical FDD RNC and may be added, for example, as a software upgrade. The TDD RNC  504  is preferably configured to include a controlling RNC (C-RNC) TDD RRM  612  and is further configured to support TDD Iub protocols  614  and TDD Iur protocols  613 , as normal.  
      Configuring an RNC as shown in FDD RNC  508  allows the configuration of a TDD RNC  504  to be less complex and therefore easier and cheaper to deploy. That is, having a single Iu connection between the core network  502  and the FDD RNC  508  and thereby eliminating the need for the TDD RNC  504  to support Iu protocols allows for quick deployment of TDD networks within a wider area FDD network. In this embodiment, the TDD RNC  504  will never be in a S-RNC mode and therefore also does not need to support the standard functionality of a S-RNC. This is because, as mentioned above, WTRUs operating within the system  500  are always forced to access the FDD RNC  508  at call connection and disconnection. That is, broadcast and access control channels are only set up in the FDD RNC  508  and therefore only when a RAB is assigned by TDD-FDD selector  510  to TDD can a WTRU such as WTRU  524  get into the TDD portion of system  500 . Once assigned to the TDD portion of system  500 , the WTRU  524  operates as normal within the TDD coverage areas and is handed over between TDD cells or back to the FDD RNC  508  as appropriate. The handover decisions between TDD cells in handled in accordance with standard TDD functionality while decisions on whether a WTRU should be handed back to a FDD RNC area is preferably determined by the TDD-FDD selector  510 .  
       FIG. 7  is a block diagram of an RNC  700  including a TDD-FDD selector  702  in accordance with alternate embodiment of the present invention. The RNC  700  is capable of switching between a TDD mode and a FDD mode. The RNC  700  preferably includes both an FDD RRM  708  and a TTD RRM  710  so that the RNC  700  may perform radio resource management for both TDD and FDD modes of communication.  
      The TDD-FDD selector  702  may be included in another entity, such as Node-B or any other RNC functional entity. The RNC  700  may be a standalone RNC entity or a combination device that includes RNC functionality in its implementation, such as a General Packet Radio Service Serving Node (GSN)/RNC, or an RNC/Node B.  
      The FDD/TDD selector  702  includes a handover unit  704  and a policy server  706 . The handover unit  704  performs a TDD-FDD handover and a FDD-TDD handover in accordance with an output of the policy server  706 .  
      The policy server  706  receives inputs related to one or more policies and makes a determination regarding a proper mode of communication. One or more policies are defined for initiating a FDD/TDD handover. Typical policy categories include: 1) Quality of Service (QoS); 2) Service; 3) Management; and 4) Behavior, but may include any additional categories as desired. The QoS policy defines the QoS condition such as a power or quality threshold. The service policy defines the service characteristic conditions, such as data rate asymmetry or real time (RT) service (e.g. a voice call) vs. non-real time (NRT) service (e.g. web browsing). The management policy defines the operation, administration and maintenance (OA&amp;M) conditions. This includes RT policies applied for load balancing purposes, or NRT aspects relating to maintenance. The behavior policy defines one or more user behavior conditions, such as user location, or speed.  
      Policies are defined as part of system configuration and may be independent or interdependent. For example, a management policy may take precedence over a QoS or service policy. Relevant inputs related to each policy are input to the policy server. The inputs to the policy server are provided by general RNC Control Logic, RRM functions or by an external entity, such as an OAM function. The policies may be defined or otherwise configured as desired thereby enabling service requests to be handled in either FDD mode or TDD mode, as desired.  
      Upon receipt of a request for a new call or a handover, the TDD-FDD selector  702  requests the policy server to make a decision regarding a proper mode of communication. The TDD-FDD selector  702  performs either a selection of a proper mode of communication or a transition between an FDD mode and a TDD mode in accordance with the decision made by the policy server  706 .  
       FIG. 8  is a flow diagram of a process  800  for handover between a TDD mode and an FDD mode in accordance with the present invention. Initially a WTRU establishes a communication in a particular communication mode (step  802 ). The WTRU then requests a particular service, such as web browsing (step  804 ). The RNC  700  then determines whether one or more of a plurality of predetermined policies is satisfied for the service request such that a transition of the mode of communication should occur (step  806 ). If one or more of the policies are met, (such as QoS, location, speed, etc.), the policy server  706  indicates that the communication mode in which the service should be granted, and the RNC  700  performs a transition of the communication mode in accordance with that indication (step  808 ). If not, the RNC  700  maintains the current mode of communication ( 810 ).  
      By way of example, where a voice call arrives while a WTRU is in a TDD mode, relevant inputs of each policy are input to the policy server. If one or more of the policy conditions for TDD to FDD handover is met, the policy server  706  indicates that a transition to FDD mode should occur and the RNC  700  performs the transition to FDD mode.  
      It is noted that while only one RNC of each RNC type (i.e. FDD and TDD) are shown in describing the present invention, any number of TDD RNCs and FDD RNCs may be provided. In such arrangements, RNCs of the same type communicate as normal using their respective Iur protocols. It is also noted that the various functions and protocols described herein, either individually or collectively, may be performed using any number of processors as desired.  
      It is important to note that the present invention may be implemented in any type of wireless communication system employing any type of time division duplex (TDD) technology or any type of frequency division duplex (FDD) technology, as desired. By way of example, the present invention may be implemented in UMTS-TDD, UMTS-FDD, TDMA, TDSCDMA, or any other similar type of wireless communication system. Further, while the present invention has been described in terms of various embodiments, other variations, which are within the scope of the invention as outlined in the claim below will be apparent to those skilled in the art.