PON Data Compression for High Efficiency

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This application claims priority to U.S. Provisional Application No. 62/594,835, filed Dec. 5, 2017, entitled “Compression Based PON Optimization,” the entire disclosure of which is incorporated by reference herein.

BACKGROUND

0002This specification relates to Passive Optical Network (PON) data compression to improve efficiency.

0003In a PON, user data consumption/utilization continues to increase. Network operators are looking for ways to increase the amount of data that they can send over their networks.

SUMMARY

0004In general, one innovative aspect of the subject matter described in this specification can be embodied in methods for improving PON efficiency by compressing data before transmitting on a PON. One example computer-implemented method includes determining, by a first telecommunications device, that one or more fields of a packet to be transmitted are compressible based on a compression table, the compression table established by the first telecommunications device and a second telecommunications device, the compression table including a plurality of compression entries on a per-flow and per-direction basis, one or more compressible fields of the packet determined based on a compression entry in the compression table, and prior to transmitting the packet to the second telecommunications device and in response to determining that the one or more fields are compressible: compressing, by the first telecommunications device, the one or more fields of the packet based on the compression table, including removing the one or more fields from the packet to generate a compressed packet, and modifying, by the first telecommunications device, one or more bits in a header of the compressed packet, the modified one or more bits in the header of the compressed packet indicating at least one compression entry in the compression table associated with the compression performed on the compressed packet.

0005Particular embodiments of the subject matter described in this specification can be implemented so as to realize one or more of the following advantages. For example, the methods, devices, and/or systems described in the present disclosure can compress highly correlated data for each service flow per subscriber, so that transmitters can convey predicted data strings using fewer bits of overhead data over a PON. In other words, there is room in the per-packet overhead to convey a modest number of compression indexes to compress (e.g., remove) correlated data. Examples of correlated data include MAC addresses, Ethertypes, VLAN tag stacks, IP addresses, and Ethernet pad bytes, which can be properly detected prior to transmission, and are typically limited in range among one service flow from an individual subscriber. In doing so, packet transmission length can be reduced by a significant amount (e.g., dozens of bytes per packet). As a result, efficiency of the PON can be improved using data compression.

0006While some aspects of this disclosure refer to computer-implemented software embodied on tangible media that processes and transforms data, some or all of the aspects may be computer-implemented methods or further included in respective systems or devices for performing the described functionality. The details of one or more embodiments of the subject matter described in this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.

DESCRIPTION OF DRAWINGS

0007<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram illustrating an example networking environment for PON data compression, according to implementations of the present disclosure.

0008<figref idref="DRAWINGS">FIG. 2</figref> is a diagram illustrating an example frame with an options field, according to implementations of the present disclosure.

0009<figref idref="DRAWINGS">FIG. 3</figref> is a diagram illustrating an example compression table, according to implementations of the present disclosure.

0010<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart of an example method for data compression in a PON, according to implementations of the present disclosure.

0011<figref idref="DRAWINGS">FIG. 5</figref> is a block diagram illustrating an example of a computer system used to provide computational functionalities associated with described algorithms, methods, functions, processes, flows, and procedures, according to implementations of the present disclosure.

0012Like reference numbers and designations in the various drawings indicate like elements.

DETAILED DESCRIPTION

0013This disclosure describes methods, systems, and apparatus for improving PON efficiency through the use of data compression. For example, a first telecommunications device (e.g., an Optical Line Terminal (OLT), or an Optical Network Unit (ONU)) can determine, in advance of transmitting a packet to a second telecommunications device, that one or more fields of the packet are compressible based on a compression table (e.g., one or more fields of the packet match a compression entry in the compression table). The compression table can be established by the first telecommunications device and the second telecommunications device prior to transmitting the packet. Prior to transmitting the packet to the second telecommunications device and in response to the determination, the first telecommunications device can compress the one or more fields of the packet based on the compression table (e.g., removing the one or more fields from the packet) to generate a compressed packet. In addition, the first telecommunications device can modify one or more bits in a header of the compressed packet to indicate at least one compression entry in the compression table associated with the compression performed on the compressed packet. Although this disclosure refers to passive optical telecommunications systems for purposes of example, the subject matter of this disclosure can be applied to other types of telecommunications systems or other systems that transmit highly correlated data for each service flow per subscriber.

0014A Passive Optical Network (PON), such as a Next-Generation Passive Optical Network 2 (NG-PON2) or a 10 Gbps Ethernet Passive Optical Network (10G-EPON), can provide a 10 Gbps data rate. As user data consumption/utilization continues to increase, demand for data rates may exceed the data rate of installed equipment. Network operators are looking for ways to improve PON efficiency, especially in the burst-mode upstream direction, so as to increase available link capacity.

0015In modern high-speed Internet service bundles, most packets to or from a subscriber feature numerous bytes that are constant for all packets within a service flow. For example, the MAC and IP addresses (e.g., subscriber's local gateway MAC and IP addresses, provider's broadband network gateway MAC and IP addresses), set of VLAN tags, and Ethertype are fields that occupy multiple bytes in a packet, but use only a few different values for those fields. Data that is already known to a receiver can be suppressed by a transmitter in order to preserve capacity of the communication channel.

