WO2023213309A1

WO2023213309A1 - Ursp rule verification method and apparatus, and network side device

Info

Publication number: WO2023213309A1
Application number: PCT/CN2023/092335
Authority: WO
Inventors: 吕华章; 柯小婉; 王文; 张奕忠
Original assignee: 维沃移动通信有限公司
Priority date: 2022-05-06
Filing date: 2023-05-05
Publication date: 2023-11-09
Also published as: CN117062248A

Abstract

The present application relates to the field of wireless communications, and discloses a URSP rule verification method and apparatus, and a network side device. The URSP rule verification method in embodiments of the present application comprises: a first network side device obtains target request information sent by a second network side device, 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 device obtains a first verification result by verifying whether the first URSP rule is consistent with a second URSP rule; and the first network side device verifies whether the first parameter of the first PDU session is consistent with a second parameter described by a route selection descriptor (RSD) in the first URSP rule, so as to obtain a second verification result.

Description

Verification method, device and network side equipment of URSP rules

cross reference

This invention requires the priority of a Chinese patent application submitted to the China Patent Office on May 6, 2022, with the application number 202210487743.0 and the invention name "URSP rule verification method, device and network side equipment". The entire content of the application is approved This reference is incorporated herein by reference.

Technical field

This application belongs to the field of wireless communication technology, and specifically relates to a verification method, device and network-side equipment for URSP rules.

Background technique

In the 3rd Generation Partnership Project (3GPP) protocol, when an application on the terminal has traffic to be sent, the application can provide the traffic characteristics of the application traffic to be sent, and the terminal (OS Operating System, OS) or modem chip) obtains the traffic characteristics provided by the application, such as the destination Internet Protocol (Internet Protocol, IP) address of the application traffic to be sent, the fully qualified domain name (Fully Qualified Domain Name, FQDN), etc. The terminal will match the traffic characteristics with the Traffic Descriptor (TD) parameters in the User Equipment Routing Option Policy (UE Route Selection Policy, URSP) rule in the terminal. After matching a certain traffic descriptor, the terminal Then select a route selection descriptor (Route Selection Descriptor, RSD) under the traffic descriptor. The routing descriptor defines the session parameters of the Protocol Data Unit (PDU) session used to carry the application traffic to be transmitted when the application traffic characteristics match a certain traffic descriptor. If the current terminal equipment (User Equipment, UE) already has a PDU session, and the session parameters of the PDU session are consistent with an RSD under the traffic descriptor selected by the terminal for application traffic, then the data to be transmitted for the application can be Route to an established Protocol Data Unit (PDU) session. Or, if the terminal selects a certain RSD under the traffic descriptor for the application traffic to be transmitted, and there is no such PDU session in the current terminal, the terminal can trigger the establishment of a new PDU session. The session parameters are consistent with the PDU session parameters in the selected RSD, and the PDU session is used to carry the application data stream to be transmitted.

However, in related technologies, URSP rules are only the behavior of the terminal device. For a certain application, the network side device cannot know whether the terminal device has applied the URSP rules configured by the network side device for the terminal device to match application traffic to a specific PDU. session, and the URSP rules specifically used by the end device to match the application traffic.

Contents of the invention

Embodiments of the present application provide a method, device 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 configured URSP rules and the URSP rules used by the terminal device for specific applications.

In a first aspect, a method for verifying URSP rules is provided, including: a first network side device obtains target request information sent by a second network side device, wherein the target request information includes: a first method used by a terminal for a target application. URSP rules and the first parameter of the first PDU session carrying the target application; the first network side device obtains the 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 the first parameter of the first PDU session and Whether the second parameter described by the routing descriptor RSD in the first URSP rule is consistent, a second verification result is obtained.

In a second aspect, a method for verifying URSP rules is provided, including: 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 bearer The first PDU session identifier of the target application, 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 The 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 uses the URSP rule correctly, and the target request information includes the first network side device. URSP rule and the first parameter of the first PDU session.

In a third aspect, a method for verifying URSP rules is provided, including: a third network side device receiving target request information sent by a second network side device, wherein the target request information indicates that the first network side device has a request for the terminal Verify whether the URSP rules are used correctly. 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 third network side device. A network side device.

In a fourth aspect, a device for verifying URSP rules is provided, including: a first acquisition module configured to acquire target request information sent by the second network side device, wherein the target request information includes: the terminal used for the target application. The first URSP rule and the first parameter of the first PDU session carrying the target application; a first verification module configured to obtain the 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; a second verification module, used to verify the first step of the first PDU session Whether the parameter is consistent with the second parameter described by the routing descriptor RSD in the first URSP rule, a second verification result is obtained.

In a fifth aspect, a device for verifying URSP rules is provided, including: 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 that carries the target application, the first PDU session identifier is used to indicate the first PDU session; a second acquisition module is used to acquire the first parameter of the first PDU session; the third The second transceiver module is also 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 uses the URSP rules correctly, and the target request information The first URSP rule and the first parameter of the first PDU session are included.

In a sixth aspect, a device for verifying URSP rules is provided, including: a receiving module configured to receive target request information sent by a second network side device, wherein the target request information indicates that the first network side device has a request for the terminal yes Verify whether the URSP rules are used correctly, and the target request information includes the first URSP rule and the first parameter of the first PDU session; a sending module for sending the target request information to the first network side equipment.

In a seventh aspect, a network side device is provided. The network side device includes a processor and a memory. The memory stores programs or instructions that can be run on the processor. The program or instructions are executed by the processor. When implementing the steps of the method described in the first to third aspects.

In an eighth aspect, 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 described in the first to third aspects, and the communication interface is used to communicate with an external devices communicate.

A ninth aspect provides a verification system for URSP rules, including: a first network side device and a second network side device. The first network side device can be used to perform the steps of the method described in the first aspect. The second network side device may be used to perform the steps of the method described in the second aspect.

In a tenth aspect, a readable storage medium is provided. Programs or instructions are stored on the readable storage medium. When the programs or instructions are executed by a processor, the steps of the method described in the first aspect are implemented, or the steps of the method are implemented as described in the first aspect. The steps of the method described in the second aspect, or the steps of implementing the method described in the third aspect.

In an eleventh aspect, a chip is provided. The chip 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 method described in the first aspect. The steps of the method, or the steps of implementing the method as described in the second aspect, or the steps of implementing the method as described in the third aspect.

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

In this embodiment of the present application, the first network side device obtains 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 from the second network side device, and verifies the first Whether a 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 verifying that the first parameter of the first PDU session is consistent with the first URSP rule Whether the second parameter described by the routing descriptor RSD in is consistent, so that the first network side device can learn whether the terminal applies the URSP rule configured by the network side device for the terminal device to match application traffic to a specific PDU session, terminal Match the URSP rules specifically used by the application traffic and whether the corresponding PDU session includes the data packets of the application traffic, so that the network side device can control the terminal.

Description of the drawings

Figure 1 shows a block diagram of a wireless communication system to which embodiments of the present application are applicable;

Figure 2 shows a schematic flow chart of the verification method of URSP rules provided by the embodiment of the present application;

Figure 3 shows another schematic flow chart of the verification method of URSP rules provided by the embodiment of the present application;

Figure 4 shows a schematic flowchart of a method for obtaining an identity of a first network side device provided by an embodiment of the present application;

Figure 5 shows another schematic flowchart of a method for obtaining an identity of a first network side device provided by an embodiment of the present application;

Figure 6 shows another schematic flowchart of a method for obtaining the identity of a first network side device provided by an embodiment of the present application;

Figure 7 shows another schematic flowchart of a method for obtaining an identity of a first network side device provided by an embodiment of the present application;

Figure 8 shows another schematic flow chart of the verification method of URSP rules provided by the embodiment of the present application;

Figure 9 shows another schematic flow chart of the verification method of URSP rules provided by the embodiment of the present application;

Figure 10 shows another schematic flow chart of the verification method of URSP rules provided by the embodiment of the present application;

Figure 11 shows another schematic flow chart of the verification method of URSP rules provided by the embodiment of the present application;

Figure 12 shows another schematic flow chart of the verification method of URSP rules provided by the embodiment of the present application;

Figure 13 shows another schematic flow chart of the verification method of URSP rules provided by the embodiment of the present application;

Figure 14 shows another schematic flow chart of the verification method of URSP rules provided by the embodiment of the present application;

Figure 15 shows a schematic structural diagram of a verification device for URSP rules provided by an embodiment of the present application;

Figure 16 shows another structural schematic diagram of a verification device for URSP rules provided by an embodiment of the present application;

Figure 17 shows another structural schematic diagram of a verification device for URSP rules provided by an embodiment of the present application;

Figure 18 shows a schematic structural diagram of a communication device provided by an embodiment of the present application;

Figure 19 shows a schematic hardware structure diagram of a network-side device provided by an embodiment of the present application.

Detailed ways

The technical solutions in the embodiments of the present application will be clearly described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, but not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art fall within the scope of protection of this application.

The terms "first", "second", etc. in the description and claims of this application are used to distinguish similar objects and are not used to describe a specific order or sequence. It is to be understood that the terms so used are interchangeable under appropriate circumstances so that the embodiments of the present application can be practiced in sequences other than those illustrated or described herein, and that "first" and "second" are distinguished objects It is usually one type, and the number of objects is not limited. For example, the first object can be one or multiple. In addition, "and/or" in the description and claims indicates at least one of the connected objects, and the character "/" generally indicates that the related objects are in an "or" relationship.

It is worth pointing out that the technology described in the embodiments of this application is not limited to Long Term Evolution (LTE)/LTE Evolution (LTE-Advanced, LTE-A) systems, and can also be used in other wireless communication systems, such as code 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 the embodiments of this application are often used interchangeably, and the described technology can be used not only for the above-mentioned systems and radio technologies, but also for other systems and radio technologies. The following description describes a New Radio (NR) system for example purposes, and NR terminology is used in much of the following description, but these techniques can also be applied to applications other than NR system applications, such as 6th ^generation Generation, 6G) communication system.

