Validation method and device of ursp rule and network side equipment

Abstract

The application discloses a URSP rule verification method, device and network side equipment, and belongs to the wireless communication field. The URSP rule verification method of the application embodiment comprises the following steps: a first network side equipment acquires target request information sent by a second network side equipment, wherein the target request information comprises a first URSP rule used by a terminal for a target application and a first parameter of a first PDU session carrying the target application; the first network side equipment obtains a first verification result by verifying whether the first URSP rule is consistent with a second URSP rule; and the first network side equipment verifies whether a first parameter of the first PDU session is consistent with a second parameter described in a route selection descriptor (RSD) in the first URSP rule, and obtains a second verification result.

Description

Technical Field

[0001] This application belongs to the field of wireless communication technology, specifically relating to a method, apparatus, and network-side device for verifying URSP rules. Background Technology

[0002] In the 3rd Generation Partnership Project (3GPP) protocol, when an application on a terminal needs to send traffic, the application can provide the traffic characteristics of the application traffic to be sent. The terminal (OS or modem chip) obtains the traffic characteristics provided by the application, such as the destination IP address and Fully Qualified Domain Name (FQDN) of the application traffic to be sent. The terminal matches these traffic characteristics with the TrafficDescriptor (TD) parameters in the User Equipment Route Selection Policy (URSP) rules in the terminal. After a match is found, the terminal selects a Route Selection Descriptor (RSD) under that traffic descriptor. This Route Selection Descriptor defines the session parameters of the Protocol Data Unit (PDU) session used to carry the application traffic to be transmitted after the application traffic characteristics match a certain traffic descriptor. If the current UE already has a PDU session, and the session parameters of that PDU session are consistent with an RSD under the traffic descriptor selected by the terminal for the application traffic, then the application's data to be transmitted can be routed to the established Protocol Data Unit (PDU) session. Alternatively, if the terminal selects an RSD under the traffic descriptor for the application traffic to be transmitted, but no such PDU session exists within the current terminal, then the terminal can trigger the establishment of a new PDU session. The session parameters of the established PDU session are consistent with the PDU session parameters within the selected RSD, and this PDU session is used to carry the application data stream to be transmitted.

[0003] However, in related technologies, URSP rules are merely the behavior of terminal devices. For a given application, the network-side device cannot know whether the terminal device has applied the URSP rules configured by the network-side device for that terminal device to match application traffic to a specific PDU session, or the specific URSP rules used by the terminal device to match the application traffic. Summary of the Invention

[0004] This application provides a method, apparatus, and network-side device for verifying URSP rules, which can solve the problem that the network-side device cannot know whether the terminal device applies the configured URSP rules and the URSP rules used by the terminal device for a specific application.

[0005] In a first aspect, a method for verifying URSP rules is provided, comprising: a first network-side device acquiring target request information sent by a second network-side device, wherein the target request information includes: a first URSP rule used by a terminal for a target application and a first parameter of a first PDU session carrying the target application; the first network-side device obtaining a first verification result by verifying whether the first URSP rule and a second URSP rule are consistent, wherein the second URSP rule is at least one URSP rule corresponding to the target application sent by the first network-side device to the terminal; and the first network-side device obtaining a second verification result by verifying whether the first parameter of the first PDU session is consistent with the second parameter described by the routing descriptor (RSD) in the first URSP rule.

[0006] Secondly, a method for verifying URSP rules is provided, comprising: a second network-side device receiving reporting information sent by a terminal, wherein the reporting information includes: a first URSP rule used by the terminal for a target application and a first PDU session identifier carrying the target application, the first PDU session identifier being used to indicate a first PDU session; the second network-side device obtaining a first parameter of the first PDU session; the second network-side device sending target request information to a first network-side device, wherein the target request information instructs the first network-side device to verify whether the terminal correctly uses URSP rules, the target request information including the first URSP rule and the first parameter of the first PDU session.

[0007] Thirdly, a method for verifying URSP rules is provided, comprising: a third network-side device receiving target request information sent by a second network-side device, wherein the target request information instructs a first network-side device to verify whether the terminal correctly uses URSP rules, and the target request information includes the first URSP rule and the first parameter of the first PDU session; the third network-side device sending the target request information to the first network-side device.

[0008] Fourthly, a URSP rule verification device is provided, comprising: a first acquisition module, configured to acquire target request information sent by a second network-side device, wherein the target request information includes: a first URSP rule used by a terminal for a target application and a first parameter of a first PDU session carrying the target application; a first verification module, configured to obtain a first verification result by verifying whether the first URSP rule and a second URSP rule are consistent, wherein the second URSP rule is at least one URSP rule corresponding to the target application sent by the first network-side device to the terminal; and a second verification module, configured to verify whether the first parameter of the first PDU session is consistent with the second parameter described by the routing descriptor (RSD) in the first URSP rule, thereby obtaining a second verification result.

[0009] Fifthly, a URSP rule verification device is provided, comprising: a second transceiver module for receiving reporting information sent by a terminal, wherein the reporting information includes: a first URSP rule used by the terminal for a target application and a first PDU session identifier carrying the target application, the first PDU session identifier indicating a first PDU session; a second acquisition module for acquiring first parameters of the first PDU session; the second transceiver module is further configured to send target request information to a first network-side device, wherein the target request information instructs the first network-side device to verify whether the terminal correctly uses the URSP rule, the target request information including the first URSP rule and the first parameters of the first PDU session.

[0010] In a sixth aspect, a URSP rule verification device is provided, comprising: a receiving module for receiving target request information sent by a second network-side device, wherein the target request information instructs a first network-side device to verify whether the terminal correctly uses the URSP rule, and the target request information includes the first URSP rule and a first parameter of the first PDU session; and a sending module for sending the target request information to the first network-side device.

[0011] A seventh aspect provides a network-side device including a processor and a memory, the memory storing a program or instructions executable on the processor, the program or instructions, when executed by the processor, implementing the steps of the method as described in the first to third aspects.

[0012] Eighthly, a network-side device is provided, including a processor and a communication interface, wherein the processor is used to implement the steps of the method as described in the first to third aspects, and the communication interface is used to communicate with an external device.

[0013] In a ninth aspect, a URSP rule verification system is provided, comprising: a first network-side device and a second network-side device, wherein the first network-side device can be used to perform the steps of the method described in the first aspect, and the second network-side device can be used to perform the steps of the method described in the second aspect.

[0014] In a tenth aspect, a readable storage medium is provided, on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect, or the steps of the method described in the second aspect, or the steps of the method described in the third aspect.

[0015] Eleventhly, a chip is provided, the chip including a processor and a communication interface coupled to the processor, the processor being configured to run a program or instructions to implement the steps of the method described in the first aspect, or the steps of the method described in the second aspect, or the steps of the method described in the third aspect.

[0016] In a twelfth aspect, a computer program / program product is provided, which is stored in a storage medium and is executed by at least one processor to implement the steps of the method as described in the first aspect, or the steps of the method as described in the second aspect, or the steps of the method as described in the third aspect.

[0017] In this embodiment, the first network-side device obtains from the second network-side device the first URSP rule used by the terminal for the target application and the first parameter of the first PDU session carrying the target application. It verifies whether the first URSP rule is consistent with at least one URSP rule corresponding to the target application sent by the first network-side device to the terminal, and verifies whether the first parameter of the first PDU session is consistent with the second parameter described by the routing descriptor (RSD) in the first URSP rule. This allows the first network-side device to know whether the terminal has applied the URSP rule configured by the network-side device for the terminal to match application traffic to a specific PDU session, the specific URSP rule used by the terminal to match the application traffic, and whether the corresponding PDU session includes data packets of the application traffic, thus facilitating network-side device control of the terminal. Attached Figure Description

[0018] Figure 1 This diagram illustrates a block diagram of a wireless communication system to which embodiments of this application may be applied;

[0019] Figure 2 This illustration shows a flowchart of a URSP rule verification method provided in an embodiment of this application;

[0020] Figure 3 This illustration shows another flowchart of the URSP rule verification method provided in the embodiments of this application;

[0021] Figure 4 This is a schematic flowchart illustrating a method for obtaining the identifier of a first network-side device according to an embodiment of this application;

[0022] Figure 5 This illustration shows another flowchart of a method for obtaining the identifier of a first network-side device according to an embodiment of this application;

[0023] Figure 6 This illustration shows yet another flowchart of a method for obtaining the identifier of a first network-side device according to an embodiment of this application;

[0024] Figure 7 This illustration shows yet another flowchart of a method for obtaining the identifier of a first network-side device according to an embodiment of this application;

[0025] Figure 8 This illustration shows another flowchart of the URSP rule verification method provided in the embodiments of this application;

[0026] Figure 9 This illustration shows another flowchart of the URSP rule verification method provided in the embodiments of this application;

[0027] Figure 10 This illustration shows another flowchart of the URSP rule verification method provided in the embodiments of this application;

[0028] Figure 11 This illustration shows another flowchart of the URSP rule verification method provided in the embodiments of this application;

[0029] Figure 12 This illustration shows another flowchart of the URSP rule verification method provided in the embodiments of this application;

[0030] Figure 13 This illustration shows another flowchart of the URSP rule verification method provided in the embodiments of this application;

[0031] Figure 14 This illustration shows another flowchart of the URSP rule verification method provided in the embodiments of this application;

[0032] Figure 15 This diagram illustrates a structural schematic of a URSP rule verification device provided in an embodiment of this application.

[0033] Figure 16 This illustration shows another structural diagram of the URSP rule verification device provided in an embodiment of this application;

[0034] Figure 17 This diagram illustrates yet another structural schematic of the URSP rule verification device provided in an embodiment of this application;

[0035] Figure 18 This illustration shows a structural diagram of a communication device provided in an embodiment of this application;

[0036] Figure 19 This diagram illustrates the hardware structure of a network-side device according to an embodiment of this application. Detailed Implementation

[0037] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0038] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first" and "second" are generally of the same class, not limited in number; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0039] It is worth noting that the technologies described in this application are not limited to Long Term Evolution (LTE) / LTE-Advanced (LTE-A) systems, but can also be used in other wireless communication systems, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single-carrier Frequency Division Multiple Access (SC-FDMA), and other systems. The terms "system" and "network" in this application are often used interchangeably, and the described technologies can be used with the systems and radio technologies mentioned above, as well as with other systems and radio technologies. The following description describes New Radio (NR) systems for illustrative purposes, and NR terminology is used in most of the following description; however, these technologies can also be applied to applications beyond NR systems, such as 6th generation (6G) radio systems. th Generation 6G communication system.

[0040] Figure 1This diagram illustrates a block diagram of a wireless communication system applicable to embodiments of this application. The wireless communication system includes a terminal 11 and a network-side device 12. Terminal 11 can be a mobile phone, tablet computer, laptop computer, personal digital assistant (PDA), handheld computer, netbook, ultra-mobile personal computer (UMPC), mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, vehicle-mounted device (VUE), pedestrian terminal (PUE), smart home (home devices with wireless communication capabilities, such as refrigerators, televisions, washing machines, or furniture), game console, personal computer (PC), ATM, or self-service machine, etc. Wearable devices include: smartwatches, smart bracelets, smart headphones, smart glasses, smart jewelry (smart bracelets, smart chains, smart rings, smart necklaces, smart anklets, smart anklets, etc.), smart wristbands, smart clothing, etc. It should be noted that the specific type of terminal 11 is not limited in this embodiment. Network-side equipment 12 may include access network equipment and / or core network equipment. Access network equipment 12 may also be referred to as radio access network equipment, radio access network (RAN), radio access network function, or radio access network unit. Access network equipment 12 may include base stations, WLAN access points, or WiFi nodes, etc. Base stations may be referred to as Node B, evolved Node B (eNB), access point, base transceiver station (BTS), radio base station, radio transceiver, Basic Service Set (BSS), Extended Service Set (ESS), home B node, home evolved B node, Transmitting Receiving Point (TRP), or any other suitable term in the field, as long as the same technical effect is achieved. The base station is not limited to specific technical terms. It should be noted that in this application embodiment, only a base station in an NR system is used as an example for description, and the specific type of base station is not limited.Core network equipment may include, but is not limited to, at least one of the following: core network node, core network function, Mobility Management Entity (MME), Access and Mobility Management Function (AMF), Session Management Function (SMF), User Plane Function (UPF), Policy Control Function (PCF), Policy and Charging Rules Function (PCRF), Edge Application Server Discovery Function (EASDF), Unified Data Management (UDM), Unified Data Repository (UDR), Home Subscriber Server (HSS), Centralized network configuration (CNC), Network Repository Function (NRF), Network Exposure Function (NEF), Local NEF (or L-NEF), and Binding Support. Core network functions (BSF), application functions (AF), etc. It should be noted that this application embodiment only uses core network equipment in the NR system as an example for description, and does not limit the specific type of core network equipment.

[0041] URSP rules are a policy defined by 3GPP and sent to the UE. The UE can match application (APP) traffic to a specific PDUsession according to the URSP rules.

