Patent Description:
In Optical Transport Network (OTN), there is momentum regarding flex modulation and flex line rates. There are different ways to achieve a flex rate. For example, some vendors have created proprietary Optical channel Data Unit Group (ODUG) Super High Order (SHO) wrappers to handle cases of <NUM>, <NUM>, <NUM>, etc. for modem technologies. In ITU-T, there have been discussions about defining OTUCn, a byte interleaved scheme for flexibility in increments of <NUM>. OTUCn stands for Optical channel Transport Unit Cn where C means <NUM> and n is a multiplier of <NUM>, e.g. OTUC2 is <NUM> GB/s, OTUC4 is <NUM> GB/s, etc. The current ITU-T OTUCn standards are planning on defining a modular (not necessarily flexible) architecture for <NUM> slices and granularity. The problem is that this architecture does not give enough granularity on next-Gen devices for bandwidth versus performance/reach tradeoffs. It also does not cover some modulation rates (e.g., <NUM>-Quadrature Amplitude Modulation (8QAM) at <NUM>) that are not aligned to <NUM> boundaries. Other initiatives have proposals to turn off single or groups of physical, virtual, or logical lanes in a Physical Medium Dependent (PMD) layer to achieve a desired rate. There are some significant implementation and logic complexities when designing a protocol to support multiple different rates at the physical layer.

This flexible line rate is becoming a hot topic in the industry and recent activities by end users include a desire for sub-<NUM> granularity (<NUM> or <NUM>). Again, some conventional schemes address flexibility by turning off physical or virtual lanes, but complexity and logic cost is significant. Resizing using lanes scheme is also a challenge. The <NUM>/<NUM> granularity does not line up well to existing <NUM> traffic. Also, scaling conventional techniques for mux/mapping rates of <NUM> up to <NUM> requires large logic complexity.

As optical transmission systems start approaching the Shannon limit for non-linear noise and demand for increased data rates continues, Digital Signal Processing (DSP)/modem engines can get implemented in parallel devices or multiple engines get integrated to create super-channels with optical or electrical mixing. Low complexity and flexible schemes are needed for inverse multiplexing ("muxing") and distributing signals across these different channels at the physical layer. To minimize line-side penalties, an equal and symmetrical bandwidth split is required across the multiple engines, and there is high complexity involved to support flexible rate bandwidth splitting. For example, to split <NUM> across two devices would be 2x170G channels, <NUM> across three devices would be 3x310G channels, etc..

There are different conventional techniques developed to handle the breakup and inverse muxing of signals across multiple channels. For example, IEEE has defined Link Aggregation Groups (LAG) and ITU has been using Virtual Concatenation (VCAT) type of schemes of standard defined containers Low Order (LO)/High Order (HO) Optical channel Transport Unit-k (OTUk). LAG is a higher layer protocol utilizing smaller-sized channels to carry a super-channel. The protocol is implemented at Layer <NUM> (Ethernet) and adds huge complexity and memory requirements. It is typically implemented using a Network Processing Unit (NPU) and other types of devices; LAG is not an appropriate approach to be integrated into optical DSP/modem devices. Standard ITU-defined VCAT schemes include grouping smaller sized standard containers, which would be Optical channel Data Unit-<NUM> (ODU2) to get <NUM> granularity on the line side. There is a large logic complexity to map a signal (i.e. <NUM>) to nxODU2 (i.e. <NUM>) and then switch and distribute these ODU2 signals across multiple optical DSP/modem devices. The extra mapping complexity can add to wander and decrease network performance. <CIT> and <CIT> relate to the field of optical transport networks, and in particular, to a method and an apparatus for transmitting and receiving a client signal in an optical transport network. <NPL>] recommends a frame structure and rate adaptation scheme for the multiplexing of ODUk and ODUflex clients into an OTUCN carrier. <CIT> relates to a low speed rate traffic signal transmission.

A method according to claim <NUM> is provided.

A system comprising a plurality of adaptation circuits as defined in claim <NUM> is provided.

