TICTOC Linlang Zhou
Internet Draft China Mobile
Intended status: Informational July 7, 2008
Expires: January 2009
RAN Synchronization Requirements
draft-zhou-tictoc-ran-sync-req-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into
languages other than English, other than to extract section XX as-is
for separate use.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
Zhou Expires January 2009 [Page 1]
Internet-Draft RAN Synchronization Requirements July 2009
This Internet draft describes RAN synchronization requirements,
mainly about synchronization description and requirements, also includes
some applications and problem description.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
Table of Contents
1. Introduction................................................2
2. Applications Description.....................................3
2.1. Time Service Applications...............................3
2.2. Frequency Service Applications..........................3
3. Synchronization Description and Requirements.................3
3.1. Network Synchronization.................................4
3.1.1. Synchronization Description........................4
3.1.2. Minimum Requirements...............................4
3.2. Node Synchronization....................................5
3.2.1. Synchronization Description........................5
3.2.2. Minimum Requirements...............................5
4. Security Considerations......................................6
5. IANA Considerations.........................................6
6. Acknowledgments.............................................6
7. References..................................................7
Author's Addresses.............................................7
Intellectual Property Statement.................................7
Disclaimer of Validity.........................................7
1. Introduction
RAN has its own synchronization requirements whatever its
backhaul is based on IP/MPLS packet switched networks or TDM/ATM links.
Besides radio interface synchronization for the NodeB, both Iub and Iu
have the same synchronization requirements when is based on packet network.
In this RAN synchronization requirements we give some applications
description about UTRAN synchronization. Also we list synchronization
scenarios in UTRAN and give the detail requirements.
Zhou Expires January 2008 [Page 2]
Internet-Draft RAN Synchronization Requirements July 2008
2. Applications Description
2.1. Time requirements by Service Applications
There are many applications in telecommunications that need to know
the time with great precision. RAN system has to provide precise time
synchronization, for there would be some services which require great
precision such as position services, streaming services, etc. In TDD
mode of 2G/3G systems, in radio interface time synchronization is also
needed for smooth handover.
2.2. Frequency requirement by Service Applications
Cellular base stations require a highly accurate frequency synchronization
as reference from which they derive transmission frequencies and operational
timing however their transport is over E1/T1 or PSN, such as Ethernet IP and
MPLS. The radio frequencies should be accurate. To use radio spectrum efficiently
transmission frequencies which are allocated to a given base station and its
neighbors had better not interfere with each other. There is an additional
requirement derived from the need for smooth handover when a mobile station
crosses from one cell to another.
3. Synchronization Description and Requirements
As to RAN synchronization issues, we may say it include "Network
synchronization" "Node Synchronization" "Transport Channel
synchronization" "Radio Interface synchronization" "Time Alignment
Handling" "Uplink synchronization"[1]. Actually when we mention these
six "Synchronization",we mean different synchronization mechanisms in
RAN system, and not mean synchronization requirements. AS to RAN
synchronization requirements, it can be more simple. We could conclude
into only two kinds of synchronization requirements: network
synchronization and node synchronization.
Zhou Expires January 2009 [Page 3]
Internet-Draft RAN Synchronization Requirements July 2008
|-------|
|Vocoder|
|-------| ---
| |
|TIME ALIGNMENT |
|-------|
| |
| RNC |
|-------| NNETOWRK ---
| | |
| | SYNC NODE
|-------| |-------|
| Node | | Node | |
| B | | B | | SYNC
|-------| |-------| | |
| | | |
+-------+ --- ---
| |
| UE |
|-------|
Figure 1 RAN SYNC REQUIREMENTS
3.1. Network Synchronization
3.1.1. Synchronization Description
Network synchronization relates to the distribution of
synchronization references to the RAN Nodes and the stability of the
clocks in the RAN. This distribution of synchronization references
includes the distribution in Iu interface, Iub interface and radio
interface. To fulfill the distribution of an accurate frequency
reference to the network elements in the UTRAN, network has to
provide a synchronization reference with enough frequency accuracy.
RNC should be able to pick-up synchronization information from Iu
interface. Synchronization of Iub interface is provided from RNC. The
clock to be implemented in UTRAN Nodes shall be chosen with
characteristics that depend on the L1 adopted. For example in order
to support STM-N interfaces at the RNC, the ITU-T Recommendation
G.813 (see reference) may be sufficient. But we still have some
common requirement for RNC.
3.1.2. Minimum Requirements
The reference frequency accuracy of RNC shall be better than or
equal to 4.6ppm.When outside reference clock is invalid, system clock
Zhou Expires January 2009 [Page 4]
Internet-Draft RAN Synchronization Requirements July 2008
of RNC should be able to change into Holdover mode. Output of system
clock should be able to hold original phase and accuracy of 4.6ppm.
As to Iub and Iu interfaces, different L1 links and interfaces
have different synchronization requirement. For E1 interfaces
frequency accuracy should be better than or equal to 50ppm(see
reference to ITU-T G.703).For STM-N interfaces frequency accuracy
should be better than or equal to 4.6ppm see (reference to ITU-T
G.813).For packet switched network frequency accuracy requirement
level is not so strict.
The frequency accuracy of base stations shall be better than or
equal to 0.05ppm on the radio interface whatever based TDD mode or
FDD mode.
3.2. Node Synchronization
3.2.1. Synchronization Description
Node Synchronization relates to the estimation and compensation
of timing difference among RAN nodes. Node synchronization includes
two types: "RNC-NodeB" and "Inter NodeB" Node Synchronization.
"RNC-NodeB" Node Synchronization allows getting knowledge of the
timing differences between RNC and its NodeBs. When there is some
position service, "RNC-NodeB" Node Synchronization would be important.
"Inter NodeB" Node Synchronization aims to achieve a common
timing reference among NodeB's. The achievement of a common timing
reference among NodeB's may be used in TDD to support Cell
synchronization in order to minimize cross-interference.
3.2.2. Minimum Requirements
As to "RNC-NodeB" Node Synchronization, timing accuracy
requirement level in packet switched network is not so strict. For
example as to Ethernet, better than 1ms may be sufficient. If position
service is provided, the requirements of "RNC-NodeB" synchrinization
are to be discussed.
"Inter NodeB" Node Synchronization in TDD should be better than
or equal to 3us. Base station synchronization accuracy is defined as
the maximum deviation in frame start times between any pair of base
stations on the same frequency that have overlapping coverage areas.
Zhou Expires January 2009 [Page 5]
Internet-Draft RAN Synchronization Requirements July 2008
If "Inter NodeB" Node Synchronization pick-up radio timing
reference from external clock reference, such as GPS, then
the timeing accuracy requirement between NodeB and reference clock
should be better than or equal to 1.5us.
If "Inter NodeB" Node Synchronization pick-up radio timing
reference from Iu interface, then the timeing accuracy requirement
between NodeB and reference RNC should be better than or equal to 1.5us.
4. Security Considerations
Time and frequency services are critical in RAN. Hence time and
frequency transfer services MUST be protected from being compromised.
The most significant threat is a false time or frequency server being
accepted instead of a true one, thus enabling a hacker to bring down
critical services. Any protection mechanism must be designed in such
a way that it does not degrade the quality of the time transfer.
5. IANA Considerations
No IANA actions are required as a result of the publication of
this document.
6. Acknowledgments
Zhou Expires January 2009 [Page 6]
Internet-Draft RAN Synchronization Requirements July 2008
7. References
[3GPP TR 25.402 V7.3.0] "Synchronisation in UTRAN Stage 2(Release7)",
June 2007
[IETF draft-bryant-tictoc-probstat-00]S.Bryant Y(J).Stein "TICTOC
Problem Statement", January 19, 2007
Author's Addresses
LinLang Zhou
China Mobile
53A, Xibianmennei Ave.
Xuanwu District
Beijing China
Email: zhoulinlang@chinamobile.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
Zhou Expires January 2009 [Page 7]
Internet-Draft RAN Synchronization Requirements July 2008
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhou Expires January 2009 [Page 8]