Note: Descriptions are shown in the official language in which they were submitted.
CA 02539728 2006-03-21
WO 2005/032172 PCT/US2004/031366
[0001] METHOD AND SYSTEM FOR INTEGRATING RESOURCE
ALLOCATION BETWEEN TIME DIVISION DUPLEX AND FREQUENCY
DIVISION DUPLEX IN WIRELESS COMMUNICATION SYSTEMS
[0002] FIELD OF INVENTION
[0003] 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.
[0004] BACKGROUND
[0005] 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.
[0006] A typical UMTS system architecture in accordance with current
3GPP specifications is depicted in Figure 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
-1-
CA 02539728 2006-03-21
WO 2005/032172 PCT/US2004/031366
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 Figure 1. Where more
than one RNC is provided in a UTRAN, inter-RNC communication is performed
via an Iur interface.
[0007] 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.
[0008] 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'
network and the WTRUs. Typically a base station emits common channel signals
allowing non-connected WTRUs to become synchronized with the base station'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.
[0009] 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 (GPRB) 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'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
-2-
CA 02539728 2006-03-21
WO 2005/032172 PCT/US2004/031366
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.
[0010] 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.
[0011] 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_
[0012] 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.
[0013] 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 Barrier 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,
-3-
CA 02539728 2006-03-21
WO 2005/032172 PCT/US2004/031366
North American cellular radios, microwave point-to-point radios and satellite
systems implement FDD type technology.
[0014] 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.
[0015] 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.
[0016] 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.
[0017] SUMMARY
[0018] 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
-4-
CA 02539728 2006-03-21
WO 2005/032172 PCT/US2004/031366
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.
[0019] BRIEF DESCRIPTION OF THE DRAWINGS)
[0020] Figure 1 is a diagram of a typical wireless communication system.
[0021] Figure 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).
[0022] Figure 3 is a diagram illustrating an embodiment of the present
invention wherein a TDD-FDD selector is provided for an integrated TDD/FDI7
RNC.
[0023] Figure 4 is a method wherein wireless resources are assigned in
accordance with the present invention.
[0024] Figure 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.
[0025] Figure 6 is a diagram illustrating the configuration of the RNC s
shown in Figure 5.
[0026] Figure 7 is a block diagram of an RNC including a TDD-FDIC
selector having a policy server.
[0027] Figure 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.
[0028] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS)
[0029] The present invention will be described with reference to the
drawing figures wherein like numerals represent like elements throughout.
[0030] 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
-5-
CA 02539728 2006-03-21
WO 2005/032172 PCT/US2004/031366
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.
[0031] Referring now to Figure 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 Figure 2 is purely by way of example.
[0032] 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.
[0033] 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
-6-
CA 02539728 2006-03-21
WO 2005/032172 PCT/US2004/031366
considerations, the TDD-FDD selectors 206, 210 work in conjunction with an
RNC'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.
[0034] 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.
[0035] 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
_7_
CA 02539728 2006-03-21
WO 2005/032172 PCT/US2004/031366
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.
[0036] 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.
[0037] Referring now to Figure 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.
[0038] Referring now to Figure 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
_g_
CA 02539728 2006-03-21
WO 2005/032172 PCT/US2004/031366
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.
[0039] 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).
[0040] 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.
-9-
CA 02539728 2006-03-21
WO 2005/032172 PCT/US2004/031366
(0041] 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.
[0042] 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'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's preferred
cell.
-10-
CA 02539728 2006-03-21
WO 2005/032172 PCT/US2004/031366
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 evaluations) 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.
[0043] Referring now to Figure 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 Figure 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.
[0044] 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,
-11-
CA 02539728 2006-03-21
WO 2005/032172 PCT/US2004/031366
where FDD service is preferred or is the only service that is available,
typical
FDD radio resource management may be used.
[0045] 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 Figure 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.
[0046] 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
-12-
CA 02539728 2006-03-21
WO 2005/032172 PCT/US2004/031366
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.
[0047] Figure 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.
[0048] 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)lR,NC, or an R,NC/Node B.
[0049] 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.
[0050] 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&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.
[0051] Policies are defined as part of system configuration and may be
independent or interdependent. For example, a management policy may take
-13-
CA 02539728 2006-03-21
WO 2005/032172 PCT/US2004/031366
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.
[0052] 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.
[0053] Figure 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).
[0054] 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.
[0055] 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
-14-
CA 02539728 2006-03-21
WO 2005/032172 PCT/US2004/031366
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.
[0056] 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, TDSGDMA, 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.
-15-