0016To improve PON efficiency, an OLT and an ONU can be configured to optionally learn fields in a packet (typically within packet headers) that are common to a high percentage of packets within a service flow. For example, in an International Telecommunication Union (ITU) PON, an XGEM-ID (10-Gigabit-capable PON Encapsulation Method ID) can be used to identify a single service flow. In an Institute of Electrical and Electronics Engineers (IEEE) PON, LLID (Logical Link ID) can be used analogously. Over an in-band overhead channel (e.g., ONU management and control interface (OMCI) for ITU PON and Ethernet Operations Administration and Maintenance (OAM) for IEEE PON), a system can set up one or more compression entries in a compression table for each XGEM-ID/LLID (or less granular, for example for each subscriber or PON). A compression entry represents a string of bytes that is suitable for compression over a PON link. Once both sides (e.g., a transmitter and a receiver) have acknowledged existence of a compression entry, the transmitter (e.g., an OLT) can detect the presence of a string of characters, corresponding to the compression entry, at an anticipated location in a packet, remove the bytes corresponding to the string of characters from the packet, and use reserved encapsulation header bytes (e.g., Options byte in XGEM header, or one of the hexadecimal “55” bytes in Ethernet preamble of EPON packets) to indicate an identity of a compression action that is taken by the transmitter. Upon reception of the compressed packet, the receiver (e.g., an ONU) can determine which (if any) compression action was taken, and use its own table of compression indexes to re-insert the bytes that were removed by the transmitter.

0017At a high-level, the described approach provides a method to automatically perform compression on highly correlated data for each service flow per subscriber. Prior to transmitting a packet, a transmitter (at an OLT or at an ONU) can convey the predicted data strings using fewer bits of overhead data in the packet. Examples of correlated data include MAC addresses, Ethertypes, VLAN tag stacks, IP addresses, and Ethernet pad bytes, which can be properly detected prior to transmission, and are typically limited in range among one service flow (or a few) from an individual subscriber. For example, the predicted data strings can be removed from the packet, and one or more compression bits in the packet can be used to indicate the removal based on a compression table. A receiver (at an OLT or at an ONU) can re-insert the removed data strings based on the one or more compression bits and the compression table after receiving the compressed packet. In doing so, packet transmission length can be reduced by a significant amount (e.g., dozens of bytes per packet). The present disclosure discusses using, for example, header compression to 10-Gigabit-capable PON Encapsulation Method (XGEM) frames to avoid transmitting highly correlated header data, thereby reducing the amount of link capacity that is required to transmit the highly correlated header data and enabling that amount of link capacity to be used to transmit payload data (e.g., user data). As a result, PON efficiency can be improved using data compression. Any telecommunications system with highly correlated data for transmission may benefit from the subject matter described in this disclosure.

0018<figref idref="DRAWINGS">FIG. 1</figref> a block diagram illustrating an example networking environment <b>100</b> for PON data compression, according to implementations of the present disclosure. As illustrated in <figref idref="DRAWINGS">FIG. 1</figref>, the environment <b>100</b> includes a PON <b>102</b> that connects users to a network <b>104</b>. In some implementations, the environment <b>100</b> may include additional and/or different components not shown in the block diagram, such as one or more active optical networks (AONs), another type of network that provides network services (e.g., ADSL2+, VDSL2, etc.), or a combination of these and other technologies. In some implementations, components may also be omitted from the environment <b>100</b>.

0019As illustrated, the PON <b>102</b> includes an OLT <b>106</b> at a service provider's central office (or other distribution point), an Optical Distribution Network (ODN) <b>134</b> (e.g., a passive optical splitter for the PON <b>102</b>), an ONU <b>110</b> near residential locations <b>116</b>, an ONU <b>112</b> near business locations <b>118</b>, an ONU <b>114</b> near wireless communications equipment <b>120</b>, a fiber optic link <b>136</b> connecting the OLT <b>106</b> and the ODN <b>134</b>, a fiber optic link <b>122</b> connecting the ODN <b>134</b> and the ONU <b>110</b>, a fiber optic link <b>124</b> connecting the ODN <b>134</b> and the ONU <b>112</b>, and a fiber optic link <b>126</b> connecting the ODN <b>134</b> and the ONU <b>114</b>. The OLT <b>106</b> is coupled to a number of ONUs <b>110</b>, <b>112</b>, and <b>114</b> (also referred to as optical network terminals (ONTs)), which are located near end users, thereby forming a point-to-multipoint network. For example, in the case of Next-Generation Passive Optical Network 2 (NG-PON2), a single OLT port can connect to 64 (or another number of) different ONUs.

0020Each ONU can include, or otherwise be coupled to, one or more customer-premises equipment (CPE) or subscriber devices (e.g., CPE modems). For example, the ONU <b>110</b> is a device that terminates the PON <b>102</b> at the customer end, and provides a service connection to a user living in the residential locations <b>116</b>. The ONU <b>110</b> terminates optical fiber transmission, and can transform incoming optical signals into electrical signals, adapted for processing by subscriber devices. As a result, ONUs can provide network services, for example, to residential locations <b>116</b>, business locations <b>118</b>, or other forms of communications infrastructure, such as wireless communications equipment <b>120</b>.