The following acronyms are utilized herein:.

In various exemplary embodiments, OTN line adaptation systems and methods are described. In an exemplary embodiment, an OTUCn line adaptation layer for a proprietary line side (SV-IaDI) splits or segments the OTUCn into <NUM> tributary slots (i.e., 10x per OTUC1), and only transmits on the line side the allocated tributary slots and OTUCn overhead. The process removes extra unused capacity of a standard OTUCn <NUM> container. This adapts a standard OTUCn frame (or any HO or SHO OTN signal), but utilizes the tributary slot structure within an OPUCn payload to get to <NUM> granularity. LO ODUk (k=<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, flex) can get mapped into OTUCn tributary slots with <NUM> granularity and these will be adapted on the line. On the receive side of the line, the m x <NUM> signal is reconstituted and put back into an OTUCn standard frame format. Ethernet clients can be sub-rate groomed, then mapped to an appropriately sized ODUflex, and then mapped to m x <NUM> tributary slots in the OTUCn structure. At the receive side of the line, the ODUflex signal is recovered from the equivalent set of allocated tributary slots.

In another exemplary embodiment, an OTUCn cell adaptation layer for a proprietary line side (SV-IaDI) creates fixed-sized cells from multiple traffic streams. These cells are switched using scheduling algorithms across a cell switch which is distributed outside or inside multiple DSP/modem devices or engines. The switch distributes cells to the multiple DSP/modem devices or engines, which achieves flexible bandwidth split. Cells having taken different paths are deskewed and aligned on the receiver to recreate the original signal. The cells contain unique IDs for switching and path selection within the modem/DSP device scope (and the line adaptation). This provides a process for addressing the complexities of providing flexible bandwidth across multiple modem/DSP devices.

Advantageously, the OTN line adaptation systems and methods align to the ITU-T OTUCn structure and models, but extends the protocol (OTN frame format) to achieve flexible rates at small increments below <NUM>. This allows adaptation of a fixed rate interface to a flexible rate line interface. ITU standards are not planning on defining SV-IaDI adaptation for OTUCn. Note, SV-IaDI is an adaptation between standard client interfaces at OTUCn and optical modems. This allows flex line and bandwidth splits among multiple devices/wavelengths. Additionally, the OTN line adaptation systems and methods result in a small logic implementation in comparison to other muxing schemes. Also, the mapping into cells can be protocol agnostic, and does not have to be limited to <NUM> granularity. This approach provides flexibility of cells (or packets) to switch and assign different paths to the desired Time Division Multiplexing (TDM) (OTUCn) traffic.

The OTN line adaptation systems and methods use OTUCn as SHO (or HO OTUk) to avoid proprietary schemes and align with future <NUM> OTN standardization. The OTN line adaptation systems and methods prevent unnecessary mapping/demapping stages by carrying OTUCn OH + payload into cells and only sending used (allocated) tributary slots in <NUM> increments (or any other increments). The OTN line adaptation systems and methods carry tributary slots independently whether the traffic source includes a single Cn, groups of Cn (e.g., C5) in single chip or groups of Cn across multi-chips. In this manner, the OTN line adaptation systems and methods disassociate modem rate to OTUC1 and tributary slot structure.

Referring to <FIG>, in an exemplary embodiment, an atomic function diagram illustrates an adaptation process <NUM>. The adaptation process <NUM> is based on the ITU-T standard OTUCn frame structures and tributary slots. Note, because the adaptation process <NUM> operates between a client <NUM> and a line <NUM>, the adaptation of OTUCn for SV-IaDI is not subject to standardization. That is, the adaptation process <NUM> is used for a vendor's line-side transmission. The adaptation process <NUM> is illustrated from the top, at a client_CI <NUM>, down to a Line_CI <NUM>. The adaptation process <NUM> takes in an OTUCn frame (OTUCn/CI <NUM>), breaks-up the <NUM>-byte overhead (per multi-frame OMFI) and <NUM> tributary payload into <NUM> x <NUM> streams (Cn10G/OTUCn, cell adaptation <NUM>). The individual <NUM> x <NUM> streams are SARed (create cells/packets), with associated identifiers (IDs) for the streams. The OPUCn MSI OH contains the allocation and structure of the <NUM> tributary slots and can distinguish which slots are filled with data and which are empty. The cell adaptation <NUM> also includes OTUCn BIP compensation, a cell ID for each cell, and timing information.

Subsequent to the cell adaptation <NUM>, line adaptation <NUM> is performed on the line TX side. On the line TX side, a scheduler can be used and configured to service and interleave only the cell streams that are filled with data (as reflected by the OPUCn MSI). The cell adaptation <NUM> provides Cn10G (n x <NUM> cells) (n ≥ <NUM>), and the line adaptation <NUM> provides m10Gcells (not necessarily carrying a multiple of <NUM>). The OTUCn/ODUCn/OPUCn OH is distributed across cell streams based on the OMFI. This results in removing unused capacity in the OTUCn structure by only transmitting the used <NUM> streams. This also results in <NUM> granularity on the line side, but still utilizing the OAM, section and functions of the SHO OTUCn. In the line adaptation <NUM>, since cell streams are interleaved, the OTUCn frame FAS cannot be used for alignment. A special cell can be used for alignment, with fixed occurrence in order to prevent the need for a PCS layer. After the line adaptation <NUM>, SD-FEC <NUM> can be added and the line_CI <NUM> can be provided to a modem.

In the opposite direction after transmission on the line RX side, cells are received and reassembled for the used streams and tributary slots. The cell ID is used to distinguish the different streams. A standard OTUCn frame is recreated and empty streams (which have been omitted on the line) are filled in and set as unallocated in the OTUCn frame (MSI). The overall adaptation process <NUM> includes receiving a standard OTUCn in, performing the adaptation process <NUM> from the client_CI <NUM> to the line_CI <NUM>, transmission (between two modems), performing the adaptation process <NUM> from the line_CI <NUM> to the client_CI <NUM>, and providing the OTUCn as the output.

Referring to <FIG>, in an exemplary embodiment, flow diagrams illustrate an adaptation processes 10A, 10B. The adaptation processes 10A, 10B are similar to the adaptation process <NUM>, but are described to illustrate disassociation of the client_CI <NUM> from the line_CI <NUM>. On the line TX side, cells are switched (via cell switch) using IDs to redirect a path to an appropriate optical modem/DSP device. Again, the granularity of this switching cell flow can be <NUM>; although other rates are possible. Client rates, interfaces and OTUCn frame format is disassociated to the actual line rate and engine instance. A scheduler is used in the line adaptation <NUM> and modem/DSP device to service the different cell flows destined for its line. On the line RX side, cells received then switched (via cell switch) back to desired OTUCn processing logic and group. Suppose the layer that OTUCn is adapted to is called Cn10G and the layer below (not carrying a multiple of <NUM>) is called m10Gcell. The number of client interfaces is disassociated from the number of line interfaces. For example, <FIG> illustrates the adaptation process 10A where a single client, client_CI <NUM>, gets split among two different line interfaces, line_CI 14A, 14B. <FIG> illustrates the adaptation process 10A where two clients, client_CI 12A, 12B, are provided to a same line interface, line_CI <NUM>.

Referring to <FIG>, in an exemplary embodiment, a diagram illustrates the front-end adaptation with the adaptation process <NUM>. <FIG> illustrates an example of converting an OTUCn to a modem bus. The OTUCn includes OPUCn payload <NUM>, OPUCn OH <NUM>, ODUCn payload <NUM>, ODUCn OH <NUM>, OTUCn payload <NUM>, and OTUCn OH <NUM>. The OPUCn payload <NUM> is split into <NUM> tributary flows or TSs and each of the <NUM> tributary payloads is mapped to one of the 10x flows per OTUC1, based on OMFI. Note, <FIG> illustrates four OMFIs, but there may be <NUM> in this exemplary embodiment for <NUM> tributary slots. The OPUCn OH <NUM>, ODUCn OH <NUM>, and the OTUCn OH <NUM> is split amongst the 10x tributary flows based on OMFI.

