Professional Documents
Culture Documents
0 (2001-03)
Technical Report
3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRA TDD Low Chip Rate Option; Radio Protocol Aspects (Release 4)
The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.
Release 4
Keywords
UMTS, radio, protocol
Internet
http://www.3gpp.org
Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media.
2001, 3GPP Organizational Partners (ARIB, CWTS, ETSI, T1, TTA, TTC). All rights reserved.
3GPP
Release 4
Contents
Foreword ............................................................................................................................................................5 1 2 3
3.1 3.2
4 5
5.1 5.2
Background and Introduction...................................................................................................................8 Overview of Physical Layer of TDD Low Chip Rate Option ..................................................................8
Frame structure........................................................................................................................................................ 8 Burst Types ............................................................................................................................................................. 9
6
6.1 6.2 6.3
Services and Functions of the Physical Layer of 1.28 Mcps TDD ........................................................10
General .................................................................................................................................................................. 10 Overview of L1 functions...................................................................................................................................... 10 L1 interactions with L2 retransmission functionality ............................................................................................ 10
7
7.1 7.2
8
8.1 8.2
9
9.1 9.2
10
10.1 10.2 10.3 10.3.1 10.4
11
11.1 11.2 11.2.1 11.2.2 11.3 11.3.1 11.3.2 11.3.3 11.3.4 11.3.5 11.3.5.1 11.3.5.2 11.3.5.3 11.3.5.4
12
12.1 12.1.1 12.1.1 12.2 12.3
3GPP
Release 4
12.4
13
13.1 13.2 13.3 13.3.1 13.3.1.1 13.3.1.2 13.3.2 13.3.2.1 13.3.2.2 13.3.2.3 13.3.2.4 13.3.2.5 13.3.2.6 13.3.2.7 13.3.2.8 13.3.3 13.3.3.1 13.3.3.2 13.3.3.3 13.3.3.4 13.3.3.5 13.3.3.6 13.3.3.7 13.3.4
14
14.1 14.1.1 14.1.2 14.1.3 14.1.4 14.2
15
15.1 15.2 15.2.1 15.2.2 15.3 15.4 15.4.1 15.4.2 15.4.3 15.5 15.6
16
16.1 16.2 16.3 16.4 16.5
17
Recommendations ..................................................................................................................................37
3GPP
Release 4
Foreword
This Technical Report has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document.
3GPP
Release 4
Scope
The present document describes the services provided by the physical layer and the layer 2/3 functionality for support of the 1.28 Mcps low chip rate option of UTRA TDD. Based on the protocol structure existing for UTRA TDD / FDD, it is identified which modifications will be required in order to enable the layer 1 characteristics and key features of the low chip rate option.
References
References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] 3GPP TS 25.928: "1.28 Mcps functionality for UTRA TDD Physical Layer". 3GPP TS 25.302: "Services provided by the Physical Layer". 3GPP TR 25.990: "Vocabulary for the UTRAN". 3GPP TS 25.321: "MAC Protocol Specification". 3GPP TS 25.331: "RRC Protocol Specification". 3GPP TR 25.921: "Guidelines and Principles for protocol description and error handling". 3GPP TS 25.222: "Multiplexing and Channel Coding (TDD)". 3GPP TS 25.304: "UE Procedures in Idle Mode and Procedures for Cell Reselection in Connected Mode". 3GPP TS 25.212: "Multiplexing and Channel Coding (FDD)". 3GPP TS 25.215: "Physical Layer Measurements (FDD)". 3GPP TS 25.223: "Spreading and modulation (TDD)".
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
3
3.1
For the purposes of the present document, the terms and definitions given in [3] apply.
3.2
AC ASC BCCH
Abbreviations
Access Class Access Service Class Broadcast Control Channel
For the purposes of the present document, the following abbreviations apply:
3GPP
Release 4
BCH BMC CCCTrCH CN DCCH DCH DL DSCH DwPTS FACH FDD FPACH GP HO ITU kbps L1 L2 L3 MAC P-CCPCH PCH PDCP PDSCH PHY PhyCH PICH P-RACH PUSCH RAB RACH RB RLC RNC RNS RNTI RRC RSCP Rx SAP S-CCPCH SCH SIR SRNC SRNS SS TDD TFCI TFI TPC Ts Tx UUE UL UMTS UpPTS USCH UTRA UTRAN
Broadcast Channel Broadcast/Multicast Control ControlCoded Composite Transport Channel Core Network Dedicated Control Channel Dedicated Channel Downlink Downlink Shared Channel Downlink Pilot Timeslot Forward Link Access Channel Frequency Division Duplex Fast Physical Access Channel Guard Period Handover International Telecommunication Union kilo-bits per second Layer 1 (physical layer) Layer 2 (data link layer) Layer 3 (network layer) Medium Access Control Primary Common Control Physical Channel Paging Channel Packet Data Convergence Protocol Physical Downlink Shared Channel Physical layer Physical Channels Paging Indicator Channel Physical Random Access Channel Physical Uplink Shared Channel Radio Access Bearer Random Access Channel Radio Bearer Radio Link Control Radio Network Controller Radio Network Subsystem Radio Network Temporary Identity Radio Resource Control Received Signal Code Power Receive Service Access Point Secondary Common Control Physical Channel Synchronization Channel Signal to Interference Ratio Serving Radio Network Controller Serving Radio Network Subsystem Synchronization Shift Time Division Duplex Transport Format Combination Indicator Transport Format Indicator Transmit Power Control Timeslot Transmit UserUser Equipment Uplink Universal Mobile Telecommunications System Uplink Pilot Timeslot Uplink Shared Channel UMTS Terrestrial Radio Access UMTS Terrestrial Radio Access Network
3GPP
Release 4
TDD low chip rate option is a Release 4 work item that was agreed in RAN#7 plenary meeting. This work item involves the introduction of functionality to enable the physical layer structure of TDD low chip rate option within the existing UTRA layers. This report identifies the required modifications within the UTRA layers 2/3. Basically, the layer 2/3 services and functions need not be changed. Emphasis must be put on the fact that it is tried to reuse existing functionality as much as possible for enabling the TDD low chip rate option. Addition or modification of some elements or parameters in comparison with the existing layer 2/3 will however be needed due to the specific physical layer structure and key features of the TDD low chip rate option and the aim of this report is to show where this is the case.
This clause contains some basic information about frame and burst structure of physical layer of TDD low chip rate option. More information on physical layer characteristics of TDD low chip rate option can be found in [1].
5.1
Frame structure
For low chip rate option, the frame length is 10ms and the 10ms frame is divided into 2 sub-frames of 5ms. The frame structure for each sub-frame in the 10ms frame length is the same. The frame structure for each sub-frame is shown in Figure 1.
Subframe 5ms (6400chip) Switching Point 1.28Mchip/s Ts0 Ts1 Ts2 Ts3 Ts4 Ts5 Ts6
DwPTS (96chips)
GP (96chips)
UpPTS (160chips)
Switching Point
Figure 1: Structure of the sub-frame for TDD low chip rate option Tsn (n from 0 to 6): the nth normal time slot, 864 chips duration; DwPTS: downlink pilot time slot, 96 chips duration; UpPTS: uplink pilot time slot, 160 chips duration; GP: main guard period for TDD operation, 96 chips duration; In Figure 1, the total number of normal traffic time slots for uplink and downlink is 7, and the length for each normal time slot is 864 chips duration. Among the 7 normal traffic time slots, Ts0 is always allocated as downlink while Ts1 is always allocated as uplink. The time slots for the uplink and the downlink are separated by a switching point. Between the downlink time slots and uplink time slots, the special period is the switching point to separate the uplink and downlink. In each sub-frame of 5ms for low chip rate option, there are two switching points (uplink to downlink and vice versa). The proposed frame structure has taken some new technologies into consideration, both the smart antenna (beam forming) technology and the uplink synchronisation will be well supported.
3GPP
Release 4
5.2
Burst Types
In correspondence to the frame structure described above, the burst structures for Tsn, DwPTS and UpPTS are proposed. The burst structure for normal time slot (Tsn) is described in Figure 2.
GP 16 CP
Figure 2: Burst structure for normal traffic time slot The structure for DwPTS and UpPTS is described in Figure 3 and Figure 4.
75us GP(32chips) SYNC(64chips)
125us
SYNC1(128chips)
GP(32chips)
Figure 4: Structure for UpPTS In Figure 2, the data symbols in each side of the midamble are 352 chips. The TPC bits for power control, the TFCI bits and the additional uplink synchronization bits (synchronization shift) are included in the Data symbols fields of the burst if they are needed. The amount of TFCI bits used is depending on the service and the details for TFCI, synchronization shift and TPC bits should be provided later with service mapping. For the power control symbols, the uplink synchronization control symbols and the TFCI the symbols around the midamble are used. The GP field in Figure 2 for each time slot is used for protection between time slots to avoid the long delay multi-path interference. It should be noted that the GP of the TS0 together with the guard period in DwPTS is 48 chips long which is different with other normal guard period of 16 chips between time slots. This 'super long' guard period can be used to avoid the interference between the last normal downlink time slot and the downlink synchronization pilot burst. Otherwise, the interference to the last downlink time slot from the strong powered pilot will be serious to the traffic; and vice versa, the interference to the downlink pilot burst from the last downlink time slot will decrease the performance on downlink synchronization and cell search. Note that if the UEs serving Node B is far away and the UE makes handover measurements it will receive the beginning of the DwPTS of a close by Node B inside these 48 chips. 48 chips correspond to 11 km difference in distance to the Node B. If the other Node B is more distant to the serving Node B, big guard period can be used for receiving the DwPTS of the handover candidate Node B. In DwPTS and UpPTS, the content of SYNC and SYNC1 field are used for downlink and uplink pilot. The GP fields are used to separate the downlink (uplink) pilot from the normal downlink (uplink) time slot. It should be pointed out that the uplink synchronization burst (SYNC1) is not followed by a RACH immediately. First the UL synchronization burst is sent by the UE in UpPTS. This SYNC1 is used for Node B to determine the received power level and the received timing. Second, the Node B transmits timing and power control information to the UE using the FPACH (one burst message) within the next 4 frames. Then the P-RACH is transmitted. Both FPACH and PRACH are carrying single burst messages transmitted on a normal traffic time slot (see Figure 2).
3GPP
Release 4
10
6
6.1
No modifications for UTRA 1.28Mcps TDD are required according to subclause 5.1 in [2].
6.2
Overview of L1 functions
No modifications for UTRA 1.28Mcps are required according to subclause 5.2 in [2].
6.3
No modifications for UTRA 1.28Mcps TDD are required according to subclause 5.3 in [2].
7
7.1
No modifications for UTRA TDD low chip rate option are required compared to UTRA TDD 3.84 Mcps.
7.2
Downlink models
No modifications for UTRA TDD low chip rate option are required compared to UTRA TDD 3.84 Mcps.
8
8.1
The transport channel concept for UTRA TDD low chip rate option is the same as for UTRA TDD 3.84 Mcps as defined in [2].
8.2
-
Common transport channel types are the same as for UTRA TDD 3.84 Mcps. Details of operation on RACH and FACH are f.f.s, e.g., power control. RACH and FACH are characterized as follows: 1. Random Access Channel(s) (RACH) characterised by: existence in uplink only; limited data field;
3GPP
Release 4
11
2. Forward Access Channel(s) (FACH) characterised by: existence in downlink only; possibility to use beam forming; power control; possibility to change rate fast (each 10ms).
The shared channels USCH and DSCH are used in the same way as for UTRA TDD 3.84 Mcps. Dedicated transport channel types are the same as for UTRA TDD 3.84 Mcps. For TDD low chip rate option, DCH has the possibility to use Uplink Synchronisation to maintain timing advance: 1. Dedicated Channel (DCH) characterised by: existing in uplink or downlink; possibility to use beam forming; possibility to change rate fast (each 10ms); fast power control; Possibility to use Uplink Synchronisation.
3GPP
Release 4
12
9
9.1
The table addresses the possible combinations of 1.28 Mcps TDD physical channels that can be supported in the uplink by one UE simultaneously on the same frequency in the TDD 1.28 Mcps option in any one 5 ms subframe. In 1.28Mcps TDD a physical channel corresponds to one code, one timeslot, one frequency. Table 1: 1.28 Mcps TDD Uplink
Physical Channel Combination 1 2 3 UpPCH PRACH UpPCH + One DPCH Transport Channel Combination Mandatory or dependent on UE radio access capabilities Mandatory Mandatory Mandatory Comment
UpPCH is used to establish the uplink synchronisation. One DPCH is needed as reference measurement channel. UpPCH transmission to target cell in case of handover. The maximum number of DCHs and the maximum channel bit rate are dependent on UE radio access capabilities This combination is required for the reference measurement channel. The maximum number of DCHs, the maximum number of CCTrCH and the maximum channel bit rate are dependent on UE radio access capabilities. The maximum number of DCHs, the maximum number of CCTrCH and the maximum channel bit rate are dependent on UE radio access capabilities. This configuration is required for UE that operate shared channels and dedicated channels simultaneously. The maximum number of DCHs, the maximum number of CCTrCH and the maximum channel bit rate are dependent on UE radio access capabilities. This configuration is required for UE that operate shared channels and dedicated channels simultaneously. This configuration is required for UE that operate shared channels. This combination may be used for shared channel operation only. This combination may be used for shared channel operation only The maximum number of DCHs and the maximum channel bit rate are dependent on UE radio access capabilities. This configuration is required for UE that operate shared channels and dedicated channels simultaneously
One DPCH
Mandatory
RACH + one or more DCH coded into one or more than one CCTrCH
One or more PUSCH UpPCH + one or more PUSCH PRACH + one or more PUSCH One or more PUSCH + one or more DPCH
10
11
One or more USCH coded onto one or more CCTrCH One or more USCH coded onto one or more CCTrCH RACH + One or more USCH coded onto one or more CCTrCH One or more USCH coded onto one or more CCTrCH + one or more DCH coded onto one or more CCTrCH
Depending on UE radio access capabilities Depending on UE radio access capabilities Depending on UE radio access capabilities Depending on UE radio access capabilities
3GPP
Release 4 Physical Channel Combination 12 UpPCH + one or more PUSCH + one or more DPCH Transport Channel Combination
one or more USCH coded onto one or more CCTrCH + one or more DCH coded into one or more CCTrCH RACH + one or more USCH coded onto one or more CCTrCH + one or more DCH coded into one or more CCTrCH
13
The maximum number of DCHs and the maximum channel bit rate are dependent on UE radio access capabilities. This combination may be used for shared channel operation. The maximum number of DCHs and the maximum channel bit rate are dependent on UE radio access capabilities. This combination may be used for shared channel operation.
9.2
The table addresses the possible combinations of 1.28 Mcps TDD physical channels that can be supported in the downlink by one UE simultaneously on the same frequency in any one 5ms subframe. In 1.28Mcps TDD a physical channel corresponds to one code, one timeslot, one frequency. Depending on UE radio capabilities UEs may be required to occassionally decode P-CCPCH of its own cell in the following Physical Channel Combinations: 5, 11,12,13,14,15,16,17. To support handover it depends on UE capabilities if a UE can support the occasional decoding of neighbour cell PCCPCH in the physical channel combinations 8, 9, 10, 11, 15,16, 17
3GPP
Release 4
14
N/A
FPACH is used to answer the UE and to adjust the timing and synchronization shift of the UE
2 3 4 5 6 7
P-CCPCH S-CCPCH P-CCPCH +S-CCPCH More than one S-CCPCH PICH FPACH + PCCPCH + none, one or more SCCPCH 2 DPCH
BCH FACH or/and PCH BCH + (FACH or/and PCH) one or more FACH+ one ore more PCH N/A BCH + (none,one or more FACH+ none.one ore more PCH) One or more DCH coded into a single CCTrCH
Mandatory
10
The maximum number of DCH and the maximum channel bit rate are dependent on UE radio access capabilities This channel is used as reference measurement channel The maximum number of DCHs, the maximum number of CCTrCH and the maximum channel bit rate are dependent on UE radio access capabilities. FPACH is used to answer the UE and to adjust the timing and synchronization shift of the UE. The maximum number of DCHs, the maximum number of CCTrCH and the maximum channel bit rate are dependent on UE radio access capabilities. This configuration is required for UE that operate shared channels and dedicated channels simultaneously. The maximum number of DCHs, the maximum number of CCTrCH and the maximum channel bit rate are dependent on UE radio access capabilities. This configuration is required for UE that operate shared channels and dedicated channels simultaneously. This configuration is required for UE that operate shared channels. This configuration is desirable but not essential for UE supporting shared channels. This configuration is desirable but not essential for UE supporting shared channels.
11
(One or more FACH or/and PCH) + one or more DCH coded into one or more CCTrCH
12
One or more PDSCH FPACH + one or more PDSCH One or more SCCPCH +one or more PDSCH
13
14
One or more DSCH coded onto one or more CCTrCH One or more DSCH coded onto one or more CCTrCH (One or more FACH and/or PCH) + One or more DSCH coded onto one or more CCTrCH
Depending on UE radio access capabilities Depending on UE radio access capabilities Depending on UE radio access capabilities
3GPP
Release 4 Physical Channel Combination 15 One or more PDSCH + one or more DPCH Transport Channel Combination
One or more DSCH coded onto one or more CCTrCH + one or more DCH coded into one or more CCTrCH one or more DSCH coded onto one or more CCTrCH + one or more DCH coded into one or more CCTrCH
This configuration is required for UE that operate shared channels and dedicated channels simultaneously.
16
FPACH is used to answer the UE and to adjust the timing and synchronization shift of the UE. This configuration is desirable but not essential for UE supporting shared channels and dedicated channels simultaneously. This configuration is desirable but not essential for UE supporting shared channels and dedicated channels simultaneously.
17
(One or more FACH and/or PCH) + one or more DSCH coded onto one or more CCTrCH + one or more DCH coded into one or more CCTrCH
10
10.1
The model of physical layer measurements is common with 3.84 Mcps TDD.
10.2
UE Measurements
UE measurements specified for 3.84 Mcps TDD are also used in 1.28 Mcps TDD. Ranges and accuracy have to be adapted.
10.3
UTRAN Measurements
UTRAN measurements specified for 3.84 Mcps TDD are also used in 1.28 Mcps TDD. Ranges and accuracy have to be adapted.
10.3.1
10.4
The parameters currently specified for FDD compressed mode [10] [5] support the monitoring of 1.28 Mcps TDD cells.
3GPP
Release 4
16
The transmission gap pattern length is defined in frames. A frame length of 10ms consists of two 1.28 Mcps TDD subframes of 5ms length. Because it is not possible to shift the transmission gap in consecutive pattern repetitions, it is effective to search with an appropriately long gap. Using the double frame method [9] a transmission gap length of 14 slots is a suitable parameter setting. Therefore, this enables UEs in FDD mode to monitor 1.28 Mcps TDD cells by means of FDD compressed mode.
11
11.1
No modifications for UTRA TDD 1.28 Mcps are required compared to UTRA TDD 3.84 Mcps.
11.2
11.2.1
No modifications for UTRA TDD 1.28 Mcps are required compared to UTRA TDD 3.84 Mcps.
No modifications for UTRA TDD 1.28 Mcps are required compared to UTRA TDD 3.84 Mcps.
11.2.2
CONTROL PRIMITIVES
No modifications for UTRA TDD 1.28 Mcps are required compared to UTRA TDD 3.84 Mcps.
11.3
11.3.1
Parameter definition
Error code
No modifications for UTRA TDD 1.28 Mcps are required compared to UTRA TDD 3.84 Mcps.
11.3.2
Event value
No modifications for UTRA TDD 1.28 Mcps are required compared to UTRA TDD 3.84 Mcps.
11.3.3
-
Access Information
For the UTRA TDD 1.28 Mcps the access information options are: Ready for RACH data transmission (when Ack on FPACH has been received); No response received in FPACH while maximum number of synchronisation attempts has been performed.
11.3.4
No modifications for UTRA TDD 1.28 Mcps are required compared to UTRA TDD 3.84 Mcps.
11.3.5
In addition to the physical channels defined for UTRA TDD, three physical channels are added to support low chip rate TDD option, they are: DwPTS, UpPTS and FPACH. Besides, two physical channels, Primary SCH and Secondary SCH, are not needed in low chip rate TDD option.
3GPP
Release 4
17
Because there is only one burst type in low chip rate TDD option, "burst type" defined as a parameter for physical channel is not necessary. Due to the different RACH procedure of low chip rate TDD option, the Access Service Class selection applies to UpPTS, rather than PRACH (see subclause 14.1.4). Shared channels, PUSCH and PDSCH, will be supported by TDD low chip rate option, The added physical channels and the modifications for PRACH are described in the following:
11.3.5.1
-
DwPTS
11.3.5.2
-
UpPTS
SYNC1 code ID
11.3.5.3
-
FPACH
11.3.5.4
-
PRACH
Spreading factor for data part Power control info: UL target SIR Primary CCPCH DL TX power UL interference
12
12.1
12.1.1
MAC services to upper layers, logical channels and mapping between logical channels and transport channels are identical for UTRA TDD 3.84 Mcps and 1.28 Mcps.
3GPP
Release 4
18
12.1.1
MAC functions
12.2
No modifications for UTRA TDD low chip rate option are required compared to UTRA TDD 3.84 Mcps
12.3
No modifications for UTRA TDD low chip rate option are required compared to UTRA TDD 3.84 Mcps
12.4
No modifications for UTRA TDD low chip rate option are required compared to UTRA TDD 3.84 Mcps
13
13.1
Uu Stratum services are the same as for UTRA FDD / 3.84 Mcps TDD.
13.2
RRC functions
RRC functions for 1.28 Mcps TDD are common with 3.84 Mcps TDD, except for timing advance control which is maintained by L1 function Uplink Synchronization in 1.28 Mcps TDD.
13.3
13.3.1
1.28Mcps TDD and 3.84Mcps TDD are both based on CDMA with an additional TDMA component. The most obvious difference is of course the different bandwidth that is used in the both modes. While 3.84Mcps TDD uses a chiprate of 3.84 Mcps the chip rate of 1.28Mcps TDD is 1.28 Mcps. In contrast to 3.84Mcps TDD it is foreseen to be the normal case for 1.28Mcps TDD that several frequency bands are used within one cell. For example if a frequency band of 5 MHz is available it is divided into three frequency bands of 1.6 MHz to be used for 1.28Mcps TDD. Timing handling is a layer1 functionality due to the high accuracy requirements in 1.28Mcps TDD. Thus timing advance as an RRC functionality is not needed. Apart from these differences there is a high potential to reuse descriptions of physical channel information in3.84Mcps TDD for 1.28Mcps TDD mode.
13.3.1.1
-
Timeslot: The frame structure defines seven timeslots per subframe. The timeslots of the two subframes in a 10ms frame are always associated to each other (except for the FPACH; this will be described later). The first timeslot (TS0) in a subframe is always dedicated to the downlink and the second timeslot (TS1) is always dedicated to the uplink. Thus at most six timeslots may be allocated in one direction in contrast to fourteen in 3.84Mcps TDD. Channelisation code: The handling of channelisation codes is exactly the same as in 3.84Mcps TDD. Midamble shift: The handling of midambles (basic midamble code and applied midamble shift) is basically the same as in 3.84Mcps TDD. The basic midamble code is also acquired during synchronisation process and the
3GPP
Release 4
19
midamble shift is either explicitly signalled for a particular physical channel or a predefined association between channelisation codes and midamble shifts is used. This association is defined in WG1 specifications. Frame allocation: As an option the same multiframe structure (defined by an offset, repetition period and repetition length) as used in 3.84Mcps TDD can be adopted for 1.28Mcps TDD. Burst type: Only one burst type exists for 1.28Mcps TDD for traffic channels. Therefore no signalling of the used burst type is required. Modulation: The basic modulation scheme is the same as in 3.84Mcps TDD. However, in case of usage of spreading factor 1 optionally 8 PSK can be used in contrast to 3.84Mcps TDD.
13.3.1.2
Handling of coded composite transport channels of dedicated or shared type in 1.28Mcps TDD:
In 1.28Mcps TDD multiplexing chain defined in [7] can be adopted with minor modifications. These modifications require only changes that are of no importance for layer 2 and layer 3 (i.e. specification of mapping of bits on the two timeslots in the different subframes). Thus the required parameters for the specification of coded composite transport channels are the same as in 3.84Mcps TDD mode i.e. Multiple CCTrCHs: A list of up to 8 CCTrCHs can be configured. Thus an identifier for the CCTrCHs is required (TFCS Identity) 2nd interleaving mode: Whether the frame or timeslot related 2nd interleaving mode is used depends on the requirements. Same as in 3.84Mcps TDD mode. Puncturing limit: Dynamic rate matching is used both in uplink and downlink. Same as in 3.84Mcps TDD mode. TFCI coding: The channel coding can be adapted to the requirements. Same as in 3.84Mcps TDD mode. TFCI existence per timeslot: Depending on the requirements a TFCI may or may not be included in particular timeslots. Same as in 3.84Mcps TDD mode. Multiple timeslots per CCTrCH: A number of timeslots may be allocated for one CCTrCH. Same as in 3.84Mcps TDD mode. Channelisation codes: In downlink direction rather multicode configuration than variable codes can be configured. In uplink direction both multicode and variable spreading are supported. Same as in 3.84Mcps TDD mode. Time info: The concept of time limited channels can be adopted from 3.84Mcps TDD mode.
13.3.2
13.3.2.1
The random access procedure for 1.28Mcps TDD is described in detail in [1]. The SYNC1 code transmission is basically the contention based mechanism in 1.28Mcps TDD. Major similarities can be noticed between preamble transmissions in FDD and SYNC1 transmissions in 1.28Mcps TDD. Thus the parameters M (maximum number of SYNC1 transmissions) are broadcast as in FDD to control the RACH procedure. Additionally, a parameter defining the step sizes to be used for the power ramping for successive SYNC1 transmissions is proposed to be included. This gives operators further means to control the RACH procedure. There is essentially no difference between a PRACH compared to a DPCH since uplink synchronisation is already achieved with the help of the SYNC1 codes. Thus the only difference between the PRACH and the DPCH is that it is assigned to be part of the random access procedure. Since similar procedures are used for 1.28Mcps TDD as for 3.84Mcps TDD similar messages are send over the RACH transport channel. In principle the configuration of the PRACH can have the same flexibility as a DPCH.
3GPP
Release 4
20
The FPACH is a physical channel with similarities to the AICH in FDD. It carries only a small number of bits containing information to adjust the uplink transmissions (power control, synchronisation, ...). One FPACH transmission is only comprised of a single sub-frame. Due to the limited amount of required transmission capacity the FPACH uses only spreading factor 16. When sending a SYNC1 sequence, the UE knows which FPACH, PRACH and S-CCPCH resources will be used for the access. This information is provided in system information on BCCH. There is a predefined correspondence between a P-RACH and a FPACH, and an implicit correspondence between SYNC1 signatures and FPACHs, according to the following rule: FPACH/PRACH number = N mod M, where FPACH/PRACH number is the FPACH/PRACH description position within the IE 'PRACH system information list', (see subclause 13.3.3) e.g. the first configured PRACH/FPACH pair gets number 0, the second configured PRACH/FPACH gets number 1 and so on. This number is the parameter M in the equation above. N is the number of the chosen signature (range 0..7). In a cell, at least one PRACH and one associated FPACH shall be configured. Up to a maximum of 8 PRACH/FPACH pairs can be configured. The SCCPCH used for one UE is chosen in the same way as in 3.84Mcps TDD and FDD based on the Initial UE Identity in idle mode and based on the old U-RNTI in connected mode.
13.3.2.2
Essentially, the description of the PCCPCH in 1.28Mcps TDD is much simpler than in 3.84Mcps TDD because the timeslot for the PCCPCH is defined to be TS0 in 1.28Mcps TDD while the timeslot is flexible in 3.84Mcps TDD depending on the location of the SCH. Furthermore, in 1.28Mcps TDD there is in contrast to 3.84Mcps TDD only one burst type. Due to the different nature of the synchronization process there are no different synchronization cases. The usage of Block STTD is currently discussed for 1.28Mcps TDD in WG1. Thus the only parameters describing the PCCPCH is the cell parameter id and Block STTD if it is decided. The primary CCPCH can be used for cell identification in a similar way for the identification of cells as the Primary CPICH info in FDD and the primary CCPCH info in TDD.
13.3.2.3
The secondary CCPCH can be described in a similar way as in 3.84Mcps TDD. Essentially, the only difference is the absence of the burst type because there is only one burst type in 1.28Mcps TDD.
13.3.2.4
Essentially, the concept for the paging indicator channel can be adopted from the 3.84Mcps TDD mode. Thus there are similar changes needed as for most of the other physical channels, i.e. the burst type is not required as a parameter.
13.3.2.5
The parameters required to define shared channels are essentially the same as those for the TDD 3.84 Mcps option. The differences reflect the differences in the physical layer parameters e.g. 8PSK is available as a modulation option. Their method of use is almost identical to that for the 3.84 Mcps option with the additions that closed loop power and timing correction can be applied to USCH transmissions. In addition the, UE can obtain timing correction before transmitting on the USCH through the completion of a SYNC1/FPACH exchange.
13.3.2.6
This subclause identifies parameters that additionally need to be broadcast to support 1.28Mcps TDD. Depending on the size of the cell a different amount of users can be supported in one timeslot. In order to improve the configuration of the receiver in the UE it is beneficial to provide these information in the system information. It is proposed to include the parameter W in system information block type 5. This parameter provides information about the maximum channel impulse response. This parameter depends on the amount of users that can be served and the environment. This parameter is foreseen to be cell specific. The allowed values are W=8, 9, 12, 16, 21, 32, 64 (cp [1]). The predefined association of Midamble to Channelisation Codes depends on this parameter (cp. [1]).
3GPP
Release 4
21
1.28Mcps TDD has higher requirements on the uplink timing of transmissions than 3.84Mcps TDD. The means to preserve uplink synchronization are layer1 bits, the SS bits. The SS bits are transmitted every subframe, however, they are often not required that often. Thus the frequency of the update of the adjustment of uplink transmission can be decreased on a case by case basis. Another advantage of the reduction of the update frequency of the adjustment of the uplink transmission is the averaging effect by jointly evaluating a number of SS bits. Thus the probability of false adjustments is reduced. A parameter "Uplink synchronisation step size" is proposed with a value range (1..8) to achieve this. Consequently, another parameter is reasonable that allows to adjust the step sizes of the uplink transmission adjustment. By providing this parameter the network can reduce the accuracy requirements on a case by case basis. The parameter "Uplink synchronisation frequency" is proposed to allow this adjustment of the step sizes for the adjustment of the uplink transmissions. A value range of (1..8) is proposed.
13.3.2.7
Depending on the capability of the base station and the characteristics of the physical channels, TSTD can be used to overcome the time varying characteristics of the communication channel. In 1.28Mcps UTRA TDD, TSTD can be applied to P-CCPCH, DwPCH, and DPCH. In case of DPCH, UE shall have the knowledge about the usage of TSTD due to the power control of DPCH. Transmission power control of DPCH is currently discussed for 1.28Mcps in WG1. Similar as for the IE "Tx diversity indicator" for FDD, "TSTD indicator" can be defined and used to inform the application of TSTD to DPCH.
13.3.2.8
In 1.28Mcps TDD, knowing the received timing of UpPCH or PRACH does not allow the Node B to measure the propagation delay, because the transmission timing of those physical channels are adjusted by the UE for uplink synchronization. For SRNC to measure the propagation delay when PRACH is sent, the following two measurement values can be used, UpPCHADV: Difference between the Rx timing and initial Tx timing of a UE. UpPCHPOS: Received starting position of the UpPCH. The reference time (UpPCHPOS = 0) is two symbols prior to the end of the DwPCH. Any received starting position of the UpPCH after that point of time is positive.
Then, SRNC can calculate the propagation delay using the above values as follows. Propagation Delay = (UpPCHADV + UpPCHPOS - 8*16 TC) / 2 To support this propagation delay measurement, the UE shall transmit the UpPCHADV to SRNC. Following Figure 5 illustrates the timing of UpPCH transmission.
UpPCH POS
Node B Timing
Actual Propagation Delay
UE Rx Timing
UE Tx Timing
Estimated Propagation Delay
UpPCH ADV
SYNC_DL Burst
SYNC_UL Burst
Figure 5:
3GPP
Release 4
22
13.3.3
NOTE:
This subclause contains a tabular description of required information for physical channel description in an RRC-like format. The hierarchical structure as specified in the RRC specification is not used but could easily be applied. The differences to the 3.84Mcps TDD mode are highlighted with revision marks. The subclause numbers in the type and reference column refer to [5] (v3.3.0).
13.3.3.1
>Puncturing limit
MP
>Repetition period
MD
>Repetition length
MP
>Time info >TFCI coding >Timeslot list >>Timeslot number >>Burst Type
MP MP MP MP MP
>>Midamble Shift
MD
MP MP
MP MP
1..2 Enumerated( (1/1),)(2/1),( 2/2),(4/1)..(4/ 4),(8/1)..(8/8) ,(16/1)..(16/1 6)) Same as in 3.84Mcps TDD.
3GPP
Release 4
23
>Puncturing limit
MP
>Repetition period
MD
>Repetition length
MP
>Time info >TFCI coding >Timeslot list >>Timeslot number >>Midamble Shift
MP MP MP MP MD
>>Burst Type
MP
MP MP
MP MP
13.3.3.2
Details of shared channels have not been decided yet for 1.28Mcps TDD. However, it is foreseen that no modifications are required for shared channels except similar changes as for dedicated channels.
3GPP
Release 4
24
13.3.3.3
MP
1 .. <maxPRA CH> PRACH info See below FPACH info See below Transport channel identity 10.3.5.18 Transport format set 10.3.5.23 Transport Format Combination Set 10.3.5.20 PRACH partitioning 10.3.3.45
MP MP MP
>RACH TFS
MD
>RACH TFCS
MD
Default value is the value of "RACH TFS" for the previous PRACH in the list (note : the first occurrence is then MP) Default value is the value of "RACH TFCS" for the previous PRACH in the list (note : the first occurrence is then MP) Default value is the value of "PRACH partitioning" for the previous PRACH in the list (note : the first occurrence is then MP) If this IE is absent, value is the value of "Persistence scaling factors" for the previous PRACH in the list if value exists Only present in SIB 5 If this IE is absent, value is the value of "Persistence scaling factors" for the previous PRACH in the list if value exists
>PRACH partitioning
MD
OP
>AC-to-ASC mapping
OP
3GPP
Release 4
25
PRACH info
Information Element/Group name 2nd interleaving mode Need MP Multi Type and reference Enumerated( Frame, Timeslot) Real(0.40..1. 0 by step of 0.04) Integer(4,8,1 6,32) Integer(1..6) Integer(0..15 ) Semantics description Same as 3.84Mcps TDD
Puncturing limit
MP
MP MP MP MD 1..6
MP MP MP
Reduced range compared to 3.84Mcps TDD mode. Range depends on cell configuration. A fixed association between channelisation codes and midamble shift is described in [1]. Same as 3.84Mcps TDD Same as in 3.84Mcps TDD.
Sync1 transmission parameters These parameters are not used in 3.84Mcps TDD. There are major similarities to the RACH transmission parameters in FDD.
Information Element/Group name Power Increment M Need MP MP Multi Type and reference Integer(0,1,2 ,3) Integer(1,2,4 ,8) Semantics description in dB Max re-transmissions of UpPTS
3GPP
Release 4
26
13.3.3.4
PCCPCH info
Need MP MD
Multi
Semantics description
Default value is "TRUE" The usage of Block STTD for 1.28 Mcps TDD is currently under discussion in WG1
SCCPCH info
Information Element/Group name 2nd interleaving mode Need MP Multi Type and reference Enumerated( Frame, Timeslot) Real(0.40..1. 0 by step of 0.04) Integer(2,4,8 ,16,32,64) Integer(1.. Repetition period 1 ) Integer(1..Re petition Period-1) Integer(4,8,1 6,32) Integer(1..6) Integer(0..15 ) Semantics description Same as 3.84Mcps TDD
Puncturing limit
MP
MD MP
Offset
MP
MP MP MP MD 1..6
Burst Type
MP
MP MP MP
Reduced range compared to 3.84Mcps TDD mode. Range depends on cell configuration. A fixed association between channelisation codes and midamble shift is described in [1]. This information is not needed in 1.28Mcps TDD because only one burst type exists. Same as 3.84Mcps TDD Same as 3.84Mcps TDD mode. Only spreading factor 16 is applicable.
3GPP
Release 4
27
PICH info
Information Element/Group name Channelisation code Need MD Multi Type and reference Enumerated ( (16/1)...(16/1 6)) Timeslot number 10.3.6.72 Enumerated (Typ1,Typ2) Integer(0..15 ) Semantics description Same as 3.84Mcps TDD.
Timeslot
MD
MP MD
Repetition period/length
MD
Offset
MP
MD MD MD
Enumerated( (4/2),(8/2), (8/4),(16/2), (16/4), (32/2),(32/4), (64/2),(64/4)) Integer (0...Repetitio n period -1) Integer (2, 4, 8) Integer(2, 4, 8) Integer(1 .. 8)
Range depends on cell configuration. A fixed association between channelisation codes and midamble shift is described in [1]. Same as 3.84Mcps TDD.
13.3.3.5
These information are proposed to be additionally included in System information block type 5 (in addition to the parameters for common channels)
Information Element/Group name Uplink synchronisation step size Need MP Multi Type and reference Integer(1..8) Semantics description This parameter specifies the step size to be used for the adjustment of the uplink transmission timing This parameter specifies the frequency of the adjustment of the uplink transmission timing
MP
Integer(1..8)
MP
13.3.3.6
The following information element is proposed to be additionally included in IE "Downlink DPCH info for each RL".
Information Element/Group name TSTD indicator Need MD Multi Type and reference Boolean Semantics description Default value is "TRUE"
3GPP
Release 4
28
13.3.3.7
Following information element is proposed to be additionally included in IE "Measured results on RACH" to support the propagation delay measurement.
Information Element/group name UpPCHADV Need MP Multi Type and reference Integer (0..352) Semantics description In chips, For 1.28Mcps TDD
13.3.4
NOTE:
It has been decided to distinguish the differences of FDD and TDD with the help of the CHOICE mode notation as described in [5] and [6]. This notation is suitable to both outline the desired commonalties between both modes and shows also the differences in an easy-to-read manner. In order to include information elements that are specific for 1.28Mcps TDD into the existing [5] a similar principle could be used. An example how the differences between 1.28 Mcps TDD and 1.28 Mcps TDD could be shown is given in the table below. 10.3.6.49 Primary CCPCH info
Information Element/Group name CHOICE mode >FDD >>TX Diversity indicator >TDD >>CHOICE TDD mode >>>3.84Mcps >>>>CHOICE SyncCase >>>>>Sync Case 1 >>>>>>Timeslot >>>>>Sync Case 2 >>>>>>Timeslot >>>1.28Mcps >>Cell parameters ID >>Block STTD indicator Need MP MD Boolean Default value is "TRUE" Multi Type and reference Semantics description
OP MP Integer (0...14) Integer(0..6) Null Integer (0...127) Block STTD indicator 10.3.6.5 PCCPCH timeslot
MP OP MD
(No data) The Cell parameters ID is described in [11]. Default value is "TRUE". The usage of Block STTD is currently under discussion in WG1
Example for inclusion of 1.28 Mcps TDD in tabular format The principles how 1.28 Mcps TDD option can be included in the tabular format of [5] have been described. It is proposed to apply a notation as shown in the above example in order to represent 1.28 Mcps TDD in [5] in R2000.
3GPP
Release 4
29
14
14.1
14.1.1
The RACH mechanism that has been defined for the 1.28 Mcps TDD [1] is a two-step process that is similar to the twostep process that has been adopted for UTRA FDD. Uplink Pilot Timeslot UpPTS is used for transmission of random access signatures, called SYNC1. The UpPTS is located in each 5 ms subframe and it is composed of 128 chips of SYNC1 and 32 chips of guard period. There should be 256 different SYNC1codes for the whole system and each 8 SYNC1 codes are allocated in a code group. Each 8 SYNC1 codes group corresponds to one SYNC code which is an identity of a cell and used for DL synchronization purpose. When a RACH access is made with the 1.28 Mcps TDD option the following steps are completed: i) The UE randomly chooses its SYNC1 code for cell access out of the 8 possible SYNC1 codes of the code group that is indicated through the used SYNC sequence in DwPTS. The UE transmits using this SYNC1 code in the UpPTS. It then monitors the burst of FPACH physical channel associated with the chosen SYNC1 sequence for acknowledgement. ii) Acknowledgement on the FPACH will permit transmission of the RACH message in the PRACH resources that are associated with the FPACH. The acknowledgement contains the time corrections and power settings that are to be used with the PRACH transmission. The acknowledgement should be received within 4 sub-frames of the SYNC1 transmission being made. After sending the RACH message, the UE will receive response by FACH on S-CCPCH indicating whether the UE random access has been accepted or not. When sending a SYNC1 sequence, the UE knows which FPACH and PRACH resources will be used for the access. This information is provided in system information on BCCH. The SYNC1 process can be repeated, up to a maximum number of times, including a power ramping of the SYNC1 transmissions. Figure 6 shows the random access transmission sequence for 1.28Mcps TDD.
3GPP
Release 4
30
Uu
UE-RRC UE-RLC UE-MAC CPHY-TrCH-Config-REQ CMAC-Config-REQ MAC-Data-REQ Initial backoff time UE-PHY Node B-PHY
Iub
RNC-MAC
Timer is set to Increment wait for ACK synchronization transmission counter on FPACH
(collision)
Timer expires
Increment Timer is set to synchronization wait for ACK on transmission counter FPACH
FPACH ACK
PHY-Data-REQ
14.1.2
NOTE:
UE MAC receives the following RACH transmission control parameters from RRC with the CMAC-Config-REQ primitive: a set of Access Service Class (ASC) parameters, which includes for each ASC, i=0,,NumASC an identification of a PRACH partition and a persistence value Pi (transmission probability), maximum number of synchronisation attempts Mmax.
When there is data to be transmitted, MAC selects the ASC from the available set of ASCs, which consists of an identifier i of a certain PRACH partition and an associated persistence value Pi. Based on the persistence value Pi, the UE MAC decides whether to start the L1 PRACH procedure in the present transmission time interval or not. If transmission is allowed, the PRACH transmission procedure (starting with the selection and transmission of a SYNC1 burst) is initiated by the sending of a PHY-ACCESS-REQ primitive. MAC then waits for access information from L1 via the PHY-ACCESS-CNF primitive. If transmission is not allowed, a new
3GPP
Release 4
31
persistency check is performed in the next transmission time interval. The persistency check is repeated until transmission is permitted. If the synchronisation burst has been acknowledged on the FPACH, L1 access information with parameter "ready for RACH data transmission" is indicated to MAC with a PHY-ACCESS-CNF primitive. Then data transmission is requested with a PHY-DATA-REQ primitive, and the PRACH transmission procedure shall be completed with transmission of the PRACH message on the P-RACH resources associated with the FPACH. If PHY received no acknowledgement on the FPACH and the maximum number of synchronisation attempts permitted has not been exceeded, then a new persistency test is performed in the next transmission time interval and the PHYACCESS-REQ procedure is repeated. The timer T2 ensures that two successive persistency tests are separated by at least one transmission time interval. If the maximum number of synchronisation attempts is exceeded then MAC abandons the RACH procedure and the message is discarded.
Start NOTE: MAC-c/sh receives RACH tx control parameters from RRC with CMAC Config-REQ primitive whenever one of the parameters is updated
Get RACH tx control parameters from RRC: Mmax, set of ASC parameters N Any data to be transmitted ? Y
Increment synchronisation transmission counter M M Mmax ? Y Update RACH tx control parameters Wait expiry Timer T 2 (next TTI) Set Timer T 2 (1 TTI) Draw random number 0 Ri< 1 R Pi ? Y Send PHY-ACCESS-REQ (start of L1 PRACH transmission procedure) N Wait expiry Timer T 2 (next TTI) N
Send PHY-DATA-REQ
(PRACH message part transmitted)
End
Figure 7: RACH transmission control procedure for 1.28 Mcps TDD (UE side, informative)
14.1.3
Due to the specific RACH procedure in 1.28 Mcps TDD, some modifications to the primitives are needed. Specifically, the RACH transmission control elements assigned to CMAC-CONFIG-Req primitive between MAC and RRC as defined in [4] must contain the maximum number of synchronisation attempts:
3GPP
Release 4
32
RACH transmission control elements: Set of ASC parameters (identifier for PRACH partitions, persistence values) Maximum number of preamble ramping cycles (FDD) or synchronisation attempts (1.28 Mcps TDD) Mmax Minimum and maximum number of time units between two preamble ramping cycles, NBO1min and NBO1max (FDD only)
In the primitives between L1 and MAC, some modification in the parameter access information is needed which is used in PHY-Access-CNF: Access Information: Ready for RACH data transmission (in case of FDD mode: when Ack on AICH has been received, in case of 1.28 Mcps TDD: when Ack on FPACH has been received). timeout, no response on AICH or AP-AICH or FPACH has been received while maximum number of access preamble transmissions / synchronisation attempts has been performed;
The following values of this parameter apply to FDD only: NACK on AICH or AP-AICH has been received; ready for CPCH data transmission (CD or CD/CA information received on CD-ICH or CD/CA-ICH, respectively); mismatch of CD-ICH or CD/CA-ICH signatures; no response on CD-ICH or CD/CA-ICH received; timeout, no CD/CA-ICH received.
FPACH physical channel has to be added to Physical Channel Description used in CPHY-RL-Setup-REQ and CPHYRL-Modify-REQ between L1 and L3, see subclause 11.3.5. PRACH description has to be slightly modified.
14.1.4
The difference in RACH procedure requires that the ASC/AC concept used in the 1.28 Mcps option is slightly different from that of the 3.84 Mcps option. 1. TDD 3.84 Mcps In TDD 3.84 Mcps RACH access is a one stage process, in which RACH transmission is repeated until an acknowledgement is obtained. 2. TDD 1.28 Mcps In 1.28 Mcps TDD, RACH access is a 2-stage process, governed by the SYNC1 transmission, as described in 14.1.1 above. SYNC1 transmission is repeated until an acknowledgement is obtained, so permitting transmission on the RACH, using pre-assigned resources. It is therefore necessary to apply partitioning to the SYNC1 signal, rather than to the PRACH signal. It is proposed that the Access Service Class concept for PRACH partitioning for the UTRA TDD 3.84 Mcps, as defined in [5], is used for partitioning the SYNC1 signal in the UTRA TDD low chip rate option. Access Classes (AC) and Access Service Classes (ASC) govern access to UpPTS, by allowing different priorities of UpPTS usage to different UEs (SYNC1 is transmitted on UpPTS). The Access Class to which a UE belongs is stored on its SIM. For initial access, the Access Service Class to be used for UpPTS is derived from the UEs Access Class by the AC-to-ASC Mapping information element, which is broadcast in BCH. The AC-to-ASC mapping as it is currently specified for FDD and 3.84 Mcps TDD remains the same for 1.28 Mcps TDD. The UpPTS resources are divided into UpPTS partitions, consisting of sets of frames defined by frame repetition period and offset. Each Access Service Class maps to a UpPTS partition, so defining the frames on which that Access Service Class may transmit a SYNC1 code, and has a persistence value Pi, which defines the probability that the Access Service
3GPP
Release 4
33
Class will transmit a SYNC1 code on its allocated frames. The transmitted SYNC1 code is chosen randomly from the available set of signatures within the two subframes of the allowed frames for this Access Service Class. With regard to the persistence value concept, no modification is required compared to 3.84 Mcps TDD.
14.2
Uplink Synchronization is a L1 function of 1.28 Mcps TDD. It is described in [1]. For the support of Uplink Synchronization, some parameters have to be introduced into RRC signalling, see subclause 13.2. No further impact on L23 protocols could be identified.
15
15.1
Cell (Re)Selection
States and Transitions in Idle Mode
15.2
15.2.1
The initial and stored information cell selection procedures are basically the same as in 3.84 Mcps TDD. However, the cell search process in 1.28 Mcps TDD is different from 3.84 Mcps TDD. The UE uses the SYNC code in DwPTS to acquire downlink synchronization to a cell. During this procedure, the UE needs to identify which of the 32 possible SYNC sequences is used. During the second step of the initial cell search procedure, the UE receives the midamble of the P-CCPCH. The location of the P-CCPCH is always known as it is sent directly before the DwPTS. Each SYNC code corresponds to a group of 4 different basic midamble codes which are again associated with a scrambling code. If the UE has determined the correct midamble code, it can read the system information on BCH. For the stored information cell selection, stored information of carrier frequencies and optionally also information on cell parameters from previously received measurement control information elements is required. In 1.28 Mcps TDD, these parameters are the same as in 3.84 Mcps TDD (frequency information and optionally cell parameter ID).
15.2.2
Cell selection Criteria are the same as in 3.84 Mcps TDD. P-CCPCH RSCP is used as measurement to determine the quality value Qrxlevmeas. Detailed ranges for the P-CCPCH RSCP measurement for 1.28 Mcps TDD are to be defined by WG4. The ranges of the parameters required to determine Srxlev are f.f.s.
15.3
The immediate cell evaluation process is the same as in 3.84 Mcps TDD.
15.4
15.4.1
No modifications compared to 3.84 Mcps TDD are required. The ranges of the measurement thresholds broadcast in system information are f.f.s.
3GPP
Release 4
34
15.4.2
15.4.3
Basically, the same parameters as in 3.84 Mcps TDD have to be broadcast for 1.28 Mcps TDD as well. The ranges for Qrxlevmin, SsearchHCS, SsearchRATn, SHCS,RATm, Sintrasearch, Sintersearch, Slimit,SearchRATm are f.f.s.
15.5
15.6
16
16.1
Handover Procedures
Handover Between 1.28 Mcps TDD Cells
Handover between 1.28 Mcps cells uses similar procedures and signalling to those that are specified for handover between 3.84 Mcps TDD cells. The differences are primarily contained in the procedures that are used by the UE to achieve synchronisation with the target cell when the handover takes place between unsynchronised cells. The handover is initiated by the UTRAN in response to measurement reports made within the network and reported by the UE. The UE is instructed to make the handover by a PHYSICAL CHANNEL RECONFIGURATION message that contains a P-CCPCH info IE that is different from that which is stored in the UE. If the IE 'Uplink Timing Advance Control' included in the 'Uplink DPCH info', in the PHYSICAL CHANNEL RECONFIGURATION message, indicates that timing advance is not enabled, then the UE hands over to the new cell without making a timing correction. It configures the new channels and transmits a PHYSICAL CHANNEL RECONFIGURATION COMPLETE message on the DCCH using AM RLC. RLC confirmation of its delivery enables the UE to resume transmissions on the new channels. The PHYSICAL CHANNEL RECONFIGURATION message may include an initial power level for uplink transmission in the new cell, if so, this power level shall be applied. If the IE 'Uplink Timing Advance Control' indicates that timing advance is enabled and the IE 'Synchronisation Mode' indicates that the target cell is synchronised then the UE executes a synchronised handover procedure. It calculates the timing offset for the target cell, configures the new channels and transmits the PHYSICAL CHANNEL RECONFIGURATION COMPLETE message. Transmissions can then be resumed on the new channels, using the initial power setting if one has been provided. This is illustrated in figure 8.
3GPP
Release 4
35
Figure 8: Synchronized Handover If the IE 'Uplink Timing Advance Control' indicates that timing advance is enabled and the IE 'Synchronisation Mode' indicates that the target cell is unsynchronised then the UE executes an unsynchronised handover procedure. The procedure differs from that specified for 3.84 Mcps TDD because the use of type 3 bursts is replaced by synchronisation through a SYNC1(UpPTS) FPACH exchange. The UE transmits successively (every four sub-frames) in the UpPTS until a response is received on the FPACH. The UTRAN may specify, in the PHYSICAL CHANNEL RECONFIGURATION message, the synchronisation code set and PRACH partition that are to be applied to the UpPTS transmissions. The FPACH response will provide a timing and power correction to the UE. Following completion of the synchronisation procedure the UE is able to configure the new channels, transmit the PHYSICAL CHANNEL RECONFIGURATION COMPLETE message and resume transmissions. This is illustrated in figure 9.
3GPP
Release 4
36
SYNC1
16.2
Handover from UMTS FDD and 3.84 Mcps TDD Cells to a 1.28 Mcps TDD Cell
Handover from cells of UMTS TDD 3.84 and UMTS FDD systems to a cell of a UMTS TDD 1.28 Mcps system is similar to unsynchronised handover between cells of type UMTS TDD 1.28 Mcps as described in subclause 16.1. The handover is initiated by the transfer, to the UE, of a 'Physical Channel Reconfiguration' message (or its equivalent). The message will contain target cell parameters and the physical resources to be used in the cell. The UE will synchronise with the target cells transmissions and completes a SYNC1/FPACH exchange to obtain initial timing and power settings. The UE is then able to transmit on the assigned physical channels and should transmit a 'Physical Channel Reconfiguration Complete' on the DCCH using AM RLC. If the UE does not successfully execute the handover, it returns to its old system, resynchronises with it, and transmits a 'Physical Channel Reconfigure Failure' message on the DCCH using AM RLC.
16.3
Handover to UMTS FDD and 3.84 Mcps TDD Cells from a 1.28 Mcps TDD Cell
Handover from a TDD 1.28 Mcps cell to an FDD cell will be identical to that from a TDD 3.84 Mcps cell to an FDD cell [5]. Whilst handover, from a TDD 1.28 Mcps cell to a TDD 3.84 Mcps cell will be equivalent to that from FDD to TDD 3.84 Mcps. Should the handover fail, the UE will resynchronise with its original cell using the SYNC1/FPACH procedure and reconfigure to its previously assigned physical resources. It then transmits the 'Physical Channel Reconfiguration' message on the DCCH.
3GPP
Release 4
37
16.4
UMTS 1.28 Mcps TDD will support hard handover from 1.28 Mcps TDD cells to cells of an external system, e.g. GSM cells, provided that the UE has the capability to do so. The handover procedure is identical to that specified in [5] for handover between cells of a UMTS system and cells of another radio access system.
16.5
UMTS 1.28 Mcps TDD will support handover from cells of external systems, e.g. GSM, provided that the UE has the capability to do so. The handover procedure is similar to that described for Inter-system handover to UTRAN in [5], although to enable the UE to obtain timing and initial power settings the 1.28 Mcps synchronisation procedure is executed before the UE transmits on the assigned channels. The UE will have received a HANDOVER TO UTRAN COMMAND in its source network. This will have conveyed to the UE a U-RNTI, the traffic and physical channel parameters and the physical channel resources that are to be used in the 1.28 Mcps TDD cell. The UE will synchronise with the target cells transmissions and perform a SYNC1/ FPACH exchange using parameters assigned to it in the HANDOVER TO UTRAN COMMAND message. This will provide the UE with initial timing and power settings. When the SYNC1/FPACH exchange is successfully completed, the UE will initiate the signalling, radio bearer and transport channels and configure the physical channels as defined in the HANDOVER TO UTRAN COMMAND message. The UE will then transmit a HANDOVER TO UTRAN COMPLETE message on the DCCH using AM RLC. Should the UE fail to complete access to the new cell it will seek recovery in the system from which the handover was initiated. Receipt of the HANDOVER TO UTRAN COMPLETE message enables the UTRAN to report to the external network that resources assigned to the UE can be released.
17
(void)
Recommendations
3GPP
Release 4
38
3GPP