TRANSMISSION METHOD

Abstract

A technique is provided for transmitting client data included in a client signal via an optical transmission path of an optical transport network. The optical transport network uses transport frames include a transport frame period for transmitting client data. The method includes receiving multiple client entities comprising multiple client data bits; determining the number of client data entities received during a transport frame period to establish a mean number of client data entities to be included in a transport frame, the mean number of client data entities corresponding to a mean number of client data bits; mapping multiple client data entities into the transport frame wherein mapping comprises alternately adding and subtracting an amount of client data bits to/from the mean number of client data bits for at least two consecutive transport frames; and transmitting the transport frames comprising the client data via the optical transport network.

Claims

1. A method for transmitting client data included in a client signal via an optical transmission path of an optical transport network, the optical transport network using transport frames comprising a transport frame period for transmitting client data, the method comprising the steps of: receiving multiple client data bits during a transport frame period; determining a number of client data entities corresponding to the received multiple client data bits to establish a mean number of client data entities to be included in a transport frame, the mean number of the client data entities corresponding to a mean number of client data bits; mapping multiple client data entities into the transport frame, wherein the mapping comprises alternately adding and subtracting an amount of client data bits to/from the mean number of client data bits for at least two consecutive transport frames; and transmitting the transport frames comprising the client data via the optical transport network.

2. The method according to claim 1, wherein the client data to be included in consecutive transport frames is changed by adding/subtracting a fixed number of client data bits to/from the mean number of client data bits.

3. The method according to claim 1, wherein the number of client data bits mapped into consecutive transport frames is periodically changed.

4. The method according to claim 3, wherein the mapping of the client data entities is performed such that the number of the client data bits to be included in a transport frame is permanently varied.

5. The method according to claim 1, wherein the number of the client data bits mapped into consecutive transport frames is changed in a non-deterministic, stochastic way.

6. The method according to claim 1, wherein the mean number of the client data entities to be included in the transport frame is determined based on a clock rate of the client signal, the transport frame period and the number of the client data bits included in a transport frame.

7. The method according to claim 1, wherein the client data are buffered within a buffer before mapping the client data into the transport frame.

8. The method according to claim 7, wherein the client data continuously written into the buffer and read out of the client data out of the buffer is controlled based on the mean number of the client data entities.

9. The method according to claim 7, wherein the mean number of the client data entities is varied to vary the read out of the client data out of the buffer.

10. The method according to claim 9, wherein the varied number of the client data entities is inserted in an overhead section of the transport frame.

11. The method according to claim 10, wherein at a receiver side, the client data included in the transport frame are buffered within a buffer.

12. The method according to claim 11, wherein the varied number of the client data entities is extracted out of the overhead section of the transport frame to control the readout of data out of the buffer at the receiver side.

13. An optical transmitter for transmitting client data included in a client signal via an optical transmission path of an optical transport network, the optical transport network using transport frames comprising a transport frame period for transmitting client data, the optical transmitter comprising: an interface adapted to receive multiple client data bits during a transport frame period; a processing entity adapted to determine a number of client data entities comprising the multiple client data bits to establish a mean number of client data entities to be included in a transport frame, the mean number of client data entities comprising a mean number of client data bits; a mapping entity adapted to map multiple client data entities into the transport frame, wherein the mapping entity is further adapted to vary an amount of client data to be transmitted in consecutive transport frames by adding or subtracting an amount of client data bits to/from the mean number of client data bits; and an optical transmission entity adapted to transmit an optical signal comprising transport frames including the client data via the optical transport network.

14. An optical receiver for receiving an optical signal of an optical transmission path of an optical transport network, the optical transport network using transport frames for transmitting client data, the optical receiver being adapted to provide client data and a client clock signal, the optical receiver comprising: an interface adapted to receive the optical signal; a processing entity adapted to extract a data entity indicator out of an overhead section of the transport frame, the data entity indicator specifying an amount of data entities included in the transport frame, wherein a value of the data entity indicator associated with consecutive transport frames continuously changes; a buffer adapted to buffer data included in the optical signal; a control entity adapted to receive the extracted data entity indicator and adapted to control a readout of client data out of the buffer based on the continuously changing data entity indicator; and a clock recovery unit adapted to provide the client clock signal based on the continuously changing value of the data entity indicator.

15. A method for receiving an optical signal of an optical transmission path of an optical transport network, the optical transport network using transport frames for transmitting client data, the method comprising the steps of: receiving the optical signal; extracting a data entity indicator out of an overhead section of the transport frame, the data entity indicator specifying an amount of data entities included in the transport frame, wherein a value of the data entity indicator associated with consecutive transport frames continuously changes; buffering client data included in the optical signal; receiving the extracted data entity indicator at a control entity and controlling a readout of client data out of the buffer based on the continuously changing data entity indicator; and recovering a client clock signal based on the continuously changing value of the data entity indicator.

Description

[0055] In order to create an OTUk frame, a client or LO-ODU signal rate is first adapted at the OPU layer and then mapped into the payload area of the OPUk. The adaptation comprises adjusting the client or LO-ODU signal rate to the OPUk data rate. The OPUk overhead contains information to support the adaptation of the client or LO-ODU signal. The adapted OPUk is then mapped into the ODUk. The ODUk overhead contains overhead bytes that allow end-to-end supervision and tandem connection monitoring. Finally, the LO-ODUk is mapped into an HO-ODUk or the HO-ODUk is mapped into an OTUk, which provides framing as well as section monitoring and forward error correction (FEC). It is worth mentioning that OTUk signals are asynchronous within certain specified limits of typically +/−20 ppm.

[0056] In an Optical Transport Network, connections are switched on ODU level. The ODU is thus the switching entity that travels along a network path. A characteristic feature of OTN is the asynchronous operation and the bit synchronous mapping of ODUk into OTUk, which results in the fact that a received ODUk, which gets connected to another output of the network node, determines the clock, specifically the OTN frame clock of the OTUk signal at the output.

[0057] In the following, the mapping procedure for mapping a client signal, specifically a constant bitrate (CBR) client signal into an OPUk payload section, in the following also referred to as server frame or multiframe, in general transport frame, is described in closer detail. The client signal is mapped into the server frame or multiframe on the basis of data entities wherein such data entity may comprise one or more client signal bits. The data entities may comprise n-bit (e.g. n=1, 8). For a given client signal comprising a constant bitrate, the number of data entities (comprising n-bit) arriving during one server frame or server multiframe period is defined by the following formula:

[00001]$\begin{array}{cc}{C}_n=\left(\frac{f_{\mathrm{client}}}{n}.Math.T_{\mathrm{server}}\right)& \left(\mathrm{formula}.Math..Math.F.Math..Math.1\right)\end{array}$

[0058] wherein f.sub.client is the client bit rate or f.sub.LO-ODU is the LO-ODU bit rate, T.sub.server is the frame period of the server frame or server multiframe and C.sub.n is the number of client or LO-ODU n-bit data entities per server frame or server multiframe.

[0059] As only an integer number of n-bit data entities can be transported per server frame or multiframe, the integer value C.sub.n(t) of C.sub.n has to be used. In order to avoid any loosing of client information, any truncation of client data bits is forbidden and the non-integer portion of C.sub.n has to be considered by an appropriate sequence of data entities included in subsequent server frames. For example, if C.sub.n=10.25, the non-integer portion (0.25) can be replicated by the following sequence of data entities included in subsequent server frames [10, 10, 10, 11]. In other words, the non-integer portion is distributed over multiple server frames in order to obtain the correct number of client data bit entities on the time average.

[0060] As already mentioned before, the client and server bit rate are independent. This allows specifying the server bit rate independently from the client bit rates. In addition, client clock impairments are not seen at the server clock. If the client or server bit rate changes due to client or server frequency tolerances, C.sub.n and C.sub.n (t) change accordingly. So, before mapping the client signal into the server frame, C.sub.n and C.sub.n(t) have to be determined continually and the mapping has to be formed based on the actually determined C.sub.n and C.sub.n(t).

[0061] Similarly, in order to extract the correct number of client information entities at the de-mapper, C.sub.n(t) has to be transmitted in the overhead section of the server frame or multiframe from the mapper to the de-mapper.

[0062] FIG. 2 shows the generic functionality of the mapper circuit 10 according to ITU-T G.709, Annex D and FIG. 3 shows the generic functionality of the de-mapper circuit 20 according to ITU-T G.709, Annex D. The mapper circuit 10 comprises a buffer 11 being adapted to receive the client data. The buffer 11 is adapted to temporarily store the client data until said data are provided to a mapping entity for including the data in a server frame or server multiframe. In addition, the buffer 11 may be adapted to determine C.sub.n based on client clock information and server frame clock (also referred to as server clock) information by using upper-mentioned formula F1. Alternatively, the mapper circuit 10 may include a further entity being adapted to determine C.sub.n based on client clock information and server frame clock information.

[0063] In addition, the mapper circuit 10 includes an overhead insertion unit 12 being adapted to insert stuffing information into the server frame or server multiframe as will be described later on, thereby providing server data in form of server frames or server multiframes. At the mapper circuit 10, C.sub.n(t) is determined based on the client and server clocks (wherein at least the client clock may be time-varying). Preferably, C.sub.n(t) may be determined continuously. The received client signal is constantly written into the buffer 11. The read-out process of buffered client data is controlled by the actual value of C.sub.n(t) using a read control entity 13. In addition, C.sub.n (t) is also included into the overhead section by means of the overhead insertion unit 12.

[0064] FIG. 3 shows a de-mapper circuit 20. The de-mapper circuit 20 comprises the reverse structure of the mapper circuit 100. The de-mapper circuit 20 comprises an overhead extraction unit 21. Said overhead extraction unit 21 may receive the server data provided by the mapper circuit 10 via the optical transport network and the server clock. The overhead extraction unit 21 is adapted to extract C.sub.n(t) out of the overhead sections of the server data. The extracted C.sub.n (t) is provided to the read control entity 22 and the buffer 23. The read control entity 22 may provide a write enable signal for enabling the buffer 23 to provide the client data at its output. The buffer may receive the server data and the server clock and may provide client data based on the server data and the C.sub.n(t)-information. The client clock is also generated based on the server clock and the C.sub.n(t)-information.

[0065] Depending on the data rate of the client signal, respectively, the transport capacity provided by payload area of the OPUk, the situation may occur that the payload section of the OPUk provides a higher transport capacity than needed for transmitting the client signal. In other words, the payload data rate of the OPUk is higher than the data rate of the client signal. In order to be able to transmit client signals with any data rate in an OPUk (provided that the client signal data rate is lower than the payload data rate of the OPUk), the client data rate is adapted to the payload data rate of the OPUk by using a justification procedure. The justification procedure uses a sigma/delta data/stuff mapping for adapting the client data rate to the payload data rate. By using said sigma/delta data/stuff mapping, the client data rate is artificially increased by adding stuff bits or stuff data entities (in general stuff information) to the client data. The amount of stuff information is chosen such that the payload section of the OPUk is totally filled with client data and said stuff information.

[0066] FIG. 4 shows a section of the frame structure of the OPUk frame providing information for said justification procedure according to ITU-T G.709, chapter 17. The overhead section of the OPUk frame comprises three justification control (JC) bytes in rows 1 to 3 of column 16, a negative justification opportunity (NJO) byte in row 4, column 16 and a positive justification opportunity (PJO) byte in row 4, column 17, said bytes providing information regarding the performed justifications. The mapping process performed by the mapper circuit 100 generates JC, NJO and PJO bytes according to the tables 17-1 and 17-2 shown in ITU-T G.709, chapter 17 and the de-mapping process performed by a de-mapper circuit 200 at the receiver side interprets the JC, NJO and PJO bytes according to table 17-3. Thereby, the artificially increased client data rate is decreased by removing stuff information thereby obtaining the original client signal out of the OPUk payload section.