[0042] For example, when an application (APP) on the UE needs to send traffic to the server, the APP can send APP traffic characteristics to the UE. These traffic characteristics can include destination IP address, FQDN, etc. Then, the UE matches the URSP rules in the UE one by one according to the APP's traffic characteristics. The traffic descriptions / characteristics specified in URSPrules can be shown in Table 1.

[0043] Table 1.

[0044]

[0045] For example, the second app can send an IP description, such as a destination IP triple, indicating that the app's traffic needs to be sent to a destination IP of 10.1.1.1 and a port number of 80. Then, if the UEURSPrules contains this traffic descriptor, it means that the app's traffic can match a certain UEURSPrules.

[0046] After matching the APP's traffic with URSPrules, the next step is to select which PDU session to use to send the APP's traffic.

[0047] Generally, a trafficdescriptor has at least one RSD, and each RSD represents a set of attributes for a PDUsession. For example, when APPtraffic matches the trafficdescriptor group with destination IP = 10.1.1.1 and port number = 80, this trafficdescriptor group has the following RSDs:

[0048] ■RSD Priority = 1

[0049] ◆S-NSSAI-a

[0050] ◆Non-3GPP Access

[0051] ■RSDprecedence=2

[0052] ◆S-NSSAI-a

[0053] ◆3GPP Access

[0054] ◆DNN = Internet

[0055] ◆SSCmode=3

[0056] For example, the characteristics or parameters of the PDU session corresponding to RSD1 are: S-NSSAI = S-NSSAI-a, using non-3GPP access. The terminal can use this PDU session in RSD1 to specifically establish a PDU session; or it can use this characteristic to select a PDU session that the terminal has already established. The selected PDU session has the same session characteristics or parameters as S-NSSAI = S-NSSAI-a, using non-3GPP access (i.e., the access type of the PDU session is non-3GPP access).

[0057] However, after the network-side device sends URSPrules to the UE, it is unknown to the network-side device whether the UE uses URSPrules to match the APP traffic to a specific PDU session, and which URSP rule is used for traffic matching, for the APP traffic. For example, for traffic of a certain application, the RSD of the traffic descriptor matched by the UE includes:

[0058] ■RSDprecedence=1

[0059] ◆S-NSSAI-a

[0060] ◆Non-3GPP Access

[0061] ■RSDprecedence=2

[0062] ◆S-NSSAI-a

[0063] ◆3GPP Access

[0064] ◆DNN = Internet

[0065] ◆SSCmode=3

[0066] The network-side device is unaware of whether the UE has executed URSP rules, and if so, which RSD it executed. To address this issue, this application provides a URSP rule verification scheme, enabling the network-side device to obtain this information. This allows the network to determine which RSD under which traffic descriptor the terminal used for traffic to a specific application, and whether using the URSP rule resulted in a newly established PDU session or matching the application traffic to an existing session.

[0067] The following description, in conjunction with the accompanying drawings, details the URSP rule verification scheme provided in this application through some embodiments and application scenarios.

[0068] Figure 2This diagram illustrates a flowchart of a URSP rule verification method according to an embodiment of this application. This method 200 can be executed by a first network-side device. In other words, the method can be executed by software or hardware installed on the first network-side device. In this embodiment, the first network-side device can be an Access and Mobility Management Policy Control (AM-PCF) network element, for example, the first network-side device can be an AM-PCF. Figure 2 As shown, the method may include the following steps.

[0069] S210, the first network-side device obtains target request information sent by the second network-side device, wherein the target request information includes: the first URSP rule used by the terminal for the target application and the first parameters of the first protocol data unit (PDU) session carrying the target application.

[0070] The target request information instructs the first network-side device to verify whether the terminal is correctly using URSP rules. In this embodiment, the second network-side device can be a session management element, such as a Session Management Function (SMF).

[0071] The target request information can be sent via at least one of the following signaling methods: Npcf_EventExposure_Subscribe, Npcf_UEPolicyControl_Update request.

[0072] For example, after a terminal uses a URSP rule for a certain application traffic, it can report the details of the specific URSP rule used to the second network-side device through a Session Non-Access Stratum (NAS) message. For instance, it can report that the terminal used a specific Traffic descriptor (FQDN = ABC.com) or an RSD (S-NSSAI = S-NSSAI-a, using non-3GPP access). Alternatively, it can directly indicate the priority of the rule or the priority of the RSD used, because for a single terminal, one rule priority corresponds to only one traffic descriptor, and the priority of an RSD under a traffic descriptor corresponds to only one RSD. For example, if the terminal reports the first URSP rule as follows: ruleprecedence = 1, RSDprecedence = 2, this indicates that the terminal used a rule with priority 1 and an RSD with priority 2 under that traffic descriptor. The NAS message includes at least one of the following: PDU session establishment request and DPU session modification request. Alternatively, the NAS message may also include: a PDU session SM context creation request (Nsmf_PDUSession_CreateSMContext Request) or a PDU session SM context update request (Nsmf_PDUSession_UpdateSMContext Request).

[0073] After receiving the NAS message from the terminal, the second network-side device can obtain the first parameter of the first PDU session corresponding to the first PDU session identifier carried in the NAS message, and then send the first parameter of the first PDU session and the first URSP rule used by the target application reported by the terminal to the first network-side device.

[0074] The first PDU session identifier indicates the PDU session to which the application traffic is ultimately matched. This PDU session can be a newly created session or an existing session on the terminal. The information reported by the terminal to the second network-side device may also include an indication message indicating whether a new PDU session is created or an existing PDU session on the terminal is matched after applying the URSP rule. For example, the indication message might indicate that a new PDU session is created to carry the application traffic after applying the first URSP rule.

[0075] In this embodiment of the application, the first network-side device and the second network-side device can directly transmit target request information. Therefore, in one possible implementation, S210 may include: the first network-side device receiving the target request information from the second network-side device.

[0076] Alternatively, the target request information can also be transmitted between the first network-side device and the second network-side device via a third network-side device and / or a fourth network-side device. Therefore, in another possible implementation, S210 may include: the first network-side device receiving the target request information forwarded by the second network-side device via the third network-side device and / or the fourth network-side device.

[0077] The third network-side device can be an Access and Mobility Management (AMF) network element, such as an Access and Mobility Management (AMM) network element, or a Session Management Policy Control (SM-PCF) network element. The fourth network-side device can be a Session Management Policy Control (SM-PCF) network element, or an Access and Mobility Management (AMF) network element. For example, the SMF sends the target request information to the AM-PCF through the AMF; or, the SMF sends the target request information to the AM-PCF through the SM-PCF; or, the SMF sends the target request information to the AMF, the AMF then sends the target request information to the SM-PCF, and the SM-PCF then sends the target request information to the AM-PCF; or, the SMF sends the target request information to the SM-PCF, the SM-PCF then sends the target request information to the AMF, and the AMF then sends the target request information to the AM-PCF.

[0078] For example, if the third network-side device is an AMF, the second network-side device is an SMF, and the first network-side device is an AM-PCF, the SMF can send the target request information to the AMF via Namf_Communication_N1N2MessageTransfer or Nsmf_EventExposure_Notify; then the AMF can send the target request information to the first network-side device, such as the AM-PCF, via Npcf_UEPolicyControl_Update request, Npcf_UEPolicyControl_UpdateNotify Subscribe, or Npcf_EventExposure_Subscribe.

[0079] For example, if the fourth network-side device is an SM-PCF, the second network-side device is an SMF, and the first network-side device is an AM-PCF, then the SMF can send the target request information to the fourth network-side device through at least one of the following signaling methods: Npcf_SMPolicyControl_Update or Npcf_SMPolicyControl_create; then, the SM-PCF can send the target request information to the AM-PCF through at least one of the following signaling methods: Npcf_PolicyAuthorization_Create, Npcf_Policy Authorization_Update.

[0080] Sending target request information also refers to sending the parameters contained in the target request information, such as the first URSP rule, to the first network-side device, such as AM-PCF.

[0081] S212, the first network-side device obtains a first verification result by verifying whether the first URSP rule and the second URSP rule are consistent, wherein the second URSP rule is at least one URSP rule corresponding to the target application sent by the first network-side device to the terminal.

[0082] The first verification result is used to indicate whether the first URSP rule and the second URSP rule are consistent. For example, the first verification result may include: the first URSP rule and the second URSP rule are consistent, that is, the first verification passes; or, the first URSP rule and the second URSP rule are inconsistent, that is, the first verification fails.

[0083] For example, the terminal executes URSP rules for the traffic of the target application, and then the terminal sends the URSP rules used to the SMF. The SMF forwards the URSP rules to the AM-PCF, and the AM-PCF performs the first verification, verifying whether the rule reported by the terminal is consistent with the rule sent by the AM-PCF to the UE, that is, verifying whether the URSP rule reported by the terminal is one of the URSP rules sent by the AM-PCF to the UE.

[0084] For example, the terminal reports the URSP rules it uses: Rule Precedence = 1 and RSD Precedence = 1. The first network-side device can restore or query the URSP rule corresponding to this priority in the AM-PCF based on the information reported by the terminal, or the AM-PCF can check the second URSP rule sent to the UE. For instance, based on the terminal's reported RulePrecedence = 1 and RSD Precedence = 1, the AM-PCF, after checking, finds the following URSP rule sent to this UE:

[0085] Rule Precedence = 1;

[0086] Traffic Descriptor: Application Descriptor = App1;

[0087] RSD Precedence = 1;

[0088] Network Slice Selection Identifier: S-NSSAI-a;

[0089] Session and Service Continuity (SSC) Mode Selection: SSC Mode 3;

[0090] Data Network Name (DNN) Selection: internet;

[0091] Access type preference: 3GPP access.

[0092] The terminal reported the first URSP rule used as follows:

[0093] Rule Precedence = 1;

[0094] Traffic Descriptor:Application descriptor=App1;

[0095] Route Selection Descriptor Precedence=1;

[0096] Network Slice Selection: S-NSSAI-a;

[0097] SSC Mode Selection: SSC Mode 3;

[0098] DNN Selection: Internet;

[0099] Access Type preference: 3GPP access.

[0100] The first network-side device then determines that the usage rule reported by the terminal (i.e., the first URSP rule) is the same as the rule actually sent by the UE to the first network-side device (i.e., the second URSP rule). If the verification passes, the rule reported by the UE is correct. This verification refers to checking whether the URSP rule reported by the terminal, including the traffic descriptor and RSD, is consistent with the traffic descriptor or RSD in the URSP rule sent to the terminal by the first network-side device. If they are consistent, it is determined that the terminal strictly used one of the URSP rules issued by AM-PCF, rather than the terminal arbitrarily using a URSP rule that the network has never issued.

[0101] S214, the first network-side device verifies whether the first parameter of the first PDU session is consistent with the second parameter described by the RSD in the first URSP rule, and obtains the second verification result.

[0102] The second verification result indicates whether the first parameter of the first PDU session is consistent with the second parameter described in the RSD of the first URSP rule. For example, the second verification result may include: the first parameter of the first PDU session and the second parameter described in the RSD of the first URSP rule are consistent in a one-to-one correspondence, i.e., the first parameter and the second parameter are consistent, i.e., the second verification passes; or, the first parameter of the first PDU session is inconsistent with any one of the second parameters described in the RSD of the first URSP rule, i.e., the second verification fails.

[0103] For example, if the first verification result indicates that the first URSP rule is consistent with at least one of the second URSP rules, the first network-side device may initiate a second verification, that is, verify whether the first parameter of the first PDU session is consistent with the second parameter described by the RSD in the first URSP rule.

[0104] Optionally, the first parameter of the first PDU session included in the target request information may include at least one of the following: PDU session type, PDU session access type, SSC mode, network slice identifier, and DNN.

[0105] Optionally, the second parameter described by the RSD in the first URSP rule may include at least one of the following: PDU session type, PDU session access type, SSC mode, network slice identifier, and DNN.

[0106] In this embodiment, whether the first parameter and the second parameter are consistent refers to whether the parameter values ​​of each parameter in the first parameter are consistent with the parameter values ​​of the corresponding parameters in the second parameter. For example, when the first parameter and the second parameter respectively include: PDU session type, PDU session access type, SSC mode, and DNN, then whether the first parameter and the second parameter are consistent means that the PDU session type in the first parameter is the same as the PDU session type in the second parameter, the PDU session access type in the first parameter is the same as the PDU session access type in the second parameter, the SSC mode in the first parameter is the same as the SSC mode in the second parameter, and the DNN in the first parameter is the same as the DNN in the second parameter. If any one of these is different, then the first parameter and the second parameter are inconsistent.

[0107] The purpose of the second verification is to ensure that if the terminal has indeed correctly used the first URSP rule, the parameters of the PDU session carrying the application traffic, such as SSC mode and DNN, must correspond one-to-one with the parameters of the PDU session indicated in the RSD of the first URSP rule, such as SSC mode and DNN, and be identical.

