AN OPTICAL TRANSPORT NETWORK

Technical Field

Examples of the present disclosure relate to transmitting or routing data, such as for example an Optical Transport Unit (OTUk or OTUC) or an Optical Data Unit (ODUk or ODUC), in an Optical Transport Network (OTN).

Background

An optical transport network (OTN) is a network including optical communication links between nodes. An optical transport network may provide optical communication links in cellular networks, for example in fronthaul, backhaul and/or core network portions of Long Term Evolution (LTE) and 5G networks. An optical network may be selected to provide high capacity and/or low latency.

Summary

One aspect of the present disclosure provides a method of transmitting an Optical Transport Unit (OTUk or OTUC) over an Optical Transport Network (OTN). The method comprises providing, in overhead in the OTUk or OTUC, an indication of a class of service of data within the OTUk or OTUC, and transmitting the OTUk or OTUC over the OTN.

A further aspect of the present disclosure provides a method of routing an Optical Data Unit (ODUk or ODUC) in an Optical Transport Network (OTN). The method comprises selecting a path for the ODUk or ODUC from a plurality of paths based on an indication in overhead received with the ODUk or ODUC of a class of service of data within the ODUk or ODUC, and causing the ODUk or ODUC to be transmitted on the selected path.

An additional aspect of the present disclosure provides apparatus for transmitting an Optical Transport Unit (OTUk or OTUC) over an Optical Transport Network (OTN). The apparatus comprises a processor and a memory. The memory contains instructions executable by the processor such that the apparatus is operable to provide, in overhead of the OTUk or OTUC, an indication of a class of service of data within the OTUk or OTUC, and transmit the OTUk or OTUC over the OTN.

Another aspect of the present disclosure provides apparatus for routing an Optical Data Unit (ODUk or ODUC) in an Optical Transport Network (OTN). The apparatus comprises a processor and a memory. The memory contains instructions executable by the processor such that the apparatus is operable to select a path for the ODUk or ODUC from a plurality of paths based on an indication in overhead received with the ODUk or ODUC of a class of service of data within the ODUk or ODUC, and cause the ODUk or ODUC to be transmitted on the selected path.

A further aspect of the present disclosure provides apparatus for transmitting an Optical Transport Unit (OTUk or OTUC) over an Optical Transport Network (OTN). The apparatus is configured to provide, in overhead of in the OTUk or OTUC, an indication of a class of service of data within the OTUk or OTUC, and transmit the OTUk or OTUC over the OTN.

A still further aspect of the present disclosure provides apparatus for routing an Optical Transport Unit (OTUk or OTUC) in an Optical Transport Network (OTN). The apparatus is configured to select a path for the ODUk or ODUC from a plurality of paths based on an indication in overhead received with the ODUk or ODUC of a class of service of data within the ODUk or ODUC, and cause the ODUk or ODUC to be transmitted on the selected path.

Brief Description of the Drawings

For a better understanding of examples of the present disclosure, and to show more clearly how the examples may be carried into effect, reference will now be made, by way of example only, to the following drawings in which:

Figure 1 shows an example of an optical transport network (OTN);

Figure 2 shows an example of overhead in an Optical Transport Unit (OTUk);

Figure 3 shows another example of overhead in an Optical Transport Unit (OTUk);

Figure 4 is a flow chart of an example of a method of transmitting an Optical T ransport Unit (OTUk or OTUC) over an Optical Transport Network (OTN); Figure 5 is another example of an optical transport network (OTN);

Figure 6 is a flow chart of an example of a method of routing an Optical Data Unit (ODUk or ODUC) in an Optical Transport Network (OTN)

Figure 7 is a schematic of an example of apparatus 700 for transmitting an Optical Transport Unit (OTUk or OTUC) over an Optical Transport Network (OTN); and

Figure 8 is a schematic of an example of apparatus 800 for routing an Optical Data Unit (ODUk or ODUC) in an Optical Transport Network (OTN).

The following sets forth specific details, such as particular embodiments or examples for purposes of explanation and not limitation. It will be appreciated by one skilled in the art that other examples may be employed apart from these specific details. In some instances, detailed descriptions of well-known methods, nodes, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more nodes using hardware circuitry (e.g., analog and/or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc.) and/or using software programs and data in conjunction with one or more digital microprocessors or general purpose computers. Nodes that communicate using the air interface also have suitable radio communications circuitry. Moreover, where appropriate the technology can additionally be considered to be embodied entirely within any form of computer-readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analogue) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions.

Different applications and services that use cellular (or mobile) networks may have different requirements in terms of quality of service (QoS). For example, they may have different requirements for delay/latency, throughput, reliability and/or availability. In one example, in the application of smart vehicle and autonomous driving, a vehicle moving at 100km/h will move 27.8m every second, or 2.78cm every millisecond. If road sensors capture an unexpected event on the road, <1 ms end-to-end latency for sending data from a road sensor means that information may reach the vehicle (e.g. via the cloud) in a time frame that corresponds to less than one meter movement of the vehicle.

In other applications, such as for example a cloud-based storage service for a device, a low latency connection between the device and a remote data center may not be needed. Hence, latency requirements, and/or other requirements for communications, may vary between applications and services.

Data is transported over an optical transport network (OTN) using optical transport units and optical data units. An optical data unit may carry data (e.g. in the form of an optical payload unit) from a source node to a destination node. In some cases, the optical data unit may be transported via a router or switch. An optical transport unit carries an optical data unit between two nodes, such as for example between a source and router. The optical transport unit is terminated at the router, and the optical data unit therein transferred to a new optical transport unit before being sent to a next hop or the destination.

An optical transport unit may be referred to as OTUC or OTUk, reflecting the speed of a communication link. For example, where k=4, OTU4 may carry data at a "l OOGbps rate. OTUC allows for 200Gbps, 400Gbps, 600Gbps or higher rates. In some examples, an optical link using OTUC operates at 105.258Gbps, and an OTUCn optical link is composed of n x OTUC links.

Figure 1 shows an example of an optical transport network (OTN) 100 in which data is sent from a source 102 to a destination 104 via a router (or switch) 106. The data is sent in an optical data unit, ODUC or ODUk 108. The optical data unit is passed unchanged from the source 102 to the destination 104 via the router 106. A first optical transport unit, OTUC or OTUk 1 10 carries the ODUC or ODUk 108 to the router 106. A second OTUC or OTUk 1 12 carries the ODUC or ODUk 108 to the destination 104. In other examples, there may be further routers/switches in the network 100.

In some examples, the ODUC or ODUk 108 includes overhead, referred to as ODUC/ODUk overhead. Therefore, in some examples, each OTUC or OTUk 1 10 and 1 12 may include ODUC/ODUk overhead as well as respective OTUC/OTUk overhead. In some examples, where data in the ODUC/ODUk 108 is in the form of an optical payload unit (OPU), the ODUC/ODUk 108 and the OTUC/OTUks 1 10 and 112 may also contain OPU overhead.

Figure 2 shows an example of overhead 200 in an OTUk, as defined in ITU-T G.709/Y.1331 06/2016, which is incorporated herein by reference. The overhead 200 is organised in rows and columns, where each row provides contiguous information in the OTUk, and the rows are not contiguous with each other, as they are separated by portions of OPUk data. Each column includes a byte of overhead in each row. The overhead 200 includes in row 1 a frame alignment overhead and OTUk overhead, as well as two bytes of OPUk overhead in columns 15 and 16. Rows 2-4 each include ODUk overhead and two bytes of OPUk overhead. While the overhead 200 in Figure 2 shows OTUk overhead, an OTUC includes overhead that has a similar structure and contains includes OTUC overhead and ODUC overhead.