0021The OLT <b>106</b>, as a network distribution element, provides an interface between the PON <b>102</b> and the network <b>104</b>, and serves as the service provider's endpoint of the PON <b>102</b>. The OLT <b>106</b> transmits downstream data traffic to ONUs (e.g., ONUs <b>110</b>, <b>112</b>, and <b>114</b>), and receives upstream data traffic from the ONUs.

0022As illustrated, the OLT <b>106</b> includes a compression engine <b>108</b> that can establish a compression table with another compression engine in a telecommunications device that the OLT <b>106</b> is communicating with. In some implementations, the OLT <b>106</b> is responsible for management of the compression table. For example, the compression engine <b>108</b> can establish a compression table with another different compression engine <b>128</b> in the ONU <b>110</b> for data compression between the OLT <b>106</b> and the ONU <b>110</b>. The compression engine <b>108</b> can establish a compression table with another different compression engine <b>130</b> in the ONU <b>112</b> for data compression between the OLT <b>106</b> and the ONU <b>112</b>. The compression engine <b>108</b> can establish a compression table with a compression engine <b>132</b> in the ONU <b>114</b> for data compression between the OLT <b>106</b> and the ONU <b>114</b>. In some implementations, the compression engine <b>108</b> can establish a single compression table for data compression with all coupled ONUs (e.g., <b>110</b>, <b>112</b>, and <b>114</b>). In some cases, the compression engine <b>108</b> can establish a particular compression table for each coupled ONU. Although illustrated as the compression engine <b>108</b> in the OLT <b>106</b> in <figref idref="DRAWINGS">FIG. 1</figref>, a physical device or a software simulator running on any virtual or hardware machine may be used according to particular needs, desires, or particular implementations of the environment <b>100</b>. Specifically, the compression engine <b>108</b> executes the algorithms and operations described in the illustrated figures, including the operations performing the functionality associated with the OLT <b>106</b> generally, as well as the various software modules, including the functionality for sending communications to and receiving transmissions from the ONUs (e.g., ONUs <b>110</b>, <b>112</b>, and <b>114</b>).

0023In addition, the compression engine <b>108</b> can perform data compression and un-compression in downstream and upstream directions between the OLT <b>106</b> and its attached ONUs (e.g., ONUs <b>110</b>, <b>112</b>, and <b>114</b>). For example, the compression engine <b>108</b> can perform data compression (e.g., header compression) prior to transmitting packets to the ONU <b>110</b> based on a compression table established between the OLT <b>106</b> and the ONU <b>110</b>. In some cases, the compression engine <b>108</b> can determine that one or more fields of a packet to be transmitted match a compression entry in the compression table. Prior to transmitting the packet and in response to the determination, the compression engine <b>108</b> can remove the one or more fields from the packet to generate a compressed packet, and modify one or more bits in a header of the compressed packet to indicate the removal. As a result, instead of transmitting the original packet, the compressed packet with a shorter packet length than the original packet is transmitted. The compression engine <b>108</b> can also perform data un-compression after receiving compressed packets from the ONU <b>110</b> based on the compression table established between the OLT <b>106</b> and the ONU <b>110</b>. For example, after receiving a compressed packet, the compression engine <b>108</b> can re-insert previously removed fields to the compressed packet based on compression bits in the header of the compressed packet and the compression table (e.g., obtaining the previously removed fields from the compression table).

0024For legacy ONUs (e.g., ONUs that do not support header compression), the OLT <b>106</b> will communicate with them without data compression and un-compression. Data compression and un-compression can be achieved independently in the upstream and downstream directions. In other words, compression entries in a compression table can be independent for upstream and downstream on bidirectional service flows.

0025Each ONU can include a compression engine. For example, the ONU <b>110</b> includes a compression engine <b>128</b>. The ONU <b>112</b> includes a compression engine <b>130</b>. The ONU <b>114</b> includes a compression engine <b>132</b>. As a result, each ONU (e.g., a compression-capable ONU) can perform data compression (e.g., header compression) prior to transmitting packets to the OLT <b>106</b> based on a compression table established between the OLT <b>106</b> and the particular ONU. In addition, each ONU (e.g., a compression-capable ONU) can perform data un-compression after receiving compressed packets from the OLT <b>106</b> based on the compression table established between the OLT <b>106</b> and the particular ONU. The disclosed subject matter does not require all OLTs and/or ONUs on a same PON to support header compression. Legacy OLTs and/or ONUs (e.g., OLTs and/or ONUs that do not support header compression) can use, for example, reserved encapsulation header bytes (e.g., as currently defined in compression tables), which can be interpreted by a compression-capable receiver as an uncompressed transmission.

0026The new elements related to the compression tables in the ONUs and OLTs need to be managed, for example, using existing in-band management channels. For ITU PONs, a compression table can be established between an ONU and an OLT via OMCI. For IEEE PONs, a compression table can be established between an ONU and an OLT via Ethernet OAM. Furthermore, the OMCI or OAM management system is capable of querying OLTs and ONUs to understand their capabilities to participate in data compression, including any limitations of the implementation (i.e. a limited number of supported entries per XGEM/LLID, a limited length of entries, or limitations to only compress/expand the layer-2 (L2) header).