[0108] The purpose of performing the second verification in S214 is to ensure that if the terminal has indeed correctly used the first URSP rule, the parameters of the PDU session carrying the application traffic, such as SSC mode and DNN, must correspond one-to-one with the parameters of the PDU session indicated in the RSD of the first URSP rule, such as SSC mode and DNN, and be identical.

[0109] In S214, the first network-side device obtains the second verification result, thereby determining whether the first parameter of the first PDU session carrying the target application is consistent with the second parameter described by the RSD in the first URSP rule.

[0110] For example, the first URSP rule reported by the terminal is:

[0111] Rule Precedence = 1;

[0112] Traffic Descriptor:Application descriptor=App1;

[0113] Route Selection Descriptor Precedence=1;

[0114] Network Slice Selection:S-NSSAI-a;

[0115] SSC Mode Selection:SSC Mode 3;

[0116] DNN Selection: internet;

[0117] Access Type preference: 3GPP access.

[0118] The second network-side device, after inspection, obtains the first PDU session that actually carries the traffic of the target application (i.e., APP1). The first parameter of this first PDU session is:

[0119] Network Slice Selection:S-NSSAI-b;

[0120] SSC Mode Selection:SSC Mode 3;

[0121] DNN Selection: internet;

[0122] Access Type preference: 3GPP access.

[0123] Therefore, it is evident that the network slice in the second parameter is S-NSSAI-b, while the network slice in the first parameter is S-NSSAI-b, which is inconsistent. Consequently, the terminal did not correctly use the URSP rules. In other words, although the terminal reported the URSP rules it used, the app's traffic did not actually utilize the PDU session bearers corresponding to the various PDU session parameters of this RSD. This indicates that the second verification failed, and the terminal did not correctly use the URSP rules.

[0124] In one possible implementation, the first network-side device can return the first authentication result and / or the second authentication result to the second network-side device. Taking the first network-side device as AM-PCF and the second network-side device as SMF as an example, AM-PCF can use at least one of the following signaling methods to send the first authentication result and / or the second authentication result to SMF: Npcf_EventExposure_Notify, Npcf_UEPolicyControl Update response.

[0125] Alternatively, the AM-PCF can send the first authentication result and / or the second authentication result to the AMF using at least one of the following signaling: Npcf_UEPolicyControl_Update response; Npcf_UEPolicyControl_UpdateNotify notify. Then, the AMF can use at least one of the following signaling to send the first authentication result and / or the second authentication result to the SMF: Nsmf_PDUSession_UpdateSMContext request; Nsmf_EventExposure_Subscribe.

[0126] Alternatively, the AM-PCF may use at least one of the following signaling methods to send the first authentication result and / or the second authentication result to the SM-PCF: Npcf_Policy Authorization_Createrequest / response, Npcf_PolicyAuthorization_Update request / response. The SM-PCF then uses at least one of the following signaling methods to send the first authentication result and / or the second authentication result to the SMF: Npcf_SMPolicyControl_Updaterequest / response, Npcf_SMPolicyControl_createrequest / response.

[0127] Through the technical solutions provided in the embodiments of this application, the first network-side device obtains from the second network-side device the first URSP rule used by the terminal for the target application and the first parameter of the first PDU session carrying the target application. It verifies whether the first URSP rule is consistent with at least one URSP rule corresponding to the target application sent by the first network-side device to the terminal, and verifies whether the first parameter of the first PDU session is consistent with the second parameter described by the routing descriptor (RSD) in the first URSP rule. This allows the first network-side device to know whether the terminal has applied the URSP rule configured by the network-side device for the terminal to match application traffic to a specific PDU session, the specific URSP rule used by the terminal to match the application traffic, and whether the corresponding PDU session includes data packets of the application traffic, thus facilitating the network-side device to control the terminal.

[0128] In one possible implementation, in order for the second network-side device to know the identifier of the first network-side device and thus send the target request information to the first network-side device, the method may further include the following steps before S210:

[0129] Step 1: The first network-side device sends URSP rules to the terminal;

[0130] Step 2: The first network-side device sends a first indication message to the third network-side device. This first indication message instructs the third network-side device to send its identifier to the second network-side device after receiving a PDU session establishment request or a PDU session modification request from the terminal. For example, the third network-side device can send the identifier of the first network-side device to the second network-side device using the following signaling: Npcf_UEPolicyControl Create Request or Npcf_UEPolicyControl Update Request.

[0131] The identifier of the first network-side device includes, but is not limited to, the identifier of the first network-side device and / or the IP address of the first network-side device.

[0132] In the above possible implementations, when the first network-side device sends URSP rules to the terminal, it instructs the third network-side device, upon receiving a PDU session establishment request or PDU session modification request from the terminal, to send the identifier of the first network-side device to the second or fourth network-side device. This allows the second network-side device to obtain the identifier of the first network-side device when the terminal establishes or modifies a PDU session, and thus send the first URSP rules used by the target application reported by the terminal via the session NAS message, as well as the first parameters of the first PDU session carrying the target application obtained by the second network-side device, to the first network-side device. For example, the first network-side device can send URSP rules to the terminal and the first instruction information to the third network-side device when the terminal registers with the network.

[0133] Optionally, in the above possible implementations, before the first network-side device sends the first indication information to the third network-side device, the first network-side device receives a first request message sent by the third network-side device. This first request message requests the creation or updating of URSP rules for the terminal. The first request message carries the terminal's capability information, indicating that the terminal supports reporting the usage information of the terminal's URSP rules. That is, the first network-side device only sends the first indication information to the third network-side device after learning that the terminal supports reporting the usage information of the terminal's URSP rules. For example, the terminal can carry the terminal's capability information in the registration message, indicating that the terminal supports reporting the usage information of URSP rules.

[0134] In one possible implementation, the method may further include: the first network-side device acquiring a third verification result sent by the second network-side device, wherein the third verification result indicates whether the first PDU session includes data packets of the target application.

[0135] For example, the third verification result may include at least one of the following: if the first PDU session includes a data packet of the target application, the third verification passes; if the first PDU session does not include a data packet of the target application, the third verification fails.

[0136] In a practical application, one possible scenario is that although the terminal declares the use of the first URSP rule, and the network side does indeed check that the session parameters of the first PDU session are consistent with the session parameters indicated by the RSD in the first URSP rule, the terminal may not actually use this first PDU session to transmit application traffic, but instead use another PDU session. Therefore, through the above possible implementation methods, the first network-side device can determine whether the first PDU session actually carries the transmission of the application traffic.

[0137] For example, the second network-side device may initiate a third verification when sending the target request information, or before or after sending the target request information, that is, to verify whether the first PDU session includes data packets of the target application. For example, the second network-side device may generate a packet detection rule based on the first URSP rule reported by the terminal, apply the packet detection rule to the first PDU session indicated by the first PDU session identifier, and obtain a third verification result. The packet detection rule is used to verify whether the first PDU session includes data packets of the target application, and then the third verification result is sent to the first network-side device.

[0138] In one possible implementation, after obtaining the second verification result in S214, if the second verification result is consistent with the second parameter described by the RSD in the first URSP rule, the first network-side device may send a request to the second network-side device to request the third verification result, thereby obtaining the third verification result from the second network-side device. The request information may include the first URSP rule and / or the first PDU session identifier. The second network-side device generates a Packet Inspection Rule (PDR) based on the first URSP rule and applies the PDR to the first PDU session corresponding to the first PDU session identifier to perform packet inspection.

[0139] In another possible implementation, the second network-side device may not actively perform the third verification, but instead execute it only upon receiving a request from the first network-side device. Therefore, in this possible implementation, the first network-side device may send a request to the second network-side device, requesting the second network-side device to perform the third verification, that is, requesting the second network-side device to verify whether the first PDU session includes data packets of the target application, and then receive the third verification result returned by the second network-side device. In other words, the second network-side device first waits for the first network-side device to complete the second verification. If the verification indicates that the terminal's second verification is successful and the URSP rules are correctly used, the second network-side device receives the relevant request information from the first network-side device and performs the third verification.

[0140] In the above possible implementations, the first network-side device may initiate third verification if the first parameter of the first PDU session is consistent with the second parameter described by the RSD in the first URSP rule, that is, request the second network-side device to perform third verification. If at least one of the first parameters of the first PDU session is inconsistent with the second parameter described by the RSD in the first URSP rule, the verification of the URSP rule shall be terminated.

[0141] In one possible implementation, the method may further include: the first network-side device sending a second indication message in any of the following situations, wherein the second indication message is used to indicate that the terminal has not correctly used the URSP rules:

[0142] (1) The first verification result indicates that the first URSP rule is inconsistent with the second URSP rule; that is, when the first URSP rule is inconsistent with the second URSP rule, the first network-side device determines that the terminal has not used the URSP rule correctly.

[0143] (2) The second verification result indicates that the first parameter is inconsistent with the second parameter; that is, if at least one of the first parameters is inconsistent with the second parameter, the first network-side device determines that the terminal has not correctly used the URSP rules.

[0144] (3) The third verification result indicates that the first PDU session does not include data packets of the target application. That is, if the data packets of the target application are not included in the transmission data packets corresponding to the first PDU session, the first network-side device determines that the terminal has not correctly used the URSP rules.

[0145] One possible way to send the second indication information is that the first network-side device sends it directly to the second network-side device; or the first network-side device sends it to the second network-side device through a third or fourth network-side device.

[0146] For example, taking AM-PCF as the first network-side device and SMF as the second network-side device, AM-PCF can use at least one of the following signaling methods to send the second indication information to SMF: Npcf_EventExposure_Notify, Npcf_UEPolicyControl Update response.

[0147] Alternatively, the AM-PCF can send the second indication information to the AMF using at least one of the following signaling methods: Npcf_UEPolicyControl_Update response; Npcf_UEPolicyControl_UpdateNotify notify. Then, the AMF can send the second indication information to the SMF using at least one of the following signaling methods: Nsmf_PDUSession_UpdateSMContextrequest; Nsmf_EventExposure_Subscribe.

[0148] Alternatively, the AM-PCF may use at least one of the following signaling methods to send the second instruction information to the SM-PCF: Npcf_Policy Authorization_Create request / response, Npcf_Policy Authorization_Update request / response. The SM-PCF then uses at least one of the following signaling methods to send the second instruction information to the SMF: Npcf_SMPolicyControl_Update request / response, Npcf_SMPolicyControl_create request / response.

[0149] After receiving the second indication information, the second network-side device can perform corresponding operations, such as rejecting the session establishment request or modification request corresponding to the first PDU session identifier, or releasing the first PDU session corresponding to the first PDU session identifier. Rejecting the session establishment request or modification request means rejecting the PDU session establishment request or modification request from the terminal that reported the first URSP rule. Alternatively, if the terminal misused the URSP rule, the PDU session carrying this application will be released. Or, before releasing the PDU session, the network side triggers the establishment of a new PDU session according to the PDU session parameters indicated by the RSD in the first URSP rule, migrates the application traffic to the new PDU session, and then releases the original session.

[0150] In one possible implementation, the method may further include: the first network-side device updating the URSP rules of the terminal in any of the following situations:

[0151] (1) The first verification result indicates that the first URSP rule is inconsistent with the second URSP rule;

[0152] (2) The second verification result indicates that at least one of the first parameters is inconsistent with the second parameter;

[0153] (3) The third verification result indicates that the data packets transmitted in the first PDU session do not include the data packets of the target application.

[0154] In any of the above situations, if the first network-side device determines that the terminal is not using the URSP rules correctly, it can update the terminal's URSP rules, for example, by re-executing the terminal's URSP policy and sending it back to the terminal. This situation means that if the terminal is not using the rules correctly, it may be due to unreasonable rule design, therefore the first network-side device needs to update the terminal's URSP rules.

[0155] Figure 3 This diagram illustrates another flowchart of the URSP rule verification method in an embodiment of this application. This method 300 can be executed by a second network-side device. In other words, the method can be executed by software or hardware installed on the second network-side device. In this embodiment, the second network-side device can be a session management network element, for example, a Session Management Function (SMF). Figure 3 As shown, the method may include the following steps.

[0156] S310, the second network-side device receives the reporting information sent by the terminal, wherein the reporting information includes: the first URSP rule used by the terminal for the target application and the first PDU session identifier carrying the target application, the first PDU session identifier being used to indicate the first PDU session.

[0157] For example, the terminal can send the reported information via an uplink NAS message. For example, the terminal uses URSP rules to match traffic of a target application to a PDU session, or uses the RSD in the matched URSP rules to establish a new PDU session, and the terminal reports the matched URSP rules (including RSD and / or TD) and the PDU session identifier indicating the PDU session.

[0158] S312, the second network-side device obtains the first parameter of the first PDU session.

[0159] Optionally, the first parameter includes at least one of the following: PDU session type, PDU session access type, SSC mode, network slice identifier, and DNN. The second network-side device can directly find the session parameters of the PDU session corresponding to the first PDU session identifier, which is the first parameter.

