Cellular passive service intention analysis method, device, network equipment and system

Abstract

The invention relates to the technical field of communication, and provides a cellular passive service intention analysis method, device, network equipment and system. The method comprises the following steps: acquiring a service intention request corresponding to a service server; analyzing the service intention request to obtain an intention descriptor corresponding to the service intention request; the intention descriptors are used for representing structured cellular passive service elements; based on the intention descriptor, determining protocol execution parameters and filtering information conforming to the underlying network protocol; and determining an executable task message sequence based on the intention descriptor, the filtering information and the protocol execution parameters. According to the embodiment of the invention, the method can achieve the automatic conversion from a high-level intention to a bottom-layer instruction, prevents a business server from understanding a bottom-layer protocol structure, remarkably reduces the integration and development complexity of a system, improves the development efficiency and the automation level of the system, and enables the deployment and application of cellular passive business to be more flexible and convenient.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, and in particular to a method and apparatus for analyzing service intent of a cellular passive system, a network device and a system. BACKGROUND

[0002] Ambient power-enabled Internet of Things (Ambient IoT) is a new type of Internet of Things technology supported in 5G networks. Ambient IoT has the characteristics of a terminal device that generally does not have a continuous power supply, but is activated by external wireless energy for short-term communication, and can achieve extremely low device cost and a super-long life cycle, and is suitable for scenarios such as large-scale asset management, warehouse inventory, and supply chain tracking.

[0003] In the prior art, the cellular passive system defined based on the 3GPP TS 23.369 protocol can only receive complete protocol parameters submitted by a service server. The service server needs to understand the parameter structure of the underlying protocol by itself, and construct binary protocol parameters such as bitstring, Offset, and Length, which leads to complex and error-prone service processing, and seriously limits the rapid integration and flexible application of cellular passive services. SUMMARY

[0004] Embodiments of the present application provide a method and apparatus for analyzing service intent of a cellular passive system, a network device and a system, to solve the problem that the cellular passive system lacks analysis of service semantics in the prior art, leading to complex and error-prone service processing, and seriously limiting the rapid integration and flexible application of cellular passive services.

[0005] In a first aspect, embodiments of the present application provide a method for analyzing service intent of a cellular passive system, applied to a service orchestration function entity (SOF) arranged between a core network and a service server, including the following steps.

[0006] Obtaining a service intent request corresponding to the service server.

[0007] Analyzing the service intent request to obtain an intent descriptor corresponding to the service intent request; the intent descriptor is used to represent a structured cellular passive service element.

[0008] Based on the intent descriptor, determining protocol execution parameters and filtering information conforming to an underlying network protocol.

[0009] Based on the intent descriptor, the filtering information and the protocol execution parameters, determining an executable task message sequence.

[0010] In one embodiment, the determination of the protocol execution parameters conforming to the underlying network protocol based on the intent descriptor includes: determine, based on the intent descriptor, a protocol execution requirement parameter conforming to the underlying network protocol from a protocol mapping table; the protocol mapping table is used to represent a mapping relationship between an intent and an execution requirement parameter; in a case where the intent descriptor is in a missing state, generate a protocol missing parameter based on a preset strategy; determine the protocol execution requirement parameter and the protocol missing parameter as protocol execution parameters conforming to the underlying network protocol.

[0011] In one embodiment, the parsing of the service intent request obtains an intent descriptor corresponding to the service intent request, including: performing semantic extraction on the service intent request to obtain an intent descriptor corresponding to the service intent request; the intent descriptor includes an intent field and a parameter field; the parameter field includes at least one of a service area, a device type, a time range, an additional action, a result style, a tenant identifier, context prompt information, and a parsing confidence.

[0012] In one embodiment, based on the intent descriptor, determining filtering information conforming to the underlying network protocol, including: determine a target filtering template based on the device type and the tenant identifier; determine filtering information draft conforming to the underlying network protocol based on an initial filtering field and at least two parameter fields in the target filtering template; the filtering information draft includes a filtering component corresponding to each parameter field; determine filtering information conforming to the underlying network protocol based on the filtering information draft.

[0013] In one embodiment, based on the intent descriptor, the filtering information, and the protocol execution parameter, determining an executable task message sequence, including: in a case where the intent descriptor meets a disassembly condition, disassemble the intent descriptor to obtain a task list including multiple tasks; parameters of each task are determined based on the intent descriptor, the filtering information, and the protocol execution parameter; determine an executable task message sequence based on the task list; the disassembly condition includes at least one of intent field type composition, area scale exceeding a first preset threshold, device scale exceeding a second preset threshold, command risk level exceeding a third preset threshold, tenant authorization pruning, and time layering requirement.

[0014] In one embodiment, based on the task list, determining an executable task message sequence, including: mapping parameters of each task in the task list to protocol fields conforming to a protocol corresponding to the first network device; packaging the protocol fields of each task to obtain an interface message corresponding to each task; adding extension metadata to each interface message to obtain a task message corresponding to each task; determining all task messages corresponding to each task as an executable task message sequence.

[0015] In one embodiment, before the protocol missing parameters are generated based on the preset strategy, the method further includes: performing a verification operation based on the parameter field to determine a verification result corresponding to the service intent request; the verification operation includes at least one of a region legality verification operation, a device type access permission verification operation, and a time range strategy verification operation.

[0016] In one embodiment, the method further includes: sending the task message sequence to the first network device; the first network device is configured to forward the task message sequence to a passive Internet of Things device.

[0017] In one embodiment, the method further includes: receiving a task execution result corresponding to each task message; aggregating all task execution results based on the extension metadata corresponding to each task message to obtain original network data; converting the original network data to service semantic data based on the intent type in the extension metadata.

[0018] In one embodiment, the method further includes: in the case that there is an abnormal label in the original network data, determining an abnormal type corresponding to the abnormal label; performing abnormal processing on the original network data based on the abnormal type to obtain abnormal processing data.

[0019] In one embodiment, the method further includes: updating the initialization parameters corresponding to the SOF based on the original network data, the service semantic data, and the abnormal processing data.

[0020] In a second aspect, the embodiments of the present application provide a cellular passive service intent analysis method, applied to a first network device, including the following steps.

[0021] receiving an executable task message sequence sent by the SOF; obtaining a task execution result corresponding to the task message sequence; send the task execution result to the SOF; The task message sequence is a service intention request corresponding to the SOF; the service intention request is parsed to obtain an intention descriptor corresponding to the service intention request; the intention descriptor is used to represent a structured cellular passive service element; protocol execution parameters and filtering information conforming to a bottom-layer network protocol are determined based on the intention descriptor; and the task message sequence is determined based on the intention descriptor, the filtering information, and the protocol execution parameters.

[0022] In a third aspect, an embodiment of the present application provides a cellular passive service intention analysis apparatus, including the following modules.

[0023] A first obtaining module is configured to obtain a service intention request corresponding to a service server.

[0024] A parsing module is configured to parse the service intention request to obtain an intention descriptor corresponding to the service intention request; the intention descriptor is used to represent a structured cellular passive service element.

[0025] A first determining module is configured to determine protocol execution parameters and filtering information conforming to a bottom-layer network protocol based on the intention descriptor.

[0026] A second determining module is configured to determine an executable task message sequence based on the intention descriptor, the filtering information, and the protocol execution parameters.

[0027] In a fourth aspect, an embodiment of the present application provides a cellular passive service intention analysis apparatus, including the following modules.

[0028] A receiving module is configured to receive an executable task message sequence sent by an SOF.

[0029] A second obtaining module is configured to obtain a task execution result corresponding to the task message sequence.

[0030] A first sending module is configured to send the task execution result to the SOF.

[0031] The task message sequence is a service intention request corresponding to the SOF; the service intention request is parsed to obtain an intention descriptor corresponding to the service intention request; the intention descriptor is used to represent a structured cellular passive service element; protocol execution parameters and filtering information conforming to a bottom-layer network protocol are determined based on the intention descriptor; and the task message sequence is determined based on the intention descriptor, the filtering information, and the protocol execution parameters.

[0032] In a fifth aspect, an embodiment of the present application provides a network device, including a memory, a transceiver, and a processor. a memory for storing a computer program; a transceiver for transceiving data under control of the processor; and the processor for reading the computer program in the memory and performing the steps of the method for resolving a cellular passive service intent according to the first aspect or the second aspect.

[0033] In a sixth aspect, an embodiment of the present application provides a cellular passive system, comprising a service server and a network device, wherein: the service server is configured to send a service intent request to the network device; and the network device is configured to perform the steps of the method for resolving a cellular passive service intent according to the first aspect or the second aspect.

[0034] In a seventh aspect, an embodiment of the present application provides a non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the method for resolving a cellular passive service intent according to the first aspect or the second aspect.

[0035] In an eighth aspect, an embodiment of the present application provides a computer program product comprising a computer program, wherein the computer program, when executed by a processor, implements the steps of the method for resolving a cellular passive service intent according to the first aspect or the second aspect.

[0036] The method, device, network device and system for resolving a cellular passive service intent provided by the embodiments of the present application introduce a SOF between a core network and a service server, obtain an intent descriptor representing a structured cellular passive service element by resolving a service intent request corresponding to the service server, determine protocol execution parameters and filtering information conforming to a bottom-layer network protocol according to the intent descriptor, and determine a task message sequence executable by a network device in the core network according to the intent descriptor, the filtering information and the protocol execution parameters. In the embodiments of the present application, the SOF introduced between the core network and the service server can receive and understand a service intent request from the service server, automatically resolve, convert and arrange the service intent request into a task message sequence conforming to a bottom-layer network protocol and directly executable, build an automatic conversion process from a high-layer intent to a bottom-layer instruction, avoid the service server from understanding a bottom-layer protocol structure, significantly reduce system integration and development complexity, improve development efficiency and system automation level, and make deployment and application of a cellular passive service more flexible and convenient. BRIEF DESCRIPTION OF DRAWINGS

[0037] In order to more clearly illustrate the technical solutions of the present application or the prior art, the following will briefly introduce the drawings needed in the embodiments or prior art description. Obviously, the drawings in the following description are some embodiments of the present application, and those skilled in the art can also obtain other drawings according to these drawings without creative labor.

[0038] Figure 1 is a structural schematic diagram of a cellular passive system provided by an embodiment of the present application.

[0039] Figure 2 is one of flow schematic diagrams of a cellular passive service intent analysis method provided by an embodiment of the present application.

[0040] Figure 3 is another of flow schematic diagrams of a cellular passive service intent analysis method provided by an embodiment of the present application.

[0041] Figure 4 is one of structural schematic diagrams of a cellular passive service intent analysis apparatus provided by an embodiment of the present application.

[0042] Figure 5 is another of structural schematic diagrams of a cellular passive service intent analysis apparatus provided by an embodiment of the present application.

[0043] Figure 6 is a structural schematic diagram of a network device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0044] In order to make the objectives, technical solutions and advantages of the present application clearer, the technical solutions in the present application will be described clearly and completely below with reference to the drawings in the present application. Obviously, the described embodiments are some embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0045] In the prior art, Figure 4.2.2.1-1: Non-roaming AIoT System Architecture in 3GPP TS 23.369 standard defines a cellular passive system, and clearly defines the standard message format and parameter structure of the passive service request, such as the binary format of filtering information (Filtering Information), inventory, command and other operation processes. However, the cellular passive system in the prior art lacks analysis of service semantics, resulting in complex and error-prone service processing, which seriously limits the rapid integration and flexible application of cellular passive services. Therefore, an embodiment of the present application provides a cellular passive system which extends the cellular passive system defined in the prior art. Figure 1 is a structural schematic diagram of a cellular passive system provided by an embodiment of the present application, as shown in Figure 1 The cellular passive system includes a service server and a network device.

[0046] The service server is configured to send a service intent request to the network device. The network device is configured to perform the steps of the method for analyzing a passive service intent of a cell according to any one of the embodiments described below.

[0047] In particular, a service server, i.e., an AF (Application Function) or a third-party service server, is configured to initiate a passive service intent request, such as an Inventory query, positioning, or issuing a command, etc.

[0048] The network device comprises the following functional entities.

[0049] AIoT device (AIoT Device, passive Internet of Things device): without a continuous power supply, only temporarily activated and communicates with the network when receiving external energy excitation.

[0050] NG-RAN (Next Generation Radio Access Network): implements the wireless side Reader function, which is configured to send energy pulses to passive devices and receive device response information.

[0051] AIOTF (AIoT Function, AIoT functional entity): located in the core network, responsible for receiving passive service requests, generating instructions to the NG-RAN, and aggregating response results returned by multiple Readers.

[0052] NEF (Network Exposure Function): provides standardized API interfaces to third-party service servers (AFs) for exposing cellular passive service capabilities, and routes external requests to core network related functional entities.

[0053] ADM (AIoT Device Management): manages the regional configuration, Reader list, device permissions, and service policy information of passive devices, and is configured to support the core network to handle passive device related service processes.

[0054] AMF (Authentication Management Function): is a key control plane network element of the 5G core network, mainly responsible for terminal access authentication and mobility management.

[0055] SOF (Service Orchestration Function, business orchestration function entity) is between the core network and the business server, as a semantic bridge and protocol enhancement layer. After obtaining the business intent request corresponding to the business server, the SOF completes the following any embodiment corresponding to the passive cellular business intent analysis method. For example, business intent recognition, including inventory query, disable, read-write, positioning and trajectory analysis, etc.; target domain analysis, including determining the AioT Area ID set according to the area name, determining the EPC prefix or identifying information bit segment mask according to the device type; protocol parameter mapping and completion, including automatically generating Filtering Information, TimeWindow, Target Area and other fields in accordance with TS 23.369, and intelligently filling in missing parameters according to the policy; legality verification, including checking unauthorized access, disabled permissions, etc. based on ADM permissions / area policy; semantic-level task orchestration, including decomposing complex intent into executable passive protocol operation sequences (Inventory batch, Command issuance, trajectory reconstruction), and attaching auxiliary information (Approx. Device Count, Response Size, etc.). The output of the SOF is a set of structured and standardized passive business messages, which can be directly consumed by NEF or AIOTF, thereby greatly reducing the protocol complexity of the business server and supporting cross-area, multi-condition, and time-series business.

[0056] It should be noted that the SOF can be independently deployed, and can also be embedded in the NEF or AIOTF, and can also be deployed by the operator in the centralized AIOTF layer or MEC to support multi-operator or cross-domain expansion. The ADM (AIoT Data Management, AIOT data management) is used to provide area, device, permission and other policy data for the SOF.

[0057] It should be noted that the internal logic submodules of the SOF are shown in Table 1.

[0058] Table 1

[0059] On the basis of the above-mentioned cellular passive service, the embodiment of the application provides a cellular passive service intention analysis method, which is applied to a SOF arranged between a core network and a service server. The SOF can be arranged between the service server and the NEF as an independent SOF, serving as a multi-tenant semantic gateway. The SOF can also be embedded in the NEF to directly perform intention analysis inside the NEF and issue standard parameters. The SOF can also be embedded in the AIOTF to perform intention analysis inside the selected AIOTF after the NEF selects the AIOTF, which is suitable for light deployment or closed-loop control. The SOF can also be deployed in the edge cloud (MEC) and is suitable for low-latency local services.

[0060] After the SOF is deployed, the SOF is initialized. For example, a domain dictionary such as an inventory (Inventory), a command (Command), a disable (Disable), a read (Read), a write (Write), and a region identifier (Area ID) determined according to a region name is loaded in the SOF, and the domain dictionary includes a semantic dictionary and a domain ontology. A parameter dependency model, for example, a mapping model between an intention and a mandatory parameter or an optional parameter mapping table, can also be loaded. An identifier mapping library including asset coding, an EPC (Evolved Packet Core), an AIoT device permanent identifier format decomposition, and the like can also be loaded. Default parameter strategies including a default time window, a maximum read-write length, and a region callback can also be loaded. A permission or region policy interface can also be loaded to query an ADM or a local policy library to confirm legality.

[0061] In addition, a data source of the SOF can also be configured or synchronized, for example, a region semantic is configured according to an operator configuration or an AIoT data management to determine a region identifier, an NG-RAN, or a Reader mapping table. A device type classification can also be configured to determine an EPC prefix mask or an identifier type bit segment mapping. Dependency rules of protocol parameters required by different intentions can also be configured. Maximum reading, writing, security disabling strategies, and the like can also be configured. Time strategies including a maximum backtracking period of a trajectory query and a default sampling interval can also be configured.

[0062] Figure 2 is a flowchart of the cellular passive service intention analysis method provided by the embodiment of the application, as shown in Figure 2 The method includes the following steps 210 to 240.

[0063] Step 210, a service intention request corresponding to a service server is acquired.

[0064] Specifically, the SOF northbound interface can obtain a service intent request corresponding to the service server, and the service intent request is a high-level instruction representing service requirements. The service intent request can be sent by the service server, NEF or AIOTF, depending on the deployment location of the SOF.

[0065] The service intent request includes natural language text and / or structured supplementary fields. The structured supplementary fields can be structured API (Application Programming Interface) call instructions.

[0066] For example, when the service intent request is a trajectory type and high complexity natural language text, the service intent request can be "query 48-hour location trajectory of device type A in warehouse 1". The structured supplementary fields corresponding to the service intent request can be: "tenant_id": "retail-A", "intent_text": "query 48-hour location trajectory of device type A in warehouse 1", "time_range_hours": 48, "response_mode": "trajectory" }.

[0067] Among them, tenant_id represents the tenant identifier, that is, the unique identifier of the business tenant or customer domain, which is used for permission control, area mapping, device identification space limitation and default parameter selection. This field is a non-3GPP standard field and is only an extension field of the SOF northbound interface. intent_text represents the intent text (i.e. natural language text). time_range_hours represents the time range (hours). response_mode represents the response mode.

[0068] For another example, when the service intent request is a conditional disabling type and includes a composite operation natural language text, the service intent request can be "disable type A shelf label in warehouse 1 that has not responded in the last 7 days". The structured supplementary fields corresponding to the service intent request can be: "tenant_id": "retail-A", "intent_text": "disable type A shelf label in warehouse 1 that has not responded in the last 7 days", "lookback_days": 7, "action": "disable" }.

[0069] Wherein, lookback_days represents lookback (days). Action represents action.

[0070] For example, when the business intent request is a batch read-write confirmation type of natural language text, the business intent request can be "write threshold -20℃ to the temperature tag of cold chain warehouse area B and read back to confirm". The structured supplementary field corresponding to the business intent request can be: "tenant_id": " coldchain-X ", "intent_text": "write threshold -20 to the temperature tag of warehouse area B and read back", " write_payload": {"temp_threshold": -20}, "confirm_read": true }。

[0071] Wherein, write_payload represents write data packet. Confirm_read represents confirmation of reading.

[0072] Step 220, parsing the business intent request to obtain an intent descriptor corresponding to the business intent request; the intent descriptor is used to represent a structured cellular passive business element.

[0073] Specifically, after obtaining the business intent request, the business intent request is subjected to semantic analysis, and the unstructured and / or structured business intent request is converted into an intent descriptor representing different cellular passive business elements.

[0074] Step 230, determining protocol execution parameters and filtering information conforming to a bottom-layer network protocol based on the intent descriptor.

[0075] Specifically, the bottom-layer network protocol can be a 3GPP TS 23.369 protocol. After converting the intent descriptor, the SOF automatically converts the intent descriptor into protocol execution parameters conforming to the bottom-layer network protocol required for executing the business intent request, and automatically converts the intent descriptor into filtering information conforming to the bottom-layer network protocol according to the filtering template library. The protocol execution parameters are used to guide the specific operation of other network devices except the SOF. The filtering information is used to accurately screen out target passive Internet of Things devices conforming to specific conditions.

[0076] Step 240, determining an executable task message sequence based on the intent descriptor, the filtering information, and the protocol execution parameters.

[0077] Specifically, after determining the intent descriptor, the filtering information and the protocol execution parameter, the parameters are encapsulated into a task message sequence including at least one standard and executable task message, to be sent to other network devices for execution.

[0078] The cellular passive service intention analysis method provided in the embodiments of the present application introduces a SOF between the core network and the service server, obtains an intent descriptor representing a structured cellular passive service element by analyzing a service intention request corresponding to the service server, determines protocol execution parameters and filtering information conforming to a bottom-layer network protocol according to the intent descriptor, and determines a task message sequence executable by a network device in the core network according to the intent descriptor, the filtering information and the protocol execution parameter. In the embodiments of the present application, the SOF introduced between the core network and the service server can receive and understand a service intention request from the service server, and automatically analyze, convert and arrange the service intention request into a task message sequence conforming to a bottom-layer network protocol and directly executable, thereby constructing an automatic conversion process from a high-layer intention to a bottom-layer instruction, avoiding the service server from understanding a bottom-layer protocol structure, significantly reducing system integration and development complexity, improving development efficiency and system automation level, and making the deployment and application of the cellular passive service more flexible and convenient.

[0079] In one embodiment, the analyzing the service intention request to obtain an intent descriptor corresponding to the service intention request comprises: performing semantic extraction on the service intention request to obtain an intent descriptor corresponding to the service intention request; the intent descriptor includes an intent field and a parameter field; the parameter field includes at least one of a service area, a device type, a time range, an additional action, a result style, a tenant identifier, context prompt information and an analysis confidence.

[0080] Specifically, after obtaining the service intention request, the SOF performs a semantic extraction operation such as natural language processing or keyword matching on the service intention request to obtain a structured intent descriptor, which includes all or part of the fields in Table 2.

[0081] Table 2

[0082] For example, the service intention request can be "query 48-hour location trajectory of device type A in warehouse 1", and the intent descriptor obtained after performing semantic extraction on the service intention request is: "intent": "TrajectoryQuery", "target_area_label": "warehouse 1", "device_class": "TypeA", "time_range_hours": 48, "result_mode": "trajectory" }。

[0083] In the embodiments of the present application, the structured intent descriptor including the intent field and the parameter field is obtained through semantic extraction, so that the SOF can accurately capture the business intent. The structured parsing improves the richness and machine readability of the intent expression, supports mixed processing of natural language and structured input, and significantly improves the accuracy and efficiency of intent parsing.

[0084] In one embodiment, the protocol execution parameter conforming to the underlying network protocol is determined based on the intent descriptor, including: determining a protocol execution requirement parameter conforming to the underlying network protocol from a protocol mapping table based on the intent descriptor; the protocol mapping table is used to represent the mapping relationship between the intent and the execution requirement parameter; generating a protocol missing parameter based on a preset strategy in the case that the intent descriptor is in a missing state; determining the protocol execution requirement parameter and the protocol missing parameter as the protocol execution parameter conforming to the underlying network protocol.

[0085] Specifically, after determining the intent descriptor, the protocol mapping table loaded during initialization is queried, and the corresponding protocol execution requirement parameter is determined according to the intent field. The protocol execution requirement parameter includes a protocol action sequence and a required generation parameter. The protocol execution requirement parameters corresponding to different intent fields are shown in Table 3.

[0086] Table 3

[0087] It should be noted that in Table 3, the remark field is used to represent the characteristics of the intent field during execution. Among them, the cross-time slice result aggregation indicates that the results need to be accumulated across multiple time slices; the authorized pruning and sliced batch processing indicates that the target set needs to be reduced according to the tenant permission before execution and is issued in batches; the chunked read-write and spot-check read-back indicates that the large data writing needs to be chunked according to the offset and read back for verification.

[0088] It should be noted that the protocol action sequence in Table 3 depends on the intent field in the intent descriptor, and the required generation parameter in Table 3 depends on the other fields in the intent descriptor except the intent field, which is shown in Table 4.

[0089] Table 4

[0090] It can be understood that the protocol mapping table is a combination of Table 3 and Table 4.

[0091] For example, after determining that the service intent request is an intent descriptor of "querying the 48-hour location trajectory of the device type A in warehouse 1", the parameter derivation process of the protocol execution requirement parameter corresponding to the intent descriptor can be: (1) According to target_area_label = "warehouse 1", AreaSet = [Area-01, Area-02] can be mapped.

[0092] (2) According to device_class = "Type A", FilteringInfo = EPC prefix bitstring is generated.

[0093] (3) According to time_range_hours = 48, TimeWindow = 48 hours is set.

[0094] (4) If there is a data gap in the target area, incremental inventory can be started for periodic scanning.

[0095] (5) Aggregate Reader ID and timestamp to construct trajectory records for business system display.

[0096] After mapping the protocol execution requirement parameter, if the intent descriptor corresponding to the service intent request has missing or incomplete parameters, the SOF can determine whether there are corresponding parameters in the preset strategy in the intent descriptor. If not, the corresponding protocol missing parameters are generated to realize intelligent completion of the parameters, so as to obtain complete protocol execution parameters conforming to the underlying network protocol according to the protocol execution requirement parameters and the protocol missing parameters, so as to ensure the integrity, performance optimization and execution correctness of subsequent protocol execution parameter delivery. If all parameters in the prediction strategy exist, the protocol missing parameters do not need to be generated, and the protocol execution requirement parameter can be determined as the protocol execution parameter.

[0097] It should be noted that the preset strategy includes the following strategies and parameters.

