Page 1268 - 5G Basics - Core Network Aspects

2 Transport aspects

Note that the state machine of Figure D.7 or Figure D.8 can also be used for off-line synchronization
checking.

When the GMP sink has synchronized its Cm(t) value to the GMP source, it interprets the received JC octets
according to the following principles:
– When the CRC is good and II = DI, the GMP sink accepts the received Cm(t) value.

– When the CRC is good and II ≠ DI, the GMP sink compares the received Cm(t) value to its expected
Cm(t) value to determine the difference between these values. This difference is compared to the
bit inversion patterns of Table D.2 or Table D.3 to determine the increment or decrement
operation sent by the source and updates its Cm(t) accordingly. Since the CRC is good, the sink can
use either JC1 or JC2 for this comparison.
– When the CRC is bad, the GMP sink compares the received Cm(t) value to its expected Cm(t) value.
The sink then compares the difference between these values, per Table D.2 or Table D.3, to the
valid bit inversion patterns in JC1, and the bit inversion, II and DI pattern in JC2.
• If JC1 contains a valid pattern and JC2 does not, the sink accepts the corresponding increment
or decrement indication from JC1 and updates its Cm(t) accordingly.
• If JC2 contains a valid pattern and JC1 does not, the sink accepts the corresponding increment
or decrement indication from JC2 and updates its Cm(t) accordingly.
• If both JC1 and JC2 contain valid patterns indicating the same increment or decrement
operation, this indication is accepted and the sink updates its Cm(t) accordingly.

• If neither JC1 nor JC2 contain valid patterns, the sink shall keep its current count value and
begin the search for synchronization.
NOTE – If JC1 and JC2 each contain valid patterns that are different from each other, the receiver can either
keep the current Cm(t) value and begin a synchronization search, or it can use the CRC to determine whether
JC1 or JC2 contains the correct pattern.

The GMP sink uses the updated Cm(t) value to extract the client data from the next OPU frame or ODTUk.ts
multiframe.

D.4 CnD(t) encoding and decoding
D.4.1 CnD(t) encoding and decoding for OPUk

The cumulative value of CnD(t) (CnD(t)) is encoded in bits 4-8 of the OPUk and ODTUk.ts justification control
bytes JC4, JC5 and JC6. Bits D1 to D10 in JC4 and JC5 carry the value of CnD(t). Bit D1 carries the most
significant bit and bit D10 carries the least significant bit.

5
The CRC-5 located in JC6 is calculated over the D1-D10 bits in JC4 and JC5. The CRC-5 uses the g(x) = x + x +
1 generator polynomial, and is calculated as follows:
1) The JC4 bits 4-8 and JC5 bits 4-8 octets are taken in network transmission order, most significant
bit first, to form a 10-bit pattern representing the coefficients of a polynomial M(x) of degree 9.
5
2) M(x) is multiplied by x and divided (modulo 2) by G(x), producing a remainder R(x) of degree 4 or
less.
3) The coefficients of R(x) are considered to be a 5-bit sequence, where x is the most significant bit.
4
4) This 5-bit sequence is the CRC-5 where the first bit of the CRC-5 to be transmitted is the coefficient
0
4
of x and the last bit transmitted is the coefficient of x .
The de-mapper process performs steps 1-3 in the same manner as the mapper process, except that here,
the M(x) polynomial of step 1 includes the CRC bits of JC6, resulting in M(x) having degree 14. In the
absence of bit errors, the remainder shall be 00000.
A parallel logic implementation of the source CRC-5 is illustrated in Appendix VI.

1258