[0160] S314, the second network-side device sends target request information to the first network-side device, wherein the target request information instructs the first network-side device to verify whether the terminal correctly uses the URSP rule, and the target request information includes the first URSP rule and the first parameter of the first PDU session.

[0161] The method by which the second network-side device sends the target request information can be found in the description of method 200 above, and will not be repeated here.

[0162] In this embodiment of the application, the target request information is used to request the first network-side device to verify whether the first URSP rule used by the terminal is consistent with at least one second URSP rule sent to the terminal by the first terminal-side device, and to verify whether the first parameter of the first PDU session is consistent with the second parameter described by the RSD in the first URSP rule, so that the first network-side device can know the usage of the terminal's URSP rules and control the terminal.

[0163] In this embodiment, the first URSP rule executed by the terminal sent by the second network-side device can be a first URSP rule used by the terminal for traffic of a certain application (e.g., application provider A). The first URSP rule sent by the second network-side device can be the traffic descriptor and the RSD used in the first URSP rule. The first URSP rule can be contained in a container and sent to the first network side, the container carrying the traffic descriptor and RSD executed by the terminal, or the container carrying the priority of the traffic descriptor and the priority of the RSD.

[0164] Another piece of information in the target request information is the first parameter of the first PDU session carrying the target application. When the terminal performs target application traffic matching to a PDU session, the terminal can report the PDU sessionID to which the traffic is matched. Then, the second network-side device can also send the attribute parameters of the first PDU session corresponding to the PDU session ID to the first network-side device. These attribute parameters include, but are not limited to, at least one of the following: SSC mode, Access type, DNN, S-NSSAI, and PDU session type.

[0165] In one possible implementation, the second network-side device may be unaware of the first network-side device that sends URSP rules to the terminal. Therefore, in one possible implementation, before S310, the method may further include: the second network-side device obtaining the identifier of the first network-side device. The identifier of the first network-side device includes, but is not limited to, one of the following: the identifier of the first network-side device or the IP address of the first network-side device.

[0166] In this embodiment of the application, the second network-side device obtains the identifier of the first network-side device in any one of the following methods one to four.

[0167] Method 1: The second network-side device receives a second request message sent by the third network-side device, wherein the second request message is used to request the establishment or update of the context of the first PDU session, and the second request message carries a target identifier, which is used to indicate the first network-side device that provides services to the terminal.

[0168] For example, when the first network-side device sends URSP rules to the terminal, it may instruct the third network-side device to send the identifier of the first network-side device to the second network-side device when it receives a PDU session establishment request or a PDU session modification request from the terminal. Then, when the third network-side device receives a PDU session establishment request or a PDU session modification request from the terminal, it may send the second request information to the second network-side device.

[0169] For example, when the first network-side device (e.g., AM-PCF) sends URSP rules to the terminal, it may use the Namf_Communication_N1N2MessageTransfer signaling to send the URSP rules to the terminal. This signaling is then sent to the third network-side device (e.g., AMF) (the first network-side device sends the URSP rules to the UE through the third network-side device). This signaling may also instruct that when the third network-side device subsequently receives a PDU session establishment request or modification request from this terminal (indicated by the UE identifier SUPI), the third network-side device will send the identifier of the first network-side device (e.g., AM-PCFID) to the second network-side device (e.g., SMF). For example, the third network-side device may send the identifier of the first network-side device to the second network-side device using the following signaling: Nsmf_PDUSession_CreateSMContext Request or Nsmf_PDUSession_UpdateSMContext Request.

[0170] Taking AM-PCF as the first network-side device, SMF as the second network-side device, and AMF as the third network-side device as an example, Figure 4 This invention illustrates a flowchart of a method for obtaining the identifier of a first network-side device according to an embodiment of this application. Figure 4 As shown, the method 400 mainly includes the following steps.

[0171] S401: The terminal sends a Registration Request to the Radio Access Network (RAN). The terminal may include in the Registration Request information regarding its support for reporting internal URSP rules (URSP enforcement).

[0172] The terminal can support reporting via NAS messages or via DCAF.

[0173] S402: The RAN forwards the terminal's registration request to the AMF.

[0174] The RAN can add some terminal location information before forwarding the registration request, which does not affect the terminal capability indication. Therefore, it can also be regarded as the UE directly sending the registration request to the AMF.

[0175] S403: AMF is selected as AM-PCF.

[0176] S404: AMF triggers the UE's policy association establishment process or the UE's policy association modification process.

[0177] For example, the AMF sends a signaling message: Npcf_UEPolicyControl Create Request, or Npcf_UEPolicyControl Update Request, which may carry the terminal's capability information. This capability information refers to the URSP rules that the terminal supports reporting.

[0178] S405: After the AM-PCF receives the signaling, it sends a response to the AMF.

[0179] S406: The AM-PCF decides to send a terminal policy (UEpolicy) to the UE. Simultaneously, if the AM-PCF discovers that the terminal supports reporting URSP rule execution status, then while sending the UEpolicy to the UE, the AM-PCF also instructs the AMF to send its AM-PCF ID to the SMF when it receives a PDU session establishment request or PDU session modification request from the terminal. The SMF is used to manage the terminal's PDU sessions.

[0180] The AM-PCF can instruct the AMF via the signaling Namf_Communication_N1N2MessageTransfer, which may include an instruction that when the terminal (which may be identified by the SUPI identifier) ​​sends a PDU session establishment request or a PDU session modification request, the AMF needs to forward the UE's AM-PCFID to the SMF and / or SM-PCF.

[0181] S407: The UE receives the UE policy sent by AM-PCF.

[0182] S408: The terminal establishes a PDU session and sends a PDU session establishment request or a PDU session modification request to the AMF.

[0183] S409: The AMF triggers a context establishment in the SMF by sending a request to the SMF to establish or update the context of the PDU session. This request may carry the AM-PCF ID.

[0184] For example, the AMF can send the signaling: Nsmf_PDUSession_CreateSMContext Request, or Nsmf_PDUSession_UpdateSMContext Request, which carries the AM-PCFID.

[0185] In this embodiment of the application, the AMF carries the AM-PCF ID to the SMF for the purpose of verifying or monitoring the execution of URSP rules. This is because the verification or monitoring of the execution of specific URSP rules needs to be completed by the AM-PCF. After the SMF receives the URSP rules actually reported by the UE from the terminal, it also needs to send them to the AM-PCF for verification. At this time, if the AMF directly provides the AM-PCF ID that serves the terminal, the process of the SMF looking up the AM-PCF can be saved.

[0186] S410: The SMF sends the AM-PCFID to the SM-PCF through the Session Management Association Establishment (SMpolicyAssociationestablishment) or Session Management Association Modification (SMpolicyAssociationmodification) process. For example, the SMF can send signaling carrying the AM-PCFID to the SM-PCF: Npcf_SMPolicyControl_Create or Npcf_SMPolicyControl_Update.

[0187] Since the SMF may communicate with the AM-PCF via the SM-PCF in the future, after obtaining the AM-PCF ID, the SMF can execute S410 to send the AM-PCF ID to the AM-PCF.

[0188] Method 2: The second network-side device sends a third request message to the third network-side device, wherein the third request message carries the identifier of the terminal, and the third request is used to obtain the context information of the terminal; the second network-side device receives the context information of the terminal returned by the third network-side device, and obtains the identifier of the first network-side device from the context information of the terminal.

[0189] The first network-side device (e.g., AM-PCF) exists as a configuration for each terminal (per UE), and the identifier of the first network-side device is primarily stored in the UE context stored by the third network-side device (e.g., AMF). Therefore, the identifier of the first network-side device can be obtained by requesting the terminal's context information from the third network-side device.

[0190] Taking AM-PCF as the first network-side device, SMF as the second network-side device, and AMF as the third network-side device as an example, Figure 5 This illustrates another flowchart of a method for obtaining the identifier of the first network-side device in an embodiment of this application, as shown below. Figure 5 As shown, the method 500 mainly includes the following steps.

[0191] S501: The SMF sends a request to the AMF to obtain the UE context from the AMF.

[0192] The signaling sent by the SMF can be: Namf_Communication_UEContextTransferRequest, or other signaling, which may carry the terminal identifier, such as UE SUPI.

[0193] S502: AMF sends UE context to SMF.

[0194] The signaling sent by the AMF can be Namf_Communication_UEContextTransferresponse or other signaling, and the signaling carries the UE context. The UE context mainly stores information related to the terminal's network access and information related to the terminal's PDU session.

[0195] S503: The SMF obtains the AM-PCF ID from the received UE context. The UE context contains a lot of information, from which the SMF can find the AM-PCF ID of the serving terminal.

[0196] Method 3: The second network-side device sends a fourth request message to the third network-side device, wherein the fourth request message is used to request the identification of the first network-side device that sends URSP rules to the terminal, and the fourth request message carries the identification of the terminal; the second network-side device receives the identification of the first network-side device returned by the third network-side device.

[0197] The first network-side device (e.g., AM-PCF) exists as a configuration for each terminal (per UE), and the identifier of the first network-side device is primarily stored in the UE context stored by the third network-side device (e.g., AMF). Therefore, the second network-side device can directly request the identifier of the first network-side device from the third network-side device. Thus, in this possible implementation, the second network-side device obtains the identifier of the first network-side device by sending a fourth request message to the third network-side device.

[0198] Taking AM-PCF as the first network-side device, SMF as the second network-side device, and AMF as the third network-side device as an example, Figure 6 This illustrates another flowchart of a method for obtaining the identifier of the first network-side device in an embodiment of this application, such as... Figure 6 As shown, the method 600 mainly includes the following steps.

[0199] S601: SMF sends a request to AMF to obtain the AM-PCF ID from AMF.

[0200] The signaling sent by the SMF can be: Namf_Communication_N1MessageNotify Subscribe, or Namf_Communication_N1N2MessageSubscribe, or other signaling. This signaling can carry the terminal's identifier (e.g., UE SUPI) and an indication that the subscribed information is an AM-PCF ID.

[0201] S602: AMF sends AM-PCF ID.

[0202] The signaling sent by the AMF can be at least one of the following: Namf_Communication_N1MessageNotify Notify, Namf_Communication_N1N2MessageTransfer, Namf_Communication_N1N2MessageNotify, or other signaling, which carries the AM-PCF ID corresponding to the terminal's identifier.

[0203] Method 4: The second network-side device sends a fifth request message to the fifth network-side device, wherein the fifth request message is used to obtain the identifier of the first network-side device that sent the URSP rules to the terminal, and the fifth request message carries the identifier of the terminal; and obtains the identifier of the first network-side device returned by the fifth network-side device. This is because the fifth network-side device stores the subscription information of each terminal, and the AM-PCFID is a type of subscription information.

[0204] The identifier of the first network-side device corresponding to the terminal can be stored in the fifth network-side device (e.g., UDM) as the terminal's subscription information. Therefore, in one possible implementation, the second network-side device can obtain the identifier of the first network-side device by sending a fifth request message to the fifth network-side device.

[0205] Taking AM-PCF as the first network-side device, SMF as the second network-side device, and UDM as the fifth network-side device as an example, Figure 7 This illustrates another flowchart of a method for obtaining the identifier of the first network-side device in an embodiment of this application, such as... Figure 7 As shown, the method 700 mainly includes the following steps.

[0206] S701: AMF or AM-PCF registers with UDM and becomes contract information, which UDM stores.

[0207] For example, the AMF or AM-PCF can send the signaling: Nudm_UECM_Registration or Nudm_UECM_Update, which carries the UE SUPI and AM-PCF ID.

[0208] The AM-PCF ID can be stored in the UDM. For example, the AM-PCF ID can be stored as access and mobility subscription data, which can only be obtained through SUPI.

[0209] S702: UDM returns a response indicating that the registration request has been received.

[0210] S703: The SMF needs to obtain the AM-PCF ID for serving the UE from the UDM and send a subscription request to the UDM.

[0211] For example, SMF can send the signaling: Nudm_SDM_Get or Nudm_SDM_Subscribe, which carries the following information: requesting subscription data of type Access and Mobility Subscription data, with data key SUPI.

[0212] S704: UDM returns a response that is a response to the subscription request sent by SMF, indicating that the subscription has been received.

[0213] S705: UDM sends AM-PCF ID to SMF via notify signaling.

[0214] For example, the UDM can send a signaling message: Nudm_SDM_Get Response, or Nudm_SDM_Notification, which carries the AM-PCF ID.

[0215] In one possible implementation, after S312, the method may further include the following steps:

[0216] Step 1: The second network-side device obtains the first URSP rule sent by the first network-side device.

[0217] For example, after obtaining the second verification result, if the second verification result indicates that the first parameter of the first PDU session is consistent with the second parameter described by the RSD of the first URSP rule, the first network-side device may send a request message to the second network-side device. The request message includes the first URSP rule and requests the second network-side device to verify whether the first PDU session includes data packets of the target application.

