TS 125 402

TS 125 402
ETSI TS 125 402 V3.0.0 (2000-01)
Technical Specification
Universal Mobile Telecommunications System (UMTS);
Synchronization in UTRAN Stage 2
(3G TS 25.402 version 3.0.0 Release 1999)
(3G TS 25.402 version 3.0.0 Release 2000)
1
ETSI TS 125 402 V3.0.0 (2000-01)
Reference
DTS/TSGR-0325402U
Keywords
UMTS
ETSI
Postal address
F-06921 Sophia Antipolis Cedex - FRANCE
Office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Internet
secretariat@etsi.fr
Individual copies of this ETSI deliverable
can be downloaded from
http://www.etsi.org
If you find errors in the present document, send your
comment to: editor@etsi.fr
Important notice
This ETSI deliverable may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network
drive within ETSI Secretariat.
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.
© European Telecommunications Standards Institute 2000.
All rights reserved.
ETSI
(3G TS 25.402 version 3.0.0 Release 2000)
2
ETSI TS 125 402 V3.0.0 (2000-01)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect
of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server
(http://www.etsi.org/ipr).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server)
which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by the ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities or GSM identities.
These should be interpreted as being references to the corresponding ETSI deliverables. The mapping of document
identities is as follows:
For 3GPP documents:
3G TS | TR nn.nnn "<title>" (with or without the prefix 3G)
is equivalent to
ETSI TS | TR 1nn nnn "[Digital cellular telecommunications system (Phase 2+) (GSM);] Universal Mobile
Telecommunications System; <title>
For GSM document identities of type "GSM xx.yy", e.g. GSM 01.04, the corresponding ETSI document identity may be
found in the Cross Reference List on www.etsi.org/key
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
2000)
3
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
Contents
Foreword ............................................................................................................................................................ 5
1
Scope........................................................................................................................................................ 6
2
References................................................................................................................................................ 6
3
Definitions, symbols and abbreviations................................................................................................... 6
3.1
3.2
3.3
4
4.1
4.2
4.3
4.4
4.5
4.6
Definitions ......................................................................................................................................................... 6
Symbols ............................................................................................................................................................. 6
Abbreviations..................................................................................................................................................... 6
Synchronisation Issues............................................................................................................................. 7
General............................................................................................................................................................... 7
Network Synchronisation .................................................................................................................................. 8
Node Synchronisation........................................................................................................................................ 8
Transport Channel Synchronisation................................................................................................................... 9
Radio Interface Synchronisation........................................................................................................................ 9
Time Alignment Handling ................................................................................................................................. 9
5
Synchronisation Counters and Parameters............................................................................................... 9
6
Node Synchronisation............................................................................................................................ 12
6.1
6.1.1
6.1.2
6.1.2.1
6.1.2.2
7
7.1
7.2
8
General............................................................................................................................................................. 12
RNC-Node B Node Synchronisation ......................................................................................................... 13
Inter Node B Node Synchronisation .......................................................................................................... 13
TDD Node B Synchronisation Ports..................................................................................................... 13
TDD Inter Node B Node Synchronisation procedure........................................................................... 15
Transport Channel Synchronisation....................................................................................................... 16
General............................................................................................................................................................. 16
Timing adjustment on Iub/Iur interfaces.......................................................................................................... 16
Radio Interface Synchronisation............................................................................................................ 17
8.1
General............................................................................................................................................................. 17
8.2
FDD Radio Interface Synchronisation............................................................................................................. 17
8.2.1
General ....................................................................................................................................................... 17
8.2.2
Neighbour cell list timing information ....................................................................................................... 20
8.3
TDD Radio Interface Synchronisation............................................................................................................. 20
8.3.1
General ....................................................................................................................................................... 20
8.3.2
Radio Frame Synchronisation .................................................................................................................... 20
8.3.3
Timing Advance......................................................................................................................................... 21
8.3.3.1
Measurement of the timing offset on the physical channels................................................................. 21
8.3.3.2
Assignment of correct timing advance value when establishing new channels.................................... 21
8.3.3.2.1
Switch to DCH/DCH state .............................................................................................................. 21
8.3.3.2.2
Switch to USCH state ..................................................................................................................... 22
8.3.3.3
Correction of timing advance value for channels in operation ............................................................. 22
8.3.3.3.1
UE in Traffic using at least one uplink DCH .................................................................................. 22
8.3.3.3.2
UE in Traffic using only USCH...................................................................................................... 22
8.3.3.4
Setting of timing advance value for target cell at handover ................................................................. 22
9
9.1
9.2
9.2.1
9.2.2
9.2.3
9.2.4
9.2.5
9.3
Usage of Synchronisation Counters and Parameters to support Transport Channel and Radio
Interface Synchronisation ...................................................................................................................... 23
General............................................................................................................................................................. 23
Calculations performed in the UTRAN ........................................................................................................... 26
UE in common channel state...................................................................................................................... 26
UE changes state from common CH state to dedicated CH state: 1 RL..................................................... 26
UE changes state from common CH state to dedicated CH state: several RL's (FDD only)...................... 26
UE in dedicated CH state request to add a new RL or moves to another cell ............................................ 26
Handover from other RAN to UMTS......................................................................................................... 26
Calculations performed in the UE.................................................................................................................... 26
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
9.3.1
9.3.2
9.4
4
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
First RL ...................................................................................................................................................... 26
Additional RL's or UE moves into a new cell ............................................................................................ 27
Synchronisation of L1 configuration changes.................................................................................................. 27
Annex A (informative): Change history....................................................................................................... 28
History.............................................................................................................................................................. 29
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
5
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
Foreword
This Technical Specification has been produced by the 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 this TS, 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 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
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
1
6
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
Scope
The present document constitutes the stage 2 specification of different synchronisation mechanisms in UTRAN and on
Uu.
2
References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• 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.
[1]
3G TS 25.401: "UTRAN Overall Description".
[2]
3G TS 25.423: "UTRAN Iur Interface RNSAP Signalling".
[3]
3G TS 25.433: "UTRAN Iub Interface NBAP Signalling".
[4]
3G TS 25.435: "UTRAN Iub Interface user Plane Protocols for Dedicated Transport Channel
DataStreams".
[5]
3G TS 25.427: " Iub/Iur Interface User Plane Protocol for DCH Data Streams".
[6]
EIA 422-A-78: "electrical characteristics of balanced voltage digital interface circuits".
3
Definitions, symbols and abbreviations
3.1
Definitions
No special definitions are defined in this document.
3.2
Symbols
No special symbols are defined in this document.
3.3
Abbreviations
For the purposes of the present document, the following abbreviations apply:
BFN
CFN
CH
CN
CRNC
DL
DCH
DPCH
DPCCH
DSCH
DRNC
Node B Frame Number (counter)
Connection Frame Number (counter)
Channel
Core Network
Controlling RNC
Down Link
Dedicated Channel
Dedicated Physical Channel
Dedicated Physical Control Channel
Downlink Shared Channel
Drift RNC
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
FACH
FDD
GPS
HO
LTOA
L1
L2
LSBx
MAC
MDC
PCCPCH
PCH
PUSCH
RACH
RAN
RFN
RL
RNC
RNS
RRC
SFN
SRNC
SRNS
TBS
TDD
TOA
TOAWE
TOAWS
TTI
UE
UL
USCH
UTRAN
7
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
Forward Access Channel
Frequency Division Duplex
Global Positioning System
Handover
Latest Time of Arrival
Layer 1
Layer 2
Last x Significant Bits
Medium Access Control
Macro Diversity Combiner
Primary Common Control Physical Channel
Paging Channel
Physical Uplink Shared Channel
Random Access Channel
Radio Access Network
RNC Frame Number (counter)
Radio Link
Radio Network Controller
Radio Network Subsystem
Radio Resource Control
Cell System Frame Number (counter)
Serving RNC
Serving RNS
Transport Block Set
Time Division Duplex
Time of Arrival
Time of Arrival Window Endpoint
Time of Arrival Window Startpoint
Time Transmission Interval
User Equipment
Up Link
Uplink Shared Channel
UMTS Terrestrial Radio Access Network
4
Synchronisation Issues
4.1
General
This section identifies the different UTRAN synchronisation issues, i.e.:
-
Network Synchronisation;
-
Node Synchronisation;
-
Transport Channel Synchronisation;
-
Radio Interface Synchronisation;
-
Time Alignment Handling.
The Nodes involved by the above mentioned synchronisation issues (with the exception of Network and Node
Synchronisation) are shown by the Synchronisation Issues Model of Figure 1.
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
8
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
V ocoder
CN
Tim e
Alignm ent
Handling
RNS
RN C
RN C
Transport
Channel
Synchronisation
N ode
B
N ode
B
N ode
B
N ode
B
N ode
B
U TRAN
Radio
Interface
Synchronisation
UE1
[TDD] Radio
Interface
Sync.
UE2
O ptional TD D only input &
output sync ports
Figure 1: Synchronisation Issues Model
The UTRAN solutions for some of the identified items are described in sections 6-9. Additional information on
UTRAN synchronisation issues and the detailed specification of UTRAN solutions can be found in the following
Technical Specifications:
-
Summary of UTRAN Synchronisation Issues:
TS 25.401 "UTRAN Overall Description", section 9.
-
RNC-Node B Node Synchronisation:
TS 25.427 "Iub/Iur Interface User Plane Protocol for DCH Data Streams", section 8.5;
TS 25.435 "UTRAN Iub Interface User Plane Protocols for Dedicated Transport Channel Data Streams", section
5.2.
-
Transport Channel Synchronisation:
TS 25.427 "Iub/Iur Interface User Plane Protocol for DCH Data Streams", sections 8.2 – 8.3;
TS 25.435 "UTRAN Iub Interface User Plane Protocols for Dedicated Transport Channel Data Streams",
sections 5.3 – 5.4.
4.2
Network Synchronisation
The Network Synchronisation relates to the stability of the clocks in the UTRAN. The standard will specify the
performance requirements on UTRAN internal interfaces.
4.3
Node Synchronisation
Node Synchronisation relates to the estimation and compensation of timing differences among UTRAN nodes. FDD
and TDD modes have different requirements on the accuracy of the timing difference estimation and on the necessity to
compensate for these differences.
Two types of Node Synchronisation can be identified, "RNC-Node B" and "Inter Node B" Node Synchronisation. Their
usage differs and the requirements differ between the FDD and TDD modes.
"RNC-Node B" Node Synchronisation allows to get knowledge of the timing differences between RNC and its Node
Bs.
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
9
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
"Inter Node B" Node Synchronisation is necessary in the TDD mode to compensate the timing differences among Node
Bs in order to achieve a common timing reference. The purpose of having a common timing reference is to allow Radio
Frame Synchronisation, which is used, within neighbouring cells to minimise cross-interference.
Positioning / Localisation functions may also set requirements on Node Synchronisation (FFS).
4.4
Transport Channel Synchronisation
The Transport Channel Synchronisation mechanism defines the radio frame in which the TBS transmission shall be
started. In FDD from this reference point the Chip Offset is used to define the exact timing of the radio frame
transmission (FDD Radio Interface Synchronisation).
4.5
Radio Interface Synchronisation
The Radio Interface Synchronisation relates to the timing of the radio frame transmission (either in downlink [FDD] or
in both directions [TDD]). FDD and TDD have different mechanisms to determine the exact timing of the radio frame
transmission and also different requirements on the accuracy of this timing.
In FDD Radio Interface Synchronisation is necessary to assure that the UE receives radio frames synchronously from
different cells, in order to minimise UE buffers.
In TDD Radio Interface Synchronisation is necessary to synchronise radio frames within neighbouring cells (Radio
Frame Synchronisation) in order to minimise cells cross-interference and between UE and UTRAN (Timing Advance)
in order to minimise UE-cell interference.
4.6
Time Alignment Handling
Time Alignment handling relates to TTIs and is used to adapt to 10 ms framing (or to unit length e.g. 20 ms) i.e. to send
and receive frames 'just-in-time' and thus minimising the delay. Time Alignment is an issue between e.g. Vocoders and
the Macrodiversity Combiner (MDC) in RNC. Time Alignment could also be used for circuit switched services like
data.
5
Synchronisation Counters and Parameters
This section defines counters and parameters used in the different UTRAN synchronisation procedures.
The parameters used only by FDD has been indicated with the notation [FDD – parameter].
BFN
Node B Frame Number counter. This is the Node B common frame number counter. BFN
is optionally frequency-locked to a Network sync reference.
Range: 0 to 4095 frames, 12 bits.
RFN
RNC Frame Number counter. This is the RNC node common frame number counter. RFN
is optionally frequency-locked to a Network sync reference.
Range: 0 to 4095 frames, 12 bits.
SFN
Cell System Frame Number counter. SFN is sent on BCCH on Layer 1. SFN is used for
paging groups and system information scheduling etc.
In FDD SFN = BFN adjusted with T_cell.
In TDD SFN is locked to the BFN (i.e. SFN=BFN).
Range: 0 to 4095 frames, 12 bits.
CFN
Connection Frame Number (counter). CFN is the frame counter used for the L2/transport
channel synchronisation between UE and UTRAN. A CFN value is associated to each TBS
and it is passed together with it through the MAC-L1 SAP. CFN provides a common frame
reference (at L2) to be used e.g. for synchronised transport channel reconfiguration.
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
10
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
The duration of the CFN cycle is longer than the maximum allowed transport delay
between MAC and L1 (in UTRAN side, between SRNC and Node B, because the L1
functions that handle the transport channel synchronisation are in the Node B).
Range: 0 to 255 frames, 8 bits. When used for PCH the range is 0 to 4095 frames, 12 bits.
Frame_offset
Frame_offset is a radio link specific L1 parameter used to map the CFN, used in the
transport channel, into the SFN that defines the specific radio frame for the transmission on
the air interface.
At the L1/L2 interaction, the mapping is performed as:
LSB8(SFN) = CFN + Frame_offset (from L2 to L1)
(5.1)
CFN = LSB8(SFN) - Frame_offset (from L1 to L2)
(5.2)
The resolution of all three parameters is 1 frame. Frame_offset and CFN have the same
range (8 bits, 0…255) and only the 8 least significant bits of the SFN are used. The
operations above are modulo 256.
In the UTRAN, the Frame_offset parameter is calculated by the SRNC and provided to the
node B.
OFF
The parameter OFF is calculated by the UE and reported to the UTRAN only when the
UTRAN has requested the UE to send this parameter. In the neighbouring cell list, the
UTRAN indicates for each cell if the Frame_offset is already known by the UTRAN or
shall be measured and reported by the UE.
OFF has a resolution of 1 frame and a range of 0 to 255.
Five different cases are discerned related to the determination of the OFF value by the UE:
1. The UE changes from common channel state to dedicated channel state: 1 RL
In this case the Tm will be zero.
2. The UE is changes from common channel state to dedicated channel state: several RL's
Tm is in this case defined as being the time difference between the received PCCPCH
path of the camping cell and the received PCCPCH paths of the other candidate cells.
Again the UE sets Tm to zero for the cell to which the UE sends an UL RRC message
(cell #1). For cells #2 to n, the UE sets Tm to the time difference of the PCCPCH
reception timing of cell#2,n from the PCCPCH reception timing of cell#1.
3. The UE adds another RL in dedicated channel state (macro-diversity) Tm is in this case
defined as being the time difference between "TUETX – To" and the earliest received
PCCPCH path of the target cell. TUETX is the time when the UE transmits an uplink
DPCCH frame, hence "TUETX – To" is the "optimum" arrival time for the first path of a
received DPCH.
4. The UE is coming from another RAN and goes to dedicated channel state: 1 RL. This
case is identical to case 1.
5. The UE is coming from another RAN or another frequency in the same RAN and goes
to dedicated channel state: several RL's
This case is identical to case 2, with one exception: Tm will not be zero for the cell to
which the UE sends an UL RRC message (the measurement information will be
received via the CN in this case) but for a reference cell selected by the UE. All other
reported Tm values will be relative to the timing of the PCCPCH in this cell.
[FDD – DOFF]
The DOFF (Downlink-Offset) is used to define Frame_offset and Chip_offset at first RL
setup. The resolution should be good enough to spread out load over Iub and load in Node
B (based on certain load distributing algorithms). In addition it is used to spread out the
location of Pilot Symbol in order to reduce the peak DL power since Pilot symbol is always
transmitting at the fixed location within a slot (the largest chips for one symbol is
512chips).
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
11
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
The SRNC sends a DOFF parameter to the UE when the new RL will make the UE change
its state (from common channel state or other when coming from another RAN) to the
dedicated channel state.
Resolution: 512 chips; Range :0 to 599 (<80ms).
[FDD – Chip Offset]
The Chip_offset is used as offset for the DL DPCH relative to the PCCPCH timing. The
Chip_offset parameter has a resolution of 1 chip and a range of 0 to 38399 (< 10ms).
The Chip_offset parameter is calculated by the SRNC and provided to the Node B.
Frame_offset + Chip_offset (sent via NBAP) are in Node B rounded together to closest 256
chip boundary. The 256 chip boundary is used regardless of the used spreading factor, also
when the spreading factor is 512. The rounded value (which is calculated in Node B)
controls the DL DPCH air-interface timing.
The "Frame_offset + Chip_offset" 256 chip boundary rounding rules for Node B to
consider for each DL DPCH are:
1. IF (Frame_offset x 38 400 + Chip_offset ) modulo 256 [chips] = {1..127} THEN round
(Frame_offset x 38 400 + Chip_offset) modulo 256 frames down to closest 256 chip
boundary.
2. IF (Frame_offset x 38 400 + Chip_offset ) modulo 256 [chips] = {128..255} THEN
round (Frame_offset x 38 400 + Chip_offset) modulo 256 frames up to closest 256 chip
boundary.
3. IF (Frame_offset x 38 400 + Chip_offset ) modulo 256 [chips] = 0 THEN
"Frame_offset x 38 400 + Chip_offset" is already on a 256 chip boundary.
[FDD –Tm]
The reported Tm parameter has a resolution of 1 chip and a range of 0 to 38399. The Tm
shall always be sent by the UE.
Five different cases are discerned related to the determination of the Tm value by the
UE:
1. The UE changes from common channel state to dedicated channel state: 1 RL
In this case the Tm will be zero.
2. The UE is changes from common channel state to dedicated channel state: several RL's
Tm is in this case defined as being the time difference between the received PCCPCH
path of the camping cell and the received PCCPCH paths of the other candidate cells.
Again the UE sets Tm to zero for the cell to which the UE sends an UL RRC message
(cell #1). For cells #2 to n, the UE sets Tm to the time difference of the PCCPCH
reception timing of cell#2,n from the PCCPCH reception timing of cell#1.
3. The UE adds another RL in dedicated channel state (macro-diversity)
Tm is in this case defined as being the time difference between "TUETX – To" and the
earliest received PCCPCH path of the target cell. TUETX is the time when the UE
transmits an uplink DPCCH frame, hence "TUETX – To" is the "optimum" arrival time for
the first path of a received DPCH.
4. The UE is coming from another RAN and goes to dedicated channel state: 1 RL
This case is identical to case 1.
5. The UE is coming from another RAN or another frequency in the same RAN and goes
to dedicated channel state: several RL's
This case is identical to case 2, with one exception: Tm will not be zero for the cell to
which the UE sends an UL RRC message (the measurement information will be
received via the CN in this case) but for a reference cell selected by the UE. All other
reported Tm values will be relative to the timing of the PCCPCH in this cell.
[FDD – T_cell]
T_cell represents the Timing delay used for defining the start of SCH, CPICH and the DL
Scrambling Code(s) in a cell relative BFN. The main purpose is to avoid having
overlapping SCHs in different cells belonging to the same Node B. A SCH burst is 256
chips long. SFN in a cell is delayed T_cell relative BFN.
Resolution: 256 chips. Range: 0 .. 9 x 256 chips.
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
12
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
t1
RNC specific frame number (RFN) that indicates the time when RNC sends the frame
through the SAP to the transport layer.
t2
Node B specific frame number (BFN) that indicates the time when Node B receives the
correspondent DL synchronisation frame through the SAP from the transport layer.
t3
Node B specific frame number (BFN) that indicates the time when Node B sends the frame
through the SAP to the transport layer.
TOAWS
TOAWS (Time of Arrival Window Startpoint) is the window startpoint. DL data frames
are expected to be received after this window startpoint (see Figure 7). TOAWS is defined
with a positive value relative Time of Arrival Window Endpoint (TOAWE). A data frame
arriving before TOAWS gives a Timing Adjustment Control frame response.
The resolution is 1 ms, the range is: {0 .. CFN length/2 –1 ms}.
TOAWE
TOAWE (Time of Arrival Window Endpoint) is the window endpoint. DL data frames are
expected to be received before this window endpoint (see Figure 7). TOAWE is defined
with a positive value relative Latest Time of Arrival (LTOA). A data frame arriving after
TOAWS gives a Timing Adjustment Control frame response.
The resolution is 1 ms, the range is: {0 .. CFN length –1 ms}.
LTOA
LTOA (Latest Time of Arrival) is the latest time instant a Node B can receive a data frame
and still be able to process it. Data frames received after LTOA can not be processed
(discarded). LTOA is defined internally in Node B to be a processing time before the data
frame is sent in air-interface. The processing time (Tproc) could be vendor and service
dependent.
LTOA is the reference for TOAWE (see Figure 7).
TOA
TOA (Time of Arrival) is the time difference between the TOAWE and when a data frame
is received (see Figure 7). A positive TOA means that data frames are received before
TOAWE, a negative TOA means that data frames are received after TOAWE. Data frames
that are received after TOAWE but before LTOA (TOA+TOAWE>=0) are processed by
Node B.
When RNC measures data frame reception times to determine window position or to
supervise data frame reception times, TOA could be added with TOAWE to make the
measurements window position independent.
TOA has a resolution of 125 µs. TOA is positive when data frames are received before
TOAWE.
The range is: {0 .. +CFN length/2 –125 µs}.
TOA is negative when data frames are received after TOAWE.
The range is: {–125 µs .. –CFN length/2}.
6
Node Synchronisation
6.1
General
By Node Synchronisation it's generally meant the achievement of a common timing reference among different nodes. In
UTRAN although a common timing reference among all the nodes could be useful, it is not required.
In fact, in order to minimise the transmission delay and the buffering time for the transmission on the air interface, it
can be useful to estimate the timing differences between RNC and Node Bs, without the need to compensate for the
phase differences between RNC's and Node B's clocks.
On the other hand the achievement of a common timing reference among Node Bs is needed in TDD to allow Radio
Frame Synchronisation, i.e. the phase differences among Node B's clocks shall be compensated.
For these reasons in UTRAN node synchronisation refers to the following two aspects:
-
RNC-Node B Node Synchronisation;
-
Inter Node B Node Synchronisation.
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
6.1.1
13
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
RNC-Node B Node Synchronisation
The Node Synchronisation between RNC and Node B can be used to find out the timing reference differences between
the UTRAN nodes (RFN in RNC and BFN in Node B). The use is mainly for determining good DL and UL offset
values for frame synchronisation between RNC and their Node Bs. Knowledge of timing relationships between these
nodes is based on a measurement procedure called RNC-Node B Node Synchronisation Procedure. The procedure is
defined in the user plane protocols for Iub (DCH, DSCH, and FACH/PCH) and Iur (DCH). The usage over the CCH
channels, e.g. FACH, is for the actual RNC-Node B Node Synchronisation procedure.
When the procedure is used from SRNC over the DCH user plane, the usage is Round-trip-delay measurements. These
could be used to determine offset values between RNCs and to find out the actual round-trip-delay a certain service has
(as the Node Sync Control Frames are transferred the same way as the DCH frames).
The procedure may also be carried out over a high priority transport bearer (beneficial when used between CRNC and
Node Bs for the RNC-Node B Synchronisation purpose). Measurements of node offsets can be made at start or restart
as well as during normal operation to supervise the stability of the nodes.
If a good Network synchronisation reference is used, the drift between nodes will be low, but could occur. If a Network
synchronisation reference isn't available or is poor (as is the case in some transport network types), the local node
reference oscillator must be relied upon. Then the RNC-Node B Node Synchronisation procedure can be used as a
background process to find out the frequency drift between nodes. Therefore, a system can be deployed without
Network synchronisation references (to e.g. the Node B's).
In the RNC-Node B Node Synchronisation procedure, the RNC sends a DL Node Synchronisation control frame to
Node B cntaining the parameter T1. Upon reception of a DL Synchronisation control frame, the Node B shall respond
with UL Synchronisation Control Frame, indicating t2 and t3, as well as t1 which was indicated in the initiating DL
Node Synchronisation control frame.
6.1.2
Inter Node B Node Synchronisation
In the FDD mode Inter Node B Node Synchronisation could be reached via the RNC-Node B Node Synchronisation in
order to determine inter Node B timing reference relations.
This could be used to determine Inter-cell relationships (via T_cell) which can be used in the neighbour cell lists in
order to speed up and simplify cell search done by UE at handover.
In TDD Inter Node B Node Synchronisation is used to achieve a common timing reference among Node Bs.
TDD may have several solutions for Inter Node B Node Synchronisation:
-
Synchronisation of Node B's to an external reference via a standardised synchronisation port (see section
6.1.2.1);
-
Synchronisation of Node B's on the air-interface, e.g. through Node B's cross measurements.
6.1.2.1
TDD Node B Synchronisation Ports
This section defines the Node B input and an output synchronisation ports that can be used for Inter Node B Node
Synchronisation. These synchronisation ports are optional.
The input synchronisation port (SYNC IN) allows the Node B to be synchronised to an external reference (e.g. GPS),
while the output synchronisation port (SYNC OUT) allows the Node B to synchronise directly another Node B (see
Figure 2).
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
14
E x te rn a l
S y n c.
S o u r ce
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
N od e B
S yn c
S yn c
Inp ut O u tput
P or t
P or t
A da p to r
N od e B
S yn c
S yn c
Inp ut O u tput
P or t
P or t
N od e B
S yn c
S yn c
Inp ut O u tput
P or t
P or t
N od e B
S yn c
S yn c
O u tput Inp ut
P or t
P or t
Figure 2: Usage of Synchronisation Ports
This allows to connect Node B's in a daisy chain configuration, so that a single external reference is enough and all
remaining nodes B can be synchronised (e.g. in case of indoor operation).
The Node B starts the synchronisation to the external reference when a valid input synchronisation signal is detected at
the input synchronisation port.
If a valid synchronisation signal is detected, the Node B regenerates that signal at its output synchronisation port. The
propagation delay between the input and output synchronisation ports shall not exceed 500 ns.
The electrical characteristics of the synchronisation ports shall conform to RS422 [6] (output synchronisation port:
section 4.1; input synchronisation port: section 4.2).
The synchronisation signal (illustrated in Figure 3) is a 100 Hz signal having positive pulses of width between 5 µs and
1 ms. This signal establishes the 10 ms frame interval. The start of a frame is defined by the falling edge of the pulse.
The synchronisation signal at the input port shall have a frequency accuracy better than the one of the Node B.
The relative phase difference of the synchronisation signals at the input port of two neighbouring Node B's shall not
exceed 5 µs.
>5µs
<1 ms
10 ms
Figure 3: Synchronisation signal
Synchronisation by a GPS receiver
The signal transmitted by a Global Positioning System (GPS) satellite indicates the GPS time that provides an absolute
time reference. This makes the GPS receiver suitable for Inter Node B Node Synchronisation.
Inter Node B Node Synchronisation is achieved by relating the synchronisation signal (at the input synchronisation port
to the GPS signal. Since the duration of a UTRAN frame is 10 ms, this implies that every 100 frames the start of a
UTRAN frame coincides with an integer GPS second.
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
6.1.2.2
15
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
TDD Inter Node B Node Synchronisation procedure
In TDD it is assumed that all the cells belonging to the same Node B are synchronised among each other. This means
that as Inter Node B Node Synchronisation is achieved, also cells belonging to those Node B's are synchronised.
In order to achieve Inter Node B Node Synchronisation several solutions can be applied.
In the procedure described in this section it is assumed that Node Bs may be synchronised through an external reference
(e.g. GPS) connected to the input synchronisation port defined in section 6.1.2.1. The other Node Bs may be
synchronised through Node B's cross measurements on the air interface.
All the Node B's that are synchronised through the external source become Reference; all the other Node B's are
synchronised via the air through a master-slave mechanism.
Note that in case of isolated area one of the Node B's could act as a free-running reference, i.e. as a reference not
connected to an external source.
In order to get synchronised a Node B shall listen at an active cell belonging either to a reference Node B or to an
already synchronised Node B (that acts as a master of the synchronisation process for the unsynchronised Node B, i.e.
the slave Node B).
All the Node B's that cannot listen to cells belonging to other Node B's shall be synchronised through their
synchronisation port (i.e. they are References as well).
Note that the propagation delay between a slave cell and its master cell can be determined through cells cross
measurements. This allows the slave cell to take into account this propagation delay when synchronising to its master.
The Inter Node B Node Synchronisation procedure is shown in Figure 4.
RNC 1
RNC 2
Sync
Signal
Node B11
Node B12
Node B13
Node B21
Node B22
Node B23
Reference Node B
Figure 4: TDD Inter Node B Node Synchronisation
In the example of Figure 4 Node B13 is the only Reference, i.e. it is the only one that is synchronised through an
external source. Node B11, Node B12 and Node B21 can listen at least to one cell of Node B13. This means that they
can get synchronised over the air directly to the Reference Node B. On the contrary Node B22 can listen only to a cell
belonging to Node B21. This means that it can get synchronised only to Node B21 that acts as a master for B22 (second
hierarchical level of synchronisation), while Node B23 can get synchronised only to Node B22 that acts as a master for
B23 (third hierarchical level of synchronisation).
The synchronisation hierarchy for the example of Figure 4 is shown in Figure 5.
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
16
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
Reference Node B
Node B13
Node B11
Node B12
Node B21
1st hierarchical level
Node B22
2nd hierarchical level
Node B23
3rd hierarchical level
Figure 5: TDD Synchronisation Hierarchy
7
Transport Channel Synchronisation
7.1
General
The Transport Channel (or L2) synchronisation provides a L2 common frame numbering between UTRAN and UE
(frame synchronisation between the L2 entities). This frame number is the Connection Frame Number (CFN), and it is
associated at L2 to every TBS and passed to L1: the same CFN is received on the peer side associated with the same
TBS.
The CFN is not transmitted in the air interface for each TBS, but is mapped by L1 to the SFN of the first radio frame
used for the transmission of the TBS (the SFN is broadcast at L1 in the BCH). The mapping is performed via the
Frame_offset parameter.
In case of soft handover, the Frame_offsets of the different radio links are selected in order to have a timed transmission
of the diversity branches in the air interface.
A L1-MAC primitive is defined to allow the L1 to indicate to L2 the necessity to adjust the timing of the DL
transmission, in order to control and minimise the transmission delay and the buffering time for the transmission on the
air interface (i.e. to ensure that the TBS does not arrive too much in advance respect to the transmission time). The
primitive is carried in the user plane by Frame Protocol procedures within the UTRAN. This transport channel
synchronisation mechanism is valid for all the transport channels.
Uu
Iub /
Iur
F r a m e _ off s et
SFNCELL1
CFN
SFNCELL1
(In band timing adj.)
Node B 1
F r a m e _ off s et
SFNCELL2
UE
SFNCELL2
CFN
CFN
CFN
MDC
CFN
CFN
CFN
(from the UL
frames)
SRNC
Node B 2
Figure 6: Transport Channel (Layer 2) Synchronisation
7.2
Timing adjustment on Iub/Iur interfaces
A receiving window is configured in Node B at Transport bearer Setup, Addition and Reconfiguration for DL frames
(TOAWS and TOAWE). The purpose is to make it possible to supervise whether data frames are received in the
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
17
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
window or not. When frames are received outside that window, a response is sent to RNC called Timing Adjustment
Control frame. This response contains Time of Arrival information (TOA)(see Figure 7).
The window could be defined to have a margin before LTOA (TOAWE >0). This is to indicate to RNC that data frames
are a bit late but they are still processed by Node B. In this case, data frames are received after TOAWE but before
LTOA.
Offset values, used for sending data frames from RNC over Iub, could therefore be refined by using this window
definition and supervising method.
DL Sync Control frames will always give TOA as response, even if the DL Sync Control frame is received within the
window. The purpose of Sync Control frames is to measure when frames are received for a certain transport bearer.
Data frames received:
Early
OK
Late
Too late
Receiving Window
tproc
TOAWE
LTOA
TOAWS
Positive TOA
DL Air-interface:
N-3
Negative TOA
N-2
N-1
N
t
Note: N-3, N-2, N-1, N represent the value of the CFN
TOA
LTOA
TOAWS
Time Of Arrival
Latest TOA
TOA Window Startpoint
TOAWE
tproc
TOA Window Endpoint
Processing time before
air-interface
Figure 7: Illustration of TOAWS, TOAWE, LTOA and TOA
The window size and position can be chosen with respect to expected data frame delay variation and different macrodiversity leg delays.
8
Radio Interface Synchronisation
8.1
General
This section describes the Radio Interface Synchronisation for FDD and TDD.
8.2
FDD Radio Interface Synchronisation
8.2.1
General
FDD Radio Interface Synchronisation assures that UE gets the correct frames when received from several cells. The UE
measures the Timing difference between its DPCH and SFN in the target cell when doing handover and reports it to
SRNC. SRNC sends this Time difference value in two parameters Frame_offset and Chip_offset over Iub to Node B.
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
18
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
Node B rounds this value to the closest 256 chip boundary in order to get DL orthogonality (regardless of used
spreading factor). The rounded value is used in Node B for the DL DPCH.
DOFF is selected by the SRNC considering the interleaving period (e.g. 10, 20, 40 or 80ms) when entering in dedicated
state from common channel state
Services are scheduled by using DOFF in order to average out the Iub traffic load and the Node B processing load.
DOFF is only used when setting up the first RL in order to initialise Frame_offset and Chip_offset and to tell UE when
frames are expected.
UE uses the UL DPCH as it is a more defined time instant than the DL DPCH as the fingers of the Rake receiver move
all the time due to time-dispersion.
The handover reference is the time instant TUETx -To, which is called DL DPCHnom in the timing diagram.
Tcell is used to skew cells in the same Node B in order to not get colliding SCH bursts, one SCH burst is 1/10 of a slot
time.
The timing diagram shows an example with two cells connected to one UE where handover is done from source cell
(Cell 1) to target cell (Cell 2).
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
DL BFN1
4094
19
4095
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
0
1
2
Tcell
DL SFN1 (Cell 1)
4094
4095
DL SFN1 mod 256
254
255
3
4
SFN is delayed Tcell relative BFN
0
1
2
3
4
0
1
2
3
4
NB1
frames
Rounded (Frame_offset+Chip_offset)
DL DPCH1 (CFN)
252
253
254
255
DL DPCH1 = (SFN 1 - Rounded (Frame_offset +
Chip_offset)) mod 256 frames
DL DPCH1
252
253
Ex: Frame_offset =2, Chip_offset =10240 chips
0
1
2
Tp1
254
255
0
1
2
To +/-α
UL DPCH (TUETx)
252
253
254
255
0
1
2
To
DL DPCHnom(TUETx –To)
UE
252
253
254
Ex: OFF +Tm = 3.3300 frames
255
0
Î OFF =3, Tm=12672 chips.
1
2
DL DPCHnom (TUETx -To) used as ref. at UE.
OFF +Tm = (SFN2 -DPCHnom) mod 256 frames
DL DPCH2
252
253
254
0
255
1
Due to:
Tm
DL SFN2
4095
0
1
4095
3
0
1
2
3
DL DPCH2 (CFN)
252
5
4
5
Ex: Chip_offset =12672 gives 128 chips
rounding error (12800 –12672).
Rounded (Frame_offset + Chip_offset)
NB2
4
DL SFN 2 is delayed Tp2 from NB at UE
Tp2
DL SFN2 (Cell 2)
2
2
Rounding, time dispersion,
frequency drift and moving UE.
253
254
255
0
1
2
DL DPCH2 (CFN) =
(SFN 2 -Rounded (Frame_offset + Chip_offset) ) mod 256 frames
UL DPCH2
252
253
254
255
0
1
UL DPCH2 relative DL DPCH 2 at NB2 is delayed T0 +/-α +2Tp2
α
BFN
CF N
DPCH
HO
NB x
OF F
RFN
R NC
S FN
st
1 received DL DPCH finger relative DL DPCH nom
Node B F rame Number (counter)
Connection F rame Number (DPCH related)
Dedicated Phys ical Channel (CF N related)
Handover
Node B (x: 1=s ource, 2=target)
Offs et with a range from 0 to 255 frames
R NC F rame Number (counter)
R adio Network Controller
S ys tem F rame Number (counter)
T cell
Tm
To
T pX
T UE T x
2
t
S pecifies the S F N delay relative B F N
Meas ured by UE at HO, T m has a range
from 0 to 38399 chips .
Is a cons tant of 1024 chips , is the nominal
difference between firs t received DPCH finger
(DL DPCH nom) and T UE T x at UE .
Propagation delay (one way), UE to Cell X
T he time when UE trans mits an
UL Dedicated Phys ical Channel.
Figure 8: FDD Radio Interface Synchronisation timing diagram
SFN1 is found in Cell 1 at Node B1 and SFN2 at Cell 2 and Node B2. SFN1 is sent T_cell1 after the Node B1 reference
BFN1. CFN is the frame numbering that is related to each DL and UL Dedicated Physical Channel (DPCH). UL DPCH
is sent from UE to both Cells (both Node B's in this example). UL DPCH at Node B2 is shown to indicate the difference
to the DL DPCH2 at Node B2.
The new RL (DL DPCH2) which is setup at the HO will face some deviation from nominal position due to the rounding
of Frame_offset and Chip_offset to 256 chip boundary in Node B. Also Time dispersion, Node B-UE frequency drift
and UE movement affects this phase deviation.
The nominal DL DPCH timing at UE is To before the TUETX time instant, which could be expressed:
DL DPCHnom = TUETX -To
In UE dedicated state, OFF and Tm are measured at UE according to the following equation:
3GPP
ETSI
(8.1)
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
20
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
OFF + Tm = (SFNtarget –DL DPCHnom) mod 256 frames [chips]
NOTE:
(8.2)
OFF has the unit Frames and Tm the unit Chips.
Example: assume that OFF + Tm equals "3.3300" frames (as given as an example in Figure 8).
Then OFF = 3 and Tm = "0.33" which corresponds to Tm = 12672 chips.
In other words (referring to the timing diagram in Figure 8):
-
How to determine Tm at UE: Select a time instant 1) where frame N starts at DL SFN2 e.g. frame number 3, the
time from that time instant to the next frame border of DL DPCHnom 2) equals Tm
(if these are in phase with each other, Tm is zero).
How to determine OFF: The difference between the frame number selected for time instant 1) and the frame number
starting at instant 2) mod 256 frames equals OFF.
Example: (3 –0) mod 256 = 3, another example is (1 –254) mod 256 = 3.
8.2.2
Neighbour cell list timing information
A cell can optionally broadcast a neighbouring cell list that indicates timing information for neighbouring cells. The list
contains the inter cell timing difference to neighbour cells with associated estimated uncertainty. The inter cell timing
uncertainty depends on what timing difference estimating means that are used in the system (No means at all, Node
sync measurements, UE inter-cell measurements, Cells belonging to the same Node B or even GPS). The purpose with
the neighbouring cell list timing information is to enable shorter cell search time for UE, to save UE battery and to
potentially lower BCH Tx power for cells in a synchronised cluster.
8.3
TDD Radio Interface Synchronisation
8.3.1
General
The TDD Radio Interface Synchronisation relates to the following two aspects:
-
Radio Frame Synchronisation;
-
Timing Advance.
In TDD mode Radio Frame Synchronisation among Node B's is achieved by means of the Inter Node B Node
Synchronisation that allows to achieve a common timing reference among Node B's. Radio Interface Synchronisation
between UE and UTRAN is achieved by means of the Timing Advance mechanism.
8.3.2
Radio Frame Synchronisation
Radio Frame Synchronisation is necessary to ensure that the uplink/downlink switching points are positioned at the
same time instant at least in adjacent cells (see Figure 9).
This requirement is necessary to avoid that a receiving UE can be saturated by a transmitting UE in a neighbouring cell.
In addition it automatically ensures that the slots of different cells are synchronised, i.e. they do not overlap at the UE.
FRAME K
Node B-1
1
2
3
9
10
11
1
2
3
9
10
11
Node B-2
ACTIVE SLOTS
FRAME N
Figure 9: Radio Frame Synchronisation
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
8.3.3
21
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
Timing Advance
Timing Advance is used in uplink to align the uplink radio signals from the UE to the UTRAN both in case of uplink
Dedicated Physical Channels (DPCH) and of Physical Uplink Shared Channels (PUSCH).
The handling of timing advance can be divided in four main categories: measurement, initial assignment, correction
during operation, and setting on handover. For each category, a number of different cases can be distinguished.
1. Measurement of the timing offset on the physical channels:
-
On PRACH transmissions;
-
On DPCH transmissions;
-
On PUSCH transmissions.
2. Assignment of correct timing advance value when establishing new channels:
-
At switch to DCH/DCH state;
-
At switch to USCH state.
3. Correction of timing advance value for channels in operation:
-
At least one uplink DCH in operation;
-
Only USCH in operation.
4. Setting of timing advance value for target cell at handover.
8.3.3.1
Measurement of the timing offset on the physical channels
Timing offset measurements are always performed in the physical layer in Node B. These measurements have to be
reported to the higher layers, where timing advance values are calculated and signalled to the UE. For this reporting, a
number of different ways are foreseen, depending on the used channels.
PRACH:
The Node B physical layer measures the timing accuracy of the RACH bursts transmitted by the
UE. It measures the timing offset of the received signal (Rx Timing Deviation) and passes this
together with the transport block to the CRNC (by means of the Iub RACH Frame Protocol). In
case the PRACH supports a DCH, the measured timing offset may be passed from DRNC to the
SRNC over Iur interface (by means of the Iur RACH Frame Protocol).
PUSCH:
The Node B physical layer measures the timing accuracy of the PUSCH bursts transmitted by the
UE. It measures the timing offset of the received signal (Rx Timing Deviation) and passes this
together with the transport block to the CRNC (by means of the Iub USCH Frame Protocol).
DPCH:
The Node B physical layer measures the timing accuracy of the DPCH bursts transmitted by the
UE. It measures the timing offset of the received signal (Rx Timing Deviation) and passes this
together with the transport block to the SRNC (by means of the Iub & Iur DCH Frame Protocols).
8.3.3.2
8.3.3.2.1
Assignment of correct timing advance value when establishing new channels
Switch to DCH/DCH state
The transition to DCH/DCH state from USCH/DSCH state, RACH/FACH state or Idle Mode operates in the following
manner:
-
The SRNC checks whether an up to date timing offset measurement is available. Such a measurement can be
available from a recent RACH access (e.g. from initial access) or from a recent USCH transmission. If no up to
date timing offset measurement is available, the SRNC has to trigger an uplink transmission from the UE before
it can assign a DCH. The SRNC calculates the required timing advance value and saves it in the UE context for
later use in dedicated or shared channel activation.
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
22
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
-
The SRNC attaches the timing advance value to the channel allocation message that it signals to the UE via
FACH (RRC CONNECTION SETUP or RADIO BEARER SETUP).
-
When the UE receives the channel allocation message it configures its physical layer.
8.3.3.2.2
Switch to USCH state
For uplink traffic using the USCH, short time allocations are sent to the UE regularly. Therefore switch to USCH is
very similar to handling of timing advance updates during USCH operation. The UTRAN only has to check, whether an
up to date timing offset measurement is available. Such a measurement can be available from a recent RACH access
(e.g. from initial access). If no up to date timing offset measurement is available, the UTRAN has to trigger an uplink
transmission from the UE before it can assign an USCH.
8.3.3.3
Correction of timing advance value for channels in operation
8.3.3.3.1
UE in Traffic using at least one uplink DCH
An UE that is operating a dedicated channel (DCH/DCH state), has to update the timing advance from time to time to
keep the received signal at the Node B within the required time window. Under reasonable assumptions the worst case
update frequency is in the order of 8 seconds.
The timing correction procedure operates in the following manner:
1. The SRNC determines whether a new timing advance value has to be transmitted to the UE taking into account
when the last correction was signalled.
2. Timing advance corrections are signalled to the UE via RRC signalling on FACH or DCH (PHYSICAL
CHANNEL RECONFIGURATION, TRANSPORT CHANNEL RECONFIGURATION or RADIO BEARER
RECONFIGURATION).
3. When the UE receives the a new timing advance value, it configures its physical layer.
There is no need for the UE to acknowledge the timing correction message:the Node B periodically measures the UE
timing accuracy, and the UE reports the received timing advance value as part of the measurement reporting. The
SRNC is then able to detect when a timing advance message has not been received and needs to be resent .
8.3.3.3.2
UE in Traffic using only USCH
The timing correction procedure operates in the following manner:
1. The CRNC determines whether a new timing advance value has to be transmitted to the UE taking into account
when the last correction was signalled. Two cases are possible:
-
if the data transfer is uplink after a longer idle period then the UE has to transmit a capacity request on the
RACH. The CRNC is therefore informed of any timing error on this RACH.
-
if a new allocation follows an USCH transmission, the timing error is already known to the CRNC from
measurements of the last uplink transmission.
2. If a Timing Advance update is needed, the CRNC includes a new timing advance value in the next USCH
allocation message to the UE (PHYSICAL SHARED CHANNEL ALLOCATION).
3. When the UE receives the a new timing advance value, it configures its physical layer.
8.3.3.4
Setting of timing advance value for target cell at handover
Handover between different cells requires the correct setting of the timing advance for the target cell, before uplink
traffic transmission is allowed. Since the TDD system has synchronised base stations, a UE is able to measure the time
offset between the two cells and, consequently, is able to correct its timing on handover without UTRAN assistance.
However to improve the accuracy for the calculated timing advance, the SRNC can include the measured timing offset
value in the HANDOVER COMMAND message.
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
23
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
After a successful handover, a HANDOVER COMPLETE message is transmitted in the new cell. In this message, the
UE can report the calculated timing advance, which is used for access to the new cell. By this way, the SRNC is
informed as fast as possible about the timing advance in the UE, and it can correct the timing advance if necessary.
9
Usage of Synchronisation Counters and Parameters
to support Transport Channel and Radio Interface
Synchronisation
9.1
General
This section describes how the different synchronisation parameters are computed and used in order to obtain Transport
Channel (L2) and Radio Interface (L1) Synchronisation.
The parameter that need to be determined by the UE are CFN, OFF and Tm (FDD only).
The parameter that need to be determined by the UTRAN are DOFF (FDD only), Frame_offset and Chip_offset (FDD
only).
Figure 10 summarises how these parameters are computed. A detailed description of the actions in each state is given in
the following sub-sections.
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
24
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
Common CH State
UE
CFN = SFN mod 256
UTRAN
Frame_offset = 0
Dedicated CH State (1 RL)
[FDD] CFN = ((SFN*38400 - DOFF*512) div 38400) mod 256
[TDD] CFN = SFN mod 256
UE
DOFF (*)
UTRAN
[FDD] DOFF generated by SRNC
Frame_offset*38400 +Chip_offset = DOFF*512 ➔ Frame_offset & Chip_offset
[TDD] Frame_offset = 0
FDD only
[FDD] Dedicated CH State (several RL’s)
CFN = ((SFN*38400 + DOFF*512) div 38400) mod 256
OFF = (CFN - SFN)mod 256
UE
DOFF
UTRAN
DOFF generated by SRNC
Frame_offset*38400 +Chip_offset = DOFF*512 + OFF*38400 + Tm ➔ Frame_offset & Chip_offset
OFF
Tm
FDD only
Dedicated CH State (additional RL or UE moves to another cell)
[FDD] OFFtarget + Tm target= (SFNtarget -CFN) mod 256
[TDD] OFFtarget = (SFNtarget -CFN) mod 256
UE
UTRAN
(*)
[FDD] Frame_offset*38400 +Chip_offset = OFFtarget *38400 + Tm ➔ Frame_offset & Chip_offset
[TDD] Frame_offset = OFFtarget
OFFtarget]
Tm (*)
only in FDD
Figure 10: Calculations performed by UE and UTRAN
Figure 11 describes what offset parameters are signalled and used in the different nodes at Initial RL setup and at
Handover (HO) in FDD. The rounding to closest 256 chip boundary is done in Node B. The rounded Frame_offset and
Chip_offset control the DL DPCH air-interface timing. The 256 chip boundary is to maintain DL orthogonality in the
cell (the rounding to the closest 256 chip boundary is done in Node B to facilitate the initial UL chip synchronisation
process in Node B).
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
UE
25
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
Node B
Node B
Source cell
Target cell
SRNC
DOFF
(RRC)
At
initial
RL
Frame_offset + Chip_offset
(NBAP)
DL DPCH
(Uu)
DL DPCHnom
=TUETx –To (UE)
DL SFN
timing reference (Uu)
At
HO
Timing difference
=”OFF+Tm” (RRC)
Frame_offset + Chip_offset
(NBAP)
DL DPCH
(Uu)
Node B rounds Frame_offset +
Chip_offset to closest 256 chip boundary,
which controls the DL DPCH air-interface
Air-interface channel timing
(Uu and Uu related in UE)
Signals over a certain protocol
(NBAP or RRC in this case)
Figure 11: [FDD] Usage of Offset values at initial RL and at HO
Figure 12 describes what offset parameters are signalled and used in the different nodes at Initial RL setup and at
Handover (HO) in TDD.
UE
At
initial
RL
Node B
Node B
Source cell
Target cell
SRNC
Frame_offset
(NBAP)
DL DPCH
(Uu)
DL SFN
timing reference (Uu)
DL SFN
timing reference (Uu)
At
HO
Timing difference =”OFF”
(RRC)
Frame_offset
(NBAP)
DL DPCH
(Uu)
Node B controls the DL DPCH air-interface timing
Air-interface channel timing
(Uu and Uu related in UE)
Signals over a certain protocol
(NBAP or RRC in this case)
Figure 12: [TDD] Usage of Offset values at initial RL and at HO
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
9.2
26
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
Calculations performed in the UTRAN
This chapter describes how an SRNC can calculate the Frame_offset and Chip_offset based on the parameters received
from the UE and available in the UTRAN.
9.2.1
UE in common channel state
In common channel state (UE on RACH/FACH), the Frame_offset is set to 0.
9.2.2
UE changes state from common CH state to dedicated CH state: 1
RL
In FDD, based on the received parameters from the UE and the DOFF value generated in the SRNC, the SRNC
calculates the Frame_offset and the Chip_offset:
Frame_offset*38400 +Chip_offset = DOFF*512
(9.1)
In TDD Frame_offset = 0.
9.2.3
UE changes state from common CH state to dedicated CH state:
several RL's (FDD only)
Based on the received parameters from the UE and the DOFF value generated in the SRNC, the SRNC calculates the
Frame_offset and the Chip_offset. The Frame_offset and the Chip_offset are calculated from the following formula:
Frame_offset*38400 +Chip_offset = DOFF*512 + OFF*38400 + Tm
NOTE:
9.2.4
(9.2)
that formula (9.2) is covering formula (9.1) since in case 1, OFF and Tm are both equal to zero.
UE in dedicated CH state request to add a new RL or moves to
another cell
In FDD, based on the received parameters from the UE, the SRNC calculates the Frame_offset and the Chip_offset with
the following formula:
Frame_offset*38400 +Chip_offset = OFF*38400 + Tm
(9.3)
In TDD Frame_offset = OFF.
9.2.5
Handover from other RAN to UMTS
In FDD, based on the definitions for OFF and Tm formula (9.1) can also be used when the UE enters the UTRAN from
another CN and establishes 1 dedicated RL. The same is true for formula (9.2) when establishing 1 or more dedicated
RL's.
In TDD when the UE enters the UTRAN from another CN and establishes 1 dedicated RL, OFF is 0.
9.3
Calculations performed in the UE
9.3.1
First RL
In FDD, based on the received DOFF and the SFN of the cell in which the UE is camping, the UE can calculate the
CFN with the following formula:
CFN = ((SFN*38400 - DOFF*512) div 38400)mod 256
In TDD the CFN is initialised with the value:
3GPP
ETSI
(9.4)
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
27
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
CFN = SFN mod 256
NOTE:
9.3.2
(9.5)
in case the UE is coming from another RAN, the SFN is not the SFN from the camping cell but the SFN
from the reference cell. In this case the OFF is set to 0.
Additional RL's or UE moves into a new cell
As long as the UE has one or more RL's established, the CFN will be increased (mod 256) by 1 every frame. Normally
no special corrections are needed when moving from one cell to the other.
However every time the UE enters a new cell (target cell), OFF might have to be reported.
In FDD Tm is always reported. The target cell OFF is calculated using the following formula:
OFFtarget + Tmtarget= (SFNtarget -CFN) mod 256
NOTE:
(9.6)
OFF is calculated as the integer number of frames, Tm is the Frame fractional part with the unit chips.
In TDD the target cell OFF is calculated using the following formula:
OFFtarget = (SFNtarget -CFN) mod 256
9.4
(9.7)
Synchronisation of L1 configuration changes
When a synchronised L1 configuration change shall be made, the SRNC commands the related Node B's to prepare for
the change. When preparations are completed and SRNC informed, serving RNC decides appropriate change time.
SRNC tells the CFN for the change by a suitable RRC message. The Node B's are informed the CFN by RNSAP and
NBAP Radio Link Reconfiguration procedures.
At indicated switch time UE and Node B's change the L1 configuration.
3GPP
ETSI
3G
(3GTS
TS25.402
25.402version
version3.0.0
3.0.0Release
Release1999
1999)
2000)
28
3GTS
TS125
25.402
ETSI
402 V3.0.0 (2000-01)
Annex A (informative):
Change history
TSG RAN#
RAN_06
Version
-
CR
-
Tdoc RAN
RP-99739
Change history
New Version
Subject/Comment
3.0.0
Approved at TSG RAN #6 and placed under Change Control
Rapporteur for TS25.402 is:
Flavio Piolini
Siemens Information & Communication Networks S.p.A.
Mobile Networks - System Engineering GSM and UMTS
20060 Cassina de' Pecchi (MI)- Italy
S.S. 11 Padana Superiore Km. 158
Phone: (+39) 02 43886527
Fax: (+39) 02 43886550
Email: flavio.piolini@siemens-icn.it
3GPP
ETSI
(3G TS 25.402 version 3.0.0 Release 2000)
29
History
Document history
V3.0.0
January 2000
Publication
ETSI
ETSI TS 125 402 V3.0.0 (2000-01)
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising