A communication method and system for unifying near field and cloud object models

Abstract

The application relates to the field of communication technology, and particularly discloses a kind of communication method and system of near field and cloud object model unification, wherein, near field link uses uniform near field envelope transmission, the envelope contains subject type field, service data field;Subject type field does not carry complete MQTT subject but corresponds to express its operation semantics, service data field carries the service message that is isomorphic with MQTT request / response body, the method comprises: obtaining target device connection context;Mobile terminal generates uniform near field envelope and sends data according to selected channel, each near field link multiplexes the envelope;Target device generates cloud-consistent device-side subject path in combination with received data and connection context, uses service routing table to complete routing;Data is returned after service execution is completed;Mobile terminal completes request-response pairing according to returned data.Compared with the prior art, the application has the advantages that cloud-consistent subject path can be reconstructed in near field without subject registration.

Description

Technical Field

[0001] This invention relates to the field of communication technology for Internet of Things (IoT) devices, and in particular to a unified communication method and system for near-field and cloud-based object models. Background Technology

[0002] IoT smart devices typically need to support both near-field control (Bluetooth Low Energy, BLE, and LAN WebSocket) and cloud-based remote control (Message Queuing Telemetry Transport, MQTT). Near-field links are bandwidth-limited and sensitive to message overhead; cloud links, on the other hand, typically use complete topic strings and standard object model request / response bodies. Mobile application software development kits (SDKs), device firmware, and cloud gateways often implement near-field and cloud protocols separately. Existing implementations that simultaneously support near-field and cloud communication mainly fall into the following categories: one is to define independent business protocols for near-field and cloud, with near-field using simplified proprietary messages and cloud using complete MQTT object model messages. The first approach optimizes each channel separately, but each channel maintains its own encoding / decoding and routing logic, which can easily lead to inconsistencies in fields for the same service across different channels. The second approach directly transmits the complete MQTT topic string and redundant context fields (such as product_key, device_id, model_version, etc.) on the near-field link. This approach can improve protocol consistency, but it incurs excessive overhead on the BLE air interface, affecting latency and connection stability. The third approach uses only the standard object model in the cloud, and performs only local direct control in the near field without aligning with the cloud object model. This approach is simple to implement, but cross-channel state synchronization and joint debugging costs are high, and it is difficult to guarantee consistent business semantics between the end and the cloud. The fourth approach adopts the Sensor Network Message Queuing Telemetry Transport Protocol (MQTT-SN) defined in OASIS's "MQTT-SN Protocol Specification Version 1.2". It replaces the complete topic string with a 2-byte topic identifier and establishes an instance-level one-to-one mapping between the topic identifier and the topic name through registration messages, or the two communicating parties pre-configure a mapping table. After the connection is re-established, re-registration is required. However, in this scheme, each topic needs to be registered and the mapping needs to be established once. The gateway needs to maintain the mapping table for each client. When the near-field connection is frequently established and disconnected, it needs to be re-registered and the mapping state needs to be restored after reconnection, which has a significant overhead. Summary of the Invention

[0003] The purpose of this invention is to provide a unified communication method and system for near-field and cloud-based object models, in order to solve the following technical problems existing in the prior art: In scenarios where smart devices simultaneously support near-field control and cloud-based remote control, how to achieve the unification of near-field channel and cloud-based object model service messages, avoid dual protocol maintenance, inconsistent fields, excessive near-field air interface overhead, and the significant increase in overhead caused by the need to re-register and restore the mapping state after frequent establishment and disconnection of near-field connections in schemes represented by topic registration and mapping mechanisms.

[0004] The objective of this invention can be achieved through the following technical solutions: A unified near-field and cloud-based object model communication method is applied between a mobile terminal and a target device. The mobile terminal and the target device communicate via at least one of multiple near-field links and a cloud message queue telemetry transmission link. The near-field links communicate based on a unified near-field envelope, which includes a subject type field and a service data field. The subject type field does not carry a complete cloud message queue telemetry transmission topic but expresses operational semantics corresponding to the cloud message queue telemetry transmission topic. The service data field carries a complete service message isomorphic to a cloud message queue telemetry transmission request or response body. The communication method includes the following steps: Obtain the connection context of the target device, wherein the connection context includes at least a product identifier and a device identifier; The mobile terminal initiates a request, determines the content of the topic type field and the business data field according to the request type, generates a globally unique request identifier and writes it into the business data field, constructs a unified near-field envelope, and the multiple near-field links share the same unified near-field envelope; The mobile terminal sends data to the target device according to the currently selected channel. When the near-field link is available, the unified near-field envelope is sent to the target device first through the near-field link. When the near-field link is unavailable, the business data field and the cloud message queue telemetry transmission topic are sent to the target device through the cloud message queue telemetry transmission link. Without needing to interact with the sender for topic registration, the target device, based on the received data and the connection context, deterministically generates a device-side topic path consistent with the cloud according to the mapping rules fixed at compile time, and performs routing processing according to the same service routing table, which is applicable to both near-field links and cloud message queue telemetry transmission links. After the target device completes the service execution, it constructs a response message, writes the service data field, and backfills the corresponding globally unique request identifier as is, and then feeds it back to the mobile terminal that initiated the request through the currently selected channel. The mobile terminal parses the received data response and completes the pairing of request and response based on the globally unique request identifier.

[0005] A unified communication method for near-field and cloud object models is applied to the target device side. The method is based on a unified near-field envelope for near-field link communication. The unified near-field envelope includes a topic type field and a service data field. The topic type field does not carry a complete cloud message queue telemetry transmission topic but expresses the operation semantics corresponding to the cloud message queue telemetry transmission topic. The service data field carries a complete service message that is isomorphic to the cloud message queue telemetry transmission request or response body. The communication method includes the following steps: The system receives data transmitted by the mobile terminal through the currently selected channel. When the near-field link is available, it prioritizes receiving the unified near-field envelope sent by the mobile terminal through the near-field link, and multiple near-field links share the same unified near-field envelope. When the near-field link is unavailable, it receives the cloud message queue telemetry transmission topic and the service data field sent by the mobile terminal through the cloud message queue telemetry transmission link. Without needing to interact with the sender for topic registration, based on the connection context and the received data, a device-side topic path consistent with the cloud is deterministically generated according to the mapping rules fixed at compile time, and routing is performed according to the same service routing table, which is applicable to both near-field links and cloud message queue telemetry transmission links. After the business is completed, a response message is constructed, written into the business data field, and the corresponding globally unique request identifier is backfilled as is. The message is then fed back to the mobile terminal that initiated the request through the currently selected channel.

