WO2020001487A1 - 开销传输方法、装置、设备及计算机可读存储介质 - Google Patents

开销传输方法、装置、设备及计算机可读存储介质 Download PDF

Info

Publication number
WO2020001487A1
WO2020001487A1 PCT/CN2019/093071 CN2019093071W WO2020001487A1 WO 2020001487 A1 WO2020001487 A1 WO 2020001487A1 CN 2019093071 W CN2019093071 W CN 2019093071W WO 2020001487 A1 WO2020001487 A1 WO 2020001487A1
Authority
WO
WIPO (PCT)
Prior art keywords
overhead
frame
data
custom
data frame
Prior art date
Application number
PCT/CN2019/093071
Other languages
English (en)
French (fr)
Inventor
蒙万洲
李雯雯
Original Assignee
南京中兴软件有限责任公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 南京中兴软件有限责任公司 filed Critical 南京中兴软件有限责任公司
Publication of WO2020001487A1 publication Critical patent/WO2020001487A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/06—Notations for structuring of protocol data, e.g. abstract syntax notation one [ASN.1]

Definitions

  • This application relates to the field of communications.
  • OTN Optical Transport Network
  • Overhead processing plays an important role in OTN, such as Automatic Protection Switching / Protection Communication Channel , APS / PCC), General Communication Channel (GCC), etc.
  • GCC General Communication Channel
  • some reserved overhead can also be used to transmit custom information related to the device or user.
  • FPGA Field Programmable Gate Array
  • an overhead transmission method including: extracting overhead data and buffering the overhead data as an overhead frame, the overhead frame includes: a channel number, a line number, and overhead data; and the overhead is transmitted.
  • the frame is encapsulated as a custom overhead data frame; and serial transmission of overhead data is performed according to the type of the custom overhead data frame.
  • an overhead transmission device including: an extraction module configured to extract overhead data and cache the overhead data as an overhead frame, where the overhead frame includes: a channel number, a line number, and Overhead data; an encapsulation module configured to encapsulate the overhead frame into a custom overhead data frame; and a transmission module configured to perform serial transmission of overhead data according to the type of the custom overhead data frame.
  • an electronic device including a memory, a processor, and at least one application program stored in the memory and configured to be executed by the processor, when the application program is executed This causes the overhead transmission method described above to be performed.
  • a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the above-mentioned overhead transmission method is implemented.
  • FIG. 1 is a flowchart of an overhead transmission method according to an embodiment of the present disclosure
  • FIG. 2 is a schematic structural diagram of overhead data provided according to an embodiment of the present disclosure
  • FIG. 3 is a schematic structural diagram of a custom overhead data frame according to an embodiment of the present disclosure.
  • FIG. 5 is a flowchart of an overhead transmission method according to another embodiment of the present disclosure.
  • FIG. 6 is a schematic structural diagram of an overhead data frame provided according to an embodiment of the present disclosure.
  • FIG. 7 is an exemplary structural block diagram of an overhead transmission device according to an embodiment of the present disclosure.
  • FIG. 8 is an exemplary structural block diagram of an overhead transmission device according to another embodiment of the present disclosure.
  • FIG. 9 is a block diagram of an exemplary structure of the transmission module in FIG. 7.
  • an overhead transmission method includes steps S10-S30.
  • step S10 overhead data is extracted, and the overhead data is buffered as an overhead frame, where the overhead frame includes: a channel number, a line number, and overhead data.
  • step S20 the overhead frame is encapsulated into a custom overhead data frame.
  • step S30 serial transmission of overhead data is performed according to the type of the custom overhead data frame.
  • the overhead data is extracted from the overhead interface, and written into the cache in the order of the channel number, the line number, and the overhead data (overhead information), and waited for one frame of data to be transmitted to the encapsulation unit together.
  • FIG. 2 is a structure diagram of overhead data of each row.
  • FIG. 3 is a schematic structural diagram of a custom overhead data frame.
  • the frame header includes bytes such as a packet type field, a request channel number, and a request multiframe.
  • the packet type indicates the type of the overhead frame.
  • the payload part is the overhead to be transmitted.
  • the length of the overhead data can be set according to the requirements.
  • the custom overhead data frame may include, for example, the following fields: Pre & SFD, pkg_type, req_ch_id, reqmfas, oh valid, SA, Len / Type, 18 ⁇ 20 lines of overhead information, and FCS.
  • the method before step S20, the method further includes step S101.
  • step S101 an overhead request and a requested multiframe value are obtained.
  • a certain initial value may be used as the requested multiframe value MFAS, and then the requested multiframe value is sequentially superimposed.
  • the insert data packet (insert overhead data frame) is the overhead data that is sent to the initiator after processing by the feedback end. There is a delay from sending the overhead request to receiving the insert data packet. In order to continuously insert overhead into the service, some overhead data needs to be buffered. Need to design the cache pipeline and appropriate request interval control.
  • step S20 includes: obtaining a cache pipeline from the overhead frame; and packaging the overhead frame into a custom overhead data frame according to the overhead request and the cache pipeline.
  • the overhead frame type is determined according to the overhead request and the buffer pipeline (one frame of data information), the state machine jump is started, and a packet process is started; if the overhead request is received, the channel number and the multiframe value MFAS lock will be requested Save, and return a response signal.
  • the sending unit of the initiator sends the custom overhead frame to the feedback terminal; the feedback terminal receives the custom overhead data frame of the initiator and sends it to the de-framing unit, parses the overhead information in the custom overhead data frame, and outputs a valid channel number, Line number and overhead data.
  • the types of the custom overhead data frames include: a data frame, a request frame, and a data request frame.
  • FIG. 5 is a flowchart of an overhead transmission method according to another embodiment of the present disclosure, which may show a specific operation of step S30 in FIG. 1. As shown in FIG. 5, step S30 includes: steps S31-S33.
  • step S31 it is determined whether the type of the custom overhead data frame is a data frame. If yes, go to step S32; if no, go to step S33.
  • step S32 extraction is performed according to the line number to output the corresponding channel number, requested multiframe value, and overhead data.
  • step S33 the overhead request, the channel number, and the requested multiframe value are extracted and buffered, and a framing operation is performed according to the channel number and the requested multiframe value, and encapsulated into an overhead data frame for transmission.
  • the channel number can be used as the write address in the first line
  • MFAS can be stored in the random access memory (RAM)
  • the channel number is used as the read address in the subsequent lines 2, 3, and 4, for example. Read MFAS information from RAM.
  • step S33 may further include: extracting and caching the request indication, the request channel number, and the requested multiframe value, maintaining a state machine, and when the framing unit is idle and the cache is not empty, the overhead of the cache is Read the request information; select the overhead bytes to be inserted according to the requested channel number and the requested multiframe, and output the overhead to be inserted into the framing unit; when the overhead insertion request is valid, start the state machine to perform the framing operation, and set the overhead to be inserted according to A certain format is encapsulated as an insert overhead data frame.
  • the certain format is, for example, the format shown in FIG. 6.
  • FIG. 6 is a schematic structural diagram of an inserted overhead data frame according to an embodiment of the present disclosure.
  • the frame header part includes the frame length;
  • the payload part includes the requested channel number, the overhead bytes of the requested insertion, and the overhead enable.
  • the length of the insertion overhead can be set according to requirements.
  • the check byte is a 4-byte cyclic redundancy (CRC) check.
  • the inserted overhead data frame may include the following fields: ch_id, MFAS, GCC0, GCC1, GCC2, APS / PCC, INS_EN, DMT, RES, Pre & SFD, DA, SA, Len / Type, 16x10 frame overhead information, FCS .
  • the method may further include: the sending unit at the feedback end sends the customized insertion overhead frame to the initiator; the initiator receives the insertion overhead frame at the feedback end and sends it to the decapsulation unit; Decapsulate to obtain the overhead information, and simultaneously latch the channel number, and store them in the cache together.
  • the sending unit at the feedback end sends the customized insertion overhead frame to the initiator; the initiator receives the insertion overhead frame at the feedback end and sends it to the decapsulation unit; Decapsulate to obtain the overhead information, and simultaneously latch the channel number, and store them in the cache together.
  • the insert cache control unit After the buffering of one frame, read the overhead data and output it to the insert cache control unit; according to the latched channel number, insert the overhead cost to each channel.
  • the RAM corresponding to the overhead one frame overhead is stored.
  • the MFAS value is equal, the overhead data with the same channel number and the overhead insertion request channel number is output to the overhead insertion unit; the overhead to be inserted is loaded into the OTN
  • FIG. 7 is an exemplary structural block diagram of an overhead transmission apparatus according to an embodiment of the present disclosure.
  • an overhead transmission device includes: an extraction module 10, an encapsulation module 20, and a transmission module 30.
  • the extraction module 10 is configured to extract overhead data and cache the overhead data as an overhead frame, where the overhead frame includes: a channel number, a line number, and overhead data.
  • the encapsulation module 20 is configured to encapsulate the overhead frame into a custom overhead data frame.
  • the transmission module 30 is configured to perform serial transmission of overhead data according to the type of the custom overhead data frame.
  • the overhead data is extracted from the overhead interface, and written into the cache in the order of the channel number, line number, and overhead data, and waits for one frame of data to be transmitted to the encapsulation unit together.
  • Figure 2 shows the overhead data for each row. Schematic diagram of the structure.
  • FIG. 3 is a schematic structural diagram of a custom overhead data frame.
  • the frame header includes bytes such as a packet type field, a request channel number, and a request multiframe.
  • the packet type indicates the type of the overhead frame.
  • the payload part is the overhead to be transmitted.
  • the length of the overhead information can be set according to the requirements.
  • the overhead transmission device in addition to the extraction module 10, the encapsulation module 20, and the transmission module 30, the overhead transmission device further includes an insertion module 40.
  • the inserting module 40 is configured to obtain an overhead request and request a multiframe value.
  • the insert data packet is the overhead data that is sent to the initiator after being processed by the feedback end. There is a delay from sending the overhead request to receiving the insert data packet. In order to continuously insert the overhead into the service, some overhead data needs to be buffered. Need to design the cache pipeline and appropriate request interval control.
  • the encapsulation module 20 may be further configured to: obtain a cache pipeline from the overhead frame; and encapsulate the overhead frame into a custom overhead data frame according to the overhead request and the cache pipeline. .
  • the overhead frame type is determined according to the overhead request and the buffer pipeline (one frame of data information), the state machine jump is started, and a packet process is started; if the overhead request is received, the channel number and the multiframe value MFAS lock will be requested Save, and return a response signal.
  • the sending unit of the initiator sends the custom overhead frame to the feedback terminal; the feedback terminal receives the custom overhead data frame of the initiator and sends it to the de-framing unit, parses the overhead information in the custom overhead data frame, and outputs a valid channel number, Line number and overhead data.
  • the types of the custom overhead data frames include: a data frame, a request frame, and a data request frame.
  • FIG. 9 is a block diagram of an exemplary structure of the transmission module in FIG. 7. As shown in FIG. 9, the transmission module includes a determination unit 31, a first transmission unit 32, and a second transmission unit 33.
  • the determining unit 31 is configured to determine whether the type of the custom overhead data frame is a data frame.
  • the first transmission unit 32 is configured to: when the type of the custom overhead data frame is a data frame, perform extraction according to a line number to output a corresponding channel number, a requested multiframe value, and overhead data.
  • the second transmitting unit 33 is configured to: when the type of the custom overhead data frame is a request frame or a data request frame, extract and cache the overhead request, the channel number, and the requested multiframe value, and according to the The channel number and the requested multiframe value are used for framing operations, and are encapsulated into an overhead data frame for transmission.
  • the channel number can be used as the write address in the first line
  • MFAS can be stored in the random access memory (RAM)
  • the channel number is used as the read address in the subsequent lines 2, 3, and 4, for example. Read MFAS information from RAM.
  • the second transmission unit may be further configured to extract and cache the request indication, the request channel number, and the requested multiframe value, and maintain a state machine.
  • the second transmission unit Read out the buffered overhead request information; select the overhead bytes to be inserted according to the requested channel number and the requested multiframe, and output the overhead to be inserted to the framing unit; when the overhead insertion request is valid, start the state machine for framing operation and wait for the
  • the insertion overhead is encapsulated into an insertion overhead data frame according to, for example, the format shown in FIG. 6, where, as shown in FIG. 6, the frame header part includes the frame length.
  • the payload part includes the request channel number, the overhead bytes requested for insertion, and the overhead enable.
  • the length of the insertion overhead can be set according to requirements.
  • the check byte is a 4-byte CRC check.
  • the second transmission unit may be further configured as: the sending unit at the feedback end sends the custom insertion overhead frame to the initiator; the initiator receives the insertion overhead frame at the feedback end and sends it to the decapsulation unit; the insertion overhead
  • the frame is decapsulated to obtain the overhead information, and the channel number is latched and stored together in the cache.
  • the overhead data is read out and output to the insert cache control unit; the overhead is inserted into the cache according to the latched channel number.
  • One frame overhead is stored in the RAM corresponding to each overhead.
  • the overhead data with the same channel number and overhead insertion request channel number is output to the overhead insertion unit; the overhead to be inserted is loaded into the OTN frame.
  • the enable signal is configured by software.
  • An embodiment of the present disclosure further provides an electronic device.
  • the electronic device may include: a memory, a processor, and at least one application program stored in the memory and configured to be executed by the processor, when the application program is executed Causes the overhead transmission method according to the above embodiments to be executed.
  • An embodiment of the present disclosure provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the methods described in the foregoing embodiments are implemented.
  • overhead data can be extracted and cached as overhead frames.
  • the overhead frames include: channel number, line number, and overhead data. ; Encapsulate the overhead frame into a custom overhead data frame; perform serial transmission of overhead data according to the type of the custom overhead data frame.
  • identifiers such as channel numbers and line numbers before the overhead and sequentially buffering them, they are packaged into a custom package for serial transmission of OTN overhead, which realizes the insertion and extraction of overhead across FPGAs, with a simple structure, high portability, and great savings.
  • OTN device pins By adding identifiers such as channel numbers and line numbers before the overhead and sequentially buffering them, they are packaged into a custom package for serial transmission of OTN overhead, which realizes the insertion and extraction of overhead across FPGAs, with a simple structure, high portability, and great savings.
  • OTN device pins By adding identifiers such as channel numbers and line numbers before the overhead and sequentially buffering them, they are packaged into a custom package for serial transmission of OTN overhead, which realizes
  • the methods in the foregoing embodiments can be implemented by means of software plus a necessary universal hardware platform, and of course, can also be implemented by hardware.
  • the technical solution of the present disclosure that is essentially or contributes to the existing technology can be embodied in the form of a software product that is stored in a storage medium (such as ROM / RAM, magnetic disk, The optical disc) includes several instructions for causing a terminal device (which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to execute the methods of the embodiments of the present disclosure.
  • a terminal device which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

本文公开了一种开销传输方法、装置、设备及计算机可读存储介质。该方法包括：提取开销数据，并将所述开销数据缓存为开销帧，所述开销帧包括：通道号、行号和开销数据；将所述开销帧封装为自定义开销数据帧；以及根据所述自定义开销数据帧的类型进行开销数据的串行传输。

Description

开销传输方法、装置、设备及计算机可读存储介质 技术领域
本申请涉及通讯领域。
背景技术
在光传送网(OTN，Optical Transport Network)中，强大的网络维护管理功能通过开销来实现，开销处理在OTN中起重要的作用，例如自动保护倒换/保护通信通路(Automatic Protection Switching/Protection Communication Channel，APS/PCC)、通用通信通路(General Communication Channel，GCC)等；另外，一些保留开销还可以用来传输设备或用户相关的自定义信息。
随着OTN设备的速率和容量不断提升，对于大容量设备来说，现场可编程门阵列(Field Programmable Gate Array，FPGA)资源显得日益紧张。例如，在一些情况下，开销的处理相对独立，通常将开销处理单独在一片FPGA中实现；而如果并行传输开销信息，逻辑处理较复杂且占用较多硬件管脚。
发明内容
根据本文的一个方面，提供的一种开销传输方法，包括：提取开销数据，并将所述开销数据缓存为开销帧，所述开销帧包括：通道号、行号和开销数据；将所述开销帧封装为自定义开销数据帧；以及根据所述自定义开销数据帧的类型进行开销数据的串行传输。
根据本文的另一个方面，提供的一种开销传输装置，包括：提取模块，其设置为提取开销数据，并将所述开销数据缓存为开销帧，所述开销帧包括：通道号、行号和开销数据；封装模块，其设置为将所述开销帧封装为自定义开销数据帧；以及传输模块，其设置为根据所述自定义开销数据帧的类型进行开销数据的串行传输。
根据本文的又一个方面，提供的一种电子设备，包括存储器、处理器和被存储在所述存储器中并被配置为由所述处理器执行的至 少一个应用程序，当所述应用程序被执行时使得执行以上所述的开销传输方法。
根据本文的又一个方面，提供的一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现以上所述的开销传输方法。
附图说明
图1为根据本公开实施例提供的一种开销传输方法流程图；
图2为根据本公开实施例提供的开销数据的结构示意图；
图3为根据本公开实施例提供的自定义开销数据帧的结构示意图；
图4为根据本公开另一实施例提供的一种开销传输方法流程图；
图5为根据本公开另一实施例提供的一种开销传输方法流程图；
图6为根据本公开实施例提供的***开销数据帧的结构示意图；
图7为根据本公开实施例提供的一种开销传输装置示例性结构框图；
图8为根据本公开另一实施例提供的一种开销传输装置示例性结构框图；以及
图9为图7中传输模块的示例性结构框图。
本文目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
为了使本文所要解决的技术问题、技术方案及有益效果更加清楚、明白，以下结合附图和实施例，对本文进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本文，并不用于限定本文。
如图1所示，根据本公开实施例的一种开销传输方法包括：步骤S10-S30。
在步骤S10，提取开销数据，并将所述开销数据缓存为开销帧， 所述开销帧包括：通道号、行号和开销数据。
在步骤S20，将所述开销帧封装为自定义开销数据帧。
在步骤S30，根据所述自定义开销数据帧的类型进行开销数据的串行传输。
在本公开实施例中，通过在开销前增加通道号、行号等标识并按序缓存，封装成自定义包进行OTN开销的串行传输，实现了开销的跨FPGA的***和提取，结构简单，移植性高，极大地节省了OTN器件管脚。
在本公开实施例中，开销数据从开销接口中提取，按照通道号、行号和开销数据(开销信息)的顺序写入缓存，等待缓存够一帧数据后一起传送至封装单元。图2为每行开销数据的结构示意图。
在本公开实施例中，图3为自定义开销数据帧的结构示意图，帧头部分包括包类型字段、请求通道号、请求复帧等字节，其中包类型指示开销帧的类型，所述类型包括数据帧、请求帧和数据请求帧三种，净荷部分是待传输的开销，开销数据的长度可根据需求设定，最后是4字节的校验字节FCS。具体的，所述自定义开销数据帧可以包括例如以下字段：Pre&SFD、pkg_type、req ch_id、req mfas、oh valid、SA、Len/Type、18×20行开销信息和FCS。
如图4所示，在本公开实施例中，步骤S20之前还包括：步骤S101。
在步骤S101，获取开销请求和请求复帧值。
可以以某一初值作为请求复帧值MFAS，之后依次叠加请求复帧值。
***数据包(***开销数据帧)为反馈端处理后发送至发起端的开销数据，从发送开销请求到收到***数据包存在延时，为了连续将开销***业务，需要缓存部分开销数据。需设计缓存水线及合适的请求间隔控制。
在本公开实施例中，步骤S20包括：从所述开销帧中获取缓存水线；以及根据所述开销请求和所述缓存水线将所述开销帧封装为自定义开销数据帧。
具体地，根据开销请求和缓存水线(一帧数据信息)来决定开 销帧类型，开启状态机的跳转，开始一次封包过程；如果收到开销请求则将请求通道号和复帧值MFAS锁存，同时返回一个应答信号。发起端的发送单元将自定义开销帧发送到反馈端；反馈端接收到发起端的自定义开销数据帧，送到解帧单元，将自定义开销数据帧中开销信息解析出来，输出有效的通道号、行号和开销数据。
在本公开实施例中，自定义开销数据帧的类型包括：数据帧、请求帧、数据请求帧。
图5为根据本公开另一实施例提供的一种开销传输方法流程图，其可以示出图1中的步骤S30的具体操作。如图5所示，步骤S30包括：步骤S31-S33。
在步骤S31，判断所述自定义开销数据帧的类型是否为数据帧。若是，则进入步骤S32；若否，则进入步骤S33。
在步骤S32，根据行号进行提取，以输出对应的通道号、请求复帧值和开销数据。
在步骤S33，将所述开销请求、通道号和请求复帧值提取出并缓存，并根据所述通道号和请求复帧值进行成帧操作，封装为***开销数据帧进行传输。
在本公开实施例中，由于开销是按行传输的，因此只有第一行能提取到复帧值MFAS。在这种情况下，可以在第1行时把通道号当做写地址，将MFAS存储到随机存取存储器(RAM)中，在后续的例如2、3、4行把通道号当作读地址，从RAM中读取MFAS信息。
在本公开实施例中，步骤S33还可以包括：将请求指示、请求通道号和请求复帧值提取出并缓存，维护一个状态机，在成帧单元空闲且缓存非空时，将缓存的开销请求信息读出；根据请求通道号和请求复帧选择待***的开销字节，将待***开销输出到成帧单元；开销***请求有效时开始启动状态机进行成帧操作，将待***开销按照一定格式封装为***开销数据帧。所述一定格式例如图6中示出的格式。
图6为根据本公开实施例提供的***开销数据帧的结构示意图。如图6所示，帧头部分包含帧长度；净荷部分包括请求通道号、请求***的开销字节和开销使能等。***开销的长度可根据需求设定。校 验字节是4字节的循环冗余(CRC)校验。具体的，所述***开销数据帧可以包括以下字段：ch_id、MFAS、GCC0、GCC1、GCC2、APS/PCC、INS_EN、DMT、RES、Pre&SFD、DA、SA、Len/Type、16x10帧开销信息、FCS。
在本公开实施例中，步骤S33之后还可以包括：反馈端的发送单元将自定义***开销帧发送到发起端；发起端接收到反馈端的***开销帧，送到解封装单元；对***开销帧进行解封装，得到开销信息，同时锁存通道号，一起存入缓存，待缓存一帧后，将开销数据读出，输出到***缓存控制单元；根据锁存的通道号将***开销缓存至各路开销对应的RAM中，存够一帧开销，待MFAS值相等后，将通道号与开销***请求通道号一致的开销数据输出给开销***单元；将待***开销装入OTN帧。根据开销***使能决定是否***，使能信号由软件配置。
图7为根据本公开实施例提供的一种开销传输装置示例性结构框图。如图7所示，一种开销传输装置包括：提取模块10、封装模块20和传输模块30。
所述提取模块10设置为提取开销数据，并将所述开销数据缓存为开销帧，所述开销帧包括：通道号、行号和开销数据。
所述封装模块20设置为将所述开销帧封装为自定义开销数据帧。
所述传输模块30设置为根据所述自定义开销数据帧的类型进行开销数据的串行传输。
在本公开实施例中，通过在开销前增加通道号、行号等标识并按序缓存，封装成自定义包进行OTN开销的串行传输，实现了开销的跨FPGA的***和提取，结构简单，移植性高，极大地节省了OTN器件管脚。
在本公开实施例中，开销数据从开销接口中提取，按照通道号、行号和开销数据的顺序写入缓存，等待缓存够一帧数据后一起传送至封装单元，图2为每行开销数据的结构示意图。
在本公开实施例中，图3为自定义开销数据帧的结构示意图，帧头部分包括包类型字段、请求通道号、请求复帧等字节，其中包类 型指示开销帧的类型，所述类型包括数据帧、请求帧和数据请求帧三种，净荷部分是待传输的开销，开销信息的长度可根据需求设定，最后是4字节的校验字节FCS。
如图8所示，在本公开实施例中，除了提取模块10、封装模块20和传输模块30外，开销传输装置还包括：***模块40。
所述***模块40设置为获取开销请求和请求复帧值。
***数据包为反馈端处理后发送至发起端的开销数据，从发送开销请求到收到***数据包存在延时，为了连续将开销***业务，需要缓存部分开销数据。需设计缓存水线及合适的请求间隔控制。
在本公开实施例中，封装模块20还可以设置为：从所述开销帧中获取缓存水线；以及根据所述开销请求和所述缓存水线将所述开销帧封装为自定义开销数据帧。
具体地，根据开销请求和缓存水线(一帧数据信息)来决定开销帧类型，开启状态机的跳转，开始一次封包过程；如果收到开销请求则将请求通道号和复帧值MFAS锁存，同时返回一个应答信号。发起端的发送单元将自定义开销帧发送到反馈端；反馈端接收到发起端的自定义开销数据帧，送到解帧单元，将自定义开销数据帧中开销信息解析出来，输出有效的通道号、行号和开销数据。
在本公开实施例中，自定义开销数据帧的类型包括：数据帧、请求帧、数据请求帧。
图9为图7中传输模块的示例性结构框图。如图9所示，传输模块包括：判断单元31、第一传输单元32和第二传输单元33。
所述判断单元31设置为判断所述自定义开销数据帧的类型是否为数据帧。
所述第一传输单元32设置为当所述自定义开销数据帧的类型为数据帧时，则根据行号进行提取，以输出对应的通道号、请求复帧值和开销数据。
所述第二传输单元33设置为当所述自定义开销数据帧的类型为请求帧或数据请求帧时，将所述开销请求、通道号和请求复帧值提取出并缓存，并根据所述通道号和请求复帧值进行成帧操作，封装为插 入开销数据帧进行传输。
在本公开实施例中，由于开销是按行传输的，因此只有第一行能提取到复帧值MFAS。在这种情况下，可以在第1行时把通道号当做写地址，将MFAS存储到随机存取存储器(RAM)中，在后续的例如2、3、4行把通道号当作读地址，从RAM中读取MFAS信息。
在本公开实施例中，第二传输单元还可以设置为：将请求指示、请求通道号和请求复帧值提取出并缓存，维护一个状态机，在成帧单元空闲且缓存非空时，将缓存的开销请求信息读出；根据请求通道号和请求复帧选择待***的开销字节，将待***开销输出到成帧单元；开销***请求有效时开始启动状态机进行成帧操作，将待***开销按照例如图6格式封装为***开销数据帧，其中，如图6所示，帧头部分包含帧长度。净荷部分包括请求通道号、请求***的开销字节、和开销使能等。***开销的长度可根据需求设定。校验字节是4字节的CRC校验。
在本公开实施例中，第二传输单元还可以设置为：反馈端的发送单元将自定义***开销帧发送到发起端；发起端接收到反馈端的***开销帧，送到解封装单元；对***开销帧进行解封装，得到开销信息，同时锁存通道号，一起存入缓存，待缓存一帧后，将开销数据读出，输出到***缓存控制单元；根据锁存的通道号将***开销缓存至各路开销对应的RAM中，存够一帧开销，待MFAS值相等后，将通道号与开销***请求通道号一致的开销数据输出给开销***单元；将待***开销装入OTN帧。根据开销***使能决定是否***，使能信号由软件配置。
本公开实施例还提供一种电子设备，所述电子设备可以包括：存储器、处理器和被存储在存储器中并被配置为由处理器执行的至少一个应用程序，当所述应用程序被执行时使得执行根据以上各实施例所述的开销传输方法。
本公开实施例提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现以上各实施例所述的方法。
需要说明的是，所述装置、设备和计算机可读存储介质实施例 与以上各方法实施例属于同一构思，因此其具体实现过程可以参见方法实施例，且方法实施例中的技术特征在装置实施例中均适用，这里不再赘述。
在根据本公开实施例的开销传输方法、装置、设备及计算机可读存储介质中，可以提取开销数据，并将所述开销数据缓存为开销帧，开销帧包括：通道号、行号和开销数据；将开销帧封装为自定义开销数据帧；根据自定义开销数据帧的类型进行开销数据的串行传输。通过在开销前增加通道号行号等标识并按序缓存，封装成自定义包进行OTN开销的串行传输，实现了开销的跨FPGA的***和提取，结构简单，移植性高，极大地节省了OTN器件管脚。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件来实现。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机、计算机、服务器、空调器或者网络设备等)执行本公开各个实施例的方法。
以上参照附图说明了本公开的示例性实施例，并非因此局限本公开的权利范围。本领域技术人员不脱离本公开的范围和实质内所作的任何修改、等同替换和改进，均应在本公开的权利范围之内。

