 that CEM node is using the TDM as a line clock to recover the frequency from the customer. It then uses that recovered frequency to transmit data back over the attachment circuit. The CEM node itself might still (optionally) have a network clock (such as SyncE), but that does not matter, because it does not use it for that circuit. That is all fine, but this creates a problem at the downstream end. The issue is that the CEM on the right-hand side does not have that frequency signal from the mas- ter AC available to it, SO it cannot drive the slave AC at the correct frequency. Of course, the CEM node could take a frequency signal from the network clock (with SyncE, for example). But this fre- quency will be different from that on the input AC, which will cause data integrity issues between the two ends of the customer circuit. If the CEM (ACR slave clock) node on the right-hand side is running the attachment circuit more quickly than the left-hand (master) side, then it will eventually run out of data in the dejitter buffer to send (causing a buffer underflow). If it pushes data out too slowly, then the dejitter buffer will fill up and generate a buffer overflow-thereby losing data. So, the right-hand CEM slave node uses the ACR method to regulate the frequency of the attach- ment circuit-based on the percentage fill of the dejitter buffer. If the dejitter buffer is filling up, then it is driving the attachment circuit too slowly, and it must speed up the frequency. If the dejitter buffer is emptying, then it is driving the circuit too quickly, and it must reduce the frequency. Thus, it is adapting the frequency that it sends to the downstream customer device based on the packet ar- rival rate, which is derived from the master clock on the upstream side. Note that because the timing only passes in one direction (in Figure 9-6, from the clock master on the left to the slave on the right), this ACR clock recovery only happens on the right-hand slave node. The left-hand CEM node takes its clock from the customer cir