As described herein, there can be N flows of cells, where N ≥ <NUM>, and each of the N flows represents an allocated tributary slot in the OTN signal, where the sub-rate equals the overall OTN signal rate divided by N. In this example, N = <NUM> and the OTUCn = <NUM>, so each flow is <NUM>. In the cell adaptation <NUM>, before the cell switch, OTUCn frames (OTUCn/ODUCn/OPUCn OH + tributary payload) are converted into 10x tributary flows and cells. Where N = <NUM>, no allocated payload, only overhead is provided from the OTN signal, i.e. the systems and methods contemplate a sub-rate signal where there is no payload, only overhead.

Referring to <FIG>, in an exemplary embodiment, cell adaptation is illustrated with unallocated tributary slots. In this example, tributary slots are occupied for OMFI = <NUM>, <NUM>, but unallocated for OMFI = <NUM>, <NUM>. Note, the OTN OH is still sent when there are unallocated tributary slots. A framer is needed to hunt for OTN FAS in cell stream (after reassembly), and no alignment of cells is needed. The framer looks for the normal frame position, or back to back OH cells if unused tributary.

Referring to <FIG>, in an exemplary embodiment, a block diagram illustrates the cell adaptation <NUM> for different flows. Here, the TS from multiple frames of OTUCn <NUM> are adapted into the cells via a cell adaptation function <NUM> (SAR). The cell adaptation function <NUM> can be implemented in circuitry with various queues or buffers. The cell adaptation function <NUM> connects to a cell switch <NUM> which is configured to provide the cells to the line adaptation <NUM>.

Referring to <FIG>, in an exemplary embodiment, a block diagram illustrates the line adaptation <NUM> and a scheduler <NUM>. The line adaptation <NUM> includes circuitry after the cell switch <NUM>, and the line adaptation <NUM> is configured to combine cells from all used and allocated flows using the scheduler <NUM>. The scheduler <NUM> can utilize round-robin, a calendar, or the like. OH circuitry <NUM> and framing circuitry <NUM> also connects to the scheduler <NUM>. Subsequent to the scheduler <NUM>, scrambling circuitry <NUM> is configured to scramble the data.

Referring to <FIG>, in an exemplary embodiment, a block diagram illustrates two <NUM> adaptation circuits <NUM>. The <NUM> adaptation circuits <NUM> perform the adaptation processes described herein and physically reside between client interface and optical modem. Note, for illustration purposes, two of the <NUM> adaptation circuits <NUM> are illustrated to show scheduling between the <NUM> adaptation circuits <NUM>. The <NUM> adaptation circuits <NUM> include OTU4/ODU4/OTUC1/ODUflex framers <NUM> which is communicatively coupled to the client. The framers <NUM> are configured to operate at a client rate - OTU4/ODU4/OTUC1/ODUflex. The framers <NUM> are communicatively coupled to ODTUC1. j PT=0x22 multiplexers <NUM> (payload type = 0x22).

The multiplexers <NUM> are configured to interface at tributary slots with the framers <NUM>. The multiplexers <NUM> are communicatively coupled to OTUC1 framers <NUM> which are configured to interface the tributary slots. Subsequent to the OTUC1 framers <NUM>, the cell adaptation function <NUM> (SAR) is configured to interface to the OTUC1s from the framers <NUM> with the 10x tributary slots therein. The cell adaptation function <NUM> (SAR) connection to the cell switch <NUM> which is communicatively coupled to the scheduler <NUM> and a scheduler <NUM> for cells between the <NUM> adaptation circuits <NUM>. Finally, the scheduler <NUM> is configured to interface to a modem for optical transmission of the cells.