[0006] A unified communication method for near-field and cloud object models is applied to the mobile terminal side. The method is based on a unified near-field envelope for near-field link communication. The unified near-field envelope includes a topic type field and a service data field. The topic type field does not carry a complete cloud message queue telemetry transmission topic, but expresses the operation semantics corresponding to the cloud message queue telemetry transmission topic. The service data field carries a complete service message that is isomorphic to the cloud message queue telemetry transmission request or response body. The communication method includes the following steps: Initiate a request, determine the content of the subject type field and business data field according to the request type, generate a globally unique request identifier and write it into the business data field, construct a unified near-field envelope, and multiple near-field links share the same unified near-field envelope; Data is sent to the target device according to the currently selected channel. When the near-field link is available, the unified near-field envelope is sent to the target device first through the near-field link. When the near-field link is unavailable, the business data field and the cloud message queue telemetry transmission topic are sent to the target device through the cloud message queue telemetry transmission link. Receive data from the target device, parse the response, and complete the pairing of request and response based on the globally unique request identifier.

[0007] The method further includes: When the topic type reported by the target device is attribute change type Further determine whether the target device is in a dual-active state where cloud message queue telemetry transmission connection and near-field session coexist. If it is in the dual-active state, the same attribute reporting service message is fanned out to the cloud and near-field respectively. The attribute reporting service message contains a service identifier and a timestamp. The near-field receiver performs deduplication and merging of cloud push and near-field reporting according to the service identifier and timestamp. If the target device maintains multiple near-field sessions simultaneously, then the same attribute reporting service message will be fanned out to each near-field session respectively; When the cloud message queue telemetry transmission is disconnected, attribute reporting is still performed in the near field; after the cloud reconnects, attribute reporting service messages are resent to the cloud according to incremental or full policies; when the near field link is disconnected, attribute reporting is performed only through the cloud message queue telemetry transmission; near field dedicated messages are not mapped to the cloud message queue telemetry transmission.

[0008] In the dual-active state, attribute reporting is independent of the currently selected channel selection. Even if the currently selected channel is a near-field link, it will not affect the fan-out of attribute reporting service messages to the cloud and other near-field links.

[0009] The near-field link includes at least one of Bluetooth Low Energy link and LAN WebSocket link.

[0010] The method for determining the currently selected channel is as follows: when the mobile terminal and the target device are on the same local area network, a local area network WebSocket link is established after the target device is discovered through the multicast domain name system, which is used as the currently selected channel; when the mobile terminal and the target device are not on the same local area network but Bluetooth is reachable, the paired Bluetooth Low Energy link is used as the currently selected channel; otherwise, the cloud message queue telemetry transmission link is used as the currently selected channel for relay.

[0011] A unified communication system for near-field and cloud-based object models, comprising: The mobile terminal includes an envelope construction module and a response parsing module. The envelope construction module initiates a request, determines the content of the subject type field and the business data field according to the request type, generates a globally unique request identifier and writes it into the business data field, and constructs a unified near-field envelope. The subject type field does not carry a complete cloud message queue telemetry transmission subject but expresses the operational semantics corresponding to the cloud message queue telemetry transmission subject. The business data field carries a complete business message isomorphic to the cloud message queue telemetry transmission request or response body. Multiple near-field links share the same unified near-field envelope. The response parsing module receives data fed back by the target device, parses the response, and completes the pairing of request and response based on the globally unique request identifier. The target device includes a near-field access module, a cloud access module, a topic reconstruction module, a unified routing module, a service module, and a response return module. The near-field access module is communicatively connected to the mobile terminal and is used to receive the unified near-field envelope via a near-field link. The cloud access module is communicatively connected to the cloud and is used to receive a cloud message queue telemetry transmission topic and the service data field via a cloud message queue telemetry transmission link. The topic reconstruction module is data-connected to the near-field access module and is used to deterministically generate a device-side topic path consistent with the cloud, based on the received data and the connection context of the target device, according to a compile-time fixed mapping rule, without requiring topic registration interaction. The unified routing module is data-connected to the topic reconstruction module and the service module and is used to route service packets according to the same service routing table, allocating them to the corresponding service modules for processing. This service routing table is applicable to both the near-field link and the cloud message queue telemetry transmission link. The response return module is data-connected to the service module and, after service execution, constructs a response packet, writes it into the service data field, and backfills the corresponding globally unique request identifier as is, for returning response data to the mobile terminal. The cloud-based device is communicatively connected to the mobile terminal and the target device, and is used to transmit data through a cloud message queue telemetry transmission channel.

[0012] The target device further includes an attribute reporting module, which is data-connected to the unified routing module. In a dual-active state where cloud message queue telemetry transmission connection and near-field session coexist, the module fans out the same attribute reporting service message to both the cloud and near-field sessions. The attribute reporting service message contains a service identifier and a timestamp. The near-field receiver performs deduplication and merging of cloud push and near-field reporting based on the service identifier and timestamp. Furthermore, when the target device maintains multiple near-field sessions simultaneously, the same attribute reporting service message is fanned out to each near-field session.

[0013] The mobile terminal also includes a frame assembly module and a transmission adaptation module; the frame assembly module is data-connected to the envelope construction module and is used to perform packet splitting and reassembly of the unified near-field envelope in Bluetooth Low Energy scenarios, and to perform binary frame encapsulation of the unified near-field envelope in LAN WebSocket scenarios; the transmission adaptation module is communicatively connected to the frame assembly module and is used to perform channel switching between the general attribute configuration file client and the WebSocket client.

[0014] Compared with the prior art, the present invention has the following beneficial effects: (1) The unified near-field envelope constructed in this invention directly expresses the operational semantics corresponding to the cloud topic by using the topic type field, and the business data field carries the complete business message. Thus, the complete topic path can be deterministically reconstructed on the target device side in combination with the connection context. There is no need to perform any topic registration interaction with the sender, zero registration round trip, zero mapping table maintenance, and no need to restore any mapping state after disconnection and reconnection. Compared with the instance-level topic identification registration and mapping mechanism represented by the sensor network message queue telemetry transmission protocol, it completely eliminates the overhead of one registration round trip for each topic, as well as the burden of maintaining the mapping table on the gateway side per client. The effect is particularly significant in mobile application scenarios where near-field connections are frequently established and disconnected.