[0218] Step 2: The second network-side device generates a packet detection rule according to the first URSP rule, applies the packet detection rule to the first PDU session indicated by the first PDU session identifier, and obtains a third verification result. The packet detection rule is used to verify whether the first PDU session includes data packets of the target application.

[0219] For example, a second network-side device (e.g., SMF) can generate packet detection rules based on traffic descriptors, such as IP descriptors, in the first URSP rule sent by the first network-side device (e.g., AM-PCF). Alternatively, the second network-side device (e.g., SMF) can convert traffic descriptors, such as domain name descriptors (FQDN), DNN, etc., in the first URSP rule sent by the first network-side device (e.g., AM-PCF), into IP descriptors, and then generate the packet detection rules. Since the packet detection rules only contain IP 5-tuples, and in the first URSP rule, only IP descriptors can be directly used to generate packet detection rules; other descriptors, such as APP descriptors, domain name descriptors, DNNs, and connection capabilities, cannot be directly used to generate packet detection rules (PDR), the SMF has the capability to convert APP descriptors, domain name descriptors, DNNs, and connection capabilities into IP 5-tuples or IP descriptors, and then directly use the converted IP descriptors to generate PDRs. Another approach is that the 5G core network (5GC) (e.g., AMF, AM-PCF, SM-PCF, etc.) has the ability to convert the APP descriptor, domain name descriptor, DNN, connectivity and other descriptors into IP quintuples or IP descriptors.

[0220] Step 3: The second network-side device sends the third verification result to the first network-side device.

[0221] In one possible implementation, the method may further include the following steps:

[0222] Step 1: The second network-side device obtains the second indication information sent by the first network-side device, wherein the second indication information is used to indicate that the terminal has not correctly used the URSP rules;

[0223] Step 2: The second network-side device rejects the session establishment request or session modification request corresponding to the first PDU session identifier, or the second network-side device releases the PDU session corresponding to the first PDU session identifier.

[0224] Specifically, rejecting the session establishment or modification request means rejecting the PDU session establishment or modification request of the terminal that reported the first URSP rule. Alternatively, if the terminal misused the URSP rule, the PDU session carrying this application will be released. Or, before releasing the PDU session, the network side triggers the establishment of a new PDU session according to the PDU session parameters indicated by the RSD in the first URSP rule, migrates the application traffic to the new PDU session, and then releases the original session.

[0225] The terminal's failure to correctly use URSP rules includes one of the following:

[0226] (1) The first URSP rule is inconsistent with the second URSP rule. The second URSP rule is at least one URSP rule corresponding to the target application sent by the first network-side device to the terminal. For example, the first network-side device can obtain the first verification result through the above S210 and S212. If the first verification result indicates that the first URSP rule is inconsistent with the second URSP rule, the first network-side device sends the second indication information to the second network-side device.

[0227] (2) At least one of the first parameters is inconsistent with the second parameter. For example, the first network-side device may send the second indication information to the second network-side device if it verifies that at least one of the first parameters of the first PDU session obtained from the second network-side device is inconsistent with the second parameter described by the RSD in the first URSP rule. Alternatively, the first network-side device may receive a second verification result sent by the second network-side device, and send the second indication information to the second network-side device if the second verification result indicates that at least one of the first parameters is inconsistent with the second parameter.

[0228] (3) The first PDU session does not include data packets of the target application. For example, the first network-side device receives a third verification result sent by the second network-side device, and if the third verification result indicates that the first PDU session does not include data packets of the target application, the first network-side device sends the second indication information to the second network-side device.

[0229] In the above possible implementations, after receiving the second indication information, the second network-side device rejects the session establishment request or session modification request corresponding to the first PDU session identifier, or the second network-side device releases the first PDU session corresponding to the first PDU session identifier. For example, if the first PDU session corresponding to the first PDU session identifier has not been established, the session establishment request to establish the first PDU session is rejected after receiving the second indication information. Alternatively, if the first PDU session corresponding to the first PDU session identifier has been established, the first PDU session corresponding to the first PDU session identifier is released after receiving the second indication information. This avoids the terminal using a PDU session that does not comply with the URSP rule indication to transmit data streams. Rejecting a session establishment request or session modification request means rejecting the PDU session establishment request or modification request of the terminal that reported the first URSP rule. Alternatively, if the terminal misuses the URSP rule, the PDU session carrying this application will be released. Or, before releasing the PDU session, the network side triggers the establishment of a new PDU session according to the PDU session parameters indicated by the RSD in the first URSP rule, migrates the application traffic to be carried on the new PDU session, and then releases the original session.

[0230] For example, if the terminal fails to correctly use the URSP rules after the second network-side device (SMF) receives the first instruction, the second network-side device shall perform at least one of the following:

[0231] 1. Send a PDU session establishment rejection message to the terminal (which can be forwarded to the terminal via AMF);

[0232] 2. Send PDU session modification rejection to the terminal (can be forwarded to the terminal via AMF);

[0233] 3. The second network device triggers the PDU session release process to release the first PDU session corresponding to the first PDU session identifier;

[0234] 4. The second network device triggers a PDU session modification command (PDUsessionmodificationcommand) to the terminal (which can be forwarded to the terminal via AMF); then, the terminal triggers a PDU session establishment request (PDUsessionestablishmentrequest) to the second network device (the session establishment request can be forwarded via AMF). In this embodiment, because the first URSP rule is not used correctly, the second network device requests the terminal to modify the session. After accepting the request, the terminal establishes a new PDU session and then switches the services carried in the first PDU session to the newly created PDU session. Finally, the terminal or the second network device releases the first PDU session.

[0235] In this embodiment, the first network-side device and the second network-side device can directly transmit information. For example, the second network-side device can first obtain the identifier of the first network-side device and then directly transmit information with the first network-side device. Alternatively, the first network-side device and the second network-side device can also transmit information through a third network-side device. For example, the first network-side device and the second network-side device can transmit information through a session management policy control network element (e.g., a session management policy control function (SM-PCF)). When transmitting information through SM-PCF, SM-PCF can employ the methods described above. Figures 4 to 7 The AM-PCF ID is obtained through the SMF. Alternatively, the first network-side device and the second network-side device transmit information through an Access and Mobility Management (AMF) element (e.g., an Access and Mobility Management Function).

[0236] Figure 8 This diagram illustrates another flowchart of the URSP rule verification method provided in this application embodiment. This method 800 can be executed by the aforementioned third network-side device; in other words, this method 800 can be executed by software or hardware installed on the third network-side device. In this application embodiment, the third network-side device can be a session management policy control network element, such as an SM-PCF, or it can be an access and mobility management network element, such as an AMF. Figure 8 As shown, the method may include the following steps.

[0237] S810, the third network-side device receives target request information sent by the second network-side device, wherein the target request information instructs the first network-side device to verify whether the terminal correctly uses the URSP rule, and the target request information includes the first URSP rule and the first parameter of the first PDU session.

[0238] The target request information is the same as the target request information in method 200 and method 300, and can be specifically described in the parameters of method 200 and method 300.

[0239] The second network-side device can send the target request information in the manner described in method 300, as specifically described in the relevant parameters of method 300.

[0240] S812, the third network-side device sends the target request information to the first network-side device.

[0241] In one possible implementation, prior to S810, the method may also include:

[0242] Step 1: The third network-side device receives first indication information sent by the first network-side device, wherein the first indication information instructs the third network-side device to send the identifier of the first network-side device to the second network-side device after receiving a PDU session establishment request or a PDU session modification request sent by the terminal.

[0243] The first network-side device may send the first indication information in the manner described in the above embodiments. For details, please refer to the description in the above embodiments, which will not be repeated here.

[0244] Step 2: The third network-side device receives a PDU session establishment request or a PDU session modification request sent by the terminal, wherein the PDU session establishment request message or the PDU session modification request is used to request the establishment or modification of the first PDU session.

[0245] Step 3, the third network-side device sends a second request message to the second network-side device, wherein the second request message is used to request the establishment or update of the context of the first PDU session, and the second request message carries a target identifier, which is used to indicate the first network-side device that provides services to the terminal.

[0246] In the above possible implementations, the third network-side device (e.g., AMF) can receive a first indication message sent by the first network-side device when the first network-side device sends URSP rules to the terminal. This first indication message instructs the third network-side device to send its identifier to the second network-side device upon receiving a PDU session establishment request or PDU session modification request from the terminal. Then, after receiving the PDU session establishment request or PDU session modification request from the terminal, the third network-side device can send a second request message to the second network-side device. This second request message requests the establishment or update of the context of the first PDU session, sending the identifier of the first network-side device providing services to the terminal to the second network-side device. For example, when the third network-side device is an AMF, the AMF can... Figure 4 The method shown provides the AM-PCF ID to the SMF.

[0247] In one possible implementation, prior to S810, the method may also include the following steps:

[0248] Step 1: The third network-side device receives a third request message sent by the second network-side device, wherein the third request message carries the identifier of the terminal, and the third request is used to obtain the context information of the terminal;

[0249] Step 2: The third network-side device sends the context information of the terminal to the second network-side device, wherein the context information includes the identifier of the first network-side device.

[0250] For example, when the third network-side device is an AMF, the AMF can follow... Figure 5 The method shown provides the AM-PCF ID to the SMF.

[0251] In one possible implementation, prior to S810, the method may also include the following steps:

[0252] Step 1: The third network-side device receives a fourth request message sent by the second network-side device, wherein the fourth request message is used to request the identification of the first network-side device that sends URSP rules to the terminal, and the fourth request message carries the identification of the terminal.

[0253] Step 2: The third network-side device sends the identifier of the first network-side device corresponding to the identifier of the terminal to the second network-side device.

[0254] For example, when the third network-side device is an AMF, the AMF can follow... Figure 6The method shown provides the AM-PCF ID to the SMF.

[0255] In this embodiment of the application, the third network-side device may also transmit the first URSP rule, the second indication information, and the third verification result transmitted between the first network-side device and the second network-side device.

[0256] The first network-side device can send the request information through signaling exchanged with the third network-side device. For example, the signaling exchange between the AM-PCF and the AMF includes: the AM-PCF sending the request information via Namf_CommunicationN1MessageNotify_Subscribe; or the AM-PCF sending the request information via at least one of the following: Npcf_UEPolicyControl_Update response or Npcf_UEPolicyControl_UpdateNotifynotify; or other signaling defined between the AM-PCF and the AMF.

[0257] The following describes the URSP rule verification method provided in this application embodiment, taking AM-PCF as the first network-side device and SMF as the second network-side device as an example.

[0258] Figure 9 This illustrates another flowchart of the URSP rule verification method provided in an embodiment of this application, as shown below. Figure 9 As shown, the method 900 mainly includes the following steps:

[0259] S901: SMF sends a request message to AM-PCF.

[0260] The request information sent by SMF to AM-PCF includes:

[0261] (1) URSP rules reported by the terminal and executed by the terminal.

[0262] For example, the URSP rules used by the terminal for traffic of a certain application (such as application provider A). This includes the TrafficDescriptor and the RSD used. This information can be contained in a container carrying the UESUPI, the TrafficDescriptor executed by the terminal, and the RSD; another approach is to include the priority of the TrafficDescriptor and the priority of the RSD in the container.

[0263] For example, a URSP rule was executed for traffic from terminal APP1:

[0264] Rule Precedence = 1

[0265] Traffic Descriptor:Application descriptor=App1

[0266] Route Selection Descriptor Precedence=1

[0267] Network Slice Selection:S-NSSAI-a

[0268] SSC Mode Selection: SSC Mode 3

[0269] DNN Selection: Internet

[0270] Access Type preference:3GPP access

[0271] The execution result from the terminal can be sent in the following two ways:

[0272] Method 1: Send Rule Precedence=1 and Route Selection Descriptor Precedence=1.

[0273] The second method: Send the specific TD and RSD to be executed, including:

[0274] Traffic Descriptor:Application descriptor=App1

[0275] RSD 1:

[0276] Network Slice Selection:S-NSSAI-a

[0277] SSC Mode Selection: SSC Mode 3

[0278] DNN Selection: Internet

[0279] Access Type preference:3GPP access

[0280] (2) Attribute parameters corresponding to the PDU session ID. When the terminal executes application traffic and matches a PDU session, the terminal can report the PDU session ID to which the traffic was matched. Then, the SMF can also send the attribute parameters corresponding to the PDU session ID to the AM-PCF. The attribute parameters corresponding to the PDU session ID include, but are not limited to, at least one of the following: SSCmode, Accesstype, DNN, S-NSSAI, PDU sessiontype

[0281] S902: AM-PCF verifies whether the terminal has correctly used the URSP rules.

[0282] Specifically, AM-PCF can perform the following steps:

[0283] Step 1: Based on the URSP rules reported by the UE, such as TD priority, RSD priority, and parameters for restoring RSD, compare them with the RSD reported by the terminal itself. If they are different, it is considered that the terminal has not used the URSP rules correctly. If they are the same, proceed to Step 2.

