755

Figure 13.2 The original IMT-2000 ‘core band’ spectrum allocations at 2 GHz.

13.1.3.1 Spectrum flexibility and deployment

The basis for the requirements on spectrum flexibility is the requirement for LTE to be deployed in existing IMT-2000 frequency bands, which implies coexistence with the systems that are already deployed in those bands, including WCDMA/HSPA and GSM. A related part of the LTE requirements in terms of spectrum flexibility is the possibility to deploy LTE-based radio access in both paired and unpaired spectrum allocations, that is LTE should support both Frequency Division Duplex (FDD), and Time Division Duplex (TDD).

The duplex scheme or duplex arrangement is a property of a radio access technology. However, a given spectrum allocation is typically also associated with a specific duplex arrangement. FDD systems are deployed in paired spectrum allocations, having one frequency range intended for downlink transmission and another for uplink transmission. TDD systems are deployed in unpaired spectrum allocations.

An example is the IMT-2000 spectrum at 2 GHz, that is, the IMT-2000 ‘core band’. As shown in Figure 13.2, it consists of the paired frequency bands 1920– 1980 MHz and 2110–2170 MHZ intended for FDD-based radio access, and the two frequency bands 1910–1920 MHz and 2010–2025 MHz intended for TDDbased radio access. Note that through local and regional regulation the use of the IMT-2000 spectrum may be different than what is shown here.

The paired allocation for FDD in Figure 13.2 is 2 × 60 MHz, but the spectrum available for a single operator may be 2 × 20 MHz or even 2 × 10 MHz. In other frequency bands even less spectrum may be available. Furthermore, the migration of spectrum currently used for other radio access technologies must often take place gradually to ensure that sufficient amount of spectrum remains to support the existing users. Thus the amount of spectrum that can initially be migrated to LTE may be relatively small, but may then gradually increase, as shown in Figure 13.3. The variation of possible spectrum scenarios will imply a requirement for spectrum flexibility for LTE in terms of the transmission bandwidths supported.

15 MHz of spectrum

Original deployment

A 5 MHz LTE carrier

Initial migration

A 10 MHz LTE carrier

Second step

A 15 MHz LTE carrier

Complete migration

Figure 13.3 Example of how LTE can be migrated step-by-step into a spectrum allocation with an original GSM deployment.

The spectrum flexibility requirement points out the need for LTE to be scalable in the frequency domain and operate in different frequency bands. This flexibility requirement is in [86] stated as a list of LTE spectrum allocations (1.25, 1.6, 2.5, 5, 10, 15 and 20 MHz). Furthermore, LTE should be able to operate in unpaired as well as paired spectrum. LTE should also be possible to deploy in different frequency bands. The supported frequency bands should be specified based on ‘release independence,’ which means that the first release of LTE does not have to support all bands from the start.

Furthermore, [86] also addresses coexistence and cositing with GSM and WCDMA on adjacent frequencies, as well as coexistence between operators on adjacent frequencies and networks in different countries using overlapping spectrum. There is also a requirement that no other system should be required in order for a terminal to access LTE, that is, LTE is supposed to have all the necessary control signaling required for enabling access.

13.1.4Architecture and migration

A few guiding principles for the LTE RAN architecture design as stated by 3GPP are listed in [86]:

•A single LTE RAN architecture should be agreed.

•The LTE RAN architecture should be packet based, although real-time and conversational class traffic should be supported.

mandatory features. This also leads to a minimized number of necessary test cases.

13.1.7General aspects

The section covering general requirements on LTE address the costand servicerelated aspects. Obviously, it is desirable to minimize the cost while maintaining the desired performance for all envisioned services. Specific to the cost, the backhaul and operation and maintenance is addressed. Thus not only the radio interface, but also the transport to the base-station sites and the management system should be addressed by LTE. A strong requirement on multi-vendor interfaces also falls into this category of requirements. Furthermore, low complexity and low power consuming mobile terminals are required.

13.2SAE design targets

The SAE objectives were outlined in the study item description of SAE, and some very high-level targets are set in [88] produced by TSG SA WG1. The SAE targets are divided into several areas:

•high-level user and operational aspects,

•basic capabilities,

•multi-access and seamless mobility,

•man–machine interface aspects,

•performance requirements for the evolved 3GPP system,

•security and privacy, and

•charging aspects.

Although the SAE requirements are many and split into the subgroups above, the SAE requirements are mainly non-radio access related. Thus, this section tries to summarize the most important SAE requirements that have an impact on either the radio access network or the SAE architecture.

The SAE system should be able to operate with more than the LTE radio access network and there should be mobility functions allowing a mobile terminal to move between the different radio access systems. In fact, the requirements do not limit the mobility between radio access networks, but opens up for mobility to fixed-access network. The access networks need not to be developed by 3GPP, other non-3GPP access networks should also be considered.