Figure 1 shows a block diagram of a wireless communication system to which embodiments of the present application are applicable. The wireless communication system includes a terminal 11 and network side device 12. The terminal 11 may be a mobile phone, a tablet computer (Tablet Personal Computer), a laptop computer (Laptop Computer), or a notebook computer, a personal digital assistant (Personal Digital Assistant, PDA), a palmtop computer, a netbook, or a super mobile personal computer. (ultra-mobile personal computer, UMPC), mobile Internet device (Mobile Internet Device, MID), augmented reality (AR)/virtual reality (VR) equipment, robots, wearable devices (Wearable Device) , vehicle user equipment (VUE), pedestrian terminal (Vehicle user equipment, VUE), smart home (home equipment with wireless communication functions, such as refrigerators, TVs, washing machines or furniture, etc.), game consoles, personal computers (personal computer, PC), teller machine or self-service machine and other terminal-side devices. Wearable devices include: smart watches, smart bracelets, smart headphones, smart glasses, smart jewelry (smart bracelets, smart bracelets, smart rings, smart necklaces, smart anklets) bracelets, smart anklets, etc.), smart wristbands, smart clothing, etc. It should be noted that the embodiment of the present application does not limit the specific type of the terminal 11. The network side device 12 may include an access network device and/or a core network device, where the access network device 12 may also be called a radio access network device, a radio access network (Radio Access Network, RAN), or a radio access network. function or radio access network unit. The access network device 12 may include a base station, a Wireless Local Area Network (Wireless Local Area Network, WLAN) access point or a Wireless Fidelity (Wireless Fidelity, WiFi) node, etc. The base station may be called a Node B, an Evolved Node B (Evolved NodeB, 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 (Transmitting Receiving Point, TRP) or some 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 needs to be explained that , in the embodiment of this application, only the base station in the NR system is taken as an example for introduction, and the specific type of the base station is not limited. Core network equipment may include but is not limited to at least one of the following: core network nodes, core network functions, mobility management entities (Mobility Management Entity, MME), access mobility management functions (Access and Mobility Management Function, AMF), session management functions (Session Management Function, SMF), User Plane Function (UPF), Policy Control Function (PCF), Policy and Charging Rules Function (PCRF), Edge Application Service Discovery function (Edge Application Server Discovery Function, EASDF), Unified Data Management (UDM), Unified Data Repository (UDR), Home Subscriber Server (HSS), centralized network configuration ( Centralized network configuration (CNC), Network Repository Function (NRF), Network Exposure Function (NEF), Local NEF (Local NEF, or L-NEF), Binding Support Function (Binding Support Function, BSF), application function (Application Function, AF), etc. It should be noted that in the embodiment of this application, only the core network equipment in the NR system is used as an example for introduction, and the specific type of the core network equipment is not limited.

URSP rules are a policy defined by 3GPP and sent to the UE. The UE can match application (Application, APP) traffic to a specific PDU session based on these URSP rules.

For example, when an application (APP) on the UE has traffic that needs to be sent to the server, the APP can send APP traffic characteristics to the UE. These traffic characteristics can include the destination IP address, fully qualified domain name (Fully Qualified Domain) Name, FQDN), etc. Then the UE matches the URSP rules in the UE one by one according to the traffic characteristics of the APP. In the URSP rules, the specified traffic description/characteristics can be as shown in Table 1.

Table 1.

For example, the second APP can send an IP description, such as a destination IP triplet, indicating that the traffic of the APP needs to be sent to destination IP = 10.1.1.1, port number = 80. Then, if there happens to be this traffic descriptor in the UE URSP rules, it means that the traffic of the APP can match a certain URS Prules.

After there are URS Prules matching the APP's traffic, the next step is to choose which PDU session (session) to use to send the APP's traffic (traffic).

Generally speaking, there is at least one RSD under a certain Traffic descriptor, and each RSD represents a set of attributes of a PDU session. For example, when APP traffic matches a group of traffic descriptors with destination IP = 10.1.1.1 and port number = 80, then there are the following RSDs under this group of traffic descriptors:

■RSD priority (precedence)=1

◆S-NSSAI-a

◆Non-3GPP access (Access)

■RSD precedence＝2

◆S-NSSAI-a

◆3GPP Access

◆DNN＝Internet

◆SSC mode=3

For example, the PDU session characteristics or session parameters corresponding to RSD1 are: S-NSSAI=S-NSSAI-a, using non-3GPP access. The terminal can use the PDU session in RSD1 to specifically establish a PDU session; or use this feature to select a PDU session that the terminal has already established. The selected PDU session, its session characteristics or session parameters, For, S-NSSAI=S-NSSAI-a, non-3GPP access is used (that is, the access type of the PDU session is non-3GPP access).

However, after the network side device sends URSP rules to the UE, for the APP traffic, whether the UE uses URSP rules to match the APP traffic to a specific PDU session, and which URSP rule is used for traffic matching, for the network side device It's all unknown. For example, for the traffic of a certain application, the RSD of the traffic descriptor matched by the UE includes:

■RSD precedence＝1

◆S-NSSAI-a

◆Non-3GPP Access

■RSD precedence＝2

◆S-NSSAI-a

◆3GPP Access

◆DNN＝Internet

◆SSC mode=3

The network side device does not know whether the UE has executed URSP rules and if so, which RSD has been executed. To address this problem, embodiments of the present application provide a verification solution for URSP rules so that network-side devices can obtain this information. The network side is allowed to obtain the traffic of an application by the terminal, which RSD under which traffic descriptor is used, and after using the URSP rule, whether a new PDU session is created or the application traffic is matched to an existing session.

The verification scheme of URSP rules provided by the embodiments of the present application will be described in detail below with reference to the accompanying drawings through some embodiments and their application scenarios.

Figure 2 shows a schematic flowchart of the verification method of URSP rules in the embodiment of the present application. The method 200 can be executed by the first network side device. In other words, the method may be executed by software or hardware installed on the first network side device. In this embodiment of the present application, the first network side device may be an access and mobility management policy control network element. For example, the first network side device may be an access and mobility management policy control function (Access and Mobility Management Policy Control). Function, AM-PCF). As shown in Figure 2, the method may include the following steps.

S210. The first network side device obtains the target request information sent by the second network side device, where the target request information includes: the first URSP rule used by the terminal for the target application and the first protocol data unit carrying the target application. The first parameter of the PDU session.

Wherein, the target request information instructs the first network side device to verify whether the terminal uses URSP rules correctly. In this embodiment of the present application, the second network side device may be a session management network element, for example, a session management function (Session Management Function, SMF).

The target request information can be sent through at least one of the following signaling: Npcf_EventExposure_Subscribe, Npcf_UEPolicyControl_Update request.

For example, after the terminal uses a URSP rule for a certain application traffic, it can report the details of the specific URSP rule to the second network side device through a session non-access stratum (NAS) message. For example, report the final The end uses a certain Traffic descriptor (FQDN=ABC.com), or uses a certain RSD (S-NSSAI=S-NSSAI-a, using non-3GPP access); it can also directly indicate that the rules used take precedence. level or RSD priority, because for a terminal, a rule priority only corresponds to one traffic descriptor, and the priority of the RSD under a traffic descriptor only corresponds to one RSD. For example, the terminal reports the first URSP rule as follows: rule precedence=1, RSD precedence=2, which means that the terminal uses a rule with a priority of 1 and an RSD with an RSD priority of 2 under the traffic descriptor. The NAS message includes at least one of the following: PDU session establishment request (PDU session establishment request), DPU session modification request (PDU session modification request). Alternatively, the NAS message may also include: PDU session SM context generation request (Nsmf_PDUSession_CreateSMContext Request) or PDU session SM context update request (Nsmf_PDUSession_UpdateSMContext Request).

After receiving the session 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 according to the first PDU session identifier carried in the NAS message, and then add the first PDU session identifier to the first PDU session identifier. The first parameter of a PDU session and the first URSP rule used by the target application reported by the terminal are sent to the first network side device.

The first PDU session identifier is used to indicate the PDU session to which the application traffic is finally matched. The PDU session may be a newly created session or an existing session in the terminal. Here, the information reported by the terminal to the second network side device may also include indication information, which is used to indicate whether to create a new PDU session after using the URSP rule or to match an existing PDU session on the terminal. For example, the indication information indicates that after using the first URSP rule, a new PDU session is created to carry the application traffic.

In this embodiment of the present application, the target request information can be transmitted directly between the first network side device and the second network side device. Therefore, in a possible implementation, S210 may include: the first network side device receives the request from the first network side device. The target request information of the second network side device.

Alternatively, the target request information may also be transmitted between the first network side device and the second network side device through 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 through the third network side device and/or the fourth network side device.

The third network side device may be an access and mobility management network element, such as AMF, or a session management policy control network element, such as SM-PCF. The fourth network side device may be a session management policy control network element. , or access and mobility management network elements. For example, SMF sends the target request information to AM-PCF through AMF; or SMF sends the target request information to AM-PCF through SM-PCF; or SMF sends the target request information to AMF, and AMF then sends the target request information to AM-PCF. The information is sent to SM-PCF, SM-PCF then sends the target request information to AM-PCF; or, SMF sends the target request information to SM-PCF, SM-PCF then sends the target request information to AMF, and AMF then sends the target request information to AM-PCF. Request information is sent to AM-PCF.

For example, if the third network side device is AMF, the second network side device is SMF, and the first network side device is AM-PCF, the SMF can be sent through Namf_Communication_N1N2MessageTransfer or Nsmf_EventExposure_Notify, sends the target request information to the AMF; then the AMF sends the target request information to the first network side device, such as AM-PCF, through Npcf_UEPolicyControl_Update request, Npcf_UEPolicyControl_UpdateNotify Subscribe or Npcf_EventExposure_Subscribe.

For another example, if the fourth network side device is SM-PCF, the second network side device is SMF, and the first network side device is AM-PCF, then the SMF can be sent through at least one of the following signaling: The target request information is sent to the fourth network side device: Npcf_SMPolicyControl_Update or Npcf_SMPolicyControl_create; then, the SM-PCF sends the target request information to the AM-PCF through at least one of the following signaling: Npcf_Policy Authorization_Create, Npcf_Policy Authorization_Update.

The sending the target request information also refers to sending the parameters included in the target request information, such as the first URSP rule, etc., to the first network side device, such as the AM-PCF.

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 sent by the first network-side device to the At least one URSP rule of the terminal corresponding to the target application.

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 is consistent with the second URSP rule, that is, the first verification is passed; or the first URSP rule is inconsistent with the second URSP rule, that is, the first verification fails.

For example, the terminal executes URSP rules for the traffic of the target application, and then the terminal sends the used URSP rules to the SMF. SMF forwards the URSP rule to AM-PCF, and AM-PCF performs the first verification to verify whether the rule reported by the terminal is consistent with the rule sent by AM-PCF to the UE, that is, it verifies whether the URSP rule reported by the terminal is sent by AM-PCF. One of the URSP rules for the UE.

For example, the URSP rules reported by the terminal itself: Rule Precedence=1 and RSD Precedence=1. The first network side device may restore or query the AM-PCF for the URSP rule corresponding to the priority based on the information reported by the terminal, or the AM-PCF may check the second URSP rule sent to the UE. For example, based on the Rule Precedence=1 and RSD Precedence=1 reported by the terminal, AM-PCF checked and found that the URSP rules sent to the UE were as follows:

Rule Precedence=1;

Traffic Descriptor: Application descriptor = App1;

RSD Precedence=1;

Network Slice Selection: S-NSSAI-a;

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

Data Network Name (DNN) Selection: internet;

Access Type preference: 3GPP access.

The terminal reported the first URSP rule used:

Rule Precedence=1;

Traffic Descriptor:Application descriptor=App1;

Route Selection Descriptor Precedence=1;

Network Slice Selection: S-NSSAI-a;

SSC Mode Selection: SSC Mode 3;

DNN Selection: internet;

Access Type preference: 3GPP access.

Then the first network side device 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 first network side device from the UE (i.e., the second URSP rule). The verification passes and the rule reported by the UE is correct. The verification here refers to verifying whether the URSP rules reported by the terminal, including traffic descriptors and RSDs, are consistent with the traffic descriptors or RSDs in the URSP rules sent to the terminal by the first network-side device. If they are consistent, it is determined that the terminal strictly uses one of the URSP rules issued by AM-PCF, rather than the terminal itself randomly using a URSP rule that has not been issued by the network at all.

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 a second verification result.

The second verification result indicates whether the first parameter of the first PDU session is consistent with the second parameter described by the RSD in 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 by the RSD in the first URSP rule, that is, the item-by-item parameters of the first parameter and the second parameter. One-to-one correspondence and consistency, that is, the second verification is passed; or, any one of the first parameters of the first PDU session and the second parameters described by the RSD in the first URSP rule is inconsistent, that is, the second verification fail.

For example, when 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 the second verification, that is, verify the first PDU. Whether the first parameter of the session is consistent with the second parameter described by the RSD in the first URSP rule.

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, access type of PDU session, SSC mode, network slice identifier, and DNN.

Optionally, the second parameter of the RSD description 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.

In this embodiment of the present application, whether the first parameter is consistent with the second parameter refers to whether the parameter value of each parameter in the first parameter is consistent with the parameter value of the corresponding parameter 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 refers to the PDU in the first parameter. The session type 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 in the second parameter The pattern is the same, the DNN in the first parameter is the same as the DNN in the second parameter. If any of them are different, the first parameter and the second parameter are inconsistent.

The purpose of performing the second verification is to ensure that if the terminal really uses the first URSP rule correctly, the The PDU session parameters of the first PDU session carrying application traffic, such as SSC mode, DNN, etc., must correspond to the parameters of the PDU session indicated in the RSD in the first URSP rule, such as SSC mode, DNN, etc., one by one and same.

The purpose of the second verification in S214 is to ensure that if the terminal really uses the first URSP rule correctly, the parameters of the PDU session of the first PDU session carrying application traffic, such as SSC mode, DNN, etc., must The parameters of the PDU session indicated in the RSD in the first URSP rule, such as SSC mode, DNN, etc., correspond to each other one by one and are the same.

In S214, the first network side device obtains the second verification result, so as to know 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.

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

Rule Precedence=1;

Traffic Descriptor:Application descriptor=App1;

Route Selection Descriptor Precedence=1;

Network Slice Selection:S-NSSAI-a;

SSC Mode Selection:SSC Mode 3;

DNN Selection:internet;

Access Type preference: 3GPP access.

The second network side device obtains the first PDU session that actually carries the traffic of the target application (ie APP1) through inspection. The first parameter of the first PDU session is:

Network Slice Selection:S-NSSAI-b;

SSC Mode Selection:SSC Mode 3;

DNN Selection:internet;

Access Type preference: 3GPP access.

It can be seen that the network slice in the second parameter is S-NSSAI-b, and the network slice in the first parameter is S-NSSAI-b. The two are inconsistent. Therefore, the terminal does not use the URSP rule correctly. In other words, although the terminal reports the URSP rules it uses, the traffic of the APP does not actually use the PDU session bearer corresponding to each PDU session parameter of this RSD. This means that the second verification failed and the terminal did not use URSP rules correctly.

In a possible implementation, the first network side device may return the first verification result and/or the second verification 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 to send the first verification result and/or the second verification result to SMF: Npcf_EventExposure_Notify, Npcf_UEPolicyControl Update response.

Alternatively, the AM-PCF may send the first verification result and/or the second verification result to the AMF using at least one of the following signaling: Npcf_UEPolicyControl_Update response; Npcf_UEPolicyControl_UpdateNotify notify. Then, AMF uses at least one of the following signalings to SMF the first verification result and/or the second verification result: Nsmf_PDUSession_UpdateSMContext request, Nsmf_EventExposure_Subscribe.

Alternatively, the AM-PCF may send the first verification result and/or the second verification result to the SM-PCF using at least one of the following signaling: Npcf_Policy Authorization_Createrequest/response, Npcf_Policy Authorization_Up date request/response. SM-PCF then uses at least one of the following signaling to send the first verification result and/or the second verification result to SMF: Npcf_SMPolicyControl_Updaterequest/response, Npcf_SMPolicyControl_creater request/response.

Through the above technical solutions provided by 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, Verify 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 verify that the first parameter of the first PDU session is consistent with the Whether the second parameter described by the routing descriptor RSD in the first URSP rule is consistent, so that the first network side device can learn whether the terminal has applied the URSP rule configured by the network side device for the terminal device to match application traffic to a specific The PDU session, the terminal matches the URSP rules specifically used by the application traffic, and whether the corresponding PDU session includes the data packets of the application traffic, so that the network side device can control the terminal.

In a possible implementation, in order for the second network side device to learn the identity of the first network side device and thereby send the target request information to the first network side device, before S210, the method may also include the following: step:

Step 1: The first network side device sends a URSP rule to the terminal;

Step 2: The first network side device sends first indication information to the third network side device, wherein the first indication information indicates that the third network side device receives a PDU session establishment request from the terminal or After the PDU session modification request is made, the identifier of the first network side device is sent to the second network side device. For example, the third network side device may send the identity of the first network side device to the second network side device through the following signaling: Npcf_UEPolicyControl Create Request, or Npcf_UEPolicyControl Update Request.

Wherein, the identification 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.

In the above possible implementation manner, when sending the URSP rule to the terminal, the first network side device instructs the third network side device to change the first network side device to the terminal upon receiving a PDU session establishment request or a PDU session modification request. The identity of the network side device is sent to the second network side device or the fourth network side device, so that when the terminal establishes a PDU session or modifies the PDU session, the second network side device can learn the identity of the first network side device, thereby connecting the terminal The first URSP rule used by the target application reported through the session NAS message, and the first parameter of the first PDU session carrying the target application obtained by the second network side device are sent to the first network side device. For example, the first network side device may send the URSP rule to the terminal when the terminal registers with the network, and send the first indication information to the third network side device.

Optionally, in the above possible implementation manner, before the first network side device sends the first indication information to the third network side device, the first network side device receives the information sent by the third network side device. A first request message, the first request message is used to request to create or update a URSP rule for the terminal, the first request message carries The capability information of the terminal indicates that the terminal supports reporting the usage information of the URSP rules of the terminal. That is to say, the first network side device only sends the first indication information to the third network side device after learning that the terminal supports the use of the URSP rule that reports the terminal. For example, the terminal may carry the capability information of the terminal in the registration message, indicating that the terminal supports reporting the usage information of URSP rules.

In a possible implementation, the method may further include: the first network side device obtaining a third verification result sent by the second network side device, wherein the third verification result indicates the first PDU Whether the session includes data packets of the target application.

For example, the third verification result may include at least one of the following: the first PDU session includes the data packet of the target application, and the third verification is passed; the first PDU session does not include the data packet of the target application. , then the third verification fails.

One possible situation in a specific application is that although the terminal declares to use the first URSP rule, the network side does 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. However, it is possible that the terminal does not actually use this first PDU session to transmit application traffic, but uses other PDU sessions. Therefore, through the above possible implementation manner, the first network side device can determine whether the first PDU session actually carries the transmission of the application traffic.

For example, the second network side device may initiate the third verification when sending the target request information or before or after sending the target request information, that is, verifying whether the first PDU session includes the data packet of the target application, For example, the second network side device may generate a packet detection rule according to 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 the third verification As a result, the packet detection rule is used to verify whether the first PDU session includes the data packet of the target application, and then the third verification result is sent to the first network side device.

In a possible implementation, after performing S214 to obtain the second verification result, the first network side device may determine if the second verification result is the same as the first parameter in the first PDU session and the first URSP rule. If the second parameters described by the RSD are consistent, request information is sent to the second network side device to request the third verification result, so as to obtain 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 detection rule (Packet Detection Rule, PDR) according to the first URSP rule, and applies the packet detection rule to the first PDU session corresponding to the first PDU session identifier to perform packet detection.

In another possible implementation, the second network side device may not actively perform the third verification, but may perform the third verification after receiving a request from the first network side device. Therefore, in this possible implementation, the first network side device may send request information 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 the third verification. Whether a data packet of the target application is included in a PDU session, and then, a third verification result returned by the second network side device is received. That is to say, the second network side device first waits for the first network side device to complete the second verification. If the verification shows that the terminal passes the second verification and the URSP rules are used correctly, the second network side device starts from the first verification. The network side device receives the relevant request information and performs the third verification.

In the above possible implementation, the first network side device may initiate the third verification when 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, the second network side device is requested to perform the third verification, and 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. , then the verification of URSP rules ends.

In a possible implementation, the method may further include: in any of the following situations, the first network side device sends second indication information, wherein the second indication information is used to indicate that the terminal does not correctly Use URSP rules:

(1) The first verification result indicates that the first URSP rule is inconsistent with the second URSP rule; that is, in the case that the first URSP rule is inconsistent with the second URSP rule, the first The network side device determines that the terminal does not use URSP rules correctly.

(2) The second verification result indicates that the first parameter is inconsistent with the second parameter; that is, when at least one parameter in the first parameter is inconsistent with the second parameter, The first network side device determines that the terminal does not use URSP rules correctly.

(3) The third verification result indicates that the data packet of the target application is not included in the first PDU session. That is to say, when the transmission data packet corresponding to the first PDU session does not include the data packet of the target application, the first network side device determines that the terminal does not use the URSP rule correctly.

One possible way of sending the second indication information is: the first network side device sends it directly to the second network side device; or the first network side device sends it through the third network side device or the fourth network side device. to the second network side device.

For example, assuming that the first network side device is AM-PCF and the second network side device is SMF, AM-PCF can use at least one of the following signaling to send the second indication information to SMF: Npcf_EventExposure_Notify, Npcf_UEPolicyControl Update response.

Alternatively, the AM-PCF may use at least one of the following signaling to send the second indication information to the AMF: Npcf_UEPolicyControl_Update response; Npcf_UEPolicyControl_UpdateNotify notify. Then, the AMF uses at least one of the following signalings to SMF the second indication information: Nsmf_PDUSession_UpdateSMContext request, Nsmf_EventExposure_Subscribe.

Alternatively, AM-PCF may use at least one of the following signaling to send the second indication information to 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 to send the second indication information to the SMF: Npcf_SMPolicyControl_Updaterequest/response, Npcf_SMPolicyControl_createrequest/response.

After receiving the above-mentioned second indication information, the second network side device may perform corresponding operations, for example, reject the session establishment request or modification request corresponding to the first PDU session identifier, or release the session establishment request or modification request corresponding to the first PDU session identifier. The first PDU session corresponding to the session ID. Wherein, rejecting the session establishment request or modification request means rejecting the PDU session establishment request or modification request of the terminal that reports the first URSP rule. Or, because the terminal misuses URSP rules, the PDU session carrying this application will be released, or, before releasing this PDU session, the network side root According to the PDU session parameters indicated by the RSD in the first URSP rule, the establishment of a new PDU session is triggered, the application traffic is migrated to be carried on the new PDU session, and then the original session is released.

In a possible implementation, the method may further include: in any of the following situations, the first network side device updates the URSP rule of the terminal:

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

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

(3) The third verification result indicates that the transmission data packet corresponding to the first PDU session does not include the data packet of the target application.

In any of the above situations, the first network side device determines that the terminal does not use URSP rules correctly, and may update the URSP rules of the terminal, for example, re-execute the URSP policy of the terminal and deliver it to the terminal. This situation means that if the terminal does not use the rules correctly, it may be caused by unreasonable rule design, so the first network side device needs to update the URSP rules of the terminal.

Figure 3 shows another schematic flowchart of the verification method of URSP rules in the embodiment of the present application. The method 300 can be executed by the second network side device. In other words, the method may be executed by software or hardware installed on the second network side device. In this embodiment of the present application, the second network side device may be a session management network element. For example, the second network side device may be a session management function (Session Management Function, SMF). As shown in Figure 3, the method may include the following steps.

S310. The second network side device receives the reporting information sent by the terminal, where 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. A PDU session identifier is used to indicate the first PDU session.

For example, the terminal may send the reported information through an uplink NAS message. For example, the terminal uses URSP rules to match the traffic of the target application to a PDU session, or uses the RSD in the matched URSP rules to establish a new PDU session. The terminal reports the matched URSP rules (including RSD and/or TD) and indicates the PDU session identifier of the PDU session.

S312: The second network side device obtains the first parameter of the first PDU session.

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, that is, the first parameters.

S314: The second network side device sends target request information to the first network side device, where the target request information instructs the first network side device to verify whether the terminal uses URSP rules correctly. The request information includes the first URSP rule and the first parameter of the first PDU session.

For the manner in which the second network side device sends the target request information, please refer to the description in the above method 200, which will not be described again here.

In this embodiment of the present 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 by the first terminal side device to the terminal and to verify that the 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 learn the usage of the terminal's URSP rule to control the terminal.

In this embodiment of the present application, the first URSP rule executed by the terminal sent by the second network side device may be the first URSP rule used by the terminal for traffic of a certain application (such as a certain application provider A). The first URSP rule sent by the second network side device may be the traffic descriptor (Traffic descriptor) and the used RSD of the first URSP rule. The first URSP rule can be included in a container and sent to the first network side. The container carries the Traffic descriptor and RSD executed by the terminal, or the container carries the priority and RSD of the traffic descriptor (Traffic descriptor). priority.

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 matches the target application traffic to a PDU session, the terminal can report the PDU session ID to which the traffic matches, and 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. This attribute parameter includes but is not limited to at least one of the following: SSC mode, Access type, DNN, S-NSSAI, PDU session type.

In a possible implementation, the second network side device may not know the first network side device that sends the URSP rule for the terminal. Therefore, in a possible implementation, before S310, the method may further include: The second network side device obtains the identity of the first network side device. Wherein, the identification of the first network side device includes but is not limited to one of the following: an identifier of the first network side device or an IP address of the first network side device.

In this embodiment of the present application, the second network side device obtains the identity of the first network side device, including but not limited to any one of the following methods one to four.

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 to establish or update the context of the first PDU session, and the second The request message carries a target identifier, and the target identifier is used to indicate the first network side device that provides services for the terminal.

For example, when sending the URSP rule to the terminal, the first network side device may instruct the third network side device to send the first network side device to the second network side device when receiving a PDU session establishment request or a PDU session modification request sent by the terminal. If the third network side device receives the PDU session establishment request or the PDU session modification request from the terminal, the third network side device sends the second request information to the second network side device.

For example, when the first network side device (for example, AM-PCF) sends the URSP rule to the terminal, for example, it uses Namf_Communication_N1N2MessageTransfer signaling to send the URSP rule to the terminal, and the above signaling is sent to the third network side device (for example, , AMF) (the first network side device sends the URSP rule to the UE through the third network side device). Then, this signaling may also indicate that when the third network side device subsequently receives the PDU session establishment request or modification request sent by the terminal (indicated by the UE identifier SUPI), the third network side device will The identification of a network side device (for example, AM-PCFID) is sent to the second network side device (for example, SMF). For example, the third network side device sends the identification of the first network side device to the second network through the following signaling: Side device: Nsmf_PDUSession_CreateSMContext Request or Nsmf_PDUSession_UpdateSMContext Request.

Taking the first network side device as AM-PCF, the second network side device as SMF, and the third network side device as AMF as an example, Figure 4 shows the method for obtaining the identity of the first network side device in the embodiment of the present application. A schematic flow chart is shown in Figure 4. The method 400 mainly includes the following steps.

S401: The terminal sends a registration request (Registration Request) to the radio access network (RAN). Wherein, the terminal may report in the registration request that the terminal supports reporting of the use of URSP rules within the terminal (URSP enforcement).

Among them, the terminal can support reporting through NAS messages or DCAF reporting.

S402: The RAN forwards the registration request of the terminal to the AMF.

Among them, the RAN can add some terminal location information and then forward the registration request, which does not affect the terminal capability indication. Therefore, it can also be regarded as that the UE directly sends the registration request to the AMF.

S403: AMF selects AM-PCF.

S404: AMF triggers the UE's policy association establishment process (policy association establishment), or triggers the UE's policy association modification (policy association Modification) process.

For example, the AMF sends signaling: Npcf_UEPolicyControl Create Request, or Npcf_UEPolicyControl Update Request, and the signaling may carry terminal capability information. The capability information of the terminal refers to the URSP rules that the terminal supports reporting for use.

S405: After receiving the signaling, AM-PCF sends a response (response) to AMF.

S406: AM-PCF decides to send the terminal policy (UE policy) to the UE. At the same time, the AM-PCF finds that the terminal supports reporting of URSP rule execution, and the AM-PCF sends the UE policy to the UE and also instructs the AMF: when receiving the terminal's PDU session establishment request or PDU session When making a modification request, send the AM-PCF ID to SMF. Wherein, the SMF is used to manage the PDU session of the terminal.

Among them, the AM-PCF can instruct the AMF through the signaling Namf_Communication_N1N2MessageTransfer. The signaling can include an indication to instruct the AMF that when the terminal (which can be identified by SUPI) sends a PDU session establishment request or a PDU session modification request, the AMF The AM-PCF ID of the UE needs to be forwarded to the SMF and/or SM-PCF.

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

S408: The terminal establishes a PDU session and sends a PDU session establishment request (PDU session establishment request) or a PDU session modification request (PDU session modification request) to the AMF.

S409: AMF triggers context establishment in SMF and sends a request to establish or update the context of the PDU session to SMF. The request can carry the AM-PCF ID.

For example, AMF can send signaling: Nsmf_PDUSession_CreateSMContext Request, or Nsmf_PDUSession_UpdateSMContext Request, which carries the AM-PCF ID.

In the embodiment of this application, the reason why AMF carries AM-PCF ID to SMF is to verify or monitor the execution of URSP rules, because the verification or monitoring of specific URSP rule execution needs to be completed in AM-PCF, and SMF does not After the terminal receives the URSP rules actually reported by the UE, it still needs to send them to AM-PCF for verification, and this At this time, if AMF directly provides the AM-PCF ID for the terminal service, the process of SMF searching for AM-PCF can be omitted.

S410: SMF sends AM-PCFID to SM-PCF through the session management management association establishment (SM policy Association establishment) or session management management association modification (SM policy Association modification) process. For example, SMF can send signaling carrying AM-PCF ID to SM-PCF: Npcf_SMPolicyControl_Create or Npcf_SMPolicyControl_Update.

Since the SMF may subsequently communicate with the AM-PCF through the SM-PCF, after obtaining the AM-PCF ID, the SMF can execute S410 and send the AM-PCF ID to the AM-PCF.

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 identity of the first network side device from the context information of the terminal.

The first network side device (for example, AM-PCF) exists as a configuration of each terminal (per UE). The storage location of the identity of the first network side device is mainly saved in the third network side device (for example, AMF). In the UE context (UE context). Therefore, the context information of the terminal may be requested from the third network side device to obtain the identity of the first network side device.

Taking the first network side device as AM-PCF, the second network side device as SMF, and the third network side device as AMF as an example, Figure 5 shows the method for obtaining the identity of the first network side device in the embodiment of the present application. Another schematic flow chart is shown in Figure 5. The method 500 mainly includes the following steps.

S501: SMF sends a request to AMF, requesting to obtain the UE context (UE context) from AMF.

The signaling sent by SMF may be: Namf_Communication_UEContextTransfer Request, or other signaling, and the signaling may carry the identity of the terminal, for example, UE SUPI.

S502: AMF sends UE context to SMF.

The signaling sent by the AMF may be Namf_Communication_UEContextTransfer response, or other signaling, and the signaling carries the UE context. Among them, the UE context mainly stores information related to the terminal's access to the network and information related to the terminal's PDU session.

S503: SMF obtains the AM-PCF ID from the obtained UE context. The UE context contains a lot of content, from which SMF can find the AM-PCF ID of the service terminal.

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 to obtain the information of the first network side device that sends the URSP rule to the terminal. The identification, 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 first network side device (for example, AM-PCF) exists as a configuration of each terminal (per UE), and the storage location of the identity of the first network side device is mainly saved in the third network side device (for example, AMF) In the UE context (UE context). Therefore, the second network side device can directly request the third network side device for the tag of the first network side device. knowledge. Therefore, in this possible implementation, the second network side device obtains the identity of the first network side device by sending a fourth request message to the third network side device.

Taking the first network side device as AM-PCF, the second network side device as SMF, and the third network side device as AMF as an example, Figure 6 shows the method for obtaining the identity of the first network side device in the embodiment of the present application. Another schematic flow chart is shown in Figure 6. The method 600 mainly includes the following steps.

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

The signaling sent by SMF can be: Namf_Communication_N1MessageNotify Subscribe, or Namf_Communication_N1N2MessageSubscribe, or other signaling. The signaling may carry the identification of the terminal (for example, UE SUPI), and indicate that the subscribed information is the AM-PCF ID.

S602: AMF sends AM-PCF ID.

Among them, 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 identity.

Method 4: The second network side device sends a fifth request message to the fifth network side device, where the fifth request message is used to obtain the identity of the first network side device that sends the URSP rule to the terminal, so The fifth request message carries the identifier of the terminal; and the identifier of the first network-side device returned by the fifth network-side device is obtained. Because the fifth network side device stores the subscription information of each terminal, and the AM-PCF ID is a type of subscription information.

The identity of the first network-side device corresponding to the terminal can be stored in the fifth network-side device (for example, Unified Data Management (UDM)) as the terminal's subscription information. Therefore, in a possible implementation, the third The second network side device may obtain the identity of the first network side device by sending a fifth request message to the fifth network side device.

Taking the first network side device as AM-PCF, the second network side device as SMF, and the fifth network side device as UDM as an example, Figure 7 shows the method for obtaining the identity of the first network side device in the embodiment of the present application. Another schematic flow chart is shown in Figure 7. The method 700 mainly includes the following steps.

S701: AMF or AM-PCF is registered to UDM and becomes contract information, and UDM saves this information.

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

Among them, AM-PCF ID can be saved in UDM. For example, AM-PCF ID can be saved as access and mobility subscription information (Access and Mobility Subscription data). This subscription information must be obtained through SUPI.

S702: UDM returns a response indicating that a registration request has been received.

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

For example, SMF can send signaling: Nudm_SDM_Get or Nudm_SDM_Subscribe, which carries: the requested subscription data type is Access and Mobility Subscription data, and the data key is SUPI.

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

S705: UDM sends AM-PCF ID to SMF through notify signaling.

For example, UDM can send signaling: Nudm_SDM_Get Response, or Nudm_SDM_Notification, which carries AM-PCF ID.

In a possible implementation, after S312, the method may also include the following steps:

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

For example, after obtaining the second verification result, the first network side device may, if the second verification result indicates that the first parameter of the first PDU session is consistent with the second parameter of the RSD description of the first URSP rule, then the first network side device may A network side device may send request information to a second network side device, where the request information includes the first URSP rule, requesting the second network side device to verify whether the first PDU session includes data of the target application. Bag.

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. , wherein the packet detection rule is used to verify whether the first PDU session includes the data packet of the target application.

For example, the second network side device (eg, SMF) can generate a packet detection rule based on the traffic descriptor, such as the IP descriptor, in the first URSP rule sent by the first network side device (eg, AM-PCF). Or, the second network side device (for example, SMF) converts this traffic descriptor according to the traffic descriptor in the first URSP rule sent by the first network side device (for example, AM-PCF), for example, domain name descriptor FQDN, DNN, etc. FQDN, DNN, APP descriptors, connection capabilities, etc. are converted into IP descriptors, and then the packet detection rules are generated. Since the packet detection rule only has IP five-tuple, and in the first URSP rule, in addition to the IP descriptor can be directly used to generate packet detection rules, the other descriptors, such as APP descriptor, domain name descriptor, DNN, connection capabilities, etc., cannot directly generate Packet Detection Rules (PDR), but SMF can have the ability to convert the APP descriptor, domain name descriptor, DNN, connection capability and other descriptors into IP quintuple, or IP descriptor, the converted IP descriptor can then be used directly for PDR generation. Another way is that the 5G core network (5GC) (for example, AMF, AM-PCF, SM-PCF, etc.) has such conversion capabilities and will convert the APP descriptor, domain name descriptor, DNN, connection capability and other descriptors , converted into IP quintuple, or IP descriptor.

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

In a possible implementation, the method may also include the following steps:

Step 1: The second network side device obtains second indication information sent by the first network side device, where the second indication information is used to indicate that the terminal does not use URSP rules correctly;

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.

Wherein, rejecting the session establishment request or modification request means rejecting the PDU session establishment request or modification request of the terminal that reports the first URSP rule. Or, because the terminal misuses the URSP rule, the PDU session carrying the application will be released, or, before releasing the PDU session, the network side triggers the establishment of a new one based on the PDU session parameters indicated by the RSD in the first URSP rule. PDU session, migrate the application traffic to be carried on the new PDU session, and then release the original session.

Among them, the terminal's improper use of URSP rules includes one of the following:

