TICTOC F. Su Internet-Draft L. He Intended status: Informational ZTE Corporation Expires: January 7, 2010 July 6, 2009 1588v2 modules of time synchronization with frequency layer support draft-su-tictoc-1588v2-time-sync-modules-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 January 7, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This I-D introduce a set of functional components of 1588v2 time/ phase synchronization system with frequency layer support and some optimized schemes for time synchronization devices based on PTP. Su & He Expires January 7, 2010 [Page 1] Internet-Draft 1588v2 time sync modules July 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. Scenario of 1588v2 time/phase sync for mobile backhaul . . . . 3 4. Time/phase Server . . . . . . . . . . . . . . . . . . . . . . 5 5. PTP Client . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Timestamping Process . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. Informative References . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Su & He Expires January 7, 2010 [Page 2] Internet-Draft 1588v2 time sync modules July 2009 1. Introduction As the TDM-based transport technology, e.g. SDH, can only provide stable frequency output to the end application (e.g. 2G cellular base station), it has been required by emerging application, such as 3G/ LTE cellular base station with TDD mode, that highly accurate time/ phase alignment be achieved using some packet-based method (e.g. IEEE Std 1588-2008 or NTP). An example of this application is the TD-SCDMA mobile bakhaul network which needs phase offset between the reference time/phae source (normally located at the edge of RNC) and NodeB is less than +/-1.5us. The number of hops on the time/phase distribution path could be 30 or more at maximum. The transport equipment for transmitting the time/phase signal are Ethernet-based and implemented as PTP enabled node. In addition, each node could be Synchronous Ethernet capable in order to provide stable frequency base locked to high quality frequency source for the time/phase calibration. It is recommended to look at the PTP profiles for time/phase sync with support of SyncE. This I-D initially describes some functional modules for implementing this profile. 2. 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. This I-D uses following terms and abbreviations 1588v2 The "Standard for A Precision Clock Synchronization Protocol for Networked Measurement and Control Systems" defined by IEEE PTP "Precision Time Protocol" defined in 1588v2 NTP "Network Time Protocol" defined by IETF SyncE Synchronous Ethernet define by ITU-T G.8261/G.8264 ToD Time of Day PPS Pulse per Second 3. Scenario of 1588v2 time/phase sync for mobile backhaul The main concern about time/phase sync in mobile backhaul application Su & He Expires January 7, 2010 [Page 3] Internet-Draft 1588v2 time sync modules July 2009 is the number of GPS devices currently used at each base station should be minimized without degrading the sync performance. Therefore, the PTP system built in backhaul networks is normally based on a server-client architecture. The time/phase server could be as close as to or co-located with RNC. The PTP client might be implemented in the base station (NodeB) or the access edge equipment connected to the base station. An example of this scenario is shown in figure 3-1. In this case, the PTP server connected to RNC is synchronized by GPS. The PTP server is also an integrated part of packet-based transport equipment which interconnected with other NEs by SyncE links. All NEs are frequency-locked to the PTP server through SyncE links down to the PTP client (NodeB). The PTP client communicates to the PTP server through PTP interface and thus time/phase synchronized to the PTP server upon a stable physical layer timing basis. GPS time | | +------+ | +-----------| RNC | v | +------+ +------+---+ +-------|PTP server|-------+ | | | | | +----------+ | . aggregation ring . . with SyncE links . . . | +----------+ | +-------| NE |-------+ +-----| |-----+ | +----------+ | | access ring | . with SyncE links . . . . +----------+ . | | NE | | +-----| |-----+ +----+-----+ | | FE +--+----+ | NodeB | PTP client +-------+ Su & He Expires January 7, 2010 [Page 4] Internet-Draft 1588v2 time sync modules July 2009 Figure 3-1 4. Time/phase Server Time/phase server is capable of providing time/phase synchronization signal to various client equipment. It is normally traceable to a standard time base such as UTC through any intra-office time/phase interface or by directly synchrinized to GPS time. It could have multiple output time/phase interfaces for instance PPS, PPS + ToD, PTP, NTP etc. The time/phase server for PTP is also regared as Grand Master(GM) whcih could be a stand-alone equipment or a module of transport equipment. Figure 4-1 has an overview of the basic function of time/phase server. The frequency reference input signal fed to the time/phase holdver function guarantees that the server would mantain required time/phase output accuracy when time/phase reference input is lost or GPS receiver fails. The PRC traceable frequency input, for example, should be required. For the PTP time/phase sync with frequency layer support, the server may also provide frequency reference output to downstream PTP devices(e.g. Boundary Clock). The frequency output interface should include 2Mb or syncE etc. + + v +------------+ +------------+ +------------+ | Time/phase | | Local | | Time/phase | --->| Input |<##>| Time/phase |<##>| Output |===> +----------+ | | Holdover | | | |GPS module| | | | | | +----------+-+ +------------+ +------------+ /#\ /#\ /#\ # # # \#/ \#/ \#/ +------------------------------------------------+ | Sync Monitoring & Management | | | +------------------------------------------------+ -----> Intra-office time/phase input =====> Time/phase output and/or frequency output +++++> Frquency reference input Figure 4-1 Su & He Expires January 7, 2010 [Page 5] Internet-Draft 1588v2 time sync modules July 2009 5. PTP Client The PTP client or PTP slave terminates and responds to PTP server with PTP messages. The local time base is mantained to be aligned with server by PTP client by means of measuring the path delay and calculating the time/phase offset between. The details have been given in 1588v2. A instance of the model of PTP client cloud be envisaged as shown in Figure 5-1. In this I-D, the frequency layer support is needed for the tunning of PTP client time/phase. +--------------+ | time | +------+ | calibration | | Sync | +--------------+ | PHY |-----------+ | +------+ | | v v +------+ +-----------+ +--------------+ | PHY |--->| clock | | time | | | | selection | | counter | +------+ +----|------+ +--------------+ ^ | ^ +------+ | | | +------+ | ext |------+ | | +--->| Sync | | freq | | +-------+ +-------------+ | | PHY | | ref | +-->| DPLL |--->| frequency |--+ +------+ +------+ +-->| | | synthesiser |--+ | +-------+ +-------------+ | +------+ +----------+ | | | PHY | |oscillator|--+ +--->| | +----------+ +------+ Figure 5-1 Clock selection function performs the best clock selection algorithm based on SSM or priority configured. The selected clock could be any line timing signal, for example, from SyncE interface or a stable external frequency input. The selected clock is then passed to DPLL to lock local frequency. The frequency synthesiser can output a range of frequencies to different system modules (e.g. to MII or GMII interfaces). Each PTP client has a local time counter which updates local time according to certain time scale. Standard time scales could be used such as UTC or TAI, otherwise the ARB time scale might be allowed if the traceablity of standard time scale (e.g. UTC or TAI) is not necessary. The time counter should have, at least, the same bit Su & He Expires January 7, 2010 [Page 6] Internet-Draft 1588v2 time sync modules July 2009 representation as the PTP timestamp value, i.e. 64 bit for integer part of nano-second and 16 bit for fractional part of nano-secnod (figure 5-2). But the timestamp resoulation only depends on the frequency granularity of time counter. For instance, if the time counter increments on the basis of 125 MHz frquency, the time measurement resolution is 8 ns, i.e. the time error raised by timestamp resolution is the multiple of 8 ns. The measure frequency of time counter could be provided by the frequency synthesiser. The time calibration sub-module is responsible for adjusting local time with reference to the PTP server time. The key parameter of calibration is the time offset between PTP client and server calculated by PTP client using the four timestamp values (t1, t2, t3 and t4). There also could be other factors that need to be considered, e.g. the path or transmission link asymmetry, these errors should be measured and compensated manually or automatically. 79 78 77 76 18 17 16 15 1 0 +--------------------------------------------+----------------------+ | | | | | ... ... | | | | | | ... ... | | | +--------------------------------------------+----------------------+ integer part of nano-second fractional part of nano-second Figure 5-2 6. Timestamping Process The timestamping process of a PTP system has a innegligible impact on the time offset calculation. It is required that the timestamping latency be minimized. There are basically two types of timestamping schemes referring to centralized scheme and distributed scheme. The centralized scheme deals with all PTP event packet at a single timestamping unit. The PTP protocol unit operates PTP protocol with timestamp values delivered from the timestamping unit. This scheme decreases the hardware expense but increases the uncertainty of internal system delay regarding to the timestamp information transfer. Comparatively, the distributed scheme makes use of separated timestamping unit close to each physical interface. These timestamping units can immediately recording the ingress and/or egress time of PTP event message. The usage of recorded time values could be decided by judging the type of message and the clock type of the node. Su & He Expires January 7, 2010 [Page 7] Internet-Draft 1588v2 time sync modules July 2009 The general structure of distributed scheme could be seen in figure 6-1. The incoming PTP event message is firstly timestamped by associated timestamping unit and sent to switch unit whcich processes the message as per pre-defined forwarding criteria. The time value of timestamped message might be extracted by PTP protocol unit to carry out protocol algorithm if necessary. On the other hand, if PTP protocol unit initiates the PTP event message, the timestamping unit will tag the message with precise time when received and send the message out from corresponding outbound port. If the event message is directly fowarded from switch unit as other service messages the total internal delay is measured at this point by subtracting the incoming timestamp value and injected into correction fiels of the message by the timestamping unit at the egress edge. PTP general message will not be processed by the timestamping unit while they are passed to switch unit or perhaps to PTP protocol unit for protocol invoking. +------------+ |PTP protocol| |unit | +------------+ ^ | v +--------------+ +----------+ +--------------+ | distributed | | switch | | distributed | | timestamping |<====>| unit |<====>| timestamping | | unit | | | | unit | +--------------+ +----------+ +--------------+ Figure 6-1 The principle of distributed timestamping scheme can be specifically calrified if we take a look at the operation for different types of PTP messages. It is assumed here that the delay request-response mode is used for delay measurement. Figure 6-2 shows the case that PTP message transits from PHY to switch unit. The edge timestamping unit can detect the PTP event messages, i.e. Sync and Delay-request, and capture the exact arriving time of the message (t2 for Sync and t4 for Delay-request). The time value is filled into the message as a timestamp and sent to switch unit. Depending on the system configuration, the timestamped message might be directed to PTP protocol unit in order to implement Su & He Expires January 7, 2010 [Page 8] Internet-Draft 1588v2 time sync modules July 2009 the PTP protocol such as time offset calculation. Otherwise, if the timestamped message need to be forwarded as other data message (i.e. in E2E transparent clock mode), it will be switched to corresponding egress port where edge timestamping unit again captures the message and updates the time information contained by loading the internal delay the message going throug the system. The Follow-up message has the similar procedure, however the edge timestamping unit will take no action on the Follw-up message. For Delay-response message, the port ID and sequence no. check are required to judge whether or not the Delay-response message is responding to the Delay-request message sourced from the local PTP port. If so, the Delay-response will be transfered to PTP protocol unit, additionally attached with the previously stored timestamp value t3 (which is the sending time of Delay-request message in sequence.) Otherwise, the Delay-response message will be straight forwarded as a transient data unit. PHY(SyncE) Edge timestamping unit Switch Unit +---------------------+ | | Sync | +------------+ | +------+---+ ------>|timestamping|------>|Sync |t2 |---+ PTP protocol | +------------+ | +------+---+ | unit | | | +--> Follow-up | Forwarding | +----------+ | | --------------------------->|Follow-up |---+---+ | | +----------+ | | | | | +--> Delay- | +------------+ | +-----------+ | Forwarding request------>|timestamping|------>|Delay- |t4 | | | +------------+ | |request| |--+ | | +-------+---+ | | | | | | | +--------+ Y | +------------+ PTP protocol Delay- | |port ID |---------->|Delay- |t3 |----> unit response----->|& | | |response| | | |seq No. |-----+ | +------------+ | |check | N | | +------------+ | +--------+ +---->|Delay- |----> Forwarding | | |response | +---------------------+ +------------+ Su & He Expires January 7, 2010 [Page 9] Internet-Draft 1588v2 time sync modules July 2009 Figure 6-2 Figure 6-3 depicts PTP message transit from switch unit to PHY through edge timestamping unit. The event message (Sync and Delay- request) coming from switch unit is firstly examined by edge stamping unit, deciding whether it is generated by PTP protocol unit or not. If the locoal PTP protocol unit intiates the event message, the timestamping unit will generate timestamp value of the sending time. The Sync message is timestamped (with t1) before it is sent out through physical interface. The timestamp value of Delay-request message, however, is generated but could be stored in local register waiting for the sequential Delay-response message. Then the timestamp pair [t3, t4] could be used. If the event message is transparently forwarded, the edge timestamping unit will check the timestamp value generated by the timestamping unit at the incoming edge and record the current time point. The diffrence between two is used for correcting the section into the message containing the residence delay on the path. Follow-up message and Delay-response message will not be processed by the edge timestamping and be directly sent out under all circumstances. Su & He Expires January 7, 2010 [Page 10] Internet-Draft 1588v2 time sync modules July 2009 Switch Edge timestamping unit PHY(SyncE) Unit +---------------------+ | | Sync | +------------+ Y | +------+--+ ----->|initiated by|------->|Sync |t1| | |local PTP | | +------+--+ delay | |protocol | N | +------+ comp. +-----+ | |unit |------->|Sync |--------->|Sync | | +------------+ | +------+ +-----+ | | Follow-up | Forwarding | +----------+ --------------------------->|Follow-up | | | +----------+ | | Delay- | +------------+ Y | +---------+--+ request----->|initiated by|------->|Delay-req|t3| | |local PTP | | +---------+--+ delay | |protocol | N | +---------+ comp. +---------+ | |unit |------->|Delay-req|--------->|Delay-req| | +------------+ | +---------+ +---------+ | | | | +------------+ Delay- | Forwarding | |Delay- | response-------------------------->|response | | | +------------+ +---------------------+ Figure 6-3 7. Security Considerations The time distribution given in this document may have security concerns as described in informative reference [4]. 8. IANA Considerations There have been no IANA considerations so far in this document. 9. Acknowledgments It is acknowledged that Mr. Zhengqi Li and Mr. Hui Su made some contributions to this document. Su & He Expires January 7, 2010 [Page 11] Internet-Draft 1588v2 time sync modules July 2009 10. Informative References [1] IEEE, "Standard for A Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std 1588- 2008, Jul 2008. [2] ITU-T, "Timing and Synchronization Aspects in Packet Networks", G.8261, Apr 2008. [3] ITU-T, "Distribution of Timing through Packet Networks", Draft G.8264, Feb 2008. [4] Frost, T., Dowd, G., and K. O' Donoghue, "Architecture for the Transmission of Timing over Packet Networks", draft-stein-tictoc-modules-03.txt, 3 Nov 2008. [5] He, L. and F. Su, "Time synchronization method in packet- switched transport network for mobile backhaul", draft-su-tictoc-time-sync-mode-01.txt 8 Apr 2009. Authors' Addresses Fei Su ZTE Corporation R.D. Building 3, ZTE Industrial Park, LiuXian Road Shenzhen 518055 P.R.China Email: su.fei@zte.com.cn Li He ZTE Corporation R.D. Building 3, ZTE Industrial Park, LiuXian Road Shenzhen 518055 P.R.China Email: he.li4@zte.com.cn Su & He Expires January 7, 2010 [Page 12]