GB/T 35255-2017 in English
VALIDApplication layer communication protocols for the interface in intelligent public LED lighting systems
- Issued on:2017-12-29
- Implemented on:2018-07-01
- File Format:PDF
- Delivery:Via email within 1~3 business days
$272.00
《GB/T 35255-2017LED公共照明智能系统接口应用层通信协议》由306（科学技术部）归口，主管部门为科学技术部。
Introduction
Core architecture and technological evolution
This standard defines the three-layer logical architecture (central management system CMS-centralized controller-terminal controller) and two-level simplified architecture of the LED public lighting intelligent system. The technological evolution is reflected in the following aspects:
| Technical dimension | Traditional system | Standard system |
|---|---|---|
| Communication mode | One-way control | Two-way interaction (command + event reporting) |
| Security mechanism | Plain text transmission | AES+RSA double encryption |
| Protocol extensibility | Fixed function set | Support XML/JSON extension (Appendix D) |
Key protocol process
1. Command response mechanism
A three-level confirmation mechanism is adopted: command → command response (within 30s) → execution result (within 300s), and the number of retries is ≤ 3 times. Typical scenarios:
Case: When setting the dimming plan of lamps, CMS sends a 0x1206 command, and the gateway needs to return a 0x02 type ACK, and feedback a result message containing an error code after execution (Section B.3.3)
2. Event reporting process
Supports active alarms (such as temperature exceeding the threshold) and periodic data collection, event response timeout 30s, retry once. Key parameters:
- Temperature alarm code: 0x2302 (trigger)/0x2202 (eliminate)
- Data collection event: 0x2101 (including resource type code)
Data security system
| Security link | Technical implementation | Parameter requirements |
|---|---|---|
| Network authentication | RSA key exchange (Section 7.5.2) | Serial number verification + public key distribution |
| Data transmission | AES encryption (B.3.6.20) | 32-bit Base64 encoded key |
| Heartbeat detection | Link maintenance mechanism (Section 7.3) | 120s idle detection + 30s response timeout |
Message format specification
Two carrying modes:
- TCP/UDP message: 16-byte message header (including CRC32 check) + variable-length message body (B.2.2)
- Non-IP message: STX(0x02) start + ESC escape + ETX(0x03) end
Typical control command structure example (B.3.6.5):
| Message ID(0x1205) | Gateway ID(4B) | Lamp ID(4B) | Parameter type(time) | Parameter value(hhmm) | End mark (0x00) |
Implementation suggestions
1. System deployment
- Preferably adopt a three-tier architecture. It is recommended that the centralized controller be deployed in the power distribution cabinet
- LPWAN technology (NB-IoT/LoRa) is preferred for wide area network communication
2. Security configuration
- RSA2048 key pair is mandatory to be enabled during the initialization phase
- The AES key update cycle does not exceed 90 days
- The heartbeat packet interval is set to ≤120 seconds
3. Troubleshooting
| Error code | Solution |
|---|---|
| 0002 (Checksum error) | Check CRC32 algorithm implementation |
| 0007 (Parameter out of bounds) | Verify illumination value range (0-100%) |
| 2303 (Communication failure) | Check underlying network (PLC/WPAN) |
Loading PDF document...
Error loading PDF. Please make sure the file is valid and try again.
We also recommend
-
GB/T 44441-2024 in English
Test of visual healthy and comfort of LED lighting products
2024-08-23 -
GB/T 34846-2017 in English
Classification and interface technical requirements of the specialized modules for LED road/tunnel lighting
2017-11-01
