General Features of E-UTRAN

 
General Features of E-UTRAN
The study being carried out under the 3GPPWork Plan is focussing on supporting services provided by
the packet-switched (PS) domain with activities in the following areas, at the very least. (1) services
related to the radio-interface physical layer (DL and UL), for example, to support flexible transmission  bandwidth up to 20 MHz, and new transmission schemes and advanced multiantenna technologies;
(2) services related to the radio-interface layer 2 and 3: for example, signaling optimization;
(3) services related to the UTRAN architecture: (a) identify the most optimum UTRAN network
architecture and the functional split between RAN network nodes, and (b) RF-related issues. It is
very important to note that the E-UTRAN scheme leaves open an option to operate at a bandwidth
that is much wider than its predecessor, the WCDMA UTRA, which has a fixed signal bandwidth at
5 MHz; this paves the way for providing a much higher data rate transmission in the E-UTRAN than
was possible in its 3G standard, WCDMA, as discussed in Section 3.2.
Also note that, as a packet-based data service in WCDMA DL with data transmission up to 8–10
Mbps (and 20 Mbps for MIMO systems), HSDPA also operates over a 5 MHz bandwidth in WCDMA
DL. Unlike standard WCDMA, the HSDPA uses several advanced technologies in its implementations,
including AMC, Multiple-Input Multiple-Output (MIMO), Hybrid Automatic Request (HARQ), fast
cell search, and advanced receiver design. However, its fixed bandwidth operation limits its further
enhancement in its data transmission rate. Therefore, in this sense, the E-UTRAN is a big step forward
toward 4G wireless technology.
All RAN WGs will participate in the study on E-UTRAN, with collaboration from SA WG2
in the key area of the network architecture. The first part of the study was the agreement of the
requirements for the E-UTRAN. Two joint meetings, with the participation of all RAN WGs, were
held in 2005:
(1) RAN WGs on Long-Term Evolution, 7–8 March 2005, Tokyo, Japan;
(2) RAN WGs on Long-Term Evolution, 30–31 May, Quebec, Canada.
In the above two meetings, TR25.913 [817] was drafted and completed. This Technical Report
(TR) contains detailed requirements or the following key parameters, which will be introduced individually
in the sequel.
Peak Data Rate
E-UTRA should support significantly increased instantaneous peak data rates, which should scale
according to different sizes of the spectrum allocation.
E-UTRAN should provide instantaneous DL peak data rate of 100 Mb/s within a 20 MHz DL
spectrum allocation (5 bps/Hz), and instantaneous UL peak data rate of 50 Mb/s (2.5 bps/Hz) within a
20 MHz UL spectrum allocation. It is therefore noted that the occupied bandwidth for the E-UTRAN
has been increased four times as wide as what its 3G system does.
Note that the peak data rates may depend on the numbers of transmit and receive antennae at
the UE. The above targets for DL and UL peak data rates were specified in terms of a reference UE
configuration comprising: (1) DL capability with two receive antennae at UE, (2) UL capability with
one transmit antenna at UE. In case of spectra shared between DL and UL transmission, E-UTRA
does not need to support the above instantaneous peak data rates simultaneously.
It is noted that the DL peak data rate supported by HSDPA (an enhanced 3GPP 3G version)
is about 10 Mbps (as discussed in Section 3.2.1). Thus, the bandwidth efficiency required by EUTRAN
(assume that the 20 MHz bandwidth will be used) has been doubled if compared to that of
the HSDPA, which uses 5 MHz bandwidth for its operation.
In the design of E-UTRAN architecture, emphasis has been laid on the increasing cell edge bit
rate while maintaining the same site locations as deployed in UTRAN/GERAN today.
C-plane and U-plane latency
It is required that a significantly reduced Control-plane (C-plane) latency (e.g. including the possibility
to exchange user-plane data starting from a camped state with a transition time of less than 100 ms,
excluding DL paging delay) should be ensured. E-UTRAN should have a transition time of less than 100 ms from a camped state, such as Release
6 Idle Mode, to an active state such as Release 6 CELL DCH. It also needs to provide a transition
time of less than 50 ms between a dormant state such as Release 6 CELL PCH and an active state
such as Release 6 CELL DCH. An example of state transition in E-UTRAN is shown in Figure 10.3.
It is also required that the possibility for a RAN U-plane latency below 10 ms should be included.
The U-plane delay is defined as the one-way transit time between a packet being available at the IP
layer in either the UE/RAN edge node and the availability of this packet at the IP layer in the RAN
edge node/UE. The RAN edge node is the node providing the RAN interface toward the core network.
Specifications should enable an E-UTRA U-plane latency of less than 5 ms in unload conditions (i.e.
a single user with a single data stream) for small IP packet, for example, zero byte payload plus
IP headers. Obviously, E-UTRAN bandwidth allocation modes may impact the experienced latency
substantially.
The protocol stacks for the C-plane and U-plane are shown in Figures 10.8 and 10.7, respectively.
Data throughput
The DL data throughput in E-UTRAN will be three to four times higher than that specified in the
Release 6 HSDPA UL specifications in terms of an averaged user throughput per MHz. It is noted
that the DL throughput performance concerned has assumed that the Release 6 reference performance
is based on a single Tx antenna at the Node B with an enhanced performance type one receiver in
the UE; while the E-UTRA may use a maximum of two Tx antennae at the Node B and two Rx
antennae at the UE. Also, it is understandable that the supported user throughput should scale with
the spectrum bandwidth allocation schemes.
On the other hand, the UL throughput in E-UTRAN will be two to three times higher than that
given in the Release 6 Enhanced Uplink or the HSUPA in terms of averaged user throughput per
MHz. It is assumed that the Release 6 Enhanced Uplink is deployed with a single Tx antenna at the
UE and two Rx antennae at the Node B; and the E-UTRA uses a maximum of a single Tx antenna at
the UE and two Rx antennae at the Node B. Of course, a greater user throughput should be achievable
using more Tx antennae at the UE.
Spectrum efficiency
E-UTRA should deliver significantly improved spectrum efficiency and increased cell edge bit rate
while maintaining the same site locations as UTRAN and GERAN deployed today.
In a loaded network, the spectrum efficiency in the DL channels in E-UTRAN should be three to
four times higher than the Release 6 HSDPA if measured in bits/sec/Hz/site. This should be achieved assuming that the Release 6 reference performance is based on a single Tx antenna at the Node B
with enhanced performance type 1 receiver in UE; while the E-UTRA may use a maximum of two
Tx antennae at the Node B and two Rx antennae at the UE.
The spectrum efficiency in the UL channels in E-UTRAN should be two to three times higher than
the Release 6 Enhanced Uplink deployed with a single Tx antenna at the UE and two Rx antennae at
the Node B. This spectrum efficiency in the UL channels in E-UTRAN should be achievable by the
E-UTRA using a maximum of a single Tx antenna at the UE and two Rx antennae at the Node B.
It should be noted that the discrepancy in the spectrum efficiency between the DL and UL channel
underlines the different operational environments between the DL and UL. Usually, the UL is much
more susceptive to channel impairments, such as multipath interference, and so on, and thus the cost
to maintain a satisfactory detection efficiency in UL channels is higher than that in DL channels.
E-UTRAN should support a saleable bandwidth allocation scheme, that is, 5, 10, 20, and possibly
15 MHz. Support to scale the bandwidth in an increment factor of 1.25 or 2.5 MHz should also be
considered to allow flexibility in narrow spectral allocations where the system may be deployed.
Mobility support
E-UTRAN should be optimized in terms of its performance for low mobile users at a speed from 0
to 15 km/h. Higher mobile users at a speed between 15 and 120 km/h should be supported with a
satisfactorily high performance. Supportable mobility across the cellular networks should be maintained
at speeds from 120 km/h to 350 km/h (or even up to 500 km/h depending on the frequency
band allocated). The provision for mobility support up to 350 km/h is important to maintain an
acceptable service quality to the users who need the services at high-speed railway systems, such
as the Euro-Star trains running between the United Kingdom and France. In such a case, a special
scenario applies for issues such as mobility solutions and channel models. For the physical layer
parameterizations, E-UTRAN should be able to maintain the connection up to 350 km/h, or even up
to 500 km/h depending on the frequency band.
The E-UTRAN should also support techniques and mechanisms to optimize delay and packet loss
during intrasystem handovers. Voice and other real-time services supported in the Circuit Switched
(CS) domain in R6 should be supported by E-UTRAN via the PS domain with a minimum of equal
quality as supported by UTRAN (e.g. in terms of guaranteed bit rate) over the whole speed range.
The impact of intra E-UTRA handovers on quality (e.g. interruption time) should be less than or
equal to that provided by CS-domain handovers in GERAN.
Coverage
E-UTRA should be sufficiently flexible to support a variety of coverage scenarios for which the
aforementioned performance targets should be met assuming the reuse of existing UTRAN sites and
the same carrier frequency. For more accurate comparisons, reference scenarios should be defined
that are representatives of the current UTRAN (WCDMA) deployments.
The throughput, spectrum efficiency, and mobility support mentioned above should be met for
5 km cells in radius, and with a slight degradation for 30 km cells in radius. A cell range of up to
100 km should not be precluded.
As mentioned earlier, E-UTRAN should operate in spectrum allocations of different bandwidths,
such as 1.25 MHz, 2.5 MHz, 5 MHz, 10 MHz, 15 MHz, and 20 MHz, in both the UL and DL.
Operations in paired and unpaired spectra should also be supported. Operation in paired and unpaired
spectra should not be excluded.
The system should be able to support content delivery over an aggregation of resources, including
Radio Band Resources (as well as power, adaptive scheduling, etc.) in same as well as different bands,
in both UL and DL, and in both adjacent and nonadjacent channel arrangements. A “Radio Band
Resource” is defined as an all spectrum available to an operator. Enhanced MBMS
Multimedia Broadcast Multicast Service (MBMS), has been introduced in 3GPP UTRAN services.
E-UTRA systems should support enhanced MBMS modes if compared to UTRA operation. For the
unicast case, E-UTRA should be capable of achieving the target performance levels when operating
from the same site locations as existing UTRA systems.
E-UTRA should provide enhanced support for MBMS services. Specifically, E-UTRA’s support
for MBMS should take the following requirements into account. (1) Physical Layer Component
Reuse: in order to reduce E-UTRA terminal complexity, the same fundamental modulation, coding,
and multiple access approaches used for unicast operations should apply to MBMS services, and the
same UE bandwidth mode set supported for unicast operations should be applicable to the MBMS
operation. (2) Voice and MBMS: the E-UTRA approach to MBMS should permit simultaneous, tightly
integrated, and efficient provisioning of dedicated voice and MBMS services to the user. (3) Unpaired
MBMS Operation: the deployment of E-UTRA carriers bearing MBMS services in unpaired spectrum
arrangements should be supported.
Spectrum deployment
E-UTRA is required to work with the following spectrum deployment scenarios:
• Coexistence in the same geographical area and colocation with GERAN/UTRAN on adjacent
channels.
• Coexistence in the same geographical area and colocation between operators on adjacent
channels.
• Coexistence on overlapping and/or adjacent spectra at country borders.
• E-UTRA should possibly operate stand-alone, that is, there is no need for any other carrier to
be available.
• All frequency bands should be allowed following release of independent frequency band
principles.
It is noted that in case of border coordination requirements, other aspects such as possible scheduling
solutions should be considered, along with other physical layer behaviors.
Coexistence and interworking with 3GPP RAT
E-UTRAN should support interworking with existing 3G systems and non-3GPP specified systems.
E-UTRAN should provide a possibility for simplified coexistence between the operators in adjacent
bands as well as cross-border coexistence.
Basically, all E-UTRAN terminals that are also supporting UTRAN and/or GERAN operations
should be capable of supporting the measurement of, and the handover from and to, both 3GPP
UTRA and 3GPP GERAN systems. In addition, E-UTRAN is required to efficiently support inter-
RAT (Radio Access Technology) measurements with an acceptable impact on terminal complexity
and network performance, for instance, by providing UEs with measurement opportunities through
DL and UL scheduling.
Therefore, note that the question here is not about backward compatibility, but only about the
support for handover mechanism between different 3GPP networks. Also note that HSPDA is still
a 3G solution from 3GPP, and it is fully backward compatible to WCDMA networks. Backwards
compatibility is highly desirable in E-UTRAN, but the trade-off versus performance and/or capability
enhancements should be carefully considered. It is interesting to note that, like the compatible
problems existing between UTRAN (based on WCDMA) and GERAN (based on GSM), the problem
has surfaced again here between E-UTRAN and UTRAN. Requirements that are applicable to interworking between E-UTRA and other 3GPP systems are
listed below:
• The interruption time during a handover of real-time services between E-UTRAN and UTRAN
should be less than 300 ms.
• The interruption time during a handover of non real-time services between E-UTRAN and
UTRAN should be less than 500 ms.
• The interruption time during a handover of real-time services between E-UTRAN and GERAN
is less than 300 ms.
• The interruption time during a handover of non real-time services between E-UTRAN and
GERAN should be less than 500 ms.
• Nonactive terminals (such as the one in Release 6 idle mode or CELL PCH) that support
UTRAN and/or GERAN in addition to E-UTRAN should not need to monitor paging messages
only from one of GERAN, UTRA or E-UTRA.
The above requirements are set for the cases where the UTRAN and/or GERAN networks provide
support for E-UTRAN handovers. The interruption times required above are to be considered as
maximum values, which may be subject to further modifications when the overall architecture and
the E-UTRA physical layer has been defined in more detail.
Architecture and migration
A single E-UTRAN architecture should be agreed upon in TSG. The E-UTRAN architecture should
be packet-based, although provisions should be made to support real-time and conversational class
traffic. E-UTRAN architecture should simplify and minimize the number of interfaces where possible.
E-UTRAN should offer a cost-effective migration from Release 6 UTRA radio interface and
architecture. The design of the E-UTRAN network should be under a single E-UTRAN architecture,
which should be packet-based (thus, all IP wireless architecture will be dominant in the
E-UTRAN networks), although provisions should be made to support real-time and conversational
class traffic.
E-UTRAN architecture should minimize the presence of “single point of failures,” and thus some
backup measures should be considered. The E-UTRAN architecture should support an end-to-end
Quality of Service (QoS) requirement. Also, backhaul communication protocols should be optimized
in E-UTRAN. QoS mechanism(s) should take into account the various types of traffic that exist to
provide efficient bandwidth utilization.
E-UTRAN should efficiently support various types of services, especially from the PS domain
(e.g. Voice over IP, Presence). The E-UTRAN should be designed in such a way as to minimize the
delay variation (jitter) for the TCP/IP packet communication.
Radio resource management
As mentioned earlier, the E-UTRAN RR management requires that: (1) an enhanced support for
end-to-end QoS is in place; (2) efficient support for transmission of higher layers is needed; and
(3) the support of load sharing and policy management across different Radio Access Technologies
is necessary.
Complexity issues
E-UTRA and E-UTRAN should satisfy the required performance. Additionally, system complexity
should be minimized in order to stabilize the system and interoperability in the earlier stages; it also serves to decrease the cost of terminal and UTRAN. To fulfill these requirements, the following points
should be taken into account.
To reduce the implementation complexity in both hardware and software, the design of E-UTRAN
networks should minimize the number of options, and also ensure the elimination of any redundant
mandatory features. It is also important to reduce the number of necessary test cases, for example,
to reduce the number of the states of protocols, minimize the number of procedures, appropriate
parameter range, and granularity.
The proposed E-UTRA/E-UTRAN requirements should minimize the complexity of the E-UTRA
UE in terms of size, weight, and battery life (standby and active), which should be consistent with
the provision of the advanced services of the E-UTRA/UTRAN. To satisfy these requirements, the
following factors should be taken into account:
• UE complexity in terms of its capability to support multi-RAT (GERAN/UTRA/E-UTRA)
should be considered when considering the complexity of E-UTRA features.
• The mandatory features should be kept to the minimum.
• There should be no redundant or duplicate specifications of mandatory features, for accomplishing
the same task.
• The number of options should be minimized. Sets of options should be realizable in terms
of separate distinct UE types/capabilities. Different UE types/capabilities should be used to
capture different complexity versus performance trade-offs, for instance, for the impact of
multiple antennae.
• The number of necessary test cases should be minimized so it is feasible to complete the
development of the test cases within a reasonable time frame after the Core Specifications are
completed.