As always in 3GPP, roaming is a very strong requirement for SAE, including inbound and outbound roaming to other SAE networks and legacy networks.

Furthermore, interworking with legacy packet-switched and circuit-switched services is a requirement. However, it is not required to support the circuit switched services from the circuit-switched domain of the legacy networks.

The SAE requirements also list performance as an essential requirement but do not go into the same level of details as the LTE requirements. Different traffic scenarios and usage are envisioned, for example user to user and user to group communication. Furthermore, resource efficiency is required, especially radio resource efficiency (cf. spectrum efficiency requirement for LTE). The SAE resource efficiency requirement is not as elaborated as the LTE requirement. Thus it is the LTE requirement that is the designing requirement.

Of course, the SAE requirements address the service aspects and require that the traditional services such as voice, video, messaging, and data file exchange should be supported, and in addition multicast and broadcast services. In fact, with the requirement to support IPv4 and IPv6 connectivity, including mobility between access networks supporting different IP versions as well as communication between terminals using different versions, any service based on IP will be supported, albeit perhaps not with optimized quality of service.

The quality of service requirement of SAE is well elaborated upon in [88]. The SAE system should for example, provide no perceptible deterioration of audio quality of a voice call during and following handover between dissimilar circuitswitched and packet-switched access networks. Furthermore, the SAE should ensure that there is no loss of data as a result of a handover between dissimilar fixed and mobile access systems. A particular important requirement for the SAE QoS concept is that the SAE QoS concept should be backwards compatible with the pre-SAE QoS concepts of 3GPP. This is to ensure smooth mobility between different 3GPP accesses (LTE, WCDMA/HSPA and GSM).

The SAE system should provide advanced security mechanisms that are equivalent to or better than 3GPP security for WCDMA/HSPA and GSM. This means that protection against threats and attacks including those present on the Internet should be part of SAE. Furthermore, the SAE system should provide information authenticity between the mobile terminal and the network, but at the same time enable lawful interception of the traffic.

The SAE system has strong requirements on user privacy. Several levels of user privacy should be provided, for example communication confidentiality, location privacy, and identity protection. Thus, SAE-based systems will hide the identity of the users from unauthorized third parties, protect the content, origin and destination of a particular communication from unauthorized parties, and protect the

location of the user from unauthorized parties. Authorized parties are normally government agencies, but the user may give certain parties the right to know about the location of the mobile terminal. One example hereof is fleet management for truck dispatchers.

Several charging models, including calling party pays, flat rate, and charging based on QoS is required to be supported in SAE. Charging aspects are sometimes visible in the radio access networks, especially those charging models that are based on delivered QoS or delivered data volumes. However, most charging schemes are only looking at information available in the core network.

users. This is similar to the approach taken in HSDPA, although the realization of the shared resource differ between the two – time and frequency in case of LTE and time and channelization codes in case of HSDPA. The use of shared-channel transmission is well matched to the rapidly varying resource requirements posed by packet data and also enables several of the other key technologies used by LTE.

The scheduler controls, for each time instant, to which users the shared resources should be assigned. It also determines the data rate to be used for each link, that is rate adaptation can be seen as a part of the scheduler. The scheduler is a key element and to a large extent determines the overall downlink performance, especially in a highly loaded network. Both downlink and uplink transmissions are subject to tight scheduling. From Chapter 7 it is well known that a substantial gain in system capacity can be achieved if the channel conditions are taken into account in the scheduling decision, so-called channel-dependent scheduling. This is exploited already in HSPA, where the downlink scheduler transmits to a user when its channel conditions are advantageous to maximize the data rate, and is, to some extent, also possible for the Enhanced Uplink. However, LTE has, in addition to the time domain, also access to the frequency domain, due to the use of OFDM in the downlink and DFTS–OFDM in the uplink. Therefore, the scheduler can, for each frequency region, select the user with the best channel conditions. In other words, scheduling in LTE can take channel variations into account not only in the time domain, as HSPA, but also in the frequency domain. This is illustrated in Figure 14.1.

The possibility for channel-dependent scheduling in the frequency domain is particularly useful at low terminal speeds, in other words when the channel is varying slowly in time. As discussed in Chapter 7, channel-dependent scheduling relies on channel-quality variations between users to obtain a gain in system capacity. For delay-sensitive services, a time-domain only scheduler may be forced to schedule a particular user, despite the channel quality not being at its peak. In such situations, exploiting channel-quality variations also in the frequency domain will help improving the overall performance of the system. For LTE, scheduling decisions can be taken as often as once every 1 ms and the granularity in the frequency domain is 180 kHz. This allows for also relatively fast channel variations to be tracked by the scheduler.

14.2.1Downlink scheduling

In the downlink, each terminal reports an estimate of the instantaneous channel quality to the base station. These estimates are obtained by measuring on a reference signal, transmitted by the base station and used also for demodulation purposes. Based on the channel-quality estimate, the downlink scheduler can