WO2013093721A1 - Protocols for visible light communications - Google Patents

Protocols for visible light communications Download PDF

Info

Publication number
WO2013093721A1
WO2013093721A1 PCT/IB2012/057233 IB2012057233W WO2013093721A1 WO 2013093721 A1 WO2013093721 A1 WO 2013093721A1 IB 2012057233 W IB2012057233 W IB 2012057233W WO 2013093721 A1 WO2013093721 A1 WO 2013093721A1
Authority
WO
WIPO (PCT)
Prior art keywords
subfield
data portions
bits
frame control
ordered data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/IB2012/057233
Other languages
English (en)
French (fr)
Inventor
Ronald Rietman
Robert James Davies
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Koninklijke Philips NV
Original Assignee
Koninklijke Philips Electronics NV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Koninklijke Philips Electronics NV filed Critical Koninklijke Philips Electronics NV
Priority to CN201280063867.0A priority Critical patent/CN103999432B/zh
Priority to JP2014548278A priority patent/JP6138821B2/ja
Priority to US14/368,063 priority patent/US9871585B2/en
Priority to EP12818821.6A priority patent/EP2749005B1/en
Priority to IN5011CHN2014 priority patent/IN2014CN05011A/en
Publication of WO2013093721A1 publication Critical patent/WO2013093721A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04BTRANSMISSION
    • H04B10/00Transmission systems employing electromagnetic waves other than radio-waves, e.g. infrared, visible or ultraviolet light, or employing corpuscular radiation, e.g. quantum communication
    • H04B10/11Arrangements specific to free-space transmission, i.e. transmission through air or vacuum
    • H04B10/114Indoor or close-range type systems
    • H04B10/116Visible light communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04Protocols for data compression, e.g. ROHC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers

Definitions

  • the invention relates to the field of IEEE 802.15.4 based networks, and in particular to methods and devices for transmitting and receiving messages in IEEE 802.15.4 based networks.
  • Visible light has drawn recent interest as a new means of communication with recent developments in solid-state lighting that make it easier to accurately control light characteristics.
  • Optical free space communications i.e. visible light (VL) and infra-red (IR) communications, for the selection and advanced control of light sources has previously been proposed, and will be referred to as coded light (CL).
  • VL visible light
  • IR infra-red
  • the light emitted from a lighting device or luminaire, employing coded light comprises a modulated part (which for the human eye is invisible) associated with coded light comprising information messages.
  • the emitted light also comprises an un-modulated part associated with an illumination contribution.
  • a visible light communications standard that is currently being developed is based on the existing IEEE 802.15.4 standard.
  • devices may be grouped into a so-called personal area network, PAN.
  • PAN personal area network
  • a PAN has an identifier that is two bytes long; and a device in a PAN may have a two- byte address assigned to it. Every device also has an eight-byte address. This eight-byte address is typically assigned to the device during manufacturing. If a device is not assigned to a PAN a default PAN identifier is used.
  • the existing IEEE 802.15.4 standard defines a medium access control, MAC layer.
  • the MAC has a header which in turn has a frame control field, in which there are five bits that signal the way the source and destination addresses of a packet are transmitted in the MAC header.
  • Two bits indicate the destination addressing mode, DAM. These two bits can take the decimal values 0, 1, 2, and 3.
  • the value 0 means that neither the destination's PAN identifier, nor its address are transmitted.
  • the value 1 is reserved, and shall thus according to the existing IEEE 802.15.4 standard not be used.
  • the value 2 means that the destination's PAN identifier is transmitted, as well as its two-byte address.
  • the value 3 means that the destination's PAN identifier is transmitted, as well as its eight-byte address.
  • TAN ID Compression Sub fie Id' may be set to 1 if both source and destination addresses are present, which then indicates that the PAN identifiers of the source and destination are the same, and that therefore only the destination PAN identifier is transmitted and the source PAN identifier is omitted.
  • a visible light communications standard (whereby the devices of the PAN preferably are luminaires and communicate by means of coded light) that is currently being developed is based on the existing IEEE 802.15.4 standard.
  • the personal area network thereby becomes a visible are network, VAN.
  • VAN VAN
  • PAN PAN
  • addressing modes defined according to the existing IEEE 802.15.4 standard have been shown to be insufficient, or inefficient, for a few applications.
  • One application is a so-called shouter device.
  • a shouter device sends information to whatever device that can receive/decode the message, and the shouter device does not expect a response.
  • a shouter device does not even need to have a receiver for visible light communications. Neither is there any requirement that a transmitted package should be received correctly.
  • This type of message is called an indiscriminate broadcast. Indiscriminate broadcast thus has a slightly different interpretation to the normal broadcast mode.
  • a normal broadcast message is intended to be received and processed by every device that receives it.
  • An indiscriminate broadcast message is only intended to be received and processed by those devices that have a specific interest in the content of the message.
  • Another application is the transmission and forwarding of control messages. In this application is does not matter which device sends the command, as long as all the intended receivers receive the message. This type of message is called an anonymous transmission.
  • an objective of the invention is to solve or at least reduce the problems discussed above. It is an objective of the present invention to further improve and adapt the existing IEEE 802.15.4 standard to better fit the properties of a VAN. It is a particular objective of this invention to propose improvements and adaptations of the existing IEEE 802.15.4 standard that allow for more flexible addressing. Generally, the above objectives are achieved by the attached patent claims. Proposed therefore are adaptations to the existing IEEE 802.15.4 standard protocol.
  • a method for transmitting a message in an IEEE 802.15.4 based network comprising a sequence of ordered data portions, wherein the sequence of ordered data portions comprises address fields and one or two frame control fields
  • the method comprising: defining bits in a first subfield of the ordered data portions indicative of use of the address fields; and/or defining bits in a second subfield of the ordered data portions indicative of whether one or two frame control fields is/are present in the ordered data portions; and transmitting the message comprising the first subfields, the first frame control field and optionally, depending on the defined bits in the second subfield, the second frame control field.
  • a method for receiving a message in an IEEE 802.15.4 based network comprising a sequence of ordered data portions, wherein the sequence of ordered data portions comprises address fields and one or two frame control fields
  • the method comprising: receiving the message; reading bits in a first subfield of the ordered data portions indicative of use of the address fields; and/or reading bits in a second subfield of the ordered data portions indicative of whether one or two frame control fields is/are present in the ordered data portions; and reading the first frame control field and optionally, depending on the bits in the second subfield, the second frame control field.
  • a transmitting lighting device for transmitting a message in an IEEE 802.15.4 based network, the message comprising a sequence of ordered data portions, wherein the sequence of ordered data portions comprises address fields and one or two frame control fields
  • the lighting device comprising: a processing unit arranged to define bits in a first subfield of the ordered data portions indicative of use of the address fields; and/or to define bits in a second subfield of the ordered data portions indicative of whether one or two frame control fields is/are present in the ordered data portions; and a transmitter arranged to transmit the message comprising the first subfields, the first frame control field and optionally, depending on the defined bits in the second subfield, the second frame control field.
  • a receiving lighting device for receiving a message in an IEEE 802.15.4 based network, the message comprising a sequence of ordered data portions, wherein the sequence of ordered data portions comprises address fields and one or two frame control fields
  • the lighting device comprising: a receiver arranged to receive the message; a processing unit arranged to reading bits in a first subfield of the ordered data portions indicative of use of the address fields; and/or to read bits in a second subfield of the ordered data portions indicative of whether one or two frame control fields is/are present in the ordered data portions; and to read the first frame control field and optionally, depending on the bits in the second subfield, the second frame control field.
  • the first frame control field and/or the second frame control field has a size of one octet of bytes, i.e. 64 bits.
  • this prevents the transmission of redundant MAC header fields, especially when short data packets are being sent.
  • this allows adding addressing methods to the existing IEEE 802.15.4 standard protocol that allow the omission of redundant addressing fields.
  • this enables incorporating a header control compression scheme that allows header control subfields that are essentially static (when used with short data packets) to be grouped together into a field/octet that can be omitted from the transmitted data.
  • the receiver is thereby arranged to, from the omission, infer the intended values of the omitted subfields. In other words: If the second control field is not present, the receiver may infer from this omission that everything that is normally defined in the second control field (i.e. all its subfields) takes on default values.
  • the message is preferably transmitted by visible light communications.
  • the message preferably comprises a medium access control, MAC, header.
  • the MAC header preferably comprises a frame control field, and the frame control field preferably at least comprises the first subfield and the second subfield.
  • the adaptation of the meaning carried by bits in the frame control field of the MAC header allows for more flexibility in the way they are used, thereby enabling, for example, an efficient signaling of indiscriminate broadcast and anonymous transmission.
  • address modes '0' allow anonymous transmissions and indiscriminate broadcasts.
  • the proposed scheme allows address modes ' 1 ' with meaning 'group identifier is not present, long address.' Preferably the long address has eight bytes.
  • the term group has a more general meaning than the term VAN.
  • the proposed scheme allows for shorter packet headers, which can give useful savings, especially in communication scenarios where each packet is flooded through a network.
  • Fig. 1 illustrates a lighting device according to embodiments
  • Fig. 2 illustrates an IEEE 802.15.4 based network
  • FIG. 3 and 4 are flowcharts of a transmission and a receiving method, respectively, according to embodiments.
  • the proposed address formats can advantageously be incorporated into the addressing scheme inherited from the existing IEEE 802.15.4 standard protocol by removal of some constraints and with new interpretations of at least some of the existing signaling.
  • the proposed bit codings are preferably arranged in such a way that the proposed features are a natural consequence of the codings.
  • Fig. 1 schematically illustrates, in terms of functional blocks, a lighting device la, lb according to an embodiment.
  • the lighting device la, lb is preferably arranged to both transmit a message and to receive a message.
  • the lighting device may be arranged to either transmit a message or to receive a message.
  • a lighting device arranged to at least transmit a message is denoted a transmitting lighting device la.
  • a lighting device arranged to at least receive a message is denoted a receiving lighting device lb.
  • Fig. 2 schematically illustrates an IEEE 802.15.4 based network 5 comprising a transmitting lighting device la transmitting message 6 to a receiving lighting device lb.
  • the lighting device la, lb is preferably arranged for visible light communications and may thus be configured to emit illumination light as well as coded light, wherein the coded light comprises the message.
  • the lighting device la, lb comprises a processing unit 2, a transmitter 3, and a receiver 4.
  • the transmitter 3 may have a light emitter associated with the illumination function of the light source la, lb (i.e.
  • the transmitter transmits a message as defined by the processing unit 2.
  • the receiver 4 which may have a light detector arranged to detect visible light communications, and thus to receive a message transmitted by visible light communications, is arranged to receive light emitted by at least one other lighting device and in the received light detect coded light.
  • the receiver 4 may comprise a photosensor or photodetector or any other suitable sensor of light.
  • the receiver 4 may comprise a charge-coupled device (CCD), CMOS sensor, a photodiode ⁇ inter alia a reverse biased LED), a phototransistor, a photoresistor, or the like.
  • a VAN device is enabled to send a broadcast to an entire VAN by using just the VAN ID as destination without the need to include the VAN broadcast address.
  • the VAN is one example of a group G. It should be noted that the herein disclosed embodiments are, although described in a VAN context, also applicable for a general group of devices which not necessarily are part of a VAN. This structure achieves an extra bit of efficiency when broadcasting short messages. Making the source address optional provides anonymous transmission (whose purpose is mainly efficiency rather than a need to hide). Not
  • transmitting a source address may be regarded as an efficiency issue within a VAN - the fact that a destination VAN has been specified means that it is not a true indiscriminate broadcast.
  • VAN ID compression bit In order to achieve this the interpretation of the VAN ID compression bit to mean that, when set, there will always be a destination VAN id transmitted and the source VAN ID shall be assumed to be identical and never transmitted. As such, it over-rides destination address modes 0 and 1 (which do not carry the VAN ID) and source address modes 2 and 3 (which do carry the VAN ID).
  • step S2 bits in a first subfield of the ordered data portions indicative of use of the address fields are therefore defined by the processing unit 2 of the transmitting lighting device la.
  • the processing unit 2 of the receiving lighting device lb Upon reception of a message 6 comprising the first subfield the processing unit 2 of the receiving lighting device lb reads bits in the subfield of the ordered data portions indicative of use of the address fields, step S22.
  • Destination address is long, such as a 64-bit, address of specific device. No grouping involved
  • Destination address is a valid VAN ID and assigned middle length (16-bit) address within the VAN (Source address indicates source is not a member of any VAN)
  • VAN IDs are members of different VAN.
  • VIC field can signal change in RX interpretation. Does not change address field generation since destination VAN ID is already present and source VAN id already not present
  • the combinations listed may be grouped as follows: ⁇ 1-1-1, 1-1- 3, 1-3-1, 1-3-3 ⁇ and ⁇ 0-2-0, 1-2-0 ⁇ , ⁇ 0-2-1, 1-2-1, 1-2-3* ⁇ , ⁇ 0-3-0, 1-3-0 ⁇ , ⁇ 0-3-1, 1-3- 1, 1-3-3* ⁇ .
  • the codes marked * take advantage of both phenomena and some codes appear in the list twice. Again, although this is a natural outcome of the coding scheme, it does make it possible for the transmitter to signal some extra information. For example, a setting of 1 or 3 as the source address with VIC set to 1 , could inform the receiver whether the transmitter is able to take part in a closed group (or VAN) (3) or not (1).
  • DAM or SAM of 1 which is a reserved (i.e., invalid) value in the existing IEEE 802.15.4 standard protocol, and some use the VIC in ways not anticipated by 15.4, giving us the potential ability to guide the receiver in its interpretation.
  • the only time an address mode of '0' is used is in the special case of an exchange of packets between a VAN hub (in the existing IEEE 802.15.4 terminology: a PAN coordinator) and a member of that same VAN.
  • a VAN hub in the existing IEEE 802.15.4 terminology: a PAN coordinator
  • address mode '0' to be used more widely, support of anonymous transmission (i.e. that the source address is not present), indiscriminate broadcast (i.e. that the destination address is not present) and the combination thereof is allowed.
  • address mode T is not supported.
  • the two-bit address fields may according to the present invention be interpreted as containing one bit (bit 1) indicating the presence (1) or otherwise (0) of the address field and another bit (bit 0) indicating the type of address, short or long (according to the present non- limiting example 16 bit (0) or 64 bit (1)).
  • bit 1 indicates the presence (1) or otherwise (0) of the address field
  • bit 0 another bit indicating the type of address, short or long (according to the present non- limiting example 16 bit (0) or 64 bit (1)).
  • mode 1 and mode 0 both have bit 1 set to 0, meaning no address field, and are therefore equivalent in practice.
  • pseudocode a procedure for receiving these bits may be written as:
  • mode 1 has the following meaning as expressed in pseudocode:
  • bit 0 controls the presence of the long (64-bit) address field and bit 1 the presence of the VAN ID and, if there is no long (64 bit) address, the presence of the middle (16-bit) address.
  • Modes 0, 2 and 3 are the same but Mode 1 now generates a long (64-bit) address with no VAN ID.
  • the VAN ID is essentially only used when a source or destination is a member of a VAN (or the destination address is a broadcast address). If a VAN member sends a message to another member of the same VAN, the two VAN IDs would be identical although only one needs to be transmitted.
  • the VAN ID Compression is set to 1 to indicate this situation. Preferably this is the only time the VAN ID Compression bit is used.
  • the MAC header, MHR generally has the generic layout according to Table 1.
  • the Auxiliary Security Header can be of arbitrary (arb.) size. Octets:
  • the frame control field of the MAC header has a number of subfields as shown in Table 2.
  • Bit 6 is set if the Source VAN identifier is identical to the destination VAN identifier and therefore omitted, step S8.
  • Bits 10-11 and 14-15 independently take the decimal values:
  • a number of mechanism are inherited from the existing IEEE 802.15.4 standard protocol.
  • Each address is made up of a middle length (16-bit) VAN ID and a long (64-bit) device address.
  • the long (64-bit) device address is a fixed, globally-unique identifier that, for example, may be assigned to the device during manufacture and thus may not be changed during use. Unless a value has been allocated, the middle length (16-bit) VAN ID is set to OxFFFF, meaning that no VAN ID has been assigned, see Table 3.
  • middle length (16-bit) short ID In VAN-based scenarios, it is possible to allocate a middle length (16-bit) short ID to replace the long (64-bit) ID; at the same time, the VAN ID will be given a value other than all 1 's (which has the specific meaning of 'unallocated'). These allocations are generated by the upper layers of a VAN hub, checking, where necessary, that no similar allocation exists within the coverage range of the hub.
  • middle length (16-bit) addresses is preferably used where available, else the default long (64-bit) address may be used. In the latter case, a VAN ID may or may not be allocated, see Table 4.
  • a VAN hub sending a message to a VAN member may omit the source ID altogether - such a packet is preferably assumed to come from the VAN hub.
  • a VAN member sending to the VAN hub may omit the destination ID altogether - such a packet is preferably assumed to be bound for the VAN hub, see Table 5.
  • a VAN member sending to another VAN member preferably includes both source and destination addresses but preferably omits one of the identical VAN IDs (the source VAN) and preferably signals this via the VAN compression bit in the header control field, see Table 6.
  • the acknowledgement packet omits both addresses - it then uses its chronological proximity to the packet being acknowledged and the sequence number as its addressing mechanism.
  • Non-transceiver devices cannot support VAN functionality and therefore cannot be assigned VAN IDs and short addresses, and, by the normal rules of the existing IEEE 802.15.4 standard protocol s disclosed above, cannot omit source or destination VAN and address fields. Some considerations to reducing the overhead have therefore been considered.
  • the source VAN ID is advantageously omitted.
  • the source address may be omitted in its entirety. This creates an anonymous packet - the device identity may be sent in the payload if necessary to the application.
  • the destination ID may be omitted if the destination is 'broadcast'. This creates an 'indiscriminate' or 'shouter' broadcast, which is a useful distinction from 'normal' broadcast. Packets sent to a receive-only device need not include a destination VAN-ID, see Table 7.
  • the ' 1-3-3' code implies that the Source VAN ID is the same as the destination VAN ID, i.e., OxFFFF.
  • An alternative coding is '0-3-1 ', using the new
  • step S10 the interpretation is that the source has no VAN ID and is not capable of being assigned one, which, in turn, implies that the device is probably a shouter device.
  • ' 0-1-1 ' might be used by a shouter device transmitting to a receiver-only device.
  • multicast operation may be more likely than unicast operation.
  • a command received needs to be relayed to other devices in the VAN.
  • a multicast function can be achieved by setting the destination address to OxFFFF, this has been discovered to be inefficient when the bulk of the traffic is multicast. It may therefore be better to make unicast the exception in this case.
  • For multicast operation it may be advantageous to include the destination VAN Identity but to omit the destination device address. It may also be advantageous to omit the source address in its entirety.
  • Anonymous transmission Not sending the source ID creates an 'anonymous' transmission - whereby it is not possible at the visible light communications level to determine the device that sent it. It may then be up to the application to provide any sender authentication that would be required. From a communications perspective, replying to an anonymous packet may only be done via broadcast because the visible light communications address of the transmitting device is not known, even if an application or other upper layer address is contained within the payload. From an application perspective, this mode may be appropriate for command messages, for which the source of the command is a matter of supreme irrelevance.
  • Indiscriminate broadcast Omitting the destination address allows a type of broadcast message termed 'indiscriminate' or, more colloquially, 'shouter' broadcast.
  • the message When no destination VAN ID is present, the message is available for every device capable of receiving/decoding it.
  • VAN ID other than OxFFFF When a VAN ID other than OxFFFF is present, the intended receiver is device within the specified VAN. The use of this mode allows a receiver to differentiate between 'shouter' messages, which may have no particular relevance, and 'normal' broadcast messages that, by implication, are intended to be received by all devices. Normal broadcast messages are passed up to the upper layers for processing while 'shouter' broadcast messages may be discarded by the MAC.
  • step S4 bits in a second subfield of the ordered data portions indicative of whether one or two frame control fields/octets is/are present in said ordered data portions are therefore defined by the processing unit 2 of the transmitting lighting device la.
  • the processing unit 6 of the receiving lighting device lb Upon reception of a message comprising the second subfield the processing unit 6 of the receiving lighting device lb reads bits in the subfield of the ordered data portions indicative of whether one or two frame control fields/octets is/are present in the ordered data portions, step S24.
  • the processing unit 6 of the receiving lighting device lb reads the first frame control field/octet, step S26.
  • the processing unit 6 of the receiving lighting device lb in step S26 also reads the second frame control field/octet.
  • a MAC header according to Table 9 is therefore proposed.
  • the first field/octet of the Frame Control field indicates 1) the frame type, 2) whether a second Control Field field/octet is present, and 3) the addressing modes.
  • a device is enabled to repeat a packet in order that a third device, too far from the sender to receive the main transmission, can at least receive the repeat.
  • the frame version bits advantageously have meaning according to Table 10.
  • the frame version field advantageously avoids the need to use a separate bit to indicate the presence or absence of the second field/octet and also enables a simple receiver to ignore packets that include the second field/octet on the grounds that it will not be able to support a feature indicated in the second field/octet.
  • the message 6 comprising the first subfields, the first frame control field/octet and optionally, depending on the defined bits in the second subfield, the second frame control field/octet is transmitted by the transmitter 3 of the transmitting lighting device la.
  • the transmitted message 6 may further include other parts of the MAC header as disclosed above.
  • the message 6 may be transmitted by visible light communications, also called coded light communications.
  • the transmitter 3 may therefore have a light emitter.
  • the receiver 4 of the receiving lighting device lb receives the message, step S20.
  • the subfields that comprise it are assumed by the receiving lighting device lb to take certain default values. Indeed, one of the address mode subfields could be placed in this second field/octet. If the DAM is placed here, for example, then broadcast packets that do not use a destination address do not need to carry the second frame control field/octet. Because no DAM is explicitly received, the receiving lighting device lb understands it to be set to indicate 'No destination address'. If present, the second field/octet is preferably defined according to Table 11. Bits:
  • the fields contained take on defined default values.
  • absence of the second field/octet implies: 1) the packet is a data frame, 2) there is no security enabled, 3) there is no pending frame indicated, 4) no sequence number is used, and 5) an acknowledgement is not requested.
  • a change from any of these default positions thus inherently implies either a longer packet (security enabled) or bidirectional operation (for which economy of transmission is not a prime concern) (frame type is other than data, frame pending is set (i.e., more data is to come), acknowledgement is requested).
  • Simple unidirectional receivers that do not support security can therefore automatically ignore any packets that included the second field/octet, see Table 12.
  • the fields have thus been rearranged and there are three more information bits.
  • the number of Frame Type bits are preferably reduced from three bits to two bits to indicate the presence or absence of the second frame control byte in the frame version and maintaining only two reserved bits.
  • the existing IEEE 802.15.4 standard protocol defines four packet types: Data, Acknowledgement, Beacon and MAC Control. The other four possibilities are reserved for possible future use.
  • the source address mode may be moved in its entirety to the second field/octet.
  • the source address may be regarded as more important and the destination address less important. If this is considered to be the more important application, then the destination address may be moved to the second field/octet. In either case, the reserved bits may be moved to the first field/octet to allow for future expansion.
  • more flexible use of one of the other features may be allowed, such as security or sequence numbering.

