Communication Techniques

Abstract

To provide techniques (for example, methods and devices) for enabling communication, for example, optical communication.SOLUTION: In one example, a first communication device (16) can be configured to receive one or more reference signals and / or beacon signals (11) from one or more front ends (14a...14g). The first communication device (16) can be configured to determine (31) channel information based on the reception of the one or more reference signals and / or beacon signals (11). The first communication device (16) can be configured to transmit channel information (32, 32b, 35, 450, 450b) during a contention access period (CAP) (11a).SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] Techniques for communication between at least one first device and at least one second device are disclosed below. For example, the second device may be a facility (e.g., with a wireless front end, e.g., an optical front end), and the at least one first device may be one or more devices (e.g., a wireless device, e.g., an optical device). In some examples, the facility (or second device) is fixed (at least in one front end), and one or more first devices may be mobile. Techniques for bit loading are also discussed. Techniques for medium access (MAC) are also discussed. Multiple-input / multiple-output (MIMO) techniques are discussed here.

Background Art

[0002] For example, wireless communication (e.g., visible light communication (VLC) and other communications, e.g., high-frequency (RF) communication, ultrasonic communication, etc.) between a facility (e.g., with a fixed relay or front end) and one or more devices (e.g., mobile devices) is known.

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Non-Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0004] If the reliability is low, for example, due to changes in the communication channel and / or movement of the device, these communications may be impaired. Therefore, techniques for enhancing reliability are generally required.

[0005] In some cases, it may be difficult to define bit loading. For example, it may be difficult to define the frequencies (for example, subcarriers) transmitted by each front end (for example, a relay) and each device (for example, a mobile device). Therefore, techniques for enhancing communication are generally required.

Means for Solving the Problems

[0006] The definition of the present invention is found in the independent claims.

[0007] According to an example, a first communication device is disclosed that is configured to receive one or more reference signals and / or beacon signals from one or more front ends (for example, an optical front end), The first communication device is configured to determine channel information based on the reception of one or more reference signals and / or beacon signals, The first communication device is configured to transmit channel information during a contention access period (CAP).

[0008] According to an example, a communication method is disclosed, and this communication method includes, in a first communication device, receiving one or more reference signals and / or beacon signals from one or more front ends (e.g., an optical front end), determining a channel based on the reception of the one or more reference signals and / or beacon signals in the first communication device, and transmitting channel information during a contention access period (CAP) from the first communication device.

[0009] According to an example, a second communication device is disclosed that is adjusted by a regulator connected to a front end, wherein the second communication device is configured to transmit one or more reference signals and / or beacon signals from one or more front ends (e.g., an optical front end), and the second communication device is configured to receive channel information during a contention access period (CAP).

[0010] According to an example, a communication method is disclosed, and this communication method includes transmitting one or more reference signals and / or beacon signals from one or more front ends (e.g., an optical front end), and receiving channel information during a contention access period (CAP).

[0011] According to an example, a central unit is disclosed, and the central unit performs an initial coarse synchronization among a plurality of front ends, orders the transmission of reference signals and / or beacon signals to a plurality of distributed front ends, obtains channel information measured by the first communication device, Subsequently, by synchronizing the front ends, a second precise synchronization is performed based on the channel information. It is configured as follows.

[0012] According to an example, a second communication device for transmitting and / or receiving through a plurality of front ends is disclosed. The second communication device performs an initial coarse synchronization among the plurality of front ends, transmits a reference signal and / or a beacon signal to one or more first devices through the front ends, acquires the channel information measured by the first communication device, and synchronizes the front ends using a second precise synchronization based on the channel information. It is configured as follows.

[0013] According to an example, a second communication device for transmitting and / or receiving through a plurality of front ends is disclosed. The second communication device performs an initial coarse synchronization among the plurality of front ends, transmits a reference signal and / or a beacon signal to one or more first communication devices through the front ends, acquires the channel information measured by the first communication device, and synchronizes the front ends using a second precise synchronization based on the channel information. It is configured as follows.

[0014] According to an example, a method is disclosed. The method includes the steps of performing an initial coarse synchronization among a plurality of front ends, issuing an instruction to transmit a reference signal and / or a beacon signal to the plurality of front ends (for example, optical front ends), acquiring the channel information measured by the first communication device based on the reference signal and / or the beacon signal, and synchronizing the front ends based on the channel information.

[0015] According to an example, a communication method for transmitting and / or receiving data through a plurality of front ends (for example, an optical front end) is disclosed. This method includes: executing an initial rough synchronization among a plurality of front ends; transmitting a reference signal and / or a beacon signal to one or more first communication devices through the front end; acquiring channel information measured by the first communication device; and synchronizing the front end based on the channel information.

[0016] According to an example, a first communication device for communication with a second communication device is disclosed. The first communication device: acquires channel state information from the reception of one or more reference signals and / or beacon signals from one or more front ends; converts the channel state information from the frequency domain to the time domain to obtain time domain channel state information; encodes the time domain channel state information; and transmits the time domain channel state information to one or more front ends. It is configured as such.

[0017] According to an example, a second communication device for communication with a first communication device is disclosed. The second communication device: includes a string of a second value and a first value, each associated with a time domain representation of the CSI; for each second value in the string, has an encoded value of the amplitude of the time domain representation at a specific sample; for each first value in the string, receives the CSI encoded such that it has an encoded sample value that is not considered to be zero; and reconstructs the CSI based on the sample values associated with the second values. It is configured as such. It is configured as such.

[0018] According to an example, a communication method for communication of a first communication device with a second communication device is disclosed, the communication method comprising: obtaining channel state information from reception of one or more reference signals and / or beacon signals from one or more front ends; converting the channel state information from the frequency domain to the time domain to obtain time domain channel state information; encoding the time domain channel state information; and transmitting the time domain channel state information to one or more front ends.

[0019] According to an example, a communication method for communication between a second communication device and a first communication device is disclosed, the communication method comprising: receiving CSI encoded such that each comprises a string of a second value and a first value, each associated with a time domain representation of the CSI, for each second value in the string, having an encoded value of the amplitude of the time domain representation at a particular sample, and for each first value, having a sample value that is encoded and not considered to be zero; and reconstructing the CSI based on the sample values associated with the second values.

[0020] According to an example, a first apparatus is disclosed, the first apparatus being configured to: receive a plurality of reference signals from a plurality of front ends; obtain channel state information (CSI) based on an evaluation of the received reference signals; encode the CSI to provide an encoded CSI; and provide information describing a selection of an encoding resolution used to encode the CSI from among a plurality of possible encoding resolutions.

[0021] ​​According to an example, a method [executed by a first communication device such as, for example, a transmitter, a mobile device, an optical transmitter, etc., such as any of the upper or lower examples] is disclosed, the method comprising: receiving a plurality of reference signals from a plurality of [for example, optical] front ends [for example, OFE]; acquiring channel state information (CSI) based on an evaluation of the received reference signals; encoding the CSI to provide encoded CSI; providing [for example, signal] information [for example, TAP format] describing a selection of an encoding resolution used to encode the CSI from among a plurality of possible encoding resolutions; and comprising.

[0022] According to an example, a second communication device is disclosed, the second communication device being configured to: receive encoded channel state information (CSI); receive information describing a selection of an encoding resolution used to encode the CSI from among a plurality of possible encoding resolutions; decode the encoded CSI according to the information describing the selection of the encoding resolution used to encode the CSI. and being so configured.

[0023] According to an example, a device according to any of the upper or lower examples, and a system comprising a device according to any of the upper or lower examples are disclosed.

[0024] According to an example, a method [executed by a first communication device such as, for example, a receiver, a device, an optical receiver, and / or a device according to any of the upper or lower examples] is disclosed, the method comprising: receiving encoded channel state information (CSI); Describing the selection of the encoding resolution used to encode CSI from among a plurality of possible encoding resolutions; for example, receiving signal information [e.g., TAP format]; Decoding the encoded CSI according to information [e.g., TAP format] describing the selection of the encoding resolution used to encode the CSI; Comprising.

[0025] According to an example, the first communication device and / or the second communication device may be a device for performing optical communication.

[0026] According to an example, the first communication device and / or the second communication device may be a device for performing communication through visible light communication (VLC).

[0027] According to an example, the first communication device and / or the second communication device may be a movable device.

[0028] According to an example, the first communication device and / or the second communication device may be at least partially fixed devices (e.g., at least one front end may be fixed).

[0029] According to an example, the first communication device and / or the second communication device may include a plurality of optical front ends.

[0030] According to an example, the first communication device and / or the second communication device may include a front hole between the regulator and / or a plurality of front ends.

[0031] According to an example, the second communication device may have a star topology.

[0032] According to an example, different front ends may be configured to relay a DL transmission from the regulator to an external first device and / or a UL transmission from the external first device to the regulator.

[0033] According to an example, different front-ends may be configured to simultaneously relay at least one DL transmission using different orthogonal sequences.

[0034] According to an example, different front-ends may be configured to relay UL received transmissions towards a regulator.

[0035] According to an example, a first communication device for communicating with a second communication device is disclosed, the first communication device being configured to transmit a bit allocation table (BAT) message, the BAT message including at least one of validity information signaling which one or more of a plurality of BATs are valid, and / or updated BAT information signaling which BAT of a plurality of BATs should be updated and the first communication device expects an acknowledgement, the acknowledgement being derived from the use of bit allocation according to at least one of an updated BAT provided by the updated BAT information and a valid BAT provided by the validity information, and if a valid acknowledgement is not received from the second communication device, retransmits the BAT message is provided.

[0036] According to an example, a first communication device for communicating with a second communication device is disclosed, the first communication device being configured to transmit a bit allocation table (BAT) message, the BAT update information including BAT update information signaling update information for updating a BAT signaled to be updated, the length of the BAT update information being variable.

[0037] According to an example, a second communication device for communicating with a first communication device is disclosed, the second communication device being configured to receive a bit allocation table (BAT) message from the first communication device, the BAT message Validity information signaling which one or more of a plurality of BATs are valid, Updated BAT information signaling which of the plurality of BATs should be updated comprises at least one of, and the second communication device is to send a confirmation, the confirmation being derived from the use of a bit allocation according to at least one of the updated BATs as provided by the updated BAT information and the valid BATs as provided by the validity information.

[0038] According to an example, a second communication device for communicating with a first communication device is disclosed, the second communication device being to receive a bit allocation table (BAT) message, BAT update information includes BAT update information signaling update information for updating the BATs signaled to be updated, The length of the BAT update information is variable.

[0039] According to an example, a method for communication between a communication device and a communication facility is disclosed, the method including the step of sending a bit allocation table (BAT) message, the BAT message validity information signaling which one or more of a plurality of BATs are valid, updated BAT information signaling which of the plurality of BATs should be updated, BAT update information signaling update information for updating the BATs signaled to be updated comprises.

[0040] According to an example, a method for communication between a second communication device and a first communication device is disclosed, the method including the step of sending a bit allocation table (BAT) message, the BAT message updated BAT information signaling which of the plurality of BATs should be updated, and Validity information for signaling which one or more of a plurality of BATs are valid comprising at least one of the method further comprises a step of sending a confirmation from the communication facility to the communication device, the confirmation being derived from the use of a bit allocation according to at least one of the updated BAT and the valid BAT; if the communication device does not receive a valid confirmation from the communication facility, a step of resending a BAT message from the communication device to the communication facility.

[0041] According to an example, a method for communicating between a first communication device and a second communication device is disclosed, the method including a step of sending a bit allocation table (BAT) message from the first communication device, the BAT update information includes BAT update information for signaling update information for updating the BAT to be signaled to be updated, the length of the BAT update information is variable.

[0042] According to an example, a non-transitory storage unit storing information that, when executed by a processor, causes the processor to execute a method according to any of the above or below examples is disclosed.

[0043] According to an example, a system is disclosed comprising a communication facility according to any of the above or below examples and a communication device according to any of the above or below examples. BRIEF DESCRIPTION OF THE DRAWINGS

[0044]

Figure 1

Figure 1a

Figure 2

Figure 2a

Figure 3

Figure 3a

Figure 3b

Figure 4

Figure 4a

Figure 5a

Figure 5b

Figure 5c

Figure 6

Figure 7a

Figure 7b

Figure 7c

Figure 7d

Figure 7e

Figure 8

Figure 8a

Figure 8b

Figure 8c

Figure 8d

Figure 9-1

Figure 9-3

Figure 9-4

Figure 9-5

Figure 9-6

Figure 9-7

Figure 10-8

Figure 10-9

Figure 10-10

Figure 10-11

Figure 10-12

Figure 10-13

Figure 10-14

Figure 10-16

Figure 10-17

Figure 10-18

Figure 10-19

Figure 11-21

Figure 11-22

Figure 11-23

Figure 11-24

Figure 11-25

Figure 11-26

Figure 11-27

Figure 11-28

Figure 11-29

Figure 11-30

Figure 11-31

Figure 11-32

Figure 11-33

Figure 11-34

Figure 11-35

Figure 11-36

Figure 11-37

Figure 11-38

Figure 11-39

Figure 11-40

Figure 11-41

Figure 11-42

Figure 11-43

Figure 11-44

Figure 11-45

Figure 11-46

Figure 11-47

Figure 11-48

Figure 11-49

Figure 11-50

Figure 11-51

Figure 11-52

Figure 11-53

Figure 11-54

Figure 11-55

Figure 11-56

Figure 11-57

Figure 11-58

Figure 11-59

Embodiments for Carrying Out the Invention