0027In some implementations, the operations performed by a compression engine (e.g., <b>108</b>, <b>128</b>, <b>130</b>, or <b>132</b>) can be implemented as operations performed by a data processing apparatus, on data stored on one or more computer-readable storage devices or received from other sources. The term “data processing apparatus” encompasses all kinds of apparatus, devices, and machines for processing data, including, by way of example, a programmable processor, a computer, a system on a chip, or multiple ones, or combinations of the foregoing. The compression engine (e.g., <b>108</b>, <b>128</b>, <b>130</b>, or <b>132</b>) can also be implemented as special purpose logic circuitry, for example, a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC).

0028The network <b>104</b> facilitates wireless or wireline communications between the components of the PON <b>102</b> with any other local or remote computer, such as additional PONs, servers, or other devices communicably coupled to the network <b>104</b>, including those not illustrated in <figref idref="DRAWINGS">FIG. 1</figref>. As illustrated in <figref idref="DRAWINGS">FIG. 1</figref>, the network <b>104</b> is depicted as a single network, but may be comprised of more than one network without departing from the scope of this disclosure.

0029In some situations, one or more of the illustrated components may be implemented, for example, as one or more cloud-based services or operations. The network <b>104</b> may be all or a portion of an enterprise or secured network, or at least a portion of the network <b>104</b> may represent a connection to the Internet, a public switched telephone network (PSTN), a data server, a video server, or additional or different networks. In some implementations, a portion of the network <b>104</b> may be a virtual private network (VPN). Further, all or a portion of the network <b>104</b> can comprise either a wireline or wireless link. Example wireless links may include 802.11ac/ad/af/a/b/g/n, 802.20, WiMax, LTE, free-space optical links, and/or any other appropriate wireless link. In other words, the network <b>104</b> encompasses any internal or external network, networks, sub-network, or combination thereof, operable to facilitate communications between various computing components, inside and outside the environment <b>100</b>. The network <b>104</b> may communicate, for example, Internet Protocol (IP) packets, Frame Relay frames, Asynchronous Transfer Mode (ATM) cells, voice, video, data, and other suitable information between network addresses. The network <b>104</b> may also include one or more local area networks (LANs), radio access networks (RANs), metropolitan area networks (MANs), wide area networks (WANs), all or a portion of the Internet, and/or any other communication system or systems at one or more locations.

0030<figref idref="DRAWINGS">FIG. 2</figref> is a diagram illustrating an example frame <b>200</b> with an options field, according to implementations of the present disclosure. For purposes of example, the frame in <figref idref="DRAWINGS">FIG. 2</figref> is an XGEM frame <b>202</b>. The subject matter of this disclosure can be applied to fields in other types of frames.

0031As illustrated, the XGEM frame <b>202</b> includes an XGEM header <b>204</b> and XGEM payload <b>206</b>. According to G.989.3, Sec. 9.1.2, the XGEM header <b>204</b> can include Payload Length Indicator (PLI) <b>208</b>, Key index <b>210</b>, XGEM Port-ID <b>212</b>, Options <b>214</b>, Last Fragment (LF) <b>216</b>, and Header Error Control (HEC) <b>218</b>. The existing Options <b>214</b> in the XGEM header <b>204</b> can be used to optionally encode headers or header fields. In some implementations, the Options <b>214</b> has 18 bits, and is set to 0×00000 (all bits set to zero) by a transmitter and ignored by a receiver. The Options <b>214</b> can store an index to an entire header (of varied length). The Options <b>214</b> can store an index for each of several well-known fields, including MAC DA, MAC SA, VLAN Tag stack, Ethertype, IP SA, and IP DA.

0032As illustrated in <figref idref="DRAWINGS">FIG. 2</figref>, the Options <b>214</b> can be used to include a reserved field <b>220</b> and a compression instruction index field <b>222</b>. The compression instruction index field <b>222</b> can use bits 3:0 (from bits 17:0 in the Options field) as an index to a compression table. For example, an index of 0 (bits 3:0 with value of 0000) can indicate that the packet is not compressed. An index of 1 (bits 3:0 with value of 0001) can indicate that the packet is compressed according to the first compression entry in the compression table. As a result, bits 3:0 can index a total of 15 entries in the compression table. In some implementations, the Options <b>214</b> can be used differently to indicate one or more entries in one or more compression tables. For example, bits 1:0 can indicate which (of four) MAC destination address is compressed, bits 3:2 can indicate which (of four) MAC source address is compressed, bits 5:4 can indicate which (of four) Ethertype fields is compressed, and so on. In some implementations, the Options <b>214</b> can be used differently to indicate one or more entries in a compression table that is limited to a single instruction at a specified byte offset of the frame to be transmitted.