[0015] (2) This invention reuses a unified near-field envelope on Bluetooth Low Energy links and LAN WebSocket links, and the service data fields are isomorphic to the cloud message queue telemetry transmission request or response body. The mobile terminal software development kit, device firmware, and cloud gateway reuse the same object model service body, eliminating the maintenance cost of dual protocols and reducing the risk of joint debugging errors caused by inconsistencies in fields of the same service on different channels. The same set of service routing tables is applicable to both near-field and cloud links, eliminating the need for gateway protocol conversion and routing mapping, resulting in unified service logic and higher data consistency.

[0016] (3) This invention writes a globally unique request identifier into the business data field, which realizes accurate matching of requests and responses, makes up for the shortcomings of the existing MQTT pure publish / subscribe model, and can directly support bidirectional business scenarios such as command interaction, attribute reading and writing, and service calls.

[0017] (4) In the dual-active state where cloud message queue telemetry transmission connection and near-field session coexist, the present invention constructs a unique attribute reporting service message for attribute change reporting and fans it out to the cloud and near-field respectively, while only sending back query response or attribute setting to the channel or connection that initiated the request. This clarifies the orthogonal routing rules of reporting messages and response messages when multiple connections coexist, avoids missing attribute change notifications and incorrect fan-out of query response and attribute setting to non-initiators, and ensures the consistency of end-cloud state. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the system structure of the present invention.

[0019] Figure 2 This is a flowchart of the method of the present invention.

[0020] Figure 3 This is a schematic diagram of the architecture for protocol layering and unified envelope mapping.

[0021] Figure 4 This is a schematic diagram of the fan-out timing for attribute reporting in a dual-active state.

[0022] Figure 5 A flowchart illustrating the selection process for the currently selected channel.

[0023] Figure 6 This is a comparison chart showing the change in the number of round-trip messages between the present invention and MQTT-SN as the number of service topics changes. Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] It should be noted that, unless otherwise specified, the features in the following embodiments and implementation methods can be combined with each other.

[0026] This embodiment proposes a unified communication method and system for near-field and cloud object models. The core idea is to reuse a unified near-field envelope on the near-field link. The service data fields within the envelope are isomorphic to the telemetry transmission request or response body of the cloud message queue. The device side deterministically reconstructs the complete topic path based on the topic type field and the connection context according to a compile-time fixed mapping rule, without requiring any topic registration interaction with the sender. The near-field link and the cloud share the same service routing table. In a dual-active state where cloud connections and near-field sessions coexist, an orthogonal notification strategy is explicitly defined for multi-channel fan-out attribute reporting and single-path backhaul of attribute setting / query responses, thereby eliminating the maintenance costs of dual protocols, reducing near-field air interface overhead, and ensuring end-to-cloud state consistency. This embodiment uses a Bluetooth Low Energy (BLE) Universal Attribute Profile (GATT) link and a LAN WebSocket link as examples to illustrate near-field communication.

[0027] In one implementation, reference Figure 1The communication system consists of three parts: a mobile terminal 101, a cloud platform 102, and a target device 103. These three parts are interconnected via a near-field BLE link 141, a near-field LAN WebSocket link 142, and a cloud-based MQTT link 143. The system eliminates the differences between near-field and cloud links through a unified protocol envelope, achieving standardization of object model communication.

[0028] Mobile terminal 101 serves as the user-side interaction entry point, and is divided into four logical layers from top to bottom: the business layer, the protocol layer, the framing layer, and the transmission adaptation layer. The business layer includes a near-field management module 111, which provides property and command request interfaces to the outside world, handling property reporting callbacks and interface refreshes. When calling the business layer, only the topic type and business body need to be specified; the underlying transmission channel's specific form is not required. The protocol layer includes an envelope construction module 112, responsible for constructing and parsing unified near-field envelopes. Internally, the envelope construction module 112 maintains a queue of pending requests indexed by both connection identifier and request identifier, handling request-response pairing and timeout logic. Each time a request is initiated, the envelope construction module 112 generates a globally unique request identifier, writes it into the business data field, and then encapsulates it together with the topic type field into a unified near-field envelope. Upon receiving a response, the envelope construction module 112 locates the corresponding request based on the request identifier in the business data field, completes the pairing, and sends the result back to the upper layer. The framing layer includes a framing assembly module 113, responsible for envelope adaptation under different near-field transmission media. In BLE scenarios, the framing assembly module 113 performs link-layer (L1) packet splitting and reassembly on the unified near-field envelope, breaking down larger envelopes into multiple packets that conform to the BLE Maximum Transmission Unit (MTU) limit, and reassembling them at the receiving end. In WebSocket scenarios, the framing assembly module 113 encapsulates the unified near-field envelope into binary frames for direct transmission. The response parsing module 114 parses the response based on the received data and completes the pairing of request and response according to the globally unique request identifier. The transmission adaptation layer, namely the transmission adaptation module 115, integrates the transmission capabilities of both GATT client and WebSocket client, and is responsible for channel selection, connection establishment, feature subscription, and message sending and receiving. The transmission adaptation module automatically selects the optimal near-field channel according to the current network environment, keeping the upper-layer protocol stack unaware during channel switching.

[0029] Cloud 102 is the single source of fact defined by the object model, providing core capabilities such as MQTT broker, device shadow management, application push, and command relay. Cloud 102 can communicate directly with the target device 103 via the MQTT link, and can also act as a relay node to forward control commands from mobile terminal 101 when the near field is unavailable. As the authoritative data source, the object model definition maintains strict isomorphism between near-field business data fields and cloud business entities, ensuring semantic consistency across the three channels.