[0098] (1) Sampling interval completion strategy: if the sampling interval (i.e., sampling_interval) is missing in the intent descriptor, the SOF can complete it according to the tenant default strategy. The sampling interval includes a trajectory query sampling interval and a state reading sampling interval. For example, the trajectory query sampling interval is 30 minutes by default, and the state reading sampling interval is 5 minutes by default.

[0099] (2) Time window completion strategy: If the inventory scanning time window is missing in the intent descriptor, SOF can estimate it according to the target area size and device density. For example, for a small area, the time window is set to 300 ms / Reader by default; for a medium or large area, the time window can be dynamically adjusted in the range of 500 ms / Reader to 1000 ms / Reader.

[0100] (3) Area semantic mapping completion strategy: The target area label (i.e., target_area_label) in the intent descriptor is mapped to the area identifier (i.e., area_ids) defined in the cellular passive system.

[0101] (4) Maximum device batch completion strategy: If the maximum device batch is missing in the intent descriptor, it can be completed according to the tenant policy, device capability or network restriction (i.e., max_device_batch). For example, the maximum device batch can be 5000 tags per batch.

[0102] (5) Context and default policy completion strategy: If the context hint information (i.e., context_hints) is missing in the intent descriptor, the execution policy can be automatically completed according to the tenant configuration, such as whether to start read-after-write confirmation, default command waiting time, etc.

[0103] For example, the protocol missing parameters determined according to the preset strategy can be { "sampling_interval_min": 30, "time_window_ms": 300, "area_ids": ["Area-01", "Area-02", "Area-05"], "max_device_batch": 5000 }.

[0104] In the embodiments of the present application, through the preset strategy, intelligent completion is performed when parameters are missing, ensuring the integrity and compliance of the protocol execution parameters, avoiding execution failure due to missing parameters, improving the robustness and automation level of the cellular passive system, reducing manual intervention, and reducing operation and maintenance costs. At the same time, the parameter completion logic of the policy area can meet the differentiated needs of multiple tenants.

[0105] In one embodiment, before generating the protocol missing parameters based on the preset strategy, the method further comprises: perform a verification operation based on the parameter field to determine a verification result corresponding to the service intent request; the verification operation includes at least one of a region legality verification operation, a device type access permission verification operation, and a time range policy verification operation.

[0106] Specifically, after determining the protocol execution requirement parameter, the parameter field in the intent descriptor also needs to be authorized and policy verified to ensure that the service intent request complies with tenant permissions, device access policies, and network operation regulations to prevent unauthorized operations.

[0107] The verification operation includes at least one of the following.

[0108] (1) Legality verification operation: check whether the target area (i.e., target_area) in the parameter field belongs to the set of regions authorized for access by the tenant identifier (i.e., tenant_id); if the region is not legal, the cellular passive system rejects the request and returns a no permission prompt.

[0109] (2) Device type access permission verification operation: check whether the device type (i.e., device_class) in the parameter field is allowed to perform the current intent operation. For example, if some device types are only allowed to read the state, not to locate or query the trajectory, if the authorization is exceeded, the cellular passive system rejects execution and returns a restriction prompt.

[0110] (3) Time range policy verification operation: check whether the time range (i.e., time_range) in the parameter field exceeds the maximum historical rollback time limit (e.g., 72 hours) configured by the operator for the tenant; if the limit is exceeded, the cellular passive system can automatically reduce to the allowed range or prompt the service server to adjust the request. In addition, the authorization pruning result is written back to the intent descriptor or the execution plan for subsequent parameter completion.

[0111] For example, taking the authorization verification of the intent descriptor corresponding to the service intent request "query the trajectory of TypeA devices in warehouse 1 for the last 48 hours" as an example, the specific verification steps include: target_area = warehouse 1, verify whether the warehouse 1 belongs to the authorized region of tenant retail-A; device_class = TypeA, verify whether trajectory query is supported, time_range_hours = 48, verify whether it exceeds the 72-hour trajectory query limit of tenant retail-A.

[0112] In the embodiments of the present application, by verifying the permissions and compliance of the service intent request in real time, unauthorized operations are prevented, and security risks are reduced. Through the device verification operation, it is ensured that the service intent is executed within a legal range, and resource abuse is avoided.

[0113] In one embodiment, based on the intent descriptor, determine the filtering information conforming to the underlying network protocol, comprising: Based on the device type and the tenant identifier, determine the target filtering template; Based on the initial filtering field and at least two parameter fields in the target filtering template, determine the filtering information draft conforming to the underlying network protocol; the filtering information draft includes filtering components corresponding to each of the parameter fields; Based on the filtering information draft, determine the filtering information conforming to the underlying network protocol.

[0114] Specifically, after determining the intent descriptor, according to the device type and the tenant identifier in the parameter field, find the target filtering template corresponding to the device type and the tenant identifier from the filtering template library. The initial filtering field in the target filtering template includes but is not limited to: EPC prefix, bit string pattern, offset and length, and allowed operation range.

[0115] The filtering templates in the filtering template library are shown in Table 5, and the filtering template library can also include other filtering templates in addition to Table 5. The target filtering template can be any filtering template in the filtering template library that meets the conditions. If a matching target filtering template is found, the SOF can determine the default filtering template as the target filtering template, or prompt the business server to supplement the device classification information, etc.

[0116] Table 5

[0117] After determining the target filtering template, on the basis of the initial filtering field, according to the complexity of the business intent request, combine the intent descriptor to automatically synthesize multiple-field filtering components. For example, according to the device type in the intent descriptor, an identification information component can be generated, according to the tenant identifier in the intent descriptor, a third party identifier component can be generated, and according to the operator domain name in the intent descriptor, a PLMN ID / NID component can be generated.

[0118] It should be noted that the number of filtering components can be at least one. When including at least two filtering components, they can be combined in list form, and there is a logical AND relationship between multiple filtering components, that is, all conditions corresponding to all filtering components need to be met. For example, the multiple-field filtering components corresponding to the business intent request are as follows: [ { "component": "Identification Information", "offset": 0, "bitstring": "1000100010100000", "length": 16 }, { "component": "Third Party Identifier", "bitstring": "110101", "length": 6 } ]。

[0119] After generating the filtering component, the filtering component is secured and differentiated to obtain filtering information conforming to the underlying network protocol and directly usable for protocol encapsulation. For example, the SOF trims the EPC prefix field according to the tenant policy, prohibits cross-tenant access, and realizes isolation between different tenants. For another example, different filtering templates are supported for different tenants for the same device type, realizing business isolation and function trimming and differentiating different tenants. For another example, the SOF supports disabling track and write permission operations for a certain type of device, realizing permission verification.

[0120] In the embodiment of the application, template matching is adopted to avoid manual configuration, improve construction speed, ensure accurate matching of business intent through multi-field joint construction, prevent unauthorized access through policy application, and comply with operator regulations.

[0121] In one embodiment, based on the intent descriptor, the filtering information and the protocol execution parameter, a task message sequence executable is determined, comprising: In the case where the intent descriptor meets a disassembly condition, the intent descriptor is disassembled to obtain a task list comprising a plurality of tasks; parameters of each task are determined based on the intent descriptor, the filtering information and the protocol execution parameter; Based on the task list, a task message sequence executable is determined; The disassembly condition comprises at least one of intent field type composition, area scale exceeding a first preset threshold, device scale exceeding a second preset threshold, command risk level exceeding a third preset threshold, tenant authorization trimming and time layering requirement.

[0122] Specifically, a high-level service intent request cannot be completed by a single 3GPP AIoT task message, and must be disassembled into multiple executable tasks, each of which corresponds to one or more Nnef_AIoT_ or Naiotf_AIoT_ calls. Therefore, after determining the intent descriptor, it is determined whether the disassembly condition is met. The disassembly condition is at least one of the following.

[0123] (1) Operation composite condition: the intent type is composite, for example, the intent type contains trajectory query, condition filtering and disable at the same time, and needs to be executed in multiple stages, then the disassembly is triggered.

[0124] (2) Area or device scale overrun condition: the area scale exceeds a first preset threshold, and the device scale exceeds a second preset threshold, for example, the target area covers multiple AIoT areas or multiple NG-RAN needs to be fragmented, and for example, there is a large amount of write or disable operation, which needs to be executed in batches, then the disassembly is triggered.

[0125] (3) Time layering requirement condition: mixed processing of historical semantics and current collection semantics, historical trajectory can only use archived Reader reports, cannot be backfilled with current inventory to supplement history, and gaps are only marked, while current state needs to be collected through real-time inventory operation, therefore, trajectory query needs to combine historical archives and current snapshots, then the disassembly is triggered.