Claims (10)

  1. 一种开销传输方法，包括：
    提取开销数据，并将所述开销数据缓存为开销帧，所述开销帧包括：通道号、行号和开销数据；
    将所述开销帧封装为自定义开销数据帧；以及
    根据所述自定义开销数据帧的类型进行开销数据的串行传输。
  2. 根据权利要求1所述的一种开销传输方法，其中，所述将所述开销帧封装为自定义开销数据帧之前还包括：
    获取开销请求和请求复帧值。
  3. 根据权利要求2所述的一种开销传输方法，其中，所述将所述开销帧封装为自定义开销数据帧包括：
    从所述开销帧中获取缓存水线；以及
    根据所述开销请求和所述缓存水线将所述开销帧封装为自定义开销数据帧。
  4. 根据权利要求3所述的一种开销传输方法，其中，所述自定义开销数据帧的类型包括：数据帧、请求帧、数据请求帧，所述根据所述自定义开销数据帧的类型进行开销数据的串行传输包括：
    判断所述自定义开销数据帧的类型是否为数据帧，
    若所述自定义开销数据帧的类型是数据帧，则根据行号进行提取，以输出对应的通道号、请求复帧值和开销数据；
    若所述自定义开销数据帧的类型不是数据帧，则将所述开销请求、通道号和请求复帧值提取出并缓存，并根据所述通道号和请求复帧值进行成帧操作，封装为***开销数据帧进行传输。
  5. 一种开销传输装置，包括：
    提取模块，其设置为提取开销数据，并将所述开销数据缓存为 开销帧，所述开销帧包括：通道号、行号和开销数据；
    封装模块，其设置为将所述开销帧封装为自定义开销数据帧；以及
    传输模块，其设置为根据所述自定义开销数据帧的类型进行开销数据的串行传输。
  6. 根据权利要求5所述的一种开销传输装置，还包括：
    ***模块，其设置为获取开销请求和请求复帧值。
  7. 根据权利要求6所述的一种开销传输装置，其中，所述封装模块还设置为：
    从所述开销帧中获取缓存水线；以及
    根据所述开销请求和所述缓存水线将所述开销帧封装为自定义开销数据帧。
  8. 根据权利要求7所述的一种开销传输装置，其中，所述自定义开销数据帧的类型包括：数据帧、请求帧、数据请求帧，所述传输模块包括：
    判断单元，其设置为判断所述自定义开销数据帧的类型是否为数据帧；
    第一传输单元，其设置为当所述自定义开销数据帧的类型为数据帧时，根据行号进行提取，以输出对应的通道号、请求复帧值和开销数据；
    第二传输单元，其设置为当所述自定义开销数据帧的类型为请求帧或数据请求帧时，将所述开销请求、通道号和请求复帧值提取出并缓存，并根据所述通道号和请求复帧值进行成帧操作，封装为***开销数据帧进行传输。
  9. 一种电子设备，包括存储器、处理器和被存储在所述存储器中并被配置为由所述处理器执行的至少一个应用程序，其中，当所述 应用程序被执行时使得执行权利要求1-4中任一项所述的开销传输方法。
  10. 一种计算机可读存储介质，其中，其上存储有计算机程序，该程序被处理器执行时实现如权利要求1-4中任一所述的开销传输方法。
PCT/CN2019/093071 2018-06-28 2019-06-26 开销传输方法、装置、设备及计算机可读存储介质 WO2020001487A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810686869.4 2018-06-28
CN201810686869.4A CN110661745B (zh) 2018-06-28 2018-06-28 一种开销传输方法、装置、设备及计算机可读存储介质

Publications (1)

Publication Number Publication Date
WO2020001487A1 true WO2020001487A1 (zh) 2020-01-02

Family

ID=68984745

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/093071 WO2020001487A1 (zh) 2018-06-28 2019-06-26 开销传输方法、装置、设备及计算机可读存储介质

Country Status (2)

Country Link
CN (1) CN110661745B (zh)
WO (1) WO2020001487A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116582412A (zh) * 2023-07-06 2023-08-11 北京晟芯网络科技有限公司 Otn跨芯片发送、接收开销及请求的方法、装置和介质

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114051023B (zh) * 2021-11-11 2023-05-23 烽火通信科技股份有限公司 光业务单元帧开销处理方法、装置、设备及可读存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1571415A (zh) * 2003-07-17 2005-01-26 华为技术有限公司 一种封装数据流的方法
CN1812316A (zh) * 2005-01-25 2006-08-02 华为技术有限公司 一种链路汇聚处理方法和装置
CN101656588A (zh) * 2009-09-21 2010-02-24 中兴通讯股份有限公司 一种传输数据的方法及***
CN101944952A (zh) * 2010-09-26 2011-01-12 中兴通讯股份有限公司 一种实现光传送网开销处理的装置及方法
US8149868B2 (en) * 2007-03-14 2012-04-03 Hitachi, Ltd. Interface board and optical transmission equipment

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7512150B2 (en) * 2003-03-24 2009-03-31 Applied Micro Circuits Corporation 10 GbE LAN signal mapping to OTU2 signal
CN100589365C (zh) * 2007-09-14 2010-02-10 中兴通讯股份有限公司 一种光传输网中光净荷单元的时隙划分与开销处理的方法
CN101668003B (zh) * 2008-09-05 2013-09-11 华为技术有限公司 数据帧传输方法、设备及***
CN101631335B (zh) * 2009-08-19 2011-12-28 中兴通讯股份有限公司 一种将开销***光通道数据单元帧的方法及装置
CN103561360B (zh) * 2013-10-24 2016-08-24 烽火通信科技股份有限公司 串行处理光传送网开销的装置及方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1571415A (zh) * 2003-07-17 2005-01-26 华为技术有限公司 一种封装数据流的方法
CN1812316A (zh) * 2005-01-25 2006-08-02 华为技术有限公司 一种链路汇聚处理方法和装置
US8149868B2 (en) * 2007-03-14 2012-04-03 Hitachi, Ltd. Interface board and optical transmission equipment
CN101656588A (zh) * 2009-09-21 2010-02-24 中兴通讯股份有限公司 一种传输数据的方法及***
CN101944952A (zh) * 2010-09-26 2011-01-12 中兴通讯股份有限公司 一种实现光传送网开销处理的装置及方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116582412A (zh) * 2023-07-06 2023-08-11 北京晟芯网络科技有限公司 Otn跨芯片发送、接收开销及请求的方法、装置和介质
CN116582412B (zh) * 2023-07-06 2023-11-24 北京晟芯网络科技有限公司 Otn跨芯片发送、接收开销及请求的方法、装置和介质

Also Published As

Publication number Publication date
CN110661745B (zh) 2022-07-08
CN110661745A (zh) 2020-01-07

Similar Documents

Publication Publication Date Title
CN111010253B (zh) 一种基于hinoc协议的himac拆帧***、方法
US20090248918A1 (en) Method and system for a usb ethertype to tunnel usb over ethernet
WO2017088557A1 (zh) 数据报文发送接收的处理方法及装置
US20160065460A1 (en) Packet processing method and apparatus
CN102104548B (zh) 一种数据包接收处理方法和装置
WO2020001487A1 (zh) 开销传输方法、装置、设备及计算机可读存储介质
CN108521343B (zh) 一种oam报文的处理方法及装置
US9503309B2 (en) Ethernet communication system and method based on MMC/SD interface
CN111245550B (zh) Sdh信号处理方法、装置及***
US9270734B2 (en) Download method and system based on management data input/output interface
CN114422617B (zh) 一种报文处理方法、***及计算机可读存储介质
CN110071839B (zh) 支持数字信号处理器的corba通信装置
WO2010025628A1 (zh) 一种物理层数据传输的方法、装置及***
EP4210247A1 (en) Method for obtaining message header information and generating message, device, and storage medium
US20120041998A1 (en) Network Interface for Accelerating XML Processing
CN113890680A (zh) 一种应用于光纤通道航电网络dds的传输方法
CN107078837A (zh) 一种协议帧传输方法、装置、节点设备以及***
CN110012367B (zh) 用于gpon olt的omci组帧装置及组帧方法
CN111342929A (zh) 信息发送和接收方法及其装置、信息处理***
CN116996478A (zh) 隧道封装表资源管理方法、dpu及相关设备
CN111181682A (zh) 一种基于fpga的gfp帧分片传输的实现方法
CN114567614B (zh) 基于fpga实现arp协议处理的方法及装置
WO2024139265A1 (zh) 信息传输的方法、电子设备和计算机可读存储介质
WO2023231428A1 (zh) IPv4报文的封装方法、电子设备和计算机存储介质
CN116055418B (zh) 以太网数据的发送方法、装置、电子设备和存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19826029

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 18.02.2021.)

122 Ep: pct application non-entry in european phase

Ref document number: 19826029

Country of ref document: EP

Kind code of ref document: A1