[0030] The target device 103, as an IoT controlled device, is divided into four logical layers from top to bottom: the business layer, the protocol routing layer, the reporting management layer, and the access layer. The access layer includes a near-field access module 131 and a cloud access module 132. The near-field access module 131 includes two access modes: a BLE GATT server and a WebSocket server. The BLE GATT server sets up multiple GATT features with separated responsibilities, respectively carrying four types of messages: request write, response notification, proactive reporting, and read-only configuration information. The WebSocket server, in conjunction with the multicast Domain Name System (mDNS) service, enables device discovery and connection establishment within the local area network. The near-field access module is responsible for receiving unified near-field envelopes from the mobile terminal 101 and passing the restored envelope content upwards to the protocol routing layer. The protocol routing layer includes a topic reconstruction module 133 and a unified routing module 134. The topic reconstruction module 133 parses the topic type field in the envelope, combines it with the product identifier and device identifier in the connection context, and deterministically generates the device-side MQTT topic path according to the mapping rules fixed at compile time. The unified routing module 134 distributes packets to the corresponding business modules 135 in the business layer according to the generated topic path and service identifier in the business data field, based on the business routing table. The same business routing table serves both the near-field link and the cloud MQTT link simultaneously, eliminating the need for gateway protocol conversion and route mapping. The reporting management layer, i.e., the attribute reporting module 137, serves as the unified exit for attribute changes and is responsible for executing corresponding reporting strategies under different connection topologies. When the device simultaneously maintains a cloud MQTT connection and at least one near-field session (dual-active state), the attribute reporting module 137 fans out the same attribute reporting business packets to both the cloud and near-field nodes; for attribute setting / query responses, the attribute reporting module 137 only sends the response back to the channel or connection that initiated the request, without fanning it out to other sessions. The business layer sets up multiple business modules 135, covering functional units such as network, control, and battery. Each business module may generate attribute change events and execute command requests; the business logic is completely transparent to the underlying transmission channel. The response feedback module 136 is integrated into the near-field access module and the cloud access module. After the business is executed, it constructs a response message, writes the business data field, and backfills the corresponding globally unique request identifier as is, and then sends it back to the initiator through the original receiving channel.

[0031] The unified near-field envelope (TopicEnvelope) is a unified protocol carrier across the entire link, sharing the same structure on both BLE and WebSocket near-field channels. The envelope core contains two fields: a topic type field (topic_type) and a business data field (mqtt_data). The topic type field is an operation semantic enumeration, expressing the operation category corresponding to the cloud MQTT topic, such as attribute setting request, attribute setting response, attribute query, attribute reporting, command request, command response, near-field heartbeat, etc. The topic type field is not a short identifier for a specific topic instance, but rather an abstraction of the operation semantic category; one enumeration can cover all device instances. The business data field carries a complete business message isomorphic to the cloud MQTT request or response body. The serialized bytes may contain fields such as request identifier (request_id), service identifier (service_id), business data and result code (code), and result description (msg). The near-field link does not transmit the complete MQTT topic string. Product identification, device identification, object model version and other information all come from the connection context and are not transmitted repeatedly in each service message, thus significantly reducing near-field air interface overhead.

[0032] In some implementations, refer to Figure 2 This describes the complete process of unified communication between near-field and cloud-based object models, including the following steps: Step S1: Obtain the connection context of the target device.

[0033] During the near-field link establishment phase, mobile terminal 101 obtains the connection context of target device 103. The connection context includes at least the product identifier (product_key) and device identifier (device_id). The method of obtaining the connection context varies depending on the near-field link type. For BLE links, mobile terminal 101 reads the read-only configuration file information (Profile-Info) of target device 103 after the connection is established, and obtains and caches information such as product identifier, device identifier, and object model version. For WebSocket links, mobile terminal 101 obtains the corresponding information through mDNS text records (TXT records). The connection context is obtained once during link establishment and cached in the envelope construction module. Subsequent business messages can omit redundant fields such as product identifier and device identifier, significantly reducing message length. The object model version is cached as the connection context after negotiation through read-only features and is not repeatedly transmitted in each near-field message.

[0034] Step S2: The mobile terminal initiates a request to construct a unified near-field envelope.

[0035] The near-field management module of the mobile terminal 101 initiates a request based on business requirements, specifying the operation type and corresponding business body. After receiving the request, the envelope construction module generates a globally unique request identifier (request_id), writes it into the business data field, sets the value of the subject type field according to the request type, and finally encapsulates the subject type field and business data field into a unified near-field envelope. The globally unique request identifier can adopt a universally unique identifier (UUID) or other formats to ensure uniqueness across sessions and channels, used for accurate matching of subsequent requests and responses. Multiple near-field links share the same unified near-field envelope structure, achieving seamless switching of channels without changing the business protocol.

[0036] Step S3: The mobile terminal sends data according to the currently selected channel.

[0037] Based on the current channel selection result, mobile terminal 101 selects the optimal path to send the unified near-field envelope to target device 103. When the near-field link is available, it prioritizes transmission via the near-field link; when the near-field link is unavailable, it sends the business data fields and the cloud MQTT topic to target device 103 via the cloud MQTT link. In the BLE scenario, the frame assembly module performs link-layer packetization on the unified near-field envelope, splitting the envelope into multiple packets conforming to BLE MTU limits, which are then sent sequentially by the GATT client of the transport adapter module based on write request characteristics. In the WebSocket scenario, the frame assembly module encapsulates the unified near-field envelope into binary frames, which are then sent directly by the WebSocket client. Multi-feature responsibility separation further reduces overhead on the BLE link. The near-field access module uses four GATT features: the first feature is a write request feature, carrying attribute setting, attribute query, or command request messages; the second feature is a response notification feature, carrying response messages; the third feature is an active reporting feature, carrying attribute reporting messages; and the fourth feature is a read-only configuration file information feature, storing connection context information such as product identifier, device identifier, and object model version. The message direction is implicitly defined by the features used, eliminating the need for additional message type fields in the business data fields, thus further saving byte overhead per message.

[0038] Step S4: The target device generates a device-side topic path and performs routing processing.

[0039] After receiving data, the near-field access module of target device 103 first performs link-layer packet reassembly in the BLE scenario and directly parses the binary frame in the WebSocket scenario, restoring it into a unified near-field envelope. The topic reconstruction module parses the topic type field in the envelope, combines it with the product identifier and device identifier in the connection context, and deterministically generates a device-side topic path consistent with the cloud according to the mapping rules fixed at compile time. The topic path generation process does not require any topic registration interaction with mobile terminal 101. The mapping rules are fixed at compile time, can be used as soon as the connection is established, and do not require restoration of any mapping state after disconnection and reconnection. This mechanism is fundamentally different from the instance-level topic identifier registration and mapping mechanism in the MQTT-SN protocol: MQTT-SN requires one registration round trip to establish mapping for each topic, and the gateway side needs to maintain the mapping table according to the client. In contrast, this embodiment has zero registration round trips, zero mapping table maintenance, and zero recovery overhead after disconnection and reconnection. The unified routing module distributes the service message to the corresponding service module for execution according to the generated topic path and the service identifier in the service data field, according to the same service routing table. The same service routing table applies to both near-field links and cloud MQTT links, and the service layer is completely unaware of channel switching. When the near-field channel is unavailable, the mobile terminal 101 sends standard MQTT commands or attribute settings to the target device 103 via the cloud MQTT link 143; the unified routing module of the target device 103 still uses the same service routing table and processes the service module, keeping the business logic consistent.

[0040] Step S5: The target device constructs a response message and sends it back.

[0041] After the business module completes its corresponding operation, it returns the result to the unified routing module. The unified routing module constructs the response business data fields, fills in the request identifier as is, and encapsulates it together with the topic type fields (such as attribute setting response, attribute query response, command response, etc.) into a unified near-field envelope. This envelope is then sent back to the mobile terminal 101 via the near-field access module using response notification features (BLE scenario) or a WebSocket frame (WebSocket scenario). The response is only sent back to the connection that initiated the request and is not fanned out to other near-field sessions or unrelated channels. If the attribute setting is successful and triggers a device state change, the attribute reporting module further triggers the attribute reporting fan-out process.

[0042] Step S6: The mobile terminal parses the response and completes the request-response pairing.

[0043] After receiving the response data, the transmission adaptation module of mobile terminal 101 reassembles the data at the frame layer and passes the restored unified near-field envelope to the envelope construction module. The envelope construction module parses the business data fields, extracts the request identifier, locates the corresponding original request in the pending request queue, completes the request-response pairing, and sends a callback of the execution result to the business layer near-field management module. By writing the globally unique request identifier into the business data fields, precise matching of requests and responses is achieved, compensating for the shortcomings of the pure publish / subscribe model of MQTT in bidirectional interaction scenarios. It can directly support various bidirectional business modes such as command interaction, attribute reading / writing, and service calls.

[0044] Reference Figure 3 The system is divided into three layers in terms of protocol: the third layer is cloud MQTT, which includes a complete topic string and a complete business body (corresponding to business semantics such as attribute settings, attribute queries, attribute reporting, command requests and responses in the object model definition); the second layer is a unified near-field envelope layer, which includes topic type fields and business data fields. This layer acts as an adaptation layer, connecting to the unified object model business semantics above and shielding the differences between different near-field transmission media below; the first layer is the near-field transmission layer. The BLE channel uses link-layer packetization plus GATT feature carrying, while the WebSocket channel uses binary frames. The cloud MQTT channel uses a complete topic string; the near-field channel only transmits the topic type field. The product identifier and device identifier come from the connection context and are mapped by the device side to generate the complete topic path. The near-field link does not transmit the complete message queue telemetry transmission topic string. The product identifier and device identifier come from the connection context, and redundant fields that can be deduced from the context can be omitted in the business data field, thereby reducing the air interface overhead of each message. After receiving the unified near-field envelope, the device side combines the product identifier and device identifier in the connection context and, based on the mapping rules fixed at compile time, deterministically maps the operation semantic category expressed by the operation semantic category identifier field to the complete device-side topic path. This mapping rule can be used directly without any registration round trip, and no mapping state needs to be restored after disconnection and reconnection. This is fundamentally different from the instance-level topic identifier registration and mapping mechanism in the sensor network message queue telemetry transmission protocol.

[0045] This embodiment further illustrates the attribute reporting fan-out strategy in DUAL_ACTIVE mode. DUAL_ACTIVE mode refers to the target device 103 simultaneously maintaining a cloud MQTT connection and at least one near-field session connection topology. (Refer to...) Figure 4When the topic type reported by target device 103 is attribute change, the system first determines whether the current connection topology is in a dual-active state. If it is in a dual-active state, the same attribute reporting service message is fanned out to the cloud and near-field respectively; the attribute reporting service message contains a service identifier and a timestamp, and the near-field receiver deduplicates and merges the cloud push and near-field report according to the service identifier and timestamp. The specific execution flow of attribute reporting in dual-active state is as follows: Step S401: When the business module detects an attribute change, it reports the attribute change event to the attribute reporting module. The event carries the service identifier (service_id), attribute data, and timestamp.

[0046] Step S402: The attribute reporting module constructs a unique attribute reporting service message (DevicePropertiesReport), which contains a service identifier and a timestamp.

[0047] Step S403: The attribute reporting module publishes the attribute reporting service message to the cloud MQTT attribute reporting topic. After receiving the message, the cloud updates the device shadow. At the same time, the attribute reporting module encapsulates the attribute reporting service message into a unified near-field envelope (the topic type field takes the attribute reporting category, and the business data field is the same attribute reporting service message), and sends it to the mobile terminal via the near-field link.

[0048] Step S404: After the device shadow update is completed in the cloud, a cloud attribute change notification is pushed to the mobile terminal.

[0049] Step S405: The mobile terminal receives the near-field report first via the near-field link, and the service layer near-field management module immediately refreshes the interface.

[0050] Step S406: If the mobile terminal subsequently receives a cloud push, the envelope construction module identifies the notification and the near-field report as belonging to the same attribute change event based on the service identifier and timestamp in the business message, performs deduplication and merging, and avoids repeated page refreshes.

[0051] When the target device maintains multiple near-field sessions simultaneously, attribute reporting service messages are fanned out to each near-field session to ensure that all online near-field connections can obtain attribute changes in a timely manner. For attribute setting or query responses, the attribute reporting module only sends the response back to the channel or connection that initiated the request, and does not fan it out to other near-field sessions or cloud channels, ensuring instruction isolation between different sessions.