[0126] (4) Command risk level condition: high command risk level and tenant authorization pruning, for example, permanent disable, write user area needs to be executed in small batches, and for example, the upstream request area exceeds authorization, which can automatically reduce executable tasks.

[0127] If the intent descriptor meets any of the above disassembly conditions, the intent descriptor is disassembled into a task list (TaskList) including multiple tasks, each task in the task list is bound to a task identifier (task_id), an operation type, a parameter set, and an optional dependency, etc. The operation type can include inventory (Inventory), command write (Command-Write), command disable (Command-Disable), and snapshot (Snapshot) and the like. The parameter set includes area fragmentation, filtering information, and auxiliary resource parameters, which can include intent descriptors and protocol execution parameters. The optional dependency can be executed after the pre-task is successful. After generating the task list, the task list is encapsulated to obtain an executable task message sequence.

[0128] For example, a historical trajectory query type service intent request is "query warehouse 1 TypeA device trajectory in the last 48 hours", then the corresponding intent descriptor disassembly includes the following tasks.

[0129] (1) HistFetch: Read Reader reports from AIOTF / operator history database ADM for the past 48h (if any).

[0130] (2) GapMark: Mark the missing time period in the history period; no backtracking.

[0131] (3) Snapshot Inventory: If the business side requests "with the latest current position", the SOF generates a single Inventory request.

[0132] (4) Result aggregation: Perform HistFetch, Snapshot Inventory, and GapMark to determine the trajectory result output.

[0133] It should be noted that if the business server does not require "current snapshot", the task of current snapshot can be deleted.

[0134] For example, the conditional disable type of business intent request is "disable type A tags in warehouse 1 that have not responded in the past 7 days", and the corresponding intent descriptor after disassembly includes the following tasks.

[0135] (1) HistFetch and FilterUnresponsive: Identify the list of devices that have not reported for 7 days.

[0136] (2) Confirm alive (Inventory confirmation, optional): Perform inventory on the filtered devices or areas to reduce false negatives.

[0137] (3) Batch disable (Command-PermanentDisable): Batch issue disable commands according to max_device_batch.

[0138] (4) Result aggregation and reporting: Aggregate success, failure, or non-response list.

[0139] It should be noted that task disassembly only exists within the SOF, and the task message sequence output by the SOF finally includes multiple Nnef_ or Naiotf_ calls.

[0140] In the embodiments of the application, the SOF can disassemble the intent into multiple tasks to avoid excessive word operation load, improve the ability of the cellular passive system to handle complex business, reduce the risk of network congestion through batch execution, and at the same time, the disassembly condition ensures that the task granularity is reasonable and optimizes resource utilization.

[0141] In one embodiment, based on the task list, determining an executable task message sequence comprises: mapping parameters of each task in the task list to protocol fields conforming to a protocol corresponding to the first network device; packaging the protocol fields of each task to obtain an interface message corresponding to each task; adding extension metadata to each interface message to obtain a task message corresponding to each task; determining all task messages corresponding to each task as an executable task message sequence.

[0142] Specifically, after determining the task list, the used interface in the first network device, including the NEF or the AIOTF, which interfaces with the SOF can be determined according to the actual deployment position of the SOF. The correspondence between the actual deployment position of the SOF and the used interface is shown in Table 6.

[0143] Table 6

[0144] After determining the used interface corresponding to the first network device, the parameters of each task are mapped to the protocol fields corresponding to the used interface by using Table 7.

[0145] Table 7

[0146] After mapping the protocol fields, the standardized protocol fields corresponding to each task are packaged into complete interface messages according to the interface specification defined in the 3GPP TS 23.369 standard, and the extension metadata shown in Table 8 is added to each interface message to obtain the task message corresponding to each task. By merging all task messages, an executable task message sequence can be obtained.

[0147] Table 8

[0148] In the embodiments of the present application, by mapping the task parameters to the protocol fields and adding the extension metadata, it is ensured that the task message conforms to the network device interface specification, the standardization degree of the task message generation is improved, the traceability and compatibility of the task message are enhanced, and the interface adaptation cost is reduced.

[0149] In one embodiment, the method further comprises: sending the task message sequence to the first network device; the first network device is used to forward the task message sequence to the passive Internet of Things device.

[0150] Specifically, as can be seen from Table 6, the actual deployment position of the SOF is different, and the first network device is different. For example, when the SOF is independently deployed or embedded in the NEF, the first network device is the NEF, the SOF can send the task message sequence to the NEF, and the NEF forwards the task message sequence to the selected AIOTF after verifying the legality of the service server. When the SOF is embedded in the AIOTF or the SOF is located in the operator, the first network device is the AIOTF, the SOF can send the task message sequence to the AIOTF, and the AIOTF can send the task message sequence to the NG-RAN or the passive Internet of Things device.

[0151] It should be noted that in the embodiments of the present application, the standard processing path of the cellular passive service intent request is unified as: service server, SOF, NEF, AIOTF, NG-RAN or RAN Reader and AIoT Device. The different deployment positions of the SOF only affect whether the intermediate nodes are folded, and do not change the logical flow of the above standard processing path.

[0152] In one embodiment, the method further comprises: receiving a task execution result corresponding to each of the task messages; aggregating all the task execution results based on the extension metadata corresponding to each of the task messages to obtain original network data; converting the original network data into service semantic data based on the intent type in the extension metadata.

[0153] Specifically, a task execution result corresponding to each task message is received, and the task execution result includes an AIoT device response and an AIOTF primary aggregation result. According to the extension metadata in each task message, multiple task execution results of the same service intent request are aggregated to obtain original network data. Specifically, the following steps are included.

[0154] (1) Establish a mapping table: the SOF pre-registers a mapping table when sending the task message sequence, and the mapping table records the following association between the intent and the transaction: The association between (intent_id, task_id) and (NEF Transaction ID, AIOTF Correlation ID, Target Areas, submission time).

[0155] The SOF supports multiple AIOTF concurrency; N task_ids under the same intent_id are possible. The same intent_id can cross multiple NEF Transactions or multiple AIOTF Correlations, and the SOF aggregates the intent_id as the top-level dimension in the subsequent aggregation.

[0156] (2) Callback access: SOF listens to the configured Notify callback (NEF or AIOTF). After receiving the task execution result, parse the Transaction or Correlation field, check the mapping, and then backfill to the corresponding task record.

[0157] (3) Multi-batch merging: If the task is sent in batches (disabled, written), SOF will integrate the success, failure or non-response status across batches; if the same intent_id contains multiple regional tasks, automatically merge the device set and mark the source batch.

[0158] (4) Gap and exception marking: If there is no reply timeout, mark "network no result" instead of "device missing"; If the task is rejected by the policy, mark "not executed (authorization rejection)"; If there is no device matching in the RAN report, mark "empty result".

[0159] (5) Audit or idempotent embedding: Use "intent_hash" to detect duplicate intents; use "policy_snapshot_id" to record the policy version at the time of execution to enable subsequent audits.

[0160] After that, SOF converts the aggregated raw network data from multiple tasks into business-friendly, high-semantic-density business semantic data according to the intent type, and retains uncertainty information to avoid misjudgment.

[0161] For example, when the intent type is a trajectory intent (TrajectoryQuery), based on the Reader time series returned by the history library, or the Reader time series and the current snapshot result, add a "gap: true" field to the historical monitoring section, map the Reader ID to the area coordinates or logical area name; "Area stay time" "crossing path" "last appearance time" can be output. The converted business semantic data is: "intent_id": "INT-TRJ-8791", "device_class": "TypeA", "time_range": {"start":"2025-07-15T00:00Z","end":"2025-07-17T00:00Z"}, "trajectory": [ {"area": "Area-01", "start": "2025-07-15T00:00Z", "end": "2025-07-15T08:10Z"}, {"gap": true, "start": "2025-07-15T08:10Z", "end": "2025-07-15T12:00Z"}, {"area": "Area-02", "start": "2025-07-15T12:00Z", "end": "2025-07-16T19:05Z"}, {"current_snapshot": true, "area": "Area-05", "time": "2025-07-17T00:00Z"} ] } For example, when the intent type is a condition disable type (DisableByCondition), the total number of candidate devices, the number of execution batches, success or failure breakdown, and the policy rejection list can be converted. The converted business semantic data is: "intent_id": "INT-DSB-9921", "total_candidates": 5234, "executed": 5000, "pending": 234, "result_breakdown": { "success": 4970, "already_disabled": 20, "auth_denied": 5, "not_found": 5, "timeout": 5 } } In one embodiment, the method further comprises: In the case of an abnormal label in the original network data, determining the abnormal type corresponding to the abnormal label; Based on the abnormal type, performing abnormal processing on the original network data to obtain abnormal processing data.