[0284] Step 2: AM-PCF obtains the parameters described by the RSD in the URSP rule reported by the terminal, and compares these parameters with the parameters of the PDUsession carrying the APPtraffic fed back by SMF. If the parameters are the same, the terminal is considered to be using it correctly; otherwise, the terminal is considered to be not using the URSP rule correctly.

[0285] For example, the URSP rules used by the terminal itself, such as Rule Precedence=1 and RouteSelection Descriptor Precedence=1;

[0286] Based on this information, AM-PCF can obtain the actual URSP rules sent to the UE as follows:

[0287] Rule Precedence = 1

[0288] Traffic Descriptor:Application descriptor=App1

[0289] Route Selection Descriptor Precedence=1

[0290] Network Slice Selection:S-NSSAI-a

[0291] SSC Mode Selection: SSC Mode 3

[0292] DNN Selection: Internet

[0293] Access Type preference:3GPP access

[0294] The terminal itself reported the following URSP rule it was using:

[0295] Rule Precedence = 1

[0296] Traffic Descriptor:Application descriptor=App1

[0297] Route Selection Descriptor Precedence=1

[0298] Network Slice Selection:S-NSSAI-a

[0299] SSC Mode Selection: SSC Mode 3

[0300] DNN Selection: Internet

[0301] Access Type preference:3GPP access

[0302] If AM-PCF finds that the usage rules reported by the terminal are the same as the rules actually sent by AM-PCF to the UE, then the first step of verification is passed, and the rules reported by the UE are correct.

[0303] The second step is for AM-PCF to compare the RSD parameters in the rules actually sent to the UE with the parameters of the PDU session carrying the traffic fed back by SMF.

[0304] For example, SMF or SM-PCF, after checking the PDU session that actually carries this application traffic, the parameters of that session are:

[0305] Network Slice Selection:S-NSSAI-b

[0306] SSC Mode Selection: SSC Mode 3

[0307] DNN Selection: Internet

[0308] Access Type preference:3GPP access

[0309] SM-PCF determined that the two slices used were different, therefore, it was determined that the terminal was not using the URSP rules correctly.

[0310] In other words, although the terminal reports the URSP rules it uses, the APP's traffic does not actually use the PDU session bearer corresponding to this RSD.

[0311] S903: AM-PCF sends the result of URSP rule execution verification.

[0312] This result may include:

[0313] (1) ACK: Indicates that the terminal has correctly used the URSP rule. Then, the AM-PCF can also instruct the SMF to perform a third verification, namely the packet inspection process. Here, ACK can indicate that both the first and second verifications have passed, or it can indicate that any one verification, such as the first or second verification, has passed.

[0314] (2) NACK: Negative response, indicating that either of the two verifications failed.

[0315] Based on the AM-PCF's verification result of the terminal's URSP rule usage, the SMF or SM-PCF can perform corresponding operations. For example, the SMF may reject the session establishment request corresponding to the PDU session ID; or, the SMF may release the PDU session corresponding to the PDU session ID; or, the SMF may first establish a new PDU session, then migrate the APP traffic to the newly established PDU session, and then release the old PDU session corresponding to the PDU session ID.

[0316] Figure 10 This illustrates another flowchart of the URSP rule verification method provided in an embodiment of this application, as shown below. Figure 10 As shown, the method 1000 mainly includes the following steps:

[0317] S1001, SMF sends a request message to AMF, which requests AM-PCF to perform URSP rule verification.

[0318] The request information is the same as the request information in S1001 of method 1000. For details, please refer to the relevant description of method 1000.

[0319] S1002, the AMF finds the corresponding AM-PCF based on the terminal's identifier and forwards the request information to the AM-PCF.

[0320] S1003, AM-PCF verifies whether the terminal has correctly used the URSP rules.

[0321] This step is the same as S902 in method 900, and you can refer to the relevant description in method 900 for details.

[0322] S1004, AM-PCF sends the results of URSP rule execution verification to AMF.

[0323] The result of the URSP rule execution verification is the same as the result of the URSP rule execution verification in Method 900. For details, please refer to the relevant description in Method 900.

[0324] S1005, AMF sends the results of the URSP rule execution verification to SMF.

[0325] After receiving the results of the URSP rule execution verification, SMF can perform the corresponding operations.

[0326] Figure 11 This illustrates another flowchart of the URSP rule verification method provided in an embodiment of this application, as shown below. Figure 11 As shown, the method 1100 mainly includes the following steps:

[0327] S1101, SMF sends a request message to SM-PCF, requesting AM-PCF to perform URSP rule verification.

[0328] The request information is the same as the request information in S901 of method 900, and you can refer to the relevant description of method 900 for details.

[0329] S1102, SM-PCF forwards the request information to AM-PCF.

[0330] Among them, SM-PCF can adopt Figures 4 to 7 The AM-PCF ID is obtained using the same method as SMF.

[0331] S1103, AM-PCF verifies whether the terminal has correctly used the URSP rules.

[0332] This step is the same as S902 in method 900, and you can refer to the relevant description in method 900 for details.

[0333] S1104, AM-PCF sends the results of URSP rule execution verification to SM-PCF.

[0334] The result of the URSP rule execution verification is the same as the result of the URSP rule execution verification in Method 900. For details, please refer to the relevant description in Method 900.

[0335] S1105, SM-PCF sends the results of URSP rule execution verification to SMF.

[0336] After receiving the results of the URSP rule execution verification, SMF can perform the corresponding operations.

[0337] Figure 12 This illustrates another flowchart of the URSP rule verification method provided in an embodiment of this application, as shown below. Figure 12 As shown, the method 1200 mainly includes the following steps:

[0338] S1201, SMF sends a request message to SM-PCF, requesting AM-PCF to perform URSP rule verification.

[0339] The request information is the same as the request information in S901 of method 900, and you can refer to the relevant description of method 900 for details.

[0340] S1202, SM-PCF forwards the request information to AMF.

[0341] S1203, AMF forwards the request information to AM-PCF.

[0342] S1204, AM-PCF verifies whether the terminal has correctly used the URSP rules.

[0343] This step is the same as S902 in method 900, and you can refer to the relevant description in method 900 for details.

[0344] S1205, AM-PCF sends the results of URSP rule execution verification to AMF.

[0345] The result of the URSP rule execution verification is the same as the result of the URSP rule execution verification in Method 900. For details, please refer to the relevant description in Method 900.

[0346] S1206, AMF sends the results of the URSP rule execution verification to SM-PCF.

[0347] S1207, SM-PCF sends the results of URSP rule execution verification to SMF.

[0348] After receiving the results of the URSP rule execution verification, SMF can perform the corresponding operations.

[0349] Figure 13This illustrates another flowchart of the URSP rule verification method provided in an embodiment of this application, as shown below. Figure 13 As shown, the method 1300 mainly includes the following steps:

[0350] S1301, the terminal uses URSP rules to match the APP's process to the PDU session, or uses the RSD in the matched URSP rules to establish a new PDU session.

[0351] S1302, the terminal sends the URSP rules it uses, as well as the RSD and PDU session identifiers, to the AMF via an uplink NAS message.

[0352] S1303, AMF sends the URSP rules, RSD, and PDU session identifiers to SMF via an uplink NAS message.

[0353] S1304, the SMF obtains the AM-PCF corresponding to the terminal. For example, the SMF can... Figures 4 to 7 The method shown is used to obtain the AM-PCF ID corresponding to the terminal.

[0354] S1305, SMF sends a request message to AM-PCF, which includes the URSP rules executed by the terminal reported by the terminal and the PDU session parameters of the APP stream reported by the terminal.

[0355] AM-PCF performs the first and second verifications. If the verification fails, it executes S1306. If the verification succeeds, it triggers the third verification and executes S1306.

[0356] In S1306, the AM-PCF sends the verification result to the SMF, indicating that the verification failed. If the terminal does not use the URSP rules correctly, the intermediate process is skipped and S1314 is executed directly.

[0357] S1307, AM-PCF sends the URSP rules that need to be monitored to SMF. These URSP rules are used to generate packet inspection rules and may also include the terminal's SUPI and PDU session ID. This step can be performed after the first and second verifications have passed.

[0358] S1308, SMF converts TD into the required packet inspection rules (e.g., converting FQDN, application descriptor, etc. into destination IP triplet for packet inspection), and these packet inspection rules are used in the PDU session corresponding to the PDU session identifier.

[0359] S1309, SMF determines the UPF corresponding to the PDU session identifier of the terminal.

[0360] S1310, the SMF sends the packet inspection rules to the UPF. The SMF can also instruct the UPF to perform packet inspection within a specified time.

[0361] S1311, the UPF applies the packet detection rules to perform packet detection. If the APP's traffic packet is detected in the PDU session, it is determined that the PDU session includes the APP's traffic packet, and the verification passes; if the APP's traffic packet is not detected in the PDU session, the verification fails. At this time, the UPF can perform packet detection within the specified time indicated by the SMF.

[0362] S1312, the UPF sends a detection report to the SMF, providing feedback on the detection results. Specifically, it reports whether the target data packet was detected within the specified time. The detection result includes: detected or not detected.

[0363] S1313, within the predetermined time, the packet detection ends, and the SMF sends the packet detection result to the AM-PCF.

[0364] S1314, AM-PCF obtains the verification result of the URSP rules for the terminal. If the verification result indicates that the terminal has not used the URSP rules correctly, then S1315 is executed.

[0365] S1315, AM-PCF adjusts the URSP rules within the terminal based on the URSP rules reported by the terminal.

[0366] S1316, AM-PCF indicates SMF: Terminal is not using URSP rules correctly.

[0367] S1317, SMF rejects the request to establish the PDU session, releases the PDU session, or modifies the parameters of the PDU session.

[0368] Figure 14 This illustrates another flowchart of the URSP rule verification method provided in an embodiment of this application, as shown below. Figure 14 As shown, the method 1400 mainly includes the following steps:

[0369] S1401, the terminal uses URSP rules to match the APP's process to the PDU session, or uses the RSD in the matched URSP rules to establish a new PDU session.

[0370] S1402, the terminal sends the URSP rules it uses, as well as the RSD and PDU session identifiers, to the AMF via an uplink NAS message.

[0371] S1403, AMF sends the URSP rule, RSD, and PDU session identifiers to SMF via an uplink NAS message.

[0372] S1404, the SMF obtains the AM-PCF corresponding to the terminal. For example, the SMF can... Figures 4 to 7 The method shown is used to obtain the AM-PCF ID corresponding to the terminal.

[0373] S1405, SMF sends a request message to SM-PCF, which includes the URSP rules executed by the terminal reported by the terminal and the PDU session parameters where the APP stream is located reported by the terminal.

[0374] S1406, SM-PCF forwards the request information to AM-PCF to send the request information.

[0375] S1407, AM-PCF performs the first and second verifications. If the verification fails, S1408 is executed. If the verification succeeds, the third verification is triggered and S1409 is executed.

[0376] S1408, AM-PCF sends the verification result to SM-PCF, indicating that the verification failed and the terminal did not use the URSP rules correctly.

[0377] S1409, SM-PCF sends the verification result to SMF, indicating that the verification failed and the terminal did not use the URSP rules correctly, and then executes S1419.

[0378] S1410, AM-PCF sends the URSP rules that need to be monitored to SM-PCF. These URSP rules are used to generate packet inspection rules and may also include the terminal's SUPI and PDU session ID.

[0379] S1411, SM-PCF sends the URSP rules that need to be monitored to SMF. The URSP rules are used to generate packet detection rules and may also include the terminal's SUPI and PDU session ID.

[0380] S1412, SMF converts TD into the necessary packet inspection rules (e.g., converting FQDN, application descriptor, etc. into destination IP triples for packet inspection), and these packet inspection rules are performed in the PDU session corresponding to the PDU session identifier.

[0381] S1413, SMF determines the UPF corresponding to the PDU session identifier of the terminal.

[0382] In S1414, the SMF sends the packet inspection rules to the UPF. The SMF can also instruct the UPF to perform packet inspection within a specified time.

[0383] S1415, the UPF applies the packet detection rules to perform packet detection. If the APP's traffic packets are detected in the PDU session, it is determined that the PDU session includes the APP's traffic packets, and the verification passes; if the APP's traffic packets are not detected in the PDU session, the verification fails. At this time, the UPF can perform packet detection within the specified time indicated by the SMF.

[0384] S1416, the UPF sends a detection report to the SMF, providing feedback on the detection results. Specifically, it reports whether the target data packet was detected within the specified time. The detection result includes: detected or not detected.

[0385] S1417, within the predetermined time, the packet detection ends, and the SMF sends the packet detection result to the SM-PCF.

[0386] S1418, SM-PCF sends packet detection results to AM-PCF.

[0387] S1419, AM-PCF obtains the verification result of the URSP rules for the terminal. If the verification result indicates that the terminal has not used the URSP rules correctly, then S1415 is executed.

[0388] S1420, AM-PCF adjusts the URSP rules within the terminal based on the URSP rules reported by the terminal.