[0052] In another implementation, when the cloud MQTT connection is lost, attribute reporting continues normally in the near-field environment. After the cloud connection is reconnected, the attribute reporting module resends attribute reporting service messages to the cloud MQTT attribute reporting topic according to an incremental or full strategy, ensuring data consistency between the end and the cloud. When the near-field link is lost, the device only performs attribute reporting through the cloud MQTT; other mobile terminals rely on cloud push or pull of device shadows to obtain attribute status. Near-field dedicated messages (such as link heartbeats, control arbitration, etc.) are not mapped to the cloud MQTT channel. After the near-field connection is restored, the target device can continue to perform low-latency control through a unified near-field envelope. Attribute reporting automatically switches fan-out targets according to the current connection topology, and the service module does not need to maintain two sets of processing logic. It is important to emphasize that attribute reporting and the currently selected channel selection are independent of each other in the dual-active state. Even if the currently selected channel is a near-field link, it does not affect the fan-out of attribute reporting service messages to the cloud and other near-field links. Channel selection only constrains the selection of the mobile terminal's downlink control entry point and is orthogonal to the fan-out rules of the target device's uplink attribute reporting, without interfering with each other. Through the above orthogonal design, different routing rules for reporting messages and response messages are clarified when multiple connections coexist: multi-channel fan-out for attribute change messages ensures no notification is missed, and single-path return for command / set / query responses avoids erroneous fan-out, thereby ensuring consistency of end-cloud status and isolation of multiple sessions.

[0053] Reference Figure 5This embodiment further illustrates the specific types of near-field links and the method for determining the currently selected channel. Near-field links include at least one of BLE links and LAN WebSocket links. The method for determining the currently selected channel is as follows: When the mobile terminal and the target device are on the same LAN, a LAN WebSocket link is established after discovering the target device via mDNS, and this link is used as the currently selected channel; when the mobile terminal and the target device are not on the same LAN but Bluetooth is reachable, the paired BLE link is used as the currently selected channel; otherwise, the cloud MQTT link is used as the currently selected channel for relay. Specifically, when the mobile terminal initiates downlink control, channel selection is determined according to the following priority order: First, it is determined whether the mobile terminal and the target device are on the same LAN. If so, the target device is discovered via mDNS, and the WebSocket client in the transmission adapter module establishes a WebSocket connection, using binary frames to carry unified near-field envelopes for transmission. The WebSocket channel has high bandwidth and low latency, making it suitable for large data volume interaction scenarios within the same LAN. If they are not on the same LAN, it is further determined whether the BLE signal is reachable. If Bluetooth is available, the GATT client in the transmission adapter module sends unified near-field envelopes via a paired BLE connection, carrying them in link-layer packet format. The BLE channel does not rely on a local area network environment and is suitable for local direct control in scenarios where the device is not network-connected or is out of the network. If Bluetooth is also unavailable, the mobile terminal sends standard MQTT commands to the cloud via a cloud-based MQTT link, which are then forwarded to the target device. The cloud-based relay mode has the widest coverage, allowing remote control as long as the device is connected to the internet, but the latency is relatively high. After discovering the target device via mDNS, the mobile terminal establishes a WebSocket connection and sends a unified near-field envelope with the exact same structure as the BLE scenario, using binary frames. Upon receiving this, the target device's WebSocket server generates the topic and uses the same routing logic as the BLE scenario, truly achieving a change in channel without a change in service protocol.

[0054] This embodiment uses Protocol Buffers (proto3) line format to perform byte-by-byte deterministic calculation of message length in typical scenarios, quantifying the technical effect of this invention in terms of near-field air interface overhead. The calculation parameters are set as follows: the request identifier is a 36-byte UUID string; the device identifier is 31 bytes (4-byte product identifier prefix + separator + 27-bit hash character); the WiFi configuration service leaflet includes a service set identifier (11 bytes), a password (8 bytes), and an encryption type field; BLE maximum transmission unit (MTU) = 185 bytes (ATT single packet payload is approximately 182 bytes). The comparison is with a scheme that directly transmits the complete MQTT topic string and redundant context fields such as product identifier, device identifier, and model version on the near-field link. The calculation results are as follows: In the scenario of requesting WiFi network configuration attributes, the message length of the direct transparent transmission solution is 240 bytes, which exceeds the 182-byte effective payload of a single frame and needs to be transmitted in 2 frames; the message length of the solution of this invention is 77 bytes, which can be transmitted in a single frame, reducing the message length by 67.9%.

[0055] In a scenario where responses to 8 service attributes are queried in batches, the direct pass-through solution is 2050 bytes (8 independent messages), while the solution of this invention is 433 bytes (batch carrying in a single envelope), reducing the message length by 78.9%.

[0056] In a scenario where the motion control attribute is set at 20 Hz, the direct pass-through scheme is 228 bytes per packet (4560 bytes per second), while the scheme of this invention is 65 bytes per packet (1300 bytes per second), resulting in a 71.5% reduction in air interface occupancy.

[0057] The aforementioned byte data represents the deterministic calculation result of the protocol line format and is reproducible. The significant reduction in message length stems primarily from three aspects: First, the topic type field only expresses the semantic category of the operation, not the specific topic instance identifier, omitting the complete topic string; second, the connection context is cached once during link establishment, allowing subsequent business messages to omit redundant fields such as product identifier and device identifier; and third, BLE's multi-feature responsibility separation eliminates the need for additional message type fields in business messages. Furthermore, compared to instance-level topic identifier registration and mapping mechanisms represented by MQTT-SN, this invention also has a significant advantage in terms of the number of round trips: MQTT-SN requires one REGISTER / REGACK round trip per topic; this invention directly sends a unified near-field envelope after reading the connection context once, resulting in zero mapping registration round trips. Specifically, in terms of mapping establishment, MQTT-SN requires one REGISTER / REGACK registration round trip per topic, while the mapping rules of this invention are fixed at compile time, allowing direct use with zero registration round trips. Regarding reconnection after disconnection, MQTT-SN requires re-registration or restoration of the mapping state, while this invention requires no restoration action and is ready to use immediately upon connection establishment. Figure 6The figure shows the relationship between the number of round-trip messages and the number of business topics N. As can be seen from the figure, each topic in MQTT-SN corresponds to one REGISTER and one REGACK, with a message count of 2N. The mapping overhead of this scheme is always 0, regardless of the number of topics. Here, N is a typical object model operation type (attribute setting / query / reporting, command request / response, heartbeat, etc.). During reconnection, the MQTT-SN overhead occurs again as 2N, while this scheme remains 0. In terms of state maintenance, the MQTT-SN gateway / device side needs to maintain a topic identifier mapping table according to the client, while this invention does not have a mapping table and only relies on the existing connection context. In mobile application scenarios where near-field connections are frequently established and disconnected, the overhead savings brought about by the above differences are particularly significant. The comparison of the total communication process overhead of the scheme of this invention and MQTT-SN is shown in Table 1.