(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 may obtain the first verification result through the above S210 and S212, and if the first verification result indicates that the first URSP rule is inconsistent with the second URSP rule, send the second network side device the second verification result. Instructions.

(2) At least one parameter among the first parameters is inconsistent with the second parameter. For example, the first network side device may verify 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, and report the request to the first network side device. The second network side device sends the second indication information. Alternatively, the first network side device receives the second verification result sent by the second network side device, and when the second verification result indicates that at least one of the first parameters is inconsistent with the second parameter, the first network side device sends a request to the second network side device. The side device sends the second indication information.

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

In the above possible implementation manner, after receiving the above 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 Release 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 is not established, after receiving the second indication information, reject the session establishment request to establish the first PDU session. Alternatively, when the first PDU session corresponding to the first PDU session identifier has been established, after receiving the second indication information, release the first PDU session corresponding to the first PDU session identifier. This prevents the terminal from transmitting data streams using PDU sessions that do not comply with the URSP rule instructions. Rejecting the session establishment request or session modification request refers to rejecting the PDU session establishment request or modification request of the terminal that reports the first URSP rule. Or, because the terminal misuses the URSP rule, the PDU session carrying the application will be released, or, before releasing the PDU session, the network side triggers the establishment of a new session based on the PDU session parameters indicated by the RSD in the first URSP rule. PDU session, migrate the application traffic to be carried on the new PDU session, and then release the original session.

For example, when the second network side device (SMF) receives the first instruction and the terminal does not use the URSP rules correctly, the second network side device performs at least one of the following:

1. Send PDU session establishment reject PDU session establishment reject to the terminal (can be forwarded to the terminal via AMF);

2. Send PDU session modification reject to the terminal (can be forwarded to the terminal via AMF);

3. The second network device triggers the PDU session release process and releases the first PDU session corresponding to the first PDU session identifier;

4. The second network device triggers the PDU session modification command PDU session modification command to the terminal (can (can be forwarded to the terminal via AMF); then, the terminal triggers a PDU session establishment request to the second network device (the session establishment request can be forwarded via AMF). In the embodiment of this application, 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 transfers the services carried in the first PDU session to Switch to the newly created PDU session. Finally, the terminal or the second network device releases the first PDU session.

In this embodiment of the present application, information can be transmitted directly between the first network side device and the second network side device. For example, the second network side device can first obtain the identity of the first network side device, and then directly communicate with the first network side device. side equipment for information transmission. Alternatively, the information transmission between the first network side device and the second network side device can also be carried out through the third network side device. For example, the first network side device and the second network side device control network elements through session management policies ( For example, the Session Management Policy Control Function (SM-PCF) transmits information. In the case of information transmission through SM-PCF, SM-PCF can use the SMF in Figure 4 to Figure 7 above to obtain AM-PCF. The AM-PCF ID is obtained in the form of PCF ID. Alternatively, the first network side device and the second network side device communicate through the access and mobility management network element (for example, Access and Mobility Management Function). Management Function (AMF) for information transmission.

Figure 8 shows another schematic flowchart of the verification method of URSP rules provided by the embodiment of the present application. The method 800 can be executed by the above-mentioned third network side device. In other words, the method 800 can be executed by the device installed on the third network side. Software or hardware on the device to execute. In this embodiment of the present application, the third network side device may be a session management policy control network element, such as SM-PCF, or the third network side device may be an access and mobility management network element, such as AMF. As shown in Figure 8, the method may include the following steps.

S810. The third network side device receives the target request information sent by the second network side device. The target request information instructs the first network side device to verify whether the terminal uses URSP rules correctly. The target request information includes The first URSP rule and the first parameter of the first PDU session.

The target request information is the same as the target request information in method 200 and method 300. Specifically, the descriptions in method 200 and method 300 can be parameterized.

The second network side device may send the target request information in the manner described in method 300. Specifically, the relevant description in method 300 may be parameterized.

S812: The third network side device sends the target request information to the first network side device.

In a possible implementation, before S810, the method may also include:

Step 1: The third network side device receives the first indication information sent by the first network side device, wherein the first indication information indicates that the third network side device receives the PDU sent by the terminal. After the session establishment request or the PDU session modification request, the identifier of the first network side device is sent to the second network side device.

The first network side device may send the first indication information in the manner described in the above embodiment. For details, please refer to the description in the above embodiment, which will not be described again here.

Step 2: The third network side device receives a PDU session establishment request or a PDU session modification request sent by the terminal, where the PDU session establishment request message or PDU session modification request is used to request establishment or modification. Change the first PDU session.

Step 3: The third network side device sends a second request message to the second network side device, where the second request message is used to request to establish or update the context of the first PDU session, and the third network side device The second request message carries a target identifier, and the target identifier is used to indicate the first network side device that provides services for the terminal.

Through the above possible implementation manner, the third network side device (for example, AMF) can receive the first indication information sent by the first network side device when the first network side device sends the URSP rule to the terminal. The first indication information The information instructs the third network side device to send the identification of the first network side device to the second network side device when receiving the PDU session establishment request or PDU session modification request sent by the terminal, and then The third network side device may send a second request message to the second network side device after receiving the PDU session establishment request or PDU session modification request sent by the terminal, wherein the second request message is used to request establishment or PDU session modification request. The context of the first PDU session is updated, and the identifier of the first network side device that provides services for the terminal is sent to the second network side device. For example, when the third network side device is an AMF, the AMF can provide the AM-PCF ID to the SMF according to the method shown in Figure 4.

In a possible implementation, before S810, the method may also include the following steps:

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 Context information of the terminal;

Step 2: The third network side device sends the context information of the terminal to the second network side device, where the context information includes the identification of the first network side device.

For example, when the third network side device is an AMF, the AMF can provide the AM-PCF ID to the SMF according to the method shown in Figure 5.

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 to obtain the first network side device that sends URSP rules to the terminal. The identification of the terminal is carried in the fourth request message;

Step 2: The third network side device sends the identity of the first network side device corresponding to the identity of the terminal to the second network side device.

For example, when the third network side device is an AMF, the AMF can provide the AM-PCF ID to the SMF according to the method shown in Figure 6.

In this embodiment of the present application, the third network side device may also transmit the first URSP rule, the second instruction information, the third verification result, etc. transmitted between the first network side device and the second network side device.

Wherein, the first network side device may send the request information through signaling interacted with the third network side device. For example, the interactive signaling between AM-PCF and AMF includes: AM-PCF through Namf_Communication

N1MessageNotify_Subscribe, send the request information; or, AM-PCF sends the request information Npcf_UEPolicyControl_Update response or Npcf_UEPolicyControl_UpdateNotify notify through at least one of the following; it can also be other signaling defined between AM-PCF and AMF.

Taking the first network side device as AM-PCF and the second network side device as SMF as an example, the following describes the verification method of URSP rules provided by the embodiment of the present application.

Figure 9 shows another schematic flow chart of the verification method of URSP rules provided by the embodiment of the present application. As shown in Figure 9, the method 900 mainly includes the following steps:

S901: SMF sends request information to AM-PCF.

Among them, the request information sent by SMF to AM-PCF includes:

(1) URSP rules executed by the terminal reported by the terminal.

For example, the terminal uses URSP rules for traffic of a certain application (such as application provider A). For example, Traffic descriptor, and the RSD used. This information can be included in a container, which carries the UE SUPI, the Traffic descriptor and RSD executed by the terminal; another method is that the container carries the priority of the Traffic descriptor and the priority of the RSD.

For example, the terminal executes a URSP rule for the traffic of APP1:

Rule Precedence＝1

Traffic Descriptor:Application descriptor=App1

Route Selection Descriptor Precedence＝1

Network Slice Selection:S-NSSAI-a

SSC Mode Selection:SSC Mode 3

DNN Selection:internet

Access Type preference:3GPP access

Then the execution results of the terminal can be sent in the following two ways:

The first one: Send Rule Precedence=1 and Route Selection Descriptor Precedence=1.

Second: Send the TD and RSD of the specific execution, including:

Traffic Descriptor:Application descriptor=App1

RSD 1:

Network Slice Selection:S-NSSAI-a

SSC Mode Selection:SSC Mode 3

DNN Selection:internet

Access Type preference:3GPP access

(2) The corresponding attribute parameters of the PDU session ID. When the terminal matches application traffic to a PDU session, the terminal can report the PDU session ID to which the traffic matches, and then SMF can also send the corresponding attribute parameters of the PDU session ID to AM-PCF. The corresponding attribute parameters of the PDU session ID include but are not limited to at least one of the following: SSCmode, Access type, DNN, S-NSSAI, PDU session type.

S902: AM-PCF verifies whether the terminal uses URSP rules correctly.

Specifically, AM-PCF can perform the following steps:

Step 1. According to the URSP rules reported by the UE, such as TD priority and RSD priority, restore RSD. parameters, and then compare them with the RSD reported by the terminal itself. If they are not the same, it is considered that the terminal does not use the URSP rules correctly. If they are the same, go to step 2;

Step 2: AM-PCF obtains the parameters described by the RSD in the URSP rules reported by the terminal, and compares the parameters with the parameters of the PDU session carrying the APP traffic reported by the SMF. If the parameters are the same, the terminal is considered to have used them correctly; if If they are not exactly the same, it is considered that the terminal does not use URSP rules correctly.

For example, the terminal reports the URSP rules used by itself, such as Rule Precedence=1 and Route Selection Descriptor Precedence=1;

Then based on this information, AM-PCF can obtain the URSP rules actually sent to the UE as follows:

Rule Precedence＝1

Traffic Descriptor:Application descriptor=App1

Route Selection Descriptor Precedence＝1

Network Slice Selection:S-NSSAI-a

SSC Mode Selection:SSC Mode 3

DNN Selection:internet

Access Type preference:3GPP access

The terminal itself reports a URSP rule used as follows:

Rule Precedence＝1

Traffic Descriptor:Application descriptor=App1

Route Selection Descriptor Precedence＝1

Network Slice Selection:S-NSSAI-a

SSC Mode Selection:SSC Mode 3

DNN Selection:internet

Access Type preference:3GPP access

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.

In the second step, AM-PCF needs 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.

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

Network Slice Selection:S-NSSAI-b

SSC Mode Selection:SSC Mode 3

DNN Selection:internet

Access Type preference:3GPP access

SM-PCF determined that the slices used by the two are different, therefore, it was determined that the terminal did not use the URSP rules correctly.

In other words, although the terminal reported the URSP rules it used, in fact, the traffic of the APP was not really Correctly use the PDU session bearer corresponding to this RSD.

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

Among others, the results can include:

(1)ACK: Indicates that the terminal has correctly used URSP rules. Then, AM-PCF can also instruct SMF to perform the third verification, that is, the packet inspection process. The ACK here may indicate that both the first verification and the second verification are passed, or may indicate that any one verification, such as the first verification or the second verification is passed.

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

According to the verification results of AM-PCF's use of terminal URSP rules, SMF or SM-PCF can perform corresponding operations. For example, SMF rejects the session establishment request corresponding to the PDU session ID; or SMF releases the session establishment request corresponding to the PDU session ID. PDU session; or, SMF first establishes a new PDU session, then migrates the APP traffic to the new PDU session, and then releases the PDU session corresponding to the old PDU session ID.

Figure 10 shows another schematic flow chart of the verification method of URSP rules provided by the embodiment of the present application. As shown in Figure 10, the method 1000 mainly includes the following steps:

S1001, SMF sends request information to AMF, and the request information requests AM-PCF to perform verification of URSP rules.

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.

S1002. The AMF finds the corresponding AM-PCF according to the terminal identifier, and forwards the request information to the AM-PCF.

S1003, AM-PCF verifies whether the terminal uses URSP rules correctly.

This step is the same as S902 in method 900. For details, please refer to the relevant description in method 900.

S1004, AM-PCF sends the result of URSP rule execution verification to AMF.

The result of the verification of the URSP rule is the same as the result of the verification of the URSP rule in method 900. For details, please refer to the relevant description in method 900.

S1005, AMF sends the result of URSP rule execution verification to SMF.

After SMF receives the results of URSP rule execution verification, it can perform corresponding operations.

Figure 11 shows another schematic flow chart of the verification method of URSP rules provided by the embodiment of the present application. As shown in Figure 11, the method 1100 mainly includes the following steps:

S1101, SMF sends request information to SM-PCF, and the request information requests AM-PCF to perform verification of URSP rules.

The request information is the same as the request information in S901 of method 900. For details, please refer to the relevant description of method 900.

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

Among them, SM-PCF can obtain the AM-PCF ID using the same method as SMF in Figures 4 to 7.

S1103, AM-PCF verifies whether the terminal uses URSP rules correctly.

S1104, AM-PCF sends the result of URSP rule execution verification to SM-PCF.

The result of the verification performed by this URSP rule is the same as the result of the verification performed by the URSP rule in method 900. Specifically, Please refer to the relevant description in method 900.

S1105, SM-PCF sends the result of URSP rule execution verification to SMF.

Figure 12 shows another schematic flow chart of the URSP rule verification method provided by the embodiment of the present application. As shown in Figure 12, the method 1200 mainly includes the following steps:

S1201, SMF sends request information to SM-PCF, and the request information requests AM-PCF to perform verification of URSP rules.

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

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

S1204, AM-PCF verifies whether the terminal uses URSP rules correctly.

S1205, AM-PCF sends the result of URSP rule execution verification to AMF.

S1206, AMF sends the result of URSP rule execution verification to SM-PCF.

S1207, SM-PCF sends the result of URSP rule execution verification to SMF.

Figure 13 shows another schematic flow chart of the URSP rule verification method provided by the embodiment of the present application. As shown in Figure 13, the method 1300 mainly includes the following steps:

S1301. The terminal uses URSP rules to match the APP process to a PDU session, or uses the RSD in the matched URSP rules to establish a new PDU session.

S1302: The terminal sends the used URSP rules, RSD, and PDU session identifiers to the AMF through the uplink NAS message.

S1303: AMF sends the URSP rule, RSD, and PDU session identifier to SMF through the uplink NAS message.

S1304. The SMF obtains the AM-PCF corresponding to the terminal. For example, SMF can obtain the AM-PCF ID corresponding to the terminal through the methods shown in Figure 4 to Figure 7.

S1305. The SMF sends request information to the AM-PCF. The request information includes the URSP rules executed by the terminal reported by the terminal and the PDU session parameters of the APP flow reported by the terminal.

AM-PCF performs the first verification and the second verification. If the verification fails, S1306 is executed. If the verification is successful, the third verification is triggered and S1306 is executed.

S1306, AM-PCF sends the verification result to SMF, indicating that the verification failed and the terminal did not use the URSP rules correctly, so the intermediate process is skipped and S1314 is executed directly.

S1307, AM-PCF sends the URSP rules that need to be monitored to SMF. The URSP rules are used to generate packet detection. Rules can also include the terminal's SUPI and PDU session ID. This step can be performed on the premise that the first and second verifications pass.

S1308, SMF converts TD into required packet inspection rules (for example, converts FQDN, application descriptor, etc. into destination IP triples for packet inspection). The packet inspection rules are performed in the PDU session corresponding to the PDU session identifier. detection.

S1309: The SMF determines the UPF corresponding to the PDU session identifier serving the terminal.

S1310, SMF sends the packet detection rules to UPF. SMF can also instruct UPF to perform packet inspection within a specified time.

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

S1312, UPF sends a detection report to SMF and feeds back the detection results. That is, whether the target data packet is detected within the specified time. The detection results include: detected or not detected.

S1313: Within the predetermined time, packet detection ends, and the SMF sends the packet detection result to AM-PCF.

S1314. AM-PCF obtains the verification result of the terminal's URSP rules. If the verification result indicates that the terminal does not use the URSP rules correctly, S1315 is executed.

S1315, AM-PCF adjusts the URSP rules in the terminal according to the URSP rules reported by the terminal.

S1316, AM-PCF indicates SMF: the terminal does not use URSP rules correctly.

S1317: The SMF rejects the establishment request of the PDU session or releases the PDU session or modifies the parameters of the PDU session.

Figure 14 shows another schematic flow chart of the verification method of URSP rules provided by the embodiment of the present application. As shown in Figure 14, the method 1400 mainly includes the following steps:

S1401. The terminal uses URSP rules to match the APP process to a PDU session, or uses the RSD in the matched URSP rules to establish a new PDU session.

S1402: The terminal sends the used URSP rules and RSD and PDU session identifiers to the AMF through the uplink NAS message.

S1403: AMF sends the URSP rule, RSD, and PDU session identifier to SMF through the uplink NAS message.

S1404, SMF obtains the AM-PCF corresponding to the terminal. For example, SMF can obtain the AM-PCF ID corresponding to the terminal through the methods shown in Figure 4 to Figure 7.

S1405. The SMF sends request information to the SM-PCF. The request information includes the URSP rules executed by the terminal reported by the terminal and the PDU session parameters of the APP flow reported by the terminal.

S1406: SM-PCF forwards the request information to AM-PCF to send the request information.

In S1407, AM-PCF performs the first verification and the second verification. If the verification fails, S1408 is executed. If the verification is successful, the third verification is triggered and S1409 is executed.

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

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

S1410, AM-PCF sends URSP rules that need to be monitored to SM-PCF. The URSP rules are used to generate packet detection rules and can also include the terminal's SUPI and PDU session ID.

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

S1412, SMF converts TD into necessary packet detection rules (for example, converts FQDN, application descriptor, etc. into destination IP triples for packet detection). The packet detection rules are detected in the PDU session corresponding to the PDU session identifier. .

S1413. The SMF determines the UPF corresponding to the PDU session identifier serving the terminal.

S1414, SMF sends the packet detection rules to UPF. SMF can also instruct UPF to perform packet inspection within a specified time.

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

S1416, UPF sends a detection report to SMF and feeds back the detection results. That is, whether the target data packet is detected within the specified time. The detection results include: detected or not detected.

S1417: Within the predetermined time, the packet detection ends, and the SMF sends the packet detection result to the SM-PCF.

S1418, SM-PCF sends the packet detection result to AM-PCF.

S1419, AM-PCF obtains the verification result of the terminal's URSP rules. If the verification result indicates that the terminal does not use the URSP rules correctly, S1415 is executed.

S1420: AM-PCF adjusts the URSP rules in the terminal according to the URSP rules reported by the terminal.

S1421, AM-PCF sends indication information to SM-PCF. The indication information indicates that the terminal does not use URSP rules correctly.

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

S1423. The SMF rejects the establishment request of the PDU session or releases the PDU session or modifies the parameters of the PDU session.

In a possible implementation, SMF and AM-PCF can also communicate through AMF. The specific process is similar to the above-mentioned method 1300 and method 1400, and will not be described again here.

In a possible implementation, SMF and AM-PCF can also communicate through AMF and SM-PCF. The specific process is similar to the above-mentioned method 1300 and method 1400, and will not be described again here.

For the verification method of URSP rules provided by the embodiments of this application, the execution subject may be a verification device of URSP rules. In the embodiment of the present application, the verification device of the URSP rule executes the verification method of the URSP rule as an example to illustrate the implementation of the present application. The embodiment provides a verification device for URSP rules.

Figure 15 shows a schematic structural diagram of a verification device for URSP rules provided by an embodiment of the present application. As shown in Figure 15, the device 1500 mainly includes: a first acquisition module 1501, a first verification module 1502 and a second verification module 1503 .

In this embodiment of the present application, the first acquisition module 1501 is used to acquire the target request information sent by the second network side device, where the target request information includes: the first URSP rule used by the terminal for the target application and the first URSP rule that carries the The first parameter of the first PDU session of the target application; the first verification module 1502 is used to obtain the first verification result by verifying whether the first URSP rule and the second URSP rule are consistent, wherein the second URSP rule It 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 the first parameter of the first PDU session and the first Whether the second parameter described by the routing descriptor RSD in the URSP rule is consistent, the second verification result is obtained.

In a possible implementation, the first parameter includes at least one of the following: PDU session type, access type of PDU session, 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, SSC mode, network slice identifier, and DNN.

In a possible implementation, the first obtaining module 1501 obtains the target request information sent by the second network side device, including one of the following:

Receive the target request information from the second network side device;

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.

In a possible implementation, as shown in Figure 15, the device may further include: a first transceiver module 1504, configured to send URSP rules to the terminal; and send first indication information to the third network side device, where , the first instruction information instructs the third network side device to send 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. logo.

In a possible implementation, the first transceiver module 1504 is also configured to receive a first request message sent by the third network side device, where the first request message is used to request to create or update a URSP rule for the terminal. , the first request message carries capability information of the terminal, and the capability information indicates that the terminal supports reporting the usage information of the URSP rule of the terminal.

In a 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:

When the first verification result indicates that the first URSP rule is consistent with the second URSP rule, the first network side device verifies that the first parameter of the first PDU session is consistent with the first URSP rule. Whether the second parameter described by RSD in the rule is consistent.

In a possible implementation, the first obtaining module 1501 is also configured to obtain a third verification result sent by the second network side device, wherein the third verification result indicates that the first PDU session Whether to include the data packet of the target application.

In a possible implementation, the first acquisition module 1501 is also configured to send the first network side device second indication information in any of the following situations, where the second indication information is used to indicate The endpoint in question is not using URSP rules correctly:

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 is inconsistent with the second parameter;

The third verification result indicates that the data packet of the target application is not included in the first PDU session.

In a possible implementation, as shown in Figure 15, the device may also include: an update module 1505, configured to update the URSP rules of the terminal in any of the following situations:

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

Figure 16 shows another schematic structural diagram of a URSP rule verification device provided by an embodiment of the present application. As shown in Figure 16, the device 1600 mainly includes: a second transceiver module 1601 and a second acquisition module 1602.

In this embodiment of the present application, the second transceiver module 1601 is used to receive reporting information sent by the terminal, where the reporting information includes: the first URSP rule used by the terminal for the target application and the third URSP rule carrying the target application. A PDU session identifier, the first PDU session identifier is 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 also used For sending 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 uses URSP rules correctly, and the target request information includes the first URSP rules and the first parameter of the first PDU session.

In a possible implementation, the second obtaining module 1602 is also configured to obtain the identity of the first network side device.

In a possible implementation, the second acquisition module acquires 1602 the identity of the first network side device, including one of the following:

Receive 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, the second request message carries a target identifier, and the The target identifier is used to indicate the first network side device that provides services for 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 context information of the terminal; receive the third request message. The context information of the terminal returned by the third network side device is used to obtain the identity 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 to obtain the identity of the first network side device that sends the URSP rule to the terminal, and the fourth request message carries having the identification of the terminal; receiving the identification of the first network side device returned by the third network side device;

Send a fifth request message to the fifth network side device, wherein the fifth request message is used to obtain the identity of the first network side device that sends the URSP rule to the terminal, and the fifth request message carries the The identification of the terminal; Obtain the identification of the first network side device returned by the fifth network side device.

In a possible implementation, as shown in Figure 16, the device may also include:

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, and apply the packet detection rule to the first The first PDU session indicated by the PDU session identifier obtains a third verification result, wherein the packet detection rule is used to verify whether the first PDU session includes the data packet of the target application.

In a possible implementation, the second acquisition module 1602 is also 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 does not use the URSP rules correctly. ;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.

In a possible implementation, the incorrect use of URSP rules by the terminal includes at least one of the following:

Whether the first URSP rule is consistent 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;

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

The first PDU session does not include the data packet of the target application.

Figure 17 shows another schematic structural diagram of a URSP rule verification device provided by an embodiment of the present application. As shown in Figure 17, the device 1700 mainly includes: a receiving module 1701 and a sending module 1702.

In this embodiment of the present 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 uses URSP rules correctly, The target request information includes the first URSP rule and the first parameter of the first PDU session; the sending module 1702 is configured to send the target request information to the first network side device.

In a 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 indicates that the third network side device receives After the terminal sends a PDU session establishment request or a PDU session modification request, send the identification of the first network side device to the second network side device; 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 also used to send a second request to the second network side device. message, wherein the second request message is used to request the establishment or update of the context of the first PDU session, the second request message carries a target identifier, and the target identifier is used to indicate providing services to the terminal. the first network side device.

In a possible implementation, the receiving module 1701 is also configured to receive a third request message sent by the second network side device, where the third request message carries the identification of the terminal, so The third request is used to obtain the context information of the terminal; the sending module 1702 is also used to send the context information of the terminal to the second network side device, wherein the context information includes the third An identification of the network side device.

In a possible implementation, the receiving module 1701 is also configured to receive a fourth request message sent by the second network side device, wherein the fourth request message is used to request to obtain the URSP sent to the terminal. Rule No. An identifier of a network-side device, and the fourth request message carries the identifier of the terminal; the sending module 1702 is also configured to send the identifier of the first network-side device corresponding to the identifier of the terminal. to the second network side device.

The verification device of the URSP rules in the embodiment of the present application may be an electronic device, such as an electronic device with an operating system, or may be a component in the electronic device, such as an integrated circuit or chip.

The URSP rule verification device provided by the embodiment of the present application can implement each process implemented by the method embodiments of Figures 2 to 14, and achieve the same technical effect. To avoid duplication, the details will not be described here.

Optionally, as shown in Figure 18, this embodiment of the present application also provides a communication device 1800, including a processor 1801 and a memory 1802. The memory 1802 stores programs or instructions that can be run on the processor 1801, for example. , when the communication device 1800 is a network-side device, when the program or instruction is executed by the processor 1801, each step of the above-mentioned URSP rule verification method embodiment is implemented, and the same technical effect can be achieved. To avoid duplication, it will not be described again here. .

An embodiment of the present application also provides a network-side device, including a processor and a communication interface. The processor is used to implement each step of the above URSP rule verification method embodiment, and the communication interface is used to communicate with an external device. This network-side device embodiment corresponds to the above-mentioned network-side device method embodiment. Each implementation process and implementation manner of the above-mentioned method embodiment can be applied to this network-side device embodiment, and can achieve the same technical effect.

Specifically, the embodiment of the present application also provides a network side device. As shown in Figure 19, the network side device 1900 includes: a processor 1901, a network interface 1902, and a memory 1903. Among them, the network interface 1902 is, for example, a common public radio interface (CPRI).

Specifically, the network side device 1900 in this embodiment of the present invention also includes: instructions or programs stored in the memory 1903 and executable on the processor 1901. The processor 1901 calls the instructions or programs in the memory 1903 to execute Figures 15 to 17 The execution methods of each module are shown and achieve the same technical effect. To avoid repetition, they will not be described in detail here.

Embodiments of the present application also provide a readable storage medium. Programs or instructions are stored on the readable storage medium. When the program or instructions are executed by a processor, each process of the above-mentioned URSP rule verification method embodiment is implemented, and can To achieve the same technical effect, to avoid repetition, we will not repeat them here.

Wherein, the processor is the processor in the terminal described in the above embodiment. 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, etc.

An embodiment of the present application further provides a chip. The chip 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 verification method of the above URSP rules. Each process in the example can achieve the same technical effect. To avoid repetition, we will not repeat it here. It should be understood that the chips mentioned in the embodiments of this application may also be called system-on-chip, system-on-a-chip, system-on-chip or system-on-chip, etc.

Embodiments of the present application further provide a computer program/program product. The computer program/program product is stored in a storage medium. The computer program/program product is executed by at least one processor to implement the above verification method of URSP rules. Each process of the embodiment can achieve the same technical effect, so to avoid repetition, it will not be described again here.

The embodiment of the present application also provides a verification system for URSP rules, including: a first network side device and a second network side device. Network side device, the first network side device can be used to perform the steps performed by the first network side device in the verification method of the URSP rule as described above, and the second network side device can be used to perform the steps of the URSP rule as described above. Steps performed by the second network side device in the verification method.

Optionally, the URSP rule verification system may further include a third network side device, and the third network side device may be configured to perform the steps performed by the third network side device in the URSP rule verification method as described above.

It should be noted that, in this document, the terms "comprising", "comprises" or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article or device that includes a series of elements not only includes those elements, It also includes other elements not expressly listed or inherent in the process, method, article or apparatus. Without further limitation, an element defined by the statement "comprises a..." does not exclude the presence of additional identical elements in a process, method, article or apparatus that includes that element. In addition, it should be pointed out that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, but may also include performing functions in a substantially simultaneous manner or in reverse order according to the functions involved. Functions may be performed, for example, the methods described may be performed in an order different from that described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

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 the necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases the former is better. implementation. Based on this understanding, the technical solution of the present application can be embodied in the form of a computer software product that is essentially or contributes to the existing technology. The computer software product is stored in a storage medium (such as ROM/RAM, disk , CD), including several instructions to cause a terminal (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in various embodiments of this application.

The embodiments of the present application have been described above in conjunction with the accompanying drawings. However, the present application is not limited to the above-mentioned specific implementations. The above-mentioned specific implementations are only illustrative and not restrictive. Those of ordinary skill in the art will Inspired by this application, many forms can be made without departing from the purpose of this application and the scope protected by the claims, all of which fall within the protection of this application.

Claims

A verification method for user equipment routing option policy URSP rules, including:

The first network side device obtains the 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 protocol data unit PDU session carrying the target application. The first parameter;

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 sent by the first network side device to the terminal. At least one URSP rule corresponding to the target application;

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 a second verification result.
The method of claim 1, wherein,

The first parameter includes at least one of the following: PDU session type, access type of PDU session, 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, access type of PDU session, session and service continuity SSC mode, network slice identifier, and data network name DNN.
The method according to claim 1, wherein the first network side device obtains the 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.
The method according to claim 1, wherein 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 a URSP rule to the terminal;

The first network side device sends first indication information to the third network side device, wherein the first indication information indicates that the third network side device receives a PDU session establishment request or a PDU session modification from the terminal. After the request, send the identification of the first network side device to the second network side device.
The method according to claim 4, wherein 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 to create or update a URSP rule for the terminal. The first request message carries The capability information of the terminal indicates that the terminal supports reporting the usage information of the URSP rules of the terminal.
The method according to any one of claims 1 to 5, wherein the first network side device verifies that the first parameter of the first PDU session is described by the routing descriptor RSD in the first URSP rule. Whether the second parameter is consistent, including:

In the case where 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.
The method according to any one of claims 1 to 5, wherein 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 the data packet of the target application.
The method of claim 7, further comprising:

In any of the following situations, the first network side device sends second indication information, where the second indication information is used to indicate that the terminal does not use URSP rules correctly:

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 is inconsistent with the second parameter;

The third verification result indicates that the data packet of the target application is not included in the first PDU session.
The method of claim 7, further comprising:

In any of the following situations, the first network side device updates the URSP rule of the terminal:

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 data packet of the target application is not included in the first PDU session.
The method according to any one of claims 1 to 9, wherein information transmission is performed directly between the first network side device and the second network side device, or the first network side device and the second network side device Information is transmitted between the second network side devices through the third network side device.
A verification method for URSP rules, including:

The second network side device receives the reporting information sent by the terminal, where 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 The 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 uses the URSP rule correctly, and the target request information The first URSP rule and the first parameter of the first PDU session are included.
The method according to claim 11, wherein 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 identity of the first network side device.
The method according to claim 12, wherein the second network side device obtaining the identity of the first network side device includes 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. In the second request message Carrying a target identifier, the target identifier is used to indicate the first network side device that provides services for the terminal;

The second network side device sends a third request message to the third network side device, where the third request message carries the identifier of the terminal, and the third request is used to obtain the identifier of the terminal. Context information; the second network side device receives the context information of the terminal returned by the third network side device, and obtains the identity 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 to obtain the identity of the first network side device that sends the URSP rule to the terminal, so 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 identity of the first network side device that sends the URSP rule to the terminal, and the fifth network side device The request message carries the identifier of the terminal; and the identifier of the first network-side device returned by the fifth network-side device is obtained.
The method according to any one of claims 11 to 13, wherein 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 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, wherein, The packet detection rule is used to verify whether the first PDU session includes the data packet of the target application;

The second network side device sends the third verification result to the first network side device.
The method of claim 14, wherein the method further includes:

The second network side device obtains second indication information sent by the first network side device, wherein the second indication information is used to indicate that the terminal does not use URSP rules correctly;

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.
The method according to claim 15, wherein the incorrect use of URSP rules by the terminal includes at least one of the following:

Whether the first URSP rule is consistent 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;

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

The first PDU session does not include the data packet of the target application.
The method according to any one of claims 10 to 16, wherein information is transmitted directly between the second network side device and the first network side device, or the second network side device and the first network side device Information is transmitted between the first network side devices through the third network side device.
A verification method for URSP rules, including:

The third network side device receives the 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 uses URSP rules correctly, and the target request information packet including 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 according to claim 18, wherein before the third network side device receives the target request information sent by the second network side device, the method further includes:

The third network side device receives the first indication information sent by the first network side device, wherein the first indication information indicates that the third network side device receives the PDU session establishment request sent by the terminal. or after the PDU session modification request, send the identification 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 PDU session modification request is used to request establishment or modification of the first PDU Conversation;

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 to establish or update the context of the first PDU session, and the second request message carries a target identifier, and the target identifier is used to indicate the first network side device that provides services for the terminal.
The method according to claim 18, wherein 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 contextual information;

The third network side device sends the context information of the terminal to the second network side device, where the context information includes the identification of the first network side device.
The method according to claim 18, wherein 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 to obtain the identity of the first network side device that sends the URSP rule to the terminal, The fourth request message carries the identification of the terminal;

The third network side device sends the identity of the first network side device corresponding to the identity of the terminal to the second network side device.
A verification device for URSP rules, including:

The first acquisition module is configured to acquire the target request information sent by the second network side device, where the target request information includes: the first URSP rule used by the terminal for the target application and the first PDU session carrying the target application. first parameter;

A first verification module, configured 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 sent by the first network side device to the terminal At least one URSP rule corresponding to the target application;

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 obtain a second verification result.
The device of claim 22, wherein the device further comprises:

The first transceiver module is configured to send URSP rules to the terminal; send first indication information to the third network side device, wherein the first indication information indicates that the third network side device receives the request from the terminal. After the PDU session establishment request or the PDU session modification request, the identifier of the first network side device is sent to the second network side device.
The apparatus according to claim 23, wherein 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 to create a Or update the URSP rule, the first request message carries capability information of the terminal, and the capability information indicates that the terminal supports reporting the usage information of the URSP rule of the terminal.
The apparatus according to any one of claims 22 to 24, wherein 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 the data packet of the target application.
The device of claim 25, wherein the device further comprises:

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 data packet of the target application is not included in the first PDU session.
A verification device for URSP rules, including:

The second transceiver module is configured to receive reporting information sent by the terminal, where 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, and the third A PDU session identifier is used to indicate the first PDU session;

A second acquisition module, configured to acquire the first parameter of the first PDU session;

The second transceiver module is also 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 uses URSP rules correctly, and the The target request information includes the first URSP rule and the first parameter of the first PDU session.
The apparatus according to claim 27, wherein the second obtaining module is further used to obtain the identity of the first network side device.
The apparatus according to claim 28, wherein the second acquisition module acquires the identity of the first network side device, including one of the following:

Receive 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, the second request message carries a target identifier, and the The target identifier is used to indicate the first network side device that provides services for 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 context information of the terminal; receive the third request message. The context information of the terminal returned by the third network side device is used to obtain the identity of the first network side device from the context information of the terminal;

Send a fourth request message to the third network side device, where the fourth request message is used to request to obtain the The terminal sends the identifier of the first network-side device of the URSP rule, and the fourth request message carries the identifier of the terminal; receives the identifier of the first network-side device returned by the third network-side device;

Send a fifth request message to the fifth network side device, wherein the fifth request message is used to obtain the identity of the first network side device that sends the URSP rule to the terminal, and the fifth request message carries the The identification of the terminal; obtaining the identification of the first network side device returned by the fifth network side device.
The device according to any one of claims 27 to 29, wherein the device further comprises:

A third verification module, configured to obtain the first URSP rule sent by the first network side device, generate a packet detection rule according to the first URSP rule, and apply the packet detection rule to the first PDU The first PDU session indicated by the session identifier obtains a third verification result, wherein the packet detection rule is used to verify whether the first PDU session includes the data packet of the target application.
A verification device for URSP rules, including:

A receiving module 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 uses URSP rules correctly, and the target request information includes the The first URSP rule and the first parameter of the first PDU session;

A sending module, configured to send the target request information to the first network side device.
The device of claim 31, wherein:

The receiving module is further configured to receive first indication information sent by the first network side device, wherein the first indication information indicates that the third network side device establishes a session after receiving the PDU sent by the terminal. After the request or the PDU session modification request, send the identification of the first network side device to the second network side device; receive the PDU session establishment request or the PDU session modification request sent by the terminal, wherein the PDU session establishment A request message or PDU session modification request, used to request the establishment or modification of the first PDU session;

The sending module is also configured to send a second request message to the second network side device, wherein the second request message is used to request to establish or update the context of the first PDU session, and the second request The message carries a target identifier, and the target identifier is used to indicate the first network side device that provides services for the terminal.
The device of claim 31, wherein:

The receiving module is also configured to receive a third request message sent by the second network side device, wherein the third request message carries the identification of the terminal, and the third request is used to obtain the Terminal context information;

The sending module is further configured to send context information of the terminal to the second network side device, where the context information includes an identifier of the first network side device.
The device of claim 31, wherein:

The receiving module is also configured to receive a fourth request message sent by the second network side device, wherein the fourth request message is used to request to obtain the identity of the first network side device that sends the URSP rule to the terminal. , the fourth request message carries the identification of the terminal;

The sending module is further configured to send the identity of the first network side device corresponding to the identity of the terminal to the second network side device.
A network side device, including a processor and a memory. The memory stores programs or instructions that can be run on the processor. When the program or instructions are executed by the processor, any one of claims 1 to 21 is implemented. Steps for the verification method of URSP rules as described in the item.
A readable storage medium on which a program or instructions are stored. When the program or instructions are executed by a processor, the steps of the URSP rule verification method according to any one of claims 1 to 21 are implemented.