Network Working Group Kuiwen Ji Huawei Internet Draft Category: Informational Expires: August 2008 February 19, 2008 IEEE1588V2 telecom profile framework draft-ji-tictoc-1588-telecom-profile-framework-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. 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 August, 2008. Abstract This Internet draft proposes the framework of IEEE1588V2 telecom profile. Ji Expires August 3, 2008 [Page 1] Internet-Draft IEEE1588V2 telecom profile framework February 2008 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................................................3 2. Requirement.................................................3 2.1. Wireless...............................................3 2.1.1. CDMA2000 Base Station (frequency and time synchronization).........................................3 2.1.2. UMTS TDD Base Station (frequency and phase synchronization).........................................4 2.1.3. TD-SCDMA Base Station (frequency and phase synchronization).........................................4 2.2. Other domains..........................................5 2.3. Scenario...............................................5 3. Interface...................................................6 3.1. Interface type.........................................6 3.2. Performance............................................6 4. Modeling....................................................6 4.1. On-pass support........................................6 4.1.1. Boundary Clock....................................7 4.1.2. End-to-End Transparent Clock......................8 4.1.3. Peer-To-Peer Transparent Clock....................8 4.2. No on-pass support.....................................9 4.3. Hybrid................................................11 5. Time Distribution..........................................11 6. Security Considerations....................................11 7. IANA Considerations........................................11 8. Acknowledgments............................................11 9. References.................................................12 9.1. Normative References.................................12 9.2. Informative References...............................12 Author's Addresses............................................12 Intellectual Property Statement...............................12 Disclaimer of Validity........................................13 Copyright Statement...........................................13 Acknowledgment................................................13 Ji Expires August 3, 2008 [Page 2] Internet-Draft IEEE1588V2 telecom profile framework February 2008 1. Introduction There are various telecommunications applications that can potentially be supported by methods of timing distribution. Timing distribution includes frequency, phase and time synchronization. In this document we only consider phase or time synchronization (they may need frequency synchronization also). To allow IEEE-1588 to satisfy the need(s) of the applications requiring timing, it is necessary to ensure that all IEEE-1588 capable devices have the features and performance to support the applications at the appropriate level. That is, the timing distribution method must be fit-for-purpose. It's necessary to define a telecom profile immediately. Some of the considerations in developing the profile are described below include: -- Requirement -- Interface -- Modeling -- TOD Distribution 2. Requirement Various of applications in telecom need different kinds of synchronization. At first, it's important to provide some explanatory information about it. Of course the profile and solution should suit them. ITU-T Recommendation G.8261/Y.1362 summarizes some of it. 2.1. Wireless Within this general use-case category there are several applications of importance. The application, from the viewpoint of timing, is to deliver the appropriate timing information to a base station (e.g. Node B). 2.1.1. CDMA2000 Base Station (frequency and time synchronization) The relevant CDMA2000 standards are the 3GPP2 C.S0010-B and 3GPP2 C S0002-B. According to the CDMA2000 specifications the average frequency difference between the actual CDMA transmit carrier frequency and Ji Expires August 3, 2008 [Page 3] Internet-Draft IEEE1588V2 telecom profile framework February 2008 specified CDMA transmit frequency assignment shall be less than 50 ppb. In the CDMA2000 specifications it is also specified that each base station shall use a time base reference that is time-aligned to CDMA System Time. CDMA System Time is synchronous to UTC time (except for leap seconds) and uses the same time origin as GPS time. All base stations use the same System Time (within a small error tolerance). For all base stations, the pilot time alignment error should be less than 3us and shall be less than 10us. Because of the above requirements it is a common practice to equip CDMA base stations with GPS receivers. 2.1.2. UMTS TDD Base Station (frequency and phase synchronization) The timing requirement applicable to the WCDMA TDD radio interface can be found in the technical specification TS 125.105 [B5]. The radio interface requirement for UMTS TDD base stations is a frequency accuracy of 50ppb; for the TDD mode there is the additional requirement for the phase alignment of neighboring base stations to within 2.5us. Note: GSM and UMTS FDD require the frequency accuracy to be less than 50ppB, but no need for phase alignment. 2.1.3. TD-SCDMA Base Station (frequency and phase synchronization) The timing requirement applicable to the TD-SCDMA radio interface can be found in the technical specification 3GPP TR 25.836. The radio interface requirement for TD-SCDMA base stations is a frequency accuracy of 50ppb; there is the additional requirement for the phase alignment of neighboring base stations to within 3us (this requirement is then measured comparing the phase between adjacent Base Stations). Because of the above requirements it is a common practice to equip TD-SCDMA base stations with GPS receivers. Note: the requirements listed in the previous clauses apply to the radio interface. When time or frequency reference is carried by the network, other requirements apply. These depend on several factors such as Radio Base Station oscillator characteristics, filter capability of the Radio Base Station, etc. As an example, Ji Expires August 3, 2008 [Page 4] Internet-Draft IEEE1588V2 telecom profile framework February 2008 frequency accuracy significantly better than 50 ppb may be required for the reference timing signal carried over the network in case of 50 ppb frequency accuracy requirement shall be fulfilled on the radio interface. The value of 16 ppb (ITU-T G.812 Type II frequency accuracy) has sometimes been mentioned. Similarly, in case accurate time and/or phase shall be distributed to the Radio Base Stations, the budget to be allocated to the network might be much smaller than the requirements defined by the wireless standards to be fulfilled on the radio interface. These aspects are for further study. The things we need to do is cooperation with these standard bodies to specify the phase/time requirement of Base Station network interface. 2.2. Other domains Besides wireless application there are other applications that need phase and/or time synchronization such as DVB, IPTV, etc. We propose to address wireless application first. 2.3. Scenario +---+---+ | Time | + Server+ | | +-------+ / / / +--+--+ +--+--+ +----+----+ | | | | | Base | + NE +-------------+ NE +-----+ Station + | | | | | | +-----+ +-----+ +---------+ | | | | | | +--+--+ +--+--+ | | | | + NE +-------------+ NE + | | | | +-----+ +-----+ | | | | | | +----+----+ +----+----+ | Base | | Base | + Station + + Station + | | | | +---------+ +---------+ Figure1. Wireless application Ji Expires August 3, 2008 [Page 5] Internet-Draft IEEE1588V2 telecom profile framework February 2008 Figure 1 shows an example scenario for wireless application. Base stations get time information from server though backhaul network. Time server can be an SSU or be integrated in the RNC (BSC). 3. Interface As the Figure 1 shows, there are two important time interfaces we should consider. One is the interface between time server and NE (interface A). Another is the interface between Base station and NE (interface B). 3.1. Interface type To transport time information, using the Ethernet interface like FE or GE using IEEE-1588V2 is a natural solution. 2048 kbit/s or 1544 kbit/s interfaces defined in G.703 have been use for a long time for transport frequency information in telecom. Is it necessary to define such a standard time interface? 3.2. Performance The requirements listed above apply to the radio interface in Base station. Interface B is network interface of Base station. It's necessary to talk about the requirement of interface B with different wireless standard body. Then we can specify the requirement of interface A. The budget between interface A and B is the specification for network equipments. 4. Modeling There was discussion on the email reflector about different solution. One key issue is whether or not to use IEEE-1588 on-pass support. 4.1. On-pass support 'IEEE-1588 on-pass support' means that every node in the synchroization chain from master to slave (server to client) can support IEEE-1588. Three situations are listed in sections 4.1.1, 4.1.2 and 4.1.3. In this case, many parameters are required to be specified in a profile, a list of them is proposed, but it is certainly not yet exhaustive. -- Size of the network (number of NEs in a synchronization chain). Ji Expires August 3, 2008 [Page 6] Internet-Draft IEEE1588V2 telecom profile framework February 2008 -- Characteristic of clocks (bandwidth, tolerance, noise generation, etc.). -- Types of IEEE-1588-V2 messages and packet rate. -- Network Limits (see section 3.2). -- Availability of a master clock protection mechanism (see section 5). 4.1.1. Boundary Clock The general concept of delivering time information by Boundary Clock (BC) modeling is given in Figure 2. There may be a number of BC nodes involved in the distribution of the reference time signal. In such cases, the synchronization function providing filtering and maybe holdover within these nodes must be able to recover time synchronization from master. Synchronization is transported one by one in a similar way to Synchronous Ethernet. +----+----+ +--+---+ +--+---+ +----+----+ | Time | | | | | | | | Server M|<<--->>|S BC M|<<--->>|S BC M|<<--->>|S Client | | | | | | | | | +---------+ +------+ +------+ +---------+ Figure2. BC modeling Note: It has been mentioned 1588 can be used combined with Sync-E. In this case, the different parameters need to be considered. Shall we consider it? Ji Expires August 3, 2008 [Page 7] Internet-Draft IEEE1588V2 telecom profile framework February 2008 4.1.2. End-to-End Transparent Clock As shows in figure3, the End-to-End Transparent Clock (E2ETC) is totally different from Boundary Clock. Each E2ETC node involved in the distribution of the reference time signal doesn't need to synchronize to the master. They measure the residence time of PTP event messages (the time the message takes to traverse the transparent clock node). These residence times are accumulated in a special field -called Correction Field. +----+----+ +--+---+ +--+---+ +----+----+ | Time | | | | | | | | Server M|<<--->>|T TC T|<<--->>|T TC T|<<--->>|S Client | | || || || ^| | | | +---------+| |+------+| ^+------+ +---------+ | v v ^ | v v | | +-+-+-+-+-+ | | | Resident| | | | time | | v +-+-+-+-+-+ | v | | +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | ...... | | | ...... | | | | | | +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | PTP paylaod | | | PTP paylaod | | | v | | +-+-+-+-+-+-+-+-+ v +-+-+-+-+-+-+-+-+ | Correction | v | Correction | | field |>>+>>>| field | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | ...... | | ...... | | | | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ Figure 3, E2ETC modeling 4.1.3. Peer-To-Peer Transparent Clock The Peer-To-Peer Transparent Clock (P2PTC) differs from the End-To-End Transparent Clock in the way that it computes the link delay in addition to the residence time delay. It uses the Pdelay_Req, Pdelay_Resp, and possibly Pdelay_Resp_Follow_Up messages to compute the link delay. The P2PTC computes the link delay between two adjacent nodes. The appropriate Correction Field is updated for both the Ji Expires August 3, 2008 [Page 8] Internet-Draft IEEE1588V2 telecom profile framework February 2008 residence time of the message within the P2PTC nodes and for the link delay on the port receiving the message. Note: performance may be improved if E2ETC or P2PTC nodes implement frequency synchronization similar to Ordinary Clocks (OC) or Synchronous Ethernet. 4.2. No on-pass support The second methods relies on time information such as IEEE-1588 messages carried by the network without 1588 support (no BCs or TCs) as shown in Figure 5. In case the intermediate nodes does not have IEEE-1588 support especially where legacy equipment is used, this is the only alternative to achieve time synchronization. It's not necessary for the support of a network-wide 1588 reference. Therefore the performance is highly impacted by Packet Delay Variation in the network. In order to minimize the impact from the packet network, specific algorithms may need to be implemented at the slave side, depending on the required accuracy. Ji Expires August 3, 2008 [Page 9] Internet-Draft IEEE1588V2 telecom profile framework February 2008 In this case, many parameters are required to be specified in a profile, a list of them is proposed, but it is certainly not yet exhaustive. -- Size of the network and relevant PDV. -- Characteristic of clocks (bandwidth, tolerance, noise generation, etc.). -- Types of 1588 V2 messages and packet rate. -- Network Limits (see section 3.2). -- Availability of a master clock protection mechanism (see section 5). /\-----+-----/\ +----+----+ //// \\\\ +----+----+ | Time | || Packet swithed || | | | Server M|<<-----| network Cloud |----->>|S Client | | | || || | | +---------+ \\\\ //// +---------+ \-------+-----/ Figure 5, No on-pass support modeling Note: One of the key points is network PDV for this situation which ITU-T Q13/SG15 is studying. IEEE-1588 relies on the symmetry of the network to recover ToD and/or phase, so the asymmetry of the network will affect performance and in this case it may be difficult to meet the time/phase synchronization for wireless applications. The support for synchronous Ethernet has to be considered as well. Synchronous Ethernet can be used to stabilize the local oscillator time base. In this case, the frequency is stable as it is recovered using Synchronous Ethernet and IEEE-1588 is used only for ToD and/or phase. Ji Expires August 3, 2008 [Page 10] Internet-Draft IEEE1588V2 telecom profile framework February 2008 4.3. Hybrid Hybrid Networks in this context represents networks where E2ETC and/or BC are used in conjunction with legacy equipments. It is a complex architecture, so. we propose to study it later. 5. Time Distribution Distribution mechanism is very important for network time synchronization. BMC introduced in the IEEEE-1588V2 is a solution. RON Cohen's daft 'PTP over MPLS' is another good suggestion for time distribution in MPLS/IP network. A list of aspects may be considered to specify a suitable telecom mechanism, but it is certainly not yet exhaustive. -- Find the best grandmaster. -- Calculating the traceability paths if possible and path selection. -- Building a tree like distribution (prevent timing-loop any time). -- Fast switching when failure occurs to maintain a degree of performance. 6. Security Considerations An experimental security protocol is defined in [IEEE-1588v2]. The IEEE-1588v2 security extension and protocol provide group source authentication, message integrity, and replay attack protection for IEEE-1588 messages. 7. IANA Considerations No IANA actions are required as a result of the publication of this document. 8. Acknowledgments The authors wish to thank Silvana Rodrigues for invaluable comments. Ji Expires August 3, 2008 [Page 11] Internet-Draft IEEE1588V2 telecom profile framework February 2008 9. References 9.1. Normative References [1588v2] IEEE, ''IEEE P1588/D2.2 Draft Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". [G.8261] ITU-T, "G.8261 - Timing and Synchronization aspects in Packet Networks". 9.2. Informative References Author's Addresses Kuiwen Ji Huawei Technologies Co. Ltd. F3 3A, Huawei Industrial Base Longgang Shenzhen 518129 P.R.China China Email: Jikuiwen@huawei.com Xiaodong Duan China Mobile Communications Corporation 53A, Xibianmennei Ave., Xuanwu District Beijing, 100053 P.R.China Email: duanxiaodong@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 Ji Expires August 3, 2008 [Page 12] Internet-Draft IEEE1588V2 telecom profile framework February 2008 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 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. Ji Expires August 3, 2008 [Page 13]