[0067] FIG. 5 shows a schematic representation of an OPUk server frame or multiframe with a payload section including data and stuff information obtained by upper-mentioned sigma/delta data/stuff mapping. Depending on the client signal bit rate and the bit rate which can be transported by the server frames, the (time dependent) number (integer number) of client data entities C.sub.n(t) to be transmitted in a single server frame is determined. According to said determined number of client data entities C.sub.n(t), client data entities are mapped into the server frame or server multiframe using sigma/delta data/stuff mapping.

[0068] FIG. 5 schematically illustrates sigma/delta data/stuff mapping according to ITU-T G.709, Annex D. The server frame or multiframe includes in its payload section a plurality of payload fields j, wherein j=1 . . . P.sub.server.

[0069] According to the sigma/delta data/stuff mapping carries payload field j client data if the following inequality is fulfilled:

(j.Math.C.sub.n(t))mod P.sub.server<C.sub.n(t).  (formula F2)

[0070] The payload field j may carry stuff if the following inequality is fulfilled:

(j.Math.C.sub.n(t))mod P.sub.server>C.sub.n(t).  (formula F3)

[0071] In other words, a number of C.sub.n(t) client data entities have to be distributed over P.sub.server payload field locations. In case that P.sub.server is greater than C.sub.n(t), there is a spacing between two payload fields carrying stuff.

[0072] Current developments focus on the transport of a reference clock along an OTU link. Another discussion is to transport Precision time protocol (PTP) over OTN.

[0073] When synchronizing the OTN transport clocks, problems may arise if the frequencies of synchronous services transported in the ODU payload area will be close to integer fractions of the transport rates, i.e. the bitrate of the client signal (in the above-mentioned embodiment the frequency of the reference clock signal) is close to an integer fraction of the bitrate being able to be transported within the server frame. Said proximity of data rates leads to systematic justification patterns with mostly stable justification states and few infrequent extra frequency justification actions for infrequent phase adjustments. This happens for both mapping-schemes used for such client configurations for asynchronous mapping: Asynchronous Mapping Procedure (AMP) as well as generic mapping procedure (GMP).

[0074] Also in Appendix VII of ITU-T recommendation G.8251, the control of jitter and wander within the optical transport network is already described that in the case of small offsets of OTN server and client clock, jitter components may be generated which pass all filters as defined for server to client de-multiplexers. As a result of passing such filters in network scenario with such small frequency differences, an accumulation of such justification events appear with higher probability.

[0075] In order to overcome the problem of low frequency jitter and/or short term wander passing the clock recovery filter in the optical receiver, it is proposed to artificially generate dithering of value of C.sub.n, i.e. a dithering of the mean number of client data entities received during a transport frame period T.sub.server. For example, a dithering of the phase of the client signal mapped into the transport frame may be generated by alternating adding and subtracting a number of bits, (for example m/2-bit, wherein m is the number of bits included in a data entity mapped into the transport frame) per server frame or multi-frame, respectively, at the input for this mapping from the signaled true C.sub.n as used for the buffer control in the mapper for generating the read control out of the buffer depicted in Figure D.1 of G.709 Annex. By, for instance, subtracting from the determined C.sub.n (formula F1) the value of m/2 bits at every odd and adding m/2 bits at every even server frame/multi-frame, a varying phase information of the client signal oscillating around the nominal value is created in the case the server clock is synchronized to a G.813, G.8262, G.812 or G.811 clock. Such phase oscillations, with the frequency of the client phase in relation to the server clock can easily be filtered by the client clock recovery process and the recovery will average the client phase to the average thereby avoiding infrequent few phase steps and its correlated possible accumulation that will generate low frequency jitter or short term wander passing the clock recovery filter.

