B.2 Void

36.3003GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN)Overall descriptionRelease 17Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

Annex C (informative):
Void

Annex D (informative):
Void

Annex E (informative):
Void

Annex F (informative):
Void

Annex G (informative):
Guideline for E-UTRAN UE capabilities

Each radio access technology has defined specific "classes" of terminals in terms of radio capabilities. E.g. in GPRS the "multislot classes" are defined, in UMTS R’99 different dedicated bearer classes are defined and for HSDPA and HSUPA 12 respectively 6 physical layer categories are defined. The definition of UMTS R’99 UE classes lead to 7 DL classes and 7 UL classes for FDD out of which only 2 DL and 3 UL classes were commercially realized. Furthermore the lower end classes (e.g. 64 UL and 64 DL) disappeared from the market with commercialization of the UMTS networks quite soon. Besides these class definitions a huge number of possible parameter combinations (to achieve certain data rates) exist with UMTS R’99 which lead to the huge number of RAB and RB combinations defined. Further activities in the early phase of UMTS standardization aimed to reduce the number of possible combinations significantly.

For HSDPA two "simple" DL categories (11 & 12) with lowered complexity were defined with the intent to speed up commercialization of HSDPA. Originally those categories should have been removed for Rel-6. Out of the 12 defined categories only approx. 4 will be realized in commercial HSDPA platform products. A similar situation is likely for HSUPA as well as for the combinations of HSDPA/HSUPA.

Generally the aim to mandate certain essential functions/requirements can help to simplify the system definition as well as the realization options (e.g. mandating 20 MHz of DL reception as well as 20 MHz UL transmission bandwidth significantly reduced the E-UTRAN system complexity). Especially mandating certain terminal functions could be useful for the system design if a defined subset of parameter combinations are also supported by the systems, e.g. the eNB scheduler. However, there is also a risk that not all the defined E-UTRA features are deployed in the networks at the time when terminals are made commercially available on the market place. Some features are likely to be rather large and complex, which further increases the risk of interoperability problems unless these features have undergone sufficient interoperability testing (IOT) on real network equipment, and preferably with more than one network in order to improve the confidence of the UE implementation. Thus, avoiding unnecessary UE mandatory features but instead defining a limited set of UE radio classes allows simplification for the interoperability testing.

Given the discussion above, it seems beneficial for the introduction of E-UTRAN to limit the combination of radio capabilities to a clearly defined subset and ensure that a given set of parameters is supported by certain UE classes as well as networks for rapid E-UTRAN deployment. It seems unrealistic to mandate only one single UE class which always mandates the maximum capability.

In order to address the different market requirements (low end, medium and high end), the definition of the following UE classes are proposed:

Table G-1: E-UTRAN UE Classes

Class	UL	DL
A	[50] Mbps	[100] Mbps
B	[25] Mbps	[50] Mbps
C	[2] Mbps	[2] Mbps

NOTE: For simplification reasons, the table only depict the UE capabilities in terms of uplink and downlink peak data rates supported. However, it should be noted that further discussion on other features is expected once the work progresses.

It may require further discussion whether there be a need for an additional terminal class between 2 Mbps and 50 Mbps classes. It might make sense, since up to 5 MHz band allocations may be rather common in real deployments for several years. This would point to bit rate class of 25 Mbps in DL and 10 Mbps in UL.

The above given data rates are indicative and should be subject for further discussions in 3GPP RAN working groups. Depending on the different solutions to reach those data rates, the target should be to define [3..4] UE classes in different data rate ranges, and other parameters affecting device complexity and cost. The definition of the required parameters/features is for further study for each of the classes. For instance, half-duplex UEs form a specific category that may be frequency band specific.

NOTE: the support of half-duplex UEs is mandatory for the eNB where such a category is allowed in the frequency band supported by the eNB.

The aim is to ensure on the one hand that high end E-UTRAN UEs, supporting data rates representing state of the art level and competitive with other radio technologies are defined, while the medium and lower data rates aim to reduce implementation cost for chipset/terminal vendors and allow adoption of most cost efficient solutions for different market segments. It is expected that the support of the high end data rate terminals is ensured from the very beginning.

Another clear exception from this exercise is that on the low end very cheap product implementation is possible (e.g. for the machine-to-machine market or the voice and very low data rate only segment – to substitute GSM in the medium term) while top end performance is needed for data applications in notebooks, wireless gateways ("wireless DSL"), etc.

Another important aspect that must be ensured is that a higher capability UE can be treated in exactly the same way as for a lower capability UE, if the network wishes to do so, e.g., in case the network does not support some higher capability features. In HSDPA, there have been problems in this respect due to 2-stage rate matching in HARQ. Such problems should be avoided in E-UTRAN, and E-UTRAN UE capabilities should provide the compatibility to ease implementation and interoperability testing.

Annex H (informative):
Void

Annex I (informative):
SPID ranges and mapping of SPID values to cell reselection and inter-RAT/inter frequency handover priorities

This Annex defines two ranges of SPID (Subscriber Profile ID for RAT/Frequency Priority) values, respectively Operator Specific and Reference values. The mapping at eNB of Reference SPID values to cell reselection and inter-RAT/inter frequency handover priorities is defined.