0033<figref idref="DRAWINGS">FIG. 3</figref> is a diagram illustrating an example compression table <b>300</b>, according to implementations of the present disclosure. As illustrated, the example compression table <b>300</b> includes three compression entries <b>302</b>, <b>312</b>, and <b>322</b>. The compression entry <b>302</b> can be indexed by compression bits with a value of 1 (e.g., the compression instruction index field <b>222</b> in <figref idref="DRAWINGS">FIG. 2</figref> with value of 0001). The compression entry <b>312</b> can be indexed by compression bits with a value of 2 (e.g., the compression instruction index field <b>222</b> in <figref idref="DRAWINGS">FIG. 2</figref> with value of 0010). The compression entry <b>322</b> can be indexed by compression bits with a value of 3 (e.g., the compression instruction index field <b>222</b> in <figref idref="DRAWINGS">FIG. 2</figref> with binary value of 0011).

0034As illustrated in <figref idref="DRAWINGS">FIG. 3</figref>, the compression entry <b>302</b> includes compression instruction <b>304</b>, compression instruction <b>306</b>, and end of instructions <b>308</b>. For a transmitter, if a packet to be transmitted has two fields that match both the compression instruction <b>304</b> and the compression instruction <b>306</b>, the transmitter can compress the packet according to the compression instruction <b>304</b> and the compression instruction <b>306</b>, and set the compression bits with a value of 1 in the compressed packet to index the compression entry <b>302</b>. For example, in a packet to be transmitted, if contents starting at the beginning of the packet (Offset: 0 bytes) with a length of 20 bytes match the hexadecimal string “00 A0 C8 11 22 33 00 A0 C8 44 55 66 81 00 60 64 08 00 45 00” and contents starting 30 bytes from the beginning of the packet (Offset: 30 bytes) with a length of 4 bytes match the hexadecimal string “C0 A8 01 01”, both contents can be compressed (e.g., removed from the packet) by the transmitter. For a receiver, if compression bits in a received packets have a value indicating the compression entry <b>302</b> (e.g., a value of 1), the receiver knows that the received packet is a compressed packet. The receiver can re-insert “00 A0 C8 11 22 33 00 A0 C8 44 55 66 81 00 60 64 08 00 45 00” to the beginning of the received packet, and then re-insert “C0 A8 01 01” at a location with an offset of 30 bytes.

0035As illustrated, the compression entry <b>312</b> includes compression instruction <b>314</b>, compression instruction <b>316</b>, and end of instructions <b>318</b>. Similar to the compression instruction <b>304</b> and the compression instruction <b>306</b> in the compression entry <b>302</b>, the compression instruction <b>314</b> and the compression instruction <b>316</b> can be used by a transmitter to remove contents from a packet to be transmitted and by a receiver to re-insert contents to a received compressed packet. The compression entry <b>322</b> includes end of instructions <b>324</b> only. In other words, the compression entry <b>322</b> indicates no data compression.

0036As discussed above, in a PON access network, headers within an XGEM/LLID tend to be highly correlated. For example at layer-2, an UNI-side MAC address typically belongs to a remote gateway (RG), a network-side MAC address typically belongs to a broadband network gateway (BNG), a VLAN tag stack is statically provisioned, an Ethertype is typically IPv4, IPv6, or Address Resolution Protocol (ARP). In addition at layer-3 (L3), IP addresses of the RG and the BNG are also correlated, as well as IP protocol, traffic class/type of service, and flow label (where applicable), as well as layer-4 (L4) port numbers. Although many values of these fields are possible within a network, typically only a limited number of values are used within an XGEM/LLID. As a result, the frequently used headers can be learned by a transmitter and a receiver, and stored in a compression table (e.g., “C0 A8 01 01” stored in the compression instruction <b>306</b>) for compressing data transmitted between the transmitter and the receiver. For example, known headers (e.g., stored in a compression table known to both the transmitter and the receiver) can be removed prior to transmission by the transmitter. XGEM header or Ethernet preamble can be used to identify the removed headers in the compression table. The known and removed headers can be re-inserted at the receiver.

0037In some implementations, the system can use OMCI messaging to define and manage known headers in a compression table. For example, an OLT can learn widely-used L2 headers on a per-XGEM, per-direction basis. The OLT can send to an ONU the identity of a new L2 header via OMCI. The identity includes byte string and length of the new L2 header. In some implementations, the identity includes individual L2 fields (e.g., MAC DA, MAC SA, VLAN tag stack, Ethertype) of the new L2 header. Once acknowledged by a transmitter and a receiver, the OLT (or ONU) transmitter can discard any matching header from a packet (e.g., header in a packet that matches one or more known headers) to be transmitted, and use the XGEM header Options field to indicate which known header should be attached at the receiver. Analogously to OMCI for ITU PONs, the same level of messaging and configuration may be achieved through OAM messaging for EPON.

0038In a residential PON, a large number of upstream packets are TCP Acks. Generally speaking, an untagged, unfragmented TCP Ack occupies 8 bytes of an XGEM header, 14 bytes of an Ethernet header, 20 bytes of an IP header for IPv4, 40 bytes of an IP header for IPv6, 20 bytes of a TCP header, 6 bytes of Ethernet pad for IPv4, 2 bytes of XGEM pad for IPv6, and 4 bytes of Ethernet FCS. As a result, an untagged, unfragmented TCP Ack occupies 72 bytes for IPv4 and 88 bytes for IPv6, including XGEM alignment overhead. By compressing the L2 overhead into existing XGEM header, only 60 bytes are occupied for IPv4 instead of 72 bytes, and only 72 bytes are occupied for IPv6 instead of 88 bytes. Using header compression of just the L2 header, the system can achieve 16.67% reduction and 18.18% reduction in transmitted packet size for IPv4 and IPv6, respectively. In addition, shorter packets can lead to fewer fragments, and hence less fragmentation overhead.

0039Note that the description above refers to L2 header compression, but there are many other compression options, and the techniques discussed above can be used (or modified) to allow for the use of other compression options. For example, IP source and destination addresses can be compressed. For IPv6, using a complex packet parser, 32 bytes can be reduced for each packet. Additional L3 and L4 header fields may also be considered, for example IP version, DiffServ, Flow Label, source port, and destination port. In addition, Ethernet pad for short frames can be compressed as well. For IPv4, frames with minimum length are padded. For IPv6, TCP frames with minimum length have no pad. In some implementations, L2 compression is similar to using IP as XGEM SDU instead of Ethernet. For example, “XGEM Type” field in XGEM Header Options can be used similar to “Ethertype” and IP can be passed through XGEM as a tunnel, and any additional compression could be considered for the remaining L3 and L4 header fields.

0040In some implementations, it is possible to achieve protocol-agnostic header compression by parsing packets prior to the transmitter to identify the highly correlated header fields (including L2, L3, L4, etc.), and creating a set of instruction strings for processing these fields. The instruction strings could either identify well-known header fields, or could generically identify byte offsets and lengths for headers to be removed (by transmitter) and reinserted (by receiver). Furthermore, the OMCI or OAM management system can be capable of querying OLTs and ONUs to understand their capabilities to participate in compression, including any limitations of the implementation (i.e. a limited number of supported entries per XGEM/LLID, a limited length of entries, or limitations to only compress/expand the L2 header).

0041<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart of an example method <b>400</b> for data compression in a PON, according to implementations of the present disclosure. The example method <b>400</b> can be performed, for example, by one or more telecommunications devices, such as those described with reference to <figref idref="DRAWINGS">FIG. 1</figref> (e.g., the OLT <b>106</b>, the ONU <b>110</b>, the ONU <b>112</b>, and the ONU <b>114</b>). The example method <b>400</b> can also be implemented as instructions stored on a non-transitory, computer-readable medium that, when executed by one or more telecommunications devices (and/or data processing apparatus), configures the one or more telecommunications devices to perform and/or cause the one or more telecommunications devices to perform the actions of the example method <b>400</b>.

0042A determination is made, by a first telecommunications device, that one or more fields of a packet to be transmitted are compressible based on a compression table (<b>405</b>). In some implementations, the compression table is established by the first telecommunications device and a second telecommunications device. The compression table can be stored locally in the first telecommunications device and the second telecommunications device, or remotely to the first telecommunications device and the second telecommunications device. In some implementations, the compression table can include multiple compression entries on a per-flow and per-direction basis. For example, one or more compressible fields of the packet can be determined based on a compression entry in the compression table. In some implementations, the first telecommunications device and the second telecommunications device can establish each compression entry in the compression table by learning one or more common fields of packets within a particular service flow.

0043In some implementations, the first telecommunications device is an ONU in a PON, and the second telecommunications device is an OLT in the PON. In some cases, the first telecommunications device is the OLT in the PON, and the second telecommunications device is the ONU in the PON. For an ITU PON, the compression table can be established through OMCI (ONU management and control interface). Each compression entry in the compression table can be associated with an XGEM-ID identifying a distinct service flow. For an IEEE PON, the compression table can be established through Ethernet Operations Administration and Maintenance (OAM). Each compression entry in the compression table can be associated with an LLID identifying a distinct service flow. The LLID can include all pertinent LLID types, such as a Physical Layer ID (PLID), a Management Link ID (MLID), and a User Link ID (ULID).

0044In some implementations, the packet is encapsulated within an XGEM frame that includes an XGEM header and XGEM payload. The one or more bits are located in options field of the XGEM header (e.g., Options <b>214</b> in <figref idref="DRAWINGS">FIG. 2</figref>). The compression table includes the multiple compression entries on a per-XGEM and per-direction basis. Each compression entry can include at least one of an offset, a length, and compression contents. A value of zero represented by compression indication bits in a particular XGEM frame indicates that the particular XGEM frame is uncompressed. A value of non-zero represented by the compression indication bits in the particular XGEM frame indicates that the particular XGEM frame is compressed.

0045Prior to transmitting the packet to the second telecommunications device and in response to determining that the one or more fields are compressible, the one or more fields of the packet are compressed by the first telecommunications device and based on the compression table (<b>410</b>). In some implementations, compressing the one or more fields of the packet can include removing the one or more fields from the packet to generate a compressed packet. For example, a 64-byte packet with a 10-byte compressible field is to be transmitted, after removing the 10-byte compressible field from the 64-byte packet, a 54-byte compressed packet is transmitted instead of the 64-byte packet.

0046One or more bits in a header of the compressed packet are modified by the first telecommunications device (<b>415</b>). In some implementations, the modified one or more bits in the header of the compressed packet indicate at least one compression entry in the compression table associated with the compression performed on the compressed packet.

0047The example method <b>400</b> shown in <figref idref="DRAWINGS">FIG. 4</figref> can be modified or reconfigured to include additional, fewer, or different actions (not shown in <figref idref="DRAWINGS">FIG. 4</figref>), which can be performed in the order shown or in a different order. For example, after <b>415</b>, the compressed packet is received by the second telecommunications device. Based on the modified one or more bits in the header of the received packet, the second telecommunications device knows that the received packet is compressed. The second telecommunications device can un-compress the received packet based on the modified one or more bits in the header of the compressed packet and a compression table. In some implementations, uncompressing the received compressed packet can include place contents into the received compressed packet at associated locations to generate an uncompressed packet. The contents and the associated locations can be obtained from the compression table based on the modified one or more bits in the header of the compressed packet. The uncompressed packet, instead of the received compressed packet, can be transmitted by the second telecommunications device to a third telecommunications device. The third telecommunications device is a destination of the packet. In some implementations, one or more of the actions shown in <figref idref="DRAWINGS">FIG. 4</figref> can be repeated or iterated, for example, until a terminating condition is reached. In some implementations, one or more of the individual actions shown in <figref idref="DRAWINGS">FIG. 4</figref> can be executed as multiple separate actions, or one or more subsets of the actions shown in <figref idref="DRAWINGS">FIG. 4</figref> can be combined and executed as a single action. In some implementations, one or more of the individual actions shown in <figref idref="DRAWINGS">FIG. 4</figref> may also be omitted from the example method <b>400</b>.

0048<figref idref="DRAWINGS">FIG. 5</figref> is a block diagram illustrating an example of a computer system <b>500</b> used to provide computational functionalities associated with described algorithms, methods, functions, processes, flows, and procedures, according to implementations of the present disclosure. The illustrated computer <b>502</b> is intended to encompass any computing device such as a server, desktop computer, laptop/notebook computer, wireless data port, smart phone, personal data assistant (PDA), tablet computing device, one or more processors within these devices, another computing device, or a combination of computing devices, including physical or virtual instances of the computing device, or a combination of physical or virtual instances of the computing device. Additionally, the computer <b>502</b> can comprise a computer that includes an input device, such as a keypad, keyboard, touch screen, another input device, or a combination of input devices that can accept user information, and an output device that conveys information associated with the operation of the computer <b>502</b>, including digital data, visual, audio, another type of information, or a combination of types of information, on a graphical-type user interface (UI) (or GUI) or other UI.

0049The computer <b>502</b> can serve in a role in a computer system as a client, network component, a server, a database or another persistency, another role, or a combination of roles for performing the subject matter described in the present disclosure. The illustrated computer <b>502</b> is communicably coupled with a network <b>530</b>. In some implementations, one or more components of the computer <b>502</b> can be configured to operate within an environment, including cloud-computing-based, local, global, another environment, or a combination of environments.

0050At a high level, the computer <b>502</b> is an electronic computing device operable to receive, transmit, process, store, or manage data and information associated with the described subject matter. According to some implementations, the computer <b>502</b> can also include or be communicably coupled with a server, including an application server, e-mail server, web server, caching server, streaming data server, another server, or a combination of servers.

0051The computer <b>502</b> can receive requests over network <b>530</b> (for example, from a client software application executing on another computer <b>502</b>) and respond to the received requests by processing the received requests using a software application or a combination of software applications. In addition, requests can also be sent to the computer <b>502</b> from internal users (for example, from a command console or by another internal access method), external or third-parties, or other entities, individuals, systems, or computers.

0052Each of the components of the computer <b>502</b> can communicate using a system bus <b>503</b>. In some implementations, any or all of the components of the computer <b>502</b>, including hardware, software, or a combination of hardware and software, can interface over the system bus <b>503</b> using an application programming interface (API) <b>512</b>, a service layer <b>513</b>, or a combination of the API <b>512</b> and service layer <b>513</b>. The API <b>512</b> can include specifications for routines, data structures, and object classes. The API <b>512</b> can be either computer-language independent or dependent and refer to a complete interface, a single function, or even a set of APIs. The service layer <b>513</b> provides software services to the computer <b>502</b> or other components (whether illustrated or not) that are communicably coupled to the computer <b>502</b>. The functionality of the computer <b>502</b> can be accessible for all service consumers using this service layer. Software services, such as those provided by the service layer <b>513</b>, provide reusable, defined functionalities through a defined interface. For example, the interface can be software written in JAVA, C++, another computing language, or a combination of computing languages providing data in extensible markup language (XML) format, another format, or a combination of formats. While illustrated as an integrated component of the computer <b>502</b>, alternative implementations can illustrate the API <b>512</b> or the service layer <b>513</b> as stand-alone components in relation to other components of the computer <b>502</b> or other components (whether illustrated or not) that are communicably coupled to the computer <b>502</b>. Moreover, any or all parts of the API <b>512</b> or the service layer <b>513</b> can be implemented as a child or a sub-module of another software module, enterprise application, or hardware module without departing from the scope of the present disclosure.