[0045] In the following examples, reference signs for devices of the same type are often referred to using the same reference numbers (e.g., 16, 14), and distinguishing them by using dots (e.g., 16', 16") or by using different letters (such as 14a, 14b, 14c, etc.). When referring to characteristics generally associated with all devices of the same type, the reference numbers may be used to refer to the entire type (e.g., 16, 14), or alternatively, by using multiple references (e.g., 14a…14g).

[0046] The following and above examples are mainly described with respect to communication mainly based on visible light communication (VLC), but in some examples, they can be generalized to, for example, wireless communication (using, for example, RF, ultrasonic, etc.).

[0047] The following and above examples are described mainly as being directed to communication between a second device that may be a facility having a fixed front end such as an optical front end, and a first device that may be a mobile device. However, in some specific cases, they can be generalized to examples where the first device is mobile (e.g., with at least one mobile front end), and / or examples involving at least one fixed-position device (e.g., with multiple front ends). In some examples, at least one of the first devices may be mobile. Additionally or alternatively, at least one of the first devices may be fixed.

[0048] The following and above examples are mainly described with respect to selecting a configuration for downlink (DL) transmission of a payload (e.g., from a facility to a device). However, it is also possible to define a configuration for uplink (UL) transmission of a payload (e.g., from a device to a facility).

[0049] The following and above examples are mainly described as being primarily intended as being associated with a network such that, for example, multiple devices (e.g., mobile devices) may send data to and receive data from a facility for communication for industrial automation or similar applications. Communication to and / or from other devices within that network or a different network may be intended. Some of the following examples refer to multiple-input / multiple-output (MIMO) networks.

[0050] In the following and above examples, payload transmission may refer to, for example, sensing values, actuation values, feedback values, etc. in an industrial environment. Additionally or alternatively, payload transmission may refer to, for example, voice data, web page data, etc. for voice communication. In the following examples, mainly control signaling is focused on, and the use of payload data for this application is generally left free.

[0051] The following and above examples are mainly described as being primarily directed to a second apparatus embodied by a distributed facility having a regulator (e.g., one single regulator) and a plurality of front-ends (e.g., optical front-ends (OFE)) connected to the regulator in a star topology. For example, the regulator may be at the center of the star, and the plurality of front-ends may be at the vertices of the star through a star connection formed through a backhaul. Other topologies (e.g., bus topology, wireless topology, point-to-point topology, etc.) are possible.

[0052] In the examples of the bottom and the top, at least some of the front ends are generally regarded as relays, and these retransmit the packets obtained from the regulators of the equipment and / or retransmit the regulator wireless packets obtained wirelessly to the regulators. In some cases, the front ends may still "personalize" their transmissions slightly (for example, by using different sequences such as orthogonal sequences and / or by using different identifiers). Thus, even when different front ends relay the same signal obtained from the regulator at the same time, they can transmit at least slightly different signals and / or can distinguish their transmissions.

[0053] FIG. 1 shows a network 10 (system) for wireless communication (for example, optical communication or visible light communication (VLC)) between at least one first communication device and at least one second communication device, which here is a communication facility 15 that can be, for example, a base station (BS). Here, the at least one first communication device includes at least one communication device (for example, a user equipment (UE), a relay endpoint (REP), a mobile device).

[0054] The second device (communication facility) 15 may include a regulator 12, which may be a computer-based system (for example, a processor-based system). The regulator 12 can be understood to be the only intelligent part (or one of the intelligent parts) of the communication facility 15 in some examples. In an example of industrial automation, the regulator 12 can also be part of a fixed equipment associated with some machines or adjusting (or associated with a device for adjusting a plurality of machines).

[0055] The second device (communication equipment) 15 may include at least one front end or a plurality of front ends (for example, relay endpoints (REP)) 14a…14g. The front ends 14a…14g may be, for example, optical front ends (OFE). In the case of OFE, each OFE may include a phototransceiver, a photodiode, a transmitting diode, a light emitting diode (LED). In the case of RF, each front end may include an RF transceiver. In the case of ultrasonic, each front end may include an ultrasonic transceiver.

[0056] In an example, the plurality of front ends 14a…14g may be part of the communication equipment 15. The optical front ends 14a…14g may be spatially distributed (for example, at known positions) so as to transmit and receive communication through channels (for example, optical channels) 18a…18g so as to transmit / receive communication in various parts of the environment. In an example, the front ends 14a…14g may have fixed and / or known positions.

[0057] The front ends 14a…14g of the second device 15 may be connected to the regulator 12 through the front hall 17. The front hall 17 may be constituted by (or at least include) communication channels (for example, 17a, 17b…17g) for enabling transmission between the front ends 14a…14g and the regulator 12. The front hall 17 may include at least one communication network. The front hall 17 may support a star topology. The front hall 17 may include a plurality of point-to-point connections. The front hall 17 may be wired (for example, using metal conductors) or cable-connected (for at least some connections) for connection to at least one front end (in some examples, all connections to the front end are wired and / or cable-connected). In some examples, the front hall 17 is wireless (for at least the connection to at least one front end). In some examples, the front hall 17 may be based on Ethernet.

[0058] FIG. 6 shows an example of the physical layer 12' of the regulator 12, but the higher layer 12" of the regulator 12 is not shown. The regulator 12 may include a plurality of transmission ports 12a…12z (transmission chains). Each transmission port 12a…12z may be connected to communication channels 17a…17z for transmission towards respective front ends. Transmission may be performed for each PLCP Service Data Unit (PSDU) via the PD-SAP. The RX configuration (not shown in the figure) may be through the PLME-SAP (PLME: Physical Layer Management Entity).

[0059] The front ends 14a…14g may perform transmission with the communication device 16 (e.g., 16', 16") through a wireless link, such as an optical link 18a…18g like a VLC link or other wireless links. Different links are collectively shown by 18, but the communication between each front end 14a…14g and respective mobile devices 16', 16" is shown using the characters associated with each front end. For example, in FIG. 1 (at least in the case shown by the figure), The front ends 14a, 14b, and 14c happen to be communicating with the mobile device 16' through three optical connections (channels) 18a, 18b, 18c respectively. The optical front end 14d is not communicating with any mobile device. The optical front ends 14e, 14f, and 14g are communicating with the mobile device 16" through wireless connections 18e, 18f, and 18g respectively.

[0060] Each front end 14a…14g can relay data packets to and from external devices. For example, signals transmitted by the regulator 12 to the front ends 14a…14g through the front hole 17 can be immediately retransmitted (e.g., optically or more generally wirelessly). Similarly, signals received by the front ends 14a…14g (e.g., optically or more generally wirelessly) are immediately retransmitted to the regulator 12 through the front hole 17. In some cases, different front ends 14a…14g simultaneously retransmit signals from the regulator 12 using different sequences (e.g., orthogonal sequences) and / or identifiers that identify each front end. For example, the first front end 14a may retransmit a signal from the regulator 12 using a first sequence, while at the same time, a second front end may retransmit the same signal from the regulator 12 using a different sequence orthogonal to the first sequence (different identifiers may also be used). The same can be applied by using various sets of non-overlapping subcarriers.

[0061] At least one mobile device 16 (e.g., 16' and 16") that can be a first communication device can be described as a user equipment and / or device that can be mobile (movable) with respect to the front ends 14a…14g or at least one of them. Thus, since the relative positions between the mobile devices 16', 16" and at least one of the optical front ends 14a…14g may change, this implies that the channel conditions for the links 18a…18g change. Nevertheless, fast connection and reconnection are possible between each mobile device 16', 16" and each front end 14a…14g. For example, in the case shown by FIG. 1, the mobile device 16" is incidentally connected to the front ends 14e…14g due to its position, but after moving, the mobile device 16" may reach a position closer to the mobile device 16'. In that case, the mobile device 16" will probably be disconnected from the front ends 14e…14g and connected to the front ends 14a…14c. This is probably due to the fact that the optical channels 18a…18c are better than the optical channels 18e…18g at that position (e.g., less noisy and / or higher signal-to-noise ratio).

[0062] Communication between the front ends 14a…14g and various first devices (e.g., communication devices 16', 16") can be performed using scheduling that assigns different resources to different mobile devices in order to avoid contention between different signals from different communication devices 16', 16".

[0063] In an example, at least some of the resources can be time slots. In an example, at least some of the resources can be selected front ends from among the front ends 14a…14g.

[0064] In the above and below examples, the regulator 12 may require several simultaneous transmissions to a plurality of front-ends (e.g., beacon transmissions, reference signals, etc.). Thus, different front-ends may simultaneously relay a beacon or a reference signal. In the above and below examples, the regulator 12 may require scheduled transmissions such that, for example, at least two different front-ends transmit and / or receive different data and / or transmit and / or receive simultaneously.

[0065] FIG. 2 shows a communication scheme 20 that maps time slots and front-ends to be assigned to different mobile devices 16 (here shown as A, B, C, and D, although at least one of them may be one of devices 16' and 16"). In scheme 20, time is scheduled according to period 21. For example, the current period 21 is after the previous period and before the subsequent period. Period 21 may start with a first beacon transmission 11' (beacon transmission for the current period) and / or end with a second beacon transmission 11" (beacon transmission for the subsequent period). A beacon transmission (also called a "beacon") may be denoted by 11 when it is not necessary to indicate whether the beacon is the first or a beacon that starts the core period of a subsequent period. In the example, the beacon 11 may be transmitted by a plurality of (e.g., all) optical front-ends 14a…14g, for example simultaneously (at the same time, in the same slot). The beacon 11 may be transmitted by different front-ends at different frequencies (e.g., carriers, sub-carriers). For example, each front-end 14a…14g may transmit a beacon in a plurality of signals at different frequencies, for example simultaneously and / or at different instants and / or over a plurality of time slots. Additionally or alternatively, different sub-carriers may be present simultaneously in the beacon 11.

[0066] During the transmission of beacon 11 from the entirety of front ends 14a…14g, each mobile device 16 may perform measurements to determine the conditions of their respective wireless links 18. For example, if by chance or intentionally, an opaque element is incidentally inserted between front end 14a and device 16', as a result, optical link 18a is blocked, preventing mobile device 16' from receiving beacon 11. The inability to receive beacon 11 in this way may cause a determination that the channel connection associated with optical link 18a is poor. The same may apply to between mobile device 16' and front ends 14b, 14e, 14f, 14g, depending on the shape and position of the inserted opaque element. Beacon 11 received from front ends 14b, 14e, 14f, 14g causes poor reception, suggesting that mobile device 16' perceives incorrect reception of beacon 11 from those front ends.

[0067] Each beacon 11 may be transmitted at different frequencies (e.g., subcarriers), for example, by sweeping along different frequencies, enabling each mobile device 16 to obtain measurement results associated with each subcarrier. The measurement results may be associated with, for example, the amplitude of the beacon signal, and / or the power of the received beacon signal, and / or energy, and / or power, etc. The measurement results may be obtained, for example, by decoding a specific pilot sequence (e.g., known by device 16), and by measuring errors in the pilot sequence, and / or by analyzing the signal. Good performance is brought about, for example, by those receptions of beacon 11 that are associated with having high energy and / or high power and / or high amplitude and / or low error rate when decoding the pilot sequence. In some examples, the more of the received pilot sequence corresponds to a predefined pilot sequence, the higher the quality.

[0068] In some examples, beacon 11 is relayed slightly differently by different front - ends 14a…14g. For example, different front - ends 14a…14g may re - transmit the same beacon 11 by using different orthogonal sequences and / or different frequencies and / or different identifiers, so that each device 16 can distinguish different pilot sequences as obtained by each front - end 14a…14g. Subsequently, each device 16 (the first device) may perform measurements of each of the pilot signals obtained from the plurality of front - ends 14a…14g to obtain the quality of different channels 18a…18g.

[0069] During the transmission of two consecutive beacons 11' and 11", according to the scheduling, period 21 has time slots for enabling the communication of data (e.g., payload) and / or control signals between the communication facility 15 and the mobile device 16. For example, a part of period 21 may be associated with a contention access period (CAP) 11a (e.g., may be re - divided into time slots). CAP 11a can be understood as a random access frame. In the example, CAP 11a may be right after beacon 11'. CAP 11a can be controlled by a listen - before - talk (LBT) medium access strategy. For example, protocol Aloha may be used. In each time slot of CAP 11a, each mobile device 16' may transmit data or control signals after detecting that no other mobile device has started transmission. Several known LBT protocols have been developed for avoiding or resolving contention.

[0070] According to scheduling 20, period 21 may include a collision-free period (CFP) 11b (e.g., which may be further divided into time slots). CFP 11b may be immediately after CAP 11a and / or immediately before a subsequent beacon 11". During each time slot within CFP 11b, communication in the uplink (UL) and / or downlink (DL) may be performed using each of the mobile devices 16 (A, B, C, D).

[0071] As can be understood from FIG. 2, the space can also be understood as being divided according to different front ends 14a…14j. For example, in the scheduling 20 shown in FIG. 2, the overall CFP 11b for three front ends 14a, 14b, 14c happens to be assigned to mobile device A. A different fourth front end 14e is contingently uniquely associated with mobile device B. Front end 14f may be assigned to mobile device C during some time slots (the first 13 time slots within CFP 11b), but the subsequent slots of front end 14e (the last 11 time slots of CFP 11b before the subsequent beacon 11') are assigned to a different mobile device D (16). In particular, the first slot of CFP 11b is contingently assigned to both mobile devices A, B, and C (front ends 14a…14c are assigned to mobile device A, front end 14d is assigned to mobile device B, front ends 14e and 14f are assigned to mobile device C, no front end is associated with mobile device D, and front ends 14d, 14h, and 14j are not associated with any mobile device at all).

[0072] Since each time slot is generally associated with a plurality of different front ends 14a…14j and different front ends can be sent to different devices, a reference to a "superframe slot" can be made. Not only time but also space will be subdivided into a plurality of resources, each of which is used for transmission by the device 16 or the facility 15. Basically, for each CFP11b, each mobile device 16 (A, B, C, D) is assigned in one or more front ends 14a…14j to a combination of one or more time slots. This concept is indicated by the acronym GTS for Guaranteed Time Slot.

[0073] Scheduling 20 may be defined in real time by the regulator 12, and the regulator 12 may allocate to each mobile device 16 (A, B, C, D) the necessary time slots and / or front ends 14a…14j to be used for communication. A particular scheduling 20 may be performed based on signaling information provided to the regulator 12 (or more generally, the communication facility 15) by each communication device 16 (A, B, C, D), and / or may be based on at least one criterion. The at least one criterion may be selected (by the regulator 12, either statically or dynamically) from among some of the criteria. One criterion may be based on feedback provided by the communication device 16 (which may not be considered for the current strategy), one criterion may be based on the urgency of the transmission, one criterion may be based on the requirements of the device, etc.

[0074] Some interesting aspects are discussed below. In some cases, for the same example, different aspects may be combined with each other.

[0075] Aspect I Here, the "device" may be generalized to the "first device (16)", and the "facility" may be generalized to the "second device (15)", and may be so even if they can be interchanged in a variation. The front end may be an optical front end. The device 16 may be a mobile device. The facility may be fixed, and the front end of the facility may be distributed. The regulator 12 or the central unit may be an intelligent part of the facility.

[0076] In particular, when the device 16 (16', 16") is movable, there may arise a possibility that the scheduling 20 no longer conforms to the position of the device after at least one movement of the device. For example, in FIG. 1, when the device 16" moves towards the position of the device 16', a situation may arise where the device 16" is probably better served by the front ends 14a, 14b, 14c than by the front ends 14e, 14f, and 14g. However, the front ends 14a, 14b, 14c are probably assigned by the scheduling 20 to the device 16'. Thus, the following situation may occur. In fact, the DL transmission addressed to the device 16' reaches the device 16". The device 16" attempts to transmit (in UL) to the front ends 14e, 14f, and 14g in the time slot assigned by the scheduling 20, and in doing so, the device 16" overlays its transmission on the simultaneous UL transmission actually performed by the device 16' in the same time slot, resulting in the front ends 14a... 14c receiving the transmission of the device 16' along with the interference of the simultaneous transmission of the device 16". At the same time, the front ends 14e... 14g remain waiting in vain for the transmission from the device 16".

[0077] However, several techniques have been developed that make it possible to cope with such or similar inconveniences.

[0078] Basically, (in UL and / or DL) The provision of a first static or quasi-static slot (e.g., without expiration and remaining valid until overwritten), and / or a second dynamic provision (e.g., with an expiration date and thus temporary) It is understood that communication can be carried out according to a strategy that provides.

[0079] Thus, device 16 can have a fixed or temporary, assigned time slot. For example, device 16 may be (fully or mostly) assigned the dynamic second time slot while moving, and device 16 that is not moving (e.g., fixed) may be (fully or mostly) assigned the quasi-static first time slot. Here, the slot (first time slot or second time slot) may be a superframe slot, which implies that at the same time, different front ends 14a…14g can send different data packets to different devices 16', 16" or receive different data packets from them. To inform devices 16', 16" of the allocation of the first time slot provision and / or the second time slot provision, facility 15 can send first time slot provision information for communicating the allocation of the first time slot provision and / or second time slot provision information for communicating the allocation of the second time slot provision. Thus, devices 16', 16" can determine when they can send data packets to facility 15 and / or receive data packets from facility 15.

[0080] It is possible to communicate the first time slot provision information (static or quasi-static first time slot provision) as part of a management frame.

[0081] In a control frame (e.g., using dynamic descriptors), it is possible to send second time slot provision information (for dynamic first time slot provision).

[0082] Note that device 15 is capable of transmitting management frames with a lower priority with respect to control frames. Therefore, the communication of dynamic second time slot allocation information has a higher priority than the communication of quasi-static first time slot allocation information.

[0083] In some examples, device 16 may request a new allocated time slot (GTS) from device 15 (e.g., after moving). In the device request, if no response is given from device 15, device 16 may consider the request as failed. This may be done, for example, after a predetermined number of periods (e.g., superframes) have elapsed. For example, after five superframes have elapsed without the transmission of the first time slot allocation information and / or the second time slot allocation information from device 15 to device 16, the request is considered as failed by device 16, and device 16 may, for example, send a new request to device 15.

[0084] Figures 7(a) to 7(c) show signaling information exchanged between device 16 and device 15 for communicating allocations to each other based on the first time slot allocation information and the second time slot allocation information.

[0085] Figure 7(a) shows a request 720 as provided by device 16 to device 15. The request 720 may indicate, for example, the requested MCS (additionally or alternatively, other data may be inserted into the request 720).

[0086] FIG. 7(b) shows an example (static or quasi-static GTS descriptor) of first time slot allocation information 710, such as may be transmitted by facility 15. The first time slot allocation information 710 may be transmitted to a device to which a static or quasi-static time slot is allocated. The first time slot allocation information 710 may include a GTS start slot field 712, which may indicate the starting point of the first GTS (e.g., where the first GTS starts in period 21 for example). The first time slot allocation information 710 may include an immediate validity field 713, which may indicate whether the allocation is immediately valid (in the same period 21) or not immediately valid (and becomes valid in a subsequent period). The first time slot allocation information 710 may include a GTS length field 714, which may indicate the length of the first GTS. When the first time slot allocation information 710 is received by device 16, the allocation signaled in the first time slot allocation information 710 is used by device 16 to permanently change the scheduling (at least until a subsequent reception of the first time slot allocation information 710). Thus, the first time slot allocation information 710 does not expire if not requested by facility 15 (e.g., if not overwritten).

[0087] FIG. 7(c) shows an example (dynamic GTS descriptor) of the second time slot allocation information 700, such as that transmitted by the facility 15. The second time slot allocation information 700 can be transmitted to a plurality of devices. The second time slot allocation information 700 may lack an address indication (e.g., when received by a plurality of devices 16). The second time slot allocation information 700 may include a GTS start slot field 702, which can indicate the starting point of the dynamic second GTS (e.g., where the dynamic second GTS starts in period 21, for example). The second time slot allocation information 700 may include a GTS length field 704, which can indicate the length of the dynamic second GTS. The second time slot allocation information 700 may include a validity field 706, which can indicate for how many subsequent periods 21 the dynamic second GTS is allocated to a particular device 16.

[0088] When the second time slot allocation information 700 is received by the device 16, the allocation signaled in the second time slot allocation information 700 is used by the device 16 to temporarily change the scheduling (e.g., for the number of periods indicated in the validity field 706). Therefore, the first time slot allocation information 710 does not expire if not requested by the facility 15.

[0089] Note that the information 710 and 700 (GTS descriptors) are information associated with a single GTS.

[0090] However, it is understood that it is possible to encode multiple GTS descriptors in the same frame (control frame or management frame) so as to provide information 710 and 700 regarding multiple slots in a single frame, thereby reducing the payload. As shown in FIG. 7(d), in some examples, multiple descriptors may be concatenated in a single list 730 (e.g., 700', 700", or 710', 710"…). The list 730 may include a GTS descriptor count field indicating how many GTS descriptors 700', 700", or 710', 710" are included in the list.

[0091] Additionally or alternatively, a message 740 (FIG. 7(e)) may be transmitted. The message 740 may include information 710 and 700 and / or the list 730. The message 740 may include a GTS descriptor count field indicating how many descriptors are in the list 730. The message 740 may include a GTS descriptor count field indicating how many GTS descriptors 700', 700", or 710', 710" are included in the list 730. The message 740 may optionally include a validity presence indication 742, which indicates whether a validity field 706 is included in the frame (see descriptor 700). The message 740 may include reserved bits 743. The message 740 may optionally include a GTS direction field, which may indicate the direction of the GTS (e.g., DL, UL).

[0092] By using information 700, 710, 730, and / or 740, the facility 15 can indicate new scheduling information to the device 16, so that dynamic GTS, static GTS, or semi-static GTS can be reallocated to different devices.

[0093] In some examples, scheduling 20 may be changed by the facility 15 and / or information 700, 710, 730, and / or 740 may be provided to the device 16 based on feedback provided by the device 16 regarding the channel 18. The feedback may be based on measurements for the beacon 11 as received from a plurality of front ends 14.

[0094] An example is provided by FIG. 2a. Another example is provided by FIG. 3, where the beacon 11 is provided simultaneously by the front ends 14a... 14g. Measurements 31 are performed on different versions of the beacon 11 as received from a plurality of front ends. Then, feedback 32 (e.g., channel state information (CSI) 32) is provided from the device 16 to the facility 15. The facility 15 may redefine the scheduling based on the acquired feedback 32. Thus, the facility 15 may provide configuration information 33 (700, 710, 720, 730, etc.) to the device 16 (in FIG. 3, even if only "dynamic GTS" is written, it is also possible to provide information about "static GTS" or "quasi-static GTS"). Examples of feedback 32 are provided below (see also further aspects).

[0095] In the above example, the GTS to which information 33, 700, 730, 740, etc. are allocated may be the GTS of the CFP 11b as shown in FIGS. 2 and 3.

[0096] Accordingly, a communication facility (15) is provided, which is configured to transmit information in an allocated time slot. The communication facility (15) is configured to transmit configuration information (700) included in one or more management frames (740). The communication facility (15) is configured to transmit configuration information (710) included in one or more control frames (740). The communication facility (15) is configured to transmit first time slot allocation information (710), which is included in a management frame. The communication facility (15) is configured to transmit second time slot allocation information (700) included in a control frame (740), which has a limited time validity. The communication facility (15) is configured to allocate one or more time slots for communication depending on the first time slot allocation information (710) and depending on the second time slot allocation information (700).

[0097] Aspect II Here, "device" may be generalized to "first device (16)", and "facility" may be generalized to "second device (15)", and may be so even if they can be interchanged in a variation. The front end may be an optical front end. Device 16 may be a mobile device. The facility may be fixed, and the front end of the facility may be distributed. The regulator 12 or the central unit may be an intelligent part of the facility.

[0098] To allocate superframe slots (e.g., as may appear as in FIG. 2 and / or as may appear as described for aspect 1), a mechanism may be used to provide feedback 32 to a second device (e.g., facility) 15 regarding reception of transmissions from a front end 14a - 14g (e.g., optical front end) of the second device (e.g., facility) 15 to a first device (e.g., device) 16 (16', 16", A, B, C, D, etc.). Generally speaking, the second device (e.g., facility) 15 (and specifically, the central unit or regulator 12) may define the most appropriate assigned slots and / or the most appropriate front end for each first device (e.g., device) 16 (e.g., 16', 16", A, B, C, D).

[0099] Generally speaking, it is possible to obtain a first communication device (e.g., device 16) configured to receive one or more reference signals and / or beacon signals (e.g., 11) from one or more front ends (14a…14g). The first communication device (16) may be configured to determine channel information (e.g., CSI) (e.g., 31) based on reception of one or more reference signals and / or beacon signals (11). The first communication device (e.g., 16) may be configured to transmit channel information (32) during a contention access period (or random access frame), e.g., CAP11a (FIGS. 2 and 3a). The first communication device (e.g., 16) may be configured to subsequently update channel information (e.g., 32b) during a collision - free period, e.g., CFP11b (e.g., FIGS. 2 and 3b).

[0100] Thus, in some examples, When the first device (e.g., a device) 16 first reaches the network, the first device 16 may transmit channel information (e.g., CSI) 32 (or an association request 35 as in FIG. 3a) at CAP11a (as in FIG. 3), because there is no assigned slot allocated to the first device (e.g., a device) 16 and the second device (e.g., a facility) does not recognize the first device 16. In response, the second device (e.g., a facility) 15 may allocate an assigned time slot (GTS) to the first device 16 through GTS33 (FIG. 3) (e.g., the GTS of CFP11b in FIG. 2). Subsequently, after the first device 16 is allocated an assigned time slot in CFP11b of period 21, the first device 16 may transmit (update) subsequent channel information (e.g., CSI) 32 in CFP11b of period 21 (as in FIG. 3b). In response, the second device 15 may allocate a GTS to the first device 16 through GTS33b (FIG. 3b) (e.g., the GTS of CFP11b).

[0101] As shown in FIG. 3, the second device (e.g., a facility) 15 may transmit a beacon 11 to the device 16. In some examples, the beacon 11 may be the same beacon as discussed above and / or the same as the beacon 11 in FIG. 2. In other examples, instead of the beacon 11, a reference signal that is not a beacon may be transmitted. In any case, even if it is clear that a reference signal may also be used in alternative examples, it is referred to here as a "beacon". The beacon 11 may be a global message, which may be the same (or approximately the same) for all front-ends 14a... 14g that relay it and may be transmitted simultaneously from all front-ends 14a... 14g and towards all first devices (e.g., device 16).

[0102] A plurality of front - ends 14a…14g can be adjusted and / or synchronized with each other, for example, by an adjuster 12, through a wired connection (for example, a front - hole 17).

[0103] From the reception of the beacon 11 and / or the reference signal, the device 16 can determine channel information (channel state information) based on the reception of the reference signal and / or the beacon. For example, the device 16 can measure the quality of channel 18. The device 16 can measure a signal - to - noise ratio (SNR) or a parameter associated with the SNR. The device 16 can perform channel estimation. A second device (for example, the device 16) can perform channel measurements.

[0104] For example, the beacon 11 and / or the reference signal may comprise, for example, a pilot sequence (known to the device 16), and the first device (for example, the device 16) can perform measurements on the reception of the pilot signal. Since the pilot sequence is known to the device 16 (for example, stored in the memory unit of the device 16), the device 16 can compare the pre - stored version of the pilot sequence with the received pilot sequence and perform measurements based on the similarity of the received signal with the pre - stored signal. The device 16 can count the amount of incorrect received values. The greater the amount of incorrect values, the worse the channel state (for example, the lower the SNR). Thus, the device 16 can comprise a measurement unit for measuring the state and / or quality and / or SNR of the channel. FIG. 3 shows the channel measurement time used by the device 16 to perform the measurement 31.

[0105] As shown in FIG. 3, device 16 may transmit a message 32 in which the measured channel information is encoded, based on the reception of a beacon or reference signal (11). The encoded measured channel information may be such that the facility 15 (and / or regulator 12) can understand whether the channels between each front end and / or device 16 are optimal. (Thus, the encoded measured channel information may be used by regulator 12 to define information 700, 710, 730, and / or 740, as described above with reference to aspect I).

[0106] It is understood that a first device (e.g., device 16) may transmit a feedback message with channel information 32, at least in a contention access period (CAP) for a first transmission (in access to the network by the first device 16). The contention access period (CAP) 11a may be as in FIG. 2 (see above). After CAP 11a, the facility 15 may inform of a new allocation (e.g., re - divided into super - frames) using message 33. Examples of message 33 may include, for example, management frames and / or control frames. Examples of information provided by message 33 are first time - slot allocation information 710 and / or dynamic second time - slot allocation information 700. Thus, message 33 may be, or may include, configuration information that allocates a grant to device 16. Message 33 may be transmitted before or after a subsequent beacon 11 of a subsequent period 21.

[0107] Broadly speaking, the second device (e.g., equipment) 15 may provide allocation information for time slots and / or front ends 14a…14g based on channel state information provided by a plurality of devices. For example, in FIG. 1, the second device (e.g., communication equipment) 15 associates front ends 14a, 14b, 14c with device 16, associates front ends 14e, 14f, 14g with device 16", and does not associate any device with front end 14b. Similarly, the second device (e.g., equipment) 15 may reach a scheduling definition as in FIG. 2, for example, by considering feedback obtained from device 16.

[0108] As described above, feedback 32 may be received from a plurality of devices 16 (e.g., 16' and 16"). Thus, the regulator 12 of the second device 15 may distribute the granted ones (GTS) during CFP11b. Note that when one device 16 has the ability to recognize different beacon signals 11 arriving from different channels 18a…18g (and different front ends 14a…14g), feedback 32 may refer to different channels 18a…18g. This is because each front end 14a…14g may be able to relay the beacon signal by using different sequences (e.g., orthogonal sequences), and thus different relayed beacon signals may be determined and measured by device 16. Thus, feedback 32 may be provided for a plurality of received relayed versions of beacon signal 11. Based on different feedbacks associated with different channels 18a…18g, the regulator 12 may perform appropriate scheduling and allocate the most appropriate superframe GTS (including the most appropriate front ends 14a…14g) to the device that detects the best channel associated with the front end. In the example, front ends 14a…14g are synchronized with each other to transmit beacon signal 11 simultaneously (some strategies for synchronization are described below).

[0109] The example of FIG. 3a will be discussed here. A new unknown first device (e.g., an unknown device) 16 that has reached near one of the front ends 14a…14g may send at least one association request 35 (e.g., 35', 35", 35''', etc.) to enable payload data to be later transmitted and / or received between the second device (e.g., the facility 15) by having several GTSs assigned at CFP11b.

[0110] A new first device (e.g., device 16) (such as not being known) that does not have a GTS assigned before the association may be provided with a first device 16 that sends an association request frame 35 at CAP11a (but not at CFP11b). Thus, the requesting device 16 may start the CAP transmission procedure after preparing a frame including an Association Request element.

[0111] In some examples, the requesting device 16 may include a feedback 32 including channel information (CSI, SNR, etc.) obtained from the reception of the latest beacon in the same period 21 in the request 35.

[0112] After sending the first association request frame 35', the new first device (e.g., device) 16 may continue to listen for an association response frame from the facility 15.

[0113] If the association response element is not received within a predetermined time limit, the new device 16 may try to associate again by sending association requests 35", 35''', etc. In FIG. 3a, no association response frame has been detected. (Note that in some examples, the association request may also be sent by other devices 16).

[0114] In some examples, the association request 35 (35', 35", etc.) can be an example of the feedback message 32 (see "Association / Reconnection + Feedback" in FIG. 3a). Thus, in some examples, at least some of the features of the feedback 32 may be the same as at least some of the features of the association request 35, and vice versa. Specifically, the association request 35 may be an example of the feedback 32, and vice versa.

[0115] In other examples, the feedback 32b (sent in CFP11b) is separate from the association request 35 and the feedback message 32.

[0116] In summary, a first device (e.g., an optical communication device) (16) can be provided that is configured to receive one or more reference signals and / or beacon signals (11) from one or more optical front-ends (14a…14g). The optical communication device (16) can be configured to determine channel information (31) based on the reception of one or more reference signals and / or beacon signals. The optical communication device (16) can be configured to transmit channel information (32) during a contention access period CAP (11a), and subsequently transmit channel information (32b) in an allocated time slot within the CFP (11b). In response, the GTS 33 and / or the GTS update 33b of the CFP 11b can be allocated to the first device (e.g., a device) by a second device (e.g., a facility) 15.

[0117] Above, the situation where the first device 16 is unknown has been mainly referred to.

[0118] However, when the first device 16 loses its connection (e.g., temporarily, e.g., due to an opaque object being inserted between the first device 16 and, e.g., the front ends 14a…14g of the second device 15), the same situation can occur. Thus, as an alternative or addition to the previous example, the same procedure can be performed by the first device 16 that has lost its connection to the second device 15 and is attempting to reconnect.

[0119] Thus, when the first communication device (16) associates with a second communication device (15) that has transmitted one or more reference signals and / or beacon signals (11), it may transmit channel information (32) or an association request (35) during a contention access period CAP (11a), and / or, the first communication device (16) may transmit channel information (32, 35) during a contention access period CAP (11a) together with a second communication device (15) that has transmitted one or more reference signals and / or beacon signals (11), and / or, when the connection of the first communication device (16) to a second communication device (15) that has transmitted one or more reference signals and / or beacon signals (11) has already been established, it may transmit channel information (32b) It may be possible to establish this.

[0120] The second device (e.g., equipment) 15 can be understood to be on the network side. Thus, "connection", "association", "reconnection", etc. can also be understood as "connection to the network", "association with the network", "reconnection to the network", etc.

[0121] Generally speaking, the second device (e.g., equipment) 15 can recognize (accept) the first communication device 16 when receiving feedback 32 and / or when receiving a connection (or reconnection) request (35).

[0122] Additionally or alternatively, the second device (e.g., equipment) 15 may allocate the GTS in the CFP11b to the first device 16 that has sent the feedback 32, 32b, and / or the connection request 35 (or reconnection).

[0123] Aspect II may, in some examples, be understood to refer to an optical communication device (e.g., a receiver), which is configured to receive one or more reference signals and / or beacon signals from one or more optical front - ends [the plurality of optical front - ends may be connected to each other, e.g., by a wired connection, e.g., Ethernet - based, and adjusted and / or synchronized by, e.g., a regulator], the optical communication device is configured to determine channel information [e.g., CSI] [e.g., associated with the SNR] [e.g., channel estimation, and / or channel measurement] based on the reception of one or more reference signals and / or beacon signals [which may be, e.g., a pilot sequence and / or signal known to or provided with the receiver], the optical communication device is configured to transmit the channel information [e.g., to one or more optical front - ends from which the one or more reference signals and / or beacon signals were received, or to a regulator coupled to one or more transmitters] during a contention access period (CAP) [e.g., during which multiple optical communication devices are allowed to transmit without an allocated (assigned) time slot] [e.g., the communication device may also request an association with a network to which the optical transmitter belongs in the same CAP].

[0124] Aspect II may also be understood to refer to an optical communication method (e.g., in a receiver such as an optical communication device), and this method is In an optical communication device, receiving one or more reference signals and / or beacon signals from one or more optical front-ends [the plurality of optical front-ends can be connected, for example, by a wired connection, can be Ethernet-based, for example, and can be adjusted and / or synchronized with each other by an adjuster], and In an optical communication device, determining channel information [such as CSI] [associated with SNR] [such as channel estimation and / or channel measurement] based on the reception of one or more reference signals and / or beacon signals [which can be, for example, a pilot sequence and / or signal known to the receiver or include the same] and Transmitting, from the optical communication device, the channel information [to, for example, one or more optical front-ends from which one or more reference signals and / or beacon signals are received, or to an adjuster coupled to one or more transmitters] during a contention access period (CAP) [during which multiple optical communication devices are allowed to transmit without an allocated (assigned) time slot] [the device may also require an association with a network to which the optical transmitter belongs in the same CAP].

[0125] Aspect II may be understood to refer to optical communication equipment [e.g., a device with an optical front end for transmitting signals to and / or receiving signals from a communication device], for example, the optical communication equipment may be adjusted by a regulator that can be connected to the front end by a wired network, the optical communication equipment is configured to transmit one or more reference signals and / or beacon signals [e.g., a pilot sequence that may already be known to the receiving communication device] from one or more optical front ends [the plurality of optical front ends may be connected, for example, by a wired connection, may be Ethernet-based, and may be adjusted and / or synchronized with each other by a regulator], and the optical communication equipment is configured to receive channel information during a contention access period (CAP) [e.g., during which multiple optical communication devices are allowed to transmit without an assigned (granted) time slot].

[0126] Aspect II may be understood to refer to an optical communication method (in an optical communication equipment including a plurality of optical front ends), and this method includes a step of transmitting one or more reference signals and / or beacon signals [e.g., a pilot sequence that may already be known to the receiving communication device] from one or more optical front ends [the plurality of optical front ends may be connected, for example, by a wired connection, may be Ethernet-based, and may be adjusted and / or synchronized with each other by a regulator], and a step of receiving channel information during a contention access period (CAP) [e.g., during which multiple optical communication devices are allowed to transmit without an assigned (granted) time slot].

[0127] Aspect III Here, the "device" may be generalized to the "first device (16)", and the "facility" may be generalized to the "second device (15)", and may be done so even if they can be interchanged in a variation. The front end may be an optical front end. The device 16 may be a mobile device. The facility may be fixed, and the front end of the facility may be distributed. The regulator 12 or the central unit may be the intelligent part of the facility.

[0128] The existence of multiple front ends 14a…14g (for example, optical front ends) may cause different front ends 14a…14g to accidentally transmit signals (for example, beacon signal 11) at different moments. This can lead to unwanted errors when transmitting from the facility 15 to the device 16 or from the device 16 to the facility 15. An example is shown in FIG. 1a, and for each transmission 18a, 18b, 18c, there are propagation delays t P1 、t P2 、t P3 and front hole delays t F1 、t F2 、t F3 and front holes 17. This problem is exacerbated by the fact that the device 16 may be movable, which can lead to unpredictable delays for communications from different front ends 14a…14g.

[0129] However, these problems can be alleviated or overcome by using a regulator or central unit 12 configured to command the transmission of reference signals and / or beacon signals (11) to multiple optical front ends (14a…14g), and / or acquire the channel information (32) measured by the optical communication device (16), and / or synchronize the optical front ends (14a - 14g) based on the channel information. It is understood that this can be achieved.

[0130] An example is given here by FIG. 1a. The beacon 11 (or more generally, the reference signal) may include or be associated with a multi-channel estimation symbol. The multi-channel estimation symbol may be different for different front-ends. Different front-ends 14a…14g may relay the beacon 11 by using different symbols. The symbols may be associated with an orthogonal sequence (e.g., for multiple-input / multiple-output (MIMO) of some field of the beacon or of the transmission associated with the beacon). In this regard, each device 16 may measure the delay of the transmissions received from each front-end. Referring to the example of FIG. 1a, the device 16 observes the delay t P1 +t F1 for the beacon version obtained from the front-end 14a, and t P1 +t F1 is the delay t P2 +t F2 observed for the beacon signal as obtained from the front-end 14b, and t P2 +t F2 is greater than the delay t P3 +t F3 of the transmission from the front-end 14c. Since the transmissions from each of the front-ends 14a, 14b, 14c can be recognized (e.g., by using orthogonal sequences or by other means), the device 16 may come to determine the measurement results of the delays.

[0131] Thus, after performing the measurements (which may be the measurement 31 in FIG. 3), the device 16 may transmit a feedback 32 (e.g., CSI feedback and / or SNR feedback, etc.) in which the delays of each of the transmissions 18a~18c from each of the front-ends 14a~14c are provided (e.g., encoded in a specific frame).

[0132] Subsequently, the equipment 15 (and specifically, the regulator or the central unit 12) can synchronize the different front ends 14a…14g such that transmissions from a front end with a relatively large delay (e.g., the front end 14a in FIG. 1a) are transmitted slightly before transmissions executed by a front end with a relatively small delay (e.g., the front end 14c). Generally, in proportion to the observed delay, provisions can be made for transmissions of the front end with a larger delay.

[0133] The operation of the central unit or regulator 12 is discussed here.

[0134] First, the regulator 12 can execute the transmission of a reference signal (e.g., a beacon) 11 to all the front ends 14a…14c through the front hole 17. For the initial transmission, an initial coarse synchronization can be executed by using, for example, PTP (e.g., precision time protocol IEEE1588 V2) or another Internet-based protocol.

[0135] The optical front ends 14a…14c can relay a coarsely synchronized reference signal and / or beacon signal as obtained from the front hole 17. Thus, different beacon versions can be transmitted along different channels 18a…18c.

[0136] The device 16 (and / or any of the other devices that may be transmitting and / or receiving signals with the communication equipment 15) can measure the delay that impairs each of the received beacon versions passing through the different channels 18a…18c (e.g., at 31).

[0137] Thus, the device 16 transmits a feedback 32 including channel state information for each of the channels associated with the front ends 14a, 14b, 14c, respectively, based on, for example, the measurements 31 executed.

[0138] The regulator 12 may receive CSI information encoded in the feedback 32 through the front ends 14a, 14b, 14c, and the backhaul 17. Thus, the regulator 12 knows the delay that has impaired each beacon conversion from the regulator 12, through the front hole 17, the optical front ends 14a, 14b, 14c, and the channels 18a, 18b, 18c, to the device 16. The regulator 12 may also utilize its own clock for verification of the delay as measured by the device 16 (the delay t F1 +t P1 when measured by the device 16, t F3 +t P3 is greater, so the same applies to the reverse delay).

[0139] Aspect III, in some examples,[[]] commands the transmission of a reference signal and / or a beacon signal (11) to a plurality of optical front ends (14a - 14g), obtains channel information (32) measured by an optical communication device (16) (e.g., a receiver and / or a mobile device) [e.g., channel information relayed by the front ends (14a - 14g)], and synchronizes the optical front ends (14a - 14g) based on the channel information [e.g., by delaying the slow front ends (14a - 14g)]. It may be understood to refer to a central unit (12) [e.g., operating as a regulator] [e.g., a device for commanding transmission to and / or reception from a plurality of optical front ends (14a - 14g)] configured as such.

[0140] Aspect III may also be understood to refer to an optical communication facility [e.g., a regulator] for transmitting and / or receiving through a plurality of optical front ends (14a - 14g), and the optical communication facility transmits a reference signal and / or a beacon signal to one or more communication devices [e.g., an optical receiver] through the optical front ends (14a - 14g), Obtain the channel information measured by the optical communication device (16) [the channel information relayed by the front ends (14a - 14g)], Based on the channel information, synchronize the optical front ends (14a - 14g) [for example, by delaying the slow front ends (14a - 14g)]. It is configured as follows.

[0141] [Optionally, the initial coarse synchronization can be performed by a central unit for the optical front ends (14a - 14g) by a protocol such as PTP or another Ethernet - based protocol.]

[0142] [In an example, the facility may include a central unit.]

[0143] Aspect III can also be understood to refer to communication facilities as described above and at least one optical communication device (16).

[0144] Aspect III can also be understood to refer to a method [for example, in a regulator and / or device for instructing transmission to and / or reception from a plurality of optical front ends (14a - 14g)], and this method includes the steps of instructing the transmission of a reference signal and / or beacon to a plurality of optical front ends (14a - 14g), obtaining the channel information measured by the optical communication device (16) (for example, a receiver and / or a mobile device) [for example, the channel information relayed by the front ends (14a - 14g)], and synchronizing the optical front ends (14a - 14g) based on the channel information [for example, by delaying the slow front ends (14a - 14g)]. and includes.

[0145] Aspect III may also be understood to refer to an optical communication method [e.g., an adjuster] for transmitting and / or receiving through a plurality of optical front-ends (14a - 14g). The optical communication method comprises transmitting a reference signal and / or a beacon signal to one or more communication devices [e.g., an optical receiver] through the optical front-ends (14a - 14g), acquiring channel information [channel information relayed by the front-ends (14a - 14g)] measured by the optical communication device (16), synchronizing the optical front-ends (14a - 14g) based on the channel information [e.g., by delaying a slow front-end (14a - 14g)], and

[0146] [Optionally, an initial coarse synchronization may be performed by a central unit for the optical front-ends (14a - 14g) by means of a protocol such as, for example, PTP or another Ethernet-based protocol]

[0147] References: 1 L. Cosart, "Precision Packet Delay Measurements Using IEEE 1588v2", 2007 IEEE Int. Symp. on Precision Clock Synchronization for Measurement, Control and Communication, Vienna, 2007, pp.85 - 91 2 R. L. Scheiterer, C. Na, D. Obradovic, G. Steindl, F.-J. Goetz, "Synchronization Performance of the Precision Time Protocol in the Face of Slave Clock Frequency Drift", 4th IEEE Conference on Automation Science and Engineering, Key Bridge Marriott, Washington DC, USA, August 23 - 26, 2008

[0148] Aspect IV Here, "device" may be generalized to "first device (16)", and "facility" may be generalized to "second device (15)", and may be so even if they can be interchanged in a variation. The front end can be an optical front end. Device 16 can be a mobile device. The facility may be fixed, and the front end of the facility may be distributed. The regulator 12 or the central unit can be the intelligent part of the facility.

[0149] In the following, for example, techniques for providing channel state information (CSI) from device 16 (16', 16", A, B, C, D) to facility 15 (and specifically to regulator 12) are discussed. This technique is, in some examples, compatible with any of the above aspects I, II, III.

[0150] For example, CSI (encoded in one feedback message such as 32 or 32b or 35) can be obtained by device 16 by performing measurement 31 on beacon 11 (or more generally a reference signal). The beacon or reference signal 11 can represent a pre - established pilot sequence whose received version (as received by device 16) can undergo measurement 31. In some examples, measurement 31 can contribute to obtaining a signal (such as an impulse response) that is compared (e.g., by conditioner 12) with a stored signal (such as a stored version of the impulse response) to determine the quality of beacon 11 (and as a result, channel 18). In some examples, CSI can be measured for each version of beacon 11 as received from each front - end 14a…14g (e.g., device 16 may have the ability to distinguish different simultaneous versions of beacon 11, and different front - ends 14a…14g may have the ability to relay different versions of beacon 11 simultaneously by using different sequences, such as orthogonal sequences). CSI as measured can be provided to facility 15, for example, as part of feedback message 32 of FIG. 3 (or as part of another feedback message transmitted by device 16 to facility 15).

[0151] Accordingly, conditioner or central unit 12 may know CSI as measured by each device 16 and may use this information for performing scheduling. For example, conditioner 12 can reconstruct the impulse response of beacon 11 as received and based thereon determine the quality of channel 18.

[0152] The adjuster 12 may obtain CSI for each of the plurality of front - ends 14a…14g from a plurality of devices 16 (e.g., 16', 16", A, C, C, D, etc.), and the adjuster 12 may obtain knowledge of the quality of each channel 18a…18g for each device 16 and each front - end 14a…14g. Referring to the example of FIG. 1, the CSI measured by the device 16' for the channels 18a…18c associated with the front - ends 14a…14c is likely to indicate better channel conditions than the CSI measured by the same device 16' for the channels associated with the front - ends 14d…14g (as a result of the long distance, it is even possible that the device 16' does not even recognize the beacon conversion 11 from some of the front - ends 14d…14g). Thus, when the adjuster 12 obtains the feedback message 32 or 32b or 35, the adjuster 12 preferably allocates the super - frame slots of the front - ends 14a…14c to the device 16' (and similarly, the super - frame slots of the front - ends 14d…14g to the device 16").

[0153] Broadly speaking, to provide the measured CSI, the device 16 may transmit a feedback message 32 or 32b or 35 that encodes a high - resolution copy of the beacon 11 as received, for example, for each sample. However, this solution requires too much payload since all samples of all received versions of the beacon signal 11 must be encoded and sent to the facility 15.

[0154] Nevertheless, it is understood that the device 16 can compress information such as CSI and present the CSI in a compressed format. For example, if the CSI is measured in the frequency domain (FD), the device 16 may convert the CSI from the FD to the time domain (TD) to obtain the TD CSI, encode the TD CSI, and Transmit TD CSI (such as feedback message 32 or 32b or 35) to one or more front-ends 14a…14g so that the one or more front-ends 14a…14g relay the TD CSI to the regulator 12 at least one of which may be performed.

[0155] FIG. 4 shows an example of a unit 400 (which may be part of device 16) for measuring and / or encoding an example of CSI. FIG. 4a shows an example of a data packet 450 for encoding CSI. The data packet 450 may be, or may be part of, an example of feedback message 32 of FIG. 3 (or 32b of FIG. 3b or 35 of FIG. 3a).

[0156] Device 16 may receive some versions of beacon 11 from different front-ends 14a…14g through respective channels 18a…18g.

[0157] Device 16 may measure FD CSI for the pilot signal of beacon 11 (or another type of reference message transmitted from the facility to device 16).

[0158] In block 404, device 16 may perform a clustered channel estimation to obtain a version 406 of the channels measured from beacon 11, such as obtained from each of the plurality of front - ends 14a…14g. Thus, different versions 406 (also shown using H) of beacon 11 received from different front - ends 14a…14g may be obtained. In some examples, only a portion of the versions of beacon 11 are actually measured by each device 16. CSI is not provided for versions of beacon 11 that are not received (e.g., because there is an obstacle blocking channel 18 or it is too far away), and these versions of beacon 11 may also be impossible to recognize (e.g., due to an excessive number of errors) or may be recognized as invalid (e.g., because the power is too low, i.e., below a minimum threshold). Referring to FIG. 1, it may be recalled that device 16' only starts measuring CSI for channels 18a, 18b, 18c, while device 16" only starts measuring CSI for channels 18e, 18f, 18g. Thus, only some versions of beacon 11 may be measured by each device 16.

[0159] In block 408, device 16 may perform a conversion from FD to TD. For example, an inverse discrete Fourier transform (IDFT) may be applied. Thus, a TD version 410 (also denoted as h) of the CSI for each version of the remaining versions of beacon 11 is obtained.

[0160] For each of the remaining channels, in block 412, by using an expression regarding taps, it is possible to re - divide the TD expression of each beacon conversion (such as received from a specific front - end). Thus, each TD signal 410 can be represented as a sequence of taps. Each tap can be understood as a specific sample value or a sequence of sample values in the time domain of the impulse response. Instead of providing each signal 410 sample - by - sample, device 16 can encode, in feedback signal 410 (e.g., 32 or 32b or 35), a value associated with the amplitude (such as at least one of intensity, power, energy, etc.) and / or the delay of the taps in the impulse response as received.

[0161] In an example, only the most important taps 414 (e.g., those with the largest amplitude and / or intensity and / or power and / or energy) may be selected, while the remaining taps may be discarded. In an example, non - zero taps are selected, while zero taps (or taps with negligible amplitude) are discarded. To decide whether to select or discard a tap, the amplitude (or intensity or energy or power) can be compared with a specific threshold 470. Thus, only the most important taps (non - zero taps) are selected (the threshold 470 may be a threshold depending on interference, and / or may be dynamically defined in block 471 based on feedback 474 such as, for example, a geometric factor G472, and / or delay and / or intensity values as obtained by unit 400).

[0162] Then, in block 416, quantization can be performed on the most important taps 414. For example, a quantization step Δ and / or the number of quantization bits B (or β) can be defined. By using quantization, compression can be obtained to provide a quantized signal that appropriately describes the taps.

[0163] Subsequently, the values of the amplitudes (or intensities or energies or powers, etc.) of each of the selected taps and / or their delays can be encoded in the feedback message 450 (32 or 32b or 35) and provided to the facility 15 (e.g., to the regulator 12 through the front end 14 and the front hall 17).

[0164] An example of the operation of the device 16 (e.g., by the unit 400) is discussed here.

[0165] First, the device 16 (e.g., 16', 16", A, B, C, D, etc.) can receive multiple beacon versions of the beacon 11 from multiple front ends 14a...14g through multiple channels 18a...18g. Generally, not all beacon versions are necessarily received or recognized by the device 16, and subsequent steps refer only to the recognized beacon versions (e.g., beacons from distant front ends are not received, or are so noisy that they are not recognized or discarded).

[0166] Then, only some of the received or recognized channels can be selected (e.g., by the block 404). This selection can be performed based on the measurement 31, for example, based on a comparison of the power or intensity measurements made on the beacon signals received from each front end. Thus, a clustered channel estimation can be performed.

[0167] Next, the most important taps can be selected (e.g., by the block 412), for example, by comparing their amplitudes, intensities, powers, energies, etc. with the threshold 470.

[0168] Next, the selected taps can be quantized (e.g., by the block 416).

[0169] Next, the quantized information about the delay and / or intensity (e.g., amplitude, energy, power, etc.) of the selected tap can be encoded (e.g., as feedback messages 32, 32b, 35, 450, etc.) and sent to the regulator 12 (e.g., through front ends 14a…14g).

[0170] FIG. 4a shows an example of a feedback message 450 (e.g., feedback 32, 32b, 35, etc.) that encodes CSI to be provided to the regulator 12. The number 451 refers to the amount of bits that can be (there can be different amounts). A part of the field that can be encoded (even in a different order) is discussed below.

[0171] The number 452 refers to the index of a particular front end as recognized. Thus, the regulator 12 knows that the CSI refers to a beacon conversion as received from a particular front end.

[0172] The number 454 refers to the step size (quantization step Δ).

[0173] The number 456 refers to the number of quantization bits (B or β).

[0174] The number 458 refers to delay information. Specifically, a delay vector can be provided. The delay vector can be a delay vector bitmap. Each nth position in the delay vector bitmap can be made to correspond to the nth tap. Thus, the delay vector bitmap can indicate whether the nth tap in the received pilot sequence is one of the selected taps (the most important tap) for which its intensity and / or delay is shown. The delay vector bitmap can be 1 (or 0 in other examples) when corresponding to a selected tap (non-zero tap), for example, based on the result of a selection as performed in block 412, and 0 (or 1 in other cases) when corresponding to an unselected tap (zero tap).

[0175] The number 460 (tap descriptor) refers to the quantized information about the strength and / or delay of each of the selected (non-zero) taps. For each of the selected taps as shown in the delay vector, indications ( "tap descriptor elements") about strengths (or amplitudes, powers, energies) 461', 461", 461''', etc., and / or delay information 462', 462", 462''', etc., can be provided.

[0176] In the example, the bit length of the field 460 is not predetermined. This is because it is not determined in advance how many taps will be described in the message 450(32).

[0177] In view of the above, the regulator 12 obtains a feedback message 32 including channel information, comprises a string (e.g., bitmap 458) of a second value (e.g., "1") and a first value (e.g., "0") each associated with a time-domain representation of the CSI, for each second value ("1") in the string (458), comprises an encoded value of the amplitude of the time-domain representation at a particular sample (e.g., strength 461 and / or delay 462), for each first value ("0") in the string (458), does not comprise a sample value that is encoded and considered to be 0 receiving the CSI (32) encoded as such, and reconstructing the CSI based on the sample values (461) associated with the second value at least one of which can be executed.

[0178] According to this procedure, the regulator 12 can perform scheduling.

[0179] In an example, each CSI is obtained from each of a plurality of devices 16, and each CSI from each device 16 refers to a particular beacon conversion 11 that is relayed from a respective particular front end among the selected channels (e.g., selected by block 404).

[0180] Accordingly, the adjuster 12 can appropriately assign front ends such that front ends are preferably assigned to devices for which the quality of the beacon conversion received from the front ends is good.

[0181] In the example of FIG. 4, it is shown that delay information is provided as both a delay vector 458 and an encoded delay field 462. However, this is not strictly essential, and in some examples, either the delay vector 458 or the encoded delay field 462 may be missing, thereby reducing the amount of bits.

[0182] Aspect IV may be related to an optical communication device (16) for communication with optical communication equipment, and the optical communication device obtains channel state information (e.g., CSI) from the reception of one or more reference signals and / or beacon signals [e.g., pilot signals and / or sequences] from one or more optical front ends (14a... 14g) [e.g., from the frequency domain], [e.g., such that a plurality of real-valued or complex-valued channel state values are associated with different frequency ranges], converts the channel state information from the frequency domain to the time domain [using a large number of taps and / or a large number of samples] to obtain time domain channel state information [e.g., thereby reconstructing the channel impulse response], encodes the time domain channel state information, and transmits the time domain channel state information to one or more optical transmitters is configured to be.

[0183] Aspect IV may also be related to optical communication equipment for communication with an optical communication device (16), the optical communication equipment comprises a string of values of "1" and values of "0" (or other symbols) each associated with a time-domain representation of CSI for each "1" value in the string [e.g., associated with a strong signal], comprises an encoded value of the amplitude of the time-domain representation at a particular sample [tap] for each "0" value [e.g., associated with a weak signal], is encoded and does not comprise a sample value regarded as 0 receives CSI encoded in such a manner reconstructs CSI based on sample values [taps] associated with a value of 1 and is configured in such a manner.

[0184] [In the example, based on a threshold, only the signals of the strongest front ends (14a…14g) are selected for feedback generation.]

[0185] Aspect IV may also be related to an optical communication method for communication of an optical communication device (16) with optical communication equipment, the optical communication method obtaining [e.g., from the frequency domain] channel state information (e.g., CSI) from reception of one or more reference signals and / or beacon signals [e.g., pilot signals and / or sequences] from one or more optical front ends (14a…14g) [e.g., such that a plurality of real or complex channel state values are associated with different frequency ranges] converting channel state information from the frequency domain to the time domain using a large number of taps and / or a large number of samples to obtain time-domain channel state information [e.g., thereby reconstructing the channel impulse response] encoding the time-domain channel state information and transmitting the time-domain channel state information to one or more optical front ends (14a…14g) (e.g., an optical transceiver) and includes.

[0186] Aspect IV may also be related to an optical communication method for communication between optical communication equipment and an optical communication device (16), the optical communication method comprising: receiving a Channel State Information (CSI) encoded such that it has a string of values of "1" and "0" each associated with a time-domain representation of the CSI, for each value of "1" in the string, having an encoded value of the amplitude of the time-domain representation at a specific sample [tap], and for each value of "0", having a sample value that is encoded and considered to be zero, reconstructing the CSI based on the sample values [taps] associated with the value of "1". Aspect IV may be understood as referring to an optical communication device for communication with optical communication equipment, the optical communication device being configured to:

[0187] obtain channel state information (e.g., CSI) from reception of one or more reference signals and / or beacon signals (e.g., pilot signals and / or sequences) from one or more optical front-ends [such that a plurality of real or complex channel state values are associated with different frequency ranges], convert the channel state information from the frequency domain to the time domain [using a number of taps and / or a number of samples] to obtain time-domain channel state information [e.g., thereby reconstructing the channel impulse response], encode the time-domain channel state information, and transmit the time-domain channel state information to one or more optical transmitters.

[0188] Aspect IV may be understood as referring to optical communication equipment for communication with an optical communication device, the optical communication equipment comprising a string of values of "1" and "0" (or other symbols) each associated with a time-domain representation of the CSI, ​ For each “1” value in a string [associated with, for example, a strong signal], having an encoded value of the amplitude of the time-domain representation at a particular sample [tap], For each “0” value [associated with, for example, a weak signal], being encoded and having no sample value regarded as zero receiving CSI encoded in such a way, reconstructing CSI based on the sample values [taps] associated with the value of 1 is configured to be.

[0189] [In the example, based on a threshold, only the strongest front-end signal is selected for feedback generation.]

[0190] Aspect IV may also be understood as referring to an optical communication method for communication of an optical communication device with an optical communication facility, the optical communication method comprising obtaining (for example, in the frequency domain) channel state information (for example, CSI) from reception of one or more reference signals and / or beacon signals (for example, pilot signals and / or sequences) from one or more optical front-ends such that [for example, a plurality of real or complex channel state values are associated with different frequency ranges], converting channel state information from the frequency domain to the time domain using a large number of taps and / or a large number of samples to obtain time-domain channel state information [for example, thereby reconstructing the channel impulse response], encoding the time-domain channel state information, transmitting the time-domain channel state information to one or more optical front-ends (for example, an optical transceiver) and including.

[0191] Aspect IV may also be understood as referring to an optical communication method for communication between an optical communication facility and an optical communication device, the optical communication method comprising Comprising strings of values of "1" and "0" respectively associated with the time-domain representation of CSI, For each "1" value in the string, having an encoded value of the amplitude of the time-domain representation at a specific sample [tap], For each "0" value, having a sample value that is encoded and considered not to be zero Receiving CSI encoded as such, Reconstructing the CSI based on the sample values [taps] associated with the "1" values and comprising.

[0192] Aspect V Here, "device" may be generalized to "first device (16)", "facility" may be generalized to "second device (15)", and they may be so generalized even if they can be interchanged in a variation. The front end may be an optical front end. Device 16 may be a mobile device. The facility may be fixed, and the front end of the facility may be distributed. The regulator 12 or the central unit may be an intelligent part of the facility.

[0193] Changes to Aspect IV are discussed here.

[0194] Here, Receiving a plurality of (e.g., simultaneous) reference signals (e.g., beacons) 11 from a plurality of [e.g., optical] front ends [e.g., OFE] 14a...14g, and / or Obtaining channel state information (CSI) (e.g., after measurement 31) based on the evaluation of the received reference signal 11, Encoding the CSI to provide an encoded CSI, Providing [e.g., signal] information [e.g., TAP format] describing the selection of the encoding resolution used to encode the CSI from among a plurality of possible encoding resolutions Reference is made in particular to a first device 16 which may be, for example, a transmitter, for example a mobile device, for example an optical transmitter, configured as such.

[0195] The CSI may be encoded, for example, as in FIG. 4 and / or FIG. 4a (for example, in particular as in fields 461 and / or 462).

[0196] Here, the CSI may be intended to be a feedback message (for example, 32, 32b, 35, 450, 450b, etc.) containing information about the channel.

[0197] It is understood that each first device 16 can transmit CSI by using a specific format. An example is given by the following table.

[0198]

Table 1

[0199] At least one of these formats can be used (other formats can be used).

[0200] In the CSI or feedback message (for example, 32, 32b, 35, 450, 450b, etc.), the following fields Field 901: The number N of recognized front ends Field 902: TAP format Field 920: Front end feedback descriptor elements 1... N (the same number as indicated in field 901) can be at least one of them.

[0201] Each field 920 (front end feedback descriptor element) Field 921: The number of pilot symbols associated with the time position of the pilot sequence Field 922: Pilot splitting (e.g., Hadamard code, sub-carrier separation, etc.) Field 923: Number of taps indicating how many taps are described later Field 460b: Tap descriptor (providing information about each described tap) may include at least one of them.

[0202] Each field 460b (for describing one particular tap) is Field 461b (tap strength or amplitude or power or energy) Field 462b (tap delay) may include at least one of them.

[0203] In fields 461b and 462, it is understood that it is possible to encode the quantity with a determined resolution, for example in units of dBm or ps or ns (picoseconds or nanoseconds). For example, to describe the strength of a tap, in some cases, a particular resolution with a step of 0.15 dBm is preferred, while in some other cases, a particular resolution with a step of 2 dBm is preferred. For similar reasons, it may be preferred to use a resolution of 30 ps to describe the delay, but in other cases, it may be preferred to use a resolution of 4 ns. In some cases, a reference value (e.g., "0 value", offset, etc.) may be given. In some cases, it is preferred to use 8 bits to encode fields 461b and / or 462b, while in some cases 4 bits are sufficient, and in other cases 10 bits are required.

[0204] Thus, various formats can be used. Each first device 16 can select a format (e.g., coding resolution) and signal the format in field 902. Thus, when the second device 15 decodes fields 461b and / or 462b, the second device 15 can obtain feedback measurement results with the required accuracy and high compression ratio.

[0205] It is understood that different configurations for fields 461b and / or 462b may be grouped together. The first device 16 can utilize the selection of coding resolution, which may be combined with each other for each selection. Different codes in field 902 can be associated with different sections that each combine configuration data for describing taps. Field 902 can encode an index pointing to all configuration data of the selected coding resolution. For example, as follows.

[0206] [Table 2]

[0207] For each format of field 461b, Number of bits 931 Reference value 932 Step 933 At least one of can be defined.

[0208] For each format of field 462b, Number of bits 941 Reference value 942 Step 943 At least one of can be defined.

[0209] Therefore, the first device 16 may select the most preferred resolution (format) based on the acquired measurement results and encode the CSI according to the selected most preferred resolution. Accordingly, fields 461b and 462 are quantized to provide good resolution and accuracy and high compression.

[0210] Note that in some examples, the information describing the selection of the encoding resolution may include the formats of the fields encoding the amplitudes and / or intensities and / or delays of the plurality of propagation paths, and / or the values associated therewith.

[0211] The second device 15 (e.g., a regulator) receives the encoded channel state information (CSI) (e.g., the message encoded as feedback messages 32, 32b, 35, or 450, 450b), receives information (902) describing the selection of the encoding resolution used to encode the CSI (32, 32b, 35, 450, 450b) from among a plurality of possible encoding resolutions, decodes the encoded CSI (32, 32b, 35, 450, 450b) according to the information (902) describing the selection of the encoding resolution used to encode the CSI. At least one of the above may be performed.

[0212] The second device 15 may perform scheduling based on feedback information as obtained from the CSI.

[0213] In the above example, some aspects relate to a device [e.g., a transmitter, e.g., a mobile device, e.g., an optical transmitter], which receives a plurality of reference signals from a plurality of [e.g., optical] front ends [e.g., OFE], acquires channel state information (CSI) based on an evaluation of the received reference signals, encodes the CSI to provide the encoded CSI, and / or Providing [e.g., signaling] information [e.g., in a TAP format] that describes the selection of the encoding resolution used to encode CSI from among a plurality of possible encoding resolutions is configured as follows.

[0214] The device may be further configured such that the format of the fields encoding the strength and / or delay of the plurality of propagation paths, and / or the values associated therewith, includes information [e.g., in a TAP format] that describes the selection of the encoding resolution.

[0215] The device may be further configured such that the CSI includes or is associated with reference signal identification information, and / or the information [e.g., in a TAP format] that describes the selection of the encoding resolution is associated with the reference signal identification information.

[0216] The device may be further configured such that the information describing the encoding resolution defines the number of bits used to encode the tap strength and / or the number of bits used to encode the tap delay.

[0217] The device may be further configured such that the information describing the encoding resolution defines the step size [e.g., 0.15 dBm or 30 ps] of the tap strength and / or delay.

[0218] The device may be further configured such that the information describing the encoding resolution defines a reference value [e.g., a "0 value"] for the tap strength and / or delay.

[0219] The device may be further configured to find [an appropriate] resolution [for quantization] based on the acquired CSI value.

[0220] The device may be further configured to select a resolution based on the rounded and quantized value of the CSI.

[0221] The device may be further configured such that the CSI comprises the strength of the received reference signal [or a plurality of versions of the reference signal moving via different propagation paths and / or arriving at the device at different times], or a value associated therewith.

[0222] The device may be further configured such that the CSI comprises the delay of the received reference signal [or the delay between a plurality of versions of the reference signal moving via different propagation paths and / or arriving at the device at different times], or a value associated therewith.

[0223] The device may be further configured such that the CSI comprises an indication of the reference signal [e.g., the fields "pilot symbol number" and / or "split"].

[0224] The device may be further configured such that the device is or includes a network conditioner.

[0225] The device may be further configured such that the information describing the selection of the coding resolution [e.g., TAP format] includes a format that follows at least one of the following formats [for either or both of "strength" or "delay"].

[0226] [Table 3]

[0227] In the above example, some aspects relate to a method [e.g., performed by a transmitter, a mobile device, an optical transmitter, according to any of the above and / or below examples], the method comprising: receiving a plurality of reference signals from a plurality of [e.g., optical] front ends [e.g., OFE]; obtaining channel state information (CSI) based on an evaluation of the received reference signals; To provide symbolized CSI, the steps of encoding CSI and / or providing [e.g., signal] information [e.g., TAP format] that describes the selection of an encoding resolution used to encode CSI from among a plurality of possible encoding resolutions including.

[0228] In the above example, some aspects receive encoded channel state information (CSI), receive [e.g., signal] information [e.g., TAP format] that describes the selection of an encoding resolution used to encode CSI from among a plurality of possible encoding resolutions, decode the encoded CSI according to the information [e.g., TAP format] that describes the selection of the encoding resolution used to encode CSI relate to a device [e.g., receiver, e.g., device, e.g., optical receiver] configured to.

[0229] The device may be further configured such that the device includes a plurality of [e.g., optical front ends] and is configured to transmit a reference signal thereto.

[0230] The device may be further configured such that the device is or includes a network conditioner [e.g., according to any of the above and / or below examples].

[0231] The device may be further configured to decode the strength and / or delay of a plurality of propagation paths from the CSI according to the tap format indicated in the information [e.g., TAP format] that describes the selection of the encoding resolution.

[0232] The device may be further configured such that the CSI includes or is associated with reference signal identification information, and / or the information [e.g., TAP format] that describes the selection of the encoding resolution is associated with the reference signal identification information.

[0233] The device may be further configured such that the information describing the encoding resolution defines the number of bits or associated value used to encode the "tap strength" and / or the number of bits or associated value used to encode the tap "delay".

[0234] The device may be further configured such that the information describing the encoding resolution defines the step size [e.g., 0.15 dBm or 30 ps] of the tap strength and / or delay, or values associated therewith.

[0235] The device may be further configured such that the information describing the encoding resolution defines the reference value ("0 value") of the tap strength and / or delay, or values associated therewith.

[0236] The device may be further configured such that the CSI comprises the strength of the received reference signal [or multiple versions of the reference signal traveling via different propagation paths and / or arriving at the device at different times], or a value associated therewith.

[0237] The device may be further configured such that the CSI comprises the delay of the received reference signal [or the delay between multiple versions of the reference signal traveling via different propagation paths and / or arriving at the device at different times], or a value associated therewith.

[0238] The device may be further configured such that the CSI comprises an indication of the reference signal [e.g., the field "pilot symbol number" and / or "split"].

[0239] The device can be further configured such that the information describing the selection of the coding resolution [e.g., TAP format] follows at least one of the following formats for [either or both of "intensity" or "delay"].

[0240]

Table 4

[0241] In the above example, some aspects relate to a device according to any of the above and / or below examples and a system comprising a device according to any of the above and / or below examples.

[0242] In the above example, some aspects are receiving encoded channel state information (CSI); receiving [e.g., signal] information [e.g., TAP format] describing the selection of the coding resolution used to code the CSI from among a plurality of possible coding resolutions; decoding the encoded CSI according to the information [e.g., TAP format] describing the selection of the coding resolution used to code the CSI and relate to a method [e.g., performed by a receiver, a device, an optical receiver, and / or a device according to any of the above and / or below examples].

[0243] Aspect VI Refer to FIG. 8d. A beacon 11 (such as may be retransmitted by each of the front ends 14a... 14g) is acquired by a first communication device (such as device 16) (such as 16', 16", A, B, C, D), which may be an optical device (such as a mobile device). The first communication device 16 may measure the beacon 11 (or a different signal from the front ends 14a... 14g) at 32. The first communication device (such as device) 16 may then transmit feedback 32 (channel state information (CSI)), which indicates the state of each of the channels 18a... 18g derived from the measurement results (for example, the stronger the intensity or the fewer the detection errors, the better the channel). The second communication device (such as a facility, such as a fixed facility) 15 may then define a scheduling 20. Subsequently, the facility 15 may transmit a scheduling message 33 (which may be the same as message 33 in FIG. 3 or message 33b in FIG. 4b in some examples), in which the scheduling 20 is defined (and some superframe slots or GTSs are allocated to each of the first devices 16', 16", A, B, C, D, etc.).

[0244] Note that even with high-performance real-time scheduling techniques, the conditions of the links 18a... 18g change significantly over time. In some cases, some specific frequency (such as a subcarrier) is preferred, while in other cases, a different subcarrier may be preferred. Note that these phenomena are generally not easily defined deterministically or a priori.

[0245] To address these issues, it is understood that at least one mobile device 16 (e.g., 16', 16", A, B, C, D) can request some specific subcarriers (and more generally, some specific communication configurations) by relying on measurements performed on signals received from, for example, the front end 14. For example, the measurements can be performed on the beacon 11. (In some examples, it is not strictly necessary for the measurements to be performed on the beacon 11. In other examples, other signals can be measured. It may be preferred that the measured signal is a signal transmitted simultaneously by all front ends, which favors the measurements on the beacon 11. In the following, while it remains understood that any other signal transmitted by the front ends 14a…14g, e.g., any signal transmitted simultaneously by the front ends, can be used to perform the measurements, for clarity, reference is made to the beacon 11.) The beacon signal 11 to be measured can present a pilot sequence that can be detected by each mobile device 16. The beacon signal 11 can include a sequence of different frequencies (subcarriers). Each device 16 can determine which are the preferred frequencies (subcarriers), for example, for UL and / or DL, based on the measurements performed on the beacon signal 11, in particular, based on the measurements performed on the different subcarriers of the beacon signal. The mobile device 16 can perform this determination for each front end 14a…14g from which the beacon signal is then decoded.

[0246] Signaling the preferred subcarriers (and the selection of the frequencies to be used) is generally not an easy task. The indication of the preferred subcarriers has to be signaled quickly from a first communication device (e.g., a device or a mobile device) 16 to a second communication device (e.g., a facility) 15 and is also susceptible to communication errors. For example, even if a particular first communication device 16 indicates a preferred subcarrier, the second communication device 15 may fail to receive this communication and thus may continue to transmit using a previous subcarrier that is no longer desirable for the first communication device 16. Furthermore, it is generally difficult for the first communication device 16 to notify the facility 12 of the agreement within the time limit, because the positive response signal takes time and this is also accompanied by an increase in the time delay.

[0247] It is understood that it is possible to define a bit allocation table (BAT) that defines various possible configurations (e.g., frequencies, number of bits for subcarriers, etc.) and identifies them quickly and easily. In the example, the BAT can be regarded as a table showing the configuration data for enabling the transmission of data between the second communication device 15 and the first communication device 16. Information about the BAT can be maintained by each of the second communication device 15 (e.g., the regulator 12) and the first communication device 16. Thus, the second communication device 15 and the first communication device 16 can communicate with each other to share information about the BAT. Thus, a plurality of active BATs may be defined, each of which may refer to a different frequency to be used in communication, and each communication is executed after selecting one of the active BATs.

[0248] FIG. 8a shows a list 50 showing a plurality of BATs 51-0, 51-1... 51-22, 51-23. Here, there are 24 BATs, but different numbers may be selected in other examples.

[0249] List 50 may contain a plurality of records each associated with a BAT. For each BAT, an identifier may be selected (which here is a number from 0 to 23). Number 52 refers to a column of a list of fields that each stores the identifier associated with a particular BAT. However, in a later part, the same number 52 may also be used to indicate the identifier associated with a particular BAT.

[0250] For each BAT, validity information may be provided. In some examples, the validity information may be encoded in the fields of message 61. (Number 53 refers to an example of a list of fields that each stores the validity information associated with a particular BAT. However, in a later part, the same number 53 may also be used to indicate the validity information associated with a particular BAT.) A valid BAT may be one of the selectable BATs, but an invalid BAT (e.g., 51-1, 51-22, 51-23) cannot be selected (at least until a subsequent update). The validity information 53 may include information about the BATs that can be used by the second communication device 15 to send data to the first communication device 16. (It may also be possible to know the invalid BATs from the validity information 53. In some examples, the validity BAT information 53 may include explicit information about the invalid BATs.) The validity information may be binary information for each BAT.

[0251] For each BAT, update BAT information may be provided. (Number 54 refers to a column of a list of fields that each stores the update BAT information associated with a particular BAT. However, in a later part, the same number 54 may also be used to indicate the update BAT information associated with a particular BAT.) The update BAT information 54 may include, for example, information about whether a particular BAT is a BAT to be updated. For example, BAT51-1 is the last BAT to be updated, but BAT51-0, 51-22, and 51-23 are not BATs to be updated. (The BATs to be updated may generally be invalid BATs.) In some examples, only one BAT is updated each time.

[0252] BAT update information can be provided for each BAT. (Reference is made to column 55 of the list of fields, each of which stores BAT update information associated with a particular BAT. However, in a later part, the same number 55 can also be used to indicate BAT update information associated with a particular BAT.) The BAT update information can include, in particular, subcarriers to be used for communication, forward error correction (FEC) information such as FEC block size and / or FEC code rate, and / or other information for characterizing communication according to a particular BAT. The BAT update information can be indexed. Each subcarrier can be associated with a particular index that can be stored in the BAT update information. The same can apply to FEC information and / or other possible information that can be part of the BAT update information.

[0253] List 50 can be stored in different instances of the storage units of each mobile device 16 and regulator 12. List 50 with all BATs 51-0…51-23 can be updated on-the-fly based on channel conditions (e.g., conditions of optical links 18a…18g). Thus, a copy of list 50 is stored in both regulator 12 and each mobile device 16. In regulator 12, an instance of list 50 is stored with reference to each mobile device 16, but note that each mobile device 16 can have only one single list 50. Other solutions are possible.

[0254] List 50 can be associated with a channel as if it were due to multiple optical front-ends. Thus, the channel is associated with the device (16' or 16") and not with a particular link (e.g., not associated with link 18a from front-end 14 to device 16, but associated with the global channel formed by links 18a, 18b, and 18c experienced by device 16'). In general, different front-ends 16a…16g can be associated with the same list 50.

[0255] In an example, the first device 16 may transmit a BAT message 61 as shown, for example, in FIG. 8. The BAT message 61 includes a validity information field 53 indicating a valid BAT from among a plurality of BATs 51-0 to 51-23 in a list 50, for example an updated BAT information field 54, for example, the currently updated BAT (for example, the currently updated BAT, which is 51-1 in this case) a BAT update information field 55, which may inform whether to update the BAT and / or whether to configure communication subsequently (for example, in the DL from the BS 15 to the mobile device 16) and may include at least one of.

[0256] The transmission of the BAT message 61 from the first device 16 to the second device 15 may cause a change in the list 50 in the second device 15 (whereas the instance of the list 50 in the first device 16 has already been updated prior to the transmission of the BAT message 61).

[0257] The first device 16 may have the freedom to select a preferred BAT (for example, based on a decision regarding measurements performed on the beacon signal 11), while the second device 15 may be obliged to use the configuration data for DL transmission from among the configuration data defined by the BAT update information field 55 for a valid BAT (in accordance with the validity information field 53). Thus, the mobile device 16 may determine a few different configurations, while the second device 15 may generally select one configuration from among the possible configurations proposed by the first device 16.

[0258] FIG. 8b shows an example of a BAT message 61. The BAT message 61 includes a transmitting device (for example, one of 16', 16", A, B, C, D) an associated front end (for example, one of 14a…14j) At least one BAT (valid BAT and / or updated BAT) may be associated with at least one of them.

[0259] BAT message 61 may define, as a valid BAT, the BATs (51-1, 51-5, 51-14) identified as 1, 5, 14 among the valid information 53. In this case, the updated BAT information field 54 may indicate that the BAT to be updated using the current BAT message 61 is the BAT identified as 1 (i.e., BAT51-1 in FIG. 8). The remaining BAT update information field 55 may provide update data for updating the transmission of DL communication from the front end 14 to the first device 16. Accordingly, the second device 15 changes the instance of the list 50 on the fly by changing the valid information 53 (if changed) and / or by updating the BAT update information 55 for BAT1 (51-1) according to the updated BAT information 54.

[0260] An example of the communication between the second device 15 and the first device 16 is given in FIG. 8c. Here, subsequent BAT messages 61 are indicated by 61', 61", 61''', etc. Here, the beacon 11 is not shown for clarity (however, it is understood that the beacon 11 has been received in time by the first device 16 and the first device 16 has performed measurements and determined the preferred front end and the preferred subcarrier).

[0261] As can be understood, the first device 16 transmits the first BAT message 61' to the second device 15. The first BAT message 61' indicates that BAT1 (51-1) is currently invalid (which can be obtained by explicitly listing all valid BATs and thereby determining the invalid BATs, or by explicitly listing all invalid BATs), and the updated BAT information field 54 indicates that BAT2 (51-2) is now updated is shown.

[0262] The BAT message 61' is shown here to be lost (or not explainable in some form, e.g., not decodable) due to some phenomenon (e.g., an object blocking channel 18 between the first device 16 and the front end 14, interference, high error rate, low energy, etc.) that is not delved into here. Thus, the BAT message 61' does not reach the second device 15.

[0263] One might naturally think that it could be possible to anticipate the transmission of an acknowledgement (ACK) and / or a negative acknowledgement (NACK) from the second device 15 to the first device 16 to handle such a phenomenon. Unfortunately, time constraints are severe, to the extent that it is known that the transmission of ACK and / or NACK is difficult and time-consuming.

[0264] However, it is understood that the first device 16 can determine an implicit acknowledgement based on whether the second device 15 transmits subsequent messages using the updated BAT and / or the valid BAT, or transmits subsequent messages without using it.

[0265] After the reception of the BAT message 61' is lost, the second device 15 transmits a message 62' (carrying payload and / or control data) by using the configuration data associated with BAT1(52 - 1). BAT1(52 - 1) is currently invalid (however, the second device 15 does not recognize that BAT1 is invalid because it has not received the BAT message 61'). Thus, by receiving the message 62' based on the invalid BAT, the first device 16 can understand that the second device 15 has not correctly received the BAT message 61' (if it had, the message 62' should have a valid configuration).

[0266] Once this incorrect recognition is determined, the first device 16 transmits, in the validity information field 53, a new version of the BAT message 61 (herein shown as BAT message 61") indicating that BAT1(51-1) is invalid (again), and may transmit the current update of BAT2 in the updated BAT information field 54 as well as the BAT update information field 55 that carries configuration information for subsequent DL messages from the second device 15 to the first device 16. If the iterative BAT message 61" is correctly received and decoded by the second device 15, the second device 15 updates the list 50 using the BAT update information encoded in the BAT update information field 55 as shown in the BAT message 61".

[0267] Accordingly, a subsequent DL message 62" from the second device 15 to the first device 16 utilizes the configuration data associated with BAT2(52-2) and is correctly decoded by the first device 16.

[0268] Accordingly, by using the updated BAT by the second device 15 for transmitting the DL message 62, a unique positive response is provided. The DL message 62' utilized invalid configuration data associated with an invalid BAT (thus providing an implicit negative response to the reception of the first BAT message 61'), but its use in the DL message 62" after the correct reception and coding of the iterative BAT message 61" results in an implicit positive response to the correct reception and the decoding of the BAT message 61".

[0269] Subsequent retransmissions of the BAT message 61 (e.g., 61', 61''', etc.) are performed later (e.g., subsequent to the reception of subsequent beacons 11', 11'', etc.). For example, the third BAT message 61''' indicates in the validity information field 53 that BAT2 (51-2) is now invalid and BAT1 (51-1) is now valid, for some reason not delved into here, while the updated BAT information field 54 indicates that BAT1 (51-1) is now updated (and of course, the BAT update information field 55 in the BAT message 61''' indicates the configuration data associated with the DL signal 62 transmitted from the second device 15 to the first device 16). Subsequently, if the second device 15 correctly receives and decodes the third BAT message 61''', the second device 15 transmits a DL message according to the configuration indicated in the BAT update information 55.

[0270] In some examples, 1) the first device 16 can a. determine valid and invalid BATs, as well as b. the BAT that is currently updated ; 2) generally, the second device 15 can select a preferred BAT from among all active BATs for DL transmission to the device 16 3) the first device 16 can determine an implicit positive or negative response from the first reception 61 to the second device 15 4) during subsequent DL transmissions from the second device 15 to the first device 16, the second device 15 selects one of the valid BATs It is possible to define a rule that includes one of these.

[0271] A more in-depth discussion of the format of the example of the BAT message 61 is given here (see particularly FIGS. 8 and 8b). The BAT message 61 can have a variable length, for example, as a result of the information it conveys being variable.

[0272] The validity information field 53 may include, for example, a validity information bitmap. The validity information bitmap may associate each bit position with one specific BAT. In the case of 24 BATs, the validity information bitmap may include 24 bits (e.g., 24 subsequent bits). Each bit may be associated with each BAT, for example, according to the position of the bit in the validity information bitmap. For example, the first bit (bit 0) of the validity information bitmap may be associated with the first BAT 51-0 in the list 50 of FIG. 8a. For example, the second bit (bit 1) of the validity information bitmap may be associated with the second BAT 51-1 in the list 50. Each bit position in the validity information bitmap may be associated with a specific BAT, and the value of the bit (1 vs. 0) may be associated with the validity of the BAT (e.g., valid state vs. invalid state). In the example of FIG. 8b, the validity information bitmap embodying the validity information 53 may be represented as "0100010000000010000000000b", which means the following.

[0273]

Table 5

[0274] By representing the validity information field 53 as a bitmap, it is always possible to ensure that the length of the validity information field 53 is constant for any possible combination of valid / invalid BATs.

[0275] The second communication device 15 and the first communication device 16 may share knowledge of the BATs based on the positions of the BATs in the validity information bitmap. The positions in the validity information bitmap may be associated with the identifiers 52 of each BAT 51-0...51-23 in the list 50. This knowledge may be predefined, for example (or may be configured in an offline session, for example).

[0276] It is not always essential that the order in the validity information bitmap exactly corresponds to the BAT identifier. It is important that the first communication device 16 and the second communication device 15 share knowledge of the relationship between the position in each validity information bitmap and a specific BAT (e.g., the BAT identifier and / or the position of the BAT in list 50).

[0277] In the example, the meanings of the values "1" and "0" may be reversed. Other types of symbols may be used.

[0278] In a variation, other techniques may be used instead of a bitmap. It is possible to use encoded values, lists, arrays, matrices, etc.

[0279] The updated BAT information field 54 may be within a specific updated BAT information field. In this case, preferably an encoded field may be used instead of a bitmap. For example, if there are 24 possible BATs, 5 bits may be used. For example, to indicate that the updated BAT is BAT1 (51-1), the updated BAT information field may be encoded as "00001b". For example, to indicate that the updated BAT is BAT14 (51-14), the updated BAT information field may be encoded as "01110b".

[0280] For this purpose, several encoding techniques may be used. It is possible to use big-endian or little-endian notation, fixed-length or variable-length, etc. Exchanging "1" for "0" or vice versa does not change the result.

[0281] In practice, a bitmap may be preferred for the validity information field 53, but the use of an encoded field for the updated BAT information 54 has important advantages. That is, it is possible to easily encode the BAT identifier with 5 bits without the need to use another bitmap. An undetermined number of valid / invalid BATs may be indicated in the validity information field 53, but only a single BAT may be indicated in the updated BAT information field 54 (as a result of the fact that only a single BAT is updated for each transmission of the BAT message 61). (More generally, a fixed number of BATs may be updated each time.)

[0282] In some examples, however, the validity information field 53 and the updated BAT field information 54 have a fixed amount of bits together. For example, they may have 24 + 5 = 29 bits.

[0283] The BAT update information field 55 may have a variable length. The BAT update information field 55 may indicate the configuration (format) of the signal 62 to be transmitted by the facility 15. Thus, the BAT update information field 55 may indicate the physical layer parameters to be used by the second device 15 when transmitting the signal 62 immediately after the BAT message 61.

[0284] The BAT update information field 55 may include, for example, forward error correction (FEC) information 55a to be used by the facility 15 when transmitting the DL message 61. Different FEC schemes may be indexed in the FEC information field 55a, which may be an encoded field. The FEC information field 55a may be encoded in several bits, for example 7 bits (e.g., 3 bits for field 55a' and / or 4 bits for field 55a"). The length of the field encoding the FEC information 55a may be constant. The FEC information field 55a may indicate the specific FEC scheme used. For example, one of the code rates (CR) known as 1 / 2, 2 / 3, 5 / 6, 16 / 18, 20 / 21, block sizes (BS) 960, 4320, etc. may be selected. In some examples (e.g., in FIG. 8b), the FEC information field 55a may be split into an FEC block size field 55a' (e.g., indicating the size of the FEC block to be used when transmitting the signal 62), and / or an FEC code rate information field 55a" (e.g., indicating the specific code rate to be used). When an FEC scheme is selected by the first communication device 16, the second communication device 15 uses it to transmit the DL message 62. Broadly speaking, the FEC scheme introduces redundancy into the message 62 and enables it to withstand possible errors when reading any values (e.g., incorrectly decoded bits, etc.).

[0285] The BAT update information field 55 may include, for example, an information field 55b regarding different groups of subcarriers. The information field 55b may indicate the subcarriers assigned to the updated BAT. The subcarriers may be indexed (e.g., according to specific values such as frequencies or according to any other conceivable indexing) and grouped according to those indexes. Thus, the first communication device 16 and the second communication device 15 may share the concept of subcarrier 0 (at a known frequency), subcarrier 1, subcarrier 2,... up to the last subcarrier.

[0286] Thus, the information field 55b can be re-divided into a plurality of group information fields 55b', 55b", etc. Each group information field 55b' can refer to a specific group of sub-carriers.

[0287] For each group information field 55b' (or 55b"), a sub-carrier grouping information field 55c' (or 55c") can be defined. This sub-carrier grouping information field 55c' is information about which sub-carriers are part of a specific group. For example, the first sub-carrier grouping information field 55c' indicates that 128 sub-carriers are part of group 1. These 128 sub-carriers can also be identified by their indices (they are the 128 sub-carriers with the smaller indices). The second sub-carrier grouping information field 55c" can indicate that 512 sub-carriers are part of group 2. These 512 sub-carriers (at least the existing ones among them) can also be identified by their indices (they start from the 129th sub-carrier and continue progressively). Thus, each group may be composed of sub-carrier intervals, and the intervals are defined according to the indices of the sub-carriers.

[0288] For each group (e.g., 1, 2) indicated in the sub-carrier grouping information fields 55d' and 55d", bit loading information is provided (e.g., how many bits should be loaded for each sub-carrier of the group). (This information may be provided based on the decision of the first communication device 16, for example, according to the decision that the noise of the first 128 sub-carriers is less and the transmission is better, which is measured, for example, when the beacon 11 is received).

[0289] For each group, the first device (e.g., a device) 16 may select from a predetermined limited number of groupings (e.g., for each group, the number of subcarriers may be selected from 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, or 4096), and this number may be specified in 4 bits. Thus, each subcarrier grouping information field 55c' may be encoded in a 4-bit field. When the field encodes "0000b", the group has only one single subcarrier. When the field encodes "0001b", the group has two subcarriers. When the field encodes "0110b", the group has 4096 subcarriers, and so on.

[0290] For each group, the number of bits to be loaded may be selected from a fixed number of bits. For example, each subcarrier may be loaded with 0...12 bits (and this is valid for all subcarriers in the same group). Thus, the load bit information fields 55d' (and 55d") may be encoded in a fixed number of bits (e.g., 4 bits).

[0291] Thus, for each group, each group information field 55b' may be encoded in a fixed number of bits (e.g., 4 bits for encoding information 55c' or 55c", and 4 bits for encoding information 55d' or 55d").

[0292] However, the length (time duration) of the group information field 55b for different groups of subcarriers can generally be variable. This is because the first device 16 can generally freely re-divide the subcarriers according to any of the groups. In the example of FIG. 8b, two different groups 1 and 2 are defined, but the first device 16 can define different groups. For example, in the field 55c', if the selection is "1 subcarrier" instead of "128 subcarriers", this means that group 1 will have one single subcarrier. The first device 16 can freely define other groups for the same remaining 127 subcarriers (for example, another group of 127 single subcarriers, or a group of 63 two-carrier groups + one single-carrier group, etc.). In that case, the length of the information 55b will be much larger as a result of defining one group information 55b' for each of the groups.

[0293] The BAT message 61 may be expected to have something like an end-of-frame sequence at the end of the last group information (for example, after the field 55b" in FIG. 8b) that can enable determination of the end of the BAT message 61. This sequence increases the time duration of the BAT message 61 without providing valuable information.

[0294] However, it is understood that it is possible to adopt particularly effective techniques that enable the knowledge based on the information shared by the device 16 and the facility 15, for example, to determine the end of the BAT message 61 based on the number of sub-carriers. Since the number of sub-carriers is limited (known to both the device 16 and the facility 15), the information about grouping can make it possible to determine the end of the BAT message 61. For example, when there are 640 sub-carriers, the BAT message 61 ends after the second group information 55b" (group 1 has 128 sub-carriers, the second group has 512 sub-carriers, 128 + 512 = 640), and there is no meaning in continuing to encode data. For example, when there are 630 sub-carriers, group 2 has only 502 sub-carriers (even if shown as having 512 sub-carriers by the encoded information 55c").

[0295] Example: The BAT Request element (e.g., the BAT message 61 in FIGS. 5 and 5b) can be used by the receiving device 16 using HB-PHY to request the use of some bit loading and error coding scheme from a future transmitter. Valid BAT Bitmap (validity information 53): Specifies the BATs that are required to be valid. The first bit of the bitmap corresponds to BAT ID 8, while the last (i.e., the rightmost) bit corresponds to BAT ID 31. A bit set to 1 indicates that the BAT is valid, and 0 indicates that the BAT is invalid, i.e., it should no longer be used by the transmitter. Updated BAT (updated BAT information 54): Specifies the ID of the BAT that is to be updated, defined at runtime. Only values 8 - 31 are permitted. A value of 0 indicates that the new BAT is not updated. This may apply when only the validity information is signaled in the BAT Request element. Values 1 - 7 are reserved. FEC Block Size (55a'): FEC Code Rate: Specifies the required FEC coding rate. BAT Group 1…N: BAT Group elements that describe the modulation for the nth group of subcarriers. Assume there are enough groups to cover all subcarriers. The last group may be wider than the remaining number of subcarriers. The required modulation for those excess subcarriers shall be ignored. BAT Group elements (such as 55b', 55b") contain information about groups of adjacent subcarriers that have the same number of bits loaded in bit-loading capable PHY transmissions. BAT Group elements contain information about groups of adjacent subcarriers that have the same number of bits loaded in bit-loading capable PHY transmissions. The structure of the BAT Group element is shown in the figure. It has the following fields: Grouping: This field contains the number of subcarriers in this group. The valid values are as follows. 1,2,4,8,16,32,64,128,256,512,1024,2048,4096 Loaded Bits: The number of bits loaded onto each subcarrier in the group. The valid values are as follows. 0,1,2,3,4,5,6,7,8,9,10,11,12

[0296] Above, the validity information was referred to as being embodied by the validity information field 53, the updated BAT information as being embodied by the updated BAT information field 54, and the BAT update information as being embodied by the BAT update information field 55. However, in some examples, this is not strictly necessary. In some examples, the validity information field 53 may not be present in the BAT message 61, but the validity information may be derived, for example, from the updated BAT information field 54. In some examples, the updated BAT information field 54 may not be present in the BAT message 61, but the updated BAT information may be derived, for example, from the validity information field 53.

[0297] The signal 62 can be a signal that carries a payload and / or signaling. In some examples, the signal 62 can be embodied by any of the signals 33, 33b, 700, etc.

[0298] In the above examples, some aspects relate to a communication device [e.g., for performing optical communication] configured to transmit a bit allocation table (BAT) message [e.g., to communication equipment], [e.g., to a user equipment, e.g., a mobile device, for communicating with communication equipment, the communication device being, e.g., a base station (BS) or a regulator], the BAT message being validity information [e.g., a bitmap, shown as "Valid BAT" in the example of FIG. 8b] signaling which one or more of a plurality of BATs are valid [e.g., available for use by a BS or regulator to transmit data to a communication device] and / or updated BAT information [e.g., shown as "Updated BAT" in the example of FIG. 8b] signaling which BAT of a plurality of BATs should be updated and / or BAT update information for signaling update information to update the BAT signaled as to be updated [e.g., the last five fields in the example of FIG. 8b] comprises.

[0299] In the above example, some aspects are configured to send a bit allocation table (BAT) message [which may comprise validity information signaling which one or more of a plurality of BATs are valid, e.g., shown as "Valid BAT" in the example of FIG. 8b, e.g., a bitmap] [e.g., usable by a BS or regulator] to [e.g., a communication facility] [e.g., a communication facility for sending data to a communication device] [e.g., for optical communication], for a communication device [e.g., a user equipment, e.g., a mobile device, the communication device being, e.g., a base station (BS) or regulator] communicating with a communication facility, the BAT message update BAT information signaling which BAT of the plurality of BATs is to be updated [e.g., shown as "Updated BAT" in the example of FIG. 8b], [optionally, BAT update information signaling update information to update the BAT signaled as to be updated, e.g., the last five fields in the example of FIG. 8b] and includes, the communication device anticipates [e.g., from a communication facility] a confirmation, the confirmation being derived from the use of bit allocation according to the updated BAT, and / or resends the BAT message if no validity confirmation is received from the communication facility is configured as such.

[0300] The communication device further Signaling valid information (e.g., a bitmap such as "Valid BAT" shown in the example of FIG. 8b) indicating whether one or more of the plurality of BATs are valid [e.g., available for use by the BS or regulator to send data to the communication device], and / or in some examples, also signaling which one or more of the plurality of BATs are not valid, and / or BAT update information for signaling update information for updating the BAT signaled as being updated [e.g., the last five fields in the example of FIG. 8b] may consist of a BAT message comprising.

[0301] The communication device may be further configured, and the length of the BAT message is variable.

[0302] The communication device may be further configured with BAT message group information regarding different groups of subcarriers [the number of subcarriers per group may vary from group to group] [e.g., the BAT message may comprise information for a plurality of groups as to how many subcarriers each group has and / or how many bits are loaded onto the subcarriers of each group].

[0303] The communication device may be configured to selectively update BATs previously signaled as being invalid.

[0304] The communication device may be configured to refrain from updating BATs previously signaled as being valid.

[0305] The communication device may be configured to expect confirmation from the communication facility [such as shown in FIG. 8c], the confirmation being derived from the use of bit allocation according to the updated BAT.

[0306] The communication device may be configured to retransmit the BAT message if it does not receive a valid confirmation from the communication facility.

[0307] The communication device may be configured to anticipate transmission using one of the BATs indicated as valid in the reception from the communication facility.

[0308] The communication device may be configured to make the information in the BAT message based on feedback on channel conditions [such as from a beacon message, such as as determined].

[0309] The communication device may be configured, and the BAT update information includes forward error correction (FEC) information [such as information regarding the expected value of the redundancy required for data to be transmitted from the communication facility].

[0310] In the above example, some aspects relate to a communication facility [such as a base station (BS) or regulator] [such as an optical communication facility] [such as for a wireless network with multiple communication devices] configured to receive a bit allocation table (BAT) message from a communication device [such as a user equipment, such as a mobile device, such as may be part of a network], and the BAT message is Validity information [such as a bitmap shown as "Valid BAT" in the example of FIG. 8b] [in some examples, may also signal which one or more of the plurality of BATs are not valid] signaling which one or more of the plurality of BATs are valid [such as usable by the communication facility to transmit data to the communication device], and / or Update BAT information [such as shown as "Updated BAT" in the example of FIG. 8b] signaling which of the plurality of BATs should be updated, and / or BAT update information for signaling update information to update the BAT signaled to be updated [e.g., the last five fields in the example of FIG. 8b] comprises.

[0311] In the above example, some aspects relate to a communication facility [e.g., a base station (BS) or regulator] [e.g., an optical communication facility] [e.g., for a wireless network with multiple communication devices] configured to receive a bit allocation table (BAT) message from a communication device [e.g., which may be part of a network, e.g., a user equipment, e.g., a mobile device], the BAT message comprising [Optional: signaling which one or more of a plurality of BATs are valid, e.g., signaling to the communication device whether a BAT is available for use by the communication facility to transmit data to the communication device, and in some examples, also signaling which one or more of a plurality of BATs are not valid, validity information, e.g., as shown as "Valid BAT" in the example of FIG. 8b, e.g., a bitmap], and / or update BAT information signaling which BAT of a plurality of BATs should be updated [e.g., as shown as "Updated BAT" in the example of FIG. 8b], and / or [Optional: BAT update information for signaling update information to update the BAT signaled to be updated [e.g., the last five fields in the example of FIG. 8b]] comprises, and the communication facility is configured to send a confirmation [e.g., to the communication device], the confirmation being derived from the use of bit allocation according to the updated BAT.

[0312] The communication facility may be configured and the bit allocation table (BAT) message Signaling valid information [e.g., a bitmap shown as "Valid BAT" in the example of FIG. 8b] indicating which one or more of a plurality of BATs are valid [e.g., available for use by a communication facility to send data to a communication device] and / or [in some examples] which one or more of the plurality of BATs are not valid, and / or BAT update information that signals update information for updating the BATs signaled as being updated [e.g., the last five fields in the example of FIG. 8b] comprises.

[0313] The communication facility may be configured and the length of the BAT message is variable.

[0314] The communication facility may be configured with BAT message group information for different groups of subcarriers [the number of subcarriers per group may vary from group to group].

[0315] The communication facility may be configured such that BATs previously signaled as being invalid may be selectively updated.

[0316] The communication facility may be configured such that BATs previously signaled as being valid cannot be updated.

[0317] The communication device may be configured to send an acknowledgment to the communication device [as shown in the figure of FIG. 8c, for example], the acknowledgment being derived from the use of a bit allocation according to the updated BAT.

[0318] The communication facility may be configured to send a transmission to the communication device using one of the BATs indicated as being valid.

[0319] A communication device may be configured, and the information in the BAT message is based on feedback about channel conditions [such as from a beacon message, such as as determined].

[0320] A communication device may be configured, and the BAT update information includes forward error correction (FEC) information [such as information about the expected value of the required redundancy for data to be transmitted from the communication device].

[0321] In the above example, some aspects relate to communication [such as wireless communication, such as optical communication] between a communication device [such as a user equipment, such as a mobile device] for performing optical communication and a communication device [such as a base station (BS) or regulator], and the method includes the step of transmitting a bit allocation table (BAT) message [such as from the communication device to the communication equipment], and the BAT message Signaling valid information [such as a bitmap shown as "Valid BAT" in the example of Figure 8b] indicating which one or more of a plurality of BATs are valid [such as usable by the BS or regulator to transmit data to the communication device], and / or Signaling updated BAT information [such as shown as "Updated BAT" in the example of Figure 8b] indicating which BATs among a plurality of BATs should be updated, and / or Signaling BAT update information for signaling update information for updating the BAT signaled as being updated [such as the last five fields in the example of Figure 8b] and comprises.

[0322] In the above example, some aspects relate to a method for communication [e.g., for optical communication] between a communication device [e.g., a user equipment, e.g., a mobile device] for performing optical communication and communication facilities [e.g., a base station (BS) or a regulator], the method including the step of transmitting a bit allocation table (BAT) message [e.g., from the communication device to the communication facilities], the BAT message being [Optional: signaling, e.g., to the communication device, which one or more of a plurality of BATs are valid, e.g., available for use by the BS or regulator to transmit data to the communication device, and in some examples, also signaling which one or more of the plurality of BATs are not valid, validity information, e.g., as shown as "Valid BAT" in the example of FIG. 8b, e.g., a bitmap], and / or updating BAT information signaling which BAT among the plurality of BATs should be updated [e.g., shown as "Updated BAT" in the example of FIG. 8b], and / or [Optional: signaling BAT update information, e.g., signaling update information for updating the BAT signaled to be updated, e.g., the last five fields in the example of FIG. 8b] comprising, and the method further is the step of transmitting an acknowledgement from the communication facilities to the communication device, the acknowledgement being derived from the use of bit allocation according to the updated BAT, and / or, if the communication device does not receive a valid acknowledgement from the communication facilities [e.g., within a predetermined threshold], the step of retransmitting the BAT message from the communication device to the communication facilities comprising.

[0323] The method may further consist of a bit allocation table (BAT) message, the BAT message being Signaling valid information (e.g., a bitmap such as shown as "Valid BAT" in the example of FIG. 8b) indicating which one or more of a plurality of BATs are valid [e.g., available for use by a BS or regulator to transmit data to a communication device], and / or [in some examples] signaling which one or more of the plurality of BATs are not valid, and / or BAT update information for signaling update information for updating the BATs signaled to be updated [e.g., the last five fields in the example of FIG. 8b] comprises.

[0324] The method may further be configured using a device.

[0325] In the above example, some aspects relate to a non-transitory storage unit that stores information that causes a processor to execute the method when executed by the processor.

[0326] In the above example, some aspects relate to a system comprising communication facilities and a communication device.

[0327] The above description includes, among other things, examples of procedures and frame types for supporting, for example, a distributed optical front end and / or MIMO techniques in a star topology. Examples are discussed below.

[0328] Goals of distributed optical front end (OFE) techniques: Introduction of spatial diversity at the signal level, and / or Enabling spatial reuse with smooth handover performance and high QoS, and / or Low-level "soft handover": A virtual cell in OFE format following the movement of a device that is completely transparent to the management protocol. See FIG. 1, which may be understood as showing a regulator in a star topology with distributed OFE serving two devices simultaneously.

[0329] Superframe Structure for Spatial Reuse and Joint Transmission + Reception: Slot-based uplink random access (ALOHA) without carrier sensing in CAP. Collisions can occur only for association and reconnection; and / or Per-device GTS allocation for normal collision-free transmission and in CFP; and / or Different GTSs (SDMA) allocated in the same superframe slot but in different OFE slots; and / or The GTS spans multiple OFE slots, which implies a "virtual cell" for joint transmission / reception. See Figure 2.

[0330] Channel Estimation, CSI Feedback, and GTS Update: Multi-cell channel estimation is based on the multi-cell pilot in the beacon. Additional desired BAT or MCS feedback can be generated for individual virtual cell transmissions; and / or The scheduler schedules the GTS based on the feedback and selects adaptive transmission; and / or The dynamic GTS is updated via a control frame and is valid for the next superframe if validity = 0, or for multiple superframes otherwise. The previous dynamic GTS allocation loses its validity. The GTS update is acknowledged in the next feedback frame. See Figure 3.

[0331] Multi-cell Channel Estimation Feedback: TAP format for variable resolution setting for taps; and / or Symbols (1 - 7) + divisions (1 - 32) for pilot / OFE identification; and / or The strength of the first tap is SNR [dB]; and / or For other taps, it is the ratio [dB] between the first tap and the current tap; and / or The first OFE / TAP has the least delay.

[0332] Adaptive bit loading feedback: Required BAT control frame format: The valid BAT bitmap indicates the applicability of each of the 24 runtime BATs for transmission from the receiver to the sender of the BAT request frame; and / or The "Updated BAT" field indicates the BAT for transmission from the receiver to the sender of the BAT frame to be updated; and / or If all runtime BATs are invalid, the frame contains only 2 octets of 0; and / or FEC scheme: Code rate (CR) 1 / 2, 2 / 3, 5 / 6, 16 / 18, 20 / 21, & Block size (BS) 960, 4320; and / or Grouping: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096 Bits to be loaded: 1, 2, 4, 8, 9, 10, 11, 12 List of groups of subcarriers for loading different numbers of bits based on The last group is a group that exceeds the actual number of subcarriers present in the PHY. See Figure 5.

[0333] Adaptive bit loading feedback protocol: When the channel changes and a previously valid BAT becomes unavailable, a new BAT is set ( "updated"). The old BAT is marked as invalid; and / or Reuse of the BAT ID in an update is permitted only if the BAT ID to be updated was previously invalid. The BAT ID to be updated must be marked as valid; and / or The reception of the required BAT frame is verified by the receiver by using the most recently updated BAT for the transmission towards the sender of the required BAT frame; and / or The loss of the required BAT frame can be removed through the use of an invalid BAT ID in subsequent receptions

[0334] Examples of required BAT frames: Examples of required BAT frames for HB-PHY with 512 subcarriers; and / or Here, it is shown that only BAT1, 5 and 14 can be used for transmission towards the sender of the required BAT frame; and / or BAT1 is updated for a given FEC and for two groups of subcarriers loaded with 8 bits and 6 bits respectively; and / or The receiver of the required BAT frame knows that the second group of subcarriers is the last group because it designates more subcarriers than the actual number; and / or The excess subcarriers of the second group are ignored and not modulated. See Figure 5b.

[0335] Adaptive modulation and coding feedback: The required MCS control frame transmitted to request the use of a specific MCS; and / or The same procedure as for the required BAT frame, but an MCS is required; and / or When the transmitter does not apply the correct MCS, the control frame is repeated.

[0336] Dynamic GTS descriptor: GTS allocation via a GTS update frame or via a beacon frame as already existing in the standard; and / or The validity field specifies the number of superframes in which the GTS is valid; and / or Only the initially applied GTS direction is considered. Surplus bits are ignored. Refer to FIGS. 7a and 7b.

[0337] Example of a superframe: A new device, or a device that has lost connection and has no GTS allocated, can send an association request and a reconnection feedback frame in the CAP; and / or All control transmissions, management transmissions, and data transmissions are executed in the GTS within the CFP.

[0338] Further examples Reference is made here to MAC layer support for multiple optical front-ends that may be associated with any of the above aspects.

[0339] This section includes, inter alia, proposals for protocol procedures and frame type aspects necessary to support distributed optical front-ends and MIMO technology in a star topology.

[0340] Goals of the distributed optical front-end (OFE) approach: Introduction of spatial diversity at the signal level Enable spatial reuse with smooth handover performance and high QoS Low-level "soft handover": virtual cells in OFE format following device movement, completely transparent to the network layer FIG. 1: Regulator in a star topology with distributed OFE serving two devices simultaneously

[0341] Front-haul technology and functional split: The PHY of the regulator is connected to the OFE via the front-haul The implementation form of the front-haul is out of scope The analog front-haul can be a simple coaxial cable or fiber transmission of analog signals Digital fronthaul can be the transmission of digitized waveform samples (CPRI). The splitting of signal chain functions, such as might be discussed as "new function splitting" in mobile networks, is out of scope. Digital fronthaul transmission technology is currently under research in the field of mobile networks, and requirements are defined in the following different standardization activities: eCPRI IEEE 802.1CM

[0342] Fronthaul delay: Fronthaul virtually increases the propagation delay. The order is up to 100 μs at most. Fronthaul delay t F shall be known and approximately the same for all OFEs. Analog fronthaul delay is part of the propagation delay. The appropriate synchronization technique for digital fronthaul is IEEE 1588v2 (PTP). The start of the MAC frame in each OFE can be obtained from the PTP slave in each OFE. If such a technique is not available, proprietary approaches can be considered. The remaining delay difference between air times in different OFEs shall be very small, i.e., significantly less than 1 / 2 of the cyclic prefix length.

[0343] PHY support for multiple OFEs (see Figure 6): The PHY of the regulator has multiple transmit and receive chains (TRX chains) and multiple ports for the OFEs (OFE ports). TX configuration per PSDU via PD-SAP Which OFE to transmit on (Optionally, at the clock period) Delay difference compensation per OFE RX configuration via PLME-SAP Groups of OFEs in virtual cells for combination in the uplink The front hole delay is constant for each OFE The MAC layer must compensate for this value as described above

[0344] Superframe structure for spatial reuse and joint transmission + reception: Slot-based uplink random access without carrier sensing in CAP. Collisions can occur only for association and reconnection Per-device GTS allocation for normal transmission and reception in CFP Different GTSs (SDMA) allocated in the same superframe slot but different OFE slots GTS spans multiple OFE slots, which implies a "virtual cell" for joint transmission / reception

[0345] Dynamic GTS: If the same superframe slot is "reused" in the GTSs of different devices (spatial multiplexing), when devices with such GTSs approach each other, movement can lead to frame collisions Therefore, the GTS allocation must adapt quickly to movement Maintain the existing quasi-static GTS allocation mechanism via management frames (5.1.10 and Appendix G of D3) Proposal: The so-called dynamic GTS can be assigned to devices by the regulator via control frames in addition to the quasi-static GTS allocation The dynamic GTS is only valid for a specified number of superframes and is then not used The quasi-static GTS is valid unless deallocated via the management protocol

[0346] Dynamic GTS descriptor: The dynamic GTS descriptor is transmitted via the control frame The dynamic GTS descriptor is similar to the quasi-static GTS descriptor, but does not have a device address and includes a Validity field. The Validity field of the dynamic GTS descriptor may include the number of superframes to which the dynamic GTS is assigned. Add a table for the GTS list.

[0347] Association and reconnection (e.g., regarding Mode II; see also Figure 3a): A new device 16 that has lost its connection to the regulator 12 and is not allocated a GTS can send an association request and a reconnection feedback frame 35 in CAP11a. Proposal: CAP transmission: Slotted Aloha in a macro slot including multiple superframe slots, where each superframe slot can hold an entire frame. Proposal: The estimated downlink CSI is included in the random access frame.

[0348] Channel estimation, CSI feedback (e.g., 32, 32b, 35), and GTS update: Channel estimation can be based on the multi-cell pilot in the beacon 11. CSI feedback (e.g., 32, 32b, 35) can typically be sent via a control frame in the GTS. The regulator 12 can dynamically update the GTS allocation based on the CSI feedback. The dynamic GTS is updated via a control frame and can be valid during the next superframe if Validity = 0, or during multiple superframes otherwise. In the example, the previous dynamic GTS allocation loses its validity. The GTS update can be acknowledged in the next feedback frame.

[0349] Mode III (see above) and Figure 1a are specifically referred to here. MU MIMO with a distributed optical front end: Using multiple distributed optical front-ends (OFEs) with a single regulator as a MU-MIMO system Delay difference compensation for multiple OFEs Control signaling for MU MIMO Delay difference: example Assume a digital front hall via Ethernet using, for example, PTP The optical network is small, for example, with a front hall delay of 10 - 100m * 5ns / m = 50 - 500ns PTP = Precision time protocol IEEE 1588v2 PTP packets get high priority and in a stationary scenario 1,2 the accuracy is <<1μs Front hall + propagation delay + PTP accuracy < long CP or synchronization sequence length LB PHY@32MHz: CP = 160 samples * 31.25ns = 4.8μs HB PHY: CP = 1.28μs PM PHY@200MHz: synchronization sequence length = 384 samples * 5ns = 1.92μs Obviously, even when all delays are combined, they are shorter than the long CP / synchronization sequence length High-precision front hall alignment can be achieved over the air (See also L. Cosart, "Precision Packet Delay Measurements Using IEEE 1588v2", 2007 IEEE Int. Symp. on Precision Clock Synchronization for Measurement, Control and Communication, Vienna, 2007, pp. 85-91; R. L. Scheiterer, C. Na, D. Obradovic, G. Steindl, F.-J. Goetz, "Synchronization Performance of the Precision Time Protocol in the Face of Slave Clock Frequency Drift", 4th IEEE Conference on Automation Science and Engineering, Key Bridge Marriott, Washington DC, USA, August 23-26, 2008.) Delay difference compensation: Problem (see also Fig. 1a): The optical front end (OFE) must be time-aligned The front hole protocol is transparent to the OWC, if any The front hole is analog or digital and indicates some delay The regulator compensates for the remaining delay difference in each OFE Situation: The system is turned on For example, PTP is applied Individual time errors t in each OFE F1 , t F2 , t F3 exist Individual propagation delays t from each OFE P1 , t P2 , t P3 exist The overall delay spread is less than 1 μs Time alignment: Proposed solution: Proposed solution: Measure individual delay differences over the air Notify the regulator about the delay differences Correct them using variable FIFO delay buffers in each OFE Proposal: The beacon uses a CP that is long enough for channel estimation, headers, optional fields, and payloads The beacon includes orthogonal sequences for MIMO in optional fields The device performs multi-cell channel estimation for all OFEs The device transmits the CIR for all visible OFEs in an association request (CSI feedback) The regulator corrects the delay differences in each OFE accordingly Downlink MIMO operation: The beacons are transmitted together over all OFEs Delay difference measurements are supported using MIMO reference signals OFEs are identified by different MIMO reference signals The device performs multi-cell channel estimation for each OFE The device provides the regulator with feedback of channel state information (CSI) for each visible OFE, and the CSI can be highly compressed (see also below) The regulator applies delay difference compensation in each OFE Adaptive CSI feedback compression: Select visible OFEs Convert the channel from the frequency domain to the time domain → Reconstruct the CIR Select non-zero taps based on a threshold that depends on noise and interference Quantize the amplitude of each non-zero tap Use fixed or variable quantization, where the variable depends on the SINR MIMO CSI feedback format: Time domain feedback for all visible OFEs Adaptive quantization is used (can be fixed) for each tap amplitude. Impulse response feedback format 3 : The OFE index represents the source OFE. The step size and quant. bits describe the adaptive quantization. The delay vector is a bitmap, which is 1 at position l if the l-th tap is non-zero and 0 otherwise. L = sum(Delay vector) is the number of non-zero taps in the CIR. Taps contains the amplitudes of L taps quantized at a depth of B bits. Adaptive bit loading: Adaptive bit loading is used together with the HB OFDM PHY. The runtime bit allocation table (BAT) is negotiated by the MAC. The device measures the subcarrier-specific SNR value and calculates the desired BAT including the number of bits per subcarrier or subcarrier group. The desired BAT is fed back to the regulator via the desired BAT control message, i.e., when the channel changes. The regulator determines whether the desired BAT is used or another BAT is used. The regulator uses the given BAT control message to inform the device. For fast switching between the predefined BAT and the runtime BAT, the PHY header contains the BAT ID required for demodulation. Adaptive bit loading: procedure: Basic BAT maintenance procedure: The device periodically updates the BATs that the device can support. The procedure can be initiated by the device or the regulator. In each preamble frame, or after a request by the device, the regulator transmits the channel estimation symbol. Negotiation as described Desirable BAT format: Information included: BAT ID to be updated Groups of sub - carriers in groups of 1, 2, 4, 8, 16 Valid BAT ID FEC block size FEC code rate Lowest loaded sub - carrier (group) Highest loaded sub - carrier (group) Bits loaded per sub - carrier (group) Followed by frame format

[0350] Other aspects Wireless specialty networks 1.1 Scope 1.2 Purpose

[0351] 2 Description The concepts discussed in this section can be generalized to systems involving a first device 16 and / or a second device 15 communicating through a wireless link, which may be optical or non - optical, for example. The concepts discussed here can be surprisingly combined with other concepts discussed above. Instead of an optical front - end (OFE), more generally, it can be referred to as a front - end (e.g., a wireless front - end). Instead of OWPAN, a reference can be made to a network (e.g., a wireless network such as an optical network).

[0352] 3 Definitions, Acronyms, and Abbreviations 3.1 Definitions This section lists the terms used throughout this disclosure. Each term is printed in bold. The definition is given after the colon. If a term has synonyms, i.e., other terms that describe the same entity in this disclosure, these synonyms can be listed in parentheses. The definition may be replaced by the designation of a synonym, in which case the definition of the synonym can be referred to. Contention Access Period (CAP): CAP Slot: A composition of multiple superframe slots in CAP Guaranteed Time Slot (GTS): MAC Frame: A frame handled by the MAC sublayer [MAC Protocol Data Unit] MAC Protocol Data Unit (MPDU): [MAC Frame] Modulation and Coding Scheme (MCS): Rate adaptation parameters at the physical layer. This includes, for example, details of the type of modulation or error coding scheme. Superframe Slot: The basic time resource that constructs the block of each superframe in the beacon-enabled channel access mode. The time lengths of other time durations, i.e., the beacon slot or the CAP slot, are multiples of the superframe slot time length.

[0353] 3.2 Acronyms and Abbreviations FCS Frame Check Sequence DME Device Management Entity TAIFS Turnaround Interframe Space LLC Link Layer Control

[0354] 4 General Description 4.1 Introduction 4.2 Components of IEEE 802.15.13 OWPAN An OWPAN (or more generally, a network) can consist of devices compliant with the disclosure. The devices have MAC-48 addresses for identification and flat addressing in the network. The devices consist of compliant MAC implementation forms and utilize the compliant PHY defined in this disclosure. It is not required that all devices implement the functions for maintaining the OWPAN. Devices that support the functions are also called regulator-compatible devices or regulators when actively maintaining the OWPAN.

[0355] In each OWPAN, a single coordinator - capable device can assume the role of a coordinator (e.g., the second device 15). The coordinator can be responsible for starting, maintaining, and finally stopping the OWPAN. The coordinator can further be involved in all data transmissions in the OWPAN. Thus, the only logical network topology of the OWPAN can be a star topology, as detailed in 4.3.

[0356] Non - coordinator devices, hereafter simply referred to as devices, implement fewer functions than the coordinator. Devices associate with the OWPAN to obtain a layer 2 connection to the network.

[0357] 4.3 Network Services The OWPAN represents a network among devices. The MCPS - SAP provides a service for transmitting MSDUs between devices based on MAC - 48 addresses. Moreover, the coordinator can act as an access point [bridge] that connects a peer in an external network and a device associated with the maintained OWPAN.

[0358] 4.3.1 Topology All IEEE 802.15.13 OWPANs have a star topology. Thus, a single coordinator can be involved in all data transmissions between two devices or between an external peer and a device associated with the OWPAN, as shown in Figure 9 - 1. Moreover, data transmissions between two devices in the same OWPAN may (in some cases) have to be relayed by the coordinator.

[0359] Depending on the application, the star topology can have different characteristics. The following sections enumerate the various special cases of the star topology to be realized.

[0360] 4.3.1.1 Distributed MIMO Star Topology To improve transmission characteristics and enhance mobility support, a star topology that supports the MIMO principle can be implemented. In that case, the regulator may have multiple optical front-ends (OFEs) for transmission and reception associated with its PHY. Using each OFE, the regulator may be able to transmit the same or different signals. However, individual OFEs cannot be addressed by the device, whereby the individual OFEs become transparent to the device, separate from the various pilot signals observed by the device.

[0361] The implementation of a distributed MIMO star topology is generally outside the scope of this disclosure. For example, the OFEs may be spatially distributed and connected to a single central regulator instance via some fronthaul technology, e.g., in accordance with IEEE 802.1CM-2018. To account for such possibilities, this disclosure defines means useful for implementation. These are, for example, the possibility of transmitting orthogonal pilot symbols from each OFE in the physical layer. However, the detailed implementation rules are omitted. The MAC further supports these possible implementations through a channel access mechanism that may be able to handle large fronthaul delays, increasing the propagation delay substantially to hundreds of microseconds.

[0362] The distributed MIMO star topology can be shown in Figure 9-3 (Figure 9-2 does not exist). The OFEs of the regulator can be arranged in various ways. One possible arrangement can be to disperse the OFEs over the target coverage area of the OWPAN.

[0363] 4.3.1.2 Omnidirectional star topology (broadcast) In the omnidirectional star topology (shown in Figure 9-4), the OWPAN comprises only a regulator. The regulator of the omnidirectional star topology does not accept associations by devices. It can transmit frames having a broadcast address as the destination address.

[0364] 4.3.1.3 Coordinated Star Topology Multiple regulators deployed in the same area can be coordinated by a master regulator. The corresponding topology can be called a coordinated star topology.

[0365] The function of the master regulator (e.g., 12) is generally outside the scope of this disclosure. It is currently expected that the deployment of a coordinated star topology includes devices from a single vendor and thus does not require standardization of the interface between the regulator and the master regulator.

[0366] The network connecting the master regulator to individual regulators can be used not only to manipulate information but also for rerouting data frames. This can also be called a backhaul 17. The master regulator (in some examples) shall provide the SAP to a higher layer to abstract the coordinated OWC network as a bridge according to the [IEEE802 bridge definition]. The coordinated topology can be shown in Figure 9-5.

[0367] Since light is extremely local, usually, in a single area, multiple uncoordinated infrastructures from different providers are not deployed. Therefore, neighboring IEEE 802.15.13 OWPANs are assumed to be deployed in a coordinated manner. If multiple OWPAN infrastructures overlap in the coverage area, they should always be coordinated by a master regulator that manages resource allocation between the corresponding regulators.

[0368] 4.3.1.4 Radio Frequency Hybrid Topology The hybrid topology involves an optional RF-based connection at each device. The realization of the hybrid topology can be outside the scope of this disclosure. It can be expected that the management of alternative OWC-based and RF-based connections can be performed according to, for example, 802.1AX on top of the 802.15.13 MAC.

[0369] 4.3.1.5 Peer-to-Peer Topology In a peer-to-peer topology, two devices seek to perform point-to-point communication with each other. In that case, one of the devices takes on the role of coordinator and provides an ad-hoc OWPAN to the other device. Thus, the peer-to-peer topology may be a special case of a star topology with a coordinator and a single non-coordinator device associated with the provided OWPAN.

[0370] 4.3.2 Integration OWPAN provides three logically distinct transmission services: 1) Transmission from the coordinator to a device or from a device to the coordinator 2) Transmission from a device to another device within OWPAN or to a peer of an external network 3) Transmission from another device within OWPAN or a peer of an external network to a device within OWPAN

[0371] Bridging, a fourth case, may not be currently supported in this disclosure. In bridging, a peer of the external network behind the coordinator can communicate with a peer of the external network behind the associated device.

[0372] In case 1), the transmitted frame can be a control frame or a management frame transmitted from the coordinator to a device or from a device to the coordinator. Also, the frame can be a data frame from a higher-layer application or protocol executed by a device or coordinator with a destination MAC-48 address set to either the address of the coordinator or the address of the device.

[0373] In Case 2), the higher layer applications or protocols executed by the device send frames with the destination set to a MAC-48 address other than the unicast address of the regulator. The destination address may belong to either another device of the OWPAN or a peer of another network to which the regulator can be connected.

[0374] 4.4 Coexistence The high directivity of light makes it difficult for coexistence schemes based on energy detection. This may be in contrast to RF-based communication technologies with omnidirectional propagation characteristics. Through these omnidirectional characteristics, heterogeneous RF technologies characterized by signals that are not mutually decodable can rely on refraining from transmission after detecting that the channel is busy by exceeding a given signal energy threshold (CCA through energy detection).

[0375] However, with directivity, Device A cannot infer that the transmission of the second Device B is currently being received at the future receiver of Device A.

[0376] This disclosure restricts non-coordinated transmissions, i.e., random channel access, to the minimum necessary purposes such as association or reconnection. However, when heterogeneous technologies enter the coverage area of IEEE 802.15.13 OWPAN, the behavior may not be specified. Currently, there may be no coordination for coexistence between different OWC disclosures.

[0377] 4.5 Architecture Similar to other IEEE 802 standards, the architecture of this disclosure can be defined by several layers to group related functions and simplify the disclosure. Each layer may be responsible for a subset of the functions included in this disclosure and provide services to the next higher layer.

[0378] Each layer includes an interface responsible for exchanging with other layers. More specifically, a lower layer provides services to the next higher layer. The term used for the corresponding interface in the present disclosure may be a service access point (SAP).

[0379] The present disclosure defines a public interface that is likely to connect entities provided by different vendors. Currently, these are the MCPS-SAP and the MLME-SAP as shown in FIG. 9-6. Other interfaces are assumed to be internal to the vendor or do not require detailed specification.

[0380] The various functions of a layer are accessible through so-called primitives that make up a given SAP. The concept of primitives can be further explained in Section 4.6.

[0381] Data that will be transmitted via OWPAN passes through multiple layers. A collection of control bits, management bits, and / or data bits that will be passed between layers can also be called a protocol data unit (PDU). Depending on the layer involved in the PDU exchange and the direction of the exchange, the PDU has a unique name. The data PDU passed to the MAC sublayer by the protocol of a higher layer can be called an MSDU. The MSDU enters the MAC sublayer through the MCPS-SAP for transmission via OWPAN and exits the MAC sublayer through the MCPS-SAP after successful transmission via OWPAN.

[0382] After processing through the MAC sublayer (during transmission) or before processing through the MAC sublayer, the data unit exchanged with the PHY can be called either an MPDU (from the perspective of the MAC) or a PSDU (from the perspective of the PHY) (PHY service data unit). The PSDU enters the PHY through the PHY-SAP and exits the PHY.

[0383] In the transmission direction, the PHY processes the PSDU to generate a PPDU, which represents the physical signal to be transmitted over the optical medium. After transmission via one or more OFEs, the PPDU may be received by the PHY layer and processed into a PSDU, which subsequently traverses multiple layers up to the MCPS-SAP.

[0384] 4.6 Concept of Primitives The service of a layer is the ability of that layer to provide to the next higher layer or sublayer by building the functions of that layer on top of the service of the next lower layer. This concept can be shown in Figure 9-7, which shows the relationship between the service user and the service provider (the next lower layer).

[0385] A service is defined by describing the flow of information between the user and the layer. This flow of information is modeled by individual instantaneous events that characterize the provision of the service. Each event consists of passing service primitives from one layer to another through the layer SAP associated with the user. Service primitives convey the information required to provide a particular service. Since these service primitives define the service being provided rather than the means by which the service is provided, they are abstractions. This definition is independent of any implementation form of any other interface.

[0386] 4.7 Functional Overview This section gives an overview of the functions supported by this disclosure.

[0387] 4.7.1 MAC Sublayer The MAC layer of this disclosure allows two modes of channel access operation.

[0388] 4.7.2 PHY Layer This disclosure supports three separate PHY layers.

[0389] 4.7.2.1 Introduction to PM-PHY

[0390] 4.7.2.2 Introduction to LB-PHY

[0391] 4.7.2.3 Introduction to HB-PHY

[0392] 4.7.3 Addressing In OWPAN, flat addressing of devices is facilitated. Each device in OWPAN has a unique MAC-48 address consisting of 48 bits. This address can be used to integrate OWPAN with other LANs that depend on the MAC-48 address format [see Std.802.1D and Std.802.1Q].

[0393] To enhance signaling efficiency, a device is assigned a shorter address during the association process. The short address consists of 16 bits and can be used to identify the device in various control and management procedures or to facilitate addressing in MAC frames.

[0394] Some addresses are reserved for special purposes. For MAC-48 addresses, the reserved addresses shall be the same as those in [IEEE 802 MAC Address Detailed Specification] (in some examples).

[0395] The short address 0x0000 shall not be used (in some examples). The short address 0xFFFF shall be used as a broadcast address (in some examples). Frames addressed to the broadcast address shall be received by all devices (in some examples).

[0396] 4.7.4 Duplex Mode All media access is controlled by the OWPAN coordinator. The coordinator may enable implicit full-duplex transmission and reception of a device if the device supports the capFullDuplex capability.

[0397] 4.8 Commitments in this Disclosure This section lists various commitments regarding formats, terms, and units within this disclosure.

[0398] 4.8.1 Format Commitments Constants and attributes defined and maintained by the MAC sublayer are written in italics and without spaces. Constants have a general prefix of "a", for example, aMinFragmentSize. Variable attributes have a general prefix of "mac", for example, macOwpanId.

[0399] The names of frames, elements, or fields are also written in italics. They start with a capital letter and may contain spaces, for example, the Association Request element.

[0400] 4.8.2 Terms for Providing Criteria The requirements for implementations compliant with this disclosure are expressed using the following terms. a. "shall" is used for mandatory requirements b. "may" is used to describe optional features that are permitted for an implementation to support c. "should" is used for recommended implementation and configuration choices

[0401] 4.8.3 Power Levels Optical wireless communication utilizes intensity - modulated light and direct detection in the receiver. Thus, the electrical signal levels as measured in the receiving DSP are not related to the received optical power levels in the same way for all devices. Rather, the relationship between the received optical power and the received electrical power depends on the details of the implementation of a given device, such as the characteristics of the LED and the photodetector.

[0402] Therefore, in order to compare signal levels, (in some examples) optical power rather than electrical power must be referenced. When signal levels are defined in the present disclosure, these are optical powers. This also applies to the emitted signal level and the received signal level.

[0403] Description of 5 MAC functions This section defines the functions and procedures of the MAC sublayer. The procedures can be initiated by the MAC or as a result of MLME-SAP primitive calls. The MAC utilizes the physical layer service and is responsible for the following tasks. · Execute channel access and transmission corresponding to the OWPAN configuration · Initiate and maintain the OWPAN · Associate with / disassociate from the OWPAN · Fragment and aggregate MSDUs · Provide a reliable link between two peer MAC entities · Adapt to alternating channel conditions

[0404] The MAC frame format that supports the MAC functions is defined in Section 6. Services, MAC PIB attributes, and device capabilities are defined in Section 7 Support for security is defined in Section 8.

[0405] 5.1 MAC Overview This section defines most of the MAC functions. This section covers the frame transmission procedure that is initiated through the MCPS-DATA.request primitive until the start of PSDU processing through the PHY. Similarly, the frame reception procedure that starts after successful reception of the PSDU through the PHY and until the trigger of the MCPS-DATA.indication primitive is described.

[0406] OWPAN can operate in either beacon-enabled mode or beacon-disabled mode. Depending on which mode is used by the coordinator, channel access is performed differently. However, the remaining transmission and reception processes are the same regardless of the channel access mechanism applied.

[0407] 5.1.1 Transmission Process The transmission process starts when the MAC receives an MSDU through the MCPS-SAP or when the MLME requests the transmission of a management frame.

[0408] The MAC is assumed (in some examples) to maintain a conversion table between MAC-48 addresses and short device addresses.

[0409] The device prepares the MPDU for transmission according to the maximum time duration as defined through the applied channel access mode. Details of obtaining the transmission opportunity depend on the channel access mechanism applied in the associated OWPAN (see Sections 5.2 and 5.3).

[0410] Figure 10-8 shows the MAC transmission process.

[0411] The device ensures (in some examples) that the MPDU size does not exceed the maximum supported PSDU size of the PHY used.

[0412] 5.1.2 Reception Process The reception process starts when the MAC receives an incoming MPDU from the PHY.

[0413] Figure 10-9 shows the MAC reception process.

[0414] After the PSDU is extracted by the PHY, the PSDU enters the MAC through the PHY-SAP it thinks of. The MAC (in some examples) shall then first verify the integrity of the frame based on the FCS included in the frame. If the frame contains an irreparable error, the MAC (in some examples) shall discard the frame. If the frame is successfully received, the MAC may analyze the frame.

[0415] The MAC (in some examples) shall discard frames having a Frame Version not supported in the Frame Control element (6.6.1.1).

[0416] The MAC (in some examples) shall filter frames based on the included receiver address. The MAC (in some examples) shall discard all frames that are not unicast to itself or not addressed to the broadcast address. If the device is a member of the multicast group to which the frame is addressed, the MAC (in some examples) shall also not discard the frame. The MAC (in some examples) shall also discard data and management frames that do not belong to the OWPAN to which the MAC is associated.

[0417] For the remaining received frames indicating the use of security in the header, the MAC (in some examples) shall perform decryption, reliability verification, and replay detection and prevention as detailed in each security section. For that purpose, the MAC utilizes the security information included in the Auxiliary Security Header of the frame as specified in each section of the security type.

[0418] If the frame indicates that it contains a fragment, the MAC shall (in some examples) buffer the frame and perform reassembly in accordance with 5.5. Subsequently, if the frame contains an aggregated MSDU, the MAC shall (in some examples) perform de-aggregation in accordance with 5.6.2.

[0419] For each received MSDU, the MAC shall (in some examples) remove duplicates in accordance with Section 5.7. Finally, the MAC shall (in some examples) generate an acknowledgement for each successfully received MSDU in accordance with 5.7.1 or 5.7.2, depending on the configuration.

[0420] 5.2 Beacon-enabled Channel Access When the OWPAN operates in beacon-enabled channel access mode, the channel time is divided into subsequent superframes. Each superframe consists of three main parts: beacon transmission, an optional contention access period (CAP), and a contention-free period (CFP).

[0421] Transmission of beacons by the OWPAN coordinator is described in 5.2.2.

[0422] In the CAP, devices may access the channel randomly by slotted ALOHA. Random access channels in the CAP may be allowed only for specific procedures and frame types as defined in 5.2.3.

[0423] All other frame transmissions occur in the CFP (see 5.2.4). The CFP consists of reserved resources and invoked GTSs, which are allocated to each device for a given superframe. The coordinator schedules and announces GTS allocations as described in 5.2.5.

[0424] 5.2.1 Superframe Structure The superframe can consist of a total of macNumSuperframeSlots superframe slots. macNumSuperframeSlots is a variable determined by the OWPAN coordinator and is notified to the devices in the beacon frame. The maximum number of superframe slots in a superframe is 65535 (see 6.6.1.10). Each superframe slot has a duration of aSuperframeSlotDuration. The number of superframe slots and their respective durations determine the total duration of each superframe.

[0425] This disclosure utilizes an integer number of superframe slots to specify the durations within a superframe. It may be the durations of the CAP, CAP slots, GTS, and other parts of the superframe.

[0426] Each OWPAN coordinator defines the superframe structure for its coordinated OWPAN. Successive superframes of an OWPAN do not necessarily have to be adjacent, but may have channel time between superframes not used by the OWPAN.

[0427] In a coordinated topology, the master coordinator determines when each OWPAN's superframe starts and how long it is. Details of the coordinated topology are outside the scope of this disclosure.

[0428] As shown in Figure 10-10, out of the macNumSuperframeSlots superframe slots in a superframe, three consecutive slot groups are used for beacon transmission, CAP, and CFP, respectively. The number of superframe slots reserved for beacon transmission depends on the length of the beacon frame. The length of the CAP is determined by the OWPAN coordinator and can vary from superframe to superframe. The remaining slots in the superframe are used for the CFP and may be used for frame transmission between devices and the coordinator.

[0429] 5.2.2 Beacon Transmission In the beacon-enabled channel access mode, the coordinator shall (in some examples) transmit a beacon at the beginning of the superframe. The beacon frame is a control frame that contains either only the Superframe Descriptor element or, alternatively, additional elements via the Superframe Descriptor element and the Variable Element Container element. The beacon should be transmitted at regular intervals when possible. Changes to the superframe timing may occur, for example, when the beacon period changes.

[0430] The coordinator shall (in some examples) maintain the macBeaconNumber PIB attribute and increment it by one for each started superframe and corresponding beacon transmission. macBeaconNumber may wrap around to 1 after reaching the highest possible value. The highest possible value is determined by the coordinator.

[0431] The coordinator shall (in some examples) embed the current macBeaconNumber into the Superframe Descriptor element of each beacon. When receiving a beacon frame, each associated device shall (in some examples) set the value of their macBeaconNumber attribute to the value in the received beacon frame.

[0432] Upon receiving a beacon frame, the device shall (in some examples) synchronize its clock to the received beacon frame as described in 5.2.6. Further, a device that either associates with the corresponding OWPAN or attempts to associate with a given OWPAN shall (in some examples) set its macNumSuperframeSlots and macCapSlotLength attributes of the MAC to the values contained in the received Superframe Descriptor element.

[0433] When multiple OFEs are used by the regulator, the beacon frame shall (in some examples) be transmitted simultaneously across all OFEs. If the regulator supports the capMultiOfeFeedback capability, the regulator shall (in some examples) embed orthogonal pilot symbols in the beacon frame as detailed in section 5.8.4.

[0434] The device shall (in some examples) expect the next beacon reception immediately following the superframe. If no beacon frame is detected, the device shall (in some examples) continue to listen for the next beacon frame to synchronize before attempting further transmissions.

[0435] 5.2.3 Medium Access in CAP CAP shall (in some examples) a) be used only for frame transmissions in the association procedure (see 5.2.3.1) b) be used only for frame transmissions in the resource request procedure (see 5.2.3.2).

[0436] ​The CAP shall (in some examples) start in a superframe slot following the beacon and end before the start of the CFP at the superframe slot boundary. The length of the CAP is advertised in the beacon frame (see 6.6.1.10). Both the CAP period and the CFP period may be dynamically shortened or lengthened per superframe to allow for more random access transmissions in the CAP or more scheduled transmissions in the CFP.

[0437] The slotted Aloha scheme is used for contention-based access in the CAP. The superframe slots within the CAP are grouped in so-called CAP slots, each of which comprises macCapSlotLength superframe slots. The number of superframe slots per CAP slot determines the slot size for the slotted Aloha scheme and thus the effectiveness of collision prevention. macCapSlotLength is advertised in the beacon frame (Section 6.6.1.10).

[0438] A device wishing to transmit shall (in some examples) randomly select a number of CAP slots RS-uniformly from [1, CW], where CW is equal to aInitialCapCw for the first attempted transmission. The random number generators of all devices shall (in some examples) be statistically uncorrelated. Subsequently, the device shall (in some examples) wait for an RS CAP slot before attempting to transmit. The waiting process may extend over multiple superframes until the entire RS CAP slot has elapsed. Transmission shall (in some examples) then be performed at the first boundary of the next CAP slot.

[0439] Transmissions in the CAP may not be acknowledged like other frames, as defined in 5.7. For example, if the device implicitly detects that the CAP transmission has not been successful due to the fact that the expected response has not been received, the device shall (in some examples) increment the variable RC by 1. RC shall (in some examples) be 0 initially. How to detect an unsuccessful CAP transmission depends on the specific procedure. Details are given in Sections 5.2.3.1 and 5.2.3.2 respectively. The CAP transmission shall (in some examples) ultimately be abandoned if RC exceeds an implementation-specific value.

[0440] For each failed transmission, the device shall (in some examples) double the CW before attempting to retransmit the frame in the CAP. However, the CW shall not exceed aMaximumCapCw. For retransmission, the device shall (in some examples) then wait again for a random number of CAP slots RS derived from [1, CW] and seek retransmission at the beginning of the subsequent CAP slot.

[0441] Following the CAP transmission, the device shall (in some examples) continuously listen in the CFP to receive possible responses to the frame transmitted in the CAP.

[0442] The process of CAP transmission is visualized for the association procedure and the resource request procedure in Figures 10-4 and 10-5 respectively.

[0443] 5.2.3.1 Association Procedure in the CAP Since the device has not been assigned a GTS prior to association, the association request frame shall (in some examples) be transmitted in the CAP. Therefore, the requesting device shall start the CAP transmission procedure after preparing a frame containing the Association Request element as described in 5.4.5.

[0444] If the device supports the capMultiOfeFeedback capability, the device shall (in some examples) include a Multi-OFE Feedback element that includes CSI obtained from the reception of the latest beacon frame in the same frame. If the beacon does not include additional multi-OFE channel estimation pilots, the device shall (in some examples) not include a Multi-OFE Feedback element.

[0445] A flowchart of the association request procedure is given in FIGS. 10-11.

[0446] If the device to be associated does not receive an Association Response after a number of superframes that depends on the implementation form, the device may presume that the transmission of the Association Request has failed. In that case, the device shall (in some examples) attempt to retransmit the Association Request in the CAP as described in 5.2.3.

[0447] 5.2.3.2 Resource Request Procedure in CAP When the device has no GTS time allocated for its transmission or (in some examples) has only insufficient GTS time, the device may execute a resource request procedure. For example, this may occur after the connection from the coordinator is interrupted and the coordinator stops allocating GTS to the device.

[0448] In that case, the device may transmit a control frame in the CAP to signal the requirements for GTS time to the coordinator. If the capMultiOfeFeedback capability is negotiated during the association, the control frame shall (in some examples) include a Multi-OFE Feedback element that includes multi-OFE CSI obtained from the reception of the latest beacon frame.

[0449] The procedure for GTS requests in the CAP is the same as the association procedure. The corresponding flowchart is shown in Figures 10 - 12.

[0450] 5.2.4 Medium Access in the CFP Channel access in the CFP is based on the principle of dynamic TDMA. Superframe slots can be reserved for each device to enable contention - free medium access. A group of adjacent superframe slots reserved for a particular device is called a Guaranteed Time Slot (GTS). The first superframe slot and the time duration given in an integral number of superframe slots define the position of the GTS in the superframe as described in Section 6.1.13.1. The GTS is (in some examples) assumed to exist only within the CFP.

[0451] The device (in some examples) maintains a list of all future GTSs after it has received the corresponding GTS Descriptor element. The device (in some examples) is assumed to transmit only in the GTSs assigned to the device.

[0452] The device should ensure that the transmitted signal cannot interfere with transmissions in other GTSs at any other device. This includes considering, for example, the overall transmission delay introduced by the PHY being used, as well as the assumed propagation delay and range. The device (in some examples) is assumed to ensure that its transmissions comply with the rules of the inter - frame space as described in 5.2.7.

[0453] A device with GTSs may or may not utilize all the allocated time durations within the GTSs. The selection of MPDUs for transmission is determined locally by the device according to the number of unprocessed frames in the queue, the values of their user priority fields, and possibly other criteria.

[0454] The regulator may perform transmission to the device at any point within the CFP. Thus, all devices (in some examples) must listen for reception throughout the entire CFP. The reverse is also true, where the regulator (in some examples) must listen on the channel for reception between each GTS.

[0455] 5.2.5 GTS Allocation and Signaling (In some examples) only the OWPAN regulator is qualified to allocate (de - allocate) GTSs. Assume that any allocated GTS (in some examples) is located within the CFP.

[0456] When the regulator supervises multiple spatially - distributed OFEs, the regulator may allocate the same super - frame slot in different GTSs to multiple spatially - separated devices in order to facilitate spatial reuse of resources across the entire OWPAN coverage area. However, the regulator (in some examples) must ensure that transmissions from and to devices sharing the same super - frame slot do not interfere.

[0457] Devices assist the regulator in the GTS allocation process by providing information about the state of their queues to ensure flow.

[0458] Devices assist the regulator in avoiding interference in the GTS allocation process by providing information about the signal strength when receiving the nearest OFE.

[0459] The regulator may move the GTSs within the super - frame for each super - frame. Thereby, the regulator relocates the GTS assignments, optimizes resource utilization, and gains flexibility to prevent GTS collisions when visibility and signal strength vary between the OFE and the device due to the movement.

[0460] The GTS scheduling is (in some examples) advertised from the regulator to the corresponding device via a control frame that includes GTS Descriptor elements. These control frames are (in some examples) unicast and are (in some examples) received only by the device to which the GTS scheduling is specified. The GTS scheduling is (in some examples) to immediately overwrite all existing GTS schedulings in the device. The previously allocated GTSs are (in some examples) not used after receiving the new GTS scheduling. The GTS scheduling becomes effective in a subsequent superframe or in the superframe indicated in the GTS scheduling frame.

[0461] 5.2.6 Synchronization All devices are (in some examples) synchronized to the regulator's clock before starting to transmit or receive, whether they are associated with a beacon-enabled OWPAN or are attempting to associate. The beacon transmitted at the beginning of each superframe enables the synchronization of devices in the beacon-enabled OWPAN through arrival time synchronization.

[0462] Each device in the OWPAN including the regulator is (in some examples) to start counting from the first superframe slot at the beginning of the beacon's PHY preamble as shown in Figure 10-13. Thus, all superframe slots, and hence the timing within the superframe, are relative to the start of the beacon preamble.

[0463] The implementation of compliant devices maintains the accuracy of the local time (in some examples) to be at least as accurate as aClockAccuracy.

[0464] 5.2.7 Interframe Space The only IFS (in some examples) defined by this disclosure is the Turn Around Interframe Space (TAIFS). TAIFS is necessary to ensure that there is sufficient turnaround time between transmissions. The turnaround time is defined as the maximum time that the transceiver requires to switch from transmitting to being ready to receive, or from receiving to starting a subsequent transmission. The transmitter must ensure that its transmission ends at least TAIFS before the end of the GTS, in order to allow all receiving devices to fully utilize their GTS from the start. TAIFS is (in some examples) at least the maximum expected turnaround time as defined for each PHY.

[0465] If the device can ensure that all other devices transmit and receive in order in their GTS, for example by implementing the capFullDuplex capability, the device may ignore the requirement to end its transmission at least TAIFS before the end of the GTS.

[0466] The space between consecutive transmissions of a single transmitter is not strictly required. The receiver is expected to be able to process incoming frames fast enough to handle consecutive transmissions.

[0467] 5.2.8 Guard Time In a TDMA system, guard time is required to prevent transmissions in adjacent GTSs from colliding when the device's local clock is not fully synchronized, for example through drift caused by inaccuracies in the frequency of the device's local clock. The GTS is defined by a start time and a time duration (see Section 6.6.1.13) as specified in the GTS element. The guard time is the time between the end of one GTS and the start of the next GTS.

[0468] Figures 10 - 14 illustrate an example of a guard time such that successive transmissions are always at least TAIFS apart when the owner of an adjacent GTS drifts towards another GTS.

[0469] The required guard time depends on the maximum drift MaxDrift between the local time and the ideal time of the device. This drift is a function of the synchronized reference event, i.e., the time elapsed since beacon reception, and the accuracy of the OFE defining the local sampling clock and the local oscillator in the device. In IEEE 802.15.13 OWPAN, the synchronization event is the start of the preamble of the beacon. The maximum drift MaxDrift can be calculated as follows. MaxDrift = clock accuracy / superframe time length

[0470] The clock accuracy depends on the implementation form of the device, but (in some examples) is assumed to be no worse than the value given by the aClockAccuracy PIB attribute. The superframe time length is the current time length of the superframe and thus the period of the synchronization event.

[0471] The synchronization accuracy SyncAccuracy describes how accurately the device can be synchronized to the regulator's clock. This value depends on the implementation form of the regulator and (in some examples) is determined by the vendor. The value (in some examples) includes the uncertainty introduced through the varying propagation time of the beacon frame on which the synchronization is based.

[0472] The regulator (in some examples) ensures that there is a guard time of at least 2·(MaxDrift + SyncAccuracy) between two successive GTSs that are not spatially orthogonal.

[0473] 5.3 Non - Beacon - Compatible Channel Access [Refer to Document 15 - 18 - 0488 - 01 - 0013]

[0474] 5.4 OWPAN Management This section describes the scanning of existing OWPANs, the initiation of new OWPANs, and the association and disassociation of devices with existing OWPANs.

[0475] 5.4.1 Scanning of OWPANs To detect any OWPAN operating nearby, a scanning procedure is executed by the device. In optical communication, a single frequency range in the baseband is used for all transmissions. Thus, the scanning of existing OWPANs is reduced to the scanning of a single frequency channel. However, multiple OWPANs may be coordinated by a master regulator and share the overall available channel time.

[0476] IEEE 802.15.13 devices are assumed (in some examples) to support passive scanning of OWPANs. During passive scanning, the device not only listens for incoming frames but also listens for undecodable signals whose received power exceeds the macEdScanThreshold threshold. If the device utilizes multiple optical front-ends, the device is assumed (in some examples) to listen on all front-ends and attempt to decode the reception for each front-end individually.

[0477] Scanning is initiated by a request from the DME through the MLME-SCAN.request primitive or by the MLME itself. A device instructed to scan an OWPAN is assumed (in some examples) to listen for beacons or RA frames received during the same period. During scanning, the MAC sublayer is assumed (in some examples) to discard all other received frames.

[0478] For each successfully decoded beacon or RA frame during the scan period, the device shall (in some examples) add the corresponding OWPAN ID and OWPAN name to the scan result list. The device shall (in some examples) further add the received electrical SNR and the security type as indicated in the frame to the result list. The returned list shall (in some examples) not contain duplicate entries.

[0479] If the device detects at least one undecodable signal having a received power exceeding macEdScanThreshold during the scan time, the device shall (in some examples) add an entry with OWPAN ID = 0xFFFF, OWPAN name = "Unknown", and the received power level of the strongest received signal to the scan result list.

[0480] If the scan is initiated through the MLME-SCAN.request primitive, the results of the scan shall (in some examples) be returned via the MLME-SCAN.confirm primitive.

[0481] 5.4.2 OWPAN Start The process of starting a new OWPAN is initiated after the coordinator-capable device is so instructed through the MLME-START.request primitive of the MLME-SAP. This section describes the steps involved in starting and maintaining an OWPAN. If a future coordinator had previously maintained an OWPAN, the DME shall (in some examples) stop the OWPAN according to 5.4.4 before starting a new OWPAN in order to reset all MAC and PHY states and disassociate any potentially associated devices.

[0482] The DME shall (in some examples) perform a scan immediately before attempting to start a new OWPAN. The DME shall (in some examples) issue an MLME-START.request primitive only if the corresponding scan reports an empty result list or if resource coordination among multiple OWPAN coordinators can be provided through a coordinated topology.

[0483] The DME of a future coordinator shall (in some examples) select an OWPAN ID and an OWPAN name. If the coordinator implements the capShortAddressing capability, the coordinator shall (in some examples) adopt the selected OWPAN ID as its short address. The DME shall (in some examples) provide the selected OWPAN ID, OWPAN name, and its short address as parameters of the MLME-START.request. The MAC shall (in some examples) set the macSecurityType attribute to the security type conveyed via the MLME-START.request primitive.

[0484] Note - The OWPAN ID may be assigned by the master coordinator. Two adjacent OWPANs shall (in some examples) not use the same OWPAN ID. Two OWPANs may use the same OWPAN name.

[0485] Upon receiving an MLME-START.request, the MLME of a future coordinator shall (in some examples) prepare for operation as a coordinator and subsequently begin transmitting frames according to the configured channel access mode.

[0486] 5.4.3 OWPAN Maintenance After a successful start of the OWPAN, the coordinator and associated devices shall (in some examples) support the primitives of the MCPS-SAP and the corresponding MAC data path functions, as well as the primitives of the MLME-SAP that implement some of the supported capabilities.

[0487] The regulator may change the parameters of the operating OWPAN such that devices associated with the OWPAN need to modify their respective PIB attributes. To control the PIB attributes of the associated devices, the regulator may send an Attribute Change Request element to the relevant devices. The Attribute Change Request element shall (in some examples) include the corresponding PIB attribute name and the new value to be set.

[0488] The device receiving the Attribute Change Request shall (in some examples) modify the value of the indicated attribute to reflect the requested change. Subsequently, the device shall (in some examples) respond to the regulator with an Attribute Change Response indicating the result of the attempted attribute change.

[0489] 5.4.4 Stopping the OWPAN To stop an existing OWPAN, the DME of the regulator shall (in some examples) issue an MLME-STOP.request through the MLME-SAP. Upon receiving the primitive, the regulator shall (in some examples) disassociate all associated devices with an appropriate reason code. Subsequently, the DME of the regulator shall (in some examples) eliminate all states brought about during the operation time of the OWPAN.

[0490] 5.4.5 Association with the OWPAN The association procedure involves multiple steps. 1. Request an association with the target to obtain (temporary) channel access 2. Optional request authentication as required by the OWPAN

[0491] 5.4.5.1 Association Request The device MLME is instructed by the DME to attempt an association with an existing OWPAN through the MLME-ASSOCIATE.request primitive. Before starting the association procedure, the device shall (in some examples) reset all states including the queue and the variables of its MAC.

[0492] After receiving the MLME-ASSOCIATE.request, the device shall (in some examples) prepare a management frame to be sent to the OWPAN coordinator. The management frame shall (in some examples) contain an Association Request element either by being a dedicated Association Request frame or by having an Association Request element included by other means.

[0493] The Association Request element shall (in some examples) contain the capabilities supported by the device for the desired association. Further, the request shall (in some examples) contain the mandatory information as detailed in subclause 6.6.1.3.

[0494] The requesting device shall (in some examples) send the management frame to the OWPAN coordinator according to the channel access rules for the association. These vary according to the applicable channel access mode in the OWPAN as detailed in clauses 5.2 and 5.3 respectively. The frame shall (in some examples) be sent unprotected (see clause 5.7).

[0495] If the regulator MLME determines to pursue an association, the regulator MLME shall (in some examples) prepare a management frame that includes an Association Response element. The Association Response element shall (in some examples) include a set of capabilities that will be used during a future association. The set of capabilities shall (in some examples) not include capabilities other than those previously indicated by the device in the Association Request element. The precise set of capabilities may be selected by the regulator.

[0496] If the regulator determines not to pursue an association, the regulator shall (in some examples) provide an Association Response element with an appropriate set of Status Codes.

[0497] If OWPAN is secure and further authentication is required, the Association Response element shall (in some examples) include further information required for subsequent authentication of the device as detailed in clause 8. After successful reception of the Association Response element, the device shall (in some examples) perform authentication using the OWPAN regulator if necessary.

[0498] A sequence chart of the successful association procedure is shown in Figure 10-16.

[0499] 5.4.5.2 Authentication Requirements If the Association Response element received by the device indicates that further authentication is required, the device shall (in some examples) process the authentication material included in the Association Response element corresponding to the applicable security type. The resulting authentication data shall (in some examples) then be included in the Association Request element and transmitted to the regulator via a management frame.

[0500] For the transmission of the Association Request element, the coordinator may grant temporary channel access to the device to be associated. If not, the device may send an Association Request element similar to the association request in the CAP.

[0501] After receiving the Association Request element from the device to be associated, the coordinator MLME (in some examples) shall indicate to the DME, via MLME - AUTHENTICATE.indication, that the device is requesting authentication. The DME (in some examples) shall then authenticate the device and provide the result to the MLME via MLME - AUTHENTICATE.request. The DME (in some examples) shall respond to the MLME - AUTHENTICATE.indication within 30 seconds.

[0502] The MLME (in some examples) shall send an Association Response element to the device attempting the association. If authentication is successful, the device (in some examples) shall be considered to be associated with the OWPAN. During the time the association is in progress, the device (in some examples) shall utilize the security required by the OWPAN and detailed in the respective security type sections, namely encryption, integrity protection, and replay protection.

[0503] After receiving a positive response to the frame containing the Association Response element or the Authentication Response element respectively, the coordinator may consider the device to have successfully associated.

[0504] 5.4.6 Dissociation from the OWPAN The disassociation of a single device from the OWPAN may be initiated through the MLME-DISASSOCIATE.request primitive, either by the OWPAN coordinator or by the device itself being affected.

[0505] To disassociate a device from the OWPAN, the coordinator shall (in some examples) send a management frame containing a Disassociation Notification element to the device to be disassociated, as shown in Figure 10-17 a). If the coordinator does not receive the corresponding positive acknowledgment frame, the coordinator may (in some examples) consider the device to be disassociated after not receiving further frames from the device for the timeout provided as a Timeout primitive parameter.

[0506] A device desiring to disassociate from the OWPAN shall (in some examples) send a management frame containing a Disassociation Notification element to the OWPAN coordinator, as shown in Figure 10-17 b). That device may (in some examples) consider itself to be disassociated after receiving a positive acknowledgment for the management frame sent.

[0507] 5.5 Fragmentation and reassembly Fragmentation may be performed by the transmitting device on the MSDU or A-MSDU. The (A-)MSDU shall (in some examples) be fragmented into a maximum of 16 fragments. All fragments shall (in some examples) contain an even number of octets, except for the last fragment which may contain an odd number of octets. Once the (A-)MSDU has been fragmented and transmission is attempted, it shall (in some examples) not be fragmented again. The minimum size of the fragments, excluding the last fragment, shall (in some examples) be at least aMinFragmentSize.

[0508] Assume that (in some examples) MPDUs containing fragmented MSDUs or A-MSDUs have a Sequence Control element. Assume that (in some examples) all fragments except the last fragment are transmitted with the Last Fragment field of the data MPDU set to 0. Assume that (in some examples) the last fragment has the Last Fragment field set to 1. Assume that (in some examples) each subsequent fragment may be transmitted with the Fragment Number field incremented. However, assume that (in some examples) the Fragment Number field is not incremented when a fragment is retransmitted.

[0509] Assume that (in some examples) MPDUs containing fragments have a sequence number that exists within the Sequence Control element of the header. Thus, assume that (in some examples) fragmented (A-)MSDUs are always transmitted in a protected state. Assume that (in some examples) all fragments of the same (A-)MSDU have the same sequence number in the MPDU header. Defragmentation of an (A-)MSDU is the reassembly of the received fragments into a complete (A-)MSDU. Assume that (in some examples) the (A-)MSDU is completely reassembled in the correct order before being passed to a higher layer.

[0510] The receiving device may discard a fragment of an MSDU if it is not completely received within a timeout determined by the receiving device. The destination device may also discard the oldest incomplete MSDU if a buffer overflow would otherwise occur. Fragments are (in some examples) to be transmitted in the order of the fragment numbers. If a no-ACK policy is used, the destination device (in some examples) is to immediately discard the MSDU if a fragment is missing. Devices (in some examples) are to support the simultaneous reception of at least three fragments of an MSDU.

[0511] 5.6 Aggregation To avoid the overhead of transmitting multiple MPDUs and corresponding PPDUs, a device may aggregate multiple MSDUs into a single MPDU. The aggregated MSDUs (A-MSDUs) are transmitted in the payload of a data frame of the A-MSDU subtype (see 6.3).

[0512] 5.6.1 Aggregation Procedure When the device MAC determines to aggregate multiple MSDUs into a single MPDU, the aggregation procedure is applied as part of the transmission process detailed in Figure 10-8.

[0513] The device (in some examples) shall simply transmit multiple MSDUs in a single MPDU if the MSDUs have the same destination address through which they are carried via the MCPS-DATA.request primitive. All MSDUs within an A-MSDU (in some examples) shall either be protected or not. The protected MSDUs (in some examples) shall not be mixed with the unprotected MSDUs. The overall resulting MPDU size in octets, which results from all aggregated MSDUs and the additional fields for aggregation, (in some examples) shall not exceed the phyMaxPsduSize of the PHY being used.

[0514] Each MSDU that is to be part of an A-MSDU (in some examples) may be wrapped in an MSDU Aggregation element. The MSDU Aggregation element (in some examples) shall include the overall length of the wrapped MSDU in octets. Further, the MSDU Aggregation element (in some examples) shall include the sequence number assigned to the MSDU.

[0515] If an MPDU containing aggregated MSDUs is successfully transmitted, the MPDU (in some examples) shall be assigned a single sequence number, as if it were an MPDU containing only a single MSDU (in some examples). Upon receiving an acknowledgement from the receiver of the MPDU, all MSDUs contained in the MPDU (in some examples) shall be acknowledged and thus considered to have been successfully transmitted.

[0516] Figure 10-18 shows aggregation and fragmentation during frame transmission. Three MSDUs arriving at the MAC through the MCPS-SAP are aggregated by being included in an MSDU Aggregation element (abbreviated as MAE). However, aggregation is optional.

[0517] An A-MSDU may optionally be fragmented. In an example, an A-MSDU consisting of three MSDUs A, B, and C is split into two fragments, each wrapped in an MPDU. The MPDU contains a new sequence number, which helps in the reassembly of the A-MSDU at the receiver. That sequence number may not be acknowledged by the receiver device. However, each MSDU within the A-MSDU has a sequence number associated in the MSDU Aggregation element. These sequence numbers must (in some examples) be acknowledged by the receiver if the Frame Control element of the MPDU has the Ack Request bit set.

[0518] 5.6.2 Aggregation Disassembly Procedure When a device receives an A-MSDU data frame, the device first (in some examples) verifies the integrity of the entire MPDU based on the MPDU FCS field. If the MPDU is received without error, the device is assumed (in some examples) to acknowledge the corresponding sequence number of the MPDU.

[0519] Subsequently, the receiving device is assumed (in some examples) to separate the payload of the A-MSDU frame into individual MSDU Aggregation elements based on the size given in the MSDU Aggregation element. The MAC then (in some examples) verifies the integrity of each MSDU based on the FCS contained in the corresponding MSDU Aggregation element. If the MSDU is received without error, the MAC is assumed (in some examples) to acknowledge the corresponding sequence number contained in the MSDU Aggregation element.

[0520] Figure 10-19 shows the reassembly and aggregation disassembly procedures. Two MPDUs 1 and 2 are received from the PHY.

[0521] 5.7 Protected Transmissions Transmissions between IEEE 802.15.13 devices may be protected. The protection ensures that during a transmission between two MACs, the MSDU is not duplicated or reordered. Moreover, the protection prevents the loss of the MSDU by means of an acknowledgment and retransmission mechanism. For that purpose, a sequence number is assigned to every MSDU transmitted.

[0522] Each device (in some examples) shall maintain an individual sequence number counter for transmissions to each peer device. The sequence number is a 12-bit wide unsigned integer, which wraps around to 0 after the highest possible value. The sequence number (in some examples) shall be assigned to every MSDU received through the MCPS-SAP based on the destination address.

[0523] Each transmitted MPDU (in some examples) shall contain a Sequence Control element if it contains an MSDU that requires protected transmission. For a single MSDU data MPDU, the Sequence Control element (in some examples) shall contain the sequence number assigned to the MSDU. For an A-MSDU, the MPDU (in some examples) shall contain a new sequence number, which maps to all the sequence numbers of the MSDUs contained. Still, each MSDU within the A-MSDU still has its own unique sequence number.

[0524] The transmitting device (in some examples) shall not transmit more than aProtectedWindow MSDUs that have not been acknowledged.

[0525] (A-)MSDU receivers can detect missing MSDUs based on the fact that they do not receive a certain sequence number. The receiver can detect duplicate MSDUs based on the fact that it receives MSDUs with the same sequence number multiple times. Two received MSDUs with the same sequence number are (in some examples) not considered duplicates if the receiver has received more than aProtectedWindow unique sequence numbers since the reception of the first of the potentially duplicate MSDUs. The receiver (in some examples) discards the last received duplicate.

[0526] If an MPDU indicates a transmitted packet that has been positively acknowledged and has an ACK Request bit set in the Frame Control and Sequence Control elements, the receiver (in some examples) acknowledges the successful transmission using one of the following positive acknowledgment types. · Single positive acknowledgment (Section 5.7.1) · Block positive acknowledgment (Section 5.7.2)

[0527] Otherwise, the receiver (in some examples) does not send a positive acknowledgment.

[0528] 5.7.1 Single Positive Acknowledgment The MSDU receiver may decide to acknowledge successful reception with a single positive acknowledgment. Thus, the information returned to the transmitter contains only information about the successful reception of a single MSDU.

[0529] The positive acknowledgment information is (in some examples) embedded as part of any of the following in the Acknowledgment Information element. · The header of any data or management frame · In a dedicated Acknowledgment control frame, containing only the Acknowledgment Information element in its payload (in some examples) ·In any frame containing a Variable Element Container element, it contains an Acknowledgment Information element

[0530] 5.7.2 Block Acknowledgment The receiver may acknowledge successfully received MSDUs by cumulative acknowledgments. The corresponding block acknowledgment frame includes information about one or more successfully received MPDUs in an aggregated manner by including a Block Acknowledgment element.

[0531] The receiver may send a block acknowledgment either without being requested or upon request by the transmitter of the received MPDU through a Block Acknowledgment Request element.

[0532] The block acknowledgment element is (in some examples) to be sent only in a frame with a unique source address. The source address of the frame containing the Block Acknowledgment element identifies the device sending the acknowledgment.

[0533] 5.7.3 Retransmission The device is (in some examples) to retransmit the protected MSDU after the device has not been acknowledged for at least macRetransmitTimeout. The macRetransmitTimeout PIB attribute may be adjusted by the coordinator through the parameter management procedure described in 5.4.3.

[0534] 5.8 Adaptive Transmission and Channel State Feedback The device may select a rate for each transmitted PPDU based on available information about the channel between the device itself and the receiver, for example, by selecting modulation and coding. This information is typically obtained from each specified receiver via a feedback mechanism or is inferred by the transmitter by other means.

[0535] 5.8.1 Multi-rate MCS The IEEE 802.15.13 PHY is capable of transmitting frames under the application of varying modulation and coding schemes (MCS). The specific definition of MCS depends on the PHY being used. It may include details regarding error coding and modulation.

[0536] By default, the device may freely select an MCS for transmission to another device. The rate selection algorithm is outside the scope of this disclosure. However, for some frames, the use of specific modulation and coding is mandatory (see 5.8.2).

[0537] If two devices support the capEffectiveChannelFeedback capability, the future receiver of a frame may request the use of a specific MCS from the future transmitter (see 5.8.3).

[0538] 5.8.2 Transmission of Mandatory Frames Some frames (in some examples) shall be transmitted at the basic rate specific to the PHY being used, as defined in each respective section of each PHY.

[0539] The frames to be transmitted at the basic rate are listed in Table 1 (Table 6).

[0540]

Table 6

[0541] 5.8.3 MCS Requirement Feedback IEEE 802.15.13 devices that support the capEffectiveChannelFeedback capability are able to measure the quality of signals received from other devices. Moreover, it is assumed that it can (in some examples) transmit an MCS Request control frame and process the received modulation request control frame as follows.

[0542] The MCS Request control frame is transmitted from a future receiver to a future transmitter. The future receiver may send an MCS Request element if it detects that the previously requested MCS may not be successfully decodable or that a higher rate MCS may be used.

[0543] If a device receives an MCS Request control frame from another device, the device is assumed to (in some examples) utilize the modulation and coding scheme requested for subsequent transmissions if it does not have frames that require special modulation and coding as defined in 5.8.2.

[0544] 5.8.3.1 Bit Loading MCS Request If cabHbPhy is negotiated during an association, a device (including a regulator) may request the use of a certain BAT from a future transmitter. Moreover, each device is assumed to (in some examples) measure the effective channel during each reception of a unicast frame to the device. If the result indicates that the previously requested BAT is not successfully decodable, the device is assumed to (in some examples) request the use of a new sufficiently robust BAT from the transmitter. The device may also request the use of a new BAT, for example, to increase throughput because the channel quality has improved.

[0545] In response to the request, the device is assumed to (in some examples) prepare a BAT Request element as follows.

[0546] The Valid Bat Bitmap field (in some examples) shall indicate a set of BATs that may be used for transmission to the device. The bitmap (in some examples) shall only indicate BATs that the device is confident that future transmitters will take the same configuration as the device. For BATs that may have different configurations in the device and future transmitters, the device (in some examples) shall set the bits in the bitmap to 0. How to infer that future transmitters will have the same configuration for BATs will be further described in words.

[0547] The Updated BAT field (in some examples) shall indicate a new BAD ID that was previously invalid and for which a new configuration is required. The FEC Block Size field (in some examples) shall include a block size for error coding, and the FEC Code Rate field (in some examples) shall include a code rate that is rest to be used for subsequent transmissions.

[0548] The device (in some examples) shall fill the BAT Group 1…N fields with the required bits per subcarrier. This may form multiple groups that include a varying number of subcarriers so as to have the same modulation format. The total number of groups (in some examples) shall cover all available subcarriers of the PHY. The total number of subcarriers covered by a group may be more than the actual number of subcarriers. In that case, the surplus subcarriers included in the last BAT Group (in some examples) shall be ignored.

[0549] The device shall (in some examples) transmit a BAT Request element in a control frame or a management frame. When the device transmits an element via a control frame, the device cannot anticipate an affirmative response and thus does not know whether a future transmitter has received the request.

[0550] 5.8.4 Multi-OFE Channel Feedback A regulator that supports the capMultiOfeFeedback capability shall (in some examples) be capable of transmitting a multi-OFE pilot, while a non-regulator device that supports the capMultiOfeFeedback capability shall (in some examples) be capable of receiving a multi-OFE pilot and subsequently estimating the channels between each transmitter of the multi-OFE pilot.

[0551] When a regulator utilizes multiple OFEs, the regulator may embed different segments of multi-OFE pilot symbols into the PPDU for each individual OFE, as defined in 11 and 13. When the regulator is part of a cooperative topology, the segments and time slots to be used for embedding the multi-OFE pilot shall (in some examples) be coordinated by a master regulator for all regulators.

[0552] The receiver of the multi-OFE pilot is capable of estimating the individual CSI between the transmitter of each pilot symbol and the receiver itself, although the signals of multiple transmitters may overlap in time. The CSI collected has time-domain taps, which are described by the respective optical signal power and the relative delay with respect to the first received tap.

[0553] When receiving a PPDU that includes a multi-OFE pilot symbol, the device (in some examples) shall be assumed to estimate the individual channels. The device (in some examples) shall then transmit a Multi-OFE Feedback element, including the measured CSI for each identified OFE of the orthogonal pilots, to the OWPAN regulator.

[0554] (In some examples) the device shall not use a format that provides only values smaller than the actual intensity value for quantization.

[0555] 6 MAC Frame Format This section provides the specification of the frame format used by the MAC.

[0556] 6.1 Bit Order and Representation The figures in Section 6 may represent the information contained in the MAC frame. The figures may show the entire MAC frame, an element, or a field. An element is generally a group of fields used. Elements enhance the readability of this disclosure. The MAC frame is described by the fields and elements it contains.

[0557] 6.1.1 Bit Order The relationship between the processing of MAC frames (meaning transmission or interpretation) and their representation in this disclosure is as follows. Bits, fields, and elements are processed from left to right in the order of their representation in the figures. This relationship is shown in FIGS. 11 to 21.

[0558] When a field contains a numerical value represented by a combination of multiple bits, the bits are processed in the order of prioritizing the MSBit. Thus, the bit with the largest value of the numerical value is processed first. When the numerical value is specified in the binary representation within this disclosure, the MSBit representation is used.

[0559] If the value of a field exceeds the octet length, it is stored within the field in big-endian representation. Thus, the octet containing the MSBit of the value is processed first.

[0560] The "reserved" fields do not carry meaningful information in the current version of this disclosure. This may be changed in a later version. The reserved fields are (in some examples) set to all 0s for transmission and (in some examples) ignored upon reception. The value of the reserved fields (in some examples) shall have no effect on the behavior of the device.

[0561] 6.1.2 Representation The MAC frames or elements in this disclosure are represented as figures in table format. The top row specifies the width of the fields or elements. The second (middle) row provides the description of the field or a reference to the element specified elsewhere in this disclosure. The third (bottom) row is optional and may provide an alternative description of the field or element corresponding to that column. The format is represented in Figures 11-22.

[0562] The width of a field is specified by both the number of bits and the number of octets when the total number of bits can be represented by an integer number of octets.

[0563] In a sequence of consecutive fields starting from the beginning of the parent frame or element and not including a variable width, a field can be described by the first and last bits of the field. The corresponding concept can be read as the word "bit" followed by the designation of the first and last bits represented. This is illustrated for Field 1 in Figure 11-24.

[0564] If a sequence of consecutive fields or elements has a variable width, the width is specified by the word "variable". If there is a field with a variable width between the field and the start of the MAC frame, absolute bit designations cannot be used.

[0565] Note - To enable correct processing of the MAC frame, the width of variable-width elements must be inferable from other fields.

[0566] The width may be given in terms of the number of bits or octets. The corresponding concept includes the number of bits or octets, followed by the word "bit" or "octet", as shown in fields 2, 3, and 5 of FIGS. 11 - 23.

[0567] 6.2 General MAC Frame Format Each MAC frame starts with a Frame Control element defined in 6.6.1.1 that indicates the Type and Subtype of the frame. This disclosure involves three basic frame Types for the transmission of data, management information, and control information.

[0568] Data frames, management frames, and control frames have separate MAC headers, which are detailed in Sections 6.3, 6.4, and 6.5 respectively. And the payload varies for different Subtypes of data frames, management frames, or control frames.

[0569] The payload contains the information to be carried via the MAC frame. For data frames, this may be one or more MSDUs received via the MCPS - SAP for transmission. In management frames, the payload consists of management information. Similarly, the payload of control frames comprises control information that assists the MAC in its operation.

[0570] Each MAC frame (in some examples) shall end with an FCS field that contains a 32 - bit CRC sum over all the preceding information bits of the MAC frame.

[0571] The general MAC frame structure is shown in FIG. 11 - 24.

[0572] 6.2.1 FCS Field The FCS field is a 32-bit field that contains a 32-bit CRC. The FCS is calculated over all fields of the MAC header and the frame body fields. These are called the calculation fields. The FCS is calculated using the 32nd degree generating polynomial of the present disclosure as follows. G(x)=x 32 +x 26 +x 23 +x 22 +x 16 +x 12 +x 11 +x 10 +x 8 +x 7 +x 5 +x 4 +x 2 +x + 1

[0573] The FCS is the one's complement (modulo 2) of the following sum. a) The remainder (modulo 2) of dividing x k (x 31 +x 30 +x 29 +…+x 2 +x + 1) by G(x), where k is the number of bits in the calculation field b) The remainder after multiplying the content of the calculation field (treated as a polynomial) by x 32 and then dividing by G(x)

[0574] The FCS field is transmitted in an order such that the coefficient of the term with the highest degree comes first.

[0575] In a typical implementation, in the transmitter, the first remainder of the division is pre-set to all 1s and then modified by division in the calculation field by the generating polynomial G(x). The one's complement of this remainder is transmitted as the FCS field, with the most significant bit first. In the receiver, the first remainder is pre-set to all 1s, and the successive incoming bits of the calculation field and the FCS, when divided by G(x), result in a non-zero remainder value specific to the absence of a transmission error. The specific remainder value is a polynomial. x 31 +x 30 +x 26 +x 25 +x 24 +x 18 +x 15 +x 14 +x 12 +x 11 +x 10 +x 8 +x 6 +x 5 +x 4 +x 3 +x+1

[0576] 6.3 Data Frame The data frame is responsible for transmitting the MSDU received via the MCPS-SAP to the peer device. The MPDU structure of the data frame is shown in Figure 11-25.

[0577] The Frame Control element is further described in 6.6.1.1. It contains a plurality of bits that determine the remaining structure of the frame header.

[0578] The data frame may carry an ACK Information element in the header. The presence of the ACK Information element is indicated by the ACK Info field in the Frame Control element of the frame. The ACK Information element may be used by the transmitter to acknowledge the successful reception of a previous frame.

[0579] Each data frame has Receiver Address and Transmitter Address fields. These fields may carry either a 16-bit short MAC address or a 48-bit full MAC address. The address format is indicated by the Short Addressing field in the Frame Control element as described in 6.6.1.1.

[0580] The data frame may have up to two additional address fields, Auxiliary Address 1 and Auxiliary Address 2. Whether these exist and what information they carry can be derived from the To Backhaul and From Backhaul fields in the Frame Control element as described in 6.6.1.1.

[0581] Management frames are protected by a sequence number and may be retransmitted if lost. The Sequence Control element is present in management frames that have the ACK Request bit set to 1 in the Frame Control element.

[0582] If the payload is secure, the data frame must have an Auxiliary Security Header. The presence of the Auxiliary Security Header is indicated by the Security Enabled bit in the Frame Control element (6.6.1.1). The format of the Auxiliary Security Header is variable and depends on the details of the security type applied, as defined in clause 8.

[0583] The payload content of the data frame is described by the subtype field of the Frame Control element. Currently, the payload may include different formats as listed in Table 2 (Table 7).

[0584]

Table 7

[0585] For a data frame of Subtype 0000, the payload has a length of 0. These null frames may be used to transmit an MPDU or the corresponding PPDU for various reasons.

[0586] Subtype 0001 indicates that the payload of the data frame contains a single MSDU.

[0587] Subtype 0010 indicates an A-MSDU in the payload of the data frame. The format of the A-MSDU is detailed in 5.6.

[0588] The FCS field of the data frame contains a frame check sequence as defined in 6.2.1.

[0589] 6.4 Management Frames Management frames carry management information that assists in the communication of two MLMEs in different protocol exchange procedures. The MPDU format of the management frames is shown in Figure 11-25.

[0590] Similar to all MAC frames, management frames start with a Frame Control element as further explained in 6.6.1.1.

[0591] Management frames may carry an ACK Information element in their headers. The presence of the ACK Information element is indicated by the ACK Info field in the Frame Control element of the frame. The ACK Information element may be used by the transmitter to acknowledge the successful reception of a previous frame.

[0592] Each management frame has Receiver Address and Transmitter Address fields. These fields may contain either a 16-bit short MAC address or a 48-bit full MAC address. The address format is indicated by the Short Addressing field in the Frame Control element as described in 6.6.1.1.

[0593] Management frames are protected by sequence numbers and may be retransmitted if lost. The Sequence Control element is present in management frames that have the ACK Request bit set to 1 in the Frame Control element.

[0594] The payload of a management frame contains one or more elements defined in 6.6. The subtype describes which elements are present in the payload field. In a simple management frame, the payload consists of only a single element. The elements that should be present for a subtype can be derived from Table 3 (Table 8).

[0595]

Table 8

[0596] The presence of a Variable Element Container element in the payload allows a single management frame to contain more than one element.

[0597] The FCS field of a management frame contains a frame check sequence as defined in 6.2.1.

[0598] 6.5 Control Frames Control frames assist the lower MAC and PHY in their operation. The MPDU structure of a control frame is shown in Figure 11-27.

[0599] As MAC frames, each control frame starts with a Frame Control element, which is further described in 6.6.1.1.

[0600] Each management frame has Receiver Address and Transmitter Address fields. These fields may contain either a 16-bit short MAC address or a 48-bit full MAC address. The address format is indicated by the Short Addressing field in the Frame Control element as described in 6.6.1.1.

[0601] The information carried via control frames is short-lived and becomes obsolete quickly. Therefore, control frames are not retransmitted upon loss. Instead, a new control frame containing the most recent control information may be transmitted.

[0602] Due to their nature, control frames carry a sequence number. As a result, the frame header is kept very simple and contains only (in some cases) the Frame Control element, the Receiver Address field, and the Transmitter Address field.

[0603]

Table 9

[0604] 6.6 Elements An element is a collection of related fields that perform general MAC functions as defined in Section 6.1. Elements may define the content of several frames and may be used to enhance the readability of the document. If an element contains a variable number of fields or other elements, the overall length of the element must be inferable from the content of its fields to enable parsing.

[0605] Each element has an ID assigned to identify the element in some frames. Table 5 (Table 10) lists the elements defined within this disclosure, their corresponding IDs, and the definition clauses.

[0606]

Table 10

[0607] 6.6.1.1 Frame Control Element Figure 11-28 shows an example of a frame control element.

[0608] The Frame Control element comprises a plurality of bits that are responsible for determining the further MAC frame structure or indicating the nature of the payload. The Frame Control element is present at the beginning of each MAC frame.

[0609] Frame Version: The Frame Version subfield specifies the version number corresponding to the frame. In some examples, this subfield is set to "00" to indicate a frame compatible with IEEE 802.15.13. All other values are reserved for future use in some examples.

[0610] Type: In the management frame, the Type field is set to 00 in some examples. In the control frame, this field is 01. In the data frame, this field is set to 00. The value 11 is reserved.

[0611] Subtype: Indicates the subtype of the frame, i.e., the content of the payload.

[0612] To Backhaul / From Backhaul: These fields are necessary for the correct interpretation of the addressing fields of the data frame in the topology where the OWPAN is integrated into the logical LAN. For example, this may apply in a cooperative topology.

[0613] Data frames (MSDUs) within the LAN have a source address and a destination address. In contrast, the receiver address and the transmitter address are the addresses of the 802.15.13 devices for receiving or transmitting the MPDU, respectively.

[0614]

Table 11

[0615] Security Enabled: The Security Enabled field is set to 1 (in some examples) if the frame is to be protected by the MAC sublayer and set to 0 (in some examples) otherwise. The Auxiliary Security Header field of the MHR is assumed to exist (in some examples) only if the Security Enabled subfield is set to 1.

[0616] ACK Request: The Acknowledment Request field specifies whether an acknowledgment is required from the receiver device upon receipt of a data or MAC management / control frame. If this subfield is set to "1", the receiver device is assumed (in some examples) to send an acknowledgment frame. If this subfield is set to "0", the receiver device is assumed (in some examples) not to send an acknowledgment frame.

[0617] ACK Info: Specifies whether the ACK Information element is present in the remaining MAC header. If the ACK information element is present, this field is set to 1 (in some examples). Otherwise, it is set to 0 (in some examples).

[0618] Short Addressing: Indicates whether a short address is used in the address field of the MAC header. If a short address is used in the header, this field is set to 1 (in some examples). Otherwise, it is set to 0 (in some examples). Some addresses, such as the OWPAN ID, are always in short form. Long addresses may be used (in some examples) only for addresses having the equivalent of a MAC-48 address.

[0619] More Fragments: In a data frame, this field is set to 1 (in some examples) if the payload contains fragments of an (A-)MSDU that is not the last fragment. Otherwise, it is set to 0 (in some examples).

[0620] 6.6.1.2 Sequence Control Element Figure 11-29 shows an example of the sequence control element.

[0621] The Sequence Control element contains information for frame fragmentation and reliable transmission.

[0622] Fragment Number: If the MPDU contains fragments of an (A-)MSDU, this field contains the respective fragment number.

[0623] Sequence Number: This field contains the assigned sequence number of the MPDU.

[0624] 6.6.1.3 Association Request Element Figure 11-30 shows an example of an Association Request Element.

[0625] The Association Request element is first sent by the device to the OWPAN coordinator when the device requests an association.

[0626] Device Mac Address: The MAC-48 address of the device requesting the association.

[0627] Capability List: One Capability List element that describes the supported capabilities of the device requesting the association.

[0628] OWPAN ID:

[0629] Supported Rates:

[0630] Extended Supported Rates:

[0631] 6.6.1.4 Association Response Element Figure 11-31 shows an example of an Association Response Element.

[0632] The Association Response element is sent by the coordinator to the device that requested the association.

[0633] Device MAC Address: The MAC-48 address of the device requesting the association.

[0634] Status Code: The status code indicates the result of the previous association request.

[0635]

Table 12

[0636] Capability List: This field contains a Capability List element that describes the set of capabilities that should be used for further channel access if the association is not rejected. If the association is rejected, this field shall be ignored (in some examples).

[0637] Short Address: The short address assigned to the device if the association is not rejected. If the association is rejected, this field shall be ignored (in some examples).

[0638] Supported Rates:

[0639] Extended Supported Rates:

[0640] 6.6.1.5 Reassociation Request Element

[0641] 6.6.1.6 Reassociation Response Element

[0642] 6.6.1.7 Disassociation Notification Element Figure 11-32 shows an example of a disassociation notification element.

[0643] The Disassociation Notification element conveys information about the disassociation of a device from the OWPAN.

[0644] Reason Code: The reason code indicates the reason for the disassociation.

[0645]

Table 13

[0646] OWPAN ID: The OWPAN ID of the device to be disassocated

[0647] Device Short Address: The device to be disassociated from the OWPAN

[0648] 6.6.1.8 Authentication Request Element Figure 11-33 shows an example of the authentication request element.

[0649] The Authentication Request element is sent by the device to the coordinator of that OWPAN to request authentication if required to successfully associate with the OWPAN.

[0650] Authentication Algorithm: The authentication algorithm used for authentication

[0651] Authentication Transaction Token: The authentication algorithm used for authentication

[0652] Status Code: The authentication algorithm used for authentication

[0653] Challenge: The authentication algorithm used for authentication

[0654] 6.6.1.9 Authentication Response Element

[0655] 6.6.1.10 Superframe Descriptor Element Figure 11-34 shows an example of the superframe descriptor element.

[0656] The Superframe Descriptor element conveys information about the starting superframe.

[0657] Superframe Number: The number of subsequent superframes. An integer that wraps around as described in 5.2.2.

[0658] Total Superframe Slots: The number of superframe slots in the subsequent superframe. Devices associated with or attempting to associate with OWPAN shall (in some cases) set their macNumSuperframeSlots PIB attributes to the value contained in this field.

[0659] Superframe Slot Duration: The duration of a single superframe slot.

[0660] CAP Slot Width: The number of superframe slots per CAP slot.

[0661] CAP Slots: The number of CAP slots included in the subsequent CAP.

[0662] 6.6.1.11 OWPAN Descriptor Element Figure 11-35 shows an example of the OWPAN descriptor element.

[0663] The OWPAN Descriptor element conveys information about OWPAN.

[0664] OWPAN Name: The name of the OWPAN as a null-terminated ASCII string. The length shall be (in some cases) between 3 octets and 32 octets including the termination of the string.

[0665] OWPAN ID: The numerical ID of the OWPAN.

[0666] Coordinator Address: MAC-48 address of the OWPAN coordinator.

[0667] Security Type: Security type applied in OWPAN. Valid types are listed in Table 2 (Table 7).

[0668] 6.6.1.12 Capability List Element Figure 11-36 shows an example of a capability list element.

[0669] The Capability List element is used to transfer information about capabilities as described in Section 7.4 between two devices.

[0670] Bitmap Width: Specifies the subsequent Capability Bitmap field in octet units. Thus, the Capability Bitmap field can contain capabilities with a maximum of ID Bitmap Width * 8 - 1. Bitmap Width 0 may be used to indicate an empty list of capabilities if necessary.

[0671] Capability Bitmap: A bitmap indicating a subset of capabilities as given in Table 36 (Table 43). In this bitmap, the leftmost bit, i.e., the bit that will be processed first, corresponds to ID 0. The rightmost bit, i.e., the bit that will be processed last according to the definition given in 6.1.1, corresponds to ID Bitmap Width * 8 - 1. If a capability is included in the subset, the bit corresponding to the ID of the capability is set to 1 (in some examples). Otherwise, the bit is set to 0 (in some examples).

[0672] For example, a one-octet (8-bit) wide bitmap indicating the presence of capabilities with IDs 1, 4, and 7 is 01001001 (processed from left to right).

[0673] 6.6.1.13 GTS Descriptor List Element Figure 11-37 shows an example of a GTS descriptor list element.

[0674] The GTS Descriptor List element holds multiple GTS Descriptor elements for a device in beacon-enabled channel access mode.

[0675] GTS Descriptor Count: This field contains the number of GTS descriptors that follow.

[0676] Validity Present: If set to 1, the child GTS descriptors have a validity field. If not present, it is set to 0.

[0677] Device Address Present: If set to 1, each child GTS Descriptor is assumed to have a Device Short Address field (in some examples).

[0678] GTS Directions: If the Directions Present field is set to 1, this field indicates the direction of the GTSs that follow.

[0679] GTS Descriptor 1…N: These fields contain one or more GTS Descriptor elements.

[0680] 6.6.1.13.1 GTS Descriptor Element Figure 11-38 shows an example of a GTS descriptor element.

[0681] This element describes a single GTS allocation for a device in beacon-enabled channel access mode.

[0682] Device Short Address: This field exists if the parent GTS Descriptor List element has the Device Address Present field set to 1. This field contains the short address of the device to which the GTS is allocated.

[0683] GTS Start Slot: This field specifies the first slot of the allocated GTS.

[0684] GTS Length: This field specifies the time length of the GTS in superframe slots.

[0685] Validity: This field exists if the parent GTS Descriptor List element has the Validity Present field set to 1. This field indicates.

[0686] 6.6.1.14 Multi-OFE Feedback Element Figure 11-39 shows an example of a multi-OFE feedback element.

[0687] The Multi-OFE Feedback element may be used to transfer multi-OFE channel feedback from a device to the OWPAN coordinator.

[0688] Number of OFEs: The number of distinct recognized OFEs. This may determine the total number of OFE Feedback Descriptor elements included.

[0689] Tap format: This field may describe the format of the taps included in the child Tap Descriptor element.

[0690]

Table 14

[0691] OFE Feedback Descriptor Element 1…N: OFE Feedback Descriptor elements that may include CSI for the channel between the device and each OFE being transmitted. The number of elements N may be equal to the Number of OFEs field.

[0692] 6.6.1.14.1 OFE Feedback Descriptor Element Figure 11-40 shows an example of an OFE feedback descriptor element.

[0693] The OFE Feedback Descriptor element may include channel state information about the signal received from a given transmitter, i.e., a single multi-OFE pilot split.

[0694] Pilot Symbol Number: In the example, it specifies the position (e.g., temporal) of each received pilot symbol within the PPDU from which the included feedback was measured. The value is 1 - 7, and 0 may be reserved.

[0695] Division: In the example, it specifies the pilot split. This is, for example, an Hadamard code or subcarrier spacing and shift as indicated in the PPDU header.

[0696] Number of Taps: In the example, it specifies the number of subsequent Tap Descriptor elements and is also denoted as N.

[0697] Tap Descriptor 1…N: May refer to Tap Descriptor elements for each tap. The first Tap Descriptor element shall (in some examples) correspond to the first received tap from that OFE.

[0698] 6.6.1.14.2 Tap Descriptor Element Table 11-41 shows an example of a Tap Descriptor element.

[0699] The Tap Descriptor element may contain information about a single tap.

[0700] Strength: It may refer to the optical signal strength of a given tap. The format may be specified in the Tap Format field of the parent Multi-OFE Feedback element.

[0701] Delay: It may refer to an integer delay in the format specified in the Tap Format field of the parent Multi-OFE Feedback element. This delay may be relative to the first received tap of all OFEs. In some examples, the delay relative to the first tap may be 0.

[0702] 6.6.1.15 MSDU Aggregation Element The MSDU Aggregation element is responsible for the aggregation of multiple MSDUs in an A-MSDU frame.

[0703] MSDU Length: The field contains the length of the subsequent MSDU in octets.

[0704] ACK Request: This field is set to 1 (in some examples) if the MSDU contained in the MSDU Aggregation element is protected, and 0 otherwise.

[0705] MSDU Sequence Number: The sequence number assigned to the MSDU by the transmitter. This field exists (in some examples) only when the ACK Request field is set to 1.

[0706] MSDU: This field contains the MSDU to be aggregated.

[0707] MSDU FCS: The MSDU CRC checksum calculated according to item 6.2.1.

[0708] 6.6.1.16 ACK Information Element Figure 11-43 shows an example of the ACK information element.

[0709] The ACK Information element is used by the receiver of an MPDU to signal the success of receiving that MPDU to the transmitter of the MPDU.

[0710] Device Short Address: The short address of the device that received the MPDU and is sending the positive acknowledgment.

[0711] Sequence Number: The sequence number of the MPDU to be positively acknowledged.

[0712] 6.6.1.17 Block ACK Request Element Figure 11-44 shows an example of the Block ACK Request element.

[0713] The Block ACK Request element is used by the transmitter of an MPDU to request a positive acknowledgment for successful reception from the receiver.

[0714] Device Short Address: The short address of the device that received the MPDU and is sending the positive acknowledgment. This field may (in some examples) be included only.

[0715] Sequence Number: The sequence number of the MPDU to be positively acknowledged.

[0716] 6.6.1.18 Block ACK Element Figure 11-43 shows an example of the Block ACK element.

[0717] The Block ACK element is used by the receivers of multiple MPDUs to signal successful receptions to the transmitter in a grouped manner. This element is (in some examples) transmitted only in frames having a source address that is neither a multicast address nor a broadcast address.

[0718] Bitmap Width: The maximum number of acknowledgments included. This field determines the width of the ACK Bitmap field in integral octets. The actual width of the bitmap is the integer contained in the Bitmap Width field plus 1.

[0719] First Sequence Number: The sequence number corresponding to the first bit in the subsequent ACK Bitmap field.

[0720] ACK Bitmap: The actual acknowledgment information. The bitmap is of width Bitmap Width + 1 octets. The transmitter of the Block ACK element is (in some examples) to select the width of the bitmap such that it can hold the desired number of acknowledgments.

[0721] In the bitmap, the rightmost bit, i.e., the bit that will be processed last according to the definition given in 6.1.1, corresponds to the first sequence number as given in the First Sequence Number field. The leftmost bit, i.e., the bit that will be processed first, corresponds to the sequence number First Sequence Number+(Bitmap Width + 1)*8 - 1 corresponding to.

[0722] For each MPDU successfully received, the transmitter of the Block ACK element is (in some examples) to set the bit corresponding to its sequence number to 1. All other bits are (in some examples) to be set to 0.

[0723] The ACK Bitmap field with a Bitmap Width of 00001(1) and a first sequence number of 321 looks as follows when sequence numbers 320, 321, 322, 324, 325, 326, 327, 328, 329, 330, 332, 333 are successfully received.

[0724]

Table 15

[0725] 6.6.1.19 MCS Request Element Figure 11-46 shows an example of an MCS request element.

[0726] The MCS Request element is used by a future receiver of a transmission to request the use of a certain MCS by a future transmitter. The MCS Request element may be used with the PM-PHY.

[0727] Requested MCS ID: The ID of the MCS being requested. The MCS ID shall be (in some examples) a valid MCS for the PM-PHY.

[0728] 6.6.1.20 BAT Request Element Figure 11-47 shows an example of a BAT request element.

[0729] The BAT Request element may be used by a device receiving using the HB-PHY to request a transmitter to use a certain bit loading and error coding scheme.

[0730] Valid BAT Bitmap: Specifies the BATs that are required to be valid.

[0731] Updated BAT: Specifies the ID of the BAT that is to be updated.

[0732] FEC Block Size:

[0733]

Table 16

[0734] FEC Code Rate: Specify the required FEC coding rate. Valid values and the corresponding code rates are listed in Table 11 (Table 17).

[0735]

Table 17

[0736] BAT Group 1…N: The BAT Group element that describes the modulation for the nth group of subcarriers. Assume that there are groups sufficient to cover all subcarriers (in some examples). The last group may be wider than the number of remaining subcarriers. Assume that the required modulation for those surplus subcarriers is ignored (in some examples).

[0737] 6.6.1.20.1 BAT Group Element Figure 11-48 shows an example of the BAT group element.

[0738] The BAT Group element contains information about a group of adjacent subcarriers that have the same number of bits loaded in bit-loading-enabled PHY transmissions.

[0739] Grouping: This field contains the number of subcarriers in this group. Valid values are 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096 as follows.

[0740] Loaded Bits: The number of bits loaded onto each sub - carrier of the group. Valid values are 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 as follows.

[0741] 6.6.1.21 Queue State Element Figure 11 - 49 shows an example of a queue state element.

[0742] Queue State elements are sent by a device to inform other devices about the state of the MSDU queue.

[0743] 6.6.1.22 HCM Allocation Element Figure 11 - 50 shows an example of an HCM allocation element.

[0744] HCM Allocation elements are used to allocate one or more HCM rows to a device.

[0745] HCM Mask: The HCM rows allocated to a device. Each bit corresponds to an HCM row. The MSBit, i.e., the left - most bit, corresponds to row 0, while the right - most bit corresponds to row 7.

[0746] 6.6.1.23 Alien Signal Element Figure 11 - 51 shows an example of an alien signal element.

[0747] Alien Signal elements may contain information about signals that have been received and identified as not originating from devices that are members of the same OWPAN (or more generally, the same network).

[0748] Signal Power: May refer to the optical power of the alien signal in dBm.

[0749] Decodable: This bit shall be set to 1 only if (in some examples) the foreign signal is decodable by the PHY and MAC. This should apply when the signal is from another IEEE 802.15.13 device.

[0750] Same MAC Mode: This bit shall be set to 1 only if (in some examples) the received frame is from an IEEE 802.15.13 OWPAN using the same channel access mode as defined in 5.2 and 5.3 respectively.

[0751] OWPAN ID Clash: This bit shall be set to 1 only if (in some examples) the received frame is from an OWPAN with the same OWPAN ID.

[0752] Foreign OWPAN ID: This field shall exist only if (in some examples) the OWPAN ID Clash field is set to 0. This field contains the OWPAN ID of the external network from which the foreign frame was received.

[0753] Foreign Device Address: This field shall exist only if (in some examples) the Decodable field is set to 1. This field contains the Device Short Address of the external transmitting device. If the address is unknown, this field shall be set to (in some examples) a short broadcast address.

[0754] 6.6.1.24 Supported MCS Element Figure 11-52 shows an example of the supported MCS elements.

[0755] The supported MCS elements may be used to convey the set of rates supported by a device. The possible values included depend on the PHY being used.

[0756] PHY ID: The ID of the PHY for which the following PHY Rates elements are specific.

[0757] PHY Rates Element: The PHY-specific PHY Rates elements as defined in each PHY entry.

[0758] 6.6.1.25 OFE Selection Element Figure 11-53 shows an example of an OFE selection element.

[0759] The OFE Selection element includes a continuous field responsible for channel measurements between multiple OFEs and the device.

[0760] 6.6.1.26 Waveform Control Element Figure 11-54 shows an example of an evolved 6.6.1.26 Wave Control Element.

[0761] The waveform control frame pertains to adaptive OFDM techniques. Multiple waveforms such as eU-OFDM and RPO-OFDM may exist in the network. The control frame may be used when an adaptive adjustment of the waveform is required.

[0762] Timestamp: The Timestamp field enables synchronization between devices in OWPAN. The OWPAN master timekeeper periodically transmits the number of microseconds since it was active. The counter wraps around when it reaches its maximum value.

[0763] OWPAN ID: The OWPAN ID field gives the ID of the OWPAN.

[0764] New Waveform: These 8 bits indicate the waveform for switching between waveforms supported by IEEE 802.15.13.

[0765] 6.6.1.27 Advanced Modulation Control Element Figure 11-55 shows an example of the Advanced Modulation Control Element.

[0766] The evolved modulation control frame indicates the evolved modulation capabilities of the communication node.

[0767] Adaptive Loading: A single bit indicates whether the communication node transmitting the evolved modulation control frame supports adaptive bit and energy loading: "1" indicates that adaptive bit and energy loading are supported. "0" indicates that adaptive bit and energy loading are not supported.

[0768] eU: These 4 bits indicate whether the node supports eU-OFDM. The bit value at a given position among the four positions indicates whether an implementation form of eU-OFDM with the same number of streams as the bit position is supported. The positions are counted from left to right. For example, "1000" indicates that only eU-OFDM with one stream is supported (in some examples). "1100" indicates that only eU-OFDM with one and two streams is supported (in some examples). "1010" indicates that only eU-OFDM with one and three streams is supported (in some examples). "1111" indicates that eU-OFDM with all possible streams is supported. "0000" indicates that eU-OFDM is not supported.

[0769] RPO: A single bit indicates whether a communication node that transmits an evolved modulation control frame supports RPO-OFDM. "1" indicates that RPO-OFDM is supported. "0" indicates that RPO-OFDM is not supported.

[0770] Relaying: These 4 bits indicate the type of relaying operation supported by a communication node that transmits an evolved modulation control frame.

[0771] The first bit indicates whether relaying in FD is supported. "1" indicates that relaying in FD is supported. "0" indicates that relaying in FD is not supported.

[0772] The second bit indicates whether relaying in HD is supported. "1" indicates that relaying in HD is supported. "0" indicates that relaying in HD is not supported.

[0773] The third bit indicates whether AF relaying is supported. "1" indicates that AF relaying is supported. "0" indicates that AF relaying is not supported.

[0774] The fourth bit indicates whether DF relaying is supported. "1" indicates that DF relaying is supported. "0" indicates that DF relaying is not supported.

[0775] MIMO: A single bit indicates whether a communication node that transmits an evolved modulation control frame supports MIMO communication. "1" indicates that MIMO is supported. "0" indicates that MIMO is not supported.

[0776] MIMO Channel Number: These 4 bits indicate the maximum number of MIMO communication channels supported by a communication node that transmits an evolved modulation control frame.

[0777] The value "0000" corresponds to 1 channel, and the value "1111" corresponds to 16 channels.

[0778] 6.6.1.28 Random Access Element Figure 11-56 shows an example of a random access element.

[0779] The Random Access element contains information used to initiate a random access procedure in the non-beacon-enabled channel access mode.

[0780] Furthermore, Random Access frames announce the presence of a non-beacon-enabled network. They are transmitted by the coordinator at regular intervals (i.e., at each random access interval) to enable devices to discover, identify, and possibly participate in the network. Random Access frames are scheduled to be transmitted at the so-called Target Beacon Transmission Time (TBTT), just when a random access interval ends. In an infrastructure network, the coordinator is responsible for transmitting Random Access frames with information such as a timestamp, the OWPAN ID, and other parameters related to the coordinator to devices within range.

[0781] Timestamp: The Timestamp field enables synchronization between devices in an OWPAN. When the coordinator prepares to send a Beacon frame, the coordinator timer is copied to the Timestamp field of the Beacon. Devices associated with the coordinator accept the timing values in any received Beacon, but they may add a small offset to the received timing values to account for local processing by the antenna and transceiver.

[0782] Random Access Interval: Each OWPAN can send Random Access frames at its own unique interval.

[0783] Capability Information: A 16-bit Capability Information field is used to advertise the capabilities of the network. In this field, each bit is used as a flag to advertise a specific network function. Devices use the capability advertisement to determine whether the device can support all the features in the OWPAN. Devices that do not implement all the features in the capability advertisement are not permitted to participate.

[0784] OWPAN ID: The OWPAN ID field gives the ID of the OWPAN.

[0785] Supported Rates: Several data rates are standardized for each PHY in IEEE 802.15.13. When a mobile device attempts to join the network, the mobile device checks the data rates used in the network. Some rates are mandatory and must be supported by the mobile device, while other rates are optional.

[0786] Country: The initial specification was designed to comply with existing regulatory requirements imposed in major developed countries. Instead of continuously revising the specification as new countries are added, a new specification was added that provides a way for the network to describe regulatory requirements for new stations. The maximum transmit power is specified using the Country element in the beacon frame. This information is available to any station that wishes to associate with the network. The Country element specifies the regulatory maximum power, and the Power Constraint element can be used to specify a lower maximum transmit power specific to the network.

[0787] Extended Supported Rates: The Extended Supported Rates element was standardized to handle more than 8 data rates.

[0788] 6.6.1.29 Attribute Change Request Element Figure 11-57 shows an example of the Attribute Change Request element.

[0789] The Attribute Change Request element may be used by an OWPAN regulator to change the PIB attribute values of an associated device.

[0790] Attribute ID: This field indicates the attribute to be updated. The ID of a given attribute can be found in Table 34 (Table 41).

[0791] New Value: The new value to be assigned to the attribute. The field format will be inferred from Table 34 (Table 41).

[0792] 6.6.1.30 Attribute Change Response Element Figure 11-58 shows an example of the Attribute Change Response element.

[0793] The Attribute Change Response element is sent from the device to the regulator as a response to the Attribute Change Request element to indicate whether the attribute change was successful.

[0794] Attribute ID: This field indicates the attribute to be updated. The ID of a given attribute can be found in Table 34 (Table 41).

[0795] New Value: The new value assigned to the attribute. The field format will be inferred from Table 34 (Table 41).

[0796] Status: The result of the previous attribute change request. The possible values are described in Table 12 (Table 18).

[0797]

Table 18

[0798] 6.6.1.31 Variable Element Container Element Figure 11-59 shows an example of a Variable Element Container element.

[0799] The Variable Element Container element comprises one or more other elements.

[0800] Multiple Elements: This bit indicates whether multiple elements are included in the subsequent fields.

[0801] Size Prefix:

[0802] Contained Element 1…N: The contained elements.

[0803] 7 MAC Service The IEEE 802.15.13 MAC provides services to higher layer protocols and the DME through the MCPS-SAP and MLME-SAP respectively. The MCPS-SAP includes primitives that support the integration of IEEE 802.15.13 networks in bridged LANs according to IEEE 802.1AC. The MLME-SAP exposes basic management functions and more evolved functions to the DME.

[0804] Service users, i.e., primitive calls originating from higher layers, have the suffix.request. Thus, it requests a service, i.e., the initiation of an action, from the next lower layer service provider. The immediate response to.request is the.confirm primitive returned by the service provider, i.e., the MAC or MLME.

[0805] Externally triggered events in the MAC or MLME are indicated to higher layers through primitives with the.indication suffix. Such events may originate from an unsolicited action, e.g., the reception of a particular management frame, or may occur as an unsynchronized response to a completed service call through a previous service request.

[0806] The number of PIB attributes defines the behavior of the MAC and reflects the current system state.

[0807] Moreover, capabilities indicate a part of the functions of the present disclosure supported by the implementation form of a given device. Those capabilities are used to negotiate the functions that can be used while the device is associated with a given OWPAN.

[0808] 7.1 MCPS-SAP MCPS-SAP supports the transmission of MSDUs between the MACs of peer IEEE 802.15.13 devices through the primitives listed in Table 13 (Table 19).

[0809]

Table 19

[0810] 7.1.1 MCPS-DATA.request The MCPS-DATA.request primitive is used by higher layers to request the transfer of data to another device.

[0811] The parameters of this primitive are listed in Table 14 (Table 20).

[0812]

Table 20

[0813] 7.1.2 MCPS-DATA.indication The MCPS-DATA.indication primitive is issued by the device's MAC when it receives an MSDU from a peer device.

[0814] The parameters of this primitive are listed in Table 15 (Table 21).

[0815]

Table 21

[0816] 7.2 MLME-SAP MLME-SAP supports the management and use of the device's MLME functions through the DME.

[0817]

Table 22

[0818] 7.2.1 MLME-ASSOCIATE The MLME-ASSOCIATE primitive is responsible for the device association process with the OWPAN as described in Clause 5.4.5.

[0819] 7.2.1.1 Request MLME-ASSOCIATE.request is issued by the DME to the device MAC to initiate the association process with a given OWPAN. Upon receiving the primitive, the MLME (in some cases) initiates the association procedure as detailed in 5.4.5.

[0820] If the MLME of a device receives multiple MLME-ASSOCIATE.request primitives for different target OWPAN IDs, it (in some cases) discards all requests except the first one and waits for its completion or timeout before accepting another request.

[0821] The parameters of this primitive are listed in Table 17 (Table 23).

[0822]

Table 23

[0823] 7.2.1.2 Indication The MLME-ASSOCIATE.indication primitive is issued by the MLME to report the result of a preceding MLME-ASSOCIATE.request primitive.

[0824] The parameters of this primitive are listed in Table 18 (Table 24).

[0825]

Table 24

[0826] 7.2.2 MLME - AUTHENTICATE The MLME - AUTHENTICATE primitive enables the DME of the OWPAN coordinator to authenticate a device that previously requested authentication.

[0827] 7.2.2.1 Request The MLME - AUTHENTICATE.request primitive is issued by the coordinator DME to permit or deny the authentication of the requesting device. This primitive is called after a preceding MLME - AUTHENTICATE.indication primitive.

[0828] The parameters of this primitive are listed in Table 19 (Table 25).

[0829]

Table 25

[0830] 7.2.2.2 Indication The MLME - AUTHENTICATE.indication primitive is issued by the coordinator MAC to the DME when an Authentication Request element is received from a device attempting an association.

[0831] The parameters of this primitive are listed in Table 20 (Table 26).

[0832]

Table 26

[0833] 7.2.3 MLME - DISASSOCIATE The MLME-DISASSOCIATE primitive is called to disassociate a given device from the OWPAN. This primitive may be called by a participating device or the OWPAN coordinator, as described in 5.4.6.

[0834] 7.2.3.1 Request MLME-DISASSOCIATE.request indicates to the MLME to initiate the disassociation procedure as described in 5.4.6.

[0835] The parameters of the primitive are listed in Table 21 (Table 27).

[0836]

Table 27

[0837] 7.2.3.2 Indication MLME-DISASSOCIATE.indication is called by the MAC to indicate the disassociation of a device from the OWPAN. It may be used by the MLME of the OWPAN coordinator device or a participating device.

[0838] The parameters of the primitive are listed in Table 22 (Table 28).

[0839]

Table 28

[0840] 7.2.4 MLME-GET The MLME-GET primitive enables the DME to obtain the values of readable MAC and PHY PIB attributes.

[0841] 7.2.4.1 Request Upon receiving the MLME-GET.request primitive, the MLME shall (in some cases) read the requested MAC or PHY PIB attributes from its information storage.

[0842] The parameters of this primitive are listed in Table 23 (Table 29).

[0843] [Table 29]

[0844] 7.2.4.2 Confirm The MLME-GET.confirm primitive is issued by the MLME as a response to a preceding MLME-GET.request primitive.

[0845] The parameters of this primitive are listed in Table 24 (Table 30).

[0846] [Table 30]

[0847] 7.2.5 MLME-SET The MLME-SET primitive enables the DME to change the values of certain writable MAC and PHY PIB attributes.

[0848] 7.2.5.1 Request Upon receiving the MLME-GET.request primitive, the MLME shall (in some cases) set the requested MAC or PHY PIB attribute to have the value provided using the AttributeValue parameter.

[0849] If a PIB attribute is set by the coordinator according to the OWPAN operation configuration, it shall (in some cases) not be writable via the MLME-SET.request primitive.

[0850] If an attempt is made to set the read-only attribute, the MLME shall respond (in some cases) in the corresponding confirm with the FailureReason parameter set to READ_ONLY.

[0851] The parameters of this primitive are listed in Table 25 (Table 31).

[0852]

Table 31

[0853] 7.2.5.2 Confirm The MLME responds to a previous MLME-SET.request by issuing the MLME-SET.confirm primitive.

[0854] The parameters of the primitive are listed in Table 26 (Table 32).

[0855]

Table 32

[0856] 7.2.6 MLME-SCAN The MLME-SCAN primitive supports the DME when requesting the MLME to perform a scan for existing OWPANs.

[0857] 7.2.6.1 Request The MLME-SCAN.request is issued by the DME to start the scan procedure.

[0858] The parameters of this primitive are listed in Table 27 (Table 33).

[0859]

Table 33

[0860] 7.2.6.2 Confirm The MLME-SCAN.confirm primitive is used by the MLME to report the results of a scan to the DME.

[0861] The parameters of this primitive are listed in Table 28 (Table 34).

[0862]

Table 34

[0863] The ResultList parameter shall (in some cases) contain a list with one entry for each element listed in Table 29 (Table 35).

[0864]

Table 35

[0865] 7.2.7 MLME-START The MLME-START primitive is used to instruct the device MAC to act as a coordinator and start the operation of a new OWPAN.

[0866] 7.2.7.1 Request The MLME-START.request primitive is issued by the DME and received by the MLME to initiate the procedure to start an OWPAN.

[0867] The MLME-START.request primitive shall (in some cases) be confirmed by the MLME through a subsequent MLME-START.confirm primitive call.

[0868] The parameters of this primitive are listed in Table 30 (Table 36).

[0869]

Table 36

[0870] 7.2.7.2 Confirm The MLMLE-START.confirm primitive is issued by the regulator MLME to report the result of a preceding request to start a new OWPAN.

[0871] The parameters of this primitive are listed in Table 31 (Table 37).

[0872]

Table 37

[0873] 7.2.8 MLME-STOP The MLME-STOP primitive is issued by the DME of the regulator to stop the operation of an operating OWPAN.

[0874] 7.2.8.1 Request The MLME-STOP.request primitive is issued by the DME of the active regulator to the MLME to stop an operating OWPAN.

[0875] The parameters of this primitive are listed in Table 32 (Table 38).

[0876]

Table 38

[0877] 7.2.8.2 Confirm The MLME-STOP.confirm primitive is issued by the regulator's MLME as a response to a preceding MLME-STOP.request primitive.

[0878] The parameters of this primitive are listed in Table 33 (Table 39).

[0879]

Table 39

[0880] 7.3 PIB Attributes The MAC has variables and constants that define its behavior. The state of the MAC is defined through the status of its queues and the current values of its variables and constants. The variables and constants are called "PIB attributes".

[0881] Table 34 (Table 40) and Table 35 (Table 41) list the PIB attributes of the variables and constants. It provides the name of the attribute, an explanation and information about the constant or the possible value space, and the related units. Some variables are (in some examples) assumed to be readable and writable via MLME-GET.request and MLME-SET.request respectively. Whether a variable can be read or written is indicated by get for reading and set for writing in the get / set column. Attributes that are completely internal to the MAC are neither readable nor writable.

[0882] PHY PIB Attributes PHY PIB attributes determine the behavior of the MAC in the same way that MAC PIB attributes do for the MAC. Since the PLME-SAP is not specified, the management of PHY PIB attributes is left to the implementer. However, if necessary, some PHY PIB attributes can be read or written via the MLME-GET primitive and the MLME-SET primitive to make the attributes accessible from the DME. In this way, the r / w column indicates whether the attribute is readable or writable.

[0883]

Table 40

[0884]

Table 41

[0885]

Table 42

[0886] 7.4 Capabilities Capabilities formally denote the functions supported, i.e., implemented, by a device. Each capability has a name and a numerical ID with a 16-bit width. Some capabilities may require other capabilities to be implemented through the device. Capabilities are listed in Table 36 (Table 43).

[0887]

Table 43

[0888] 8 Security The MAC sublayer is responsible for providing security services on the specified incoming and outgoing frames. This disclosure supports the following security services. · Data confidentiality · Data authenticity · Replay protection

[0889] This disclosure supports the use of different security types. For this purpose, an ID is assigned to each distinct security type to facilitate the differentiation of multiple approaches in the MAC protocol. Table 37 (Table 44) lists the different security types and their corresponding IDs, as well as the sections where they are described.

[0890]

Table 44

[0891] Except for Open Systems security, each security type is characterized by the applicable encryption algorithm and authentication method. Each security type may utilize existing protocol procedures. For example, during an association, it is included in a frame in which common fields for an au...

Claims

1. a first communication device (16) for communicating with a second communication device (15), said first communication device (16) being configured to transmit a bit allocation table (BAT) message (61); the BAT message (61) includes BAT update information (55) signaling update information for updating a BAT (51-1) that is signaled to be updated; The first communication device (16), wherein the BAT update information (55) groups information into different groups of subcarriers, and the BAT update information (55) includes, for each group of subcarriers, information indicating the number of subcarriers in the group.

2. 2. The first communication device (16) of claim 1, wherein a length of the BAT update information (55) is variable based on a number of groups of subcarriers.

3. 2. The first communication device (16) of claim 1, wherein the number of subcarriers for each group is obtained from a predetermined limited number of groupings.

4. 2. The first communication device (16) of claim 1, wherein different groups of subcarriers have different numbers of subcarriers.

5. 2. The first communication device (16) of claim 1, wherein the BAT update information (55) includes, for each group of subcarriers, at least one field (55c) indicating which carriers are in the group.

6. 2. The first communication device (16) of claim 1, wherein the BAT update information (55) comprises, for each group of subcarriers, at least one field (55d) indicating bitloading information (55d).

7. 2. The first communication device (16) of claim 1, wherein the BAT update information (55) comprises, for each group of subcarriers, at least one field (55c, 55d) describing characteristics of said group of subcarriers.

8. predicting a confirmation, said confirmation being derived from the use of a bit allocation according to at least one updated BAT (51-1) as provided by said update BAT information (54) and a valid BAT as provided by validity information (53); resending the BAT message (61) if no valid confirmation is received from the second communication device (15); The first communication device (16) of claim 1, configured to:

9. The first communications device of claim 1 , wherein the subcarriers are indexed, each group of subcarriers being identified by an index.

10. The first communication device of claim 1 , configured to communicate with the second communication device through optical communication.

11. a second communication device for communicating with a first communication device, said second communication device being adapted to receive a bit allocation table (BAT) message (61); the BAT message (61) includes BAT update information (55) signaling update information for updating a BAT (51-1) that is signaled to be updated; A second communications device, wherein the BAT update information (55) groups information into different groups of subcarriers, and wherein the BAT update information (55) includes, for each group of subcarriers, information indicating the number of subcarriers in the group.

12. The second communication device of claim 11, wherein a length of the BAT update information (55) is variable based on a number of groups of subcarriers.

13. 12. The second communication device of claim 11, wherein the number of subcarriers for each group is obtained from a predetermined limited number of groupings.

14. The second communications device of claim 11, wherein different groups of subcarriers have different numbers of subcarriers.

15. 12. The second communication device of claim 11, wherein the BAT update information (55) includes, for each group of subcarriers, at least one field (55c) indicating which carriers are in the group.

16. 12. The second communication device of claim 11, wherein the BAT update information (55) comprises, for each group of subcarriers, at least one field (55d) indicating bitloading information (55d).

17. 12. The second communication device according to claim 11, wherein the BAT update information (55) comprises, for each group of subcarriers, at least one field (55c, 55d) describing characteristics of said group of subcarriers.

18. A method for communication between a first communication device (16) and a second communication device (15), the method comprising the steps of: the first communication device (16) transmitting a bit allocation table (BAT) message (61); the BAT message (61) includes BAT update information (55) signaling update information for updating a BAT (51-1) that is signaled to be updated; The method, wherein the BAT update information (55) groups information into different groups of subcarriers, and the BAT update information (55) includes, for each group of subcarriers, information indicating the number of subcarriers in the group.

Images