[0076] In order to provide enough buffer space, the buffer 11 depth of the mapper circuit 10 and also the buffer 21 of the de-mapper circuit 20 for the stored client data at the mapping/de-mapping GMP processor as depicted in Figure D.1 of G.709 Annex needs to be increased to be able to insert at least 2 extra 2*m-bit data entries into a server frame to prevent buffer under/over-run at the mapper/de-mapper.

[0077] FIG. 6 shows a mapper circuit 100 included in an optical transmitter of an optical transmission system being adapted to provide upper-mentioned transmitted data rate dithering in closer detail. The mapper circuit 100 comprises a buffer 110. Said buffer 110 receives the client signal for buffering the client signal. The client signal is a digital signal including a plurality of client data entities, each client data entity comprising n client data bits. In addition, the mapper circuit 100 may comprise a processing entity (not shown in FIG. 6) which is adapted to determine the number of client data entities received during a transport frame period (e.g. based on formula F1). Thereby, a mean number of received client or LO-ODU data entities is determined. In the following, said mean number may be referred to as C.sub.n. In case of a constant bitrate client or LO-ODU signal, the mean number of received client C.sub.n (also referred to as LO-ODU data entities) may comprise a fixed value. The processing entity for determining said the mean number of received client or LO-ODU data entities C.sub.n may be included in the buffer 110 or may be a separate entity.

[0078] Said mean number of received client or LO-ODU data entities C.sub.n comprises a mean number of client or LO-ODU data bits. With n being the number of bits being included in the client or LO-ODU data entity, the mean number of client or LO-ODU data bits is n*C.sub.n. In order to generate a dithering of the client data mapped into subsequent transport frames, the mapper circuit 100 comprises a dithering entity 140. Said dithering entity 140 may receive the server clock, i.e. the clock based on which the transport frames are transmitted via the optical transport network.

[0079] The dithering entity 140 is adapted to modify the mean number of received client data entities C.sub.n in order to achieve a variation of client signal data transmitted in subsequent transport frames. More in detail, the mean number of received client data entities C.sub.n, respectively, in the present case the modified or varied number of received client data entities, in the following referred to as C.sub.n+/−, is used for controlling the read out of client data out of the buffer 110 as well as the mapping of said client data into the transport frames. For example, C.sub.n+/− is provided to the read control entity 130 which is adapted to provide a read enable signal to the buffer 110 based on C.sub.n+/− value. The read out of client data is controlled based on said read enable signal. C.sub.n+/− value is in the following also referred to as data entity indicator.

[0080] Similarly, the modified or varied number of received client data entities C.sub.n+/− is also provided to the mapping entity 120. Said mapping entity maps the client data into the transport frames based on said modified or varied number of received client data entities C.sub.n+/−, i.e. depending on the value of C.sub.n+/−, a certain amount of client data bits are mapped into the transport frame.

[0081] Said dithering of client data mapped into the transport frame may be done in a deterministic way or a non-deterministic, stochastic way. In other words, the mean number of received client data entities C.sub.n provided by the processing entity may be varied by adding/subtracting a fixed number of client data bits to/from the mean number of client data bits included in said mean number of received client data entities C.sub.n or changing C.sub.n based on a certain fixed variation pattern.

[0082] For example, said modified or varied number of received client data entities C.sub.n+/− may be obtained by an alternating adding/subtracting of a certain amount of client data bits. The transport or HO-ODU frame (server frame, multiframe) may include C.sub.m data entities (or data blocks) comprising m bytes, wherein m is an integer value. Preferably, the C.sub.n is modified by adding/subtracting m/2 client or LO-ODU data bytes. Thereby, a certain transport or HO-ODU frame may comprise m/2 less bytes of the client or LO-ODU data signal and the subsequent transport or HO-ODU frame may comprise m/2 more bytes of the client or LO-ODU data signal, both compared to the situation without performing dithering of client or LO-ODU data. In other words, subsequent transport or HO-ODU frames may comprise a different amount of client or LO-ODU data, the difference being one m-byte data block. Thereby, the amount of client or LO-ODU data transmitted in consecutive transport or HO-ODU frames dithers around the mean number of received client or LO-ODU data entities C.sub.n, said dithering being easily filtered out in the client or LO-ODU clock recovery process at the receiver side. The frequency of said dithering, respectively, the phase oscillations caused by said dithering is