Referring to <FIG>, in an exemplary embodiment, a flow chart illustrates a process <NUM> for Optical Transport Network (OTN) line side adaptation to provide sub-rate granularity and distribution. The process <NUM> includes segmenting an OTN signal into N flows of cells with associated identifiers, based on tributary slots of the OTN signal, wherein N ≥ <NUM>, and wherein the cells do not include unallocated payload from the OTN signal (step <NUM>). The process <NUM> also includes switching the cells to a scheduler (step <NUM>). Finally, the process <NUM> includes scheduling, from the scheduler, the cells for a line side modem (step <NUM>). Note, the steps <NUM>, <NUM> can include switching the cells, with a scheduler, to one or more line side modems. The OTN signal can be one of a) from a client and the N flows of cells from the client are sent to different line side modems and b) from two or more clients and the N flows of cells from the two or more clients are sent to a same line side modem.

The segmenting can be determined based on the OMFI and MSI associated with the OTN signal, and N is based on a number of allocated tributary slots in the OTN signal. When N = <NUM>, only overhead is provided in the cells to the line side modem. The OTN signal is an Optical channel Transport Unit (C=<NUM>) x n (n=<NUM>, <NUM>, <NUM>,. ) (OTUCn) or a High Order or Super High Order OTN signal with tributary slots. The signal provided to the line side modem is a sub-rate of the OTUCn or the High Order or Super High Order OTN signal with tributary slots or a full-rate of the same signal. The scheduling can utilize round robin or a calendar. The method can further include inserting a framing cell to enable recovery from the line side modem. The scheduling can include scheduling some of the cells to a second line side modem.

In the various exemplary embodiments described herein, reference has been made to OTUCn for illustration purposes. Those of ordinary skill in the art will recognize the systems and methods can also be used on High Order (HO) OTN signals with corresponding tributary slots. For example, a HO OTU4 has <NUM> TSs of <NUM> each, and the systems and methods described herein can enable transmission of less than the <NUM> TSs, i.e. a sub-rate, to provide a composite signal of less than <NUM> to the line side modem when there are unallocated TSs. The systems and methods also contemplate operations with any Super High Order (SHO) OTN signal that may be developed. For example, OTUCn has been described herein where C = <NUM> and n = <NUM>, <NUM>, <NUM>. , and there may be other variants of this such as OTULn where L = <NUM> and n = <NUM>, <NUM>, <NUM>,. for increments of <NUM> (whereas the OTUCn has increments of <NUM>). Any such embodiments are contemplated herein.

It will be appreciated that some exemplary embodiments described herein may include one or more generic or specialized processors ("one or more processors") such as microprocessors, digital signal processors, customized processors, and field programmable gate arrays (FPGAs) and unique stored program instructions (including both software and firmware) that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the methods and/or systems described herein. Alternatively, some or all functions may be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the aforementioned approaches may be used. Moreover, some exemplary embodiments may be implemented as a non-transitory computer-readable storage medium having computer readable code stored thereon for programming a computer, server, appliance, device, etc. each of which may include a processor to perform methods as described and claimed herein. Examples of such computer-readable storage mediums include, but are not limited to, a hard disk, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory), Flash memory, and the like. When stored in the non-transitory computer readable medium, software can include instructions executable by a processor that, in response to such execution, cause a processor or any other circuitry to perform a set of operations, steps, methods, processes, algorithms, etc..

Claim 1:
A method, performed by an adaptation circuit (<NUM>), comprising the steps of receiving a plurality of signals each from a corresponding optical modem of a plurality of optical modems responsive to an Optical Transport Network, OTN, signal being broken up for transmission as the plurality of signals, wherein each of the plurality of signals was received by the corresponding optical modem connected to a corresponding line (<NUM>), wherein the OTN signal was broken up for transmission by one of a) a same client (<NUM>) sent to different optical modems of the plurality of optical modems, and b) two or more clients (<NUM>) sent to the plurality of optical modems;
reassembling the plurality of signals into the OTN signal where each of the plurality of signals is an Optical channel Transport Unit C1, OTUC1, (<NUM>) and the OTN signal is an OTUCn, n > <NUM>, and wherein the plurality of signals take different paths and the reassembling includes deskewing and aligning to recreate the OTN signal.