[0162] Specifically, in the embodiments of the present application, the SOF can classify, retry, or suspend operations such as network exceptions according to the intended semantics and policy levels, rather than relying solely on underlying error codes. The exception handling includes the following policies.

[0163] (1) Automatic retry policy: If the inventory is empty, but the regional wireless coverage is normal, the retry can be configured for N times. Write-type operations can automatically retry for some failed devices, and limit the number of retries or the total time length.

[0164] (2) High-risk command protection: Permanent disable: If the first batch failure rate exceeds the threshold, suspend the subsequent batch and require manual confirmation; Write user area: If the read-back verification failure rate exceeds the threshold, automatically downgrade to read-only mode.

[0165] (3) Authorization pruning degradation: If the NEF rejects some areas, the SOF can automatically delete non-compliant shards, continue to execute the remaining legal areas, and mark "partial execution" in the results.

[0166] (4) Error classification model: network unreachable, non-response, authorization rejection, data format error or verification failure; error classification is used for business alarm and automatic policy iteration.

[0167] In one embodiment, the method further comprises: Based on the original network data, the business semantic data and the exception handling data, updating the initialization parameters corresponding to the SOF.

[0168] Specifically, after aggregating, semantic converting and exception handling the task execution results, the initialization parameters such as the preset policy and the filter template library maintained internally are dynamically updated according to the original network data, the business semantic data and the exception handling data obtained by processing, to adapt to the adaptive closed-loop optimization. The specific updating operations include the following.

[0169] (1) Filtering hit rate learning: compare the estimated device quantity and the actual hit device number, hit rate = actual response times / estimated device quantity, i.e. hit_ratio = actual_responded / approx_device_count, automatically suggest narrowing or widening the EPC prefix / bit segment.

[0170] (2) TimeWindow optimization: statistics RAN actual completion time length; if long-term timeout, increase the default scanning window; if redundant, decrease to save resources.

[0171] (3) Batch size tuning: record success rate per batch and network congestion, dynamically adjust the maximum device batch size.

[0172] (4) Gap analysis: count the number of repeated gap segments and suggest the operator to supplement Reader coverage or optimize the sampling strategy.

[0173] (5) Policy version iteration: generate a new policy_snapshot_id_next after updating the policy; in combination with the fields in the encapsulated task message sequence, realize versioned audit. The new policy is loaded during SOF initialization or hot-updated in the running state.

[0174] The embodiment of the application provides a cellular passive service intention analysis method, which is applied to a first network device, Figure 3 is a second flowchart of a cellular passive service intention analysis method provided by the embodiment of the application, as shown in the figure, the method comprises the following steps 310 to 330. Figure 3

[0175] Step 310, receiving an executable task message sequence sent by a SOF.

[0176] Step 320, obtaining a task execution result corresponding to the task message sequence.

[0177] Step 330, sending the task execution result to the SOF.

[0178] The task message sequence is a service intention request of a service server obtained by the SOF; the service intention request is analyzed to obtain an intention descriptor corresponding to the service intention request; the intention descriptor is used to represent a structured cellular passive service element; based on the intention descriptor, protocol execution parameters and filtering information conforming to a bottom-layer network protocol are determined; the intention descriptor, the filtering information and the protocol execution parameters are determined based on the intention descriptor.

[0179] For example, when the SOF is independently deployed or the SOF is embedded in the NEF, the first network device is the NEF, and after the NEF receives the executable task message sequence sent by the SOF, the following operations are performed.

[0180] (1) AF request authorization: verify the representation of the AF, regional access permission, and allowed operations (Inventory / Read / Disable, etc.).

[0181] (2) Target Area analysis: map the Area ID submitted by the SOF to the operator configuration; support for multiple AIOTFs.

[0182] ​(3) AIOTF selection (see TS 23.369 Architecture Principles): Select 1 to n AIOTFs according to target area, AIOTF service range, and operation policy.

[0183] (4) Forwarding request: Construct "Naiotf_AIoT_Inventory" or "Naiotf_AIoT_Command"; carry AF identity, Target Area, filtering, and assistance information (e.g., estimated device number and message size indication).

[0184] (5) Transaction identity allocation and notification subscription: NEF establishes a transaction context for the AF and subscribes to AIOTF notifications.

[0185] By way of example, when the SOF is embedded in the AIOTF or the SOF is located inside the operator, the first network device is the AIOTF. After the AIOTF receives the executable task message sequence sent by the SOF, the following operations are performed.

[0186] (1) Message legality check (field completeness, format, and authorization data synchronization).

[0187] (2) AF authorization review (if dual-layer authorization is enabled; ADM AF authorization data can be checked).

[0188] (3) NG-RAN or RAN Reader selection: According to the Target Area and historical Reader reports; the coverage can be narrowed in combination with the last position cache.

[0189] (4) Assistance Info generation (according to TS 23.369 standard): Including approximate device number, expected response message size, request type (Inventory or Command), and RAN aggregation time interval.

[0190] (5) Correlation ID allocation (per AF transaction or per batch operation).

[0191] (6) Issue Inventory or Command Request to NG-RAN.

[0192] After the first network device has accepted and issued the inventory or command request, the NG-RAN executes the task message sequence according to the 3GPP standard to realize cellular passive access. Specifically, the following operations are included.

[0193] (1) Area Activation: Select RAN Reader to activate by uplink Target Area information (Area clipping is derived from SOF authorization or mapping result).

[0194] (2) Resource Hint Application: Configure scanning period, power and collision avoidance policy using "Approximate number of AIoT Devices", "time_window_ms", request type (inventory or command) and other auxiliary information.

[0195] (3) AIoT Identification Information Carried in Paging or Read / Write: Map Filtering Information to paging / read / write command filtering conditions to make RAN Reader interact with target devices only, improving energy efficiency. The AIoT identification information is derived from Filtering Information.

[0196] (4) Local Aggregation: NG-RAN can collect device responses in batches within a local window and report them again to reduce signaling storm.

[0197] In the embodiments of the present application, the existing RAN protocol is not changed, the SOF generates more accurate parameters, the RAN execution efficiency is improved, and the invalid paging is reduced.

[0198] Then, the AIoT device response is acquired, and AIOTF primary aggregation is implemented, specifically including the following steps.

[0199] (1) Device Matching Return: Passive Internet of Things devices that meet the filtering information respond to the paging after collecting sufficient energy and return their identification or command execution status.

[0200] (2) Command Scenario: The results of write, read back, disable and other operations (success or failure status code, user area data) are uploaded with AIoT NAS message. If the target device does not support read or write, it may return a rejection state; the SOF needs to identify when aggregating the results.

[0201] (3) RAN→AIOTF: NG-RAN encapsulates multiple AIoT device responses in inventory report or command response, carries Reader ID, Correlation ID and other information, and reports AIOTF (indirectly through AMF or directly).

[0202] (4) AIOTF Primary Aggregation: AIOTF can combine responses from different RAN Readers according to Correlation ID, and attach Reader location information or RAN AIoT Device NGAP ID if necessary, to prepare for further uploading to NEF or AF.

[0203] The cellular passive service intention parsing device provided in the application is described below, and the cellular passive service intention parsing device described below can be referred to the cellular passive service intention parsing method described above.

[0204] The application provides a cellular passive service intention parsing device, Figure 4 is one of the structural schematic diagrams of the cellular passive service intention parsing device provided in the application, as Figure 4 shown, the cellular passive service intention parsing device 400 includes a first acquisition module 410, a parsing module 420, a first determination module 430 and a second determination module 440.

[0205] The first acquisition module 410 is configured to acquire a service intention request corresponding to a service server.

[0206] The parsing module 420 is configured to parse the service intention request to obtain an intention descriptor corresponding to the service intention request; the intention descriptor is used to represent a structured cellular passive service element.

[0207] The first determination module 430 is configured to determine protocol execution parameters and filtering information conforming to a bottom-layer network protocol based on the intention descriptor.

[0208] The second determination module 440 is configured to determine an executable task message sequence based on the intention descriptor, the filtering information and the protocol execution parameters.

[0209] The cellular passive service intention parsing device provided in the application introduces a SOF between a core network and a service server, parses a service intention request corresponding to the service server to obtain an intention descriptor representing a structured cellular passive service element, respectively determines protocol execution parameters and filtering information conforming to a bottom-layer network protocol according to the intention descriptor, and determines a task message sequence executable by a network device in the core network according to the intention descriptor, the filtering information and the protocol execution parameters. In the application, the SOF introduced between the core network and the service server can receive and understand the service intention request from the service server, automatically parses, converts and arranges the service intention request into a task message sequence conforming to the bottom-layer network protocol and directly executable, constructs an automatic conversion process from a high-layer intention to a bottom-layer instruction, avoids the service server from understanding the bottom-layer protocol structure, significantly reduces the system integration and development complexity, improves the development efficiency and the system automation level, and makes the deployment and application of the cellular passive service more flexible and convenient.

[0210] Optionally, the parsing module 420 is specifically configured to: perform semantic extraction on the service intention request to obtain an intention descriptor corresponding to the service intention request; the intention descriptor comprises an intention field and a parameter field; the parameter field comprises at least one of a service area, a device type, a time range, an additional action, a result style, a tenant identifier, context prompt information, and a parsing confidence.

[0211] Optionally, the first determining module 430 is specifically configured to: determine, based on the intention descriptor, a protocol execution requirement parameter conforming to a bottom-layer network protocol from a protocol mapping table; the protocol mapping table is used to represent a mapping relationship between an intention and an execution requirement parameter; in a case where the intention descriptor is in a missing state, generate a protocol missing parameter based on a preset strategy; determine the protocol execution requirement parameter and the protocol missing parameter as protocol execution parameters conforming to the bottom-layer network protocol.

[0212] Optionally, the first determining module 430 is specifically configured to: determine a target filtering template based on the device type and the tenant identifier; determine a filtering information draft conforming to the bottom-layer network protocol based on an initial filtering field and at least two parameter fields in the target filtering template; the filtering information draft comprises filtering components corresponding to the parameter fields; determine filtering information conforming to the bottom-layer network protocol based on the filtering information draft.

[0213] Optionally, the second determining module 440 is specifically configured to: in a case where the intention descriptor meets a disassembling condition, disassemble the intention descriptor to obtain a task list comprising a plurality of tasks; parameters of the tasks are determined based on the intention descriptor, the filtering information, and the protocol execution parameter; determine an executable task message sequence based on the task list; the disassembling condition comprises at least one of an intention field type composition, an area scale exceeding a first preset threshold, a device scale exceeding a second preset threshold, a command risk level exceeding a third preset threshold, tenant authorization pruning, and time layering requirements.

[0214] Optionally, the second determining module 440 is specifically configured to: map the parameters of the tasks in the task list to protocol fields conforming to a protocol corresponding to a first network device; encapsulate the protocol fields of the tasks to obtain interface messages corresponding to the tasks; add extension metadata to the interface messages to obtain task messages corresponding to the tasks; Determine all task messages corresponding to each of the tasks as an executable task message sequence.

[0215] Optionally, the cellular passive service intent resolution device 400 further includes a verification module, which is specifically used for: Perform a verification operation based on the parameter field to determine a verification result corresponding to the service intent request; the verification operation includes at least one of a region legality verification operation, a device type access permission verification operation, and a time range policy verification operation.

[0216] Optionally, the cellular passive service intent resolution device 400 further includes a second sending module, which is specifically used for: Send the task message sequence to a first network device; the first network device is used to forward the task message sequence to a passive Internet of Things device.

[0217] Optionally, the cellular passive service intent resolution device 400 further includes an aggregation module, which is specifically used for: Receive a task execution result corresponding to each of the task messages; Aggregate all task execution results based on the extension metadata corresponding to each of the task messages to obtain original network data; Convert the original network data into service semantic data based on the intent type in the extension metadata.

[0218] Optionally, the cellular passive service intent resolution device 400 further includes an exception processing module, which is specifically used for: In the case that there is an exception label in the original network data, determine an exception type corresponding to the exception label; Perform exception processing on the original network data based on the exception type to obtain exception processing data.

[0219] Optionally, the cellular passive service intent resolution device 400 further includes an updating module, which is specifically used for: Update the initialization parameters corresponding to the SOF based on the original network data, the service semantic data, and the exception processing data.

[0220] The present application embodiment provides a cellular passive service intent resolution device, Figure 5 is a structure diagram two of the cellular passive service intent resolution device provided by the present application embodiment, as Figure 5 shown, the cellular passive service intent resolution device 500 includes a receiving module 510, a second obtaining module 520, and a first sending module 530.

[0221] The receiving module 510 is configured to receive an executable task message sequence sent by the SOF.

[0222] The second obtaining module 520 is configured to obtain a task execution result corresponding to the task message sequence.

[0223] The first sending module 530 is configured to send the task execution result to the SOF.

[0224] The task message sequence is a service intent request corresponding to a service server acquired by the SOF; the service intent request is parsed to obtain an intent descriptor corresponding to the service intent request; the intent descriptor is used to represent a structured cellular passive service element; protocol execution parameters and filtering information conforming to a bottom-layer network protocol are determined based on the intent descriptor; and the executable task message sequence is determined based on the intent descriptor, the filtering information, and the protocol execution parameters.

[0225] Figure 6 is a structural schematic diagram of a network device provided by an embodiment of the present application, with reference to Figure 6 The present application also provides a network device, which can include a memory 610, a transceiver 620, and a processor 630. The memory 610 is configured to store a computer program; the transceiver 620 is configured to transceive data under the control of the processor 630; and the processor 630 is configured to read the computer program in the memory 610 and perform the following operations: obtain a service intent request corresponding to a service server; parse the service intent request to obtain an intent descriptor corresponding to the service intent request; the intent descriptor is used to represent a structured cellular passive service element; determine protocol execution parameters and filtering information conforming to a bottom-layer network protocol based on the intent descriptor; determine an executable task message sequence based on the intent descriptor, the filtering information, and the protocol execution parameters; Alternatively, receive an executable task message sequence sent by the SOF; obtain a task execution result corresponding to the task message sequence; send the task execution result to the SOF; The task message sequence is a service intent request corresponding to a service server acquired by the SOF; the service intent request is parsed to obtain an intent descriptor corresponding to the service intent request; the intent descriptor is used to represent a structured cellular passive service element; protocol execution parameters and filtering information conforming to a bottom-layer network protocol are determined based on the intent descriptor; and the executable task message sequence is determined based on the intent descriptor, the filtering information, and the protocol execution parameters.

[0226] wherein, in Figure 6 The bus architecture can include any number of interconnected buses and bridges, specifically, various circuitry linking the one or more processors represented by the processor 630 and the memory represented by the memory 610. The bus architecture can also link various other circuitry such as peripheral devices, voltage regulators, and power management circuitry, which are well known in the art and thus, are not further described herein. The bus interface provides an interface. The transceiver 620 can be a plurality of elements, i.e., including a transmitter and a receiver, providing a means for communicating with various other apparatus over a transmission medium. The processor 630 is responsible for managing the bus architecture and general processing, and the memory 610 can store data used by the processor 630 in executing operations.

[0227] It should be noted that the terminal and the network device provided by the embodiments of the present application can realize all the method steps achieved by the above-mentioned method embodiments, and achieve the same technical effects. Therefore, the same parts and beneficial effects of the method embodiments in the embodiments will not be described in detail.

[0228] In another aspect, the present application also provides a computer program product, the computer program product comprising a computer program, the computer program being stored in a non-transitory computer-readable storage medium, and the computer program being executable by a processor to perform the method of analyzing the cellular passive service intention provided by each of the above methods, the method comprising: obtaining a service intention request corresponding to a service server; analyzing the service intention request to obtain an intention descriptor corresponding to the service intention request; the intention descriptor is used to represent a structured cellular passive service element; determining protocol execution parameters and filtering information conforming to a bottom network protocol based on the intention descriptor; determining an executable task message sequence based on the intention descriptor, the filtering information, and the protocol execution parameters. Or, receiving the executable task message sequence sent by the SOF; obtaining a task execution result corresponding to the task message sequence; sending the task execution result to the SOF; The task message sequence is the SOF obtaining a service intention request corresponding to a service server; analyzing the service intention request to obtain an intention descriptor corresponding to the service intention request; the intention descriptor is used to represent a structured cellular passive service element; determining protocol execution parameters and filtering information conforming to a bottom network protocol based on the intention descriptor; and determining based on the intention descriptor, the filtering information, and the protocol execution parameters.

[0229] In yet another aspect, the present application also provides a non-transitory computer-readable storage medium having stored thereon a computer program, which, when executed by a processor, implements the cellular passive service intention analysis method provided by the above method, the method comprising: obtaining a service intention request corresponding to a service server; analyzing the service intention request to obtain an intention descriptor corresponding to the service intention request; the intention descriptor is used to represent a structured cellular passive service element; determining protocol execution parameters and filtering information conforming to a bottom-layer network protocol based on the intention descriptor; determining an executable task message sequence based on the intention descriptor, the filtering information and the protocol execution parameters. Or, receiving the executable task message sequence sent by the SOF; obtaining a task execution result corresponding to the task message sequence; sending the task execution result to the SOF; The task message sequence is the SOF obtaining a service intention request corresponding to a service server; analyzing the service intention request to obtain an intention descriptor corresponding to the service intention request; the intention descriptor is used to represent a structured cellular passive service element; determining protocol execution parameters and filtering information conforming to a bottom-layer network protocol based on the intention descriptor; determining based on the intention descriptor, the filtering information and the protocol execution parameters.

[0230] The device embodiments described above are only schematic, wherein the units shown as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., can be located in one place, or can be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the present embodiment. Those skilled in the art can understand and implement without creative labor.

[0231] From the above description of the embodiments, those skilled in the art can clearly understand that the embodiments can be realized by means of software plus necessary universal hardware platforms, and of course can also be realized by hardware. Based on such understanding, the above technical solutions, essentially or in other words, the part of the prior art that makes a contribution, can be embodied in the form of a software product, which can be stored in a computer-readable storage medium, such as a ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions to make a computer device (which can be a personal computer, a server, or a first network device, etc.) execute the methods described in each embodiment or some parts of the embodiments.

[0232] Finally, it should be noted that the above examples are only used to illustrate the technical solutions of the present application, and are not intended to limit the same; although the present application has been described in detail with reference to the foregoing examples, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing examples, or make equivalent replacements for some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for parsing the intent of passive cellular services, characterized in that, The method, applied to the Service Orchestration Function (SOF) entity located between the core network and the service server, includes: Retrieve the business intent request corresponding to the business server; The service intent request is parsed to obtain the intent descriptor corresponding to the service intent request; the intent descriptor is used to represent structured cellular passive service elements; Based on the intent descriptor, determine the protocol execution parameters and filtering information that conform to the underlying network protocol; Based on the intent descriptor, the filtering information, and the protocol execution parameters, an executable task message sequence is determined.

2. The cellular passive service intent parsing method according to claim 1, characterized in that, The step of determining protocol execution parameters conforming to the underlying network protocol based on the intent descriptor includes: Based on the intent descriptor, protocol execution requirement parameters that conform to the underlying network protocol are determined from the protocol mapping table; the protocol mapping table is used to represent the mapping relationship between intent and execution requirement parameters. When the intent descriptor is missing, protocol missing parameters are generated based on a preset strategy; The protocol execution requirement parameters and the protocol missing parameters are determined as protocol execution parameters that conform to the underlying network protocol.

3. The cellular passive service intent parsing method according to claim 1, characterized in that, The step of parsing the business intent request to obtain the intent descriptor corresponding to the business intent request includes: Semantic extraction is performed on the business intent request to obtain the intent descriptor corresponding to the business intent request; the intent descriptor includes an intent field and a parameter field; the parameter field includes at least one of the following: business area, device type, time range, additional action, result style, tenant identifier, contextual prompt information, and resolution confidence.

4. The cellular passive service intent parsing method according to claim 3, characterized in that, Based on the intent descriptor, filter information conforming to the underlying network protocol is determined, including: Based on the device type and the tenant identifier, determine the target filtering template; Based on the initial filter field and at least two parameter fields in the target filter template, a filter information draft conforming to the underlying network protocol is determined; the filter information draft includes filter components corresponding to each of the parameter fields. Based on the draft filtering information, filtering information that conforms to the underlying network protocol is determined.

5. The cellular passive service intent parsing method according to claim 1, characterized in that, The step of determining the executable task message sequence based on the intent descriptor, the filtering information, and the protocol execution parameters includes: If the intent descriptor meets the decomposition conditions, the intent descriptor is decomposed to obtain a task list including multiple tasks; the parameters of each task are determined based on the intent descriptor, the filtering information, and the protocol execution parameters. Based on the task list, determine the executable task message sequence; The decomposition conditions include at least one of the following: composite intent field type, region size exceeding a first preset threshold, device size exceeding a second preset threshold, command risk level exceeding a third preset threshold, tenant authorization pruning, and time tiering requirements.

6. The cellular passive service intent parsing method according to claim 5, characterized in that, The step of determining the executable task message sequence based on the task list includes: The parameters of each task in the task list are mapped to protocol fields that conform to the protocol corresponding to the first network device; Encapsulate the protocol fields of each task to obtain the interface message corresponding to each task; Add extended metadata to each of the interface messages to obtain the task messages corresponding to each task. The task messages corresponding to each task are determined as an executable sequence of task messages.

7. The cellular passive service intent parsing method according to claim 3, characterized in that, Before generating the protocol missing parameters based on the preset strategy, the method further includes: A verification operation is performed based on the parameter fields to determine the verification result corresponding to the business intent request; the verification operation includes at least one of the following: regional legality verification operation, device type access permission verification operation, and time range policy verification operation.

8. The cellular passive service intent parsing method according to any one of claims 1-7, characterized in that, The method further includes: The task message sequence is sent to the first network device; the first network device is used to forward the task message sequence to the passive IoT device.

9. The cellular passive service intent parsing method according to claim 8, characterized in that, The method further includes: Receive the task execution results corresponding to each of the aforementioned task messages; Based on the extended metadata corresponding to each task message, the execution results of all tasks are aggregated to obtain the raw network data. Based on the intent type in the extended metadata, the original network data is converted into business semantic data.

10. The cellular passive service intent parsing method according to claim 9, characterized in that, The method further includes: If anomaly labels exist in the original network data, determine the anomaly type corresponding to the anomaly label; Based on the aforementioned anomaly type, the original network data is processed to obtain anomaly-processed data.

11. The cellular passive service intent parsing method according to claim 10, characterized in that, The method further includes: Based on the original network data, the business semantic data, and the anomaly handling data, update the initialization parameters corresponding to the SOF.

12. A method for parsing the intent of passive cellular services, characterized in that, Applied to a first network device, the method includes: Receive the sequence of executable task messages sent by SOF; Obtain the task execution result corresponding to the task message sequence; Send the task execution result to the SOF; The task message sequence is the service intent request corresponding to the service server obtained by the SOF; the service intent request is parsed to obtain the intent descriptor corresponding to the service intent request; the intent descriptor is used to characterize the structured cellular passive service elements; based on the intent descriptor, the protocol execution parameters and filtering information that conform to the underlying network protocol are determined; determined based on the intent descriptor, the filtering information and the protocol execution parameters.

13. A cellular passive service intent parsing device, characterized in that, include: The first acquisition module is used to acquire the business intent request corresponding to the business server; The parsing module is used to parse the service intent request to obtain the intent descriptor corresponding to the service intent request; the intent descriptor is used to represent structured cellular passive service elements. The first determining module is used to determine, based on the intent descriptor, protocol execution parameters and filtering information that conform to the underlying network protocol; The second determining module is used to determine an executable task message sequence based on the intent descriptor, the filtering information, and the protocol execution parameters.

14. A cellular passive service intent parsing device, characterized in that, include: The receiving module is used to receive the sequence of executable task messages sent by SOF; The second acquisition module is used to acquire the task execution result corresponding to the task message sequence; The first sending module is used to send the task execution result to the SOF; The task message sequence is the SOF request for obtaining the business intent corresponding to the business server; The service intent request is parsed to obtain the intent descriptor corresponding to the service intent request; the intent descriptor is used to represent structured cellular passive service elements; Based on the intent descriptor, determine the protocol execution parameters and filtering information that conform to the underlying network protocol; Determined based on the intent descriptor, the filtering information, and the protocol execution parameters.

15. A network device, characterized in that, Includes memory, transceiver, and processor; Memory, used to store computer programs; Transceiver, used to send and receive data under the control of the processor; A processor is configured to read a computer program from the memory and execute the steps of the cellular passive service intent parsing method according to any one of claims 1 to 11, or implement the steps of the cellular passive service intent parsing method according to claim 12.

16. A cellular passive system, characterized in that, This includes business servers and network equipment, among which: The service server is used to send service intent requests to the network device; The network device is used to perform the steps of the cellular passive service intent parsing method as described in any one of claims 1 to 11, or to implement the steps of the cellular passive service intent parsing method as described in claim 12.

17. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the cellular passive service intent parsing method as described in any one of claims 1 to 11, or implements the steps of the cellular passive service intent parsing method as described in claim 12.

Images