[0389] S1421, AM-PCF sends an indication message to SM-PCF, indicating that the terminal is not using URSP rules correctly.

[0390] S1422, SM-PCF forwards the above instruction information to SMF.

[0391] S1423, SMF rejects the request to establish the PDU session, releases the PDU session, or modifies the parameters of the PDU session.

[0392] In one possible implementation, the SMF and AM-PCF can also communicate through the AMF. The specific process is similar to that of methods 1300 and 1400 mentioned above, and will not be repeated here.

[0393] In one possible implementation, the SMF and AM-PCF can also communicate through the AMF and SM-PCF. The specific process is similar to that of methods 1300 and 1400 mentioned above, and will not be repeated here.

[0394] The URSP rule verification method provided in this application can be executed by a URSP rule verification device. This application uses the execution of the URSP rule verification method by a URSP rule verification device as an example to illustrate the URSP rule verification device provided in this application.

[0395] Figure 15 This invention provides a schematic diagram of a URSP rule verification device according to an embodiment of the present application. Figure 15 As shown, the device 1500 mainly includes: a first acquisition module 1501, a first verification module 1502, and a second verification module 1503.

[0396] In this embodiment, the first acquisition module 1501 is used to acquire target request information sent by the second network-side device, wherein the target request information includes: a first URSP rule used by the terminal for the target application and a first parameter of the first PDU session carrying the target application; the first verification module 1502 is used to obtain a first verification result by verifying whether the first URSP rule and the second URSP rule are consistent, wherein the second URSP rule is at least one URSP rule corresponding to the target application sent by the first network-side device to the terminal; the second verification module 1503 is used to verify whether the first parameter of the first PDU session is consistent with the second parameter described by the routing descriptor RSD in the first URSP rule, thereby obtaining a second verification result.

[0397] In one possible implementation, the first parameter includes at least one of the following: PDU session type, PDU session access type, Session and Service Continuity (SSC) mode, Network Slice Identifier, and Data Network Name (DNN); and / or, the second parameter includes at least one of the following: PDU session type, PDU session access type, SSC mode, Network Slice Identifier, and DNN.

[0398] In one possible implementation, the first acquisition module 1501 acquires the target request information sent by the second network-side device, including one of the following:

[0399] Receive the target request information from the second network-side device;

[0400] Receive the target request information forwarded by the second network-side device through the third network-side device and / or the fourth network-side device.

[0401] In one possible implementation, such as Figure 15As shown, the device may further include: a first transceiver module 1504, used to send URSP rules to the terminal; and send first indication information to a third network-side device, wherein the first indication information instructs the third network-side device to send the identifier of the first network-side device to the second network-side device after receiving a PDU session establishment request or a PDU session modification request from the terminal.

[0402] In one possible implementation, the first transceiver module 1504 is further configured to receive a first request message sent by the third network-side device. The first request message is used to request the creation or updating of URSP rules for the terminal. The first request message carries the terminal's capability information, which indicates that the terminal supports reporting the usage information of the terminal's URSP rules.

[0403] In one possible implementation, the second verification module 1503 verifies whether the first parameter of the first PDU session is consistent with the second parameter described by the routing descriptor RSD in the first URSP rule, including:

[0404] If the first verification result indicates that the first URSP rule is consistent with the second URSP rule, the first network-side device verifies whether the first parameter of the first PDU session is consistent with the second parameter described by the RSD in the first URSP rule.

[0405] In one possible implementation, the first acquisition module 1501 is further configured to acquire a third verification result sent by the second network-side device, wherein the third verification result indicates whether the first PDU session includes data packets of the target application.

[0406] In one possible implementation, the first acquisition module 1501 is further configured to send second indication information in any of the following situations, wherein the second indication information is used to indicate that the terminal has not correctly used URSP rules:

[0407] The first verification result indicates that the first URSP rule is inconsistent with the second URSP rule;

[0408] The second verification result indicates that the first parameter and the second parameter are inconsistent;

[0409] The third verification result indicates that the first PDU session does not include data packets of the target application.

[0410] In one possible implementation, such as Figure 15As shown, the device may further include: an update module 1505, configured to update the URSP rules of the terminal in any of the following circumstances:

[0411] The first verification result indicates that the first URSP rule is inconsistent with the second URSP rule;

[0412] The second verification result indicates that at least one of the first parameters is inconsistent with the second parameter;

[0413] The third verification result indicates that the first PDU session does not include data packets of the target application.

[0414] Figure 16 This application provides another schematic diagram of the structure of a URSP rule verification device, as shown in the embodiment of the present application. Figure 16 As shown, the device 1600 mainly includes: a second transceiver module 1601 and a second acquisition module 1602.

[0415] In this embodiment, the second transceiver module 1601 is used to receive reporting information sent by the terminal, wherein the reporting information includes: a first URSP rule used by the terminal for the target application and a first PDU session identifier carrying the target application, the first PDU session identifier being used to indicate the first PDU session; the second acquisition module 1602 is used to acquire the first parameters of the first PDU session; the second transceiver module 1601 is further used to send target request information to the first network-side device, wherein the target request information instructs the first network-side device to verify whether the terminal correctly uses the URSP rule, the target request information including the first URSP rule and the first parameters of the first PDU session.

[0416] In one possible implementation, the second acquisition module 1602 is further configured to acquire the identifier of the first network-side device.

[0417] In one possible implementation, the second acquisition module acquires the identifier of the first network-side device 1602, including one of the following:

[0418] The system receives a second request message sent by a third network-side device, wherein the second request message is used to request the establishment or update of the context of the first PDU session, and the second request message carries a target identifier, which is used to indicate the first network-side device that provides services to the terminal.

[0419] Send a third request message to the third network-side device, wherein the third request message carries the identifier of the terminal, and the third request is used to obtain the context information of the terminal; receive the context information of the terminal returned by the third network-side device, and obtain the identifier of the first network-side device from the context information of the terminal;

[0420] Send a fourth request message to the third network-side device, wherein the fourth request message is used to request the identification of the first network-side device that sent the URSP rules to the terminal, and the fourth request message carries the identification of the terminal; receive the identification of the first network-side device returned by the third network-side device;

[0421] Send a fifth request message to a fifth network-side device, wherein the fifth request message is used to obtain the identifier of the first network-side device that sends URSP rules to the terminal, and the fifth request message carries the identifier of the terminal; obtain the identifier of the first network-side device returned by the fifth network-side device.

[0422] In one possible implementation, such as Figure 16 As shown, the device may further include:

[0423] The third verification module 1603 is used to obtain the first URSP rule sent by the first network-side device, generate a packet detection rule according to the first URSP rule, apply the packet detection rule to the first PDU session indicated by the first PDU session identifier, and obtain a third verification result. The packet detection rule is used to verify whether the first PDU session includes the data packet of the target application.

[0424] In one possible implementation, the second acquisition module 1602 is further configured to acquire second indication information sent by the first network-side device, wherein the second indication information is used to indicate that the terminal has not correctly used the URSP rules; reject the session establishment request corresponding to the first PDU session identifier; or, the second network-side device releases the PDU session corresponding to the first PDU session identifier.

[0425] In one possible implementation, the terminal's failure to correctly use URSP rules includes at least one of the following:

[0426] Whether the first URSP rule and the second URSP rule are consistent, wherein the second URSP rule is at least one URSP rule corresponding to the target application sent by the first network-side device to the terminal;

[0427] At least one of the first parameters is inconsistent with at least one of the second parameters;

[0428] The first PDU session did not include data packets for the target application.

[0429] Figure 17 This illustration shows another structural diagram of the URSP rule verification device provided in the embodiments of this application, such as... Figure 17 As shown, the device 1700 mainly includes a receiving module 1701 and a transmitting module 1702.

[0430] In this embodiment of the application, the receiving module 1701 is used to receive target request information sent by the second network-side device, wherein the target request information instructs the first network-side device to verify whether the terminal correctly uses URSP rules, and the target request information includes the first URSP rule and the first parameter of the first PDU session; the sending module 1702 is used to send the target request information to the first network-side device.

[0431] In one possible implementation, the receiving module 1701 is further configured to receive first indication information sent by the first network-side device, wherein the first indication information instructs the third network-side device to send the identifier of the first network-side device to the second network-side device after receiving the PDU session establishment request or PDU session modification request from the terminal; receive the PDU session establishment request or PDU session modification request sent by the terminal, wherein the PDU session establishment request message or PDU session modification request is used to request the establishment or modification of the first PDU session; the sending module 1702 is further configured to send a second request message to the second network-side device, wherein the second request message is used to request the establishment or update of the context of the first PDU session, and the second request message carries a target identifier, the target identifier being used to indicate the first network-side device providing services to the terminal.

[0432] In one possible implementation, the receiving module 1701 is further configured to receive a third request message sent by the second network-side device, wherein the third request message carries the identifier of the terminal, and the third request is used to obtain the context information of the terminal; the sending module 1702 is further configured to send the context information of the terminal to the second network-side device, wherein the context information includes the identifier of the first network-side device.

[0433] In one possible implementation, the receiving module 1701 is further configured to receive a fourth request message sent by the second network-side device, wherein the fourth request message is used to request the identification of the first network-side device that sends URSP rules to the terminal, and the fourth request message carries the identification of the terminal; the sending module 1702 is further configured to send the identification of the first network-side device corresponding to the identification of the terminal to the second network-side device.

[0434] The URSP rule verification device in the embodiments of this application can be an electronic device, such as an electronic device with an operating system, or a component in an electronic device, such as an integrated circuit or a chip.

[0435] The URSP rule verification device provided in this application embodiment can achieve Figures 2 to 14 The various processes implemented in the method embodiments achieve the same technical effect, and will not be described again here to avoid repetition.

[0436] Optional, such as Figure 18 As shown, this application embodiment also provides a communication device 1800, including a processor 1801 and a memory 1802. The memory 1802 stores a program or instructions that can be executed on the processor 1801. For example, when the communication device 1800 is a network-side device, when the program or instructions are executed by the processor 1801, they implement the various steps of the above-mentioned URSP rule verification method embodiment and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0437] This application also provides a network-side device, including a processor and a communication interface. The processor is used to implement the various steps of the above-described URSP rule verification method embodiment, and the communication interface is used to communicate with external devices. This network-side device embodiment corresponds to the above-described network-side device method embodiment. All implementation processes and methods of the above method embodiments can be applied to this network-side device embodiment and achieve the same technical effects.

[0438] Specifically, embodiments of this application also provide a network-side device. For example... Figure 19 As shown, the network-side device 1900 includes a processor 1901, a network interface 1902, and a memory 1903. The network interface 1902 is, for example, a common public radio interface (CPRI).

[0439] Specifically, the network-side device 1900 of this embodiment further includes: instructions or programs stored in memory 1903 and executable on processor 1901, wherein processor 1901 calls the instructions or programs in memory 1903 to execute. Figures 15 to 17 The methods executed by each module shown achieve the same technical effect, and to avoid repetition, they will not be described in detail here.

[0440] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described URSP rule verification method embodiment and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0441] The processor is the processor in the terminal described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0442] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described URSP rule verification method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be described again here. It should be understood that the chip mentioned in this application embodiment can also be called a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0443] This application also provides a computer program / program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the above-described URSP rule verification method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0444] This application embodiment also provides a URSP rule verification system, including: a first network-side device and a second network-side device. The first network-side device can be used to execute the steps performed by the first network-side device in the URSP rule verification method described above, and the second network-side device can be used to execute the steps performed by the second network-side device in the URSP rule verification method described above.

[0445] Optionally, the URSP rule verification system may further include a third network-side device, which can be used to perform the steps executed by the third network-side device in the URSP rule verification method described above.

[0446] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0447] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0448] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for verifying User Equipment Routing Option Policy (URSP) rules, characterized in that, include: The first network-side device obtains target request information sent by the second network-side device, wherein the target request information includes: the first URSP rule used by the terminal for the target application and the first parameters of the first protocol data unit (PDU) session carrying the target application; The first network-side device obtains a first verification result by verifying whether the first URSP rule and the second URSP rule are consistent, wherein the second URSP rule is at least one URSP rule corresponding to the target application sent by the first network-side device to the terminal; The first network-side device verifies whether the first parameter of the first PDU session is consistent with the second parameter described by the routing descriptor RSD in the first URSP rule, and obtains the second verification result.

2. The method according to claim 1, characterized in that, The first parameter includes at least one of the following: PDU session type, PDU session access type, Session and Service Continuity (SSC) mode, Network Slice Identifier, Data Network Name (DNN); and / or, The second parameter includes at least one of the following: PDU session type, PDU session access type, session and service continuity (SSC) mode, network slice identifier, and data network name (DNN).

3. The method according to claim 1, characterized in that, The first network-side device obtains target request information sent by the second network-side device, including one of the following: The first network-side device receives the target request information from the second network-side device; The first network-side device receives the target request information forwarded by the second network-side device through the third network-side device and / or the fourth network-side device.