Landscapes

  • Physics & Mathematics (AREA)
  • Electromagnetism (AREA)
  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)
  • Optical Communication System (AREA)
PCT/IB2012/057233 2011-12-23 2012-12-12 Protocols for visible light communications Ceased WO2013093721A1 (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN201280063867.0A CN103999432B (zh) 2011-12-23 2012-12-12 用于可见光通信的协议
JP2014548278A JP6138821B2 (ja) 2011-12-23 2012-12-12 可視光通信のためのプロトコル
US14/368,063 US9871585B2 (en) 2011-12-23 2012-12-12 Protocols for visible light communications
EP12818821.6A EP2749005B1 (en) 2011-12-23 2012-12-12 Protocols for visible light communications
IN5011CHN2014 IN2014CN05011A (enExample) 2011-12-23 2012-12-12

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201161579751P 2011-12-23 2011-12-23
US61/579,751 2011-12-23

Publications (1)

Publication Number Publication Date
WO2013093721A1 true WO2013093721A1 (en) 2013-06-27

Family

ID=47603884

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2012/057233 Ceased WO2013093721A1 (en) 2011-12-23 2012-12-12 Protocols for visible light communications

Country Status (6)

Country Link
US (1) US9871585B2 (enExample)
EP (1) EP2749005B1 (enExample)
JP (1) JP6138821B2 (enExample)
CN (1) CN103999432B (enExample)
IN (1) IN2014CN05011A (enExample)
WO (1) WO2013093721A1 (enExample)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106662322A (zh) * 2014-08-01 2017-05-10 飞利浦灯具控股公司 具有无线电模块的照明器

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104506235B (zh) * 2014-12-10 2018-11-30 北京智谷睿拓技术服务有限公司 光通信方法和设备
CN104618018B (zh) * 2014-12-30 2018-09-18 北京智谷睿拓技术服务有限公司 基于可见光通信的数据传输方法和装置
CN105959061A (zh) * 2016-06-21 2016-09-21 江苏大学 Led到led的半双工通信系统
CN107707302A (zh) * 2016-08-08 2018-02-16 镇江明辉光信息科技有限公司 基于led的近距离点对点高速双向数据传输系统
CN106982094A (zh) * 2017-04-09 2017-07-25 深圳市先通网信息科技有限公司 可见光通信方法及系统
US11328564B2 (en) 2019-08-31 2022-05-10 Appleton Grp Llc Event indications of hazardous environment luminaires using visual sequences
US11219112B2 (en) 2019-09-09 2022-01-04 Appleton Grp Llc Connected controls infrastructure
US11232684B2 (en) 2019-09-09 2022-01-25 Appleton Grp Llc Smart luminaire group control using intragroup communication
US11343898B2 (en) 2019-09-20 2022-05-24 Appleton Grp Llc Smart dimming and sensor failure detection as part of built in daylight harvesting inside the luminaire

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4508915B2 (ja) * 2005-03-23 2010-07-21 京セラ株式会社 光送信装置及び可視光通信システム
JP4643403B2 (ja) * 2005-09-13 2011-03-02 株式会社東芝 可視光通信システム及びその方法
US8098689B2 (en) * 2006-05-11 2012-01-17 Intel Corporation Systems and methods for frame tunnelling in wireless communications
DE102006037243B4 (de) * 2006-08-09 2010-06-02 Siemens Ag Netzwerk zur drahtlosen Übertragung von Daten
KR101009803B1 (ko) * 2008-02-21 2011-01-19 삼성전자주식회사 가시광 통신을 이용한 데이터 송수신 장치 및 방법
EP2334017B1 (en) * 2009-12-10 2018-01-03 Alcatel Lucent Forwarding a packet in a sensor personal area network
KR101951358B1 (ko) * 2011-12-15 2019-02-22 삼성전자주식회사 무선 전력 송신기 및 그 제어 방법

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"IEEE Standard for Local and metropolitan area networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs);IEEE Std 802.15.4-2011 (Revision of IEEE Std 802.15.4-2006)", IEEE STANDARD, IEEE, PISCATAWAY, NJ, USA, 5 September 2011 (2011-09-05), pages 1 - 314, XP017694668, ISBN: 978-0-7381-6683-4 *
"IEEE Standard for Local and Metropolitan Area Networks--Part 15.7: Short-Range Wireless Optical Communication Using Visible Light;IEEE Std 802.15.7-2011", IEEE STANDARD, IEEE, PISCATAWAY, NJ, USA, 6 September 2011 (2011-09-06), pages 1 - 309, XP017694867, ISBN: 978-0-7381-6665-0 *
N/A: "San Antonio Closing Report ; 15-04-0681-00-004b-san-antonio-closing-report", IEEE DRAFT; 15-04-0681-00-004B-SAN-ANTONIO-CLOSING-REPORT, IEEE-SA MENTOR, PISCATAWAY, NJ USA, vol. 802.154b, 19 November 2004 (2004-11-19), pages 1 - 4, XP017670721 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106662322A (zh) * 2014-08-01 2017-05-10 飞利浦灯具控股公司 具有无线电模块的照明器

Also Published As

Publication number Publication date
JP6138821B2 (ja) 2017-05-31
US20150071644A1 (en) 2015-03-12
US9871585B2 (en) 2018-01-16
CN103999432A (zh) 2014-08-20
IN2014CN05011A (enExample) 2015-09-18
JP2015506602A (ja) 2015-03-02
EP2749005B1 (en) 2020-06-24
EP2749005A1 (en) 2014-07-02
CN103999432B (zh) 2017-07-14

Similar Documents

Publication Publication Date Title
US9871585B2 (en) Protocols for visible light communications
US8452188B2 (en) Visible light communication method and system
US8380082B2 (en) Method and apparatus for outputting visibility frame in visible light communication system providing multiple communication modes
JP4689412B2 (ja) 送信装置及び通信システム
AU2009200917B2 (en) Radio network communication system and protocol
CN1207220A (zh) 实现多模式无线光通信的健壮方法和装置
CN104956768B (zh) 用于在照明设备的照明系统中传输消息时使用的模块、方法以及对应的照明设备和照明系统
WO2010110618A2 (ko) 백스캐터링 방식 rfid 통신 시스템
EP1735974A2 (en) Wireless communication protocol
JP2012502551A5 (enExample)
CN106470458B (zh) 在WiFi网络中进行控制的方法和设备
US7548552B2 (en) Method for polling in a medium access control protocol
JP6143774B2 (ja) 符号化光通信用のプロトコル
US20170272376A1 (en) Packet order identification with reduced overhead in packetized data transmission
JP2018527858A (ja) ワイヤレス通信方法及びシステム
US10608740B2 (en) Method and apparatus for visible light communication
JP2018509739A (ja) 照明ネットワーク
EP3042490B1 (en) Device, method and network for internet protocol communication over a dmx network
JP2014512721A (ja) 一時ブロックフローを解決する方法及び装置
EP1518358A2 (en) Communication system with an extended coverage area
CN111193544B (zh) 一种基于可见光双向通信系统的通信方法和系统
WO2016155820A1 (en) Connecting lighting devices
CN112311506B (zh) 一种组播通信反馈方法、终端设备、系统
CN103959914B (zh) 用于接收和发射编码光的照明设备、方法和编码光系统
Abbasi et al. 6LoWPAN: IPv6 for Battery-less Building Networks

Legal Events

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

Ref document number: 12818821

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2014548278

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE