DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Election/Restriction
The restriction requirement has been withdrawn in light of the amendments to the claims and Applicant’s arguments.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Election/Restriction
The election/restriction based on unity of invention has been withdrawn in light of the amendments to the claims.
Claim Rejections - 35 USC § 112 - Indefinite
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 11 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 11 recites:
10. (Original) The method according to claim 9, wherein that sending, through the FlexE slot, the basic unit set comprises: sending, through the FlexE slot, the basic unit set to which the idle information block is inserted.
The underlined language is confusing and it is not clear what is being claimed. Clarification is required.
Claim Rejections - 35 USC § 103 - Obvious
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1, 3, 4, 8, 12-15, 18, 19, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2021/0076111 (Shew) in view of US 2017/0005901 (GAREAU).
Regarding claim 1, Shew teaches a data transmission method, applied to a sending end, comprising:
determining a basic unit carrying a client service (FIG. 3: Data to Wireless Mapper 50 and/or PDCP mapper 70), wherein the basic unit is a basic unit comprised in a basic unit set;
mapping the client service to the basic unit (FIG. 3: Data to Wireless Mapper 50 and/or PDCP mapper 70 and/or mapper 78); and
sending, through a flexible Ethernet (FlexE) slot, the basic unit set to a receiving end (FIG. 3: data sent from left side and received on the right side).
FIG. 3 is reproduced for reference.
PNG
media_image1.png
532
744
media_image1.png
Greyscale
Determining a Basic Unit.
Regarding “determining a basic unit”, see the present application at PG Pub:
[0071] In S110, determining a basic unit may be understood as determining the format of the basic unit and determining the label of the basic unit, that is, the sequence number of the basic unit. Different basic units may have different formats. For example, in the case where a basic unit is a cell, the format of the basic unit may be 66-bit code blocks or bytes. The format of a basic unit is not limited here. After the format of a basic unit is determined, the sequence number of the basic unit is determined in the present application. Each basic unit in the basic unit set is labeled with a sequence number. In S110, the sequence number of the basic unit carrying the client data is determined.
In other words, determining a basic unit is determining the format and label of the basic unit. Shew teaches to determine the format and sequence number. See, for example:
[0033] The mapper 50 can be referred to as a “data lane to wireless data plane mapper” to perform adaptation between the wired domain 52 and the wireless domain 54. In the present disclosure, there are three proposed approaches for how a wireless system can transport the 64 B/66 B block streams. These include transport by bits, by bytes, or by encapsulation in IP packets; these are referred to herein as bit mapping, byte mapping, and packet mapping, respectively. 64 B/66 B streams are taken off the data lane streams 64 and are handed off to some part of the wireless data plane by the mapper 50. Depending on where they are handed off, i.e., the approach, different type of mapping/encapsulations are required. The description in [0024] uses the bit mapping.
[0034] For packet mapping, the mapper 50 provides the 64 B/66 B data stream to the PDCP mapper 70 via IP encapsulation. The mapper 50 can pack a 64 B/66 B block stream into IP packets or the like, i.e., something that can be transported over the wireless stack. IP encapsulation can include sequence numbers in the packets to ensure the 64 B/66 B block stream can be reconstituted in the correct order at the receiver, i.e., at an adjacent mapper 50 on the other end of the wireless domain 54.
[0047] The stream of data can include a stream of blocks sized based on a line encoding technique. The mapping can include packet mapping where the stream of blocks is encapsulated into packets each having a sequence number to ensure correct ordering at a receiver, and wherein the packets are provided to the wireless data plane at a Packet Data Convergence Protocol (PDCP) layer in the wireless data plane.
[0049] In a further embodiment, a system includes a mapper configured to receive data lane streams each including a stream of blocks associated with one of a Flexible Ethernet (FlexE) signal or a Metro Transport Networking (MTN) signal, and map the stream of blocks to data formatted for transmission over one or more wireless links by a transmit device in a wireless data plane; and a demapper configured to receive the formatted data from a receive device in the wireless data plane, and demap the received data to the stream of blocks reconstituting the one of the FlexE signal or the MTN signal.
In other words, Shew teaches to determine a basic unit. Furthermore, these teachings in Shew are related to providing the communication services of the system, so that they are within the scope of “client services”.
Basic Unit Set.
The application teaches that the basic unit set includes at least one basic unit. See:
[0079] In one embodiment, the basic unit set includes at least one basic unit and is used for carrying the client data of at least one terminal device.
Therefore, the teaching of the use of a basic unit in Shew includes a basic unit set.
Mapping
Shew at FIG. 3 illustrates the use of a mapper to map data. Shew also teaches to map the blocks for transmission. See:
[0005] In another embodiment, a system includes a mapper configured to receive data streams each including a stream of blocks associated with one of a Flexible Ethernet (FlexE) signal or a Metro Transport Networking (MTN) signal, and map the stream of blocks to data formatted for transmission over one or more wireless links by a transmit device in a wireless data plane; and a demapper configured to receive the formatted data from a receive device in the wireless data plane, and demap the received data to the stream of blocks reconstituting the one of the FlexE signal and the MTN signal. The data formatted can include packet mapping where the stream of blocks is encapsulated into packets each having a sequence number to ensure correct ordering at the demapper, and the packets can include provided to the wireless data plane at a Packet Data Convergence Protocol (PDCP) layer in the wireless data plane. The data formatted can include byte mapping where the stream of blocks is converted into a byte stream that is provided to a Radio Link Control (RLC) layer in the wireless data plane that guarantees byte delivery in order at the demapper. The data formatted can include bit mapping wherein the stream of blocks is transferred as a stream of bits to a transport buffer Service Access Point (SAP) in the wireless data plane. The stream of data can include a stream of 64 B/66 B blocks, and wherein the data streams are each about 5 Gb/s corresponding to one of 20 calendar slots in a 100 Gb/s FlexE frame. The data streams can be a plurality of streams and each is transported over a different wireless link. The system can further include a transmit buffer between the mapper and the wireless data plane; and a receive buffer between the demapper and the wireless data plane.
See also the Wireless Mapper 50 and/or PDCP mapper 70 in FIG. 3. See also the discussion of the PDCP mapper 70:
[0032] The PDCP mapper 70 encapsulates data into an IP packet (among other functions) that are wireless domain datagrams. The RLC layer 72 provides buffering of bytes to match an incoming data stream with the wireless channel and reliable transmission of bytes over the wireless channel (layer 2 functionalities). The transport buffer 74 function performs i) layer 1 wireless functionality and hybrid Automatic Repeat Request (ARQ) to deal with fading channels, ii) creation of buffers of coded bits created in a size that can be mapped on available spectrum and time resources (Orthogonal Frequency-Division Multiplexing (OFDM) symbols), iii) coding such as Low-Density Parity-Check (LDPC), polar, Turbo Product Code (TPC) (some bits may be removed from the coded buffer to create punctured codes), and iv) the like. The modulation device 76 includes creating symbols (time waveforms) from coded bits. The spectrum resource mapper 78 may work with modulation to assign bits to wireless spectrum or in time (on OFDMA symbols or resource blocks).
See also the teachings and discussion of Shew above under “Determining a Basic Unit”. In other words, Shew teaches mapping.
Sending Through Flex-E.
Gareau teaches that FlexE slots was a known implementation in communications systems. See, for example:
[0056] The FlexE operates using a calendar which assigns 66b block positions on each PHY 22 of the FlexE group 12 to each of the FlexE clients 14. The calendar has a granularity of 5G and has a length of 20 slots per 100G of FlexE group 12 capacity. Two calendars are supported: an “A” and a “B” calendar. At any given time, one of the calendars is used for mapping the FlexE clients 14 into the FlexE group 12 and demapping the FlexE clients 14 from the FlexE group 12. The two calendars are provided to facilitate reconfiguration.
See also FIG. 11:
PNG
media_image2.png
439
1029
media_image2.png
Greyscale
In addition, Shew teaches the use of FlexE for the transmission of client data. See, for example:
[0001] The present disclosure generally relates to networking. More particularly, the present disclosure relates to systems and methods for Flexible Ethernet (FlexE) over wireless links.
[0002] Flexible Ethernet (FlexE) is a link multiplexing technology initially specified in the Optical Internetworking Forum's Flexible Ethernet Implementation Agreement (document OIF-FLEXE-01.0, March 2016, OIF-FLEXE-01.1, June 2017, and OIF-FLEXE-02.0, June 2018, the contents of each is incorporated by reference herein). The Implementation Agreement (IA) enables one or more 100GBASE-R PHYs to be bonded, with clients of 10, 40, and m×25 Gb/s. The bonded 100GBASE-R PHYs are known as a FlexE Group. Also, MTN (metro transport networking) is being developed in the International Telecommunication Union (ITU) as G.mtn “Interfaces for a metro transport network.” MTN has also been historically called “Flexible Ethernet (FlexE) switching” or “Slicing packet Networking (SPN).” FlexE and G.mtn have not been proposed or described for operation over wireless links. That is, FlexE is specified for optical/wired links only utilizing standard IEEE 802.3 Ethernet PMDs/PHYs.
[0014] The present disclosure relates to systems and methods for Flexible Ethernet (FlexE) over wireless links. The present disclosure substitutes the lower part of an Ethernet PHY below the FlexE calendar function, with a wireless link. This enables the advantages of a FlexE Group (channelization, bonding, and subrating) to a set of wireless links. It can also provide end-to-end hard slicing across multiple different media types (e.g., optical and wireless). The addition of wireless links could increase the topology options for Ethernet networks, e.g., topologies of Ethernet links and wireless links could be created. Support of FlexE clients over such topology is beneficial for client rates that do not exactly match the physical rates. Wireless links may be advantageous in some situations where optical fiber is not present or would be expensive to deploy.
[0015] FIG. 1 is a diagram of the IEEE 802.3 stack and ITU-T architectural views of FlexE and MTN. The technology enabling FlexE is the FlexE shim, which is an adaptation of a 64 B/66 B encoded bit-stream into a Time Division Multiplexing (TDM) like structure across a FlexE group. Each FlexE client has its own bit rate, Media Access Control (MAC), and Reconciliation layers, and Media-Independent Interface (xMII) above the FlexE shim. 64 B/66 B blocks from multiple clients are adapted to the FlexE group using a calendar function that distributes them to the 100GBASE-R PHYs in the FlexE group. The calendar subdivides each 100 Gb/s PHY into 20 slots, and the FlexE shim adaptation multiplexes/demultiplexes all 64 B/66 B blocks from a FlexE client into/from the same set of calendar slots. 200 Gbit/s and 400 Gb/s Ethernet PHYs were added in OIF FlexE IA 2.0.
[0016] As an example of FlexE, four clients each with a rate of 75 Gb/s, which is not an IEEE802.3 rate, could be supported by a FlexE group including three 100GBASE-R PHYs. The FlexE group acts as a 300 Gb/s Ethernet link.
[0026] FlexE or MTN Path client data may originate at Ethernet switch 16, be switched over a FlexE group over optical Ethernet links, and arrives at the edge device 24. Then, it is switched in the MTN path layer to an egress microwave links 36 in the 5G wireless point to multi-point link 14. FlexE or MTN path client data at the output of the microwave link 36 is switched to an egress FlexE group over optical Ethernet links 38. The end-to-end MTN path connection 12 is configured by setting up calendar slots on the Ethernet switch 16, the network device 18, and the edge devices 24 and 26 respectively, and setting up calendar slots with wireless QoS requirements on the microwave link 36.
See also the teachings and discussion of Shew above under “Determining a Basic Unit”.
It would have been obvious that the sending of the basic unit taught in Shew can be implemented in a known manner, such as through a flexible Ethernet (FlexE) slot as taught in Shew and Gareau. In particular, both are in the same technical field (e.g., communications) and the results would have been predictable.
Sending.
Regarding sending the data basic unit, see FIG. 3, reproduced above. See also:
[0031] The wireless domain 54 includes a Packet Data Convergence Protocol (PDCP) mapper 70 that interfaces a Radio Link Control (RLC) layer 72 that interfaces a transport buffer 74. The transport buffer 74 connects to a modulation device 76 that connects to a spectrum resource mapper 78 that supports wireless transmission. FIG. 3 is illustrated in a single direction, transmission from left to right. Of course, a practical embodiment with bidirectional communication would support the same functions in both directions.
In other words, to the extent it was not explicit, it would have been obvious to send, through a flexible Ethernet (FlexE) slot, the basic unit set to a receiving end
Regarding claim 3, Shew teaches the method according to claim 1, wherein the basic unit set comprises at least one basic unit, and the basic unit set is used for carrying client services of at least one terminal device.
See the discussion of claim 1. In general, Shew teaches the use of basic units (i.e., at least one) used to carry data (i.e., communication services).
Regarding claim 4, Shew teaches the method according to claim 1, wherein the basic unit comprises overhead information, and the overhead information comprises at least one of the following: sequence information or operations, administration and maintenance (OAM) information.
Gareau at FIG. 7 illustrates overhead in the FlexE slots.
PNG
media_image3.png
227
993
media_image3.png
Greyscale
Gareau also teaches that it was known for FlexE to include overhead with OAM fields. See, for example:
[0007] In an exemplary embodiment, a node configured to support a Flexible Ethernet (FlexE) client service in a network includes circuitry configured to receive a FlexE client; and circuitry configured to at least one of monitor and update one or more Operations, Administration, and Maintenance (OAM) fields in FlexE overhead, wherein the OAM fields cover a single client path for the FlexE client. The one or more OAM fields can include a client service error monitoring field which does not rely on packet Cyclic Redundancy Check (CRC). The one or more OAM fields can include a client service error monitoring field including a bitstream Bit Interleaved Parity (BIP) code. The one or more OAM fields can include any of a connectivity/trace, link fault, remote fault, maintenance states, test signals, link neighbor discovery, and backwards fault and error indication. The one or more OAM fields can be disassociated from standard Local Fault and Remote Fault information for an associated FlexE group/PHY. The one or more OAM fields can be located using a multiframe scheme in the FlexE overhead. The one or more OAM fields can be implemented in a Reconciliation Sublayer. The node can be one of a Regenerator Section (RS) Optical Transport Network (OTN) switch, a Multiplex Section (MS) OTN switch, and a FlexE switch.
[0029] FIG. 18 is a diagram of an exemplary FlexE OAM implementation with FlexE overhead;
PNG
media_image4.png
562
797
media_image4.png
Greyscale
It would have been obvious that the FlexE format can be implemented in a known manner, such as with OAM fields in the overhead. In particular, Gareau is in the same technical field (e.g., communications) and the results would have been predictable (e.g., the FlexE will include overhead having OAM fields).
Regarding claim 8, Shew teaches the method according to claim 1, wherein at least one FlexE slot is provided.
Shew teaches the use of a FlexE and slots. See, for example:
[0049] In a further embodiment, a system includes a mapper configured to receive data lane streams each including a stream of blocks associated with one of a Flexible Ethernet (FlexE) signal or a Metro Transport Networking (MTN) signal, and map the stream of blocks to data formatted for transmission over one or more wireless links by a transmit device in a wireless data plane; and a demapper configured to receive the formatted data from a receive device in the wireless data plane, and demap the received data to the stream of blocks reconstituting the one of the FlexE signal or the MTN signal.
[0026] FlexE or MTN Path client data may originate at Ethernet switch 16, be switched over a FlexE group over optical Ethernet links, and arrives at the edge device 24. Then, it is switched in the MTN path layer to an egress microwave links 36 in the 5G wireless point to multi-point link 14. FlexE or MTN path client data at the output of the microwave link 36 is switched to an egress FlexE group over optical Ethernet links 38. The end-to-end MTN path connection 12 is configured by setting up calendar slots on the Ethernet switch 16, the network device 18, and the edge devices 24 and 26 respectively, and setting up calendar slots with wireless QoS requirements on the microwave link 36.
See also the more detailed discussion of Shew in claim 1. Gareau also teaches FlexE slots. See:
[0060] The scenario illustrated in FIG. 5 is supported by marking a certain number of the calendar slots as unavailable. This is different from “unused”, in that it is known, due to transport network constraints, that not all of the calendar slots generated from the FlexE mux will reach the FlexE demux and, therefore, no FlexE client 14 should be assigned to those slots. The intention is that when a PHY 22 of the FlexE group 12 is carried across the transport network, the mapping is able to compress the signal to less than the PHY rate by dropping the unavailable calendar slots. A case where 25% of the calendar slots are unavailable is illustrated in FIG. 8.
Gareau at FIG. 8 also illustrates slots in a plurality of basic units.
PNG
media_image5.png
231
1173
media_image5.png
Greyscale
See also:
[0060] The scenario illustrated in FIG. 5 is supported by marking a certain number of the calendar slots as unavailable. This is different from “unused”, in that it is known, due to transport network constraints, that not all of the calendar slots generated from the FlexE mux will reach the FlexE demux and, therefore, no FlexE client 14 should be assigned to those slots. The intention is that when a PHY 22 of the FlexE group 12 is carried across the transport network, the mapping is able to compress the signal to less than the PHY rate by dropping the unavailable calendar slots. A case where 25% of the calendar slots are unavailable is illustrated in FIG. 8.
Therefore, it would have been obvious that at least one FlexE slot is provided.
Regarding claim 12, Shew teaches a data transmission method, applied to a receiving end, comprising:
receiving a basic unit set through a flexible Ethernet (FlexE) slot from a sending end;
determining a basic unit carrying a client service in the basic unit set, wherein the client service is mapped to the basic unit; and
demapping the basic unit to extract the client service from the basic unit.
This is the receiving end of the data transmission method of claim 1. FIG. 3 of Shew illustrates a sending end (left side) and a complementary receiving end (right side).
PNG
media_image1.png
532
744
media_image1.png
Greyscale
See the more detailed discussion of Shew in claim 1. As a result, this claim would have been obvious in light of the rejection of claim 1.
In addition, see Applicant’s arguments filed July 11, 2026 on pages 6-7 which states that all of the pending claims share the same inventive concept. In particular, see the top of page 7 which states:
Therefore, Invention I describes the method and apparatus of a sending end, and Invention II describes the method and apparatus of a receiving end. The features of the sending method (amended claim 1) correspond one-to-one with the features of the receiving method (amended claim 12), and the latter is the inverse process of the former. Applicant also submits that in the present application, current claim 1 and amended claim 12 relate to a single general inventive concept, and they have corresponding technical features.
Therefore, this claim would have been obvious in light of the rejection of claim 1.
Regarding claim 13, Shew teaches the method according to claim 12, wherein determining the basic unit carrying the client service in the basic unit set comprises:
determining sequence information of the basic unit carrying the client service; and
determining, based on the sequence information, the basic unit carrying the client service in the basic unit set.
Shew at FIG. 3 illustrates an apparatus with a transmit side, a receive side with structure/functionality complimentary to the transmit side (see FIG. 3 reproduced in claim 12). In particular, Shew teaches to use sequence information to determine correct ordering at the receiver. See:
[0004] In an embodiment, a mapper includes circuitry configured to receive data streams each is a stream of data based on a calendar function associated with one of Flexible Ethernet (FlexE) and Metro Transport Networking (MTN); and circuitry configured to perform mapping of each of the data streams and to provide an output of the mapping to a device in a wireless data plane for transmission over one or more wireless links. The stream of data can include a stream of blocks sized based on a line encoding technique. The mapping can include packet mapping where the stream of blocks is encapsulated into packets each having a sequence number to ensure correct ordering at a receiver, and the packets can be provided to the wireless data plane at a Packet Data Convergence Protocol (PDCP) layer in the wireless data plane. The mapping can include byte mapping where the stream of blocks is converted into a byte stream that is provided to a Radio Link Control (RLC) layer in the wireless data plane that guarantees byte delivery in order at a receiver. The mapping can include bit mapping wherein the stream of blocks is transferred as a stream of bits to a transport buffer Service Access Point (SAP) in the wireless data plane. The stream of data can include a stream of 64 B/66 B blocks, and wherein the data streams are each about 5 Gb/s corresponding to one of 20 calendar slots in a 100 Gb/s FlexE frame. The data streams can be a plurality of streams and each is transported over portions of different wireless links.
[0005] In another embodiment, a system includes a mapper configured to receive data streams each including a stream of blocks associated with one of a Flexible Ethernet (FlexE) signal or a Metro Transport Networking (MTN) signal, and map the stream of blocks to data formatted for transmission over one or more wireless links by a transmit device in a wireless data plane; and a demapper configured to receive the formatted data from a receive device in the wireless data plane, and demap the received data to the stream of blocks reconstituting the one of the FlexE signal and the MTN signal. The data formatted can include packet mapping where the stream of blocks is encapsulated into packets each having a sequence number to ensure correct ordering at the demapper, and the packets can include provided to the wireless data plane at a Packet Data Convergence Protocol (PDCP) layer in the wireless data plane. The data formatted can include byte mapping where the stream of blocks is converted into a byte stream that is provided to a Radio Link Control (RLC) layer in the wireless data plane that guarantees byte delivery in order at the demapper. The data formatted can include bit mapping wherein the stream of blocks is transferred as a stream of bits to a transport buffer Service Access Point (SAP) in the wireless data plane. The stream of data can include a stream of 64 B/66 B blocks, and wherein the data streams are each about 5 Gb/s corresponding to one of 20 calendar slots in a 100 Gb/s FlexE frame. The data streams can be a plurality of streams and each is transported over a different wireless link. The system can further include a transmit buffer between the mapper and the wireless data plane; and a receive buffer between the demapper and the wireless data plane.
In other words, the sequence information is used at the receiver to order (i.e., determine) the transmitted/received data. See also the complimentary transmit and receive functionality in FIG. 5.
PNG
media_image6.png
696
502
media_image6.png
Greyscale
See also, for example:
[0041] The process 200 can further include receiving the formatted data from a receive device in the wireless data plane (step S3); and demapping the received data to the stream of blocks reconstituting the one of the FlexE stream or the MTN stream (step S4).
[0042] The data formatted can include packet mapping where the stream of blocks is encapsulated into packets each having a sequence number to ensure correct ordering at the demapper, and wherein the packets are provided to the wireless data plane at a Packet Data Convergence Protocol (PDCP) layer in the wireless data plane.
[0049] In a further embodiment, a system includes a mapper configured to receive data lane streams each including a stream of blocks associated with one of a Flexible Ethernet (FlexE) signal or a Metro Transport Networking (MTN) signal, and map the stream of blocks to data formatted for transmission over one or more wireless links by a transmit device in a wireless data plane; and a demapper configured to receive the formatted data from a receive device in the wireless data plane, and demap the received data to the stream of blocks reconstituting the one of the FlexE signal or the MTN signal.
Therefore, the functionality of this claim would have been obvious.
Regarding claim 14, Shew teaches the method according to claim 12, wherein the basic unit set comprises at least one basic unit, and the basic unit set is used for carrying the client data of at least one terminal device.
This method is complementary (on the receiving side) to the method of claim 3 and would have been obvious for the reasons discussed in claim 12 and in claim 3.
Regarding claim 15, Shew teaches the method according to claim 14, wherein the basic unit comprises overhead information, and the overhead information comprises at least one of the following:
sequence information or operations, administration and maintenance (OAM) information.
This method is complementary (on the receiving side) to the method of claim 4 and would have been obvious for the reasons discussed in claim 12 and in claim 4.
Regarding claim 18, Shew teaches a sending end, comprising:
at least one processor; and
a storage apparatus configured to store at least one program;
wherein executed by the at least one processor, the at least one program causes the at least one processor to implement:
determining a basic unit carrying a client service, wherein the basic unit is a basic unit comprised in a basic unit set;
mapping the client service to the basic unit; and
sending, through a flexible Ethernet (FlexE) slot, the basic unit set to a receiving end.
This is a processor/memory implementation of method claim 1. Shew teaches that functionality can be implemented with a processor and memory storing programming. See:
[0050] It will be appreciated that some embodiments described herein may include one or more generic or specialized processors (“one or more processors”) such as microprocessors; Central Processing Units (CPUs); Digital Signal Processors (DSPs): customized processors such as Network Processors (NPs) or Network Processing Units (NPUs), Graphics Processing Units (GPUs), or the like; Field Programmable Gate Arrays (FPGAs); and the like along with unique stored program instructions (including both software and firmware) for control thereof 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 or circuitry. Of course, a combination of the aforementioned approaches may be used. For some of the embodiments described herein, a corresponding device in hardware and optionally with software, firmware, and a combination thereof can be referred to as “circuitry configured or adapted to,” “logic configured or adapted to,” etc. perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. on digital and/or analog signals as described herein for the various embodiments.
[0051] Moreover, some embodiments may include a non-transitory computer-readable storage medium having computer readable code stored thereon for programming a computer, server, appliance, device, processor, circuit, etc. each of which may include a processor to perform functions 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 or device (e.g., any type of programmable circuitry or logic) that, in response to such execution, cause a processor or the device to perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. as described herein for the various embodiments.
It would have been obvious that the method can be implemented with a processor and memory as recited in the claim.
Regarding claim 19, Shew teaches a receiving end, comprising:
at least one processor; and
a storage apparatus configured to store at least one program;
wherein executed by the at least one processor, the at least one program causes the at least one processor to implement the method according to claim 12.
This is a processor/memory implementation of method claim 12. This would have been obvious for the reasons discussed in claims 18 and 12.
Regarding claim 20, Shew teaches a non-transitory computer-readable storage medium storing a computer program which, when executed by a processor, causes the processor to implement the method according to claim 1.
This is a CRM implementation of the method of claim 1. Shew teaches the use of CRM with instructions executable by a processor to perform desired functionality. See the discussion of claim 12. This claim would have been obvious for the reasons discussed in claims 1 and 12.
Claim(s) 2, 5-7, and 9-11 is/are rejected under 35 U.S.C. 103 as being unpatentable over the art as applied to claim 1 above, and further in view of US 2002/0012334 (Strawczynski).
Regarding claim 2, Shew teaches the method according to claim 1, wherein the basic unit comprises a cell.
Shew teaches using basic units in the form of packets. See:
[0004] In an embodiment, a mapper includes circuitry configured to receive data streams each is a stream of data based on a calendar function associated with one of Flexible Ethernet (FlexE) and Metro Transport Networking (MTN); and circuitry configured to perform mapping of each of the data streams and to provide an output of the mapping to a device in a wireless data plane for transmission over one or more wireless links. The stream of data can include a stream of blocks sized based on a line encoding technique. The mapping can include packet mapping where the stream of blocks is encapsulated into packets each having a sequence number to ensure correct ordering at a receiver, and the packets can be provided to the wireless data plane at a Packet Data Convergence Protocol (PDCP) layer in the wireless data plane. The mapping can include byte mapping where the stream of blocks is converted into a byte stream that is provided to a Radio Link Control (RLC) layer in the wireless data plane that guarantees byte delivery in order at a receiver. The mapping can include bit mapping wherein the stream of blocks is transferred as a stream of bits to a transport buffer Service Access Point (SAP) in the wireless data plane. The stream of data can include a stream of 64 B/66 B blocks, and wherein the data streams are each about 5 Gb/s corresponding to one of 20 calendar slots in a 100 Gb/s FlexE frame. The data streams can be a plurality of streams and each is transported over portions of different wireless links.
Furthermore, it was known that basic units can be cells. See Strawczynski:
[0057] The present invention is also applicable to asynchronous mode transmission (ATM) using TDM frames. In ATM communications, information is transferred in basic units known as cells. Each ATM cell is comprised of 53 bytes of which five bytes comprise a header field and the remaining 48 bytes comprise a user information field. One or more ATM cells are embedded in the TDM frames.
It would have been obvious that the basic units taught in Shew can be implemented in a known manner, such as a cell as taught in Strawczynski. In particular, both are in the same technical field (e.g., communications) and the results would have been predictable.
Regarding claim 5, Shew teaches the method according to claim 1, wherein the basic unit is a cell, the cell is formed by combining different target code blocks;
the different target code blocks comprise a border control code block and a data code block (D block);
the data code block is used for carrying the client service;
the border control code block is used for identifying a border of the cell; and
the border control code block comprises at least one of the following: a starting block (S block), a terminating block (T block).
Strawczynski teaches that it was known that basic units can be in the form of cells. See Strawczynski:
[0057] The present invention is also applicable to asynchronous mode transmission (ATM) using TDM frames. In ATM communications, information is transferred in basic units known as cells. Each ATM cell is comprised of 53 bytes of which five bytes comprise a header field and the remaining 48 bytes comprise a user information field. One or more ATM cells are embedded in the TDM frames.
It would have been obvious that the basic units can be cells (see the discussion of claim 2).
Gareau teaches a basic unit in the form of FlexE slot (see the discussion of claim 1). Regarding the OAM blocks, Gareau at FIG. 7 illustrates overhead in the FlexE slots.
PNG
media_image3.png
227
993
media_image3.png
Greyscale
Gareau also teaches that it was known for FlexE to include overhead with OAM fields. See, for example:
[0007] In an exemplary embodiment, a node configured to support a Flexible Ethernet (FlexE) client service in a network includes circuitry configured to receive a FlexE client; and circuitry configured to at least one of monitor and update one or more Operations, Administration, and Maintenance (OAM) fields in FlexE overhead, wherein the OAM fields cover a single client path for the FlexE client. The one or more OAM fields can include a client service error monitoring field which does not rely on packet Cyclic Redundancy Check (CRC). The one or more OAM fields can include a client service error monitoring field including a bitstream Bit Interleaved Parity (BIP) code. The one or more OAM fields can include any of a connectivity/trace, link fault, remote fault, maintenance states, test signals, link neighbor discovery, and backwards fault and error indication. The one or more OAM fields can be disassociated from standard Local Fault and Remote Fault information for an associated FlexE group/PHY. The one or more OAM fields can be located using a multiframe scheme in the FlexE overhead. The one or more OAM fields can be implemented in a Reconciliation Sublayer. The node can be one of a Regenerator Section (RS) Optical Transport Network (OTN) switch, a Multiplex Section (MS) OTN switch, and a FlexE switch.
[0029] FIG. 18 is a diagram of an exemplary FlexE OAM implementation with FlexE overhead;
PNG
media_image4.png
562
797
media_image4.png
Greyscale
See also Gareau at FIG. 9 and:
[0054] In the case where the FlexE client 14 comes from an Ethernet PHY which uses PCS lane alignment markers (e.g., 40GBASE-R), the lanes must be deskewed, re-interleaved and serialized, removing the alignment markers to produce the 64b/66b stream which is treated as a FlexE client 14. All FlexE clients 14 transmitted over the same FlexE group 12 must be aligned to a common clock. This is accomplished using idle insertion/deletion as described in IEEE Std 802.3-2015 clause 82.2.3.6. In addition, the bit-rate of each FlexE client 14 is reduced slightly from nominal as part of this process to allow room for insertion of FlexE overhead and the PCS lane alignment markers of the FlexE group 12. So the 64b/66b encoded format of a FlexE client 14 operates at a data rate of:
[0061] The anchor position FlexE overhead is encoded as an ordered set (control block type 0x4B). A different “O” code (Operational Code) is selected (i.e. 0x5) which is different from that for the sequence ordered set used by Ethernet or the signal ordered set used by Fibre channel. The information to be transmitted in the FlexE overhead is encoded into the bytes D1, D2, and D3 of the overhead set block is shown in FIG. 9.
[0074] The 25GBASE-R specification is currently under development in the IEEE P802.3by project. While the specification has not been finalized, judging from currently adopted baselines, converting a 25GBASE-R signal to a 25G FlexE client signal format is expected to involve correcting FEC errors (if FEC present), removing the FEC, removing the CWM (if present), trans-decoding to 64b/66b, and using the idle insertion/deletion process as described in IEEE Std 802.3-2015 clause 82.2.3.6 (which will actually be doing idle deletion to make room for the FlexE overhead) to adapt the signal to the 25G FlexE client rate and align start of packet to an 8-byte boundary, encoding according to the 66b block format of Figure 82-4 in IEEE Std 802.3-2015 from the received format which uses the blocks according to Figure 49-7 of the same standard. The conversion of a 25G FlexE client signal coming from a FlexE demux to a 25GBASE-R signal is expected to involve using the idle insertion/deletion process as described in IEEE Std 802.3-2015 clause 49.2.4.7 (which will actually be doing idle insertion to compensate for the space that had been occupied by FlexE overhead—the FlexE group lane alignment markers take the same proportion of the space as the CWM), 256b/257b transcoding, insertion of the CWM, and calculation and insertion of FEC, if appropriate.
Regarding the data code blocks, Gareau teaches data carrying blocks between the overhead (e.g., see FIG. 7). See also Shew as discussed in claim 1 regarding FlexE carrying client data.
Regarding claim 6, Shew teaches the method according to claim 5, wherein overhead information in the basic unit is carried by the target code blocks.
Gareau teaches that the OAM and other data is carried in the overhead blocks.
PNG
media_image4.png
562
797
media_image4.png
Greyscale
See the discussion of claim 5 for a more detailed discussion.
Regarding claim 7, Shew teaches the method according to claim 1, wherein the basic unit is a cell, wherein the client service is mapped to a data code block of the cell.
Shew teaches that it was contemplated to implement the apparatus using packets. See, for example:
[0004] In an embodiment, a mapper includes circuitry configured to receive data streams each is a stream of data based on a calendar function associated with one of Flexible Ethernet (FlexE) and Metro Transport Networking (MTN); and circuitry configured to perform mapping of each of the data streams and to provide an output of the mapping to a device in a wireless data plane for transmission over one or more wireless links. The stream of data can include a stream of blocks sized based on a line encoding technique. The mapping can include packet mapping where the stream of blocks is encapsulated into packets each having a sequence number to ensure correct ordering at a receiver, and the packets can be provided to the wireless data plane at a Packet Data Convergence Protocol (PDCP) layer in the wireless data plane. The mapping can include byte mapping where the stream of blocks is converted into a byte stream that is provided to a Radio Link Control (RLC) layer in the wireless data plane that guarantees byte delivery in order at a receiver. The mapping can include bit mapping wherein the stream of blocks is transferred as a stream of bits to a transport buffer Service Access Point (SAP) in the wireless data plane. The stream of data can include a stream of 64 B/66 B blocks, and wherein the data streams are each about 5 Gb/s corresponding to one of 20 calendar slots in a 100 Gb/s FlexE frame. The data streams can be a plurality of streams and each is transported over portions of different wireless links.
[0034] For packet mapping, the mapper 50 provides the 64 B/66 B data stream to the PDCP mapper 70 via IP encapsulation. The mapper 50 can pack a 64 B/66 B block stream into IP packets or the like, i.e., something that can be transported over the wireless stack. IP encapsulation can include sequence numbers in the packets to ensure the 64 B/66 B block stream can be reconstituted in the correct order at the receiver, i.e., at an adjacent mapper 50 on the other end of the wireless domain 54.
Furthermore, when using packets, it would have been obvious to map data (e.g., content) to the content carrying part of the packet. See also the discussion of mapping in claim 1.
Furthermore, Strawczynski teaches that it was known that basic units can be in the form of cells. See Strawczynski:
[0057] The present invention is also applicable to asynchronous mode transmission (ATM) using TDM frames. In ATM communications, information is transferred in basic units known as cells. Each ATM cell is comprised of 53 bytes of which five bytes comprise a header field and the remaining 48 bytes comprise a user information field. One or more ATM cells are embedded in the TDM frames.
It would have been obvious that the basic units in Shew can be of other known forms for basic units, such as cells as taught in Strawczynski. See also the discussion of claim 2.
Regarding claim 9, Shew teaches the method according to claim 1, wherein that sending, through the FlexE slot, the basic unit set comprises:
in response to the basic unit being a cell and the basic unit set comprising a plurality of basic units, inserting an idle information block every set number of basic units, wherein the idle information block is inserted between the plurality of basic units.
Shew teaches sending, through the FlexE slot, the basic unit set. Gareau at FIG. 8 illustrates unused (e.g., idle) blocks every set number of basic units.
PNG
media_image5.png
231
1173
media_image5.png
Greyscale
See also:
[0060] The scenario illustrated in FIG. 5 is supported by marking a certain number of the calendar slots as unavailable. This is different from “unused”, in that it is known, due to transport network constraints, that not all of the calendar slots generated from the FlexE mux will reach the FlexE demux and, therefore, no FlexE client 14 should be assigned to those slots. The intention is that when a PHY 22 of the FlexE group 12 is carried across the transport network, the mapping is able to compress the signal to less than the PHY rate by dropping the unavailable calendar slots. A case where 25% of the calendar slots are unavailable is illustrated in FIG. 8.
Also, Gareau teaches various uses for idle information blocks. See, for example:
[0039] FIG. 2A illustrates the functions of the FlexE mux (the FlexE shim 16 functions in the transmit direction). Where the 64b/66b encode and idle insert/delete functions and whether these functions are part of the FlexE is application specific. What is presented for insertion into the slots of the FlexE master calendar is a stream of 64b/66b encoded blocks encoded per IEEE Std 802.3-2015 Table 82-4 which has been rate-matched to other clients of the same FlexE shim 16. This stream of 66b blocks might be created directly at the required rate using back-pressure from a Network Processing Unit (NPU). It might come from a single-lane Ethernet PHY such as 10G or 25G, where the process of rate-matching involves both idle insertion/deletion, plus converting the rate-aligned stream from the 4-byte alignment of IEEE Std 802.3-2015 clause 49 to the 8-byte alignment of IEEE Std 802.3-2015 clause 82. Note that the IEEE 802.3 diagrammatic convention of showing idle insertion/deletion as though this were an operation that operates on a stream of 64b/66b blocks, even though strictly speaking this may require 64b/66b decoding and recoding, particularly in the case of converting between 4-byte alignment and 8-byte alignment. The stream of blocks may come from a multi-lane Ethernet PHY, where the lanes need to be deskewed and re-interleaved with alignment markers removed prior to performing idle insertion/deletion to rate match with other clients of the same FlexE shim 16. Or the stream may have come from another FlexE shim 16, for example, connected across an OTN network, where all that is required is to perform idle insertion/deletion to rate match with other clients of the same FlexE shim 16.
[0042] Where the Idle Insertion/Deletion, 66B Decoding functions are performed and whether they are inside or outside the FlexE is application specific. The 66b blocks could be delivered directly to an NPU. If delivered to a single-lane PHY, idle insertion/deletion may be used to increase the rate to the PHY rate, realigning to 4-byte boundaries in the process (for 10G or 25G) and recoding 64b/66b according to clause 49. For a multi-lane PHY, idle insertion/deletion is used to increase the rate to the PHY rate less the space needed for alignment markers, the blocks are distributed to PCS lanes with AM insertion. For a FlexE client mapped over OTN, idle insertion/deletion may be used to adjust the rate as required for the OTN mapping.
[0054] In the case where the FlexE client 14 comes from an Ethernet PHY which uses PCS lane alignment markers (e.g., 40GBASE-R), the lanes must be deskewed, re-interleaved and serialized, removing the alignment markers to produce the 64b/66b stream which is treated as a FlexE client 14. All FlexE clients 14 transmitted over the same FlexE group 12 must be aligned to a common clock. This is accomplished using idle insertion/deletion as described in IEEE Std 802.3-2015 clause 82.2.3.6. In addition, the bit-rate of each FlexE client 14 is reduced slightly from nominal as part of this process to allow room for insertion of FlexE overhead and the PCS lane alignment markers of the FlexE group 12. So the 64b/66b encoded format of a FlexE client 14 operates at a data rate of:
Therefore, it would have been obvious that the basic unit set comprises a plurality of basic units, inserting an idle information block every set number of basic units, wherein the idle information block is inserted between the plurality of basic units.
Furthermore, Strawczynski teaches that it was known that basic units can be in the form of cells. See Strawczynski:
[0057] The present invention is also applicable to asynchronous mode transmission (ATM) using TDM frames. In ATM communications, information is transferred in basic units known as cells. Each ATM cell is comprised of 53 bytes of which five bytes comprise a header field and the remaining 48 bytes comprise a user information field. One or more ATM cells are embedded in the TDM frames.
It would have been obvious that the basic units in Shew can be of other known forms for basic units, such as cells as taught in Strawczynski. See also the discussion of claim 2.
Regarding claim 10, Shew teaches the method according to claim 9, wherein that sending, through the FlexE slot, the basic unit set comprises: sending, through the FlexE slot, the basic unit set to which the idle information block is inserted.
Although this claim is rejected under 112(b), in the interests of compact prosecution the following rejection is presented to assist applicant in preparing a response.
As discussed in claim 1, Shew and Gareau teaches sending a basic unit through the FlexE slot, and as discussed in claim 9 Gareau teaches to send idle information block.
Therefore, to the extent the claim is understood, it would have been obvious to send, through the FlexE slot, the basic unit set to which the idle information block is inserted.
Regarding claim 11, Shew teaches the method according to claim 1, wherein that mapping the client service to the basic unit comprises:
in response to the basic unit being a cell, encoding the client service by using a 64/66 encoding rule; or encoding the client service by first using a 64/66 encoding rule and then using another encoding rule; and
mapping the encoded client service to the basic unit
As discussed in claim 1, Shew teaches to map the client services to the basic unit. Furthermore, Shew also teaches using a 64/66 encoding rule. See:
[0005] In another embodiment, a system includes a mapper configured to receive data streams each including a stream of blocks associated with one of a Flexible Ethernet (FlexE) signal or a Metro Transport Networking (MTN) signal, and map the stream of blocks to data formatted for transmission over one or more wireless links by a transmit device in a wireless data plane; and a demapper configured to receive the formatted data from a receive device in the wireless data plane, and demap the received data to the stream of blocks reconstituting the one of the FlexE signal and the MTN signal. The data formatted can include packet mapping where the stream of blocks is encapsulated into packets each having a sequence number to ensure correct ordering at the demapper, and the packets can include provided to the wireless data plane at a Packet Data Convergence Protocol (PDCP) layer in the wireless data plane. The data formatted can include byte mapping where the stream of blocks is converted into a byte stream that is provided to a Radio Link Control (RLC) layer in the wireless data plane that guarantees byte delivery in order at the demapper. The data formatted can include bit mapping wherein the stream of blocks is transferred as a stream of bits to a transport buffer Service Access Point (SAP) in the wireless data plane. The stream of data can include a stream of 64 B/66 B blocks, and wherein the data streams are each about 5 Gb/s corresponding to one of 20 calendar slots in a 100 Gb/s FlexE frame. The data streams can be a plurality of streams and each is transported over a different wireless link. The system can further include a transmit buffer between the mapper and the wireless data plane; and a receive buffer between the demapper and the wireless data plane.
In other words, Shew teaches the data stream can be encoded with 64/66 encoding. It would have been obvious that the data in Shew can be processed in a known manner, such as with 64/66 encoding.
Furthermore, Strawczynski teaches that it was known that basic units can be in the form of cells. See Strawczynski:
[0057] The present invention is also applicable to asynchronous mode transmission (ATM) using TDM frames. In ATM communications, information is transferred in basic units known as cells. Each ATM cell is comprised of 53 bytes of which five bytes comprise a header field and the remaining 48 bytes comprise a user information field. One or more ATM cells are embedded in the TDM frames.
It would have been obvious that the basic units in Shew can be of other known forms for basic units, such as cells as taught in Strawczynski. See also the discussion of claim 2.
Claim(s) 16 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over the art as applied to claim 14 above, and further in view of US 2002/0012334 (Strawczynski).
Regarding claim 16, Shew teaches the method according to claim 14, wherein the basic unit is a cell,
the cell is formed by combining different target code blocks;
the different target code blocks comprise a border control code block and a data code block (D block);
the data code block is used for carrying the client service;
the border control code block is used for identifying a border of the cell; and
the border control code block comprises at least one of the following: a starting block (S block), a terminating block (T block).
This method is complementary (on the receiving side) to the method of claim 5 and would have been obvious for the reasons discussed in claims 12 and 14, and in claim 5.
Regarding claim 17, Shew teaches the method according to claim 16, wherein overhead information in the basic unit is carried by the target code blocks.
This method is complementary (on the receiving side) to the method of claim 6 and would have been obvious for the reasons discussed in claims 12 and 14, and in claim 6.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 10,142,030 (Blanks) at FIG. 8 teaches a free space communication system.
PNG
media_image7.png
830
290
media_image7.png
Greyscale
FIG. 9 is a block diagram of a transceiver including a variety of controllers used for implementing the functionality of the transceiver.:
PNG
media_image8.png
797
564
media_image8.png
Greyscale
US 2016/0149645 (Liu) at FIGS. 3 and 4 which illustrate alternative embodiments in which FIG. 3 uses a red LED 304, and FIG. 4 uses a white LED 404 and a red filter 408.
PNG
media_image9.png
423
402
media_image9.png
Greyscale
In other words, encoding, decoding, driving, sending, and receiving signals in free space was known.
US 2021/0067249 (Hull) at FIG. 1 illustrates a free space optical communication system including access points 117, 118, and user devices 109, 110, 120.
PNG
media_image10.png
460
647
media_image10.png
Greyscale
See, for example:
[0023] Certain aircraft equipment and systems, such as display 106, headset 109, and EFB 110, may use light communication (LC) to provide data and/or power connections to the aircraft. The LC-capable systems may have an embedded LC sensor 115 and LC transmitter 116 that are configured to communicate with LC access points 117, 118 onboard the aircraft. Alternatively, an external LC device 120 may connect directly to one or more device to support LC connections, such using as a dongle 120 that plugs into a USB or other port on display 106. The external LC communication device 120 has an LC sensor 121 and an LC transmitter 122. LC sensors 115, 121 (e.g., cameras or photodetectors) and LC transmitters 116, 122 (e.g., LED) need to be exposed to remote light sources and sensors in LC access points 117, 118.
LiFi Implementation.
It also teaches that this communication can be implemented with LiFi. See, for example:
[0028] Light transmitter 116 may be a LED, for example. Light transmitter 116 may use invisible (e.g., infrared) and/or visible light spectrum for high speed data communication. The total size of the infrared and visible light spectrum is approximately 2600 times the size of the entire radio frequency spectrum. LEDs have been shown to enable data rates up to 5 Gbps with peak transmission speeds of 8 Gbps using with a single LED. Data rates higher than 100 Gbps are feasible with laser-based lighting. Accordingly, LC can vastly extend the available bandwidth for wireless communication devices. Communication protocols available for LC may be referred to as Light Fidelity (LiFi) or Optical Wireless Communication (OWC) and may be defined in IEEE 802.11bb, IEEE 802.15.7m, 802.15.13, or other standards.
Access Point Transceiver.
FIG. 3 illustrates a detailed view of an access point 300 including a controller 306, a set of lights for light communication 303, and a set of light sensors 309.
PNG
media_image11.png
455
742
media_image11.png
Greyscale
See, for example:
[0046] FIG. 3 depicts a light communication access point 300 for use in an aircraft according to an example embodiment. A first set of one or more lights 301 provide visible light for cockpit or cabin lighting. A second set of one or more lights 302 provide visible or invisible light for use in powering LC-capable devices. A third set of one or more lights 303 are adapted for transmitting data using visible or invisible light communications. Power supply 304 receives power from an aircraft electrical bus 305, such as an avionics bus or accessory bus. Power supply 304 provides power to cockpit/cabin lights 301, such as LEDs, incandescent, or fluorescent bulbs, which may be selected on or off by a crewmember or passenger. Power supply 304 also provides electricity to power lights 302, which may be LEDs or laser lights, that transmit power wirelessly to other devices. Controller 306 may manage when such wireless power is available and at what frequencies. Power lights 302 may transmit power over the same frequency or groups of one or more lights 302 may transmit power on different visible and/or invisible frequencies.
[0047] Data is transmitted using LC by encoding data bits using transmitter/encoder 307 into a signal that drives data lights 303, which then broadcast the information as light signals. Data lights may be LEDs or laser lights, for example. Data lights 303 may transmit data over the same frequency or groups of one or more lights 303 may transmit data on different frequencies. Controller 306 is coupled to an aircraft data network 308, which carries information, such as digital bit streams, packet data, voice, video, text, or other content. Controller 306 receives information to be broadcast and sends the information to transmitter/encoder 307, which encodes the information as digital signals that are transmitted by data lights 303 in the visible and/or invisible spectrum.
[0048] A light sensor 309 detects visible and/or invisible light and generates an electronic signal for receiver/decoder 310, which extracts data bits that are carried by the light. The extracted bits may carry information that can be processed by controller 306 and forwarded to aircraft data network 308. Light sensor 309 may be, for example, a camera, image sensor, or photodetector, such as a CMOS sensor or other electronic chip that converts photons to electrons for digital processing.
Communication Device.
FIG. 4 illustrates a detailed view of a light communications device including processors 401, memory 402, light sensor 414, and light source 417.
PNG
media_image12.png
561
747
media_image12.png
Greyscale
See, for example:
[0053] System memory 402 may be configured to store program instructions and/or data accessible by processor 401. In various embodiments, system memory 402 may be implemented using any suitable memory technology, such as Static Random-Access Memory (SRAM), Synchronous Dynamic RAM (SDRAM), nonvolatile/Flash-type memory, or any other type of memory. As illustrated, program instructions and data implementing certain operations and modules such as those described herein may be stored within system memory 402 as program instructions 410 and data storage 411, respectively. In other embodiments, program instructions and/or data may be received, sent, or stored upon different types of computer-accessible media or on similar media separate from system memory 402.
[0054] A computer-accessible medium may include any tangible and/or non-transitory storage media or memory media such as electronic, magnetic, or optical media—e.g., disk or CD/DVD-ROM coupled to device 400 via bus 403. The terms “tangible” and “non-transitory,” as used herein, are intended to describe a computer-readable storage medium (or “memory”) excluding propagating electromagnetic signals but are not intended to otherwise limit the type of physical computer-readable storage device that is encompassed by the phrase computer-readable medium or memory. For instance, the terms “non-transitory computer-readable medium” or “tangible memory” are intended to encompass types of storage devices that do not necessarily store information permanently, including for example, Random Access Memory (RAM). Program instructions and data stored on a tangible computer-accessible storage medium in non-transitory form may further be transmitted by transmission media or signals, such as electrical, electromagnetic, or digital signals, which may be conveyed via a communication medium such as a network and/or a wireless link.
[0060] Light communication is supported using a light sensor 414 and a receiver/decoder 415 to receive data and a transmitter/encoder 416 and light transmitter 417 to transmit data. Light sensor 414 may be, for example, a camera, image sensor, or photodetector, such as a CMOS sensor or other electronic chip that converts photons to electrons for digital processing. Light sensor 414 detects light and generates an electronic signal for receiver/decoder 415, which extracts data bits that are carried by the light. The extracted bits may carry information that can be used by processors 401A-N. Data can also be sent using LC by encoding data bits using transmitter/encoder 416 into a signal that drives light transmitter 417, which then broadcasts the information as light signals. Light transmitter 417 may be an LED or laser, for example. Light sensor 414 and light transmitter 417 may use invisible (e.g., infrared or ultraviolet) and/or visible light spectrum for high speed data communication.
US 5,917,634 (Otobe) at FIG. 2 illustrates a system for indoor use, non-reflected, free space optical communication.
PNG
media_image13.png
605
532
media_image13.png
Greyscale
FIG. 5 illustrates an embodiment operating with reflected light.
PNG
media_image14.png
733
533
media_image14.png
Greyscale
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DARREN WOLF whose telephone number is (571)270-3378. The examiner can normally be reached Monday through Friday, 7:00 AM to 3:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, KENNETH N. VANDERPUYE can be reached on 571-272-3078. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
DARREN E. WOLF
Primary Examiner
Art Unit 2634
/DARREN E WOLF/ Primary Examiner, Art Unit 2634
Prosecution Insights