4. The method according to claim 1, characterized in that, Before the first network-side device obtains the target request information sent by the second network-side device, the method further includes: The first network-side device sends URSP rules to the terminal; The first network-side device sends a first indication message to the third network-side device, wherein the first indication message indicates that after receiving the PDU session establishment request or PDU session modification request from the terminal, the third network-side device sends the identifier of the first network-side device to the second network-side device.

5. The method according to claim 4, characterized in that, Before the first network-side device sends the first indication information to the third network-side device, the method further includes: The first network-side device receives a first request message sent by the third network-side device. The first request message is used to request the creation or updating of URSP rules for the terminal. The first request message carries the terminal's capability information, which indicates that the terminal supports reporting the usage information of the terminal's URSP rules.

6. The method according to any one of claims 1 to 5, characterized in that, The first network-side device verifies whether the first parameter of the first PDU session is consistent with the second parameter described by the routing descriptor RSD in the first URSP rule, including: If the first verification result indicates that the first URSP rule is consistent with the second URSP rule, the first network-side device verifies whether the first parameter of the first PDU session is consistent with the second parameter described by the RSD in the first URSP rule.

7. The method according to any one of claims 1 to 5, characterized in that, The method further includes: The first network-side device obtains a third verification result sent by the second network-side device, wherein the third verification result indicates whether the first PDU session includes data packets of the target application.

8. The method according to claim 7, characterized in that, The method further includes: The first network-side device sends a second indication message in any of the following situations, wherein the second indication message is used to indicate that the terminal has not correctly used the URSP rules: The first verification result indicates that the first URSP rule is inconsistent with the second URSP rule; The second verification result indicates that the first parameter and the second parameter are inconsistent; The third verification result indicates that the first PDU session does not include data packets of the target application.

9. The method according to claim 7, characterized in that, The method further includes: The first network-side device updates the URSP rules of the terminal under any of the following circumstances: The first verification result indicates that the first URSP rule is inconsistent with the second URSP rule; The second verification result indicates that at least one of the first parameters is inconsistent with the second parameter; The third verification result indicates that the first PDU session does not include data packets of the target application.

10. The method according to any one of claims 1 to 9, characterized in that, The first network-side device and the second network-side device can directly transmit information, or the first network-side device and the second network-side device can transmit information through a third network-side device.

11. A method for verifying URSP rules, characterized in that, include: The second network-side device receives the reporting information sent by the terminal, wherein the reporting information includes: the first URSP rule used by the terminal for the target application and the first PDU session identifier carrying the target application, wherein the first PDU session identifier is used to indicate the first PDU session; The second network-side device obtains the first parameter of the first PDU session; The second network-side device sends target request information to the first network-side device, wherein the target request information instructs the first network-side device to verify whether the terminal correctly uses the URSP rule, and the target request information includes the first URSP rule and the first parameter of the first PDU session; After the second network-side device sends the target request information to the first network-side device, the method further includes: The second network-side device obtains the first URSP rule sent by the first network-side device; The second network-side device generates a packet detection rule based on the first URSP rule, applies the packet detection rule to the first PDU session indicated by the first PDU session identifier, and obtains a third verification result. The packet detection rule is used to verify whether the first PDU session includes data packets of the target application. The second network-side device sends the third verification result to the first network-side device.

12. The method according to claim 11, characterized in that, Before the second network-side device sends the target request information to the first network-side device, the method further includes: The second network-side device obtains the identifier of the first network-side device.

13. The method according to claim 12, characterized in that, The second network-side device obtains the identifier of the first network-side device by one of the following: The second network-side device receives a second request message sent by the third network-side device, wherein the second request message is used to request the establishment or update of the context of the first PDU session, and the second request message carries a target identifier, which is used to indicate the first network-side device that provides services to the terminal; The second network-side device sends a third request message to the third network-side device, wherein the third request message carries the identifier of the terminal, and the third request is used to obtain the context information of the terminal; the second network-side device receives the context information of the terminal returned by the third network-side device, and obtains the identifier of the first network-side device from the context information of the terminal; The second network-side device sends a fourth request message to the third network-side device, wherein the fourth request message is used to request the identification of the first network-side device that sends URSP rules to the terminal, and the fourth request message carries the identification of the terminal; the second network-side device receives the identification of the first network-side device returned by the third network-side device; The second network-side device sends a fifth request message to the fifth network-side device, wherein the fifth request message is used to obtain the identifier of the first network-side device that sent the URSP rules to the terminal, and the fifth request message carries the identifier of the terminal; and obtains the identifier of the first network-side device returned by the fifth network-side device.

14. The method according to claim 11, characterized in that, The method further includes: The second network-side device obtains the second indication information sent by the first network-side device, wherein the second indication information is used to indicate that the terminal has not correctly used the URSP rules; The second network-side device rejects the session establishment request corresponding to the first PDU session identifier, or the second network-side device releases the PDU session corresponding to the first PDU session identifier.

15. The method according to claim 14, characterized in that, The terminal is not using URSP rules correctly, including at least one of the following: Whether the first URSP rule and the second URSP rule are consistent, wherein the second URSP rule is at least one URSP rule corresponding to the target application sent by the first network-side device to the terminal; At least one of the first parameters is inconsistent with at least one of the second parameters; The first PDU session did not include data packets for the target application.

16. The method according to any one of claims 11 to 15, characterized in that, The second network-side device and the first network-side device can directly transmit information, or the second network-side device and the first network-side device can transmit information through a third network-side device.

17. A method for verifying URSP rules, characterized in that, include: The third network-side device receives target request information sent by the second network-side device, wherein the target request information instructs the first network-side device to verify whether the terminal correctly uses URSP rules, and the target request information includes the first URSP rule and the first parameter of the first PDU session; The third network-side device sends the target request information to the first network-side device; The method further includes the following steps before the third network-side device receives the target request information sent by the second network-side device: The third network-side device receives a first indication message sent by the first network-side device, wherein the first indication message indicates that after receiving a PDU session establishment request or a PDU session modification request sent by the terminal, the third network-side device sends the identifier of the first network-side device to the second network-side device. The third network-side device receives a PDU session establishment request or a PDU session modification request sent by the terminal, wherein the PDU session establishment request message or the PDU session modification request is used to request the establishment or modification of the first PDU session; The third network-side device sends a second request message to the second network-side device, wherein the second request message is used to request the establishment or update of the context of the first PDU session, and the second request message carries a target identifier, which is used to indicate the first network-side device that provides services to the terminal.

18. The method according to claim 17, characterized in that, Before the third network-side device receives the first request message sent by the second network-side device, the method further includes: The third network-side device receives a third request message sent by the second network-side device, wherein the third request message carries the identifier of the terminal, and the third request is used to obtain the context information of the terminal; The third network-side device sends the terminal's context information to the second network-side device, wherein the context information includes the identifier of the first network-side device.

19. The method according to claim 17, characterized in that, Before the third network-side device receives the first request message sent by the second network-side device, the method further includes: The third network-side device receives a fourth request message sent by the second network-side device, wherein the fourth request message is used to request the identification of the first network-side device that sends URSP rules to the terminal, and the fourth request message carries the identification of the terminal. The third network-side device sends the identifier of the first network-side device corresponding to the identifier of the terminal to the second network-side device.

20. A URSP rule verification device, applied to a first network-side device, characterized in that, The device includes: The first acquisition module is used to acquire target request information sent by the second network-side device, wherein the target request information includes: the first URSP rule used by the terminal for the target application and the first parameters of the first PDU session carrying the target application; The first verification module is used to obtain a first verification result by verifying whether the first URSP rule and the second URSP rule are consistent, wherein the second URSP rule is at least one URSP rule corresponding to the target application sent by the first network-side device to the terminal; The second verification module is used to verify whether the first parameter of the first PDU session is consistent with the second parameter described by the routing descriptor RSD in the first URSP rule, and to obtain the second verification result.

21. The apparatus according to claim 20, characterized in that, The device further includes: The first transceiver module is used to send URSP rules to the terminal and send first indication information to the third network-side device, wherein the first indication information instructs the third network-side device to send the identifier of the first network-side device to the second network-side device after receiving the PDU session establishment request or PDU session modification request from the terminal.

22. The apparatus according to claim 21, characterized in that, The first transceiver module is further configured to receive a first request message sent by the third network-side device. The first request message is used to request the creation or updating of URSP rules for the terminal. The first request message carries the terminal's capability information, which indicates that the terminal supports reporting the usage information of the terminal's URSP rules.

23. The apparatus according to any one of claims 20 to 22, characterized in that, The first acquisition module is further configured to acquire a third verification result sent by the second network-side device, wherein the third verification result indicates whether the first PDU session includes data packets of the target application.

24. The apparatus according to claim 23, characterized in that, The device further includes: The update module is used to update the URSP rules of the terminal in any of the following situations: The first verification result indicates that the first URSP rule is inconsistent with the second URSP rule; The second verification result indicates that at least one of the first parameters is inconsistent with the second parameter; The third verification result indicates that the first PDU session does not include data packets of the target application.

25. A verification device for URSP rules, characterized in that, include: The second transceiver module is used to receive reporting information sent by the terminal, wherein the reporting information includes: the first URSP rule used by the terminal for the target application and the first PDU session identifier carrying the target application, wherein the first PDU session identifier is used to indicate the first PDU session; The second acquisition module is used to acquire the first parameter of the first PDU session; The second transceiver module is further configured to send target request information to the first network-side device, wherein the target request information instructs the first network-side device to verify whether the terminal correctly uses URSP rules, and the target request information includes the first URSP rules and the first parameters of the first PDU session; The third verification module is used to obtain the first URSP rule sent by the first network-side device, generate a packet detection rule according to the first URSP rule, apply the packet detection rule to the first PDU session indicated by the first PDU session identifier, and obtain a third verification result. The packet detection rule is used to verify whether the first PDU session includes data packets of the target application.

26. The apparatus according to claim 25, characterized in that, The second acquisition module is also used to acquire the identifier of the first network-side device.

27. The apparatus according to claim 26, characterized in that, The second acquisition module acquires the identifier of the first network-side device, including one of the following: The system receives a second request message sent by a third network-side device, wherein the second request message is used to request the establishment or update of the context of the first PDU session, and the second request message carries a target identifier, which is used to indicate the first network-side device that provides services to the terminal. Send a third request message to the third network-side device, wherein the third request message carries the identifier of the terminal, and the third request is used to obtain the context information of the terminal; receive the context information of the terminal returned by the third network-side device, and obtain the identifier of the first network-side device from the context information of the terminal; Send a fourth request message to the third network-side device, wherein the fourth request message is used to request the identification of the first network-side device that sent the URSP rules to the terminal, and the fourth request message carries the identification of the terminal; receive the identification of the first network-side device returned by the third network-side device; Send a fifth request message to a fifth network-side device, wherein the fifth request message is used to obtain the identifier of the first network-side device that sends URSP rules to the terminal, and the fifth request message carries the identifier of the terminal; obtain the identifier of the first network-side device returned by the fifth network-side device.

28. A URSP rule verification device, applied to a third-party network device, characterized in that, The device includes: The receiving module is configured to receive target request information sent by the second network-side device, wherein the target request information instructs the first network-side device to verify whether the terminal correctly uses the URSP rule, and the target request information includes the first URSP rule and the first parameter of the first PDU session; The sending module is used to send the target request information to the first network-side device; The receiving module is further configured to receive first indication information sent by the first network-side device, wherein the first indication information instructs the third network-side device to send the identifier of the first network-side device to the second network-side device after receiving the PDU session establishment request or PDU session modification request sent by the terminal; and to receive the PDU session establishment request or PDU session modification request sent by the terminal, wherein the PDU session establishment request message or PDU session modification request is used to request the establishment or modification of the first PDU session; The sending module is further configured to send a second request message to the second network-side device, wherein the second request message is used to request the establishment or update of the context of the first PDU session, and the second request message carries a target identifier, the target identifier being used to indicate the first network-side device providing services to the terminal.

29. The apparatus according to claim 28, characterized in that, The receiving module is further configured to receive a third request message sent by the second network-side device, wherein the third request message carries the identifier of the terminal and the third request is used to obtain the context information of the terminal; The sending module is further configured to send the context information of the terminal to the second network-side device, wherein the context information includes the identifier of the first network-side device.

30. The apparatus according to claim 28, characterized in that, The receiving module is further configured to receive a fourth request message sent by the second network-side device, wherein the fourth request message is used to request the identification of the first network-side device that sends URSP rules to the terminal, and the fourth request message carries the identification of the terminal. The sending module is further configured to send the identifier of the first network-side device corresponding to the identifier of the terminal to the second network-side device.

31. A network-side device, characterized in that, It includes a processor and a memory, the memory storing a program or instructions that can run on the processor, the program or instructions being executed by the processor to implement the steps of the URSP rule verification method as described in any one of claims 1 to 19.

32. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the URSP rule verification method as described in any one of claims 1 to 19.

Images