400 E-UTRAN: 3GPP’S EVOLUTIONAL PATH TO 4G (RR) specifications in the Universal Terrestrial Radio Access Network (UTRAN); the specification of the access network interfaces (Iu, Iub, and Iur); the definition of the Operations and Maintenance (O&M) requirements in UTRAN and conformance testing for the Base Stations. 10.2 Origin of E-UTRAN At the 3GPP TSG RAN #26 meeting, the Study Item description on “Evolved UTRA and UTRAN” was approved [815]. It is noted that all 3GPP TSG RAN meetings after the #26 meeting have been called 3GPP TSG RAN (new) meetings. The justification of the Study Item was that with enhancements such as HSDPA and HSUPA, the 3GPP radio-access technology will be highly competitive for several years. However, to ensure competitiveness in an even longer time frame, that is, for the next 10 years and further, a long-term evolution of the 3GPP radio-access technology needs to be considered. Important parts of such a long-term evolution include reduced latency, higher user data rates, improved system capacity and coverage, and reduced cost for the operator. In order to achieve this, an evolution of the radio interface as well as the radio network architecture should be considered. Considering a desire for even higher data rates and also taking into account future additional 3G spectrum allocations, the long-term 3GPP evolution should include an evolution toward support for wider transmission bandwidth than 5 MHz. At the same time, support for transmission bandwidths of 5 MHz and less than 5 MHz should also be investigated in order to allow for more flexibility in whichever frequency bands the system may be deployed. 3GPP work on the Evolution of the 3G Mobile System started with the RAN Evolution Work- shop, held from 2–3 November 2004 in Toronto, Canada. The Workshop was open to all interested organizations and members and nonmembers of 3GPP. Operators, manufacturers, and research insti- tutes presented more than 40 contributions with views and proposals on the evolution of the UTRAN. A set of high-level requirements were identified in the Workshop including: (1) Reduced cost per bit, (2) Increased service provisioning – more services at a lower cost with better user experience, (3) Flexibility of use of existing and new frequency bands, (4) Simplified architecture, Open inter- faces, and (5) Agreement toward reasonable terminal power consumption. It was also recommended that the Evolved UTRAN should bring significant improvements to justify the standardization effort and it should avoid unnecessary options. In a certain light, the collaboration with 3GPP SA WGs was found a must with regards to the new split between the Access Network and the Core, and the characteristics of the throughput that new services would require. With the conclusions of this Workshop and with broad support from 3GPP members, a feasibility study on the UTRA and UTRAN Long-Term Evolution was started in December 2004. The objective was to develop a framework for the evolution of the 3GPP radio-access technology toward a high- data–rate, low-latency and packet-optimized radio-access technology. The study should be completed by June 2006 (at the time when this book is finished, it seems that this deadline for final E-UTRAN standard is likely to be postponed), with the selection of a new air-interface and the layout of the new architecture. At that point, Work Items will be created to introduce the E-UTRAN in 3GPP Work Plan. 10.3 General Features of E-UTRAN The study being carried out under the 3GPP Work 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 E-UTRAN: 3GPP’S EVOLUTIONAL PATH TO 4G 401 bandwidth up to 20 MHz, and new transmission schemes and advanced multiantenna technolo- gies; (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 indi- vidually 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 E- UTRAN (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. 402 E-UTRAN: 3GPP’S EVOLUTIONAL PATH TO 4G Figure 10.3 An example of state transition in E-UTRAN architecture. 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 E-UTRAN: 3GPP’S EVOLUTIONAL PATH TO 4G 403 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 main- tained 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. 404 E-UTRAN: 3GPP’S EVOLUTIONAL PATH TO 4G 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 schedul- ing 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 capabil- ity 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. E-UTRAN: 3GPP’S EVOLUTIONAL PATH TO 4G 405 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 archi- tecture, 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 406 E-UTRAN: 3GPP’S EVOLUTIONAL PATH TO 4G 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 accom- plishing 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. 10.4 E-UTRAN Study Items The E-UTRAN WGs have dedicated normal meeting times to the Evolution activity, as well as separate Ad Hoc meetings. RAN WG1 held one of these Ad Hoc meetings on June 20–21, 2005 (3GPP TSG RAN WG1 Ad Hoc on UTRA/UTRAN LT evolution, held in Sophia Antipolis, France), where it started looking at, and evaluating new air-interface schemes. A set of six basic layer 1 or physical layer proposals were then agreed for further study, which included the following: • FDD UL based on SC-FDMA, FDD DL based on OFDMA • FDD UL based on OFDMA, FDD DL based on OFDMA • FDD UL/DL based on MC-WCDMA • TDD UL/DL based on MC-TD-SCDMA • TDD UL/DL based on OFDMA • TDD UL based on SC-FDMA, TDD DL based on OFDMA. The evaluations of these technologies against the requirements for the physical layer are collected in TR25.814 [818]. The TSG RAN WG2 has also organized the first meeting to propose and discuss the air-interface protocols of the Evolved UTRAN [819]. Although the details of these are very dependent on the solutions chosen for the physical layer, some assumptions, and agreements have been taken, which are summarized as follows: • Simplification of the protocol architecture and the actual protocols is necessary. E-UTRAN: 3GPP’S EVOLUTIONAL PATH TO 4G 407 • There should be no dedicated channels, and so they form a simplified Medium Access Control (MAC) layer (without MAC-d entity). • A debate over Radio Resource Control (RRC) was held. It is generally supported that it should be simplified and have less states. The location of its functions is open. • Currently, there are very similar functions in the Radio Network and the Core. This should be simplified. • Other open issues include: (1) Macro diversity. 1 (2) Security and ciphering; (3) Handover sup- port; and (4) Measurements. The TSG RAN WG3 (as shown in Figure 10.2, the fifth layer from the top in the second column from the left) is working closely with SA WG2 (as shown in Figure 10.2, the fourth layer from the top in the third column from the left) in the definition of the new E-UTRAN architecture. SA WG2 has started its own study for the System Architecture Evolution whose objective is to develop a framework for an evolution or migration of the 3GPP system to a higher-data-rate, lower-latency, and packet-optimized system that supports multiple RATs. The focus of this work will be on the PS domain with the assumption that voice services are supported in this domain. This study builds on the RAN Long-Term Evolution and on the All-IP Network work carried out in SA WG1, and a long list of open points that needed clarification were identified, which include the items stated below. First, how will we achieve mobility within the Evolved Access System? This issue is closely associated with the ways to overcome serious Doppler spread problems in a fast fading channel envi- ronment. As the allowed mobility supported in E-UTRAN will be higher than the 3GPP 3G system, this problem is very critical to the overall success of the E-UTRAN project. Then, is the Evolved Access System envisioned to work on new and/or existing frequency bands? As 3GPP UTRAN is working in 2 GHz carrier frequency bands with its bandwidth being 5 MHz, the E-UTRAN may not be suitable for its operation in the same 2 GHz band as WCDMA is. The main reason is that E-UTRAN can work on a much wider bandwidth (up to 20 MHz), and the existing bandwidth allocation at 2 GHz is already very crowded. The real situation could be different from country to country. As an example, the US radio spectrum allocation situation can be seen from Figure 9.1 [792]. The more frequently discussed issues in SA WG1 include the following: • Is connecting the Evolved RAN to the legacy PS core necessary? • How do we add support for non-3GPP Access Systems (ASs)? • WLAN 3GPP IP AS might need some new functionalities for Intersystem Mobility with the Evolved AS. • Clarify which interfaces are the roaming interfaces, and how roaming works in general. • The issues on inter-AS mobility should be discussed. • Possible difference between PCC functionalities, mainly stemming from the difference in how Inter-AS mobility is provided. • How do UEs discover ASs and corresponding radio cells? The options include autonomous per AS versus the UEs scans/monitors of any supported AS to discover systems and cells. Or, do ASs advertise other ASs to support UEs in discovering alternative ASs? How is such advertising performed (e.g. system broadcast, requested by UE, etc.)? How do these procedures impact battery lifetime? 1 General agreement is that it should be avoided in the DL design. 408 E-UTRAN: 3GPP’S EVOLUTIONAL PATH TO 4G G x Figure 10.4 The E-UTRAN Model architecture B1 for non-roaming scenario, where R1,R2andR are working names for reference points; G x + denotes evolved or extended G x ; PCRF1 represents evolved Policy and Charging Rules Function; the dash links and circles represent new functional elements/interfaces in E-UTRAN architecture. • In the case of ASs advertising other ASs: will any AS provide seamless coverage (avoiding the loss of network/network search), or is a hierarchy of ASs needed to provide seamless coverage for continuous advertisement? The two model architectures [820], which summarize the broad range of proposals that have been presented in several WG meetings, are shown in Figures 10.4 and 10.5. Note that the key difference in the two model E-UTRAN architectures lies in the way that intersystem mobility is achieved and managed, and thus the interactions among the E-UTRAN network and other 3GPP networks, such as UTRAN (based on WCDMA technology) and GERAN (based on GSM standard). 10.5 E-UTRAN TSG Work Plan As mentioned earlier, the E-UTRAN standardization process is still going on. Only some very general technical aspects have been agreed upon in the TSG RAN meetings, and even for them the subsequent meetings can revise them from time to time. So far, a detailed work plan of the aforementioned Study Items has been made by 3GPP and can be summarized in terms of the milestones per TSG RAN E-UTRAN: 3GPP’S EVOLUTIONAL PATH TO 4G 409 Figure 10.5 The E-UTRAN Model architecture B2, where R h provides functionality to prepare han- dovers so that interruption time is reduced. It is intended that this interface should be generic enough to cope with other combinations of RATs, for which handover preparation is needed. G x + denotes G x with added Inter-Access-System mobility support. W x + denotes W x with added Inter-Access- System mobility support. Inter-AS MM denotes Inter-Access-System Mobility Management. PCRF2 elements are drawn twice only for figure topology reasons. PCRF2 represents the evolved Policy and Charging Rules Function. The dash links and circles represent new functional elements/interfaces in E-UTRAN architecture. meetings. The work plan for SAE is included below by taking into account the time alignment between the LTE and SAE works. TSG RAN #28 meeting (June 2005, Quebec) • Revised Work plan; • Requirement TR Approved: (1) Deployment Scenarios included; (2) Requirements on Migra- tion Scenarios included. TSG RAN #29 meeting (September 2005, Tallin) Revised Work plan TSG RAN #30 meeting (December 2005, MT) • Revised Work plan; • Physical Layer basics: (1) Multiple access scheme; (2) Macro diversity or not. [...]... 15.36 MHz (4 × 3.84 MHz) 1024 601 23.04 MHz (6 × 3.84 MHz) 1536 90 1 30.72 MHz (8 × 3.84 MHz) 2048 1201 7/6 7/6 7/6 7/6 7/6 7/6 (4. 69/ 9) ×6, (5.21/10) ×1c (16.67/32) (4. 69/ 18) ×5, (4 .95 / 19) ×2 (16.67/64) (4. 69/ 36) ×3, (4.82/37) ×4 (16.67/128) (4.75/73) ×6, (4.82/74) ×1 (16.67/256) (4.73/1 09) ×2, (4.77/110) ×5 (16.67/384) (4.75/146) ×5, (4. 79/ 147) ×2 (16.67/512) FFT size Number of occupied subcarriersa... China Feb RAN 1,2,3,4 Joint, 7–11 Nov ASIA SA #30, 5–8 Dec, Malta SA2 #48 5 9 Sep, Sophia Antipolis RAN 1,2,3,4 29 Aug–2 Sep, London Sep SA1 # 29 11–15 Jul, Povoa de varzim Aug RAN # 29, 21–23 Sept, Tallin SA # 29, 26– 29 Sept, Tallin RAN 1,2,3,4+SA2 joint, 19 20 Sept, Tallin RAN-CN functional split tentative RAN 1,2,3,4+SA2 Joint, 29 Aug–2 Sept London RAN-CN functional split agreed May RAN 1,2,3,4 May, TBD... in the sequel Next Generation Wireless Systems and Networks Hsiao-Hwa Chen and Mohsen Guizani  2006 John Wiley & Sons, Ltd (B.2) 434 MAI IN ASYNCHRONOUS FLAT FADING UWB CHANNEL Figure B.1 This figure illustrates how to divide the integral given in Equation (7.17) into two sections, that is, (a) the integral section from 0 to τk ; (b) the integral section from τk to Tb , where ik = 3 and N = 7 are assumed... should also be considered; and (3) Realistic assumptions have to be taken into account when comparing different MIMO concepts, such as feedback errors and delays, which need to consider multiantenna reference signals overhead and its effect on performance, complexity, and signaling requirements, and so on The resulting reference signal and signaling overheads in both UL and DL have to be justified by... + + + + − + + + − − − − + − − + − − −) (+ + + − + + − + + + + − − − + − − − − + − − + − + + + − − − + −, + − + + + − − − + − + + − + + + − + − − − + + + + − + + − + + +) Next Generation Wireless Systems and Networks Hsiao-Hwa Chen and Mohsen Guizani  2006 John Wiley & Sons, Ltd ORTHOGONAL COMPLEMENTARY CODES (PG = 8 ∼ 512) 428 (2) Length of element codes = 16, flock size = 4 (+ + + + + − + − + + −... real valued symbols are then dephased, and are multiplied by i m+n before the inverse fast Fourier transform (IFFT) as shown in Figure 10 .9 E-UTRAN: 3GPP’S EVOLUTIONAL PATH TO 4G 4 19 Figure 10 .9 The OFDM/OQAM signal generation process for the FDD OFDMA downlink scheme in E-UTRAN architecture The main difference between OFDM/OQAM and conventional OFDM signal generation lies in the filtering by the prototype... Revised work plan TSG RAN #32 meeting (May 31–June 2, 2006, Poland) • RAN TR25 .91 2 ready for approval: (1) TR has its level of details at stage 2 and this is necessary for the smooth transition to Work Item phase; (2) The TR should include performance assessments, UE capabilities, and system and terminal complexities • Mobility between 3GPP and non-3GPP accesses • QoS concept • MBMS architecture • Documentation... frequency dependent scheduling and link adaptation These pilots span a larger bandwidth than the one used for data transmission Note that in-band pilots may also be used for frequency dependent scheduling and link adaptation It was suggested that orthogonal in-band pilot (IBP) symbol patterns are needed in the following cases: (1) If a UE transmits on two antennae (Antenna A and Antenna B) as in the case... schemes, the transmission bandwidth may vary in terms of different numbers of OFDM subcarriers Multiplexing and pilot structure Two types of pilot symbols should be considered, including: (1) in band pilots, which are used for coherent data demodulation, for example, channel estimation These pilots are transmitted in the part of the bandwidth used for data transmission; (2) out of band pilots, which are... related to E-UTRA/UTRA/GSM • States and state transitions: (1) Final state model; (2) State transition between E-UTRA and UTRA/GERA • Intra E-UTRA and E-UTRA-UTRA/GSM mobility in Active and Idle modes: (1) Mobility concept including measurements and signaling; (2) Interruption time node and interface budget • Service Requirements: (1) Are there any legacy service requirements that are obsolete? Or are . of occupied subcarriers a 76 151 301 601 90 1 1201 Number of OFDM symbols per subframe (Short / Long CP) 7/6 7/6 7/6 7/6 7/6 7/6 CP length b Short (4. 69/ 9) ×6, (5.21/10) ×1 c (4. 69/ 18) ×5, (4 .95 / 19) ×2 (4. 69/ 36) ×3, (4.82/37) ×4 (4.75/73) ×6, (4.82/74) ×1 (4.73/1 09) ×2, (4.77/110) ×5 (4.75/146) ×5, (4. 79/ 147) ×2 Long. 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”. 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