The overhead 200 does not indicate any information regarding the type of payload, information or data contained within the OTUC/OTUk. Therefore, OTUC/OTUks are treated in the optical network (e.g. routed, switched or prioritized) without considering the type of data being transported.

In embodiments of the present disclosure, it is proposed to provide an indication of a Class of Service (CoS) of data within an OTUC/OTUk. This indication is provided in overhead in the OTUC/OTuk. The overhead 200 of Figure 2 includes six bytes of reserved information in row 4, columns 9-14. In some embodiments, the indication may be included within the currently reserved data. Figure 3 shows an example of OTUk overhead 300 that has a similar structure and format to the overhead 200 shown in Figure 2, except that the reserved byte in row 4, column 9 is replaced by an indication 302 of a class of service (CoS) of information carried in the corresponding OTUk. Similarly, in other embodiments, a reserved byte of ODUC overhead in an OTUC may be used to provide an indication of the CoS. More generally, the indication may be included in any appropriate manner anywhere in the overhead (OTUC/OTUk overhead, ODUC/ODUk overhead and/or OPUC/OPUk overhead) in an OTUC or OTUk.

Figure 4 is a flow chart of an example of a method 400 of transmitting an Optical Transport Unit (OTUk or OTUC) over an Optical Transport Network (OTN). The method 400 may be carried out in some examples by a source node (including e.g. a wireless device or User Equipment, UE), a router or switch node or any other node in an optical transport network (OTN). The method 400 comprises, in step 402, providing, in overhead in the OTUk or OTUC, an indication of a class of service of data within the OTUk or OTUC. Providing the indication in the overhead may comprise for example inserting the CoS into the overhead or forwarding the indication in overhead, for example from overhead in an OTUC/OTUk received from a previous hop. The indication may be provided in any part of the overhead, for example in OTUC/OTUk overhead, ODUC/ODUk overhead and/or OPUC/OPUk overhead. Including the indication of the CoS in the ODUC or ODUk overhead, as shown as an example in Figure 3, may ensure that the indication is easily available to network nodes, and so the OTUC/OTUk or ODUC/ODUk therein can be routed quickly and/or with a low processing requirement, and the indication is also easily transferred to the next OTUC/OTUk to contain the ODUC/ODUk.

Step 404 of the method 400 comprises transmitting the OTUk or OTUC over the OTN. This may be transmitted for example to a next hop router or switch or a destination node.

In some examples, transmitting the OTUk or OTUC over the OTN comprises selecting a first path from a plurality of paths in the OTN for the OTUk or OTUC based on the indication, and transmitting the OTUk or OTUC on the selected path. For example, the path may be selected based on the CoS. In one example, a node carrying out the method 400 may have a choice of paths on which to send the OTUC/OTUk and/or the ODUC/ODUk therein to its destination. Where the CoS suggests that the data therein has a low latency requirement, for example, a path with a lower delay, latency or cost may be chosen, whereas where the CoS suggests that the data therein has a higher latency requirement or tolerance, another path with a higher delay, latency or cost may be chosen. Each path may in some examples include at least some common sections or routers. Information regarding the available paths and their characteristics such as delay may be received in some examples from a network controller.

Figure 5 is an example of an optical transport network 500. The network includes a source node 502 (which may be a router or switch in some examples) and a destination node 504 (which may be a router or switch in some examples). A first path 506 and a second path 508 are available between the source 502 and the destination 504. The first path 506 and the second path 508 are different but may share one or more common nodes or links, or they may share no common nodes or links (apart from the destination 504). In some examples, the first path 506 and/or the second path 508 may comprise a direct link to the destination 504 (i.e. not via any other network nodes).

In some embodiments, the first path 506 or the second path 508 may be chosen based on the indication of the CoS in the OTUC/OTUk, and also based on one or more respective characteristics of each of the paths. For example, the characteristics may include one or more of delay, latency, cost, throughput, reliability and/or availability. In other embodiments, there may be more than two paths, and a path selected from the available paths based on the CoS and the characteristic(s).