0053The computer <b>502</b> includes an interface <b>504</b>. Although illustrated as a single interface <b>504</b> in <figref idref="DRAWINGS">FIG. 5</figref>, two or more interfaces <b>504</b> can be used according to particular needs, desires, or particular implementations of the computer <b>502</b>. The interface <b>504</b> is used by the computer <b>502</b> for communicating with another computing system (whether illustrated or not) that is communicatively linked to the network <b>530</b> in a distributed environment. Generally, the interface <b>504</b> is operable to communicate with the network <b>530</b> and comprises logic encoded in software, hardware, or a combination of software and hardware. More specifically, the interface <b>504</b> can comprise software supporting one or more communication protocols associated with communications such that the network <b>530</b> or interface's hardware is operable to communicate physical signals within and outside of the illustrated computer <b>502</b>.

0054The computer <b>502</b> includes a processor <b>505</b>. Although illustrated as a single processor <b>505</b> in <figref idref="DRAWINGS">FIG. 5</figref>, two or more processors can be used according to particular needs, desires, or particular implementations of the computer <b>502</b>. Generally, the processor <b>505</b> executes instructions and manipulates data to perform the operations of the computer <b>502</b> and any algorithms, methods, functions, processes, flows, and procedures as described in the present disclosure.

0055The computer <b>502</b> also includes a database <b>506</b> that can hold data for the computer <b>502</b>, another component communicatively linked to the network <b>530</b> (whether illustrated or not), or a combination of the computer <b>502</b> and another component. For example, database <b>506</b> can be an in-memory, conventional, or another type of database storing data consistent with the present disclosure. In some implementations, database <b>506</b> can be a combination of two or more different database types (for example, a hybrid in-memory and conventional database) according to particular needs, desires, or particular implementations of the computer <b>502</b> and the described functionality. Although illustrated as a single database <b>506</b> in <figref idref="DRAWINGS">FIG. 5</figref>, two or more databases of similar or differing types can be used according to particular needs, desires, or particular implementations of the computer <b>502</b> and the described functionality. While database <b>506</b> is illustrated as an integral component of the computer <b>502</b>, in alternative implementations, database <b>506</b> can be external to the computer <b>502</b>. As illustrated, the database <b>506</b> holds the previously described compression table <b>520</b>.

0056The computer <b>502</b> also includes a memory <b>507</b> that can hold data for the computer <b>502</b>, another component or components communicatively linked to the network <b>530</b> (whether illustrated or not), or a combination of the computer <b>502</b> and another component. Memory <b>507</b> can store any data consistent with the present disclosure. In some implementations, memory <b>507</b> can be a combination of two or more different types of memory (for example, a combination of semiconductor and magnetic storage) according to particular needs, desires, or particular implementations of the computer <b>502</b> and the described functionality. Although illustrated as a single memory <b>507</b> in <figref idref="DRAWINGS">FIG. 5</figref>, two or more memories <b>507</b> or similar or differing types can be used according to particular needs, desires, or particular implementations of the computer <b>502</b> and the described functionality. While memory <b>507</b> is illustrated as an integral component of the computer <b>502</b>, in alternative implementations, memory <b>507</b> can be external to the computer <b>502</b>.

0057The application <b>508</b> is an algorithmic software engine providing functionality according to particular needs, desires, or particular implementations of the computer <b>502</b>, particularly with respect to functionality described in the present disclosure. For example, application <b>508</b> can serve as one or more components, modules, or applications. Further, although illustrated as a single application <b>508</b>, the application <b>508</b> can be implemented as multiple applications <b>508</b> on the computer <b>502</b>. In addition, although illustrated as integral to the computer <b>502</b>, in alternative implementations, the application <b>508</b> can be external to the computer <b>502</b>.

0058The computer <b>502</b> can also include a power supply <b>514</b>. The power supply <b>514</b> can include a rechargeable or non-rechargeable battery that can be configured to be either user- or non-user-replaceable. In some implementations, the power supply <b>514</b> can include power-conversion or management circuits (including recharging, standby, or another power management functionality). In some implementations, the power-supply <b>514</b> can include a power plug to allow the computer <b>502</b> to be plugged into a wall socket or another power source to, for example, power the computer <b>502</b> or recharge a rechargeable battery.

0059There can be any number of computers <b>502</b> associated with, or external to, a computer system containing computer <b>502</b>, each computer <b>502</b> communicating over network <b>530</b>. Further, the term “client,” “user,” or other appropriate terminology can be used interchangeably, as appropriate, without departing from the scope of the present disclosure. Moreover, the present disclosure contemplates that many users can use one computer <b>502</b>, or that one user can use multiple computers <b>502</b>.

0060While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any inventions or of what may be claimed, but rather as descriptions of features specific to particular embodiments of particular inventions. Certain features that are described in this specification, in the context of separate embodiments, can also be implemented in combination or in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments, separately, or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can, in some cases, be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

0061Thus, particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results.