A transmitter often carries client data between interfaces with independent clocks. The source determines how fast data arrives, while the outgoing link has its own transmission rate and framing overhead. Meeting both interfaces' specifications does not make their effective data rates identical.
A small rate mismatch becomes significant over time. If transmission consumes client data slightly faster than it arrives, the transmitter eventually runs out of data to send. If it consumes data slightly slower, unsent data accumulates. More storage delays either outcome, but it cannot correct a sustained difference between arrival and transmission rates.
Rate adaptation reconciles those rates while preserving client data and order. Ethernet transport over FlexO provides a concrete example, using the mapping procedures specified in ITU-T G.709.1. The frames retain their prescribed cadence while the client allocation changes. The receiver must recover each client block in order.
Where the rate mismatch appears in FlexO
Flexible optical transport network (FlexO) interfaces carry client signals, such as Ethernet, over optical links. Each frame contains payload space for the client and overhead for interpreting and managing the transmission. Mapping defines how client data occupies that payload space.
For Ethernet transport, FlexO provides slightly more payload capacity than the client requires across the permitted clock tolerances. Some positions therefore carry no client data, and the proportion depends on the relative client and line rates. Here, the client is the encoded Ethernet signal, including its control and idle information, which continues between packets.
Clause 10.2 defines GMP mapping of Ethernet into FlexO. Generic Mapping Procedure (GMP) allocates payload positions to client data or stuffing and communicates the allocation through justification overhead. This gives the transmitter a way to accommodate the rate difference without changing the frame structure.
Adapt the client rate through stuffing
Stuffing fills payload positions with blocks that carry no client data. These are called stuff blocks, and the receiver discards them using the accompanying mapping information. Increasing their share reduces the effective client transmission rate. Reducing it makes more positions available for client data.
Rate adaptation connects two decisions: how much client data to transmit, and where to place it. Rate estimation and occupancy feedback determine the client count. GMP turns it into a payload allocation the receiver can interpret.
In the transmitter's egress path, GMP maps client data into the outgoing FlexO payload. GMP defines the mapping and signaling; the rate estimation and feedback strategy are implementation choices. The approach described here uses the measured arrival rate to establish a baseline allocation and FIFO occupancy to correct accumulated imbalance.
Choose the client count from rate and occupancy
Client rate estimation starts by counting accepted input blocks over successive allocation periods. Averaging recent measurements gives a baseline allocation without chasing every short variation in arrival timing. A block held back by backpressure has not entered the datapath and must not count toward that estimate.
Buffering bridges the timing difference between client arrivals and available transmission opportunities. Storing accepted blocks in first-in, first-out (FIFO) order preserves their sequence until they can be transmitted. FIFO occupancy records the accumulated difference between arrivals and departures. Even an accurate rate estimate does not remove a previous excess; occupancy feedback adjusts transmission to clear it.
GMP denotes the client block count per allocation period by C_m, where m
identifies the block size in bits. Combining the rate estimate with an occupancy
correction determines this count. Above the occupancy target, the correction
increases the count to transmit more stored
data. Below the target, it decreases the count to let the FIFO replenish.
A higher C_m means more client blocks and less stuffing.
Integer allocations can make C_m alternate between nearby values even when
the average rates are balanced. The FIFO level can therefore fluctuate around
its target without a sustained drift. Correcting every excursion can amplify
oscillation. A dead zone suppresses these small occupancy corrections while
allowing C_m to follow the rate estimate and fractional accumulation.
Carrying a fractional remainder into later decisions prevents rounding from repeatedly erasing small adjustments. Limits bound the client count, so feedback can correct a mismatch only within the available adjustment range.
Consider a client whose arrival rate increases by 100 ppm (0.01%). Occupancy rises while the averaged estimate catches up, and feedback increases the allocation. The animation illustrates this control approach using example parameters. The shaded band marks a dead zone of 31–33 blocks around a target of 32.
The FIFO gauge shows stored blocks at allocation boundaries. After brief excursions to 34, occupancy ends at 33, within the dead zone. The caption indicates when occupancy correction is active.
Turn the count into payload positions
The calculated C_m specifies how many client blocks to transmit. GMP's
placement algorithm uses that count to distribute client blocks and stuffing
across the payload.
For Ethernet-to-FlexO mapping, C_m applies to a four-frame allocation window.
The example follows one FlexO payload instance.
That window defines the total client allocation; the FIFO does not need to
collect four frames of data before transmission begins. Within the window,
each payload position is assigned to client data or stuffing.
A deterministic delta-sigma algorithm distributes those positions. At each
position, an accumulator adds C_m to its running total. When the total
reaches the window capacity, it selects a client block and subtracts that
capacity. Otherwise, the position carries stuff. This spreads the gaps in
client transfers across the window. A client position consumes the next stored
block, while a stuff position leaves it in place. Both ends can reproduce the pattern from
the count and their position within the window.
The animated example starts at 10,216 arrivals per window. A 100 ppm increase makes the average 10,217.0216. Individual windows contain whole blocks, so most receive 10,217 and occasionally one receives 10,218.
The highlighted period connects the control decision to payload transfers. Of 10,220 available positions, C_m = 10,218 assigns 10,218 to
client blocks and two to stuffing.
Table 10-4
in G.709.1 lists those stuff locations as positions 1 and 5,111. During that
period, 10,217 client blocks enter the FIFO. Sending one more than arrives lowers occupancy from 35 to
34 blocks. The frame capacity stays unchanged while the allocation reduces
the stored excess.
Communicate the allocation through justification control
The receiver cannot recognize stuff by looking for zero blocks, because zero can also be valid client data. Justification control (JC) bytes carry the encoded client count and timing information in frame overhead once per four-frame window. After decoding the count, the receiver applies the same placement rule for the corresponding window and discards the identified stuff positions.
JC also carries fractional timing information, preserving detail finer than the whole-block allocation. The count determines block placement; the fractional information supports client timing recovery. CRC fields allow the receiver to detect corrupted control information.
The overhead must describe the correct payload window. A valid count paired with the wrong window can make the receiver discard client data or forward stuff. A useful verification approach follows a known data sequence through mapping and recovery while varying the client arrival rate. Checking the recovered sequence exercises the relationship between payload and overhead and can expose loss or reordering that a block count alone would miss.
Reliable rate adaptation requires the allocation, buffering, and receiver interpretation to remain consistent as timing changes. GMP provides the transport mechanism, while implementation and verification must establish that control decisions preserve client data across the supported operating range. If you are working with high-speed interfaces such as Ethernet, we would like to hear about the rate-adaptation, synchronization, and verification challenges in your design.