In some examples, after the OTUC or OTUk has been transmitted on the selected path, subsequent OTUC/OTUks that have the same indication of CoS may be transmitted on the selected path. Thus, there may for example be no need to re-evaluate path characteristics to select a path for the subsequent OTUC/OTUks.

In some examples, the indication comprises a 5G Quality of Service Identifier (5QI). The 5QI may comprise for example the 5QI defined in 3GPP TS 23.501 , V16.0.2, which is incorporated herein by reference. Table 5.7.4-1 suggests 5QI values. In some examples, the indication indicates a delay budget for the data (e.g. maximum delay allowable or tolerated by the data). In some examples, the delay budget may correspond to the delay budget associated with the 5QI value.

In some examples, the OTUk or OTUC is associated with a flow, and the method comprises determining the indication from the flow associated with the OTUk or OTUC. This information may in some examples be retrieved from a Session Management Function (SMF).

Figure 6 is a flow chart of an example of a method 600 of routing an Optical Data Unit (ODUk or ODUC) in an Optical Transport Network (OTN). The method 600 may be implemented in some examples by a router or switch in the OTN, or in a network controller. The method 600 comprises, in step 602, selecting a path for the ODUk or ODUC from a plurality of paths based on an indication in overhead received with the ODUk or ODUC of a class of service (CoS) of data within the ODUk or ODUC. For example, as suggested above, a lower latency path may be selected for lower latency tolerant data, and a higher latency path may be selected for higher latency tolerant data, where the latency tolerance of the data may be determined from the indication of the CoS. The path may be selected based on for example a respective parameter such as respective delay and respective cost for each of the plurality of paths. The indication may be included in ODUC/ODUk overhead, and/or in other overhead received with the ODUc/ODUk, such as for example OTUC/OTUk overhead or OPU overhead.

The method 600 also comprises, in step 604, causing the ODUk or ODUC to be transmitted on the selected path. This may comprise for example transmitting the ODUk or ODUC on the selected path (e.g. in an OTUk or OTUC), or instructing a node such as a router, switch or source node to transmit the ODUC/ODUk on the selected path. In some examples, subsequent ODUC/ODUks may also be transmitted on the selected path if they have the same indication of CoS.

In some examples, the indication is in Optical Data Unit (ODUk or ODUC) overhead of the ODUk or ODUC, though in other embodiments the indication may be located additionally or alternatively elsewhere in the overhead. The indication may in some examples comprise a 5G Quality of Service Identifier (5QI) and/or indicates a delay budget for the data.

Figure 7 is a schematic of an example of apparatus 700 for transmitting an Optical Transport Unit (OTUk or OTUC) over an Optical Transport Network (OTN). The apparatus 700 comprises processing circuitry 702 (e.g. one or more processors) and a memory 704 in communication with the processing circuitry 702. The memory 704 contains instructions executable by the processing circuitry 702. The apparatus 700 also comprises an interface 706 in communication with the processing circuitry 702. Although the interface 706, processing circuitry 702 and memory 704 are shown connected in series, these may alternatively be interconnected in any other way, for example via a bus.

In one embodiment, the memory 704 contains instructions executable by the processing circuitry 702 such that the apparatus 700 is operable to provide, in overhead of in the OTUk or OTUC, an indication of a class of service of data within the OTUk or OTUC, and transmit the OTUk or OTUC over the OTN. In some examples, the memory 704 contains instructions executable by the processing circuitry 702 such that the apparatus 700 is operable to carry out the method 400 described above.

Figure 8 is a schematic of an example of apparatus 800 for routing an Optical Data Unit (ODUk or ODUC) in an Optical Transport Network (OTN). The apparatus 800 comprises processing circuitry 802 (e.g. one or more processors) and a memory 804 in communication with the processing circuitry 802. The memory 804 contains instructions executable by the processing circuitry 802. The apparatus 800 also comprises an interface 806 in communication with the processing circuitry 802. Although the interface 806, processing circuitry 802 and memory 804 are shown connected in series, these may alternatively be interconnected in any other way, for example via a bus.

