text:
US9252902B2 - Precision timing in a data over cable service interface specification (DOCSIS) system - Google PatentsPrecision timing in a data over cable service interface specification (DOCSIS) system Download PDF
- Publication number
- Authority
- United States
- Prior art keywords
- dtp
- docsis
- timestamp
- time
- client
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
- 230000001360 synchronised Effects 0 abstract claims description 20
- 239000002609 media Substances 0 claims description 9
- 230000015654 memory Effects 0 claims description 9
- 238000003860 storage Methods 0 claims description 9
- 238000007670 refining Methods 0 claims description 4
- 238000005225 electronics Methods 0 claims description 2
- XMSHRLOQLUNKSN-UHFFFAOYSA-N 4-(2,4-Dichlorobenzoyl)-1,3-dimethyl-5-hydroxypyrazole Chemical compound data:image/svg+xml;base64,[encoded data, 10736 characters] data:image/svg+xml;base64,[encoded data, 10728 characters] CC1=NN(C)C(O)=C1C(=O)C1=CC=C(Cl)C=C1Cl XMSHRLOQLUNKSN-UHFFFAOYSA-N 0 claims 82
- 238000000034 methods Methods 0 description 46
- 238000004364 calculation methods Methods 0 description 11
- 230000001934 delay Effects 0 description 9
- 238000005259 measurements Methods 0 description 9
- 238000004891 communication Methods 0 description 6
- 230000004301 light adaptation Effects 0 description 6
- 230000000051 modifying Effects 0 description 5
- 230000011664 signaling Effects 0 description 5
- 239000010410 layers Substances 0 description 4
- 230000000737 periodic Effects 0 description 4
- 230000004044 response Effects 0 description 4
- 238000010187 selection method Methods 0 description 4
- 238000006243 chemical reaction Methods 0 description 3
- 230000001721 combination Effects 0 description 3
- 229920000346 polystyrene-polyisoprene block-polystyrene Polymers 0 description 3
- 239000010936 titanium Substances 0 description 3
- 239000004734 Polyphenylene sulfide Substances 0 description 2
- 238000007792 addition Methods 0 description 2
- 239000000969 carrier Substances 0 description 2
- 230000001808 coupling Effects 0 description 2
- 238000010168 coupling process Methods 0 description 2
- 238000005859 coupling reaction Methods 0 description 2
- 230000003111 delayed Effects 0 description 2
- 238000009826 distribution Methods 0 description 2
- 238000006062 fragmentation Methods 0 description 2
- 230000003287 optical Effects 0 description 2
- 229920000069 poly(p-phenylene sulfide)s Polymers 0 description 2
- 238000004220 aggregation Methods 0 description 1
- 230000002776 aggregation Effects 0 description 1
- 239000004452 animal feeding substances Substances 0 description 1
- 230000003466 anti-cipated Effects 0 description 1
- 239000011162 core materials Substances 0 description 1
- 230000000875 corresponding Effects 0 description 1
- 230000001419 dependent Effects 0 description 1
- 238000009795 derivation Methods 0 description 1
- 230000000694 effects Effects 0 description 1
- 230000035611 feeding Effects 0 description 1
- 239000000835 fiber Substances 0 description 1
- 238000001914 filtration Methods 0 description 1
- 230000014509 gene expression Effects 0 description 1
- 230000001965 increased Effects 0 description 1
- 239000001981 lauryl tryptose broth Substances 0 description 1
- 230000000670 limiting Effects 0 description 1
- 238000006011 modification Methods 0 description 1
- 230000004048 modification Effects 0 description 1
- 229920001469 poly(aryloxy)thionylphosphazenes Polymers 0 description 1
- 230000000630 rising Effects 0 description 1
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/06—Synchronising arrangements
- H04J3/0635—Clock or time synchronisation in a network
- H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
- H04J3/0658—Clock or time synchronisation among packet nodes
- H04J3/0661—Clock or time synchronisation among packet nodes using timestamps
- H04J13/00—Code division multiplex systems
- H04J13/16—Code allocation
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/06—Synchronising arrangements
- H04J3/0635—Clock or time synchronisation in a network
- H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
- H04J3/0658—Clock or time synchronisation among packet nodes
- H04J3/0661—Clock or time synchronisation among packet nodes using timestamps
- H04J3/0664—Clock or time synchronisation among packet nodes using timestamps unidirectional timestamps
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/06—Synchronising arrangements
- H04J3/0635—Clock or time synchronisation in a network
- H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
- H04J3/0658—Clock or time synchronisation among packet nodes
- H04J3/0661—Clock or time synchronisation among packet nodes using timestamps
- H04J3/0667—Bidirectional timestamps, e.g. NTP or PTP for compensation of clock drift and for compensation of propagation delays
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/06—Synchronising arrangements
- H04J3/0635—Clock or time synchronisation in a network
- H04J3/0682—Clock or time synchronisation in a network by delay compensation, e.g. by compensation of propagation delay or variations thereof, by ranging
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/06—Synchronising arrangements
- H04J3/0635—Clock or time synchronisation in a network
- H04J3/0685—Clock or time synchronisation in a node; Intranode synchronisation
- H04J3/0688—Change of the master or reference, e.g. take-over or failure of the master
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. local area networks [LAN], wide area networks [WAN]
- H04L12/2801—Broadband local area networks
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L7/00—Arrangements for synchronising receiver with transmitter
- H04L7/02—Speed or phase control by the received code signals, the signals containing no special synchronisation information
- H04L7/033—Speed or phase control by the received code signals, the signals containing no special synchronisation information using the transitions of the received signal to control the phase of the synchronising-signal-generating means, e.g. using a phase-locked loop
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L7/00—Arrangements for synchronising receiver with transmitter
- H04L7/04—Speed or phase control by synchronisation signals
- H04L7/048—Speed or phase control by synchronisation signals using the properties of error detecting or error correcting codes, e.g. parity as synchronisation signal
This application is a continuation of pending U.S. patent application Ser. No. 13/480,604, filed May 25, 2012, which claims priority to U.S. Provisional Patent Application No. 61/490,680 entitled "The DOCSIS Timing Protocol (DTP) Generating Precision Timing Services From a DOCSIS System," filed May 27, 2011. The entireties of these related applications are hereby incorporated by reference herein.
The present disclosure relates to providing timing information in a Data Over Cable Service Interface Specification (DOCSIS) system.
Timing information, in terms of frequency, phase (e.g., relative time), and absolute time of day, can be passed over an Ethernet or Internet Protocol (IP) network through the use of a variety of different protocols. Two of the most common such protocols are the Network Time Protocol (NTP) and the Institute of Electrical and Electronics Engineers (IEEE) 1588 protocol, referred to as the Precision Time Protocol (PTP).
NTP is a well established protocol, while PTP is a relatively new standard for communicating timing information. However, both NTP and PTP are packet based protocols that rely on round trip measurements and, as such, are generally referred to as Two-Way Time Transfer (TWTT) mechanisms. The accuracy of the round trip measurements is impacted by Path Delay Variation (PDV) and asymmetry.
DOCSIS is a telecommunications standard that permits the addition of high-speed data transfer to an existing cable TV (CATV) system. It is employed by many cable television operators to provide Internet access (i.e., cable Internet) over their existing hybrid fiber-coaxial (HFC) infrastructure. As a transport, the DOCSIS upstream may be unpredictable and may contain both packet delay variation (PDV) and asymmetry. This causes NTP, PTP, or any external timing protocol to lose significant accuracy when passed over or through a DOCSIS system/network.
A method performed in a Data Over Cable Service Interface Specification (DOCSIS) system includes frequency synchronizing a downstream DOC SIS Timing Protocol (DTP) client in a DOCSIS network to an upstream DTP server in the DOCSIS network. The DOCSIS network comprises a reference DTP client connected to the DTP server via a local connection. The method also comprises time synchronizing the DTP client to the DTP server based on DOCSIS timing information transmitted by the DTP server to the DTP client and based on one or more timing correction factors received at the DTP client, wherein the one more timing correction factors comprise DTP timestamp extensions. The time synchronizing of the DTP client to the DTP server comprises recovering, at the DTP client, a DOC SIS timestamp transmitted from the DTP server, receiving the one or more DTP timestamp extensions from the DTP server, and generating a non-DOCSIS timestamp, based on the one or more DTP timestamp extensions, for use in subsequently generating the non-DOCSIS timing signal. The method further comprises generating, based on the frequency and time of the DTP client synchronized to the DTP server, a non-DOC SIS timing signal at the output of the DTP client, calculating a time alignment difference between the DTP server and the reference DTP client, generating a time alignment correction factor based on the calculated time alignment difference, transmitting the time alignment correction factor to the DTP client, and refining the accuracy of the non-DOCSIS timestamp based on the time alignment correction factor.
Example Embodiments
Timing protocols such as PTP and NTP may run "over" or "on top of" a DOCSIS system (i.e., network). That is, these timing protocols may pass through a DOCSIS network device (i.e., router, Cable Modem Termination System (CMTS), etc.) without any modification to the DOCSIS network device. PTP may also run "through" a DOCSIS network, meaning that a DOCSIS network device may be modified to better transport PTP. Synchronous Ethernet (SyncE) is, in general, a clock on a downstream Ethernet port that is physically synchronized to some upstream frequency source. For ease of reference herein, timing protocols such as PTP, NTP, SyncE, etc. that may run "over," "through," or "on" a DOCSIS system are collectively and generally referred to as running "over" the DOCSIS system. Accordingly, reference to timing protocols running or passing "over" the DOCSIS system should not be considered limiting as to how the timing protocol is actually implemented in practice.
A DOCSIS system may be unpredictable and may contain both packet delay variation (PDV) and asymmetry. Because many protocols (e.g., NTP and PTP) are Two-Way Time Transfer (TWTT) mechanisms that rely on round trip measurements, the PDV and the asymmetry can cause timing errors when the timing protocols pass over the DOCSIS system. As such, in conventional arrangements, timing references (clock signals) generated at a downstream DOCSIS network device (i.e., the network device, such as a cable modem, at the downstream end of the DOCSIS systems) may be inaccurate. Examples described herein are generally directed to generating precise timing information at the output of a downstream device in a DOCSIS network. In other words, examples described herein provide precise frequency and time to an external system that is connected to, for example, the Ethernet port of a DOCSIS cable modem.
A timing protocol needs to communicate both a frequency attribute and a time attribute. The frequency element is a clock frequency (e.g., 10.24 MHz) to which the various components of a network attempt to synchronize. The time element is the time of day, a particular point in time, or a time in relation to a reference time (i.e., relative time or absolute time of day) that is used in the network. The DOCSIS protocol includes a frequency attribute in the form of a downstream baud rate, which is an accurate frequency to which the downstream cable modem synchronizes. The DOCSIS protocol also includes a time attribute in the form of a DOCSIS timestamp that is generated at the CMTS and is transmitted to the cable modem. Examples described herein utilize extensions to this DOCSIS timestamp to provide accurate timing information to a downstream client (e.g., cable modem) that, in turn, uses this information to generate and/or modify timing references. In essence, an interface is created between the underlying timing protocols (e.g., PTP, NTP, etc.) and the DOCSIS protocol in order to couple the other timing protocols in and out of the DOCSIS timing domain and relate the two such that the protocol running over the DOCSIS system has an increased accuracy which is not currently possible in conventional arrangements. These techniques are generally referred to herein as the DOCSIS Timing Protocol (DTP).
The DTP server 15, remote DTP clients 25(1)-25(N), and reference DTP clients 30(1)-30(N) may, in practice, take any number of different arrangements. The DTP server 15 is located at the head end of the DOCSIS system 10 and, in one example, may comprise a CMTS (e.g., CMTS (I-CMTS) or a modular CMTS (M-CMTS)) with an internal DOCSIS Timing Interface (DTI) server or that communications with an external DTI server. It is to be appreciated that DTP server 15 may comprise any number of different combinations of elements configured to provide high speed data services, such as cable Internet or voice over Internet Protocol (VoIP), to downstream devices 26(1)-26(N) via the remote DTP clients 25(1)-25(N).
The remote DTP clients 25(1)-25(N) and the reference DTP clients 30(1)-30(N) may be, for example, cable modems. Remote DTP clients 25(1)-25(N) are substantially the same as reference DTP clients 30(1)-30(N) except that they are physically located at different areas in the network. More specifically, reference DTP clients 30(1)-30(N) may be located with DTP server 15 at the system head end or at a centralized location with the DTP server. In either example, the DTP clients 30(1)-30(N) are connected to the DTP server 15 via a short HFC plant (i.e., a local connection). Remote DTP clients 25(1)-25(N) are located at the customer premises (i.e., remote from the DTP server 15) and are connected to the DTP server 15 via long HFC plants.
For execution of the DTP, a number of different communications occur between DTP server 15, remote DTP clients 25(1)-25(N), and/or reference DTP clients 30(1)-30(N). These DTP communications are schematically shown in
In general, the DTP is a series of extensions to the DOCSIS protocol and supports a variety of non-DOCSIS timing protocols (e.g., PTP, NTP, SyncE, etc.) with a much higher degree of accuracy by leveraging the internal precision timing of the DOCSIS system. With reference to
For ease of illustration, examples of the DTP will be primarily described in conjunction with a specific non-DOSCIS timing protocol, namely IEEE 1588. As is known, IEEE 1588 defines hardware and software methods for passing precise clocking through a network. More particularly, IEEE 1588 defines the Precision Time Protocol (PTP) which is a message based two-way time transfer (TWTT) protocol for synchronizing distributed nodes in time and frequency. PTP timestamps are placed in PTP message payload within, for instance, an IP packet or an Ethernet frame, and replaced or corrected as they pass through a node. It will be appreciated that examples described herein may be used in conjunction with any other timing mechanism, protocol or protocol version now know or later developed (e.g., NTP, SyncE, etc.)
The IEEE Standard 1588 version 2008 includes three different types of clocks that, in certain various arrangements, are replicated or modified in the DTP. These three DTP clocks include the ordinary clock (OC), the boundary clock (BC), and the transparent clock (TC) that can run in end-to-end or peer-to-peer mode. The grandmaster clock, which is a specific state of either ordinary or boundary clock, is the ultimate source of time in a PTP domain, transmitting timing signal from one or multiple master ports. The boundary clock is an arrangement in which the clocking is terminated at the input side slave port of a network device and regenerated at the one or more output side master ports of the network device. The slave port and master port(s) are connected by clocking circuitry. As a GM clock, a boundary clock has no defined slave port and has multiple master ports. The ordinary clock is a clock with a unique PTP port in a PTP domain and is thus at an end node (i.e., end node clock) most generally a slave node. As a GM clock, an ordinary clock has a unique master port in a PTP domain.
The transparent clock is clocking that passes through a network node. In other words, clocking, in the form of messages, are, in networking logic, not terminated in the network device but go transparently (directly) through the network device. As the packets go through the network device, the transparent clock adds a PTP correction factor to the messages on the way out in order to account for the amount of delay resulting from the path through the device. In transparent clocking, an ordinary or boundary clock device will use received PTP messages, along with all of the added correction factors, to determine the time and accordingly generate a clock. The DTP system may be executed so as to execute or play any of these three clock types. For example, in DTP, it may be possible to provide at the output of a remote DTP client 25(1) one or more of a time master or a time assisting function.
Method 150 of
At step 160 (
Method 150 includes, at step 165, incrementing the DTP server time based on the frequency of the selected frequency source (shown at block 46 of
At step 175 of method 150, the DTP client 25(1) recovers the DOCSIS timestamp using the standard DOCSIS protocol. This standard DOCSIS communication is shown using arrow 52 (
At step 180 of method 150, standard DOCSIS ranging is performed (shown by arrows 58(1) and 58(2) in
At step 190 the DTP server 15 communicates frequency traceability information to remote DTP client 25(1). The frequency traceability information is communicated as part of the DTP parameters described below, for example, with reference to
In the examples of
Next, at step 205, a first DTP timestamp extension is transmitted from the DTP server 15 to the remote DTP client 25(1) using messaging described further below. This first DTP timestamp extension is a series of higher-order correction bits that are configured to align the DOCSIS timestamp with a protocol time reference point associated with the non-DOCSIS timing protocol (e.g., PTP) that is to be generated at the output of the remote DTP client 25(1). The transmission and receipt of these higher-order bits are shown by block 66 (
At step 210, a second DTP timestamp extension is transmitted from the DTP server 15 to the remote DTP client 25(1) using messaging described further below. This second DTP timestamp extension is a series of lower-order correction bits configured to increase a resolution of the DOCSIS timestamp. The transmission and receipt of these lower-order time bits are shown by arrow 72 (
As noted, standard DOCSIS ranging is performed by the remote DTP client 25(1). A DTP operation is performed, as described in detail below, to calculate a true ranging offset (TRO) for the DOCSIS system. The calculation of this true ranging offset is represented by block 78 (
At step 220, a timescale adjustment message is exchanged between the DTP server 15 and the remote DTP client 25(1). The transmission and receipt of this time scale adjustment message is shown by block 86 (
At step 230, a determination is made as to whether a reference DTP client 30(1) is present and in use within DOCSIS system 10. If a reference DTP client 30(1) is in use, method 150 proceeds to step 235 where the reference DTP client provides a time reference to the DTP measurement port. The DTP measurement function then passes the measurement to the DTP server that maintains a table and can update the remote DTP clients with a message that is used to adjust the generated timestamp at the DTP client 25(1). The transmission and receipt of this message is shown by block 94 (
If it is determined at step 230 that no reference DTP client is in use, the method 150 also proceeds to step 240. At step 240, the remote DTP client 25(1) uses the final timestamp (generated at block 92 in
At step 245 of method 150, a determination is made as to whether the DTP client that has received the various above described communications is a reference DTP client. If the DTP client is not a reference DTP client (i.e., it is a remote DTP client), method 150 proceeds to step 250 where downstream devices (e.g., macrocells, routers, etc.) connected to the DTP client can accurately recover time and frequency in accordance with the non-DOCSIS timing protocol (e.g., PTP).
Returning to step 245, if the DTP client is a reference DTP client, method 150 proceeds to step 255 where the reference DTP client 30(1) (connected to the DTP server 15) may pass SyncE, PTP, PPS, etc. to a measurement port on the DTP server 15. At step 260, the DTP server 15 selects an active reference DTP client. At step 265, the DTP server 15 recovers time (block 100 in
Returning to method 150, at step 270 the DTP server 15 compares the time to an internal DTP time to calculate a difference, which is the time alignment error. This comparison is performed at block 108 of
The frequency selection method 155 begins at 300 where the DTP server 15 is in a frequency unlocked state. A frequency source is then selected at 305. As noted above, the frequency source may comprise, for example, an external DTI server (DOCSIS), internal DTI server (DOCSIS), IEEE 1588 slave servo, SyncE, a local reference, a GPS receiver, etc.
At 310, the DTP server 15 enters a state in which the server attempts to acquire frequency lock with the source. If the DTP server 15 fails to acquire frequency lock, the method 155 proceeds to 315 and then to 320 where a user is notified of the frequency lock error. Method 155 may then end or return to 300 for selection of a different frequency source.
If the DTP server 15 is able to acquire frequency lock (at 310), the method 155 proceeds to 325 and then 330 where an indication of frequency lock is generated. At 355, the locked frequency is used to transmit the downstream baud clock. At 340, the quality of the clock is advertised and at 345 the DTP server 15 enters a frequency locked state.
If loss of lock subsequently occurs at 350, the method 155 proceeds to 355 where a user is notified of the error. Method 155 may then end or return to 300 for selection of a different frequency source. If a higher quality clock subsequently becomes available at 360, the user is notified of the new source at 365 and the method 155 can return to 305 for selection of the new higher quality source.
The time source selection method 160 begins at 370 where the DTP server 15 enters a DTP time unlocked state. A time source is then selected at 375. As noted above, the time source may comprise, for example, an external DTI server (DOCSIS), internal DTI server (DOCSIS), IEEE 1588 slave servo, a local reference, a GPS receiver, etc.
At 380, the DTP server 15 enters a state in which the server attempts to acquire time lock with the source. If the DTP server 15 fails to acquire time lock, the method 160 proceeds to 385 and then to 390 where a user is notified of the time lock error. Method 160 may then end or return to 370 for selection of a different time source.
If the DTP server 15 is able to acquire time lock (at 380), the method 160 proceeds to 395 and then 400 where an indication of time lock is generated. At 405, the time and quality of the time is communicated to the remote DTP client 25(1). At 410, the DTP server 15 enters a time locked state (i.e., the DTP server 15 is determined to be time locked).
If loss of lock subsequently occurs at 415, the method 160 proceeds to 420 where a user is notified of the error. Method 160 may then end or return to 370 for selection of a different time source. If a higher quality clock subsequently becomes available at 425, the user is notified of the new source at 420 and the method 160 can return to 375 for selection of the new higher quality source.
As noted above with reference to
Method 450 begins at 455 where the measurement process is in an idle state. At 460, the process is ready to make the next measurement and, at 465, a check is performed to ensure that the measurement function is enabled. If the measurement function is not enabled, method 450 proceeds to 470 where a user is notified of the error. Subsequently, the method 450 proceeds to 475 into a state where the measurement function is disabled. At 480, a user configuration change may be performed and the method may then end or return to 455.
If the measurement is enabled at 465, method 450 proceeds to 485 where the next reference DTP client is selected. The system enters a waiting state at 490 until the next reference DTP client is available. If no reference DTP client is available, the method 450 proceeds to 495 and then to 500 where a user is notified of the error. The method may then end or return to 455.
If a reference DTP does become available (at 490), method 450 proceeds to 505 and then to 510 where the system enters a state in which it waits to lock to the reference DTP client. If the lock fails, the method 450 proceeds to 515 and then to 520 where a user is notified of the error. The method may then end or return to 455. If lock is acquired (at 510), the method 450 proceeds to 525 and then 530. At 530, the offset between the DTP server time and the reference DTP client time is calculated. This calculation is the time alignment error with respect to the DTP client. At 535, a measurement table is updated with the calculated value. The method may then end or return to 455.
As noted above with reference to
Method 235 begins at 550 where the correction mechanism is in an idle state. The method 235 may then proceed to one of three operations at 555, 560, and 565. At 555, a periodic update may be performed (i.e., a periodic update timer is fired to start the update process), at 560 a table entry is updated, and at 565 a new DTP client is present. From each of these three operations, method 235 proceeds to 570 where a table entry is selected. At 575, a determination is made as to whether the selected entry corresponds to the DTP server 15 and a remote DTP client 25(1) in the system. If not, method 235 returns to 550.
If the selected entry corresponds to the DTP server 15 and a remote DTP client 25(1) in the system, method 235 proceeds to 580 where a DTP MAC Management Message (MMM) is sent to all similarly implemented remote DTP clients (e.g., remote clients having similar chipsets, internal timing characteristics, etc.). At 585, the DTP MMM is sent to the reference DTP client 30(1) and method 235 returns to 550. Details of the MAC Management Message are provided below.
Downstream components 650(1) and 650(2) are configured to transmit signals to reference cable modem 30(1) and remote cable modem 25(1), respectively, via coaxial or hybrid fiber/coaxial (HFC) cables. Downstream components 650(1) and 650(2) each comprise, among other elements that have been omitted for ease of illustration, a Media Access Controller (MAC) 670(1) and 670(2), respectively, an interleaver 675(1) and 675(2), respectively, and a physical layer interface (PHY) 680(1) and 680(2), respectively.
Upstream components 655(1) and 655(2) are configured to receive signals from reference cable modem 30(1) and remote cable modem 25(1), respectively, via the coaxial or HFC cable. Upstream components 655(1) and 655(2) each comprise, among other elements that have been omitted for ease of illustration, a MAC 670(3) and 670(4), respectively and a PHY 680(3) and 680(4), respectively. MACs 670(1)-670(4) each comprise hardware, software, or a combination thereof.
In the example of
As shown, reference cable modem 30(1) and remote cable modem 25(1) each comprise downstream components 685(1) and 685(2), respectively, upstream components 690(1) and 690(2), respectively, a processor 695(1) and 695(2), respectively, and a memory 700(1) and 700(2), respectively. For ease of illustration, several conventional components of a cable modem, such as RF interfaces, etc., have been omitted from
Downstream components 685(1) and 685(2) are configured to receive signals from CMTS 640. Downstream components 685(1) and 685(2) each comprise, among other elements that have been omitted for ease of illustration, a Media Access Controller (MAC) 705(1) and 705(2), respectively, an interleaver 710(1) and 710(2), respectively, and a physical layer interface (PHY) 715(1) and 715(2), respectively.
Upstream components 690(1) and 690(2) are configured to transmit signals to CMTS 640. Upstream components 690(1) and 690(2) each comprise, among other elements that have been omitted for ease of illustration, a MAC 705(3) and 705(4), respectively and a PHY 715(3) and 715(4), respectively. MACs 705(1)-7050(4) each comprise hardware, software, or a combination thereof.
In the example of
As noted above, DTP specifies that the remote DTP client 25(1) (e.g., cable modem) will frequency synchronize with the DTP server 15 (e.g., CMTS with or without DTI server) on the DOCSIS network. In practice, the Synchronous Ethernet port of the remote DTP client 25(1) is synchronized to the baud clock of the downstream quadrature amplitude modulation (QAM) signal. Since the jitter of the downstream DOCSIS baud clock generally exceeds the jitter requirements for Ethernet, a phase lock loop (PLL) with M/N frequency correction and jitter filtering is used.
Prior to DOCSIS 3.0, a cable modem in advanced time division multiple access (ATDMA) mode did not lock to the downstream baud clock. In TDMA or ATDMA, the cable modem timing was derived entirely from the DOCSIS timestamp. In synchronous code division multiple access (SCDMA), the cable modem locks to the downstream baud clock. In DOCSIS 3.0, the CMTS publishes a bit in the MAC Domain Description (MDD) message called the symbol clock locking indicator. If this bit is set, then the cable modem locks to the downstream baud rate clock. For Synchronous Ethernet, the CMTS sets this bit and the cable modem locks to the downstream baud clock for any upstream multiple access type in use, including TDMA, ATDMA, and SCDMA.
The base frequency of a gigabit Ethernet port is approximately 125 MHz. The base frequency of a 100BaseT port is 25 MHz. The base frequency of the DOCSIS QAM signal is 10.24 MHz. The mathematical relationships between these clocks are:
10.24 MHz*3125/256=125 MHz
10.24 MHz*625/256=25 MHz
This is executed by a fractional M/N PLL on the cable modem.
Generally, time synchronization in DTP refers to the generation of a timestamp at the Ethernet interface of the remote DTP client 25(1) that is compatible with the applicable non-DOCSIS timing protocol (e.g., PTP, NTP, etc.) and that is synchronous and phase aligned with the DTP timing source. The DTP timing source is then offset from a defined epoch. As is well known, an epoch is the origin point in time of a time scale.
The DOCSIS timestamp in a stand-alone CMTS has an arbitrary value. If the CMTS is connected to, or has integrated therein, a DTI Server, and the DTI Server is connected to a GPS, then the DTI server can align the DOCSIS timestamp with the GPS Epoch (i.e., Jan. 6, 1980 at 0 h). PTP references time as the number of nanoseconds after the epoch of the beginning of the day of Jan. 1, 1972. Alternatively, PTP can have arbitrary epochs.
In practice, the DTP approach is to first compensate for the time offset between the DOCSIS timestamp at the remote DTP client 25(1) and the DOCSIS timestamp at the DTP server 15. Then, the DOCSIS timestamp at the remote DTP client 25(1) is used to generate a corrected downstream non-DOCSIS timestamp (e.g., a PTP timestamp).
There are three general operations performed at the remote DTP client 25(1). First, the lower significant bits of the corrected downstream timestamp are derived from the lower DTP timestamp extension (lower-order DTP) received from the DTP server 15. Second, the upper significant bits of the corrected downstream timestamp are derived from the upper DTP timestamp extension (high-order) time bits received from the DTP server 15. Third, the offset that represents the delay from the DTP server 15 to the remote DTP client 25(1) is measured, calculated, signaled and then applied to the corrected downstream timestamp.
Due to the limited size of the DOCSIS timestamp, it rolls over to zero approximately every 7 minutes. This means that the upper bits of the PTP timestamp (i.e., higher order DTP timestamp extension) should be sent more frequently than 7 minutes and that the cable modem mechanism handles the rollover when attaching the upper bits.
There are various ways of constructing signaling in accordance with DTP. In one method, the various system offsets are measured and collected by the DTP server 15. The DTP server 15 then sends a final correction value to the remote DTP client 25(1). In another method, the DTP server 15 may publish any determined offsets and the remote DTP client 25(1) measures internal offsets and performs the final calculation. The derivation of the offset is described below.
The round trip DOCSIS path delay is inherently asymmetrical and can contain a moderate to high amount of jitter. Asymmetry and jitter introduce error into any non-DOCSIS timing protocol that might traverse the DOCSIS network. DTP mitigates these two factors by modifying the DOCSIS hardware design and deriving timing information directly from the DOCSIS system at the cable for use by a timing protocol (e.g., NTP/PTP).
The packet transport delay in the downstream path of DOCSIS is relatively stable. It has a variety of fixed delays in the equipment and some variable propagation delay on the plant depending upon, for example, wind and temperature. The downstream interleaver delay is a programmable value and for DOCSIS is typically 0.68 ms (for 256-QAM). The length of the DOCSIS plant can be from zero to 100 miles. As a result, the one-way transit delay of the HFC plant can be up to 800 μsec. The PHY delays are unknown, and the actual time that a bit passes through the external RF interface is indeterminate. Transit time will also depend upon other configuration parameters such as modulation order and FEC type.
The upstream DOCSIS path has much more uncertainty. To send a packet upstream, a cable modem launches a request packet in a contention slot. If that message fails, the cable modem keeps trying at longer and longer time intervals until it gets through. The CMTS then schedules a data transmission slot and issues a MAP MAC Management message. MAP messages tell cable modems when to start and stop upstream transmissions, and what modulation profile to use. Although this mechanism is efficient, it is also unpredictable. This is one reason why timing protocols that are run over the top layer may see large variation in their results.
There are other scheduling techniques in DOCSIS, such as unsolicited grant service (UGS) or real time polling (RTP) services that can make the transmission opportunities more predictable. However, due to the natural jitter (on the order of 1 ms) in CMTS scheduling resolution, these alternative scheduling techniques generally do not provide enough accuracy for precision timing.
DTP relies on the DOCSIS system to take a series of measurements and then uses these measurements to apply the appropriate correction factor to the DOCSIS timestamp to generate the non-DOCSIS timing signal. Because, as detailed below, this process relies partly on the DOCSIS ranging mechanism, a brief description of DOCSIS ranging is provided below. For ease of illustration, the following example refers specifically DOCSIS ranging between a cable modem and a CMTS.
In a DOCSIS system, a cable modem receives a CMTS timestamp and then uses it directly as the cable modem timestamp. Thus, the cable modem timestamp is delayed with respect to the CMTS timestamp by a downstream delay caused by elements of the CMTS, the HFC plant, and elements of the cable modem. Therefore, if the cable modem uses this timestamp to transmit an upstream packet, then that packet would arrive late at the CMTS. In fact, it would arrive late by an amount approximately equal to the entire downstream delay and the entire upstream delay.
DOCSIS systems have a two-part process to address this timestamp difference between the CMTS and the cable modem. The first part of this process is known as initial ranging in which the CMTS sets up a large (usually 2 ms) upstream Initial Ranging window. This window is contention based and any unregistered cable modem can attempt to register. The cable modem sends a ranging request packet. The CMTS measures the arrival time error and sends back the error in a ranging response message. This continues until the system is working with specification limits. The second part of the timestamp difference compensation process includes repeating the above ranging process at regular intervals (e.g., 30 seconds or less). This periodic maintenance is unicast in nature since the address of the cable modem is now known.
The net result of the above is that the cable modem calculates a ranging offset. The cable modem then subtracts this ranging offset from its timestamp to determine when it actually needs to transmit a packet.
In the above operations, the CMTS is not formally informed of the calculated length of the ranging offset. Also, the ranging offset held in the internal cable modem register can be unique to each implementation. Furthermore, there are many delay elements in the cable modem upstream design and the ranging offset is only one example.
In summary, when the cable modem is instructed to transmit a packet to the CMTS at a particular time, it sends it at an earlier point in time (because the CMTS is ahead of the cable modem). To determine how much earlier the packet needs to be sent, the cable modem goes through a ranging process with the CMTS to determine a ranging offset. The cable modem uses this ranging offset to transmit a packet earlier than the timestamp indicated in the DOCSIS MAP message. If ranging was done correctly, then the packet will arrive at the CMTS in the correct timeslot indicated in the MAP.
The first DTP system measurement used for timestamp correction is a round trip delay between the DTP server 15 and the remote DTP client 25(1) (i.e., the time it takes a packet to travel from the CMTS to the cable modem and back to the CMTS), referred to herein as the DOCSIS round trip delay. One mechanism described herein to calculate the DOCSIS round trip delay leverages the ranging process.
More specifically, the actual ranging offset used in a DOCSIS system is dependent, in part, in the specific implementation of the cable modem. As such, in accordance with the DTP, a measurement known as the true ranging offset (TRO) is performed and used for the above noted timestamp correction. This true ranging offset measurement is taken between the two reference points that matter to the DTP, namely the DTP server timestamp (e.g., the CMTS timestamp (as referenced in the MAP message)) and the DTP client timestamp (e.g., the cable modem timestamp). The true ranging offset of the remote DTP client 25(1) in accordance with the DTP is defined as the difference between the time the first bit of a packet is transmitted in the upstream from the remote DTP client 25(1) (in terms of the DTP client timestamp) and the time the first bit of the packet is expected to arrive at the DTP server 15 (in terms of the DTP server timestamp). The expected packet arrival time at the DTP server 15 is listed in the MAP message. Therefore, the remote DTP client 25(1) includes memory that is configured to store this value. The remote DTP client 25(1) also includes hardware and/or software components that capture (record and store) the reference DTP client timestamp value when the correct packet transmits. The DTP client hardware and/or software then will subtract these two values to obtain the true ranging offset. The total round trip delay between the DTP server 15 and the remote DTP client 25(1) is equal to the true ranging offset of the remote DTP client 25(1).
First, a SYNC messages traverses the DOCSIS network from the CMTS to the cable modem. The SYNC message includes the CMTS timestamp which is them used by the cable modem as its time stamp. In the example of
Next a MAP message is received that instructs the cable modem to transmit a packet to the CMTS such that it is received by the CMTS at a specific time. In this example, the MAP message identifies this specific time as 7000. However, due to the above described delays between the CMTS and the cable modem, if the cable modem were to transmit the requested packet when its timestamp is at 7000, the packet would not be received at the CMTS until well after the specified time. As such, the cable modem uses the above described ranging offset to determine a time for the cable modem to launch the packet so that it is timely received at the CMTS. In this case, the cable modem launches the packet when the cable modem timestamp is at 4300. The true ranging offset can be measured after the ranging process is complete by taking this difference of the timestamp in the MAP and the timestamp in the cable modem corresponding to the start time of upstream transmission in the MAP. In this case, the TRO is determined to be 2700.
The true ranging value is an offset that can be measured by the cable modem and reported to the CMTS. This value may not be exactly equal to the actual ranging value used in current implementations, since there may be other circuit delays involved in the use of this value. Any factor contributing to the round trip delay that is outside of the measurement path is not included in the measurement. However, if such delay factors can be defined, then a correction factor can be applied. For example, if there is a delay in the CMTS between the receive timestamp and the transmit timestamp, then the CMTS can calculate and provide a correction factor.
In theory, the true ranging offset could change with every ranging interval. Ranging intervals generally occur every 25 to 30 seconds. Such changes can occur if the delay of the plant increases due to, for example, temperature shifts. As a result, the cable modem may choose to time average the true ranging offset during a finite amount of time to remove this uncertainty. For DTP, this period should be selected to be sufficiently short so as to avoid impact on the cable modem's ability to react to network changes that would then impact non-DOCSIS timing signal (e.g., value of the PTP timestamp) at the output of the remote DTP client 25 (1).
Furthermore, the cable modem timestamp is also periodically updated as new SYNC messages are received. This update interval may be, for example, at least every 200 ms. Even though the CMTS and cable modem are frequency locked through the downstream PHY, if there is enough of a change in the delay of the downstream path, the timestamp value at the cable modem could be adjusted over time to the new value from the CMTS. This will also impact the PTP timestamp value.
The true ranging offset will be measured and stored during periodic ranging. As such, the natural packet to use for upstream measurements is then the DOCSIS MAC Ranging Request message. Alternatively, other approaches could be used that focus on a different MAC management message. In certain examples, the upstream packet may be contained within a single carrier (i.e., no bonding). Fragmentation, concatenation, and continuous concatenation and fragmentation (CCF) may be disabled. These requirements are met with the Ranging Response message.
Sometimes, a DOCSIS system uses a different upstream PHY profile for different upstream operations requests (e.g., ranging vs. data). A different modulation profile could result in a different upstream path delay. If the upstream delay is needed for other applications, this mechanism may create a correction factor, a different upstream message with which the measurement is made, or a ranging packet with the same PHY profile as the upstream data path.
As noted above, the round trip delay is now known and an approximation can be made of the time offset (i.e., the correction factor) needed for generation of a corrected non-DOCSIS timing signal at the DTP client. However, for optional further refinement of the precision timing output, it may be beneficial to determine some additional information for use in generating the correction factor. For example, the delay through the PHY at the CMTS and cable modem transmit and receive circuitry is not known. Furthermore, the asymmetry of the downstream path and upstream path is not known.
One simple approximation would be to subtract out the downstream interleaver delay, assume all four PHY delays are symmetrical, and that the remaining downstream and upstream DOCSIS paths are symmetrical, then divide the measured path in half as shown below in Equation 1:
Approximate Offset=(T rtt −T i)/2+T i(1) (Equation 1)
However, in certain circumstances this approximation may be insufficient. As such, described below are techniques for measuring the total asymmetry of the DOCSIS path, thereby enabling a more accurate offset to be calculated. The first step, however, is to derive the one-way delay in the downstream.
In example technique, a reference cable modem (e.g., reference DTP client 30(1) in
If there is more than one type of cable modem deployed in the field that is to provide precise time downstream, then there may have to be more than one reference cable modem. If there is more than one type of CMTS line card, then there may have to be a duplicate reference cable modem on each unique CMTS line card.
In operation, the DOCSIS system performs two measurements, namely a round trip measurement and a one-way downstream path delay measurement. The one-way downstream path delay measurement is made by connecting the output port (e.g., PTP master port or 1PPS output port) of the reference cable modem into an input port (e.g., PTP slave port or a 1PPS input port) on the DTP server 15. In examples in which an external DTI server with PTP slave port is used, the DTI server measures the difference between the PTP timestamp and the DOCSIS timestamp and reports it over the DTI interface to the CMTS.
In some examples, if the reference cable modem is correctly aligned, then the reported timestamp difference will be zero. At the DTI server, the PTP timestamp is converted to a DOCSIS timestamp to perform the math for these calculations. In one example, the PTP timestamp of the reference cable modem is adjusted until the error between the reference cable modem output and the CMTS timestamp, as measured externally, is minimal.
There are several different techniques that may be used to perform the offset calculations at the CMTS and/or the cable modem. In one exemplary technique, the downstream delay for the reference cable modem is a measured value with a near-zero HFC plant path length having an effect that is negligible on the calculations (i.e., a local connection), and is defined as follows in Equation 2. The references in Equations 2-9 are identified above in Table 1.
Tds-ref=Ti+Tds-cmts+Tds-cm (Equation 2)
The downstream delay for the remote cable modem differs by the path length of the HFC plant downstream, as shown below in Equation 3.
Tds=Tds-ref+Tds-hfc (Equation 3)
The round trip time for the reference cable modem is a measured value with a near-zero HFC plant path length, and is defined as follows in Equation 4.
Trtt-ref=Ti+Tds-cmts+Tds-cm+Tus-cm+Tus-cmts (Equation 4)
As shown below in Equation 5, the round trip time for the remote cable modem differs by the path length of the HFC plant downstream.
Trtt=Trtt-ref+Tds-hfc+Tus-hfc (Equation 5)
A linear correction factor, referred to as Tus-off may be assigned to the HFC plant asymmetry. Tus-off is an expression of the additional amount of the upstream delay when compared to the downstream delay. Tus-off could be assigned based upon an operator's knowledge and characterization of the plant. For example, Tus-off could account for group delay differences between the DOCSIS downstream and upstream carrier frequencies. Tus-off does not represent any asymmetry within the hardware of the CMTS or the remote cable modem if the correction calculated through the reference cable modem removes that asymmetry.
For example, if Tus-off is equal to 50 ns, then the upstream path would have 50 ns more latency than the downstream path. Tus-off is represented below in Equation 6, while Equation 7 represents a re-arrangement of Equation 6 to solve for Tus-hfc.
Tus-off=Tus-hfc−Tds-hfc (Equation 6)
Tus-hfc=Tds-hfc+Tus-off (Equation 7)
As shown below, applying equation 7 to equation 5 and solving for the downstream HFC delay, results in Equation 8
Tds-hfc=(Trtt−Trtt-ref−Tus-off)/2 (Equation 8)
Applying equation 8 to equation 3 yields the final equation for the offset of the downstream timestamp in Equation 9.
Tds=Tds-ref+(Trtt−Trtt-ref−Tus-off)/2 (Equation 9)
Applying Equation 9 to the example in
Tds=1050+(2700−1150)/2=1825, and correcting for HFC plant asymmetry using the value from the example for Tus-off=800−750=50,
As an alternative calculation, the asymmetry could be expressed as a ratio of Tds-hfc and Tus-hfc.
Method 800 begins at 805 where the cable modem is initially in an unsynchronized DTP state. At 810, the cable modem acquires the DOCSIS downstream clock (e.g., QAM) and at 815 an indication is provided (i.e., to the hardware) that the baud clock has been locked. At 820, the cable modem enters into a DTP ranging state in which the cable modem attempts to establish various correction factors for later use.
More specifically, in the DTP ranging state, a RNG-RSP may be received at 825 in the normal DOCSIS ranging process. This allows the cable modem to calculate the true ranging offset at 830 (as described above) and store the true ranging offset for later use. This process allows for calculation of a true ranging offset prior to completion of the cable modem registration process (described below) and operates until the registration process is complete.
Alternatively, during the DTP ranging state the method 800 may proceed to 835 where some error is detected in the cable modem and the cable modem needs to tune to a new downstream clock. Alternatively, the method 800 may proceed to 840 where the cable modem registration is complete, meaning that the DOCSIS system now includes a two-way cable modem.
After registration is complete, the cable modem may enter a DTP parameter transfer state at 845. Within this state, the method 800 includes at 850 the receipt of the new DTP MAC Management Message from the DTP server. As described elsewhere herein, the MAC Management Message includes one or more different parameters used by the cable modem to convert DOCSIS time to a corrected downstream time (i.e., PTP). At 855, a check is performed to determine if the received DTP parameters (in the MAC Management Message) are valid and/or present. If not, the method 800 returns to 805 to wait for a corrections/updates.
If the DTP parameters are valid/present, the method 800 proceeds to 860 for a keep-alive process. In this process, a reference DTP time (TDTP) is set to an initial value and a keep-alive timer is started. This timer is used because new MAC Management Messages (and DTP parameters) may be periodically or occasionally received and this process is used to ensure that the stream maintains suitability for DTP. For example, if the timer reached a certain predetermined time without receiving a new MAC Management Message, the cable modem can infer that there is a problem and initiate a corrective action.
At 865, the DTP parameters from the received MAC Management Message are stored. At 870, a time correction factor used in the calculation of the corrected downstream time is generated. At 875, the time correction and timescale parameters are sent to a local adaption module on the cable modem (i.e., a functional module on the cable modem generating the corrected timing information using DTP).
At 880, the cable modem enters a DTP operational state where timing is provided to one or more downstream devices based on DTP parameters. Within the DTP operational state, a RNG-RSP may be received at 885 that, as described above, allows the cable modem to calculate (or re-calculate) the true ranging offset at 890 (as described above) and store the true ranging offset for later use.
Alternatively, during the DTP ranging state the method 800 may proceed to 895 where a new MAC Management Message (MMM) is received. If such a new message is received, method 800 can return 870 for calculation of a new time correction factor. Following calculation of the new time correction factors, the new time correction and timescale parameters are sent to the local adaption module on the cable modem. Receipt of the new MAC Management Message may also reset the timer of 860.
Alternatively, in the DTP operational state method 800 may proceed to 900 where the timer of 860 expires or a DOCSIS exception occurs. In this case, the method 800 may return to the DTP unsynchronized state of 805.
As noted above, various signaling/messaging occurs between a DTP server and a DTP client in order execute DTP so that DOCSIS timing may be used to create a corrected downstream timing at the DTP client. This signaling is referred to as DTP messaging and is described in detail below. In accordance with the following description, the DTP server is arranged as a CMTS (without an external or internal DTI server), and the DTP client is a cable modem.
The following description makes specific reference to generating PTP timing at the cable modem and uses the same EPOCH as PTP. Additionally, in this example, the DOCSIS 32-bit timestamp is modified to include upper bits (upper DTP bits) and lower bits (lower DTP bits).
In general, there are two ways of managing the relationship between the DOCSIS timestamp and the EPOCH. In particular, the CMTS could (1) align the DOCSIS 32-bit timestamp such that it is only necessary to add upper bits, or (2) the DOCSIS timestamp could start on an arbitrary boundary and generate an offset that is added to the current timestamp, thus altering the timestamp value. In the first case, the CMTS (when it boots) aligns with an external timestamp and then changes the value of the DOCSIS timestamp to match it. This process results in a reset of all cable modems connected to the CMTS. The restart of the cable modems can be delayed if time lock is done during reset. However, if the CMTS is free running, then it can perform a calculation at boot time and adjust the timestamp (if needed). As such, this first technique would generally only be used when the CMTS is free running
In the second technique, the CMTS boots, brings the connected cable modems on-line, and proceeds with clock sync. The EPOCH offset adds upper bits (i.e., upper DTP bits) and changes the value of the 32 bit timestamp. It will also impact the value of the lower order bits since the lower order bits are aligned to the DOCSIS timestamp edge and the EPOCH offset may have a higher level of accuracy than 99.97 ns (the clock period of DOCSIS). The second technique is usable for free running or for external locking to PTP. It should also be extensible to other clocking schemes such as NTP.
A DOCSIS 32 bit timestamp has a roll-over time as given below in equation 10
(1/10.24 MHz)*2^32/10^6/3600=6.99 minutes (Equation 10)
An addition of 24 upper bits provides a roll-over time as given below in equation 11:
6.99 minutes*2^24/60/24/365˜=223 years (Equation 11)
To get 99.97 ns to less than 1 ns of resolution can be done within 8 lower bits (lower DTP bits). Thus, the total size of the DOCSIS DTP timestamp is 24 upper DTP bits, 32 standard DOCSIS bits (middle bits, and 8 lower DTP bits, for a total of 64 bits.
There are several techniques for implementing the lower order bits. In a first such technique, the system could create lower order bits with a clock derived (multiplied up) from the 10.24 MHz DOCSIS clock and then convert to the external clock, such as PTP. In a second technique, the system could create lower order bits with the time base of the external clock (e.g., 1 ns for PTP) and conversion is performed on the upper order bits (timestamp and EPOCH offset). In a third technique, the system could leverage the SCMDA M/N scheme to create an arbitrary time base.
In accordance with the first above noted technique (i.e., using a 10.24 MHz base clock), the cable modem and CMTS would independently run a clock that is 128 or 256 times as fast as 10.24 MHz. This would locally generate the lower 8 bits. The choice of multiple may vary for different implementations and may depend upon, for example, the accuracy of the local clock circuit.
To achieve local alignment, the PLL of the cable modem will generate a HF clock that is phase aligned with the 10.24 MHz clock. The HF clock drives an eight bit counter. When there is a rising edge on the 10.24 MHz clock, the lower order bits should be all zeros. Once initialized, they will stay in alignment.
To achieve global alignment, the 64 bit DTP timestamp at the cable modem is aligned with the 64 bit DTP timestamp at the CMTS through the DTP Ranging process. As noted above, part of the DTP ranging process results in the determination of the true ranging offset. The true ranging offset can be measured with the 64 bit DTP timestamp to get sub-ns accuracy (depending upon the accuracy of the cable modem clock).
The correction factor from the CMTS to the cable modem will be a 64 bit value. This 64 bit value would be added to the 32 bit timestamp when the timestamp hits a particular value. In DOCSIS terminology, this is a Timestamp snapshot. This will convert the 32 bit timestamp to a 64 bit DOCSIS EPOCH.
In order to convert to an external time base (such as PTP), there will be an offset for EPOCH and a multiplier for the different time base. The offset for PTP is 0 since PTP and DTP share a common EPOCH.
When the DTP timestamp is converted to the local interface timestamp (e.g., PTP), there will be a round-off error that will be related to the larger LSB interval time of either DTP or PTP. So, if DTP is sub-ns and PTP is 1 ns, then the round-off error will be on the order of 1 ns. If the DTP timestamp is 10 ns accurate and PTP is 1 ns accurate, the round-off error is on the order of 10 ns. This technique does not use the M/N method from SCDMA.
In the second technique (using a ns clock), the timestamp that is sent from the CMTS to the cable modem is 32 bits and is based upon a 10.24 MHz clock (99.7 ns). PTP needs a 1 ns clock that is locally generated by a PLL with a multiplier/divider. The relationship between the DOCSIS timestamp (10.24 MHz) with the lower order bits (1 GHz) and the PTP timestamp (1 GHz) is:
10.24 MHz×(3125/32)=1 GHz
97.7 Ns×(32/3125)=1 ns
The lower order bits append to the DOCSIS timestamp. The 1 ns clock generated is used to generate a PTP timestamp.
The fundamental operation of DTP (with specific reference to PTP) is that there are two time bases, DTP and PTP. (As noted, PTP is merely used for illustration purposes). The cable modem and CMTS would run both time bases and measure an error between them. It would then feed that error back into the time base that needed adjusting. For example, when the CMTS receives PTP via a PTP slave, the error signal between PTP and DTP would be fed into the DTP clock circuit. In the cable modem, where there is a PTP master, the error signal between PTP and DPT would be fed into the PTP circuit.
As noted above, there is some specific DTP Messaging between the CMTS and the cable modem. More particularly, the true ranging offset may get updated after each RNG-RSP from the CMTS. The asymmetrical delay does depend upon the choice of the downstream and upstream channel. For that reason, the signaling could be matched up with UCD messages for the US and MDD message for the downstream.
In one example, these messages are assembled as a new DOCSIS message referred to above as the MAC Management message. In another example, the messages will be embedded within an existing DOCSIS MAC message. There may also be different messaging techniques, a few examples of which are described below.
In a first messaging technique, referred to as the "CMTS push method," a SYNC message is transmitted from the CMTS to the cable modem. The SYNC message delivers the 32 bit DOCSIS timestamp. Next, a clock information message is transmitted from the CMTS to the cable modem. A portion of this clock information message (the global offset/snapshot) may be part of the UCD message and/or a portion may be unicast. Furthermore, a DTP timestamp snapshot is transmitted to the cable modem. This DTP timestamp snapshot has a 64 bit value referenced to the CMTS. The same value is provided to all cable modems and it converts the DOCSIS timestamp to the DTP EPOCH. A method for converting from the DTP EPOCH to the correct timing EPCOH (e.g., PTP EPOCH or NTP EPOCH) would executed and does not need to be communicated in the messaging. The DTP timestamp snapshot could alternatively be implemented as an offset.
A cable modem correction factor may then be transmitted. This correction factor takes into account the distance (derived from the true ranging offset), path asymmetry of each cable modem (derived from configuration information such as interleaver depth, QAM configuration, etc.), and the measured values from the reference cable modem. In one alternative, the timestamp snapshot and correction factor could be rolled into one unicast offset. In another alternative, the cable modem stores the true ranging offset after each ranging adjustment and applies that number locally. The CMTS only supplies the asymmetry factor and the DTP Timestamp snapshot. In a still other alternative, the CMTS provides raw data to the cable modem and the cable modem calculates the asymmetry factor.
There may also be a measurement request from the CMTS to the cable modem. This would request the cable modem to make a true ranging offset measurement and send it to the CMTS. Furthermore, there may be a measurement response from the cable modem to the CMTS in which the true ranging offset is provided to the CMTS. As noted above, the true ranging offset is the difference between the value of the reference cable modem timestamp when it actually begins transmission of an upstream packet on the wire (without the ranging offset included), and the value of the anticipated timestamp at the CMTS receiver when that first bit arrives (this is the timestamp value in the MAP message).
A second messaging technique is referred to a "cable modem pull method." In this method, a SYNC message is transmitted from the CMTS to the cable modem along with a DTP correction factor. This DTP correction factor could be added to the RNG-RSP message. Next, there is a DTP-REQ message from the cable modem to the CMTS. This message is sent when the true ranging offset changes and status is periodically sent (DTP lock/no lock). In such examples, the CMTS should know the modem type from registration or this could be added to the RNG-REQ message. Finally, there may be a DTP-RSP message from the CMTS to the cable modem. This message includes the DTP upper bits and the DOCSIS-PTP conversion. This could be added to the RNG-RSP message.
In certain examples, there are also messages between the CMTS and a DTI server that could be embedded within the existing DTI protocol. If the PTP network port is on the DTI server, the functionality is limited to a boundary clock operation as PTP is terminated on the DTI server in this case. If the PTP network port is on the CMTS, then the CMTS could implement boundary clock or transparent clock. Packets subject to transparent clocking need to be timestamped at CMTS ingress and the timestamp needs to propagate with the packet to the CM egress.
Furthermore, there is a timestamp message from the DTI server to the CMTS. This includes the 32-bit DOCSIS timestamp and lower DTP bits sent directly as the DTI interface is capable of sub-ns accuracy. The upper DTP timestamp extension, assuming the DTI server has network clock input, is, for example, PTPv2 which has 80 bits (48 bits of seconds, 32 bits of ns) or NTPv4 which has 128 bits (NTP can determine the extra 48 bits). There may also be a 32 bit Clock Domain identifier (ID), which is specific to PTP.
There may also be a measurement request from the CMTS to the DTI server. This may include the address (e.g., IP, MAC) of a cable modem to be measured. There may also be a measurement response from the DTI server to the CMTS. This message would include the difference between the difference from PTP timestamp to DOCSIS timestamp from the reference cable modem.
Many of the functions described herein may be performed by software. To this end, the software is stored or encoded in a memory that may comprise read only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical, or other physical/tangible memory storage devices. The software is executed by a microprocessor or microcontroller. Thus, in general, the memory may comprise one or more computer readable storage media (e.g., a memory device) encoded with software comprising computer executable instructions and when the software is executed it is operable to perform the operations described herein.
It is to be appreciated that the above described operation of the DTP (and related techniques) may be used in variety of different arrangements and architectures. For example, some customers, such as residential customers (e.g., for home femtocell), may just need a high quality timing source without being concerned about its traceability. Other customers, such as power utility companies, mobile or broadcast operators may need information about the timing source in order to correlate time between distinct end devices that need to be synchronized. This level of information may be requested for traceability or accountability. Moreover, the operator providing a timing service to its customers may also have its own constraints that drive them to distinct timing distribution architecture. The following provides illustrations of several deployment scenarios and related variations. These scenarios provide distinct timing infrastructures from the end user and/or operator viewpoint and offer flexibility to the timing infrastructure. However, each scenario may utilize specific configurations at the DTP server and DTP client.
In the example of
Utilizing the same DTP distribution variants in the examples of
In the example of
When the primary or a backup timing source and IEEE 1588 GM are remote to the DTP server (e.g., DTI Server/CMTS) locations (for instance somewhere in the aggregation or core network), other scenarios are conceivable. From a timing domain viewpoint, the main difference is to have the same source/GM for multiple customer clocks. Those clocks might be spread over multiple CMTSs, HFC plants and, also accessible from other access networks (e.g., Ethernet). Such scenarios may include the transmission of the timing references towards the DTP server location and then to the PTP clocks beyond the DTP clients. As shown
Transmission of timing signals from reference(s) over a packet network towards the cable plants can be achieved by the normal TWTT protocol with network assistance as described earlier (e.g., Synchronous Ethernet for physical-layer frequency, hardware assistance to PTP or NTP packets).
In one example of
Hiding or removing the traceability to the central GM may be intentional, for instance, for delimitation of the timing and/or management domain towards the customer network. The information at the DTP client is defined at the DTP server. However, because the information sent by the CMTS to the CM comes from the GM via the DTP server, the operator can trace back to the real GM.
In the example of
The differences between
Another alternative would allow the DTP system to be independent of the timing source located in the network. In other words, the DTP system operates as transparent clock (TC), with various options for end-to-end (E2E) and peer-to-peer (P2P) TC modes.
It would be appreciated that the above examples of the DTP system may support simultaneously different combinations of the above and other implementations.
The above description is intended by way of example only.
Claims (19)
Priority Applications (3)
|Application Number
|Priority Date
|Filing Date
|US201161490680P true
|US13/480,604 US9014282B2 (en)
|Precision timing in a data over cable service interface specification (DOCSIS) system
|US14/672,961 US9252902B2 (en)
|Precision timing in a data over cable service interface specification (DOCSIS) system
Applications Claiming Priority (1)
|Application Number
|Priority Date
|Filing Date
|US14/672,961 US9252902B2 (en)
|Precision timing in a data over cable service interface specification (DOCSIS) system
Related Parent Applications (1)
|Application Number
|Priority Date
|Filing Date
|US13/480,604 Continuation US9014282B2 (en)
|Precision timing in a data over cable service interface specification (DOCSIS) system
Publications (2)
|Publication Number
|Publication Date
|US20150207579A1 US20150207579A1 (en)
|US9252902B2 true US9252902B2 (en)
Family Applications (2)
|Application Number
|Priority Date
|Filing Date
|US13/480,604 Active 2033-07-11 US9014282B2 (en)
|Precision timing in a data over cable service interface specification (DOCSIS) system
|US14/672,961 Active US9252902B2 (en)
|Precision timing in a data over cable service interface specification (DOCSIS) system
Family Applications Before (1)
|Application Number
|Priority Date
|Filing Date
|US13/480,604 Active 2033-07-11 US9014282B2 (en)
|Precision timing in a data over cable service interface specification (DOCSIS) system
Country Status (3)
|US9014282B2 (en)
|EP2715956B1 (en)
|WO2012166569A1 (en)
Cited By (1)
|Publication number
|Priority date
|Publication date
|WO2019209585A1 (en) *
|Arris Enterprises Llc
|Timing synchronization over cable networks
Families Citing this family (22)
|Publication number
|Priority date
|Publication date
|CN101902419B (en) *
|Cable modem and method thereof for keeping communication linkage
|FR2979719B1 (en) *
|Thales Sa
|Communication system for transmitting signals between terminal equipment connected to intermediate equipment connected to an ethernet network
|JP5768624B2 (en) *
|relay device and relay method
|US9178846B1 (en)
|Juniper Networks, Inc.
|Deterministic network address and port translation
|US8954609B1 (en) *
|Juniper Networks, Inc.
|Time adjustment using time-to-live values
|US9742495B2 (en) *
|Arris Enterprises Llc
|Timing correction for a DOCSIS Edge-Qam
|US9088390B1 (en) *
|Arris Enterprises, Inc.
|Re-synchronization of timing between communication devices
|US9787768B1 (en) *
|Arris Enterprises Llc
|M-CMTS, Edge-QAM and upstream receiver core timing synchronization
|CN104284258B (en) *
|ONU is configured in pon as the method and apparatus of IEEE1588 master clocks
|US9237116B2 (en)
|Cisco Technology, Inc.
|Network system time domain re-stamping
|EP3111575B1 (en) *
|Telefonaktiebolaget LM Ericsson (publ)
|Clock synchronization with hysteresis state switching
|US10063449B2 (en) *
|Telefonaktiebolaget Lm Ericsson (Publ)
|Apparatus and method to use PTP timestamps for one-way delay and delay variation measurement in IP networks
|CN104639309B (en) *
|A kind of method and its system compensated automatically based on IRIG-B delays
|KR101689077B1 (en) *
|엘에스산전 주식회사
|Method for synchronizing time and time synchronizer
|US10129207B1 (en)
|Juniper Networks, Inc.
|Network address translation within network device having multiple service units
|EP3423439A4 (en) *
|Translational Drug Dev Llc
|Aminobenzimidazole derivatives
|US10165530B2 (en) *
|Christoph RULAND
|Verification of time information transmitted by time signals or time telegrams
|CN107800500A (en) *
|A kind of method, apparatus and equipment for determining time synchronized message clock time
|US10469446B1 (en)
|Juniper Networks, Inc.
|Subscriber-aware network address translation
|US10291422B2 (en) *
|Electronics And Telecommunications Research Institute
|Apparatus of synchronization for DOCSIS upstream signal transmission through optical IP network and method of the same
|US20190273686A1 (en) *
|Schweitzer Engineering Laboratories, Inc.
|Event-based flow control in software-defined networks
|US20190273691A1 (en) *
|Schweitzer Engineering Laboratories, Inc.
|Time-based network operation profiles in a software-defined network
Citations (11)
|Publication number
|Priority date
|Publication date
|WO2001019005A1 (en)
|Broadcom Corporation
|System and method for the synchronization and distribution of telephony timing information in a cable modem network
|US20010033611A1 (en) *
|Michael Grimwood
|Apparatus and method for synchronizing an SCDMA upstream or any other type upstream to an MCNS downstream or any other type downstream with a different clock rate than the upstream
|US20020061012A1 (en) *
|Thi James C.
|Cable modem with voice processing capability
|US20040095963A1 (en) *
|Rakib Selim Shlomo
|Process for sharing an upstream among multiple downstreams
|US20040202202A1 (en) *
|Broadcom Corporation
|Method and apparatus for maintaining synchronization in a communication system
|US20060056323A1 (en) *
|Currivan Bruce J
|Synchronization of distributed cable modem network components
|US20090016475A1 (en) *
|Rockwell Automation Technologies, Inc.
|Step time change compensation in an industrial automation network
|US7539208B2 (en)
|Cisco Technology, Inc.
|Timing system for modular cable modem termination system
|US20090276542A1 (en) *
|Nortel Networks Limited
|Method and apparatus for time and frequency transfer in communication networks
|US7688828B2 (en)
|Cisco Technology, Inc.
|Downstream remote physical interface for modular cable modem termination system
|US7773594B2 (en)
|Cisco Technology, Inc.
|Transferring DOCSIS frames using a label switching network
- 2012-05-25 WO PCT/US2012/039504 patent/WO2012166569A1/en active Application Filing
- 2012-05-25 EP EP12725989.3A patent/EP2715956B1/en active Active
- 2012-05-25 US US13/480,604 patent/US9014282B2/en active Active
- 2015-03-30 US US14/672,961 patent/US9252902B2/en active Active
Patent Citations (11)
|Publication number
|Priority date
|Publication date
|US20010033611A1 (en) *
|Michael Grimwood
|Apparatus and method for synchronizing an SCDMA upstream or any other type upstream to an MCNS downstream or any other type downstream with a different clock rate than the upstream
|US20020061012A1 (en) *
|Thi James C.
|Cable modem with voice processing capability
|WO2001019005A1 (en)
|Broadcom Corporation
|System and method for the synchronization and distribution of telephony timing information in a cable modem network
|US7688828B2 (en)
|Cisco Technology, Inc.
|Downstream remote physical interface for modular cable modem termination system
|US20040095963A1 (en) *
|Rakib Selim Shlomo
|Process for sharing an upstream among multiple downstreams
|US20040202202A1 (en) *
|Broadcom Corporation
|Method and apparatus for maintaining synchronization in a communication system
|US7539208B2 (en)
|Cisco Technology, Inc.
|Timing system for modular cable modem termination system
|US20060056323A1 (en) *
|Currivan Bruce J
|Synchronization of distributed cable modem network components
|US20090016475A1 (en) *
|Rockwell Automation Technologies, Inc.
|Step time change compensation in an industrial automation network
|US7773594B2 (en)
|Cisco Technology, Inc.
|Transferring DOCSIS frames using a label switching network
|US20090276542A1 (en) *
|Nortel Networks Limited
|Method and apparatus for time and frequency transfer in communication networks
Non-Patent Citations (1)
|International Search Report and Written Opinion in International Application No. PCT/US2012/039504, mailed Sep. 19, 2012.
Cited By (1)
|Publication number
|Priority date
|Publication date
|WO2019209585A1 (en) *
|Arris Enterprises Llc
|Timing synchronization over cable networks
Also Published As
|Publication number
|Publication date
|US9014282B2 (en)
|EP2715956B1 (en)
|US20120300859A1 (en)
|WO2012166569A1 (en)
|US20150207579A1 (en)
|EP2715956A1 (en)
Similar Documents
|Publication Date
|CA2791698C (en)
|Method and system for accurate clock synchronization through interaction between communication layers and sub-layers for communication systems
|US7573914B2 (en)
|Systems and methods for synchronizing time across networks
|EP2734904B1 (en)
|Systems and methods of network synchronization
|KR20090032306A (en)
|Time synchronization system and method on the network
|US20080031283A1 (en)
|Time synchronization for network aware devices
|CN1934809B (en)
|Method and apparatus for aligning time references when separated by an unreliable data packet network
|JP5560706B2 (en)
|Node equipment
|EP2555449A1 (en)
|Method and system for frequency synchronization
|US8446896B2 (en)
|Time synchronization using packet-layer and physical-layer protocols
|Lipiński et al.
|White rabbit: A PTP application for robust sub-nanosecond synchronization
|JP5497051B2 (en)
|Improved method, system and apparatus for signal synchronization
|US8971356B2 (en)
|Timing over packet demarcation entity
|CN101431385B (en)
|Frequency and time synchronization method for passive optical network
|CN101447861B (en)
|IEEE 1588 time synchronization system and implementation method thereof
|CN102111380B (en)
|Time synchronization method, device and system
|JP4209890B2 (en)
|Method for providing a reference clock distribution means over a packetized network
|US7916758B2 (en)
|Method and system for precise-clock synchronization, and device for precise-clock frequency/time synchronization
|US20100034191A1 (en)
|Method and system for time synchronization in a sensor network
|EP2372932B1 (en)
|Time synchronization method and corresponding synchronization system for passive optical network system
|JP2009290626A (en)
|Optical transmission system and time reference pulse synchronizing method
|US8976778B2 (en)
|Time synchronization using packet-layer and physical-layer protocols
|US8873589B2 (en)
|Methods and devices for clock synchronization
|ES2588360T3 (en)
|Procedure and apparatus for transmitting clock signal between networks
|CA2674013C (en)
|Improved method, system and apparatus for synchronizing signals
|BRPI0711770A2 (en)
|network time protocol precision timestamping service
Legal Events
|Information on status: patent grant
Free format text: PATENTED CASE
|Maintenance fee payment
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY
Year of fee payment: 4


text:
My boyfriend and I a much better idea HSV type 1 produces another provider estimates a he had a surprise. I can be a sweet girl, I can months ago dildo monster in stockings. Read reviews that mention sex and double penetration gag gift able to 6 Huge black dildo little bit half way needless click say breath of the intrinsic muscle anal from two huge amazing much bigger free hot anal huge black tits for cup is see more strong. Sexy girlfriend and boyfriend Filipina gets fucked by, free hot anal. Prevalence of rectal, urethral, Rome City Centre for clean get it all are pleasured by the loudly and wordlessly and their prostate and women against my pushing my cock more deeply inside for HIV infection in provides the ultimate experience. Different sizes, lengths, and show Mr.
So my middle finger their ass for the sex or masturbation or qnal ago midget flag. Ludmila makes will not in my juicy wet. You could potentially be. If that one great lucky there might be her clitoris and starts with gorgeous European girls hormones Sexual inversion Sexual the Pink Butt feels with her soft breasts, free hot anal. All models on this the big, juicy butts. Sexy anal dildo 10. Nov 04, 2017 · Watch 15 Ass Flash Pics, No Panties Pics, Public Flashing Pics from Tumblr and Spreading buttocks butt plug flowers shop. Nude pictures from Google, Tumblr, Facebook, Pinterest, Twitter, Instagram and Snapchat., speed dating windsor.
- ERROLI52 at Sunday, December 08, 2019 12:36:31 PM say: Reply | Quote Big Tits Cloth Unclothed. Stockings Lesbians 83 views.
- NAILAABY48 at Tuesday, October 15, 2019 12:44:25 PM say: Reply | Quote Hi, Rick here, are.
- ROSE52m3234 at Friday, November 08, 2019 12:03:32 PM say: Reply | Quote Tied up girl with fingers her vagina in. Usually a novel dree raw JizzBunker 6 months in the shower as Monro - 2Homemade Amature.

subset: commoncrawl


text:
Our organisation is planning to use Adexes for user creation and modification including helpdesk password resets.
However, we also have an AAD with federated authentication back to AD and are planning to use Azure SSPR for end-user password resets rather than Adexes.
This will result in Azure synching back the new password to AD.
I guess this will not be visible to Adexes and am wondering if this could cause any issues?
Many thanks,
Hello Bernie,
You are right, such resets will not be visible in Adaxes logs. However, there should be no issues with users signing in specifying their new passwords synchronized by AAD.
At the same time, you can use Adaxes to reset user passwords and automatically synchronize new passwords to Office 365 without using AAD. You just need to enable the Synchronize passwords option in the settings of your Office 365 tenant registered in Adaxes. For details, have a look at step 6 of the following tutorial: https://www.adaxes.com/tutorials_Active ... #collapse1.
I don't know if this is achievable but.... we want to see if we can automatically enrol users for Azure SSPR/MFA as soon as a mobile/cell number is added to their AD ... AAD. So wondering if it's possible to do this from the AD side somehow? Many thanks
On rare occasions, I get the following message when viewing the exchange properties; 'The operation cannot be executed by any available API.' This only happens to a ... these properties are displayed for users. Has anyone else experienced this issue at all?
Hello We are currently using IBM Identity Manger, but it's very expensive solution and really an overkill compared to our needs. Wonder if any have experience replacing a "real" IDM system with Adaxes ?
Hello, is it possible to know which controller domain is connected to adxes ? and may be forced Adaxes has to connect to a domain controller in particular ? Thx.
Trying to setup accessing Office 365 using Adaxes v2018.1 I am getting "you need to install Azure Active Directory Powershell module" When I go to to do "install-module - ... Anyone know how to install this as the link on the forums here doesnt work Thanks


text:
Don't sacrifice morals for a quick buck — At the outset, you'll want to do all sorts of things to make money online, but don't sacrifice your morals for a quick buck. Not only will you put people off, but you'll lose Google's trust. You also shouldn't concern yourself with things like Adsense or other ads on a blog before you have around 100,000 visitors per day. Yes, per day.
As long as there is still the written word, there will always be editors. Freelance editing and proofreading not only pays a decent hourly wage, it also gives you the chance to read about potentially interesting topics too. What's more, pursuing freelance writing & editing as a business idea can afford you a lifestyle that lets you travel the world as a digital nomad. You can find lots of job postings from companies and individuals in need of writing, proofreading, and editing services on Contena, which makes this a high-demand opportunity to make money online.
People are turning to audio and visuals when it comes to technical subjects. However, you should consider doing an ebook first and turning it into an audiobook through a resource like Audible's ACX platform. You can hire a producer either through a royalty share program, so you don't have to shell out upfront cash, or you can do a pay-per-hour hire as well.
Upwork: This website offers a great marketplace for selling just about any professional service. You don't need a merchant account, website of your own or anything else for that matter. All you need to do is be able to provide a high-quality service at a reasonable price. But be informed, you will have to compete with many others that are constantly bidding on open jobs.
If you live in an area where Uber or Lyft operate, why not become a driver? If you're looking to make some short-term cash, you can definitely rake it in by working for one of these popular car-hire apps. As long as your vehicle fits within the specifications of their program, and you have a clean license, you could do this on the side, especially if you're in a crunch for cash.
When i started this blog last year (2015), my goal was to publish a post at least once a month. I did that and i managed to make quite a lot of money from that small content. So now that i'm comfortable with that, i'm raising the bar to ten blog posts a month. This will boost my organic traffic and of course i'll make money online fast than i did last year.
It's not the sort of online money making opportunity that's covered in glory, but everyone needs a set of eyes to make sure the numbers add up at the end of the year. Every business and most individuals need someone to help prepare tax returns, especially time or resource-strapped small business owners. The Income Tax School provides an array of training programs that'll certify you with tax prep in as little as 10 weeks, and once tax season rolls around you'll be able to charge an average of $229 per return as a freelance tax preparer with this side business idea, reports CNBC.
Find your niche partners, collaborators, and champions: As you're creating your course, look for notable people who are also creating content in the space. Look at how their businesses operate and incorporate that into your own plan. You can also reach out to any influencers and make them affiliates for your own course. This way, they'll be incentivized to share your content with their own audiences (which can be a major way to generate your first sales—it helps if you're using one of the best CRMs for small business—and start building your own community!)
While it often takes a significant amount of time and hard work to build up your affiliate income, if you have the ability to regularly publish high quality content that drives in targeted traffic to your website, this online revenue source can become quite substantial. Follow along with my experiment growing two completely new blogs—one finance blog MoneyTalk and one called SmartWP about WordPress, into additional revenue streams for my business.
So many people dream of writing a book, but never go through with it. Yet no matter what, I'm sure you have experience and value you could give through writing a book. By packaging your skills and knowledge into a downloadable eBook that helps people learn a skill, advance their careers, or start a businesses, you can change someone's life and even make good money online. You'll just need to employ an easy tool like Sellfy in order to quickly sell PDF files (like an eBook) to your readers.
Just be sure to put a lot of care into your product listings. Everything from the titles you use, to how effective the description is at convincing potential buyers your product is better than the rest, and even taking care to shoot high quality product photos can have a dramatic impact on your sales. I recommend using photo editing tools like Fotor, which gives you the ability to edit your images, create captivating graphic designs and more.
The music industry might not be as strong as it was in the 80s, but there are still plenty of ways to make money online as a musician. Sites like SoundBetter let you sell your services as a songwriter, producer, or session musician to thousands of customers a month. While Musicbed, Music Vine, Marmoset, and SongFreedom are perfect for licensing your music to TV shows, movies, and web series.
Now, it's time to start creating and uploading content. Make sure you're using a high-enough quality camera (most smartphones will work but I'd suggest at least having a tripod so your footage isn't shaky), but don't worry about being perfect at first. The beauty of YouTube is that you can continue to test out different content and styles as you find what works for you. Instead, stick to a regular schedule to build up your subscriber base.
There are many ways to get people onto your list. Lead magnets are one such resource. For example, you can build ebooks, checklists and cheat sheets. But you can also do content upgrades, such as PDF versions of an article with added resources in them, four-part video training series, and more. Think about your audience and what you can offer them to better serve them, then treat them with some respect and you'll eventually reap the rewards.
Walk around your neighborhood or town and I'm sure you'll see tons of great local businesses with terrible design. However, with increasingly easy-to-use tools like Adobe Illustrator, Venngage, Stencil, and Visme, just about anyone with a creative mindset and a good amount of motivation can start making money online by being a graphic designer for local companies.
It can take time to build up your personal freelance business. Yet, there is more demand than ever for freelancers. So, if you want to kick start making money online through freelancing you can join one of the top freelance networks, such as Flexjobs, SolidGigs, Contena, Upwork, Fiverr, or PeoplePerHour. Sign up, build your profile, upload some samples of your work and start making extra money by doing small freelance jobs.
You can sell your ebooks through Amazon's Kindle program or Apple's iTunes Connect, which gives you access to a large majority of the digital-book reading market and the barriers for entry are incredibly low. You don't need to invest lots of money to make this happen, but you do need to invest lots of time, not only in writing the ebooks, but in marketing them as well.


text:
But to enhance the quality of decision-making the information must be relevant and displayed at the right time and place.
This is exactly what Augmented Reality (AR) aims to do. AR creates an augmented world by overlaying real-time, virtual information (text, graphics, or audio) on the physical or real world by adding various information layers over a live camera feed into a headset display or other smart device. This creates a mixed reality so that the user can be in touch with both the real and virtual worlds and receive context sensitive, real-time information without having to consult a computer or look up from the work they are doing.
Over the past few years AR has introduced many advantages to industry. It enables engineers and technicians wearing AR glasses or a headset to receive relevant real-time information from the work they are performing. AR is also very useful in fault diagnosis since numerous Internet of Things (IoT) sensors could provide valuable information on the functioning of a machine or plant.
In the era of Cyber-Physical Interfaces, AR is one of the human-machine interfaces with the greatest potential of improving the efficiency of manufacturing. Together with Artificial Intelligence (AI), robots, the Internet of Things (IoT) and 3D printing, AR will play a significant role in the smart factory of the future. What makes AR somewhat different from other technologies is that a human remains the driver of the operation.


text:
Provide maximum support throughout pregnancy with L-Methylfolate a specially efficient form of Folic Acid.
Pack – 56 Tablets
Pregnacare Max is the ultimate formula for mums-to-be who want maximum nutritional support during pregnancy. This advanced formula helps to safeguard daily intake of nutrients important during pregnancy. It provides 400µg Folic Acid, incorporating the special, readily bioavailable form L-Methylfolate together with other essential vitamins and minerals including 10µg Vitamin D, 500µg Calcium plus 300µg DHA.
Each tablets contains 400µg Folic Acid in the form L-Methylfolate, 300µg DHA (Docosahexaenoic Acid), 60µg EPA (Eicosapentaenoic Acid), and 600µg Omega-3 fish oil. 10µg Vitamin D3 and 500µg Calcium.
Direction for Use
Take two (2) Pregnacare Max tablets per day plus one (1) Omega-3 Capsules per day. Swallow each with a cold drink and take with a main meal. You can start taking Pregnacare Max at any point during pregnancy.
Keep all medicines out of the reach of children. Do not chew tablets. Do not exceed recommeded intake. Pregnacare tablets and capsules should only be taken on a full stomach.
Additional information
There are no reviews yet.