[00002]$f_{\mathrm{osc}}=\frac{1}{2*T_{\mathrm{Server}}};$

[0083] with T.sub.Server being the frame period of a transport or HO-ODU frame/multiframe.

[0084] The modified or varied number of received client data entities C.sub.n+/− may be inserted into the overhead section of the transport frame in order to transmit C.sub.n+/− to the receiver side and extract the client data out of the transport frame based on the received value of C.sub.n+/−, respectively, recover the clock of the client signal based on the received value of C.sub.n+/−.

[0085] FIG. 7 shows a demapper circuit 200 included in an optical receiver. The demapper circuit 200 may comprise a processing entity 210 being adapted to extract C.sub.n+/− out of the overhead section of the transport frame of the server data and provide the extracted value of C.sub.n+/− to the read control entity 220. The value C.sub.n+/− is in the following also referred to as data entity indicator. The read control entity 220 may further receive the server clock and provide a control signal based on the server clock and the extracted value of C.sub.n+/−. The payload data included in the server data (data including the client data) may be provided to a buffer 230. The buffer 230 receives the control signal provided by the read control entity 220. The read out of client data out of the buffer 230 is performed based on said control signal. Furthermore, the demapper circuit 200 comprises a clock recovery entity 240, said clock recovery entity 240 receiving the extracted value of C.sub.n+/− and may recover the client signal clock based on C.sub.n+/−. For example, the clock recovery entity 240 may comprise a phase locked loop circuit and a clock recovery filter for recovering the client signal clock. Due to the dithering of C.sub.n+/−, infrequent phase steps resulting from infrequent steps of the data rate of the server data (i.e. infrequent steps of the data rate of the client data transmitted within the transport frames) are avoided which may result in low frequency jitter or short term wander passing the clock recovery filter. Thereby, the transmission quality of high precision synchronous signals, specifically, reference clock signals via an optical transport network is improved.

[0086] FIG. 8 shows a diagram indicating the steps of a method 300 for transmitting client data via an optical transmission path of an optical transport network. As mentioned above, the optical transport network uses transport frames comprising a transport frame period for transmitting client data.

[0087] First, multiple client entities comprising multiple client data bits are received (S310). After receiving said multiple client data bits, the number of client data entities received during a transport frame period is determined (S320) and a mean number of client data entities to be included in a transport frame is established (S330), said mean number of client data entities corresponding to a mean number of client data bits. Furthermore, multiple client data entities are mapped into the transport frame (S340) thereby alternately adding and subtracting an amount of client data bits to/from said mean number of client data bits for at least two consecutive transport frames. Finally, the transport frames comprising said client data are transmitted via the optical transport network (S350).

[0088] FIG. 9 shows method steps of a corresponding method 400 for receiving an optical signal comprising transport frames including a client signal.

[0089] First, the optical signal is received by the optical receiver (S410). After receiving the optical signal, a data entity indicator is extracted out of an overhead section of the transport frame (S420), said data entity indicator specifying an amount of data entities included in the transport frame. Thereby, the value of the data entity indicator associated with consecutive transport frames continuously changes. In addition, client data included in the optical signal are buffered in a buffer entity (S430). The extracted data entity indicator is received at the control entity (S440) and the readout of client data out of the buffer is controlled based on the continuously changing data entity indicator (S450). Finally, a client clock signal is recovered based on the continuously changing value of the data entity indicator (S460).

[0090] It should be noted that the description and drawings merely illustrate the principles of the proposed methods and systems. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the invention and are included within its spirit and scope.

[0091] Finally, it should be noted that any block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the invention. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

[0092] The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, the explicit use of the term “processor” or “computer” should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read-only memory (ROM) for storing software, random-access memory (RAM), and non-volatile storage. Other hardware, conventional and/or custom, may also be included.