In one embodiment, the memory 804 contains instructions executable by the processing circuitry 802 such that the apparatus 800 is operable to select a path for the ODUk or ODUC from a plurality of paths based on an indication in overhead received with the ODUk or ODUC of a class of service of data within the ODUk or ODUC, and cause the ODUk or ODUC to be transmitted on the selected path. In some examples, the memory 804 contains instructions executable by the processing circuitry 802 such that the apparatus 800 is operable to carry out the method 600 described above. In some examples described herein, the indication of class of service (CoS) of data is a 5G Quality of Service Indicator 5QI. The 5QI is a value that may be used in some examples as a reference to 5G QoS parameters that control QoS forwarding treatment for the QoS Flow (e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration). The table below provides an example of 5QI values, corresponding indication of CoS values, and example services that may produce data having that particular 5QI or indication of CoS value.

At least some embodiments disclosed herein may provide one or more of the following advantages. Providing the indication of CoS into overhead, such as for example ODUk/ODUC overhead may keep the processing time in a transmitting or routing or switching node low, for example in line with the low latency constraint of 5G network design. Therefore, for example, the node does not need to recover an indication of CoS from upper layers, which may result in demapping of the ODUk/ODUC at each decision point. Providing the indication of CoS into overhead, such as for example ODUk ODUC overhead, may allow nodes to switch and aggregate homogeneous traffic (e.g. traffic with the same indication of CoS) along the same path(s) that are suitable or preferential for traffic with a particular class of service. Providing the indication of CoS into overhead, such as for example ODUk/ODUC overhead may allow triggering of OTN protection and restoration schemes based on the class of service: for example, the most critical valuable traffic (as indicated by CoS), e.g. traffic with a CoS that indicates high reliability requirement, could be protected against a multiple fault of node and/or optical fiber, while other traffic may be not be protected or may be protected to a lesser extent, e.g. by having fewer alternative paths available. In some examples (e.g. where the indication of CoS is included in currently reserved bytes in overhead), nodes that are not aware of the indication of CoS (e.g. have not been programmed or upgraded to handle traffic based on the CoS) will not be impacted by the presence of the indication in the overhead.

Some clients (e.g. nodes or applications that send and/or receive communications) may communicate over an optical transport network (OTN) in a manner such that all communications may be classified with a Class of Service (CoS). Examples of communications that such clients may use include one or more of MMTC (Massive Machine Type Communication), URRLC (Ultra Reliable Low Latency Communication) and EMBB (Enhanced Mobile Broadband). Embodiments of this disclosure may use the indication of CoS in the overhead efficiently so as to manage the communications in an OTN. Furthermore, in some examples, this may also be done dynamically; in a network such as a 5G network for example, bandwidth required for each type of service may be time-varying, and hence an OTN may manage traffic dynamically based on the CoS. By including an indication of CoS in overhead of communications (e.g. in overhead of or with an ODUC, ODUk, OTUC or OTUk), nodes in an OTN may switch or route communications efficiently using the CoS, without needing to examine the underlying data (e.g. packets encapsulated in the communications). This may in some examples simplify an OTN implemented in accordance with embodiments disclosed in this document compared to an OTN in which the underlying data is examined to determine the CoS, for example. It should be noted that the above-mentioned examples illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative examples without departing from the scope of the appended statements. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim,“a” or“an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the statements below. Where the terms,“first”,“second” etc. are used they are to be understood merely as labels for the convenient identification of a particular feature. In particular, they are not to be interpreted as describing the first or the second feature of a plurality of such features (i.e. the first or second of such features to occur in time or space) unless explicitly stated otherwise. Steps in the methods disclosed herein may be carried out in any order unless expressly otherwise stated. Any reference signs in the statements shall not be construed so as to limit their scope.