The CCITT (the International Telegraph and Telephone Consultative Committee) is a permanent organ of the International Telecommunication Union (ITU). CCITT is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis.
The Plenary Assembly of CCITT which meets every four years, establishes the topics for study and approves Recommendations prepared by its Study Groups. The approval of Recommendations by the members of CCITT between Plenary Assemblies is covered by the procedure laid down in CCITT Resolution No. 2 (Melbourne, 1988).
Recommendation G.706 was prepared by Study Group XVIII and was approved under the Resolution No. 2 procedure on the 5th of April 1991.
___________________
CCITT NOTES
1) In this Recommendation, the expression ôAdministrationö is used for conciseness to indicate both a telecommunication Administration and a recognized private operating agency.
2) A list of abbreviations used in this Recommendation can be found in Annex D.
πITU1991
All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the ITU.
PAGE BLANCHE
Recommendation G.706
Recommendation G.706
FRAME ALIGNMENT AND CYCLIC REDUNDANCY CHECK (CRC) PROCEDURES
RELATING TO BASIC FRAME STRUCTURES DEFINED IN RECOMMENDATION G.704
(Melbourne, 1988, revised 1990)
1 General
This Recommendation relates to equipment which receives signals with basic frame structures as defined in Recommendation G.704. It defines the frame alignment, the cyclic redundancy check (CRC) multiframe alignment and CRC bit error monitoring procedures to be used by such equipment. Annex A contains background information about the use of the CRC procedures and their limitations.
Annex B gives details of a modified CRC-4 multiframe alignment algorithm which allows automatic interworking between equipment with and without a CRC-4 capability. Annex C gives details regarding the updating of CRC-4 information when an intermediate equipment (i.e. between true path terminating equipments) has a write-access to a message-based data-link facility (see Recommendation G.704, º 2.3.3.5.4).
2 Frame alignment and CRC procedures at l544 kbit/s interface
2.1 Loss and recovery of frame alignment
There are two alternative multiframe structures at the 1544 kbit/s interface:
a) 24-frame multiframe, and
b) 12-frame multiframe.
2.1.1 Loss of frame alignment
The frame alignment signal should be monitored to determine if frame alignment has been lost. Loss of frame alignment should be detected within 12 ms. Loss of frame alignment must be confirmed over several frames to avoid the unnecessary initiation of the frame alignment recovery procedure due to transmission bit errors. The frame alignment recovery procedure should commence immediately once loss of frame alignment has been confirmed.
Note û For the 12-frame multiframe described in Recommendation G.704, loss of multiframe alignment is deemed to occur when loss of frame alignment occurs.
2.1.2 Recovery of frame alignment
2.1.2.1 Frame alignment recovery time
The frame alignment recovery time is specified in terms of the maximum average reframe time in the absence of errors. The maximum average reframe time is the average time to reframe when the maximum number of bit positions must be examined for locating the frame alignment signal.
a) 24-frame multiframe
The maximum average reframe time should not exceed 15 ms.
Note û Some existing designs of equipment were designed to a limit of 50 ms.
b) 12-frame multiframe
The maximum average reframe time should not exceed 50 ms.
Note û These times do not include the time required for the CRC procedure for false frame alignment verification defined in º 2.2.2.
2.1.2.2 Strategy for frame alignment recovery
a) 24-frame multiframe
Frame alignment should be recovered by detecting the valid frame alignment signal. When the CRC-6 code is utilized for error performance monitoring (see º 2.2.3), the CRC-6 information may be coupled with the framing algorithm to ensure that a valid frame alignment signal contained within the 24 F-bits is the only pattern onto which the reframe circuit can permanently lock. This procedure is illustrated in Figure 1/G.706.
b) 12-frame multiframe
Overall frame alignment should be recovered by way of simultaneous detection of the frame alignment signal and the multiframe alignment signal, or of frame alignment followed by multiframe alignment.
FIGURE 1 G.706 = 12.5 cm
2.2 CRC bit monitoring
Error monitoring by CRC-6 assumes a signal quality sufficient for frame alignment to be established so that CRC-6 bits can be correctly accessed.
2.2.1 Monitoring procedure
i) A received CRC message block (CMB) is acted upon by the multiplication/division process defined in Recommendation G.704 after having its F-bits replaced by binary 1s.
ii) The remainder resulting from the division process is then stored and compared on a bit-by-bit basis with the CRC bits received in the next CMB.
iii) If the remainder exactly corresponds to the CRC bits contained in the next CMB of the received signal, it is assumed that the checked CMB is error-free.
2.2.2 Monitoring for false frame alignment (see º A.1.1)
In the case of the 24-frame multiframe, when the CRC-6 code is utilized for error performance monitoring, it may also be used to provide immunity against spurious frame alignment signals. The procedure described in º2.1.2.2a) should be followed.
2.2.3 Error performance monitoring using CRC-6 (see º A.1.2)
For the purpose of error performance monitoring, it should be possible to obtain indications of each CRC message block which is received in error. The consequent error information should be used in accordance with the requirements to be defined in respective equipment Recommendations.
3 Frame alignment and CRC procedures at 6312 kbit/s interface
3.1 Loss and recovery of frame alignment
For the 6312 kbit/s hierarchical level, the term ôframe alignmentö is synonymous of ômultiframe alignmentö. The last five bits of the 789-bit frame are designated as the F-bits (see Recommendation G.704) and are time-shared as a frame alignment signal and for other purposes.
3.1.1 Loss of frame alignment
The frame alignment signal should be monitored to determine if frame alignment has been lost. The loss of frame alignment is declared when seven consecutive incorrect frame alignment signals have been received.
The recovery of frame alignment procedure should start immediately once loss of frame alignment has been confirmed.
3.1.2 Recovery of frame alignment
3.1.2.1 Frame alignment recovery time
The frame alignment recovery time is specified in terms of the maximum average reframe time in the absence of errors. The maximum average reframe time is the average time to reframe when the maximum number of bit positions must be examined for locating the frame alignment signal.
The maximum average reframe time should be less than 5 ms.
3.1.2.2 Strategy for frame alignment recovery
Frame alignment should be recovered by detecting three consecutive correct frame alignment signals. In addition to this, the CRC-5 code (see º 3.2) should be coupled with the framing algorithm to ensure that a valid frame alignment signal contained within the F-bits is the only pattern onto which the reframe circuit can permanently lock. This procedure is illustrated in Figure 1/G.706.
3.2 CRC bit monitoring
Error monitoring by CRC-5 assumes a signal quality sufficient for frame alignment to be established so that the CRC-5 bits can be correctly accessed.
3.2.1 Monitoring procedure
i) A received sequence of 3156 serial bits (i.e. 3151 bits of CMB and 5 CRC bits) is divided by the generator polynomial defined in Recommendation G.704.
ii) If the remainder resulting from the division process is 00000, it is assumed that the checked CMB is error-free.
3.2.2 Monitoring for false frame alignment (see º A.1.1)
The procedure in º 3.1.2.2 should be followed when the CRC-5 code is used to provide immunity against false frame alignment signal.
Using the CRC-5 code, it should be possible to detect false frame alignment within 1 second and with greater than 0.99 probability. On detection of such an event, a research for correct frame alignment should be initiated.
With a random error ratio of 10û4, the mean time between two events of falsely initiating a search for frame alignment due to an excessive number of errored CRC message blocks should be more than one year.
Note 1 û With a random error ratio of approximately 10û3, it is almost impossible to distinguish whether CRC errors are caused by the false frame alignment or by transmission bit errors.
Note 2 û To achieve the probability bounds stated above, one method is to count the errored CRC-5 message blocks with the understanding that a count of 32 consecutive errored CRC-5 blocks indicates false frame alignment.
3.2.3 Error performance monitoring using CRC-5 (see º A.1.2)
For the purpose of error performance monitoring, it should be possible to obtain indications for each CRC message block which is received in error. The consequent error information should be used in accordance with the requirements to be defined in the respective equipment Recommendations.
4 Frame alignment and CRC procedures at 2048 kbit/s interface
4.1 Loss and recovery of frame alignment
4.1.1 Loss of frame alignment
Frame alignment will be assumed to have been lost when three consecutive incorrect frame alignment signals have been received.
Note 1 û In addition to the preceding, in order to limit the effect of spurious frame alignment signals, the following procedure may be used:
Frame alignment will be assumed to have been lost when bit 2 in time slot 0 in frames not containing the frame alignment signal has been received with an error on three consecutive occasions.
Note 2 û Loss of frame alignment can also be invoked by an inability to achieve CRC multiframe alignment in accordance with º 4.2, or by exceeding a specified count of errored CRC message blocks as indicated in º 4.3.2.
4.1.2 Strategy for frame alignment recovery
Frame alignment will be assumed to have been recovered when the following sequence is detected:
û for the first time, the presence of the correct frame alignment signal;
û the absence of the frame alignment signal in the following frame detected by verifying that bit 2 of the basic frame is a 1;
û for the second time, the presence of the correct frame alignment signal in the next frame.
Note û To avoid the possibility of a state in which no frame alignment can be achieved due to the presence of a spurious frame alignment signal, the following procedure may be used:
When a valid frame alignment signal is detected in frame n, a check should be made to ensure that a frame alignment signal does not exist in frame n + 1, and also that a frame alignment signal exists in frame n + 2. Failure to meet one or both of these requirements should cause a new search to be initiated in frame n + 2.
4.2 CRC multiframe alignment using information in bit 1 of the basic frame
If a condition of assumed frame alignment has been achieved, CRC multiframe alignment should be deemed to have occurred if at least two valid CRC multiframe alignment signals can be located within 8 ms, the time separating two CRC multiframe alignment signals being 2 ms or a multiple of 2 ms. The search for the CRC multiframe alignment signal should be made only in basic frames not containing the frame alignment signal.
If multiframe alignment cannot be achieved within 8 ms, it should be assumed that frame alignment is due to a spurious frame alignment signal and a research for frame alignment should be initiated.
Note 1 û The research for frame alignment should be started at a point just after the location of the assumed spurious frame alignment signal. This will usually avoid realignment onto the spurious frame alignment signal.
Note 2 û Consequent actions taken as a result of loss of frame alignment should no longer be applied once frame alignment has been recovered. However, if CRC multiframe alignment cannot be achieved within a time limit in the range of 100 ms to 500 ms, e.g. owing to the CRC procedure not being implemented at the transmitting side, consequent actions should be taken equivalent to those specified for loss of frame alignment.
Note 3 û Equipment incorporating the CRC-4 procedure should be designed to be capable of interworking with equipment which does not incorporate the CRC-4 procedure; that is, an ability to continue to provide service (traffic) between equipments with and without a CRC-4 capability. This can be achieved either manually (e.g. by straps) or automatically.
û For the manual case, the equipment incorporating the CRC-4 procedure should be capable of fixing bit-1 of the frame to the binary ô1ö (see Table 4a/G.704 Note 1).
û For the automatic case, this can be achieved at the equipment having the CRC-4 capability either:
û as a ôhigher-layerö function under the control of a network management facility (e.g. a TMN) û the details are for futher study; or
û as a ôlower-layerö function using a modified CRC-4 multiframe alignment algorithm as described in Annex B.
4.3 CRC bit monitoring
If frame and CRC multiframe alignment have been achieved, the monitoring of the CRC bits in each sub-multiframe should commence.
4.3.1 Monitoring procedure
i) A received CRC sub-multiframe (SMF) is acted upon by the multiplication/division process defined in Recommendation G.704 after having its CRC bits extracted and replaced by 0s.
ii) The remainder resulting from the division process is then stored and subsequently compared on a bit-by-bit basis with the CRC bits received in the next SMF.
iii) If the remainder exactly corresponds to the CRC bits contained in the next SMF of the received signal, it is assumed that the checked SMF is error-free.
4.3.2 Monitoring for false frame alignment (see º A.1.1)
It should be possible to detect a condition of false frame alignment within 1 second and with a probability greater than 0.99. On detection of such an event, a research for frame alignment should be initiated.
With a random error ratio of 10û3 the probability of falsely initiating a search for frame alignment due to an excessive number of errored CRC blocks should be less than 10û4 over a 1 second period.
Figure 2/G.706 shows an illustration of the procedure to be followed in passing from the frame alignment search to error monitoring using CRC.
Note 1 û The research for frame alignment should be started at a point just after the location of the assumed spurious frame alignment signal. This will usually avoid realignment onto the spurious frame alignment signal.
Note 2 û To achieve the probability bounds stated above, a preferred threshold count is 915 errored CRC blocks out of 1000, with the understanding that a count of │ 915 errored CRC blocks indicates false frame alignment.
FIGURE 2 G.706 = 14 cm
4.3.3 Error performance monitoring using CRC-4 (see º A.1.2)
Information on the status of the CRC processing should be made available in two forms:
a) Direct information
Every time a CRC block is detected in error, it will be necessary to indicate this condition.
b) Integrated information
In consecutive 1 second periods, the number of errored CRC blocks should be made available. This number will be in the range 0 to 1000 (decimal).
5 Frame alignment and CRC procedures at 8448 kbit/s interface
For further study.
ANNEX A
(to Recommendation G.706)
Background information on the use of cyclic
redundancy check (CRC) procedures
A.1 Reasons for application of CRC
CRC procedures can be used for both protection against false frame alignment and for bit error monitoring.
A.1.1 Protection against false frame alignment
The CRC procedures are used to protect against false frame alignment of receivers of multiplex signals. For example, false frame alignment could occur in an ISDN if a user imitates a frame alignment signal in his non-voice terminal. However, since a user is not controlling the composition of a multiplex frame, the addition of CRC bits, and evaluation of these bits in the receiver, leads to detection of the false frame alignment.
A.1.2 Bit error monitoring
The CRC procedure is also used for improved bit error ratio monitoring if low values of error ratio (e.g. 10û6) are to be considered. CRC monitoring (like monitoring of the frame alignment signal) takes account of the entire digital link between the source and sink of a multiplex signal, as opposed to code violation monitoring (e.g. monitoring of AMI, HDB3 or B8ZS violations) which concerns only the digital line section nearest to the receiver, or in many cases only an interface line [e.g. between a digital multiplexer and an exchange terminal (ET)].
A.2 Limitations of CRC procedures
A.2.1 Probability of undetected bit errors
It can be estimated [1] that for CRC-n, and long message/check blocks, the probability that an error remains undetected approaches 2ûn even with a high bit error ratio; with a low bit error ratio, the probability is lower. The resulting inaccuracy (at most, with CRC-4, about 6% of blocks with undetected errors; similarly, with CRC-6, 1.6%) is tolerable for the required purpose.
A.2.2 Limitation of application to bit error ratio measurement
The CRC monitoring procedure is not well suited to measure values of bit error ratio that are so high that on average every message/check block contains at least one bit error (i.e. for BER = 10û3 or higher).
ANNEX B
(to Recommendation G.706)
Modified CRC-4 multiframe alignment algorithm to allow automatic interworking
between equipments with and without a CRC-4 capability
B.1 General
Situations are envisaged when it may be necessary to allow automatic interworking between equipments with and without CRC-4 capability, e.g. in a switched/managed 2048 kbit/s network. Two methods of achieving automatic interworking are:
û method 1: Using a ôlower-layerö approach based on a modified CRC-4 multiframe alignment algorithm.
û method 2: Using a "higher-layer" approach based on remote control via a network management facility.
This annex details an implementation using method 1. Method 2 is for further study.
B.2 Modified CRC-4 multiframe alignment algorithm
B.2.1 Overview of algorithm
The modified CRC-4 multiframe alignment algorithm is based on the following strategy:
If a valid basic frame alignment signal is consistently present but CRC-4 multiframe alignment is not achieved by the end of the total CRC-4 multiframe alignment search period, it is assumed that the distant end is a Non-CRC-4 equipment.
B.2.2 Consequent actions for CRC-4-to-Non-CRC-4 equipment interworking
Under these circumstances, the following consequent actions apply at the equipment having the CRC-4 capability:
a) provide an indication (not necessarily an alarm) that there is ôno incoming CRC-4 multiframe alignment signalö;
b) inhibit CRC-4 processing on the receive 2048 kbit/s signal;
c) continue to transmit CRC-4 data to the distant end with both ôEö bits (see Table 4b/G.704) set to zero.
Note û This allows, as explained in º B.2.5, the identification of failure of CRC-4 multiframe alignment generation/detection, but with correct basic framing, when interworking between equipments each having the modified CRC-4 multiframe alignment algorithm.
The algorithm is robust against spurious basic frame alignment and there are no interworking problems with equipment having a manually selectable CRC-4 capability.
B.2.3 Details of the alignment algorithm
Figure B-1/G.706 depicts a block-schematic flow diagram of the alignment algorithm.
A 400 ms CRC-4 multiframe alignment search period ensures that correct basic and CRC-4 multiframe alignment is possible for up to about 40 spurious simulations of the basic frame alignment sequence present between two real basic frame alignment signal locations.
The 400 ms timer is triggered on the initial (i.e. primary) recovery of basic frame alignment. Once the 400ms timer is triggered, it is not reset unless the criteria for ôloss of (primary) basic frame alignmentö occurs (see º4.1.1): The ôloss of (primary) basic frame alignmentö checking process runs continuously irrespective of the state of the CRC-4 multiframe alignment process below it.
A research for basic frame alignment initiated if CRC-4 multiframe alignment cannot be achieved in 8 ms (as required in º 4.2) should not reset the 400 ms timer or invoke consequent actions associated with loss of primary basic frame alignment, that is, in this particular section of the alignment flow diagram, all searches for basic frame alignment are carried out in parallel with, and hence independent of, the primary basic frame loss checking process (see Figure B-1/G.706). All subsequent searches for CRC-4 multiframe alignment are associated with each basic framing sequence found during the parallel search.
In order that the algorithm does not introduce a disturbance (of 400 ms maximum duration) to traffic during the search for CRC-4 multiframe alignment, traffic should be allowed through upon, and synchronized to, the initially determined primary basic frame alignment sequence.
If a CRC-4 multiframe alignment signal is found before the 400 ms timer elapses, then the basic frame alignment sequence associated with the CRC-4 multiframe alignment signal should be the one chosen, i.e. if necessary, the primary basic frame alignment position should be amended accordingly. CRC-4 processing would then determine if this was truly the valid alignment location (in accordance with º 4.3.2). However, if a CRC-4 multiframe alignment sequence cannot be found before the 400 ms timer elapses, it should be concluded that a condition of interworking between equipments with and without a CRC-4 capability exists; in this case traffic should be maintained to the initially determined primary basic frame alignment signal location and the consequent actions given in º B.2.2 invoked.
If the 2048 kbit/s path is reconfigured at any time, then it is assumed that the (new) pair of path terminating equipments will need to re-establish the complete framing process, i.e. the algorithm is reset.
B.2.4 Setting of the ôEö bits during and after alignment
CRC-4 equipment using the modified CRC-4 multiframe alignment algorithm should always set the return CRC-4 data in the E bits to zero until the equipment interworking relationship has been established at the end of the complete framing sequence. At this time the following consequent actions should apply:
û If CRC-4-to-CRC-4 equipment interworking is established, then normal CRC-4 processing of errored CRC-4 block data should commence, e.g. setting the E bits in accordance with Recommendation G.704, º 2.3.3.4.
û If CRC-4-to-Non-CRC-4 equipment interworking is established, the E bits should remain at 0 (this being of no consequence to the Non-CRC-4 equipment).
B.2.5 Detection of CRC-4 multiframe generator/detector failure (basic framing correct) in equipments using the modified CRC-4 multiframe algorithm
The reception of a permanent state of E bits set to 0 signifies that the distant equipment is unable to achieve CRC-4 multiframe alignment.
Note û If the A (remote alarm indication (RAI)) bit is not set to 1 in TS0 then the distant end is assumed to have achieved basic frame alignment.
The inability to gain CRC-4 multiframe alignment at the distant end should not result in an alarm at the distant end, but only an indication of the condition. It would then be up to maintenance personnel at the local and distant ends to identify if the CRC-4 multiframe alignment generator or detector had failed.
The integration period and threshold value for determining this failure mode should be a count of more than990 errored CRC-4 blocks, as determined from the E bit data, in each second (i.e. out of a 1000 CRC-4 check blocks) for five consecutive seconds. These values have been chosen since they are almost inconceivable as a result of any error distribution which did cause some other effect, e.g. either local loss of frame alignment, or distant loss of frame alignment signified by the reception of the A (RAI) bit set in TS0.
FIGURE B-1/G.706 = page pleine
Notes to Figure B-1/G.706
Note 1 û Until primary basic frame alignment is established the A (RAI) bit should be set to one and the E bits set to zero. When primary basic frame alignment is established, both the A (RAI) and E bits should be set to zero.
If CRC-4 multiframe alignment is subsequently achieved within the 400 ms search window, primary basic frame alignment should be confirmed to that associated with the CRC-4 multiframe alignment position. CRC-4 performance monitoring should then start (see º 4.3.1) with the E bits set in accordance with Recommendation G.704 º 2.3.3.4. If however, CRC-4 multiframe alignment cannot be achieved within the 400 ms search window but a state of primary basic frame alignment has been consistently present, then incoming CRC-4 processing should remain inhibited and both the A (RAI) and E bits should remain set to zero. The information provided by the A and E bits (taken together) allows the possibility of identifying failure of the CRC-4 multiframe alignment signal generator/receiver when primary basic frame alignment is consistently present (see º B.2.5).
Note 2 û Once the initial primary basic frame alignment is established, a primary basic frame alignment loss checking process is enabled; this now runs continuously as a background process, i.e. a loss of primary basic frame alignment at any time should reset the algorithm.
In practice the 400 ms timer could be a suitably calibrated counter.
Note 3 û As already observed in Note 1 to ºº 4.2 and 4.3.2, during any search for parallel basic frame alignment, the search should commence at a point just after any previous alignment position. When taken in conjunction with the 400ms timer, the strategy can avoid about 40 independent spurious framing sequences between true framing sequences.
Note 4 û It is assumed that any reconfiguration of the 2048 kbit/s path (e.g. due to a management request in a switched 2048 kbit/s network) results in a loss of primary basic framing between the (new) pair of path termination equipments, i.e. the algorithm is completely reset.
Note 5 û It is not considered necessary to associate a ôtime-outö with each parallel basic frame alignment search since:
û it is intended that the 400 ms timer be continuously referenced during the parallel basic frame alignment search, such that if the 400 ms timer elapses the parallel basic frame alignment search terminates and the state of ôCRC-4 to Non-CRC-4 interworkingö is entered;
û in practice, even if no spurious simulations of the basic frame alignment are present, it is likely that a parallel basic frame alignment search state will be entered/exited several times during the 400 ms CRC-4 multiframe alignment search window due to the parallel search repeatedly discovering the primary basic frame alignment position.
ANNEX C
(to Recommendation G.706)
CRC-4 checksum updating procedure at intermediate path points
in a message-based data-link application
C.1 General
The Sa4 bit may be used as a message-based data-link within 2048 kbit/s paths (see Note 4 to Table4a/G.704). Situations are envisaged where access to this data-link could be required at points on the path between the true path termination points, e.g. reporting of error performance data from intermediate sites along the path. In such situations it is important that the logical path termination role of CRC-4 is not invalidated or impaired. Hence, any changes to the Sa4 bits within a SMF at an intermediate path point does not imply a recalculation of the CRC-4 bits over the whole SMF, but rather their update as a linear re-coding function in respect of specific deterministic binary changes of the Sa4 bits only.
This annex gives:
û a mathematical proof of the validity of the updating procedure, and
û an example of the conceptual basis for implementation û including the principle by which the updating procedure can be extended, if required, to include all the spare bits, i.e. Sa4 to Sa8.
C.2 Mathematical proof of validity of updating procedure
The complete bit pattern of a SMF can be represented as a data polynomial, D(x), of degree 2047 in x by:
where
ai = 0 or 1, and the degree of x represents the bit position within the SMF.
The CRC-4 checksum for D(x) is the remainder, R(x), resulting from the modulo 2 division of x4D(x) by the CRC-4 generator polynomial G(x), that is
where
G(x) = x4 + x + 1
Q(x) = Quotient polynomial, having the same degree as D(x)
The polynomial representation of the Sa4 bit positions of the SMF is a specific form of equation (C-1), viz:
If we let the polynomial Sa4 diff (x) represent the desired changes in the Sa4 bit positions of the SMF, then:
That is, Sa4 diff (x) has ô1sö only in the positions where the ônewö Sa4 bit does not match that already present in D(x).
Applying the general form of equation (C-2) to equation (C-4), we get:
Rearranging and collecting like-terms in equation (C-5) yields:
Equation (C-6) shows that the required (i.e. updated) CRC-4 checksum, Rnew(x), is simply the modulo 2 sum of the original CRC-4 checksum, R(x), and the remainder, Rdiff (x), from applying the CRC-4 encoding process to the polynomial representation of the desired Sa4 bit changes in the SMF. That is:
Note that the above process is based only on deterministic changes to the bit structure of D(x), i.e. the SMF. Any errors present in D(x) or its associated CRC-4 checksum, R(x), are not known to the updating process. Hence, the true end-to-end path error detection property of the CRC-4 procedure is preserved.
Clearly the updating process can be applied to any deterministic changes to the bit structure of D(x), e.g. the other Sa bits.
C.3 An example of a conceptual basis for implementing the updating process
Figure C-1/G.706 shows a conceptual basis for implementing the CRC-4 updating process which takes any combination of the Sa bits into account; the example is not intended to constrain actual methods of practical implementation.
FIGURE C-1/G.706 = 7 cm
ANNEX D
(to Recommendation G.706)
Alphabetical list of abbreviations used
in this Recommendation
BFA Basic frame alignment
CMB CRC message bloc
CRC Cyclic redundancy check
ET Exchange terminal
MFA Multiframe alignment
RAI Remote alarm indication
SMF Sub-multiframe
Bibliography
[1] LEUNG (C.) and WITZKE (K.A).: A comparison of some error detecting CRC code standards, IEEE Trans., Vol. COM-33, pp. 996-998, 1985.