[0058] Table 1

[0059] The core difference between this invention and MQTT-SN lies in the registration phase. In a steady state (i.e., the same topic has been registered and the same connection context has been cached), both schemes use a short topic identifier plus business data, and the business data does not contain the topic. At this point, the single packet length is similar, with the only difference being that MQTT-SN uses a 2-byte topic id, while this invention uses topic_type, and that this invention can also omit fields that can be inferred from the context from the business body.

[0060] In summary, this invention offers the following technical advantages: First, it achieves cross-platform protocol homogeneity. The App SDK, device firmware, and cloud gateway reuse the same object model business entity, reducing the maintenance costs of dual protocols and mitigating the risk of debugging errors caused by inconsistent fields. Second, it provides controllable near-field bandwidth. By omitting complete topic strings and inferable context fields, it balances BLE air interface efficiency and latency stability, resulting in a 60% to 80% reduction in message length in typical scenarios. Third, it ensures seamless channel switching. WebSocket is prioritized within the same local area network, BLE is used if Bluetooth is available, and cloud MQTT is used otherwise. The business layer consistently uses a unified envelope and routing semantics, making channel switching transparent to the upper layer. Fourth, it improves consistency between end-to-end and cloud states. In dual-active scenarios, dual-channel fan-out for attribute reporting ensures no notifications are missed, command / setting responses are only sent back to the initiator to avoid false notifications, and a deduplication and merging mechanism prevents repeated interface refreshes. Fifth, the direction is implicitly conveyed by transmission characteristics. Requests, responses, and reports on BLE are carried by different characteristics, eliminating the need to set additional message type fields in business messages and further saving air interface overhead.

[0061] Understandably, without departing from the core technical concept of this application, the following alternative or extended solutions can be adopted. First, the near-field transmission channel is not limited to Bluetooth Low Energy and WebSocket; it can also be other near-field or LAN channels such as private reliable transmission based on User Datagram Protocol (UDP) or Bluetooth classic serial port emulation, as long as the same unified near-field envelope format is maintained. Second, the serialization method of the unified near-field envelope and service data fields is not limited to the protocol buffer format; it can also adopt concise data exchange format, compact binary, or other serialization methods, as long as the near-field and cloud service fields can be mapped losslessly. Third, the representation of the topic type field is not limited to enumeration types; it can also be a short integer opcode or hash digest, with the complete topic path generated by a table lookup on the device side. The mapping rules remain fixed at compile time. Fourth, the attribute reporting fan-out strategy is not limited to dual-fan-out in dual-active mode; it can also select to report only to the cloud, only to the near-field, or dual-fan-out based on attribute importance level, subscription relationship, or device power strategy. Command responses still adhere to the single-path return principle. Fifth, the method of this application can be applied to terminal devices such as routers, cameras, energy storage devices, charging devices, and home appliances that have both near-field direct connection and cloud object model capabilities, as well as corresponding mobile terminal software development kits and cloud access gateways.

[0062] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0063] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0064] If the technical solution of this application involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution of this application involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the individual through pop-up information or by asking the individual to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

[0065] The preferred embodiments of the present invention have been described in detail above. It should be understood that those skilled in the art can make numerous modifications and variations based on the concept of the present invention without creative effort. Therefore, all technical solutions that can be obtained by those skilled in the art based on the concept of the present invention through logical analysis, reasoning, or limited experimentation on the basis of existing technology should be within the scope of protection defined by the claims.

Claims

1. A unified near-field and cloud-based object model communication method, applied between a mobile terminal and a target device, wherein the mobile terminal and the target device communicate via at least one of multiple near-field links and cloud message queue telemetry transmission links, characterized in that, The near-field link communicates based on a unified near-field envelope, which includes a subject type field and a service data field. The subject type field does not carry a complete cloud message queue telemetry transmission subject but expresses operational semantics corresponding to the cloud message queue telemetry transmission subject. The service data field carries a complete service message isomorphic to the cloud message queue telemetry transmission request or response body. The communication method includes the following steps: Obtain the connection context of the target device, wherein the connection context includes at least a product identifier and a device identifier; The mobile terminal initiates a request, determines the content of the topic type field and the business data field according to the request type, generates a globally unique request identifier and writes it into the business data field, constructs a unified near-field envelope, and the multiple near-field links share the same unified near-field envelope; The mobile terminal sends data to the target device according to the currently selected channel. When the near-field link is available, the unified near-field envelope is sent to the target device first through the near-field link. When the near-field link is unavailable, the business data field and the cloud message queue telemetry transmission topic are sent to the target device through the cloud message queue telemetry transmission link. Without needing to interact with the sender for topic registration, the target device, based on the received data and the connection context, deterministically generates a device-side topic path consistent with the cloud according to the mapping rules fixed at compile time, and performs routing processing according to the same service routing table, which is applicable to both near-field links and cloud message queue telemetry transmission links. After the target device completes the service execution, it constructs a response message, writes the service data field, and backfills the corresponding globally unique request identifier as is, and then feeds it back to the mobile terminal that initiated the request through the currently selected channel. The mobile terminal parses the received data response and completes the pairing of request and response based on the globally unique request identifier.

2. The communication method for unifying near-field and cloud-based object models according to claim 1, characterized in that, The method further includes: When the topic type reported by the target device is attribute change type Further determine whether the target device is in a dual-active state where cloud message queue telemetry transmission connection and near-field session coexist. If it is in the dual-active state, the same attribute reporting service message is fanned out to the cloud and near-field respectively. The attribute reporting service message contains a service identifier and a timestamp. The near-field receiver performs deduplication and merging of cloud push and near-field reporting according to the service identifier and timestamp. If the target device maintains multiple near-field sessions simultaneously, then the same attribute reporting service message will be fanned out to each near-field session respectively; When the cloud message queue telemetry transmission is disconnected, attribute reporting is still performed in the near field; after the cloud reconnects, attribute reporting service messages are resent to the cloud according to incremental or full policies; when the near field link is disconnected, attribute reporting is performed only through the cloud message queue telemetry transmission; near field dedicated messages are not mapped to the cloud message queue telemetry transmission.

3. The communication method for unifying near-field and cloud-based object models according to claim 2, characterized in that, In the dual-active state, attribute reporting is independent of the currently selected channel selection. Even if the currently selected channel is a near-field link, it will not affect the fan-out of attribute reporting service messages to the cloud and other near-field links.

4. The communication method for unifying near-field and cloud-based object models according to claim 1, characterized in that, The near-field link includes at least one of Bluetooth Low Energy link and LAN WebSocket link.

5. The communication method for unifying near-field and cloud-based object models according to claim 4, characterized in that, The method for determining the currently selected channel is as follows: when the mobile terminal and the target device are on the same local area network, after discovering the target device through the multicast domain name system, a local area network WebSocket link is established as the currently selected channel; When the mobile terminal and the target device are not on the same local area network and Bluetooth is reachable, the paired Bluetooth Low Energy link will be used as the currently selected channel. Otherwise, the cloud message queue telemetry transmission link will be used as the currently selected channel for relay.

6. A unified communication method for near-field and cloud-based object models, applied to the target device side, characterized in that, This method is based on a unified near-field envelope for near-field link communication. The unified near-field envelope includes a topic type field and a service data field. The topic type field does not carry a complete cloud message queue telemetry transmission topic but expresses the operation semantics corresponding to the cloud message queue telemetry transmission topic. The service data field carries a complete service message that is isomorphic to the cloud message queue telemetry transmission request or response body. The communication method includes the following steps: The system receives data transmitted by the mobile terminal through the currently selected channel. When the near-field link is available, it prioritizes receiving the unified near-field envelope sent by the mobile terminal through the near-field link, and multiple near-field links share the same unified near-field envelope. When the near-field link is unavailable, it receives the cloud message queue telemetry transmission topic and the service data field sent by the mobile terminal through the cloud message queue telemetry transmission link. Without needing to interact with the sender for topic registration, based on the connection context and the received data, a device-side topic path consistent with the cloud is deterministically generated according to the mapping rules fixed at compile time, and routing is performed according to the same service routing table, which is applicable to both near-field links and cloud message queue telemetry transmission links. After the business is completed, a response message is constructed, written into the business data field, and the corresponding globally unique request identifier is backfilled as is. The message is then fed back to the mobile terminal that initiated the request through the currently selected channel.

7. A unified communication method for near-field and cloud-based object models, applied to the mobile terminal side, characterized in that, This method is based on a unified near-field envelope for near-field link communication. The unified near-field envelope includes a topic type field and a service data field. The topic type field does not carry a complete cloud message queue telemetry transmission topic but expresses the operation semantics corresponding to the cloud message queue telemetry transmission topic. The service data field carries a complete service message that is isomorphic to the cloud message queue telemetry transmission request or response body. The communication method includes the following steps: Initiate a request, determine the content of the subject type field and business data field according to the request type, generate a globally unique request identifier and write it into the business data field, construct a unified near-field envelope, and multiple near-field links share the same unified near-field envelope; Data is sent to the target device according to the currently selected channel. When the near-field link is available, the unified near-field envelope is sent to the target device first through the near-field link. When the near-field link is unavailable, the business data field and the cloud message queue telemetry transmission topic are sent to the target device through the cloud message queue telemetry transmission link. Receive data from the target device, parse the response, and complete the pairing of request and response based on the globally unique request identifier.

8. A unified communication system for near-field and cloud-based object models, characterized in that, include: The mobile terminal includes an envelope construction module and a response parsing module. The envelope construction module is used to initiate a request, determine the content of the subject type field and the business data field according to the request type, generate a globally unique request identifier and write it into the business data field, and construct a unified near-field envelope. The subject type field does not carry a complete cloud message queue telemetry transmission subject but expresses the operation semantics corresponding to the cloud message queue telemetry transmission subject. The business data field carries a complete business message that is isomorphic to the cloud message queue telemetry transmission request or response body. Multiple near-field links share the same unified near-field envelope; the response parsing module receives data from the target device, parses the response, and completes the pairing of request and response based on the globally unique request identifier; The target device includes a near-field access module, a cloud access module, a topic reconstruction module, a unified routing module, a service module, and a response return module. The near-field access module is communicatively connected to the mobile terminal and is used to receive the unified near-field envelope via a near-field link. The cloud access module is communicatively connected to the cloud and is used to receive a cloud message queue telemetry transmission topic and the service data field via a cloud message queue telemetry transmission link. The topic reconstruction module is data-connected to the near-field access module and is used to deterministically generate a device-side topic path consistent with the cloud, based on the received data and the connection context of the target device, according to a compile-time fixed mapping rule, without requiring topic registration interaction. The unified routing module is data-connected to the topic reconstruction module and the service module and is used to route service packets according to the same service routing table, allocating them to the corresponding service modules for processing. This service routing table is applicable to both the near-field link and the cloud message queue telemetry transmission link. The response return module is data-connected to the service module and, after service execution, constructs a response packet, writes it into the service data field, and backfills the corresponding globally unique request identifier as is, for returning response data to the mobile terminal. The cloud-based device is communicatively connected to the mobile terminal and the target device, and is used to transmit data through a cloud message queue telemetry transmission channel.

9. A communication system for unifying near-field and cloud-based object models according to claim 8, characterized in that, The target device further includes an attribute reporting module, which is data-connected to the unified routing module. In a dual-active state where cloud message queue telemetry transmission connection and near-field session coexist, the module fans out the same attribute reporting service message to both the cloud and near-field sessions. The attribute reporting service message contains a service identifier and a timestamp. The near-field receiver performs deduplication and merging of cloud push and near-field reporting based on the service identifier and timestamp. Furthermore, when the target device maintains multiple near-field sessions simultaneously, the same attribute reporting service message is fanned out to each near-field session.

10. A communication system for unifying near-field and cloud-based object models according to claim 8, characterized in that, The mobile terminal also includes a frame assembly module and a transmission adaptation module; the frame assembly module is data-connected to the envelope construction module and is used to perform packet splitting and reassembly of the unified near-field envelope in Bluetooth Low Energy scenarios, and to perform binary frame encapsulation of the unified near-field envelope in LAN WebSocket scenarios. The transmission adaptation module is communicatively connected to the frame assembly module and is used to perform channel switching between the general attribute configuration file client and the WebSocket client.

Images