WO2023213282A1 - Ursp规则的验证方法、装置及网络侧设备 - Google Patents

Ursp规则的验证方法、装置及网络侧设备 Download PDF

Info

Publication number
WO2023213282A1
WO2023213282A1 PCT/CN2023/092149 CN2023092149W WO2023213282A1 WO 2023213282 A1 WO2023213282 A1 WO 2023213282A1 CN 2023092149 W CN2023092149 W CN 2023092149W WO 2023213282 A1 WO2023213282 A1 WO 2023213282A1
Authority
WO
WIPO (PCT)
Prior art keywords
network side
side device
pdu session
verification result
parameter
Prior art date
Application number
PCT/CN2023/092149
Other languages
English (en)
French (fr)
Inventor
吕华章
柯小婉
王文
张奕忠
Original Assignee
维沃移动通信有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 维沃移动通信有限公司 filed Critical 维沃移动通信有限公司
Publication of WO2023213282A1 publication Critical patent/WO2023213282A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/11—Allocation or use of connection identifiers

Definitions

  • 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.
  • the application 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 (User Equipment, UE) (OS Operating system 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.
  • TD Traffic Descriptor
  • the terminal After matching a certain traffic descriptor, then The terminal then selects a route selection descriptor (Route Selection Descriptor, RSD) under the traffic descriptor.
  • RSD Route Selection 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 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 the application traffic, then the data to be transmitted for the application can be routed to the established protocol data Unit (Protocol Data Unit, PDU) session.
  • PDU Protocol Data Unit
  • 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.
  • URSP rules are only the behavior of the terminal device.
  • 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.
  • 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.
  • a method for verifying URSP rules including: a first network side device receiving reporting information sent by a terminal, wherein the reporting information includes the first URSP rule used by the terminal for a target application and the bearer The first PDU session identifier of the target application, the first PDU session identifier is used to indicate the first PDU session; the first network side device obtains the first PDU session identifier by verifying whether the first URSP rule and the second URSP rule are consistent.
  • a verification result 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; when the first verification result indicates that the first When the URSP rules are consistent with at least one of the second URSP rules, the first network side device obtains a second verification result through the second network side device, wherein the second verification result indicates that the first Whether the first parameter of the PDU session is consistent with the second parameter described by the routing descriptor RS D in the first URSP rule; the first network side device obtains the third verification result through the second network side device, Wherein, the third verification result indicates whether the first PDU session includes the data packet of the target application.
  • another method for verifying URSP rules including: the second network side device determines a second verification result by interacting with the first network side device, wherein the second verification result indicates the first Whether the first parameter of the PDU session is consistent with the second parameter described by the RSD in the first URSP rule used by the terminal for the target application; the second network side device verifies whether the first PDU session includes the The data packet of the target application is obtained, and the third verification result indicates whether the first PDU session includes the data packet of the target application.
  • another method for verifying URSP rules including: a third network side device receiving request information sent by the first network side device, wherein the request information includes: a first PDU session identifier and/or Or a first URSP rule, the first PDU session indicated by the first PDU session identifier is a PDU session carrying a target application of the terminal, and the first URSP rule is a URSP rule used by the terminal for the target application;
  • the third network side device sends the request message information to the second network side device; wherein the request information is used for at least one of the following: requesting to obtain the first parameter of the first PDU session; requesting to verify all Whether the first parameter of the first PDU session is consistent with the second parameter described by the RSD in the first URSP rule; requesting whether the first PDU session includes the target application according to the first URSP rule. data pack.
  • a device for verifying URSP rules including: a first receiving module configured to receive reporting information sent by a terminal, wherein the reporting information includes the terminal's target The first URSP rule used by the application and the first PDU session identifier carrying the target application, the first PDU session identifier is used to indicate the first PDU session; the first acquisition module is used to verify the first URSP rule whether it is consistent with the second URSP rule, and obtain the first verification result, 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; second Obtaining module, configured to obtain a second verification result, wherein the second verification result indicates the first parameter of the first PDU session and the second parameter described by the routing descriptor RSD in the first UR SP rule Whether they are consistent; obtain a third verification result through the second network side device, where the third verification result indicates whether the first PDU session includes the data packet of the target application.
  • another verification device for URSP rules including: a determination module configured to determine a second verification result by interacting with the first network side device, wherein the second verification result indicates the first verification result of the terminal. Whether the first parameter of the PDU session is consistent with the second parameter described by the RSD in the first URSP rule used by the terminal for the target application; the third acquisition module is used to verify whether the first PDU session includes the The data packet of the target application is obtained, and the third verification result indicates whether the first PDU session includes the data packet of the target application.
  • another device for verifying URSP rules including: a second receiving module configured to receive request information sent by the first network side device, wherein the request information includes: a first PDU session identifier and/or a first URSP rule, the first PDU session indicated by the first PDU session identifier is a PDU session carrying the target application of the terminal, and the first URSP rule is the URSP used by the terminal for the target application.
  • a sending module configured to send the request information to the second network side device; wherein the request information is used for at least one of the following: requesting to obtain the first parameter of the first PDU session; requesting to verify 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; requesting whether the first PDU session includes data of the target application according to the first URSP rule Bag.
  • a network side device in a seventh aspect, 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.
  • a network side device 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.
  • a readable storage medium stores a program or Instructions, programs or instructions when executed by a processor implement the steps of the method described in the first aspect, or implement the steps of the method described in the second aspect, or implement the steps of the method described in the third aspect.
  • a chip in an eleventh aspect, 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.
  • 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 first network side device After receiving the reporting information sent by the terminal, the first network side device verifies that the first URSP rule is consistent with the first network based on the first URSP rule used by the terminal for the target application included in the reporting information. At least one URSP rule corresponding to the target application sent by the side device to the terminal is consistent, and the first parameter indicating the first PDU session carrying the target application is obtained through the second network side device and the RSD in the first URSP rule The described second verification result of whether the two parameters are consistent, and the third verification result indicating whether the first PDU session includes the data packet of the target application, so that the network side device can learn whether the terminal has applied the network side device to the terminal.
  • the URSP rules configured on the device match application traffic to a specific PDU session, the URSP rules specifically used by the terminal to match the application traffic, and whether the corresponding PDU session includes data packets of the application traffic, which facilitates network-side equipment to control the terminal.
  • 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 another schematic flow chart of the verification method of URSP rules provided by the embodiment of the present application
  • Figure 5 shows another schematic flow chart of the verification method of URSP rules provided by the embodiment of the present application.
  • Figure 6 shows another schematic flow chart of the verification method of URSP rules provided by the embodiment of the present application.
  • Figure 7 shows another schematic flow chart of the verification method of URSP rules provided by the 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.
  • 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.
  • the first object can be one or multiple.
  • “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.
  • LTE Long-term evolution
  • LTE-Advanced, LTE-A Long-term evolution
  • LTE-Advanced, LTE-A Long-term evolution
  • CDMA Code Division Multiple Access
  • Time Division Multiple Access Time Division Multiple Access
  • TDMA Time Division Multiple Access
  • FDMA frequency division multiple access
  • OFDMA Orthogonal Frequency Division Multiple Access
  • SC- FDMA single-carrier Frequency Division Multiple Access
  • 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.
  • NR New Radio
  • 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 , 6G) communication system.
  • NR New Radio
  • FIG. 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 (User Equipment, UE) 11 and a 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.
  • UE User Equipment
  • 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.
  • PDA Personal Digital Assistant
  • wearable devices include: smart watches, smart bracelets, smart headphones, smart glasses, smart jewelry (smart bracelets, smart bracelets, smart rings, smart necklaces, smart anklets , smart anklets, etc.), smart wristbands, smart clothing, etc.
  • 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 (WLAN) access point or a Wireless Fidelity (WiFi) node, etc.
  • WLAN Wireless Local Area Network
  • WiFi Wireless Fidelity
  • the base station may be called a Node B, an Evolved Node B (eNB), Access point, Base Transceiver Station (BTS), radio base station, radio transceiver, Basic Service Set (BSS), Extended Service Set (ESS), home B-node, home Evolved B-node, Transmitting Receiving Point (TRP) or some other suitable terminology in the field, as long as the same technical effect is achieved, the base station is not limited to specific technical terms. It should be noted that in this article In the application examples, only the basis in the NR system is used The base station is introduced as an example, and the specific type of base station is not limited.
  • Core network equipment may include but is not limited to at least one of the following: core network 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.
  • MME mobility management entities
  • AMF Access and Mobility Management Function
  • SMF Session Management Function
  • UPF User Plane Function
  • PCF Policy Control Function
  • URSP rules are a policy defined by 3GPP and sent to the UE. Based on these URSP rules, the UE can match application (Application, APP) traffic to a specific PDU session (session).
  • application Application, APP
  • the APP can send the APP traffic characteristics to the UE. These traffic characteristics can be the destination IP address, 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.
  • IP description such as a destination IP triplet
  • the next step is to choose which PDU session (session) to use to send the APP's traffic (traffic).
  • each RSD represents a set of attributes of a PDU session.
  • 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 RSD of the traffic descriptor matched by the UE includes:
  • the network side device does not know whether the UE has executed URSP rules and if so, which URSP rules have 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.
  • 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.
  • the method may be executed by software or hardware installed on the first network side device.
  • the first network side device may be an access and mobility management policy control network element.
  • the first network side device may be an access and mobility management policy control function (Access and Mobility Management Policy Control). Function, AM-PCF).
  • the method may include the following steps.
  • the first 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.
  • the first PDU session identifier is used to indicate The first PDU session carrying the target application.
  • the first PDU session identifier indicates 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.
  • the information reported by the terminal to the first 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.
  • the indication information indicates that after using the first URSP rule, a new PDU session is created to carry the application traffic.
  • 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 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 mainly includes: the first URSP rule is consistent with the second URSP rule, and the first verification is passed; or the first URSP rule is inconsistent with the second URSP rule, and the first verification fails.
  • the terminal executes URSP rules for the traffic of the target application, and then the terminal sends the used URSP rules to AM-PCF.
  • AM-PCF performs the first verification to verify whether the rule reported by the terminal is consistent with the rule sent to the UE by AM-PCF, that is, whether the URSP rule reported by the terminal is one of the URSP rules sent by AM-PCF to the UE.
  • SSC Session and Service Continuity
  • Mode Selection SSC Mode 3;
  • DNN Data Network Name
  • Access Type preference 3GPP access.
  • SSC Mode Selection SSC Mode 3;
  • Access Type preference 3GPP access.
  • 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.
  • the first network side device uses the second network side device to Prepare to obtain a second verification result, wherein 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.
  • the second verification result includes: the first parameter of the first PDU session and the second parameter described by the RSD in the first URSP rule correspond to each other one by one and are consistent, then the second verification is passed; If any one of the first parameters of the first PDU session is inconsistent with the second parameters described in the RSD in the first URSP rule, the second verification fails.
  • the first network side device may initiate a second verification and obtain the second second verification through the second network side device. Validation results. If the first network side device finds that the first verification fails, it directly determines that the terminal does not use the URSP rules correctly, and does not perform the second verification.
  • the first parameter of the first PDU session may include at least one of the following: PDU session type, PDU session access type, SSC mode, network slice identifier, and DNN.
  • 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.
  • 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.
  • the first parameter and the second parameter respectively include: PDU session type, PDU session access type, SSC mode, and DNN
  • 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 the second verification 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 be consistent with the first PDU session.
  • the parameters of the PDU session indicated in the RSD in a URSP rule, such as SSC mode, DNN, etc., correspond one to one and are the same.
  • the first network side device obtains the second verification result to learn 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.
  • the first network side device is a policy control network element for access and mobility management and cannot know the first parameter of the first PDU session used by the terminal. Therefore, the first network side device can obtain the second verification through the second network side device. result.
  • the second network side device may be a session management network element, for example, Session Management Function (SMF).
  • SMS Session Management Function
  • the first URSP rule reported by the terminal is:
  • 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:
  • Access Type preference 3GPP access.
  • the network slice in the second parameter is S-NSSAI-b
  • 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. If the second verification fails, the third verification described below will not continue to be executed.
  • the first network side device obtains a third verification result through 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 third verification result includes 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 The third verification failed.
  • the first network side device can learn whether the traffic of the target application is in the first PDU session.
  • This method is to verify whether the application data packet actually exists in the first PDU session.
  • One possible situation is that although the terminal declares to use the first URSP rule, and 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, the terminal may not This first PDU session is actually used to transmit application traffic, but other PDU sessions are used. In this case, deep packet inspection is also required to determine whether the first PDU session actually carries the transmission of the application traffic.
  • the first network side device may indicate when the second verification result indicates that the first parameter and the If the second parameters are inconsistent, for example, if at least one of the first parameters is inconsistent with the second parameter, start the third verification and obtain the third verification result through the second network side device.
  • the AM-PCF can request the SMF to directly complete the second verification or the third verification at the same time.
  • the method further includes: in any of the following situations, the first network side device sends first indication information to the second network side device, wherein the first indication information Used to indicate that 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; 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.
  • the second verification result indicates that at least one of the first parameters is inconsistent with the second parameter; that is, at least one of the first parameters is inconsistent with the second parameter. If the parameters are inconsistent, the first network side device determines that the terminal does not use the URSP rule correctly.
  • 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. 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.
  • 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.
  • 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.
  • 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.
  • the second network side device 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:
  • the second network device triggers the PDU session release process and releases the first PDU session corresponding to the first PDU session identifier
  • the second network device triggers a PDU session modification command to the terminal (which can be forwarded to the terminal via AMF); then, the terminal triggers a A PDU session establishment request (PDU session establishment request) is sent to the second network device (the session establishment request can be forwarded via the AMF).
  • PDU session establishment request PDU session establishment request
  • the second network device requests the terminal to modify the session. After the terminal accepts the request, it establishes a new PDU session, and then carries the first PDU session in the service, switch to the newly created PDU session. Finally, the terminal or the second network device releases the first PDU session.
  • the method may further include: 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 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.
  • 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.
  • the first network side device verifies the first URSP rule according to the first URSP rule used by the terminal for the target application included in the reporting information. Consistent with at least one URSP rule corresponding to the target application sent by the first network side device to the terminal, and obtaining the first parameter and the first URSP indicating the first PDU session carrying the target application through the second network side device.
  • the second verification result described by the RSD in the rule is whether the two parameters are consistent, and the third verification result indicates whether the first PDU session includes the data packet of the target application, so that the network side device can learn whether the terminal has applied the network side
  • the device configures the URSP rules for the terminal device to match the application traffic to a specific PDU session.
  • the terminal matches the specific URSP rules used by the application traffic and whether the corresponding PDU session includes the data packets of the application traffic. This facilitates the network-side device to identify the terminal. Take control.
  • Figure 3 shows another schematic flowchart of the verification method of URSP rules provided by this embodiment of the present application.
  • the first network side device obtains the second network side device through the second network side device.
  • the verification result may be implemented by: the first network side device may obtain the first parameter of the first PDU session carrying the target application from the second network side device, and then verify that the first parameter of the first PDU session is consistent with the first parameter of the first PDU session. Check whether the second parameter described by RSD in the first URSP rule is consistent.
  • the method 300 mainly includes the following steps.
  • S314 The first network side device obtains the first parameter of the first PDU session from the second network side device.
  • the first network side device may obtain the first parameter of the first PDU session by sending a request to the second network side device. Therefore, in a possible implementation, S314 may include: the first network side device sending first request information to the second network side device, wherein the first request information includes the first PDU session An identifier, used to request the first parameter of the first PDU session corresponding to the first PDU session identifier; the first network side device receives the first response information sent by the second network side device, wherein the first network side device A response message includes the first parameter of the first PDU session.
  • the first parameter may include at least one of the following: PDU session type, access type of PDU session, session and service continuity SSC mode, network slice identifier, and DNN.
  • the first network side device can send a request, the request including the first PDU session identifier, and the request is used to obtain the parameters of the PDU session corresponding to the PDU session identifier, such as PDU session type, access type of PDU session, session and service continuity SSC mode, network slice identifier, DNN.
  • This request can be sent using the following signaling: Nsmf_EventExposure Subscribe, or Npcf_AMPolicyControl_Notify, or Npcf_UEPolicyControl_Notify and other signaling.
  • the first network side device obtains the second verification result by verifying whether the first parameter is consistent with the second parameter described in the routing descriptor RSD in the first URSP rule.
  • the first network side device may compare whether the first parameter of the received first PDU session is consistent with the second parameter described by the RSD in the first URSP rule used by the terminal. Specifically, for whether the first parameter and the second parameter are consistent, please refer to the description in the above method 200. For example, after AM-PCF obtains the parameters of the first PDU session, it compares them in AM-PCF, completes the second verification, and obtains the second verification result.
  • the first network side device obtains a third verification result through the second network side device, where the third verification result indicates whether the first PDU session includes the data packet of the target application.
  • the first request information sent by the first network side device may include the first URSP rule, requesting the second network side device to verify whether the first PDU session includes the target.
  • the application data packet that is, the first request information is used to request the first parameters of the first PDU session corresponding to the first PDU session identifier, and to request the second network side device to verify whether the first PDU session includes the Describe the data packet of the target application.
  • the second network side device may generate a packet detection rule based on the RSD and/or TD in the first URSP rule, and apply the packet detection rule to the packet corresponding to the first PDU session identifier.
  • First PDU session obtain the third verification result, and return the third verification result to the first network side device.
  • the third verification result may be included in the first response information.
  • AM-PCF can directly request SMF to obtain the first PDU session parameters and perform second verification to obtain the second verification result; at the same time, instruct SMF to generate a packet detection rule (Packet Detection Rule) based on the first URSP rule. PDR), perform the third verification.
  • PDR Packet Detection Rule
  • the first network side device may also request the first parameter of the first PDU session from the second network side device and request the second network side device to verify the first Whether the PDU session includes the data packet of the target application. Therefore, in this possible implementation, S318 may also include: after sending the first request information to the second network side device or after receiving the first response information sent by the second network side device, the The first network side device sends second request information to the second network side device, and receives the third verification result returned by the second network side device, where the second request information is used to request to obtain the As a third verification result, the second request information includes the first PDU session identifier and the first URSP rule.
  • the first network side device can first wait for the parameters of the first PDU session fed back by the second network side device, and then the first network side device performs the second verification. If the second verification passes, the first network side device sends a second request to request the second network side device to perform the third verification. In this way, the second verification and the third verification are sequential. If the second verification fails, the third verification cannot be performed.
  • the first network side device receives the third verification result returned by the second network side device, which may include: the first network side device receives the second network side device.
  • Second response information returned by the side device wherein the second response information includes the third verification result, and the second response information is used to respond to the second request information.
  • the third verification result refers to whether the data packet of the target application is queried in the first PDU session. The obtained result is: the target data packet is queried or the target data packet is not queried.
  • the first network side device may, when the second verification result indicates that the first parameter is consistent with the second parameter, the first network side device may The second network side device sends the second request information. That is to say, when the second verification passes, the first network side device can request the second network side device to perform a third verification, that is, to verify whether the first PDU session includes the data of the target application. Bag. This can reduce unnecessary processes and save verification time.
  • Figure 4 shows another schematic flowchart of the verification method of URSP rules provided by the embodiment of the present application.
  • the first network side device obtains the second verification result through the second network side device in the following manner:
  • the first network side device sends the first PDU session identifier and the first URSP rule to the second network side device, and requests the second network side device to verify the first parameter and the first URSP rule. whether the second parameters are the same, so as to obtain the second verification result from the second network side device.
  • the method mainly includes the following steps.
  • step S410 the same as step S210.
  • step S412 the same as step S212.
  • the first network side device sends third request information to the second network side device, where the third request information includes the first URSP rule and the first PDU session identifier.
  • the first network side device may, when the first verification result indicates that the first URSP rule is consistent with at least one of the second URSP rules, that is, the first network side device may perform the first verification on the first URSP rule used by the terminal for the target application.
  • S414 is executed to request the second network side device to verify, through the third request information, that the first parameter of the first PDU session corresponding to the first PDU session identifier is the same as the first parameter of the first PDU session. Whether the second parameter described by the RSD in a URSP rule is consistent, and verifying whether the first PDU session corresponding to the first PDU session identifier includes a data packet of the target application.
  • This method means that the subject performing the second verification is changed from the first network side device to the second network side device (for example, SMF).
  • the second network side device for example, SMF.
  • AM-PCF sends the first URSP rule to SMF, SMF first restores the session parameters of the first PDU session according to the first PDU session ID, and then SMF performs the conversion of the session parameters of the first PDU session to the first PDU session ID.
  • the session parameters indicated in the RSD in the URSP rule are compared one by one for the second verification. SMF then sends the verification results to AM-PCF.
  • the first network side device obtains the third response information sent by the second network side device, wherein the third response information includes the second network side device's comparison of the first parameter and the second parameter.
  • the second verification result obtained by verification, and the third verification result obtained by the second network side device verifying whether the first PDU session includes the data packet of the target application.
  • the second network side device may obtain the first parameter of the first PDU session corresponding to the first PDU session identifier, and compare the first parameter of the first PDU session with the first PDU session identifier. Compare the second parameter in the RSD in the first URSP rule in the three request information, determine whether the first parameter is consistent with the second parameter, obtain the second verification result, and generate a package according to the first URSP rule. Detection rules: apply the packet detection rules to the first PDU session corresponding to the first PDU session identifier, obtain the third verification result, and return the second verification result and the third verification result to the first PDU session through the third response message. Network side equipment.
  • Figure 5 shows another schematic flowchart of the verification method of URSP rules provided by the embodiment of the present application.
  • the difference between method 500 and method 400 is that the first network side device respectively requests the second network side device to verify the first Whether the first parameter of the first PDU session corresponding to the PDU session identifier is consistent with the second parameter described by the RSD in the first URSP rule, and verifying whether the first PDU session corresponding to the first PDU session identifier includes the target Application data package.
  • the URSP rule verification method 500 may include the following steps.
  • step S510 the same as step S210.
  • step S512 the same as step S212.
  • the first network side device sends fourth request information to the second network side device, where the fourth request information includes the first URSP rule and the first PDU session identifier for requesting The second network side device verifies the first parameter and the second parameter.
  • the fourth request is that the first network side device (for example, AM-PCF) instructs the second network side device (for example, SMF) to complete the second verification without including the third verification task.
  • the method for the second network side device to perform the second verification is the same as the embodiment in Figure 4 above.
  • the first network side device may, when the first verification result indicates that the first URSP rule is consistent with at least one of the second URSP rules, that is, the first network side device may perform the first verification on the first URSP rule used by the terminal for the target application.
  • S514 is executed to request the second network side device to verify the first parameter of the first PDU session corresponding to the first PDU session identifier and the first parameter of the first PDU session through the fourth request information. Whether the second parameter of the RSD description in a URSP rule is consistent.
  • the first network side device obtains the fourth response information sent by the second network side device, wherein the fourth response information includes the second network side device's comparison of the first parameter and the third
  • the second verification result is obtained by verifying two parameters.
  • the second network side device may obtain the first parameter of the first PDU session corresponding to the first PDU session identifier, and compare the first parameter of the first PDU session with the first PDU session identifier. Compare the second parameter in the RSD in the first URSP rule in the three request messages, determine whether the first parameter is consistent with the second parameter, obtain the second verification result, and send the fourth response message to the third parameter. A network side device returns the second verification result.
  • the first network side device sends fifth request information to the second network side device, where the fifth request information includes the first URSP rule and the first PDU session identifier for requesting
  • the second network side device verifies whether the first PDU session includes the data packet of the target application.
  • the fifth request may be that the first network side device (for example, AM-PCF) has obtained the second verification result: the terminal correctly uses the URSP rule (or the session parameters of the first PDU session are in accordance with the first URSP rule).
  • the terminal correctly uses the URSP rule (or the session parameters of the first PDU session are in accordance with the first URSP rule).
  • instruct SMF to perform the third verification.
  • the first network side device may perform S518 when the second verification result indicates that the first parameter is consistent with the second parameter to avoid unnecessary processes.
  • the first network side device obtains the fifth response information sent by the second network side device, wherein the fifth response information includes the second network side device's response to whether the first PDU session includes The third verification result obtained by verifying the data packet of the target application.
  • the second network side device After receiving the fifth request information, the second network side device generates a packet detection rule according to the first URSP rule in the fifth request information, and applies the packet detection rule to the first PDU session identifier corresponding to the first PDU session identifier. PDU session, obtain the third verification result, and return the third verification result to the first network side device through the fourth response information.
  • FIG. 6 shows another schematic flowchart of the verification method of URSP rules provided by the embodiment of the present application.
  • the method 600 can be executed by the above-mentioned second network side device.
  • the method 600 can be executed by the device installed on the second network. software or hardware on the device.
  • the second network side device may be a session management network element, for example, a session management function (Session Management Function, SMF) entity.
  • SMF Session Management Function
  • the second network side device determines a second verification result by interacting with the first network side device, wherein the second verification result indicates that the first parameter of the first PDU session carrying the target application of the terminal is the same as that of the terminal. Whether the second parameter described by the RSD in the first URSP rule used by the target application is consistent.
  • S610 may include the following steps:
  • Step 1 The second network side obtains the first request information sent by the first network side device, wherein the first request information includes a first PDU session identifier, and the first PDU session identifier is used to indicate the first PDU session identifier.
  • the first request information includes a first PDU session identifier
  • the first PDU session identifier is used to indicate the first PDU session identifier.
  • the first request information may be used to request to obtain the first parameter of the first PDU session corresponding to the first PDU session identifier.
  • Step 2 The second network side device obtains the first parameter of the first PDU session.
  • the first parameter includes at least one of the following: PDU session type, PDU session access type, SSC mode, network slice identifier, and DNN.
  • SMF can directly find the session parameters of the PDU session corresponding to the first PDU session identifier, that is, the first parameter.
  • Step 3 The second network side device returns first response information, where the first response information includes the first parameter of the first PDU session, instructing the first network side device to verify the first parameter. Is it consistent with the second parameter?
  • the second parameter includes at least one of the following: PDU session type, PDU session access type, SSC mode, network slice identifier, and DNN.
  • the first network side device may transfer the first PDU session included in the first response message.
  • the first parameter is compared with the second parameter described in the RSD in the first URSP rule used by the terminal to determine whether the first parameter is consistent with the second parameter.
  • the second network side device for example, SMF
  • the first network side device for example, AM-PCF
  • the second network side device completes the second verification by itself and will The result of the second verification is fed back to the first network side device.
  • the SMF may send a first response to the AM-PCF, and the first response may be sent through the following signaling: Nsmf_EventExposure_Notify, or Npcf_AMPolicyControl_Subscribe, or Npcf_UEPolicyControl_Subscribe or other signaling.
  • the second network side device obtains a third verification result by verifying whether the first PDU session includes the data packet of the target application, wherein the third verification result indicates that the first PDU session contains Whether to include the data packet of the target application.
  • the above first request information may also include the first URSP rule, and the first request information is also used to request the second network side device to verify whether the first PDU session includes the The data packet of the target application.
  • S612 may include: after receiving the first request information, the second network side device generates a packet detection rule according to the first URSP rule in the first request information, and applies the packet detection rule to the The first PDU session indicated by the first PDU session identifier is used to obtain 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. That is to say, the first request information also instructs SMF to complete the third verification.
  • the second network side device generates the packet detection rule according to the first URSP rule.
  • One method of generating the packet detection rule may be: the second network side device (for example, SMF) generates the packet detection rule based on the traffic descriptor, such as the IP descriptor, in the first URSP rule sent by the AM-PCF.
  • 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.
  • IP descriptors 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.
  • PDR Packet Detection Rules
  • 5G Core Network such as AMF, AM-PCF, SM-PCF, etc.
  • 5GC 5G Core Network
  • AMF AMF
  • AM-PCF AM-PCF
  • SM-PCF SM-PCF
  • conversion capabilities to convert the APP descriptor, domain name descriptor, DNN, and connection capabilities and other descriptors, converted into IP quintuple, or IP descriptor.
  • the first response information may also include the third verification result.
  • the first network side device may also request the first parameter of the first PDU session and request the second network side device to verify whether the first PDU session includes the target application. of data packets. Therefore, S612 can include:
  • Step 1 After receiving the first request information or after returning the first response information to the second network side device, the second network side device obtains the second request sent by the first network side device.
  • Information wherein the second request information is used to request to obtain the third verification result, and the second request information carries the first PDU session identifier and the first URSP rule.
  • the first network side device may send the second request information after sending the first request information.
  • the first network side device may also send the second request information after receiving the first response information returned by the second network side device.
  • the second verification result in the first response information indicates that If the first parameter of the first PDU session is consistent with the second parameter described by the RSD in the first URSP rule, the second request message is sent.
  • the first network side device for example, AM-PCF
  • the second network side device for example, SMF
  • Step 2 The second network side device generates a packet detection rule according to the first URSP rule in the second request information, and applies the packet detection rule to the first PDU indicated by the first PDU session identifier. session, and obtain 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 may return second response information to the first network side device, where the second response information includes the Third verification result.
  • the second network side device may also verify whether the first parameter of the first PDU session is consistent with the second parameter described by the RSD in the first URSP rule. Therefore, in a possible implementation, as shown in Figure 4, the verification method of the URSP rule may include the following steps.
  • the second network side device receives the third request information sent by the first network side device, where the third request information includes the first URSP rule and the first PDU session identifier.
  • the third request information is used to request the second verification result and the third verification result, that is, the third request information is used to request the second network side device to verify the third verification result. Whether the first parameter of the first PDU session corresponding to a PDU session identifier is consistent with the second parameter described by the RSD in the first URSP rule and verifying whether there is a data packet of the target application in the first PDU session.
  • the second network side device obtains the first parameter of the first PDU session indicated by the first PDU session identifier.
  • the second network side device obtains the first parameter of the first PDU session corresponding to the first PDU session identifier according to the first PDU session identifier in the third request information.
  • S415 The second network side device verifies that the first parameter matches the first URSP specification. Then whether the second parameter described in the RSD is consistent, the second verification result is obtained. That is, the second network side device performs the second verification.
  • the second network side device determines that the first parameter is inconsistent with the second parameter.
  • the second network side device determines that the first parameter is consistent with the second parameter.
  • the second network side device generates a packet detection rule according to the first URSP rule in the third request information, and applies the packet detection rule to the first PDU session indicated by the first PDU session identifier. , obtain the 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, and the third response information (including the second verification result and the third verification result ) is sent to the first network side device.
  • the second network side device may also send the second response information including the second verification result and the third response information including the third verification result to the first network side device respectively. For example, after S415, send the second response message, and in S417, the third response information including the third verification result is sent.
  • S413 and S417 There may be no restriction on the sequence between S413 and S417. For example, they may be performed at the same time, or S413 and S415 may be executed first, and then executed after it is determined that the first parameter is consistent with the second parameter. S417, thereby saving unnecessary processes.
  • the first network side device when the second 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 first network side The device may also request to obtain the second verification result and the third verification result respectively. Therefore, in a possible implementation, as shown in Figure 5, the verification method of the URSP rule may include the following steps.
  • the second network side device receives the fourth request information sent by the first network side device, wherein the fourth request information includes the first URSP rule and the first PDU session identifier, for Requesting the second network side device to verify the first parameter of the first PDU session indicated by the first PDU session identifier and the second parameter described by the RSD in the first URSP rule.
  • the second network side device obtains the first parameter of the first PDU session indicated by the first PDU session identifier.
  • the second network side device obtains the second verification result by verifying whether the obtained first parameter is consistent with the second parameter described by the RSD in the first URSP rule.
  • the second network side device receives the fifth request information sent by the first network side device, where the fifth request information includes the first URSP rule and the first PDU session identifier, for Request the second network side device to respond to the first PDU session identifier indicated by the first PDU session identifier. Verify whether a PDU session includes the data packet of the target application.
  • the first network side device may send the fifth request information after receiving the fourth response information.
  • the first network side device may indicate the second verification result in the fourth response information. If the first parameter of the first PDU session is consistent with the second parameter of the RSD description in the first URSP rule, the fifth request information is sent.
  • the second network side device generates a packet detection rule according to the first URSP rule in the fifth request information, and applies the packet detection rule to the first PDU session indicated by the first PDU session identifier. , obtain the 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, and the third verification result is included in the fifth response information and returned to the first network side device.
  • the method may also include:
  • Step 1 The second network side device receives first indication information sent by the first network side device, wherein the first 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 modification request corresponding to the first PDU session identifier, or the second network side device releases the first PDU session corresponding to the first PDU session identifier.
  • 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.
  • 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.
  • the terminal's improper use of URSP rules includes one of the following:
  • 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 when the first verification result indicates that the first URSP rule is inconsistent with the second URSP rule, send the first network side device to the second network side device. Instructions.
  • At least one parameter among the first parameters is inconsistent with the second parameter.
  • 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 first indication information.
  • 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 first indication information.
  • the first PDU session does not include the data packet of the target application.
  • the 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, sends the data packet to the second network side device. the first instruction information.
  • the second network side device rejects the session establishment request or modification request corresponding to the first PDU session identifier, or the second network side device releases The first PDU session corresponding to the first PDU session identifier. For example, if the first PDU session corresponding to the first PDU session identifier is not established, after receiving the first 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 first 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 modification request means rejecting the PDU session establishment request or modification request of the terminal that reports the first URSP rule.
  • 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.
  • the second network side device 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:
  • Send PDU session modification reject to the terminal (can be forwarded to the terminal via AMF);
  • the second network device triggers the PDU session release process and releases the first PDU session corresponding to the first PDU session identifier
  • the second network device triggers a PDU session modification command (PDU session modification command) to the terminal (which can be forwarded to the terminal via AMF); then, the terminal triggers a PDU session establishment request (PDU session establishment request) to the second network device.
  • Network device (the session establishment request may be forwarded via AMF).
  • the second network device Since the first URSP rule is not used correctly, the second network device requests the terminal to modify the session. After the terminal accepts the request, it establishes a new PDU session, and then carries the first PDU session in the service, switch to the newly created PDU session. Finally, the terminal or the second network device releases the first PDU session.
  • information can be transmitted directly between the first network side device and the second network side device.
  • the first network side device can first learn the identity of the second network side device, for example, through unified data management. Entity (Unified Data Management, UDM) obtains the terminal pair The identifier of the corresponding second network side device (for example, mobility management network element).
  • UDM Unified Data Management
  • 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.
  • 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) performs information transmission, or the first network side device and the second network side device communicate through access and mobility management network elements (SM-PCF).
  • SM-PCF Access and Mobility Management Function
  • AMF Access and Mobility Management Function
  • FIG. 7 shows another schematic flowchart of the verification method of URSP rules provided by the embodiment of the present application.
  • the method 700 can be executed by the above-mentioned third network side device.
  • the method 700 can be executed by the device installed on the third network side.
  • 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.
  • the method may include the following steps.
  • the third network side device receives the request information sent by the first network side device, where the request information includes: a first PDU session identifier and/or a first URSP rule, and the first PDU session identifier is used to Indicates the first PDU session carrying the target application of the terminal, and the first URSP rule is the URSP rule used by the terminal for the target application.
  • the request information is used for at least one of the following:
  • the above fifth request information includes the first PDU identifier and the first URSP rule.
  • the request information may include at least one of the first request information, the second request information, the third request information, the fourth request information and the fifth request information in the above methods 200 to 600.
  • the first network side device may send the request information through signaling interacted with the third network side device.
  • the interactive signaling between AM-PCF and AMF includes: AM-PCF sends the request information through Namf_Communication N1MessageNotify_Subscribe; or AM-PCF sends the request information through at least one of the following: Npcf_UEPolicyControl_Update response or Npcf_UEPolicyControl_UpdateNotify notify; or it can be Other signaling defined between AM-PCF and AMF.
  • the third network side device sends the request information to the second network side device.
  • the third network side device may carry the request information in signaling and send it to the second network side device.
  • the method may further include the following steps:
  • Step 1 The third network side device obtains the response information returned by the second network side device.
  • the response information may include one of the following:
  • the response information may include any one of the above-mentioned first response information, second response information, third response information, fourth response information and fifth response information.
  • Step 2 The third network side device sends the response information to the first network side device.
  • the third network side device in addition to transmitting the above request information and response information transmitted between the first network side device and the second network side device, can also transmit the relationship between the first network side device and the second network side device.
  • Other information between side devices such as the above-mentioned first indication information, will not be described again in the specific embodiments of this application.
  • AMF can send the above response information to AM-PCF through the following signaling: Namf_Communication N1MessageNotify Notify; or, it can also use the following signaling to send the response information: Npcf_UEPolicyControl_Update request; Npcf_UEPolicyControl_UpdateNotify subscribe. It can also be other signaling defined between AMF and AM-PCF.
  • 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 8 shows another schematic flowchart of the verification method of URSP rules according to the embodiment of the present application. As shown in Figure 8, the method 800 mainly includes the following steps.
  • AM-PCF After AM-PCF receives the URSP rules reported by the terminal for a certain APP, it performs the first verification to verify whether the rules reported by the terminal are consistent with the URSP rules sent by AM-PCF to the UE. When they are consistent, If the first verification is passed, AM-PCF sends the URSP rules used by the terminal (mainly sending the RSD parameters in the URSP rules) and the PDU session ID carrying the APP traffic to SMF.
  • SMF obtains the parameters of the PDU session based on the PDU session ID, and converts the PDU session
  • the parameters of the call are sent to AM-PCF.
  • the parameters of the PDU session may include: at least one of SSC mode, Access type, PDU session type, DNN, S-NSSAI, etc.
  • AM-PCF compares the PDU session parameters described by the RSD in the URSP rule used by the terminal with the PDU session parameters reported by the SMF.
  • the second verification fails and S807 is executed; if they are the same, the verification is passed and S804 is executed to perform packet detection, that is, the third verification is performed.
  • AM-PCF instructs SMF to perform packet detection.
  • SMF generates packet detection rules (PDR) based on the RSD and TD in the URSP rules used by the terminal sent by AM-PCF, performs packet detection in the PDU session corresponding to the PDU session ID, and sends the detection packet results to AM-PCF .
  • PDR packet detection rules
  • the detection packet result indicates that SMF detects the data packet of the APP, it means that the URSP rules are used correctly and the process ends; if the detection packet result indicates that SMF does not detect the data packet of the APP, it means that the traffic of the APP does not appear in the PDU session, indicating that the terminal does not use URSP rules correctly, then execute S807.
  • AM-PCF can optimize the UE policy, such as re-executing the UE policy and sending it to the UE.
  • AM-PCF indicates SMF that the UE does not use URSP rules correctly.
  • the SMF can perform the following three operations:
  • Operation 1 SMF rejects the session establishment request corresponding to the PDU session ID.
  • Operation 2 SMF releases the PDU session corresponding to the PDU session ID.
  • Operation 3 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 9 shows another schematic flowchart of the verification method of URSP rules according to the embodiment of the present application. As shown in Figure 9, the method 900 mainly includes the following steps.
  • AM-PCF After AM-PCF receives the URSP rules reported by the terminal for a certain APP, it performs the first verification to verify whether the rules reported by the terminal are consistent with the URSP rules sent by AM-PCF to the UE. When they are consistent, If the first verification is passed, AM-PCF sends the URSP rules used by the terminal (mainly sending the RSD parameters in the URSP rules) and the PDU session ID carrying the APP traffic to AMF.
  • AMF sends the URSP rules used by the terminal and the PDU session ID carrying the APP traffic to SMF.
  • the interactive signaling between the AMF and SMF may be at least one of the following or other signaling:
  • Nsmf_EventExposure Subscribe Nsmf_PDUSession_UpdateSMContext.
  • SMF obtains the parameters of the PDU session based on the PDU session ID, and sends the parameters of the PDU session to the AMF.
  • the parameters of the PDU session may include: SSC mode, Access type, PDU session type, at least one of DNN, S-NSSAI, etc.
  • the interactive signaling between the SMF and the AMF may include at least one of the following:
  • AMF sends the parameters of the PDU session to AM-PCF.
  • SMF generates packet detection rules (PDR) based on the RSD and TD in the URSP rules used by the terminal, performs packet detection in the PDU session corresponding to the PDU session ID, and sends the packet detection results to AMF.
  • PDR packet detection rules
  • AMF sends the detection packet result to AM-PCF.
  • AM-PCF compares the PDU session parameters described by the RSD in the URSP rule used by the terminal with the PDU session parameters reported by the SMF, performs secondary verification, and obtains the results of the third verification based on the detection packet results.
  • the second verification fails and S908 is executed; if they are the same, the second verification passes. If the result of the third verification (ie, the detection packet result) indicates SMF detection If the data packet of the APP is detected, it means that the URSP rules are used correctly and the process is over; if the detection packet result indicates that SMF does not detect the data packet of the APP, it means that the traffic of the APP does not appear in the PDU session. , indicating that the terminal does not use URSP rules correctly, then execute S908.
  • AM-PCF can optimize the UE policy, such as re-executing the UE policy and sending it to the UE.
  • the AM-PCF sends the verification result of the URSP rule usage to the AMF, and the verification result indicates that the UE does not use the URSP rule correctly.
  • AMF sends the verification result used by the URSP rule to SMF.
  • the SMF can perform the following three operations:
  • Operation 1 SMF rejects the session establishment request corresponding to the PDU session ID.
  • Operation 2 SMF releases the PDU session corresponding to the PDU session ID.
  • Operation 3 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 flowchart of the verification method of URSP rules according to the embodiment of the present application. As shown in Figure 10, the method 1000 mainly includes the following steps.
  • AM-PCF After AM-PCF receives the URSP rules reported by the terminal for an APP, it performs the first verification to verify that the rules reported by the terminal are the same as those reported by AM-PCF and sent to the UE. Whether the URSP rules are consistent. If they are consistent, the first verification is passed. AM-PCF sends the URSP rules used by the terminal (mainly sending the RSD parameters in the URSP rules) and the PDU session ID that carries the APP traffic. to SM-PCF.
  • the interactive signaling between AM-PCF and SM-PCF includes at least one of the following:
  • Npcf_PolicyAuthorization_Subscribe that is, a subscription message, which is used to subscribe to the usage of the first URSP rule sent, for example, after using the first URSP rule to generate a PDR, the result of packet detection in the PDU session.
  • SM-PCF sends the URSP rules used by the terminal and the PDU session ID carrying the APP traffic to the SMF.
  • the sending method is through at least one of the following signaling: Npcf_SMPolicyControl_UpdateNotify; Npcf_SMPolicyControl_Update request.
  • SMF obtains the parameters of the PDU session based on the PDU session ID, and sends the parameters of the PDU session to SM-PCF.
  • the parameters of the PDU session may include: SSC mode, Access type, PDU session type, at least one of DNN, S-NSSAI, etc.
  • SM-PCF sends the parameters of the PDU session to AM-PCF.
  • the signaling used for sending can be one of the following: Npcf_SMPolicyControl UpdateNotify Notify; Npcf_SMPolicyControl_Update request.
  • SMF generates packet detection rules (PDR) based on the RSD and TD in the URSP rules used by the terminal, performs packet detection in the PDU session corresponding to the PDU session ID, and sends the packet detection results to SM-PCF.
  • PDR packet detection rules
  • SM-PCF sends the detection packet result to AM-PCF.
  • the signaling used for sending may be one of the following: Npcf_Policy_Authorization Notify; Npcf_EventExposure_Notify.
  • AM-PCF compares the PDU session parameters described by the RSD in the URSP rule used by the terminal with the PDU session parameters reported by the SMF, performs secondary verification, and obtains the results of the third verification based on the detection packet results.
  • the second verification fails and S1008 is executed; if they are the same, the second verification passes. If the result of the third verification (ie, the detection packet result) indicates SMF detection If the data packet of the APP is detected, it means that the URSP rules are used correctly and the process is over; if the detection packet result indicates that SMF does not detect the data packet of the APP, it means that the traffic of the APP does not appear in the PDU session. , indicating that the terminal does not use URSP rules correctly, then perform S1008.
  • the detection packet result indicates SMF detection If the data packet of the APP is detected, it means that the URSP rules are used correctly and the process is over; if the detection packet result indicates that SMF does not detect the data packet of the APP, it means that the traffic of the APP does not appear in the PDU session. , indicating that the terminal does not use URSP rules correctly, then perform S1008.
  • AM-PCF can optimize the UE policy, such as re-executing the UE policy to UE sends it on.
  • the AM-PCF sends the verification result of the URSP rule usage to the AMF.
  • the verification result indicates that the UE does not use the URSP rule correctly.
  • AMF sends the verification result used by the URSP rule to SMF.
  • the SMF can perform the following three operations:
  • Operation 1 SMF rejects the session establishment request corresponding to the PDU session ID
  • Operation 2 SMF releases the PDU session corresponding to the PDU session ID
  • Operation 3 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 11 shows another schematic flow chart of the verification method of URSP rules according to the embodiment of the present application. As shown in Figure 11, the method 1100 mainly includes the following steps.
  • the terminal uses URSP rules to match APP traffic to a PDU session, or uses the RSD in the matched URSP rules to establish a new PDU session.
  • S1102 The terminal sends the used URSP rules, RSD, and PDU session identifiers to the AMF through the NAS message.
  • AMF sends the URSP rule, RSD, and PDU session identifier to AM-PCF through the UE policy control update request (Npcf_UEPolicyConrol_Update Request).
  • AM-PCF returns UE policy control update response (Npcf_UEPolicyConrol_Update response) to AMF.
  • AM-PCF performs the first verification, that is, it verifies whether the URSP rules reported by the terminal are consistent with the URSP rules sent by AM-PCF to the terminal. If they are consistent, continue to execute S1106; otherwise, execute S1118.
  • AM-PCF sends Nudm_SDM_Get or Nudm_SDM_Subscibe to UDM, which carries the terminal's subscription permanent identifier (Subscription Permanent Identifier, SUPI), sub key and S-NSSAI.
  • subscription permanent identifier Subscribescription Permanent Identifier, SUPI
  • SUPI Subscribe Permanent Identifier
  • UDM returns a Nudm_SDM_Get response or a Nudm_SDM_Subscibe response to AM-PCF.
  • the response can carry the PDU session ID, SMF ID, and SM-PCF ID.
  • AM-PCF sends to the SMF corresponding to the SMF ID the URSP rules that need to be monitored (that is, the URSP rules used by the terminal), including the terminal's SUPI, PDU session ID, RSD and TD in the URSP rules.
  • SMF obtains various parameters of the PDU session corresponding to the PDU session ID, such as SSC mode, etc.
  • SMF sends the obtained parameters of the PDU session to AM-PCF, so that AM-PCF performs secondary verification, that is, AM-PCF verifies that the parameters of the PDU session sent by SMF are consistent with Check whether the parameters described in the RSD of the URSP rules used by the terminal are consistent.
  • 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. .
  • the SMF determines the UPF corresponding to the PDU session identifier serving the terminal.
  • SMF sends the packet detection rules to UPF.
  • SMF can also instruct UPF to perform packet inspection within a specified time.
  • UPF applies the packet detection rule to perform packet detection to detect whether there is a traffic packet of the APP in the PDU session. At this time, UPF performs packet detection within the specified time indicated by SMF.
  • 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.
  • AM-PCF performs a second verification to verify whether the parameters of the PDU session sent by SMF are consistent with the parameters described in the RSD of the URSP rule used by the terminal. If any parameter of the PDU session sent by SMF is consistent with If the corresponding parameter described in the RSD of the URSP rule used by the terminal is inconsistent, execute S1118. If any parameter of the PDU session sent by SMF is consistent with the corresponding parameter described in the RSD of the URSP rule used by the terminal, if If the packet detection result indicates that there is a traffic packet of the APP in the PDU session, the process ends. If the packet detection result indicates that there is no traffic packet of the APP in the PDU session, S1118 is executed.
  • AMF-PCF adjusts the URSP rules in the terminal according to the URSP rules reported by the terminal.
  • the AMF sends the verification result of the URSP rule usage to the SMF. If the URSP rule usage is incorrect, the AMF requests the SMF to reject the establishment request of the PDU session or release the PDU session or modify the parameters of the PDU session.
  • Figure 12 shows another schematic flowchart of the verification method of URSP rules according to the embodiment of the present application. As shown in Figure 12, the method 1200 mainly includes the following steps.
  • the terminal uses URSP rules to match APP traffic to a PDU session, or uses the RSD in the matched URSP rules to establish a new PDU session.
  • S1202 The terminal sends the used URSP rules, RSD, and PDU session identifiers to the AMF through a Non-Access Stratum (NAS) message.
  • NAS Non-Access Stratum
  • AMF sends the URSP rule, RSD, and PDU session identifier to AM-PCF through the UE policy control update request (Npcf_UEPolicyConrol_Update request).
  • AM-PCF returns the UE policy control update response (Npcf_UEPolicyConrol_Update response) to the AMF.
  • AM-PCF performs the first verification, that is, it verifies whether the URSP rules reported by the terminal are consistent with the URSP rules sent by AM-PCF to the terminal. If they are consistent, continue to execute S1206; otherwise, execute S1221.
  • AM-PCF sends Nudm_SDM_Get or Nudm_SDM_Subscibe to UDM, which carries the terminal's subscription permanent identifier (Subscription Permanent Identifier, SUPI), sub key and S-NSSAI.
  • subscription permanent identifier Subscribescription Permanent Identifier, SUPI
  • SUPI Subscribe Permanent Identifier
  • UDM returns a Nudm_SDM_Get response or a Nudm_SDM_Subscibe response to AM-PCF.
  • the response can carry the PDU session ID, SMF ID, and SM-PCF ID.
  • AM-PCF sends to AMF the URSP rules that need to be monitored (that is, the URSP rules used by the terminal), including the terminal's SUPI, PDU session ID, RSD and TD in the URSP rules.
  • AMF sends the URSP rules that need to be monitored to SMF. Since the SMF corresponding to each terminal is stored in the AMF, the AMF can directly find the IP address of the SMF; or, the AM-PCF can instruct the SMF when sending the URSP rules to be monitored.
  • SMF obtains various parameters of the PDU session corresponding to the PDU session ID, such as SSC mode, etc.
  • the SMF sends the obtained parameters of the PDU session to the AMF.
  • AMF transfers various parameters of the PDU session to AM-PCF, so that AM-PCF performs secondary verification, that is, AM-PCF verifies that various parameters of the PDU session sent by SMF are consistent with each parameter described in the RSD of the URSP rule used by the terminal. Whether the parameters are consistent.
  • AM-PCF can also indicate SMF (via AMF), the result of the second verification. If the second verification fails, the process after step S1213 to S1219 will no longer be executed.
  • S1213 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. .
  • the SMF determines the UPF corresponding to the PDU session identifier serving the terminal.
  • SMF sends the packet detection rules to UPF.
  • SMF can also instruct UPF to perform packet inspection within a specified time.
  • UPF applies the packet detection rule to perform packet detection to detect whether there is a traffic packet of the APP in the PDU session. At this time, UPF performs packet detection within the specified time indicated by SMF.
  • 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.
  • AMF sends the packet detection results within the predetermined time to AM-PCF.
  • AM-PCF performs a second verification to verify whether the parameters of the PDU session sent by SMF are consistent with the parameters described in the RSD of the URSP rule used by the terminal. If any parameter of the PDU session sent by SMF is consistent with If the corresponding parameter described in the RSD of the URSP rule used by the terminal is inconsistent, execute S1218. If any parameter of the PDU session sent by SMF is consistent with the corresponding parameter described in the RSD of the URSP rule used by the terminal, if If the packet detection result indicates that there is a traffic packet of the APP in the PDU session, the process ends. If the packet detection result indicates that there is no traffic packet of the APP in the PDU session, S1221 is executed.
  • AMF-PCF adjusts the URSP rules in the terminal according to the URSP rules reported by the terminal.
  • the AMF sends the verification result of the URSP rule usage to the SMF. If the URSP rule usage is incorrect, the AMF requests the SMF to reject the establishment request of the PDU session or release the PDU session or modify the parameters of the PDU session.
  • Figure 13 shows another schematic flowchart of the verification method of URSP rules according to the embodiment of the present application. As shown in Figure 13, the method 1300 mainly includes the following steps.
  • the terminal uses URSP rules to match APP traffic 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 and RSD and PDU session identifiers to the AMF through the NAS message.
  • AMF sends the URSP rule, RSD, and PDU session identifier to AM-PCF through the UE policy control update request (Npcf_UEPolicyConrol_Update request).
  • AM-PCF returns UE policy control update response (Npcf_UEPolicyConrol_Update response) to AMF.
  • AM-PCF performs the first verification, that is, it verifies whether the URSP rules reported by the terminal are consistent with the URSP rules sent by AM-PCF to the terminal. If they are consistent, continue to execute S1306; otherwise, execute S1321.
  • AM-PCF sends Nudm_SDM_Get or Nudm_SDM_Subscibe to UDM, which carries the terminal's subscription permanent identifier (Subscription Permanent Identifier, SUPI), sub key and S-NSSAI.
  • subscription permanent identifier Subscribescription Permanent Identifier, SUPI
  • SUPI Subscribe Permanent Identifier
  • UDM returns a Nudm_SDM_Get response or a Nudm_SDM_Subscibe response to AM-PCF.
  • the response can carry the PDU session ID, SMF ID, and SM-PCF ID.
  • AM-PCF sends to SM-PCF the URSP rules that need to be monitored (that is, the URSP rules used by the terminal), including the terminal's SUPI, PDU session ID, RSD and TD in the URSP rules.
  • SM-PCF sends the URSP rules that need to be monitored and used to SMF.
  • SMF obtains various parameters of the PDU session corresponding to the PDU session ID, for example, S SC mode etc.
  • the SMF sends the obtained parameters of the PDU session to the SM-PCF.
  • SM-PCF AM-PCF the various parameters of the PDU session, so that AM-PCF performs secondary verification, that is, AM-PCF verifies that the various parameters of the PDU session sent by SMF are as described in the RSD of the URSP rules used by the terminal. Are all the parameters consistent?
  • S1313 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. .
  • the SMF determines the UPF corresponding to the PDU session identifier serving the terminal.
  • SMF sends the packet detection rules to UPF.
  • SMF can also instruct UPF to perform packet inspection within a specified time.
  • UPF applies the packet detection rule to perform packet detection to detect whether there is a traffic packet of the APP in the PDU session. At this time, UPF can perform packet detection within the specified time indicated by SMF.
  • 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.
  • SM-PCF sends the packet detection results within the predetermined time to AM-PCF.
  • AM-PCF performs a second verification to verify whether the parameters of the PDU session sent by SMF are consistent with the parameters described in the RSD of the URSP rule used by the terminal. If any parameter of the PDU session sent by SMF is consistent with If the corresponding parameter described in the RSD of the URSP rule used by the terminal is inconsistent, execute S1318. If any parameter of the PDU session sent by SMF is consistent with the corresponding parameter described in the RSD of the URSP rule used by the terminal, if If the packet detection result indicates that there is a traffic packet of the APP in the PDU session, the process ends. If the packet detection result indicates that there is no traffic packet of the APP in the PDU session, S1321 is executed.
  • AMF-PCF adjusts the URSP rules in the terminal according to the URSP rules reported by the terminal.
  • the AMF sends the verification result of the URSP rule usage to the SMF. If the URSP rule usage is incorrect, the AMF requests the SMF to reject the establishment request of the PDU session or release the PDU session or modify the parameters of the PDU session.
  • Figure 14 shows another schematic flowchart of the verification method of URSP rules according to the embodiment of the present application. As shown in Figure 14, the method 1400 mainly includes the following steps.
  • AM-PCF After the terminal reports the used URSP rules to AM-PCF, AM-PCF first performs the first verification to verify whether the rules used by the terminal are consistent with the actual URSP rules sent by AM-PCF to the UE. When consistent, When the first verification is passed, the AM-PCF sends the terminal The URSP rule used (mainly sending the RSD parameters in the URSP rule) and the ID of the PDU session carrying the APP traffic to the SMF.
  • the AM-PCF may also give an indication message: indicating whether the SMF only performs the second verification, or whether it needs to further perform three verifications of packet detection.
  • the AM-PCF may instruct the SMF to use the parameters in the first URSP rule RSD, compare them with the session parameters of the first PDU session, perform secondary verification, and then feed back the results; or, the AM-PCF may also It can be instructed that after completing the second verification, the third verification is performed regardless of the result; or the AM-PCF directly instructs the SM-PCF to complete the second verification or the third verification at the same time.
  • S1402 SMF obtains the parameters of the PDU session based on the PDU session ID, including: SSC mode, Access type, PDU session type, DNN, S-NSSAI, etc.; then SMF compares these PDU session parameters with those sent by AM-PCF The parameters contained in the RSD in the URSP rules used by the terminal. If the parameters are inconsistent, it means that the terminal does not use URSP rules correctly, and the secondary verification fails, then execute S1403, skipping S1404 and S1405; if the parameters are consistent, it means that the terminal uses URSP rules correctly, and execute S1404 and S1405 for packet detection. Next steps are to be determined.
  • SMF sends the verification result.
  • the verification fails, indicating that the PDU session parameters indicated by RSD in the URSP rules used by the terminal do not match the parameters of the PDU session that actually carries the APP traffic.
  • SMF generates packet detection rules based on the RSD and TD in the URSP rules used by the terminal sent by AM-PCF, performs packet detection in the PDU session, and sends the detection results.
  • S1405 If SMF detects the packet, it means that the URSP rules are used correctly and the process ends. If SMF does not detect the packet, it means that the traffic of the APP does not appear in the PDU session, which means that the terminal does not Use URSP rules correctly and execute S1406.
  • AM-PCF optimizes the UE policy, such as re-executing the UE policy and sending it to the UE.
  • AM-PCF indicates SMF that the UE does not use URSP rules correctly, and then SMF will perform S1408.
  • S1408 When the SMF receives an indication that the UE does not use the URSP rules correctly, the SMF can perform one of the following three operations:
  • Operation 1 SMF rejects the session establishment request corresponding to the PDU session ID
  • Operation 2 SMF releases the PDU session corresponding to the PDU session ID
  • Operation 3 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.
  • the execution subject may be a verification device of URSP rules.
  • the verification device of URSP rules is used to execute the URSP rules.
  • the verification method is taken as an example to describe the verification device of URSP rules provided by the embodiment of the present application.
  • Figure 15 shows a schematic structural diagram of a URSP rule verification device provided by an embodiment of the present application.
  • the device 1500 mainly includes: a first receiving module 1501, a first obtaining module 1502 and a second obtaining module 1503 .
  • the first receiving module 1501 is used to receive reporting information sent by the terminal, where the reporting information includes the first URSP rule and the first PDU session identifier used by the terminal for the target application.
  • the first PDU session identifier is used to indicate the first PDU session carrying the target application;
  • the first obtaining 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 is at least one URSP rule corresponding to the target application sent by the first network side device to the terminal;
  • the second acquisition module 1503 is used to obtain the second verification result, wherein
  • the second verification result indicates 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;
  • the third verification is obtained through the second network side device As a result, the third verification result indicates whether the first PDU session includes the data packet of the target application.
  • the second obtaining module 1503 obtains the second verification result through the second network side device, including:
  • the second verification result is obtained by verifying whether the first parameter is consistent with the second parameter described by the routing descriptor RSD in the first URSP rule.
  • the second obtaining module 1503 obtains the second verification result and the third verification result through the second network side device, including:
  • the third request information includes the first URSP rule and the first PDU session identifier
  • the third response information includes the third response information obtained by verifying the first parameter and the second parameter by the second network side device.
  • the second obtaining module 1503 obtains the second verification result and the third verification result through the second network side device, including:
  • the fourth response information sent by the second network side device wherein the fourth response information includes the second network side device verifying the first parameter and the second parameter.
  • the fifth request information includes the first URSP rule and the first PDU session identifier, used to request the second network side device to Verify whether the first PDU session includes the data packet of the target application;
  • the fifth response information includes the second network side device verifying whether the first PDU session includes the data packet of the target application.
  • the third verification result obtained.
  • Figure 16 shows another schematic structural diagram of a URSP rule verification device provided by an embodiment of the present application.
  • the device 1600 mainly includes: a determination module 1601 and a third acquisition module 1602.
  • the determination module 1601 is configured to determine a second verification result by interacting with the first network side device, wherein the second verification result indicates the first PDU session of the target application carrying the terminal. Whether the parameter is consistent with the second parameter described by the RSD in the first URSP rule used by the terminal for the target application; the third acquisition module 1602 is used to verify whether the first PDU session includes the data of the target application package to obtain a third verification result, wherein the third verification result indicates whether the first PDU session includes the data packet of the target application.
  • the determination module 1601 determines the second verification result by interacting with the first network side device, including:
  • the first request information sent by the first network side device, wherein the first request information includes a first PDU session identifier, and the first PDU session identifier is used to indicate the first PDU session;
  • the first response information includes the first parameter of the first PDU session, instructing the first network side device to verify whether the first parameter is consistent with the second parameter.
  • the third obtaining module 1602 obtains the third verification result by verifying whether the first PDU session includes the data packet of the target application, including:
  • the packet detection rule After receiving the first request information, generate a packet detection rule according to the first URSP rule in the first request information, and apply the packet detection rule to the first PDU session identifier indicated by the packet detection rule. A PDU session to obtain the 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, and the first request information also includes the first URSP rules.
  • the third obtaining module 1602 obtains the third verification result by verifying whether the first PDU session includes the data packet of the target application, including:
  • the second request information After receiving the first request information or after returning the first response information to the second network side device, obtain the second request information sent by the first network side device, wherein the first network side device
  • the second request information is used to request to obtain the third verification result, and the second request information carries the first PDU session identifier and the first URSP rule;
  • Generate packet detection rules according to the first URSP rule in the second request information apply the packet detection rules to the first PDU session indicated by the first PDU session identifier, and obtain 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 determination module 1601 determines the second verification result includes: receiving third request information sent by the first network side device, wherein the third request information includes the first URSP rule and the first PDU session identifier; obtain the first parameter of the first PDU session indicated by the first PDU session identifier; by verifying the first parameter and the routing descriptor in the first URSP rule Whether the second parameter described by RSD is consistent, the second verification result is obtained; the third acquisition module 1602 obtains the third verification result including: generating a packet detection according to the first URSP rule in the third request information Rule, apply the packet detection rule to the first PDU session indicated by the first PDU session identifier, and obtain 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 determining module 1601 determines that the second verification result includes: receiving fourth request information sent by the first network side device, wherein the fourth request information includes the first URSP rule and the first PDU session identifier, used to request verification of the first parameter of the first PDU session indicated by the first PDU session identifier and the second parameter described by the RSD in the first URSP rule. ; Obtain the first parameter of the first PDU session indicated by the first PDU session identifier; obtain the obtained first parameter by verifying whether it is consistent with the second parameter described by the RSD in the first URSP rule.
  • the second verification result; the third acquisition module 1602 obtaining the third verification result includes: receiving fifth request information sent by the first network side device, wherein the fifth request information includes the first The URSP rule and the first PDU session identifier are used to request verification of whether the first PDU session indicated by the first PDU session identifier includes the data packet of the target application; according to all the data packets in the fifth request information Describe the first URSP rule, generate a packet detection rule, apply the packet detection rule to the first PDU session indicated by the first PDU session identifier, and obtain a third verification result, wherein the packet detection rule is used for verification Whether the first PDU session includes the data packet of the target application.
  • Figure 17 shows another structural schematic diagram of a URSP rule verification device provided by an embodiment of the present application.
  • the device 1700 mainly includes: a second receiving module 1701 and a sending module 1702.
  • the second receiving module 1701 is configured to receive request information sent by the first network side device, where the request information includes: a first PDU session identifier and/or a first URSP rules, the first PDU session identifier is used to indicate the first PDU session carrying the target application of the terminal, and the first URSP rule is the URSP rule used by the terminal for the target application; sending module 1702, for Send the request information to the second network side device; wherein the request information is used for at least one of the following:
  • 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.
  • 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.
  • the communication device 1800 is a network-side device
  • 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.
  • the embodiment of the present application also provides a network side device.
  • the network side device 1900 includes: a processor 1901, a network interface 1902, and a memory 1903.
  • the network interface 1902 is, for example, a common public radio interface (CPRI).
  • CPRI common public radio interface
  • 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.
  • 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.
  • the processor is the processor in the terminal described in the above embodiment.
  • the readable storage Storage media include computer-readable storage media, such as computer read-only memory ROM, random access memory RAM, magnetic disks or optical disks, 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.
  • 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.
  • Embodiments of the present application also provide 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 third verification method of URSP rules as described above.
  • the second network-side device may be used to perform the steps performed by the second network-side device in the verification method of the URSP rule as described above.
  • 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.
  • 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.
  • the technical solution of the present application essentially or the part that contributes to the existing technology can be embodied in the form of a computer software product.
  • the computer software product is stored in a storage medium (such as ROM/RAM, magnetic disc, optical disk), including several instructions to cause a terminal (which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to execute the methods described in various embodiments of this application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请公开了一种URSP规则的验证方法、装置及网络侧设备，属于无线通信领域，本申请实施例的种URSP规则的验证方法，包括：第一网络侧设备接收终端发送的上报信息，其中，所述上报信息包括所述终端针对目标应用使用的第一URSP规则以及承载所述目标应用的第一PDU会话标识；所述第一网络侧设备通过验证所述第一URSP规则与第二URSP规则是否一致，获取第一验证结果；在所述第一验证结果指示所述第一URSP规则与所述第二URSP规则中至少一个规则一致的情况下，所述第一网络侧设备通过第二网络侧设备获取第二验证结果；所述第一网络侧设备通过所述第二网络侧设备获取第三验证结果。

Description

URSP规则的验证方法、装置及网络侧设备
交叉引用
本发明要求在2022年05月05日提交中国专利局、申请号为202210482912.1、发明名称为“URSP规则的验证方法、装置及网络侧设备”的中国专利申请的优先权，该申请的全部内容通过引用结合在本发明中。
技术领域
本申请属于无线通信技术领域，具体涉及一种URSP规则的验证方法、装置及网络侧设备。
背景技术
在第三代合作计划(3rd Generation Partnership Project，3GPP)协议中，当终端上的应用有流量要发送的时候，应用可以提供待发送的应用流量的流量特征，终端(User Equipment，UE)(OS操作系统或modem芯片)获取应用提供的流量特征，例如，待发送的应用流量的目的互联网协议(Internet Protocol，IP)地址、全限定域名(Fully Qualified Domain Name，FQDN)等。终端会将该流量特征与终端中的用户设备路由选项策略(UE Route Sel ection Policy，URSP)规则中的流量描述符(Traffic Descriptor，TD)参数进行匹配，匹配到某个流量描述符以后，然后终端再选择该流量描述符下的某个路由选择描述符(Route Selection Descriptor，RSD)。该路由选择描述符中定义了，当应用流量特性同某流量描述符匹配以后，用于承载待传输的应用流量的协议数据单元(Protocol Data Unit，PDU)会话的会话参数。如果当前UE已经有一个PDU会话，且该PDU会话的会话参数同终端为应用流量所选择的流量描述符下的某个RSD一致，那么可以将该应用的待传输数据路由至已建立的协议数据单元(Protocol Data Unit，PDU)会话。或者，如果终端为待传输的应用流量选择了该流量描述符下的某个RSD以后，而当前终端内不存在这样的PDU会话，那么终端可以触发新PDU会话的建立，所建立的PDU会话的会话参数，同选择的RSD内的PDU会话参数一致，并使用该PDU会话承载所述待传输的应用数据流。
然而，在相关技术中，URSP规则只是终端设备的行为，对于某个应用，网络侧设备并不能获知终端设备是否应用了网络侧设备为该终端设备配置的URSP规则去匹配应用流量到特定的PDU会话，以及终端设备匹配该应用流量具体使用的URSP规则。
发明内容
本申请实施例提供一种URSP规则的验证方法、装置及网络侧设备，能够解决网络侧设备无法获知终端设备是否应用配置的URSP规则以及终端设备针对具体应用使用的URSP规则的问题。
第一方面，提供了一种URSP规则的验证方法，包括：第一网络侧设备接收终端发送的上报信息，其中，所述上报信息包括所述终端针对目标应用使用的第一URSP规则以及承载所述目标应用的第一PDU会话标识，所述第一PDU会话标识用于指示第一PDU会话；所述第一网络侧设备通过验证所述第一URSP规则与第二URSP规则是否一致，获取第一验证结果，其中，所述第二URSP规则为所述第一网络侧设备发送给所述终端的与所述目标应用对应的至少一个URSP规则；在所述第一验证结果指示所述第一URSP规则与所述第二URSP规则中至少一个规则一致的情况下，所述第一网络侧设备通过第二网络侧设备获取第二验证结果，其中，所述第二验证结果指示所述第一PDU会话的第一参数与所述第一URSP规则中的路由选择描述符RS D描述的第二参数是否一致；所述第一网络侧设备通过所述第二网络侧设备获取第三验证结果，其中，所述第三验证结果指示所述第一PDU会话中是否包括所述目标应用的数据包。
第二方面，提供了另一种URSP规则的验证方法，包括：第二网络侧设备通过与第一网络侧设备交互，确定第二验证结果，其中，所述第二验证结果指示终端的第一PDU会话的第一参数与所述终端针对目标应用使用的第一URSP规则中的RSD描述的第二参数是否一致；所述第二网络侧设备通过验证所述第一PDU会话中是否包括所述目标应用的数据包，获取第三验证结果，其中，所述第三验证结果指示所述第一PDU会话中是否包括所述目标应用的数据包。
第三方面，提供了又一种URSP规则的验证方法，包括：第三网络侧设备接收所述第一网络侧设备发送的请求信息，其中，所述请求信息包括：第一PDU会话标识和/或第一URSP规则，所述第一PDU会话标识所指示的第一PDU会话为承载终端的目标应用的PDU会话，所述第一URSP规则为所述终端针对所述目标应用使用的URSP规则；所述第三网络侧设备将所述请求消息信息发送给第二网络侧设备；其中，所述请求信息用于以下至少之一：请求获取所述第一PDU会话的第一参数；请求验证所述第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数是否一致；请求根据所述第一URSP规则对所述第一PDU会话中是否包括所述目标应用的数据包。
第四方面，提供了一种URSP规则的验证装置，包括：第一接收模块，用于接收终端发送的上报信息，其中，所述上报信息包括所述终端针对目标 应用使用的第一URSP规则以及承载所述目标应用的第一PDU会话标识，所述第一PDU会话标识用于指示第一PDU会话；第一获取模块，用于通过验证所述第一URSP规则与第二URSP规则是否一致，获取第一验证结果，其中，所述第二URSP规则为所述第一网络侧设备发送给所述终端的与所述目标应用对应的至少一个URSP规则；第二获取模块，用于获取第二验证结果，其中，所述第二验证结果指示所述第一PDU会话的第一参数与所述第一UR SP规则中的路由选择描述符RSD描述的第二参数是否一致；通过所述第二网络侧设备获取第三验证结果，其中，所述第三验证结果指示所述第一PDU会话中是否包括所述目标应用的数据包。
第五方面，提供了另一种URSP规则的验证装置，包括：确定模块，用于通过与第一网络侧设备交互，确定第二验证结果，其中，所述第二验证结果指示终端的第一PDU会话的第一参数与所述终端针对目标应用使用的第一URSP规则中的RSD描述的第二参数是否一致；第三获取模块，用于通过验证所述第一PDU会话中是否包括所述目标应用的数据包，获取第三验证结果，其中，所述第三验证结果指示所述第一PDU会话中是否包括所述目标应用的数据包。
第六方面，提供了又一种URSP规则的验证装置，包括：第二接收模块，用于接收所述第一网络侧设备发送的请求信息，其中，所述请求信息包括：第一PDU会话标识和/或第一URSP规则，所述第一PDU会话标识所指示的第一PDU会话为承载终端的目标应用的PDU会话，所述第一URSP规则为所述终端针对所述目标应用使用的URSP规则；发送模块，用于将所述请求信息发送给第二网络侧设备；其中，所述请求信息用于以下至少之一：请求获取所述第一PDU会话的第一参数；请求验证所述第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数是否一致；请求根据所述第一URSP规则对所述第一PDU会话中是否包括所述目标应用的数据包。
第七方面，提供了一种网络侧设备，该网络侧设备包括处理器和存储器，所述存储器存储可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如第一方面至第三方面所述的方法的步骤。
第八方面，提供了一种网络侧设备，包括处理器及通信接口，其中，所述处理器用于实现如第一方面至第三方面所述的方法的步骤，所述通信接口用于与外部设备进行通信。
第九方面，提供了一种URSP规则的验证系统，包括：第一网络侧设备和第二网络侧设备，所述第一网络侧设备可用于执行如第一方面所述的方法的步骤，所述第二网络侧设备可用于执行如第二方面所述的方法的步骤。
第十方面，提供了一种可读存储介质，所述可读存储介质上存储程序或 指令，所述程序或指令被处理器执行时实现如第一方面所述的方法的步骤，或者实现如第二方面所述的方法的步骤，或者实现如第三方面所述的方法的步骤。
第十一方面，提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现如第一方面所述的方法的步骤，或者实现如第二方面所述的方法的步骤，或者实现如第三方面所述的方法的步骤。
第十二方面，提供了一种计算机程序/程序产品，所述计算机程序/程序产品被存储在存储介质中，所述计算机程序/程序产品被至少一个处理器执行以实现如第一方面所述的方法的步骤，或者实现如第二方面所述的方法的步骤，或者实现如第三方面所述的方法的步骤。
在本申请实施例中，第一网络侧设备在接收到终端发送的上报信息后，根据该上报信息中包括终端针对目标应用使用的第一URSP规则，验证所述第一URSP规则与第一网络侧设备发送给终端的与所述目标应用对应的至少一个URSP规则一致，并通过第二网络侧设备获取指示承载所述目标应用的第一PDU会话的第一参数与第一URSP规则中的RSD描述的经二参数是否一致的第二验证结果，以及指示第一PDU会话中是否包括目标应用的数据包的第三验证结果，从而使得网络侧设备可以获知终端是否应用了网络侧设备为该终端设备配置的URSP规则去匹配应用流量到特定的PDU会话、终端匹配该应用流量具体使用的URSP规则以及对应的PDU会话中是否包括该应用流量的数据包，便于网络侧设备对终端进行控制。
附图说明
图1示出本申请实施例可应用的一种无线通信系统的框图；
图2示出本申请实施例提供的URSP规则的验证方法的一种流程示意图；
图3示出本申请实施例提供的URSP规则的验证方法的另一种流程示意图；
图4示出本申请实施例提供的URSP规则的验证方法的又一种流程示意图；
图5示出本申请实施例提供的URSP规则的验证方法的又一种流程示意图；
图6示出本申请实施例提供的URSP规则的验证方法的又一种流程示意图；
图7示出本申请实施例提供的URSP规则的验证方法的又一种流程示意图；
图8示出本申请实施例提供的URSP规则的验证方法的又一种流程示意图；
图9示出本申请实施例提供的URSP规则的验证方法的又一种流程示意图；
图10示出本申请实施例提供的URSP规则的验证方法的又一种流程示意图；
图11示出本申请实施例提供的URSP规则的验证方法的又一种流程示意图；
图12示出本申请实施例提供的URSP规则的验证方法的又一种流程示意图；
图13示出本申请实施例提供的URSP规则的验证方法的又一种流程示意图；
图14示出本申请实施例提供的URSP规则的验证方法的又一种流程示意图；
图15示出本申请实施例提供的URSP规则的验证装置的一种结构示意图；
图16示出本申请实施例提供的URSP规则的验证装置的另一种结构示意图；
图17示出本申请实施例提供的URSP规则的验证装置的又一种结构示意图；
图18示出本申请实施例提供的一种通信设备的结构示意图；
图19示出本申请实施例提供的一种网络侧设备的硬件结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。
本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，以便本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施，且“第一”、“第二”所区别的对象通常为一类，并不限定对象的个数，例如第一对象可以是一个，也可以是多个。此外，说明书以及权利要求中“和/或”表示所连接对象的至少其中之一，字符“/”一般表示前后关联对象是一种“或”的关系。
值得指出的是，本申请实施例所描述的技术不限于长期演进型(Long T erm Evolution，LTE)/LTE的演进(LTE-Advanced，LTE-A)系统，还可用于其他无线通信系统，诸如码分多址(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)和其他系统。本申请实施例中的术语“系统”和“网络”常被可互换地使用，所描述的技术既可用于以上提及的系统和无线电技术，也可用于其他系统和无线电技术。以下描述出于示例目的描述了新空口(New Radio，NR)系统，并且在以下大部分描述中使用NR术语，但是这些技术也可应用于NR系统应用以外的应用，如第6代(6th Generation，6G)通信系统。
图1示出本申请实施例可应用的一种无线通信系统的框图。无线通信系统包括终端(User Equipment，UE)11和网络侧设备12。其中，终端11可以是手机、平板电脑(Tablet Personal Computer)、膝上型电脑(Laptop Computer)或称为笔记本电脑、个人数字助理(Personal Digital Assistant，PDA)、掌上电脑、上网本、超级移动个人计算机(ultra-mobile personal computer，UMPC)、移动上网装置(Mobile Internet Device，MID)、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、机器人、可穿戴式设备(Wearable Device)、车载设备(VehicleUser Equipment，VUE)、行人终端(Pedestrian User Equipment，PUE)、智能家居(具有无线通信功能的家居设备，如冰箱、电视、洗衣机或者家具等)、游戏机、个人计算机(personal computer，PC)、柜员机或者自助机等终端侧设备，可穿戴式设备包括：智能手表、智能手环、智能耳机、智能眼镜、智能首饰(智能手镯、智能手链、智能戒指、智能项链、智能脚镯、智能脚链等)、智能腕带、智能服装等。需要说明的是，在本申请实施例并不限定终端11的具体类型。网络侧设备12可以包括接入网设备和/或核心网设备，其中，接入网设备12也可以称为无线接入网设备、无线接入网(Radio Access Network,RAN)、无线接入网功能或无线接入网单元。接入网设备12可以包括基站、无线局域网(Wireless Local Area Network，WLAN)接入点或无线保真(Wireless Fidelity，WiFi)节点等，基站可被称为节点B、演进节点B(eNB)、接入点、基收发机站(Base Transceiver Station，BTS)、无线电基站、无线电收发机、基本服务集(Basic Service Set，BSS)、扩展服务集(Extended Service Set，ESS)、家用B节点、家用演进型B节点、发送接收点(Transmitting Receiving Point，TRP)或所述领域中其他某个合适的术语，只要达到相同的技术效果，所述基站不限于特定技术词汇，需要说明的是，在本申请实施例中仅以NR系统中的基 站为例进行介绍，并不限定基站的具体类型。核心网设备可以包含但不限于如下至少一项：核心网节点、核心网功能、移动管理实体(Mobility Management Entity，MME)、接入移动管理功能(Access and Mobility Management Function，AMF)、会话管理功能(Session Management Function，SMF)、用户平面功能(User Plane Function，UPF)、策略控制功能(Policy Control Function，PCF)、策略与计费规则功能单元(Policy and Charging Rules Function，PCRF)、边缘应用服务发现功能(Edge Application Server Discovery Function，EASDF)、统一数据管理(Unified Data Management，UDM)，统一数据仓储(Unified Data Repository，UDR)、归属用户服务器(Home Subscriber Server，HSS)、集中式网络配置(Centralized network configuration，CNC)、网络存储功能(Network Repository Function，NRF)，网络开放功能(Network Exposure Function，NEF)、本地NEF(Local NEF，或L-NEF)、绑定支持功能(Binding Support Function，BSF)、应用功能(Application Function，AF)等。需要说明的是，在本申请实施例中仅以NR系统中的核心网设备为例进行介绍，并不限定核心网设备的具体类型。
URSP规则(rules)是3GPP定义的一种给UE发送的策略，UE根据这个URSP规则可以匹配应用(Application，APP)的流量到特定的PDU会话(session)。
比如，当UE上的应用(APP)有流量需要发送到服务器端的时候，APP可以发送APP流量特征给UE，这些流量特征可以目的IP地址、FQDN等。然后UE根据APP的流量特征，去逐个匹配UE内的URSP规则，在URSP rules里，所规定的流量描述/特征可以如表1所示。
表1.

比如说，第二项APP可以发送一个IP描述，比如，目的IP三元组，表明该APP的这个流量是需要发给目的IP＝10.1.1.1，端口号＝80的一个流量。然后，如果UE URSP rules里恰好有这个流量描述符(Traffic descriptor)，则说明APP的这个流量可以匹配到某一个URSP rules。
在有URSP rules匹配APP的流量以后，下一步则需要选择使用哪个PD U会话(session)发送APP的流量(traffic)。
一般来说，某个Traffic descriptor下，有至少一个RSD，每个RSD代表了一个PDU session的一组属性。比如说，当APP traffic匹配到目的IP＝10.1.1.1，端口号＝80的这一组traffic descriptor，然后这一组traffic descriptor下有如下几个RSD：
比如，RSD1对应的PDU会话的特性或会话的参数为：S-NSSAI＝S-NSSAI-a，使用non-3GPP接入。终端可以使用这个RSD1里的PDU会话特定建立PDU会话；或者使用这个特性，去选择终端已经建立的PDU会话。被选择的PDU会话，其会话特性或会话参数，为，S-NSSAI＝S-NSSAI-a，使用non-3GPP接入(即PDU会话的接入类型为非3GPP接入)。
然而，在网络侧设备给UE发送URSP rules以后，对于APP的traffic，UE是否使用了URSP rules去匹配APP流量到特定的PDU会话，以及使用了哪个URSP规则进行流量匹配，对于网络侧设备来说都是未知的。比如，针对某个应用的流量，UE匹配到的流量描述符的RSD包括：

而网络侧设备并不知道UE是否执行了URSP rules以及如果执行了，执行了哪个URSP规则。针对该问题，本申请实施例提供了URSP规则的验证方案，使得网络侧设备可以获知这些信息。
下面结合附图，通过一些实施例及其应用场景对本申请实施例提供的U RSP规则的验证方案进行详细地说明。
图2示出本申请实施例中的URSP规则的验证方法的一种流程示意图，该方法200可以由第一网络侧设备执行。换言之，所述方法可以由安装在第一网络侧设备上的软件或硬件来执行。在本申请实施例中，第一网络侧设备可以为接入及移动性管理策略控制网元，例如，第一网络侧设备可以为接入及移动性管理策略控制功能(Access and Mobility Management Policy Control Function，AM-PCF)。如图2所示，该方法可以包括以下步骤。
S210，第一网络侧设备接收终端发送的上报信息，其中，所述上报信息包括所述终端针对目标应用使用的第一URSP规则以及第一PDU会话标识，所述第一PDU会话标识用于指示承载所述目标应用的第一PDU会话。
比如说，终端为某个应用流量使用了URSP规则以后，可以上报具体使用的URSP规则的细节，比如，使用了某个Traffic descriptor(FQDN＝ABC.com)，或使用了某个RSD(S-NSSAI＝S-NSSAI-a，使用non-3GPP接入)；也可以直接指示所述使用的规则优先级或RSD的优先级，因为对于一个终端，一个规则优先级只对应一个流量描述符，一个流量描述符下面的RSD的优先级只对应一个RSD。比如说，终端上报第一URSP规则如下：rule precedence＝1，RSD precedence＝2，这就说明终端使用了优先级为1的规则和该流量描述符下RSD优先级为2的RSD。
所述第一PDU会话标识，指示所述应用流量最终匹配到的PDU会话，该PDU会话可以是新建的会话，也可以是终端里已有的会话。此处，终端上报给第一网络侧设备的上报信息中也可以包括一个指示信息，该指示信息用于指示使用URSP规则以后是新建PDU会话还是匹配到终端上已有的PDU会话。比如说，该指示信息指示使用第一URSP规则以后，新建了一个PDU会话承载该应用流量。
S212，所述第一网络侧设备通过验证所述第一URSP规则与第二URSP规则是否一致，获取第一验证结果，其中，所述第二URSP规则为所述第一网络侧设备发送给所述终端的与所述目标应用对应的至少一个URSP规则。所述第一验证结果主要包括：第一URSP规则与第二URSP规则一致，第一验证通过；或第一URSP规则与第二URSP规则不一致，第一验证失败。
例如，终端为目标应用的流量执行URSP规则，然后终端将所使用的URSP规则发给AM-PCF。AM-PCF执行第一次验证，验证终端上报的这个规则和AM-PCF发给UE的规则是否一致，即验证终端上报的URSP规则是否为AM-PCF发送给UE的URSP规则中的一个。
比如，终端自己上报使用的URSP规则：Rule Precedence＝1和RSD Precedence＝1。第一网络侧设备可以根据终端上报的信息，恢复或者在AM-PCF中查询该优先级对应的URSP规则，或者AM-PCF检查发送给UE的第二URSP规则。比如说，根据终端上报的Rule Precedence＝1和RSD Precedence＝1，AM-PCF经检查，发现给这个UE发送的URSP规则如下：
Rule Precedence＝1；
流量描述符(Traffic Descriptor)：应用描述符(Application descriptor)＝App1；
RSD Precedence＝1；
网络切片标识符(Network Slice Selection)：S-NSSAI-a；
会话和服务连续性(Session and Service Continuity，SSC)模式(Mode Selection)：SSC Mode 3；
数据网络名称(Data Network Name，DNN)选择(Selection)：internet；
接入类型优先(Access Type preference)：3GPP接入(access)。
而终端上报了一个使用的第一URSP规则为：
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。
则第一网络侧设备确定终端上报的使用规则(即第一URSP规则)和实际第一网络侧设备发送UE发的规则(即第二URSP规则)一样，验证通过，UE上报的规则正确。这里的验证是指：验证终端所上报的使用的URSP规则，包括流量描述符和RSD，与第一网络侧设备发给终端的URSP规则里的流量描述符或RSD是否一致。如果一致，则确定终端严格使用了AM-PCF下发的任何URSP规则之一，而不是终端自己随意使用了一个网络根本没有下发过的URSP规则。
S214，在所述第一验证结果指示所述第一URSP规则与所述第二URSP规则中至少一个规则一致的情况下，所述第一网络侧设备通过第二网络侧设 备获取第二验证结果，其中，所述第二验证结果指示所述第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数是否一致。所述第二验证结果包括：所述第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数，逐项一一对应且一致，则第二验证通过；所述第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数中，任意一项不一致，则第二验证失败。
在第一验证结果指示所述第一URSP规则与所述第二URSP规则中至少一个规则一致的情况下，所述第一网络侧设备可以启动第二验证，通过第二网络侧设备获取第二验证结果。如果第一网络侧设备发现第一验证没有通过，则直接判定所述终端没有正确使用URSP规则，也就不再执行第二验证了。
在一个可能的实现方式中，所述第一PDU会话的第一参数可以包括以下至少一项：PDU会话类型、PDU会话的接入类型、SSC模式、网络切片标识符、DNN。
在一个可能的实现方式中，所述第一URSP规则中的RSD描述的第二参数可以包括以下至少一项：PDU会话类型、PDU会话的接入类型、SSC模式、网络切片标识符、DNN。
在本申请实施例中，所述第一参数与所述第二参数是否一致是指所述第一参数中的各个参数的参数值是否分别与所述第二参数中对应的参数的参数值一致。例如，在第一参数和第二参数分别包括：PDU会话类型、PDU会话的接入类型、SSC模式以及DNN的情况下，则第一参数与第二参数是否一致是指第一参数中的PDU会话类型与第二参数中的PDU会话类型相同，第一参数中的PDU会话接入类型与第二参数中的PDU会话接入类型相同，第一参数中的SSC模式与第二参数中的SSC模式相同，第一参数中的DNN与第二参数中的DNN相同。如果其中任一项不同，则第一参数与第二参数不一致。
进行第二验证的目的是使得所述终端如果真的正确的使用了第一URSP规则，则所述承载应用流量的第一PDU会话的PDU会话的参数，比如SSC模式，DNN等，必须与第一URSP规则里的RSD里指示的PDU会话的参数，比如SSC模式，DNN等，逐个一一对应且相同。
在S214中，第一网络侧设备获取第二验证结果，以获知承载目标应用的第一PDU会话的第一参数与第一URSP规则中的RSD描述的第二参数是否一致。
第一网络侧设备为接入及移动性管理的策略控制网元，不能获知终端使用的第一PDU会话的第一参数，因此，第一网络侧设备可以通过第二网络侧设备获取第二验证结果。其中，第二网络侧设备可以为会话管理网元，例如， 会话管理功能(Session Management Function，SMF)。
例如，终端上报的使用的第一URSP规则为：
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。
而第二网络侧设备经过检查获取实际承载目标应用(即APP1)流量的第一PDU会话，该第一PDU会话的第一参数为：
Network Slice Selection:S-NSSAI-b；
SSC Mode Selection:SSC Mode 3；
DNN Selection:internet；
Access Type preference:3GPP access。
由此可见，第二参数中的网络切片为S-NSSAI-b，而第一参数中的网络切片为S-NSSAI-b，两者不一致，因此，终端并没有正确使用URSP规则。也就是说，终端虽然上报了自己用的URSP规则，但是其实所述APP的流量并没有真正的使用这个RSD的各项PDU会话参数所对应的PDU会话承载。这就说明，第二验证没有通过，所述终端没有正确使用URSP规则。如果第二验证没有通过，则下述的第三验证也将不再继续执行。
S216，所述第一网络侧设备通过所述第二网络侧设备获取第三验证结果，其中，所述第三验证结果指示所述第一PDU会话中是否包括所述目标应用的数据包。所述第三验证结果包括以下至少一项：第一PDU会话中包括所述目标应用的数据包，所述第三验证通过；第一PDU会话中不包括所述目标应用的数据包，则所述第三验证失败。
通过步骤S216，第一网络侧设备可以获知目标应用的流量是否在第一PDU会话。
这种方式是为了验证所述第一PDU会话中是否真正存在应用数据包。一种可能的情况是，终端虽然声明使用了第一URSP规则，网络侧也确实检查所述第一PDU会话的会话参数跟第一URSP规则里的RSD指示的会话参数一致，但是可能终端并没有真正使用这个第一PDU会话进行传输应用流量，而是使用了其他PDU会话。这样的话，还需要进行深度包检测，来确定所述第一PDU会话是否真正的承载了所述应用流量的传输。
可选地，第一网络侧设备可以在第二验证结果指示所述第一参数与所述 第二参数不一致的情况下，例如，所述第一参数中的至少一项与所述第二参数不一致的情况下，启动第三次验证，通过所述第二网络侧设备获取第三验证结果。比如说，所述AM-PCF可以请求SMF直接同时完成第二验证或第三验证。
在一个可能的实现方式中，所述方法还包括：在以下任一情况下，所述第一网络侧设备向所述第二网络侧设备发送第一指示信息，其中，所述第一指示信息用于指示所述终端未正确使用URSP规则：
(1)所述第一验证结果指示所述第一URSP规则与所述第二URSP规则不一致；也就是说，在所述第一URSP规则与所述第二URSP规则不一致的情况下，第一网络侧设备确定所述终端未正确使用URSP规则。
(2)所述第二验证结果指示所述第一参数中的至少一项参数与所述第二参数不一致；也就是说，在所述第一参数中的至少一项参数与所述第二参数不一致的情况下，第一网络侧设备确定所述终端未正确使用URSP规则。
(3)所述第三验证结果指示所述第一PDU会话对应的传输数据包中未包括所述目标应用的数据包。也就是说，在所述第一PDU会话对应的传输数据包中未包括所述目标应用的数据包的情况下，第一网络侧设备确定所述终端未正确使用URSP规则。
第二网络侧设备在接收到上述第一指示信息之后，可以执行相应的操作，例如，拒绝与所述第一PDU会话标识对应的会话建立请求或修改请求，或者，释放与所述第一PDU会话标识对应的第一PDU会话。其中，拒绝所述会话建立请求或修改请求，是指拒绝上报第一URSP规则的终端的PDU会话建立请求或修改请求。或者，由于终端误用了URSP规则，则承载这个应用的PDU会话将被释放，或者，在释放这个PDU会话之前，网络侧根据第一URSP规则里的RSD指示的PDU会话参数，触发建立新的PDU会话，迁移所述应用流量在新的PDU会话上承载，然后再释放原有会话。
比如，当第二网络侧设备(SMF)收到第一指示以后，所述终端未正确使用URSP规则，则第二网络侧设备执行以下至少一项：
(1)发送PDU会话建立拒绝(PDU session establishment reject)到终端(可以经AMF转发至终端)；
(2)发送PDU会话修改拒绝(PDU session modification reject)到终端(可以经AMF转发至终端)；
(3)第二网络设备触发PDU会话释放(PDU session release)过程，释放所述第一PDU会话标识对应的第一PDU会话；
(4)第二网络设备，触发PDU会话修改指令(PDU session modification command)到终端(可以经AMF转发至终端)；然后，所述终端触发一 个PDU会话建立请求(PDU session establishment request)到第二网络设备(所述会话建立请求可以经AMF转发)。本方法对应在本申请实施例中，由于第一URSP规则未被正确使用，第二网络设备请求终端修改会话，终端接受请求后，建立新的PDU会话，然后将所述第一PDU会话中承载的业务，切换至新建的PDU会话上。最后，终端或第二网络设备再释放第一PDU会话。
在一个可能的实现方式中，该方法还可以包括：在以下任一情况下，所述第一网络侧设备更新所述终端的URSP规则：
(1)所述第一验证结果指示所述第一URSP规则与所述第二URSP规则不一致；
(2)所述第二验证结果指示所述第一参数中的至少一项参数与所述第二参数不一致；
(3)所述第三验证结果指示所述第一PDU会话对应的传输数据包中未包括所述目标应用的数据包。
在上述任一情况下，第一网络侧设备确定终端未正确使用URSP规则，可以更新所述终端的URSP规则，例如，重执行终端的URSP策略并下发给终端。这种情况是说，如果终端没有正确使用规则，可能是规则设计不合理导致的，因此需要第一网络侧设备更新终端的所述URSP规则。
通过本申请实施例提供的上述技术方案，第一网络侧设备在接收到终端发送的上报信息后，根据该上报信息中包括终端针对目标应用使用的第一URSP规则，验证所述第一URSP规则与第一网络侧设备发送给终端的与所述目标应用对应的至少一个URSP规则一致，并通过第二网络侧设备获取指示承载所述目标应用的第一PDU会话的第一参数与第一URSP规则中的RSD描述的经二参数是否一致的第二验证结果，以及指示第一PDU会话中是否包括目标应用的数据包的第三验证结果，从而使得网络侧设备可以获知终端是否应用了网络侧设备为该终端设备配置的URSP规则去匹配应用流量到特定的PDU会话、终端匹配该应用流量具体使用的URSP规则以及对应的PDU会话中是否包括该应用流量的数据包，便于网络侧设备对终端进行控制。
在本申请实施例中，图3示出本申请实施例提供的URSP规则的验证方法的另一流程示意图，在该方法300中，第一网络侧设备通过第二网络侧设备获取所述第二验证结果的实现方式可以是：第一网络侧设备可以从第二网络侧设备获取承载所述目标应用的第一PDU会话的第一参数，然后验证所述第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数是否一致。如图3所示，该方法300主要包括以下步骤。
S310，同S210。
S312，同S212。
S314，所述第一网络侧设备从所述第二网络侧设备获取所述第一PDU会话的第一参数。
在一个可能的实现方式中，第一网络侧设备可以通过向第二网络侧设备发送请求以获取所述第一PDU会话的第一参数。因此，在一个可能的实现方式中，S314可以包括：所述第一网络侧设备向所述第二网络侧设备发送第一请求信息，其中，所述第一请求信息包括所述第一PDU会话标识，用于请求所述第一PDU会话标识对应的第一PDU会话的第一参数；所述第一网络侧设备接收所述第二网络侧设备发送的第一响应信息，其中，所述第一响应信息包括所述第一PDU会话的第一参数。
可选地，所述第一参数可以包括以下至少一项：PDU会话类型、PDU会话的接入类型、会话和服务连续性SSC模式、网络切片标识符、DNN。
比如说，第一网络侧设备(例如，AM-PCF)可以发送一个请求，所述请求包括第一PDU会话标识，所述请求用于获得该PDU会话标识所对应的PDU会话的参数，比如说PDU会话类型、PDU会话的接入类型、会话和服务连续性SSC模式、网络切片标识符、DNN。这个请求可以使用如下的信令发送：Nsmf_EventExposure Subscribe，或者Npcf_AMPolicyControl_Notify，或者是Npcf_UEPolicyControl_Notify等其他信令。
S316，第一网络侧设备通过验证所述第一参数与所述第一URSP规则中的路由选择描述符RSD描述的第二参数是否一致，获取所述第二验证结果。
第一网络侧设备可以比较接收到所述第一PDU会话的第一参数与终端所使用的第一URSP规则中的RSD描述的第二参数是否一致。具体地，所述第一参数与所述第二参数是否一致可以参见上述方法200中的描述。例如，AM-PCF获取第一PDU会话的参数以后，在AM-PCF里进行比较，完成第二验证，得到第二验证结果。
S318，第一网络侧设备通过所述第二网络侧设备获取第三验证结果，其中，所述第三验证结果指示所述第一PDU会话中是否包括所述目标应用的数据包。
在一个可能的实现方式中，所述第一网络侧设备发送的第一请求信息中可以包括所述第一URSP规则，请求第二网络侧设备验证所述第一PDU会话中是否包括所述目标应用的数据包，也就是说，第一请求信息用于请求第一PDU会话标识对应的第一PDU会话的第一参数，并请求第二网络侧设备验证所述第一PDU会话中是否包括所述目标应用的数据包。第二网络侧设备在接收到第一请求信息之后，可以基于所述第一URSP规则中的RSD和/或TD生成包检测规则，将该包检测规则应用于所述第一PDU会话标识对应的第一 PDU会话，获取所述第三验证结果，将所述第三验证结果返回给第一网络侧设备。可选地，所述第三验证结果可以包括在所述第一响应信息中。例如，AM-PCF可以直接请求SMF，一方面获取第一PDU会话参数，进行第二验证，以获取第二验证结果；同时，指示SMF根据第一URSP规则生成数据包检测规则(Packet Detection Rule，PDR)，执行第三验证。所述第二验证和第三验证的执行相互不影响。
在本申请实施例的一个可能的实现方式中，第一网络侧设备也可以分别向第二网络侧设备请求第一PDU会话的第一参数以及请求所述第二网络侧设备验证所述第一PDU会话中是否包括所述目标应用的数据包。因此，在该可能的实现方式中，S318还可以包括：在向所述第二网络侧设备发送第一请求信息之后或在接收所述第二网络侧设备发送的第一响应信息之后，所述第一网络侧设备向所述第二网络侧设备发送第二请求信息，接收所述第二网络侧设备返回的所述第三验证结果，其中，所述第二请求信息用于请求获取所述第三验证结果，所述第二请求信息包括所述第一PDU会话标识和所述第一URSP规则。采用该这种实施方式，第一网络侧设备可以先等待第二网络侧设备反馈的第一PDU会话的参数，然后第一网络侧设备执行第二验证。如果所述第二验证通过以后，第一网络侧设备再发送第二请求，请求第二网络侧设备执行第三验证。这种方式下，第二验证和第三验证有先后顺序，在所述第二验证未通过的情况下，不能执行第三验证。
在上述可能的实现方式中，可选地，第一网络侧设备接收所述第二网络侧设备返回的所述第三验证结果，可以包括：所述第一网络侧设备接收所述第二网络侧设备返回的第二响应信息，其中，所述第二响应信息包括所述第三验证结果，所述第二响应信息用于响应所述第二请求信息。所述第三验证结果是指在所述第一PDU会话中是否查询到了所述目标应用的数据包，得到的结果为：查询到目标数据包或者未查询到目标数据包。
在上述可能的实现方式中，可选地，第一网络侧设备可以在所述第二验证结果指示所述第一参数与所述第二参数一致的情况下，所述第一网络侧设备向所述第二网络侧设备发送所述第二请求信息。也就是说，第一网络侧设备可以在第二次验证通过的情况下，再请求第二网络侧设备执行第三次验证，即验证所述第一PDU会话中是否包括所述目标应用的数据包。从而可以减少不必要的流程，节约验证的时间。
图4示出本申请实施例提供的URSP规则的验证方法的又一种流程示意图，在方法400中，第一网络侧设备通过第二网络侧设备获取所述第二验证结果的实现方式是：第一网络侧设备将第一PDU会话标识和所述第一URSP规则发送给第二网络侧设备，请求第二网络侧设备验证所述第一参数与所述 第二参数是否相同，从而从第二网络侧设备获取所述第二验证结果。如图4所示，该方法主要包括以下步骤。
S410，同步骤S210。
S412，同步骤S212。
S414，第一网络侧设备向所述第二网络侧设备发送第三请求信息，其中，所述第三请求信息包括所述第一URSP规则以及所述第一PDU会话标识。
可选地，第一网络侧设备可以在第一验证结果指示所述第一URSP规则与所述第二URSP规则中至少一个规则一致的情况下，即对所述终端针对目标应用使用的第一URSP规则验证(即第一次验证)通过之后，执行S414，通过第三请求信息，请求第二网络侧设备验证所述第一PDU会话标识对应的第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数是否一致，以及验证所述第一PDU会话标识对应的第一PDU会话中是否包括目标应用的数据包。这种方式是说，执行第二验证的主体由第一网络侧设备改为第二网络侧设备(例如，SMF)。例如，AM-PCF发送所述第一URSP规则给SMF，SMF先根据第一PDU会话ID恢复所述第一PDU会话的会话参数，然后SMF来执行将第一PDU会话的会话参数，和第一URSP规则里的RSD里指示的会话参数进行逐一比较，进行第二验证。SMF再将所述验证结果发给AM-PCF。
S416，第一网络侧设备获取所述第二网络侧设备发送的第三响应信息，其中，所述第三响应信息包括所述第二网络侧设备对所述第一参数与所述第二参数进行验证得到的所述第二验证结果，以及所述第二网络侧设备对所述第一PDU会话中是否包括所述目标应用的数据包进行验证得到的所述第三验证结果。
第二网络侧设备在接收到第三请求信息之后，可以获取与所述第一PDU会话标识对应的第一PDU会话的第一参数，将所述第一PDU会话的第一参数与所述第三请求信息中的第一URSP规则中的RSD中的第二参数进行对比，判断所述第一参数与所述第二参数是否一致，得到第二验证结果，并根据第一URSP规则，生成包检测规则，将包检测规则应用到所述第一PDU会话标识对应的第一PDU会话，获取所述第三验证结果，将第二验证结果和第三验证结果通过第三响应信息返回给第一网络侧设备。
图5示出本申请实施例提供的URSP规则的验证方法的又一种流程示意图，方法500与方法400的不同之处在于，第一网络侧设备分别请求第二网络侧设备验证所述第一PDU会话标识对应的第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数是否一致，以及验证所述第一PDU会话标识对应的第一PDU会话中是否包括目标应用的数据包。如图5所 示，该URSP规则的验证方法500可以包括以下步骤。
S510，同步骤S210。
S512，同步骤S212。
S514，所述第一网络侧设备向所述第二网络侧设备发送第四请求信息，其中，所述第四请求信息包括所述第一URSP规则以及所述第一PDU会话标识，用于请求所述第二网络侧设备对所述第一参数与所述第二参数进行验证。本实施例中，第四请求是第一网络侧设备(例如，AM-PCF)指示第二网络侧设备(例如，SMF)，完成第二验证，而不包括第三验证的任务。第二网络侧设备进行第二验证的方法同上图4实施例。
可选地，第一网络侧设备可以在第一验证结果指示所述第一URSP规则与所述第二URSP规则中至少一个规则一致的情况下，即对所述终端针对目标应用使用的第一URSP规则验证(即第一次验证)通过之后，执行S514，通过第四请求信息，请求第二网络侧设备验证所述第一PDU会话标识对应的第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数是否一致。
S516，所述第一网络侧设备获取所述第二网络侧设备发送的第四响应信息，其中，所述第四响应信息包括所述第二网络侧设备对所述第一参数与所述第二参数进行验证得到的所述第二验证结果。
第二网络侧设备在接收到第三请求信息之后，可以获取与所述第一PDU会话标识对应的第一PDU会话的第一参数，将所述第一PDU会话的第一参数与所述第三请求信息中的第一URSP规则中的RSD中的第二参数进行对比，判断所述第一参数与所述第二参数是否一致，得到第二验证结果，通过第四响应信息向所述第一网络侧设备返回所述第二验证结果。
S518，所述第一网络侧设备向所述第二网络侧设备发送第五请求信息，其中，所述第五请求信息包括所述第一URSP规则以及所述第一PDU会话标识，用于请求所述第二网络侧设备对所述第一PDU会话中是否包括所述目标应用的数据包进行验证。所述第五请求可以是第一网络侧设备(例如，AM-PCF)在已经得到第二验证结果为：终端正确使用URSP规则(或者，所述第一PDU会话的会话参数跟第一URSP规则里的RSD指示的PDU会话参数一致)的前提下，指示SMF进行第三验证。
可选地，第一网络侧设备可以在第二验证结果指示所述第一参数与所述第二参数一致的情况下，执行S518，以避免不必要的流程。
S520，所述第一网络侧设备获取所述第二网络侧设备发送的第五响应信息，其中，所述第五响应信息包括所述第二网络侧设备对所述第一PDU会话中是否包括所述目标应用的数据包进行验证得到的所述第三验证结果。
第二网络侧设备在接收到第五请求信息之后，根据所述第五请求信息中的第一URSP规则，生成包检测规则，将包检测规则应用到所述第一PDU会话标识对应的第一PDU会话，获取所述第三验证结果，将第三验证结果通过第四响应信息返回给第一网络侧设备。
图6示出本申请实施例提供的URSP规则的验证方法的又一种流程示意图，该方法600可以由上述第二网络侧设备执行，换而言之，该方法600可以由安装在第二网络侧设备上的软件或硬件来执行。在本申请实施例中，第二网络侧设备可以为会话管理网元，例如，会话管理功能(Session Management Function，SMF)实体。如图6所示，该方法可以包括以下步骤。
S610，第二网络侧设备通过与第一网络侧设备交互，确定第二验证结果，其中，所述第二验证结果指示承载终端的目标应用的第一PDU会话的第一参数与所述终端针对所述目标应用使用的第一URSP规则中的RSD描述的第二参数是否一致。
在一个可能的实现方式中，S610可以包括以下步骤：
步骤1，所述第二网络侧获取所述第一网络侧设备发送的第一请求信息，其中，所述第一请求信息包括第一PDU会话标识，所述第一PDU会话标识用于指示第一PDU会话。
其中，第一请求信息可以用于请求获取第一PDU会话标识对应的第一PDU会话的第一参数。
步骤2，所述第二网络侧设备获取所述第一PDU会话的第一参数。
可选地，所述第一参数包括以下至少一项：PDU会话类型、PDU会话的接入类型、SSC模式、网络切片标识符、DNN。SMF直接根据第一PDU会话标识可以找到该标识对应的PDU会话的会话参数，也就是第一参数。
步骤3，所述第二网络侧设备返回第一响应信息，其中，所述第一响应信息包括所述第一PDU会话的第一参数，指示所述第一网络侧设备验证所述第一参数与所述第二参数是否一致。
在一个可能的实现方式中，所述第二参数包括以下至少一项：PDU会话类型、PDU会话的接入类型、SSC模式、网络切片标识符、DNN。
该可能的实现方式与上述方法300对应，第一网络侧设备在接收到第二网络侧设备返回的第一响应消息之后，可以将所述第一响应消息中包括的所述第一PDU会话的第一参数与所述终端使用的第一URSP规则中的RSD描述的第二参数进行比较，判断所述第一参数与所述第二参数是否一致，具体可以参见上述方法300中的描述。也就是说，所述第二网络侧设备(例如，SMF)既可以只反馈第一PDU会话的第一参数，让第一网络侧设备(例如，AM-PCF)来进行第二验证；也可以第二网络侧设备自己完成第二验证，将 第二验证的结果反馈给第一网络侧设备。例如，所述SMF可以发送给AM-PCF的第一响应，该第一响应可以通过如下信令发送：Nsmf_EventExposure_Notify，或者Npcf_AMPolicyControl_Subscribe，或者是Npcf_UEPolicyControl_Subscribe等其他信令。
S612，所述第二网络侧设备通过验证所述第一PDU会话中是否包括所述目标应用的数据包，获取第三验证结果，其中，所述第三验证结果指示所述第一PDU会话中是否包括所述目标应用的数据包。
在一个可能的实现方式中，上述第一请求信息还可以包括所述第一URSP规则，第一请求信息还用于请求所述第二网络侧设备验证所述第一PDU会话中是否包括所述目标应用的数据包。S612可以包括：第二网络侧设备在接收到所述第一请求信息后，根据所述第一请求信息中的所述第一URSP规则，生成包检测规则，将所述包检测规则应用于所述第一PDU会话标识指示的第一PDU会话，获取第三验证结果，其中，所述包检测规则用于验证所述第一PDU会话中是否包括所述目标应用的数据包。也就是说，第一请求信息同时指示SMF完成第三验证。
在一个可能的实现方式中，所述第二网络侧设备根据所述第一URSP规则，生成所述包检测规则。所述包检测规则的一种生成方法可以为：第二网络侧设备(例如，SMF)根据AM-PCF发送的第一URSP规则里的流量描述符，比如IP描述符等，生成包检测规则。或者，第二网络侧设备(例如，SMF)根据第一网络侧设备(例如，AM-PCF)发送的第一URSP规则里的流量描述符，比如说，域名描述符FQDN，DNN等，将这个FQDN、DNN、APP描述符、连接能力等，转换成IP描述符，然后生成所述包检测规则。由于所述包检测规则只有IP五元组，而第一URSP规则里，除了IP描述符可以直接用于生成包检测规则以外，其余的描述符，比如APP描述符、域名描述符、DNN、连接能力等，都无法直接生成包检测规则(PDR)，但是SMF可以具备这样的能力，将所述APP描述符、域名描述符、DNN、连接能力等描述符，转换成IP五元组，或者IP描述符，然后，可以将转换后的IP描述符直接用于PDR的生成。另一种方式是5G核心网(5G Core Network，5GC)(比如，AMF，AM-PCF，SM-PCF等)具备这样的转换能力，将所述APP描述符、域名描述符、DNN、连接能力等描述符，转换成IP五元组，或者IP描述符。
可选地，所述第一响应信息中还可以包括所述第三验证结果。
在一个可能的实现方式中，第一网络侧设备也可以分别请求所述第一PDU会话的第一参数以及请求所述第二网络侧设备验证所述第一PDU会话中是否包括所述目标应用的数据包。因此，S612可以包括：
步骤1，在接收到所述第一请求信息后或者在向所述第二网络侧设备返回第一响应信息之后，所述第二网络侧设备获取所述第一网络侧设备发送的第二请求信息，其中，所述第二请求信息用于请求获取所述第三验证结果，所述第二请求信息中携带有所述第一PDU会话标识和所述第一URSP规则。
例如，第一网络侧设备可以在发送第一请求信息之后，发送所述第二请求信息。或者，第一网络侧设备也可以在接收到所述第二网络侧设备返回的第一响应信息之后，发送所述第二请求信息，例如，第一响应信息中所述第二验证结果指示所述第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数一致的情况下，发送所述第二请求消息。这种方式是，当第一网络侧设备(例如，AM-PCF)确定所述第二验证通过以后，才指示第二网络侧设备(例如，SMF)进行第三验证。
步骤2，所述第二网络侧设备根据第二请求信息中的所述第一URSP规则，生成包检测规则，将所述包检测规则应用于所述第一PDU会话标识所指示的第一PDU会话，获取第三验证结果，其中，所述包检测规则用于验证所述第一PDU会话中是否包括所述目标应用的数据包。
在一个可能的实现方式中，在上述步骤2中，第二网络侧设备在获取所述第三验证结果后，可以向第一网络侧设备返回第二响应信息，该第二响应信息包括所述第三验证结果。
在本申请实施例中，也可以由第二网络侧设备验证所述第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数是否一致。因此，在一个可能的实现方式中，如图4所示，该URSP规则的验证方法可以包括以下步骤。
S411，第二网络侧设备接收所述第一网络侧设备发送的第三请求信息，其中，所述第三请求信息包括所述第一URSP规则以及所述第一PDU会话标识。
在该可能的实现方式中，第三请求信息用于请求所述第二验证结果和所述第三验证结果，即所述第三请求信息用于请求所述第二网络侧设备验证所述第一PDU会话标识对应的第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数是否一致以及验证所述第一PDU会话中是否有所述目标应用的数据包。
S413，所述第二网络侧设备获取所述第一PDU会话标识指示的第一PDU会话的第一参数。
所述第二网络侧设备根据所述第三请求信息中所述第一PDU会话标识，获取第一PDU会话标识对应的第一PDU会话的第一参数。
S415，所述第二网络侧设备通过验证所述第一参数与所述第一URSP规 则中的RSD描述的第二参数是否一致，得到所述第二验证结果。即由第二网络侧设备进行第二验证。
其中，在所述第一参数中的任一项参数与所述第二参数中的对应参数的参数值不一致的情况下，第二网络侧设备确定所述第一参数与所述第二参数不一致，而在所述第一参数中的各项参数与所述第二参数中的对应参数的参数值均一致的情况下，第二网络侧设备确定所述第一参数与所述第二参数一致。
S417，所述第二网络侧设备根据第三请求信息中的所述第一URSP规则，生成包检测规则，将所述包检测规则应用于所述第一PDU会话标识所指示的第一PDU会话，获取第三验证结果，其中，所述包检测规则用于验证所述第一PDU会话中是否包括所述目标应用的数据包，将第三响应信息(包括第二验证结果和第三验证结果)发送给第一网络侧设备。
或者，第二网络侧设备也可以向第一网络侧设备分别发送包括第二验证结果的第二响应信息和包括第三验证结果的第三响应信息，例如，在S415之后，发送该第二响应消息，在S417发送包括第三验证结果的第三响应信息。
其中，S413和S417之间可以没有先后顺序的限制，例如，可以同时进行，或者，也可以先执行S413和S415，在确定所述第一参数与所述第二参数一致的情况下，再执行S417，从而节约不必要的流程。
在本申请实施例中，在由第二网络侧设备验证所述第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数是否一致的情况下，第一网络侧设备也可以分别请求获取所述第二验证结果和所述第三验证结果。因此，在一个可能的实现方式中，如图5所示，该URSP规则的验证方法可以包括以下步骤。
S511，所述第二网络侧设备接收所述第一网络侧设备发送的第四请求信息，其中，所述第四请求信息包括所述第一URSP规则以及所述第一PDU会话标识，用于请求所述第二网络侧设备对所述第一PDU会话标识所指示的第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数进行验证。
S513，所述第二网络侧设备获取所述第一PDU会话标识所指示的第一PDU会话的第一参数。
S515，所述第二网络侧设备通过验证获取的所述第一参数与所述第一URSP规则中的RSD描述的第二参数是否一致，得到所述第二验证结果。
S517，所述第二网络侧设备接收所述第一网络侧设备发送的第五请求信息，其中，所述第五请求信息包括所述第一URSP规则以及所述第一PDU会话标识，用于请求所述第二网络侧设备对所述第一PDU会话标识所指示的第 一PDU会话中是否包括所述目标应用的数据包进行验证。
在一个可能的实现方式中，第一网络侧设备可以在接收第四响应信息之后，发送所述第五请求信息，例如，第一网络侧设备可以在第四响应信息中第二验证结果指示所述第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数一致的情况下，发送所述第五请求信息。
S519，所述第二网络侧设备根据第五请求信息中的所述第一URSP规则，生成包检测规则，将所述包检测规则应用于所述第一PDU会话标识所指示的第一PDU会话，获取第三验证结果，其中，所述包检测规则用于验证所述第一PDU会话中是否包括所述目标应用的数据包，并将所述第三验证结果包含在第五响应信息中返回给第一网络侧设备。
在一个可能的实现方式中，该方法还可以包括：
步骤1，所述第二网络侧设备接收所述第一网络侧设备发送的第一指示信息，其中，所述第一指示信息用于指示所述终端未正确使用URSP规则；
步骤2，所述第二网络侧设备拒绝所述第一PDU会话标识对应的会话建立请求或修改请求，或者，所述第二网络侧设备释放所述第一PDU会话标识对应的第一PDU会话；其中，拒绝所述会话建立请求或修改请求，是指拒绝上报第一URSP规则的终端的PDU会话建立请求或修改请求。或者，由于终端误用了URSP规则，则承载这个应用的PDU会话将被释放，或者，在释放这个PDU会话之前，网络侧根据第一URSP规则里的RSD指示的PDU会话参数，触发建立新的PDU会话，迁移所述应用流量在新的PDU会话上承载，然后再释放原有会话。
其中，所述终端未正确使用URSP规则包括以下之一：
(1)所述第一URSP规则与第二URSP规则不一致，所述第二URSP规则为所述第一网络侧设备发送给所述终端的与所述目标应用对应的至少一个URSP规则；例如，第一网络侧设备可以通过上述S210和S212获取第一验证结果，在第一验证结果指示所述第一URSP规则与第二URSP规则不一致的情况下，向第二网络侧设备发送所述第一指示信息。
(2)所述第一参数中至少一项参数与所述第二参数不一致。例如，第一网络侧设备可以验证从第二网络侧设备获取的第一PDU会话的第一参数中的至少一项参数与第一URSP规则中的RSD描述的第二参数不一致的情况下，向所述第二网络侧设备发送所述第一指示信息。或者，第一网络侧设备接收第二网络侧设备发送的第二验证结果，在第二验证结果指示所述第一参数中的至少一项参数与第二参数不一致的情况下，向第二网络侧设备发送所述第一指示信息。
(3)所述第一PDU会话中未包括所述目标应用的数据包。例如，第一 网络侧设备接收第二网络侧设备发送的第三验证结果，在第三验证结果指示所述第一PDU会话中未包括所述目标应用的数据包的情况下，向第二网络侧设备发送所述第一指示信息。
在上述可能的实现方式中，第二网络侧设备在接收到上述第一指示信息之后，拒绝所述第一PDU会话标识对应的会话建立请求或修改请求，或者，所述第二网络侧设备释放所述第一PDU会话标识对应的第一PDU会话。例如，在未建立第一PDU会话标识对应的第一PDU会话的情况下，在接收到所述第一指示信息之后，拒绝请求建立所述第一PDU会话的会话建立请求。或者，在已建立第一PDU会话标识对应的第一PDU会话的情况下，在接收到所述第一指示信息之后，释放所述第一PDU会话标识对应的第一PDU会话。从而可以避免终端使用不遵守URSP规则指示的PDU会话传输数据流。其中，拒绝会话建立请求或修改请求，是指拒绝上报第一URSP规则的终端的PDU会话建立请求或修改请求。或者，由于终端误用了URSP规则，那么，承载这个应用的PDU会话将被释放，或者，在释放这个PDU会话之前，网络侧根据第一URSP规则里的RSD指示的PDU会话参数，触发建立新的PDU会话，迁移所述应用流量在新的PDU会话上承载，然后再释放原有会话。
比如，当第二网络侧设备(SMF)收到第一指示以后，所述终端未正确使用URSP规则，则第二网络侧设备执行以下至少一项：
(4)发送PDU会话建立拒绝(PDU session establishment reject)到终端(可以经AMF转发至终端)；
(5)发送PDU会话修改拒绝(PDU session modification reject)到终端(可以经AMF转发至终端)；
(6)第二网络设备触发PDU会话释放(PDU session release)过程，释放所述第一PDU会话标识对应的第一PDU会话；
(7)第二网络设备，触发PDU会话修改指令(PDU session modification command)到终端(可以经AMF转发至终端)；然后，所述终端触发一个PDU会话建立请求(PDU session establishment request)到第二网络设备(所述会话建立请求可以经AMF转发)。本方法对应在本申请实施例中，由于第一URSP规则未被正确使用，第二网络设备请求终端修改会话，终端接受请求后，建立新的PDU会话，然后将所述第一PDU会话中承载的业务，切换至新建的PDU会话上。最后，终端或第二网络设备再释放第一PDU会话。
在本申请实施例中，第一网络侧设备与第二网络侧设备之间可以直接进行信息传输，例如，第一网络侧设备可以先获知第二网络侧设备的标识，例如，通过统一数据管理实体(Unified Data Management，UDM)获取终端对 应的第二网络侧设备(例如，移动性管理网元)的标识。或者，第一网络侧设备与第二网络侧设备之间也可以通过第三网络侧设备进行信息传输，例如，第一网络侧设备与第二网络侧设备之间通过会话管理策略控制网元(例如，会话管理策略控制功能(Session Management Policy Control Function，SM-PCF)进行信息传输，或者，所述第一网络侧设备与所述第二网络侧设备之间通过接入和移动管理网元(例如，接入和移动管理功能(Access and Mobility Management Function，AMF)进行信息传输。
图7示出本申请实施例提供的URSP规则的验证方法的又一流程示意图，该方法700可以由上述第三网络侧设备执行，换而言之，该方法700可以由安装在第三网络侧设备上的软件或硬件来执行。在本申请实施例中，第三网络侧设备可以为会话管理策略控制网元，例如，SM-PCF，或者，第三网络侧设备可以为接入和移动管理网元，例如，AMF。如图7所示，该方法可以包括以下步骤。
S710，第三网络侧设备接收所述第一网络侧设备发送的请求信息，其中，所述请求信息包括：第一PDU会话标识和/或第一URSP规则，所述第一PDU会话标识用于指示承载终端的目标应用的第一PDU会话，所述第一URSP规则为所述终端针对所述目标应用使用的URSP规则。
其中，所述请求信息用于以下至少之一：
(1)请求获取所述第一PDU会话的第一参数；例如，上述包括所述第一PDU标识的第一请求信息。
(2)请求验证所述第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数是否一致；例如，上述包括所述第一PDU标识和所述第一URSP规则的第一请求信息或第三请求信息。
(3)请求根据所述第一URSP规则对所述第一PDU会话中是否包括所述目标应用的数据包。例如，上述包括所述第一PDU标识和所述第一URSP规则的第五请求信息。
其中，所述请求信息可以包括上述方法200至600中的第一请求信息、第二请求信息、第三请求信息、第四请求信息和第五请求信息中的至少之一。
其中，第一网络侧设备可以通过与第三网络侧设备之间交互的信令，发送所述请求信息。例如，所述AM-PCF与AMF的交互信令包括：AM-PCF通过Namf_Communication N1MessageNotify_Subscribe，发送所述请求信息；或者，AM-PCF通过以下至少一项发送请求信息Npcf_UEPolicyControl_Update response或Npcf_UEPolicyControl_UpdateNotify notify；也可以是AM-PCF与AMF之间定义的其他信令。
S712，所述第三网络侧设备将所述请求信息发送给第二网络侧设备。
其中，第三网络侧设备可以将所述请求信息携带在信令中发送给第二网络侧设备。
在一个可能的实现方式中，在所述第三网络侧设备将所述请求信息发送给第二网络侧设备之后，所述方法还可以包括以下步骤：
步骤1，所述第三网络侧设备获取所述第二网络侧设备返回的响应信息。
可选地，所述响应信息可以包括以下之一：
(1)所述第一PDU会话的第一参数以及第三验证结果，其中，所述第三验证结果用于指示所述第一PDU会话中是否包括所述目标应用的数据包；
(2)第二验证结果和所述第三验证结果，其中，所述第二验证结果指示所述第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数是否一致。
在本申请实施例中，所述响应信息可以包括上述的第一响应信息、第二响应信息、第三响应信息、第四响应信息以及第五响应信息中的任意之一。
步骤2，所述第三网络侧设备将所述响应信息发送给所述第一网络侧设备。
在本申请实施例中，第三网络侧设备除了传输第一网络侧设备与第二网络侧设备之间传输的上述请求信息和响应信息之外，还可以传输第一网络侧设备与第二网络侧设备之间的其它信息，例如，上述的第一指示信息，具体本申请实施例中不再赘述。
例如，AMF可以通过以下信令，将上述响应信息发送给AM-PCF：Namf_Communication N1MessageNotify Notify；或者，也可以使用以下信令发送所述响应信息：Npcf_UEPolicyControl_Update request；Npcf_UEPolicyControl_UpdateNotify subscribe。也可以是AMF与AM-PCF之间定义的其他信令。
下面以第一网络侧设备为AM-PCF，第二网络侧设备为SMF为例，对本申请实施例提供的URSP规则的验证方法进行说明。
图8示出了本申请实施例的URSP规则的验证方法的又一种流程示意图，如图8所示，该方法800主要包括以下步骤。
S801：AM-PCF接收到终端上报的针对某一APP所使用的URSP规则以后，进行第一次验证，验证终端上报的所使用的规则与AM-PCF发给UE的URSP规则是否一致，当一致的情况下，第一次验证通过，AM-PCF发送终端所使用的URSP规则(主要是发送URSP规则里的RSD的参数)以及承载所述APP流量的PDU会话ID至SMF。
其中，如果AM-PCF验证终端上报的所使用的规则与AM-PCF发给UE的URSP规则不一致，则执行S807。
S802，SMF根据PDU会话ID，得到该PDU会话的参数，将该PDU会 话的参数发送给AM-PCF。其中，该PDU会话的参数可以包括：SSC mode、Access type、PDU session类型，DNN、S-NSSAI等中的至少一项。
S803，AM-PCF比较终端所使用的URSP规则里的RSD描述的PDU会话参数与SMF上报的PDU会话的参数。
如果不相同，则二次验证失败，执行S807；如果相同，则验证通过，执行S804，进行包检测，即进行第三次验证。
S804，AM-PCF指示SMF进行包检测。
S805，SMF根据AM-PCF发送的终端使用的URSP规则中的RSD及TD，生成包检测规则(PDR)，在PDU会话ID对应的PDU会话里进行包检测，将检测包结果发送给AM-PCF。
S806，如果检测包结果指示SMF检测出所述APP的数据包，则说明URSP规则使用正确，流程结束；如果检测包结果指示SMF未检测出所述APP的数据包，则说明所述APP的流量并未出现在所述PDU session中，说明终端未正确使用URSP规则，则执行S807。
S807，AM-PCF可以对UE policy进行优化，比如重执行UE policy给UE发下去。
S808，AM-PCF指示SMF，UE未正确使用URSP规则。
S809，SMF得到UE未正确使用URSP规则的指示后，SMF可以执行以下三个操作：
操作1：SMF拒绝所述PDU session ID对应的会话建立请求。
操作2：SMF释放所述PDU session ID对应的PDU会话。
操作3：SMF先建立新的PDU会话，然后将所述APP流量迁移至该新建PDU会话，然后释放旧的所述PDU session ID对应的PDU会话。
图9示出了本申请实施例的URSP规则的验证方法的又一种流程示意图，如图9所示，该方法900主要包括以下步骤。
S901：AM-PCF接收到终端上报的针对某一APP所使用的URSP规则以后，进行第一次验证，验证终端上报的所使用的规则与AM-PCF发给UE的URSP规则是否一致，当一致的情况下，第一次验证通过，AM-PCF发送终端所使用的URSP规则(主要是发送URSP规则里的RSD的参数)以及承载所述APP流量的PDU会话ID至AMF。
其中，如果AM-PCF验证终端上报的所使用的规则与AM-PCF发给UE的URSP规则不一致，则执行S908。
S902，AMF将所述终端所使用的URSP规则以及承载所述APP流量的PDU会话ID发送至SMF。所述AMF跟SMF之间的交互信令可以是以下至少一项或者其他信令：
Nsmf_EventExposure Subscribe；Nsmf_PDUSession_UpdateSMContext。
S903，SMF根据PDU会话ID，得到该PDU会话的参数，将该PDU会话的参数发送给AMF。其中，该PDU会话的参数可以包括：SSC mode、Access type、PDU session类型，DNN、S-NSSAI等中的至少一项。所述SMF跟AMF之间的交互信令可以包括以下至少一项：
Namf_Communication N1N2MessageTransfer Response；或者其他消息。
S904，AMF将该PDU会话的参数发送给AM-PCF。
S905，SMF根据终端使用的URSP规则中的RSD及TD，生成包检测规则(PDR)，在PDU会话ID对应的PDU会话里进行包检测，将检测包结果发送给AMF。
S906，AMF将检测包结果发送给AM-PCF。
S907，AM-PCF比较终端所使用的URSP规则里的RSD描述的PDU会话参数与SMF上报的PDU会话的参数，进行二次验证，并根据检测包结果获取三次验证的结果。
如果RSD描述的PDU会话参数与SMF上报的PDU会话的参数不相同，则二次验证失败，执行S908；如果相同，则二次验证通过，如果三次验证的结果(即检测包结果)指示SMF检测出所述APP的数据包，则说明URSP规则使用正确，流程结束；如果检测包结果指示SMF未检测出所述APP的数据包，则说明所述APP的流量并未出现在所述PDU session中，说明终端未正确使用URSP规则，则执行S908。
S908，AM-PCF可以对UE policy进行优化，比如重执行UE policy给UE发下去。
S909，AM-PCF向AMF发送URSP规则使用的验证结果，该验证结果指示UE未正确使用URSP规则。
S910，AMF将URSP规则使用的验证结果发送给SMF。
S911，SMF得到UE未正确使用URSP规则的验证结果后，SMF可以执行以下三个操作：
操作1：SMF拒绝所述PDU session ID对应的会话建立请求。
操作2：SMF释放所述PDU session ID对应的PDU会话。
操作3：SMF先建立新的PDU会话，然后将所述APP流量迁移至该新建PDU会话，然后释放旧的所述PDU session ID对应的PDU会话。
图10示出了本申请实施例的URSP规则的验证方法的又一种流程示意图，如图10所示，该方法1000主要包括以下步骤。
S1001：AM-PCF接收到终端上报的针对某一APP所使用的URSP规则以后，进行第一次验证，验证终端上报的所使用的规则与AM-PCF发给UE 的URSP规则是否一致，当一致的情况下，第一次验证通过，AM-PCF发送终端所使用的URSP规则(主要是发送URSP规则里的RSD的参数)以及承载所述APP流量的PDU会话ID至SM-PCF。
所述AM-PCF和SM-PCF的交互信令包括以下至少一项：
(1)Npcf_PolicyAuthorization_Subscribe，即订阅消息，该订阅用于订阅发送的第一URSP规则的使用情况，比如，使用第一URSP规则生成PDR以后，在所述PDU会话中进行包检测的结果。
(2)Npcf_EventExposure_Subscribe。
其中，如果AM-PCF验证终端上报的所使用的规则与AM-PCF发给UE的URSP规则不一致，则执行S1008。
S1002，SM-PCF将所述终端所使用的URSP规则以及承载所述APP流量的PDU会话ID发送至SMF。所述发送方式，通过以下至少一项信令：Npcf_SMPolicyControl_UpdateNotify；Npcf_SMPolicyControl_Update request。
S1003，SMF根据PDU会话ID，得到该PDU会话的参数，将该PDU会话的参数发送给SM-PCF。其中，该PDU会话的参数可以包括：SSC mode、Access type、PDU session类型，DNN、S-NSSAI等中的至少一项。
S1004，SM-PCF将该PDU会话的参数发送给AM-PCF。发送使用的信令可以为以下之一：Npcf_SMPolicyControl UpdateNotify Notify；Npcf_SMPolicyControl_Update request。
S1005，SMF根据终端使用的URSP规则中的RSD及TD，生成包检测规则(PDR)，在PDU会话ID对应的PDU会话里进行包检测，将检测包结果发送给SM-PCF。
S1006，SM-PCF将检测包结果发送给AM-PCF。所述发送使用信令可以为以下之一：Npcf_Policy_Authorization Notify；Npcf_EventExposure_Notify。
S1007，AM-PCF比较终端所使用的URSP规则里的RSD描述的PDU会话参数与SMF上报的PDU会话的参数，进行二次验证，并根据检测包结果获取三次验证的结果。
如果RSD描述的PDU会话参数与SMF上报的PDU会话的参数不相同，则二次验证失败，执行S1008；如果相同，则二次验证通过，如果三次验证的结果(即检测包结果)指示SMF检测出所述APP的数据包，则说明URSP规则使用正确，流程结束；如果检测包结果指示SMF未检测出所述APP的数据包，则说明所述APP的流量并未出现在所述PDU session中，说明终端未正确使用URSP规则，则执行S1008。
S1008，AM-PCF可以对UE policy进行优化，比如重执行UE policy给 UE发下去。
S1009，AM-PCF向AMF发送URSP规则使用的验证结果，该验证结果指示UE未正确使用URSP规则。
S1010，AMF将URSP规则使用的验证结果发送给SMF。
S1011，SMF得到UE未正确使用URSP规则的验证结果后，SMF可以执行以下三个操作：
操作1：SMF拒绝所述PDU session ID对应的会话建立请求；
操作2：SMF释放所述PDU session ID对应的PDU会话；
操作3：SMF先建立新的PDU会话，然后将所述APP流量迁移至该新建PDU会话，然后释放旧的所述PDU session ID对应的PDU会话。
图11示出了本申请实施例的URSP规则的验证方法的又一种流程示意图，如图11所示，该方法1100主要包括以下步骤。
S1101，终端使用URSP规则，匹配APP的流量到PDU会话，或使用匹配到的URSP规则中的RSD建立新的PDU会话。
S1102，终端通过NAS消息，向AMF发送所使用的URSP规则以及RSD、PDU会话标识。
S1103，AMF通过UE策略控制更新请求(Npcf_UEPolicyConrol_Update Request)，将所述URSP规则以及RSD、PDU会话标识发送给AM-PCF。
S1104，AM-PCF向AMF返回UE策略控制更新响应(Npcf_UEPolicyConrol_Update response)。
S1105，AM-PCF进行第一次验证，即验证终端上报的URSP规则与AM-PCF发送给终端的URSP规则是否一致，如果一致，则继续执行S1106，否则，执行S1118。
S1106，AM-PCF向UDM发送Nudm_SDM_Get或者Nudm_SDM_Subscibe，其中携带有终端的签约永久标识(Subscription Permanent Identifier，SUPI)、sub key以及S-NSSAI。
S1107，UDM向AM-PCF返回Nudm_SDM_Get响应或者Nudm_SDM_Subscibe响应，该响应中可以携带PDU会话标识、SMF ID、SM-PCF ID。
S1108，AM-PCF向SMF ID对应的SMF发送需要监控使用的URSP规则(即终端使用的URSP规则)，包括终端的SUPI、PDU会话ID、URSP规则中的RSD和TD。
S1109，SMF获取PDU会话ID对应的PDU会话的各项参数，例如，SSC模式等。
S1110，SMF将获取的PDU会话的各项参数发送至AM-PCF，以使得AM-PCF进行二次验证，即AM-PCF验证SMF发送的PDU会话的各项参数与 终端使用的URSP规则的RSD中描述的各项参数是否一致。
S1111，SMF将TD转换成必须的包检测规则(例如，将FQDN、应用描述符等转换成目的IP三元组用于检包)，该包检测规则在PDU会话标识对应的PDU会话中进行检测。
S1112，SMF确定服务所述终端的与所述PDU会话标识对应的UPF。
S1113，SMF将包检测规则发送给UPF。SMF还可以指示UPF在规定的时间内进行包检测。
S1114，UPF应用所述包检测规则进行包检测，检测所述PDU会话中是否有所述APP的流量包。此时，UPF在SMF所指示的规定时间内进行包检测。
S1115，UPF向SMF发送检测报告，反馈检测结果。即，是否在规定时间里检测出了目标数据包。检测结果包括：检测出或者未检测出。
S1116，在预定时间内，结束包检测，SMF向AM-PCF发送包检测结果。
S1117，AM-PCF进行第二次验证，验证SMF发送的PDU会话的各项参数与终端使用的URSP规则的RSD中描述的各项参数是否一致，在SMF发送的PDU会话的任意一项参数与终端使用的URSP规则的RSD中描述对应项参数不一致的情况下，执行S1118，在SMF发送的PDU会话的任意一项参数与终端使用的URSP规则的RSD中描述对应项参数一致的情况下，如果包检测结果指示所述PDU会话中有所述APP的流量包，则结束流程，如果包检测结果指示所述PDU会话中没有所述APP的流量包，则执行S1118。
S1118，AMF-PCF根据终端上报的URSP规则，对终端内的URSP规则进行调整。
S1119，AMF将URSP规则使用的验证结果发送给SMF，如果URSP规则使用不正确，则请求SMF拒绝所述PDU会话的建立请求或释放所述PDU会话或修改所述PDU会话的参数。
图12示出了本申请实施例的URSP规则的验证方法的又一种流程示意图，如图12所示，该方法1200主要包括以下步骤。
S1201，终端使用URSP规则，匹配APP的流量到PDU会话，或使用匹配到的URSP规则中的RSD建立新的PDU会话。
S1202，终端通过非接入层(Non-Access Stratum，NAS)消息，向AMF发送所使用的URSP规则以及RSD、PDU会话标识。
S1203，AMF通过UE策略控制更新请求(Npcf_UEPolicyConrol_Update request)，将所述URSP规则以及RSD、PDU会话标识发送给AM-PCF。
S1204，AM-PCF向AMF返回UE策略控制更新响应(Npcf_UEPolicyConrol_Update response)。
S1205，AM-PCF进行第一次验证，即验证终端上报的URSP规则与AM-PCF发送给终端的URSP规则是否一致，如果一致，则继续执行S1206，否则，执行S1221。
S1206，AM-PCF向UDM发送Nudm_SDM_Get或者Nudm_SDM_Subscibe，其中携带有终端的签约永久标识(Subscription Permanent Identifier，SUPI)、sub key以及S-NSSAI。
S1207，UDM向AM-PCF返回Nudm_SDM_Get响应或者Nudm_SDM_Subscibe响应，该响应中可以携带PDU会话标识、SMF ID、SM-PCF ID。
S1208，AM-PCF向AMF发送需要监控使用的URSP规则(即终端使用的URSP规则)，包括终端的SUPI、PDU会话ID、URSP规则中的RSD和TD。
S1209，AMF将需要监控使用的URSP规则发送给SMF。由于，所述AMF中保存了每个终端对应的SMF，因此，AMF可以直接找到SMF的IP地址；也可以，AM-PCF在发送待监控的URSP规则的时候，指示给SMF。
S1210，SMF获取PDU会话ID对应的PDU会话的各项参数，例如，SSC模式等。
S1211，SMF将获取的PDU会话的各项参数发送至AMF。
S1212，AMF将PDU会话的各项参数AM-PCF，以使得AM-PCF进行二次验证，即AM-PCF验证SMF发送的PDU会话的各项参数与终端使用的URSP规则的RSD中描述的各项参数是否一致。在此步骤以后，AM-PCF也可以指示SMF(通过AMF)，第二验证的结果。如果第二验证没有通过，则步骤S1213之后的过程到S1219将不再执行。
S1213，SMF将TD转换成必须的包检测规则(例如，将FQDN、应用描述符等转换成目的IP三元组用于检包)，该包检测规则在PDU会话标识对应的PDU会话中进行检测。
S1214，SMF确定服务所述终端的与所述PDU会话标识对应的UPF。
S1215，SMF将包检测规则发送给UPF。SMF还可以指示UPF在规定的时间内，进行包检测。
S1216，UPF应用所述包检测规则进行包检测，检测所述PDU会话中是否有所述APP的流量包。此时，UPF在SMF所指示的规定时间内进行包检测。
S1217，UPF向SMF发送检测报告，反馈检测结果。即，是否在规定时间里检测出了目标数据包。检测结果包括：检测出或者未检测出。
S1218，在预定时间内，结束包检测，SMF向AMF发送包检测结果。
S1219，AMF将在预定时间内的包检测结果发送给AM-PCF。
S1220，AM-PCF进行第二次验证，验证SMF发送的PDU会话的各项参数与终端使用的URSP规则的RSD中描述的各项参数是否一致，在SMF发送的PDU会话的任意一项参数与终端使用的URSP规则的RSD中描述对应项参数不一致的情况下，执行S1218，在SMF发送的PDU会话的任意一项参数与终端使用的URSP规则的RSD中描述对应项参数一致的情况下，如果包检测结果指示所述PDU会话中有所述APP的流量包，则结束流程，如果包检测结果指示所述PDU会话中没有所述APP的流量包，则执行S1221。
S1221，AMF-PCF根据终端上报的URSP规则，对终端内的URSP规则进行调整。
S1222，AMF将URSP规则使用的验证结果发送给SMF，如果URSP规则使用不正确，则请求SMF拒绝所述PDU会话的建立请求或释放所述PDU会话或修改所述PDU会话的参数。
图13示出了本申请实施例的URSP规则的验证方法的又一种流程示意图，如图13所示，该方法1300主要包括以下步骤。
S1301，终端使用URSP规则，匹配APP的流量到PDU会话，或使用匹配到的URSP规则中的RSD建立新的PDU会话。
S1302，终端通过NAS消息，向AMF发送所使用的URSP规则以及RSD、PDU会话标识。
S1303，AMF通过UE策略控制更新请求(Npcf_UEPolicyConrol_Update request)，将所述URSP规则以及RSD、PDU会话标识发送给AM-PCF。
S1304，AM-PCF向AMF返回UE策略控制更新响应(Npcf_UEPolicyConrol_Update response)。
S1305，AM-PCF进行第一次验证，即验证终端上报的URSP规则与AM-PCF发送给终端的URSP规则是否一致，如果一致，则继续执行S1306，否则，执行S1321。
S1306，AM-PCF向UDM发送Nudm_SDM_Get或者Nudm_SDM_Subscibe，其中携带有终端的签约永久标识(Subscription Permanent Identifier，SUPI)、sub key以及S-NSSAI。
S1307，UDM向AM-PCF返回Nudm_SDM_Get响应或者Nudm_SDM_Subscibe响应，该响应中可以携带PDU会话标识、SMF ID、SM-PCF ID。
S1308，AM-PCF向SM-PCF发送需要监控使用的URSP规则(即终端使用的URSP规则)，包括终端的SUPI、PDU会话ID、URSP规则中的RSD和TD。
S1309，SM-PCF将需要监控使用的URSP规则发送给SMF。
S1310，SMF获取PDU会话ID对应的PDU会话的各项参数，例如，S SC模式等。
S1311，SMF将获取的PDU会话的各项参数发送至SM-PCF。
S1312，SM-PCF将PDU会话的各项参数AM-PCF，以使得AM-PCF进行二次验证，即AM-PCF验证SMF发送的PDU会话的各项参数与终端使用的URSP规则的RSD中描述的各项参数是否一致。
S1313，SMF将TD转换成必须的包检测规则(例如，将FQDN、应用描述符等转换成目的IP三元组用于检包)，该包检测规则在PDU会话标识对应的PDU会话中进行检测。
S1314，SMF确定服务所述终端的与所述PDU会话标识对应的UPF。
S1315，SMF将包检测规则发送给UPF。SMF还可以指示UPF在规定的时间内，进行包检测。
S1316，UPF应用所述包检测规则进行包检测，检测所述PDU会话中是否有所述APP的流量包。此时，UPF可以在SMF所指示的规定时间内进行包检测。
S1317，UPF向SMF发送检测报告，反馈检测结果。即，是否在规定时间里检测出了目标数据包。检测结果包括：检测出或者未检测出。
S1318，在预定时间内，结束包检测，SMF向SM-PCF发送包检测结果。
S1319，SM-PCF将在预定时间内的包检测结果发送给AM-PCF。
S1320，AM-PCF进行第二次验证，验证SMF发送的PDU会话的各项参数与终端使用的URSP规则的RSD中描述的各项参数是否一致，在SMF发送的PDU会话的任意一项参数与终端使用的URSP规则的RSD中描述对应项参数不一致的情况下，执行S1318，在SMF发送的PDU会话的任意一项参数与终端使用的URSP规则的RSD中描述对应项参数一致的情况下，如果包检测结果指示所述PDU会话中有所述APP的流量包，则结束流程，如果包检测结果指示所述PDU会话中没有所述APP的流量包，则执行S1321。
S1321，AMF-PCF根据终端上报的URSP规则，对终端内的URSP规则进行调整。
S1322，AMF将URSP规则使用的验证结果发送给SMF，如果URSP规则使用不正确，则请求SMF拒绝所述PDU会话的建立请求或释放所述PDU会话或修改所述PDU会话的参数。
图14示出了本申请实施例的URSP规则的验证方法的又一种流程示意图，如图14所示，该方法1400主要包括以下步骤。
S1401：终端上报所使用的URSP规则给AM-PCF以后，AM-PCF先进行第一次验证，验证终端上报的所使用的规则与实际AM-PCF发给UE的URSP规则是否一致，当一致的时候，第一次验证通过，AM-PCF发送终端所 使用的URSP规则(主要是发送URSP规则里的RSD的参数)以及承载所述APP流量的PDU会话的ID至SMF。
此时，AM-PCF还可以给一个指示信息：指示所述SMF，是只进行二次验证，还是说需要进一步执行包检测三次验证。比如说，所述AM-PCF可以指示SMF，使用第一URSP规则RSD里的参数，与所述第一PDU会话的会话参数进行比较，执行二次验证，然后反馈结果；或者，AM-PCF还可以指示，完成第二验证以后，不管结果如何，都执行第三验证；或者AM-PCF直接指示SM-PCF同时完成第二验证或第三验证。
S1402：SMF根据PDU session ID，得到该PDU会话的参数，包括：SSC mode，Access type，PDU session类型，DNN，S-NSSAI等等；然后SMF进行比较，比较这些PDU会话参数和AM-PCF发送的终端所使用的URSP rules里的RSD包含的参数。如果参数不一致，则说明终端没有正确使用URSP规则，则二次验证失败，则执行S1403，跳过S1404和S1405；如果参数一致，则说明终端正确使用了URSP规则，执行S1404和S1405进行包检测，之后的步骤待定。
S1403：SMF发送验证结果，验证失败，指示所述终端使用的URSP规则中RSD指示的PDU会话参数，跟实际承载这个APP流量的PDU会话的参数不符，然后执行S1406-S1408，跳过S1404和S1405。
S1404：SMF根据AM-PCF发送的终端使用的URSP规则中的RSD和TD，生成包检测规则，在PDU session里进行包检测，并发送检测结果。
S1405：如果SMF检测出所述包，则说明URSP规则使用正确，结束流程，如果SMF未检测出所述包，则说明所述APP的流量并未出现在所述PDU session中，则说明终端未正确使用URSP规则，执行S1406。
S1406：AM-PCF对UE policy进行优化，比如重执行UE policy给UE发下去。
S1407：AM-PCF指示SMF，UE未正确使用URSP规则，然后SMF将执行S1408。
S1408：当SMF得到UE未正确使用URSP规则的指示后，SMF可以执行以下三个操作之一：
操作1：SMF拒绝所述PDU session ID对应的会话建立请求；
操作2：SMF释放所述PDU session ID对应的PDU会话；
操作3：SMF先建立新的PDU会话，然后将所述APP流量迁移至该新建PDU会话，然后释放旧的所述PDU session ID对应的PDU会话。
本申请实施例提供的URSP规则的验证方法，执行主体可以为URSP规则的验证装置。本申请实施例中以URSP规则的验证装置执行URSP规则的 验证方法为例，说明本申请实施例提供的URSP规则的验证装置。
图15示出本申请实施例提供的URSP规则的验证装置的一种结构示意图，如图15所示，该装置1500主要包括：第一接收模块1501、第一获取模块1502和第二获取模块1503。
在本申请实施例中，第一接收模块1501，用于接收终端发送的上报信息，其中，所述上报信息包括所述终端针对目标应用使用的第一URSP规则以及第一PDU会话标识，所述第一PDU会话标识用于指示承载所述目标应用的第一PDU会话；第一获取模块1502，用于通过验证所述第一URSP规则与第二URSP规则是否一致，获取第一验证结果，其中，所述第二URSP规则为所述第一网络侧设备发送给所述终端的与所述目标应用对应的至少一个URSP规则；第二获取模块1503，用于获取第二验证结果，其中，所述第二验证结果指示所述第一PDU会话的第一参数与所述第一URSP规则中的路由选择描述符RSD描述的第二参数是否一致；通过所述第二网络侧设备获取第三验证结果，其中，所述第三验证结果指示所述第一PDU会话中是否包括所述目标应用的数据包。
在一个可能的实现方式中，所述第二获取模块1503通过第二网络侧设备，获取第二验证结果，包括：
从所述第二网络侧设备获取所述第一PDU会话的第一参数；
通过验证所述第一参数与所述第一URSP规则中的路由选择描述符RSD描述的第二参数是否一致，获取所述第二验证结果。
在一个可能的实现方式中，所述第二获取模块1503通过第二网络侧设备，获取第二验证结果和所述第三验证结果，包括：
向所述第二网络侧设备发送第三请求信息，其中，所述第三请求信息包括所述第一URSP规则以及所述第一PDU会话标识；
获取所述第二网络侧设备发送的第三响应信息，其中，所述第三响应信息包括所述第二网络侧设备对所述第一参数与所述第二参数进行验证得到的所述第二验证结果，以及所述第二网络侧设备对所述第一PDU会话中是否包括所述目标应用的数据包进行验证得到的所述第三验证结果。
在一个可能的实现方式中，所述第二获取模块1503通过第二网络侧设备，获取第二验证结果和所述第三验证结果，包括：
向所述第二网络侧设备发送第四请求信息，其中，所述第四请求信息包括所述第一URSP规则以及所述第一PDU会话标识，用于请求所述第二网络侧设备对所述第一参数与所述第二参数进行验证；
获取所述第二网络侧设备发送的第四响应信息，其中，所述第四响应信息包括所述第二网络侧设备对所述第一参数与所述第二参数进行验证得到的 所述第二验证结果；
向所述第二网络侧设备发送第五请求信息，其中，所述第五请求信息包括所述第一URSP规则以及所述第一PDU会话标识，用于请求所述第二网络侧设备对所述第一PDU会话中是否包括所述目标应用的数据包进行验证；
获取所述第二网络侧设备发送的第五响应信息，其中，所述第五响应信息包括所述第二网络侧设备对所述第一PDU会话中是否包括所述目标应用的数据包进行验证得到的所述第三验证结果。
图16示出本申请实施例提供的URSP规则的验证装置的另一种结构示意图，如图16所示，该装置1600主要包括：确定模块1601和第三获取模块1602。
在本申请实施例中，确定模块1601，用于通过与第一网络侧设备交互，确定第二验证结果，其中，所述第二验证结果指示承载终端的目标应用的第一PDU会话的第一参数与所述终端针对目标应用使用的第一URSP规则中的RSD描述的第二参数是否一致；第三获取模块1602，用于通过验证所述第一PDU会话中是否包括所述目标应用的数据包，获取第三验证结果，其中，所述第三验证结果指示所述第一PDU会话中是否包括所述目标应用的数据包。
在一个可能的实现方式中，所述确定模块1601通过与第一网络侧设备交互，确定第二验证结果，包括：
获取所述第一网络侧设备发送的第一请求信息，其中，所述第一请求信息包括第一PDU会话标识，所述第一PDU会话标识用于指示第一PDU会话；
获取所述第一PDU会话的第一参数；
返回第一响应信息，其中，所述第一响应信息包括所述第一PDU会话的第一参数，指示所述第一网络侧设备验证所述第一参数与所述第二参数是否一致。
在一个可能的实现方式中，所述第三获取模块1602通过验证所述第一PDU会话中是否包括所述目标应用的数据包，获取第三验证结果，包括：
在接收到所述第一请求信息后，根据所述第一请求信息中的所述第一URSP规则，生成包检测规则，将所述包检测规则应用于所述第一PDU会话标识指示的第一PDU会话，获取第三验证结果，其中，所述包检测规则用于验证所述第一PDU会话中是否包括所述目标应用的数据包，所述第一请求信息中还包括所述第一URSP规则。
在一个可能的实现方式中，所述第三获取模块1602通过验证所述第一PDU会话中是否包括所述目标应用的数据包，获取第三验证结果，包括：
在接收到所述第一请求信息后或者在向所述第二网络侧设备返回第一响应信息之后，获取所述第一网络侧设备发送的第二请求信息，其中，所述第 二请求信息用于请求获取所述第三验证结果，所述第二请求信息中携带有所述第一PDU会话标识和所述第一URSP规则；
根据第二请求信息中的所述第一URSP规则，生成包检测规则，将所述包检测规则应用于所述第一PDU会话标识所指示的第一PDU会话，获取第三验证结果，其中，所述包检测规则用于验证所述第一PDU会话中是否包括所述目标应用的数据包。
在一个可能的实现方式中，所述确定模块1601确定所述第二验证结果包括：接收所述第一网络侧设备发送的第三请求信息，其中，所述第三请求信息包括所述第一URSP规则以及所述第一PDU会话标识；获取所述第一PDU会话标识指示的第一PDU会话的第一参数；通过验证所述第一参数与所述第一URSP规则中的路由选择描述符RSD描述的第二参数是否一致，得到所述第二验证结果；所述第三获取模块1602获取所述第三验证结果包括：根据第三请求信息中的所述第一URSP规则，生成包检测规则，将所述包检测规则应用于所述第一PDU会话标识所指示的第一PDU会话，获取第三验证结果，其中，所述包检测规则用于验证所述第一PDU会话中是否包括所述目标应用的数据包。
在一个可能的实现方式中，所述确定模块1601确定所述第二验证结果包括：接收所述第一网络侧设备发送的第四请求信息，其中，所述第四请求信息包括所述第一URSP规则以及所述第一PDU会话标识，用于请求对所述第一PDU会话标识所指示的第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数进行验证；获取所述第一PDU会话标识所指示的第一PDU会话的第一参数；通过验证获取的所述第一参数与所述第一URSP规则中的RSD描述的第二参数是否一致，得到所述第二验证结果；所述第三获取模块1602获取所述第三验证结果包括：接收所述第一网络侧设备发送的第五请求信息，其中，所述第五请求信息包括所述第一URSP规则以及所述第一PDU会话标识，用于请求对所述第一PDU会话标识所指示的第一PDU会话中是否包括所述目标应用的数据包进行验证；根据第五请求信息中的所述第一URSP规则，生成包检测规则，将所述包检测规则应用于所述第一PDU会话标识所指示的第一PDU会话，获取第三验证结果，其中，所述包检测规则用于验证所述第一PDU会话中是否包括所述目标应用的数据包。
图17示出本申请实施例提供的URSP规则的验证装置的又一种结构示意图，如图17所示，该装置1700主要包括：第二接收模块1701和发送模块1702。
在本申请实施例中，第二接收模块1701，用于接收所述第一网络侧设备发送的请求信息，其中，所述请求信息包括：第一PDU会话标识和/或第一 URSP规则，所述第一PDU会话标识用于指示承载终端的目标应用的第一PDU会话，所述第一URSP规则为所述终端针对所述目标应用使用的URSP规则；发送模块1702，用于将所述请求信息发送给第二网络侧设备；其中，所述请求信息用于以下至少之一：
请求获取所述第一PDU会话的第一参数；
请求验证所述第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数是否一致；
请求根据所述第一URSP规则对所述第一PDU会话中是否包括所述目标应用的数据包。
本申请实施例中的URSP规则的验证装置可以是电子设备，例如具有操作系统的电子设备，也可以是电子设备中的部件，例如集成电路或芯片。
本申请实施例提供的URSP规则的验证装置能够实现图2至图14的方法实施例实现的各个过程，并达到相同的技术效果，为避免重复，这里不再赘述。
可选的，如图18所示，本申请实施例还提供一种通信设备1800，包括处理器1801和存储器1802，存储器1802上存储有可在所述处理器1801上运行的程序或指令，例如，该通信设备1800为网络侧设备时，该程序或指令被处理器1801执行时实现上述URSP规则的验证方法实施例的各个步骤，且能达到相同的技术效果，为避免重复，这里不再赘述。
本申请实施例还提供一种网络侧设备，包括处理器和通信接口，处理器用于实现上述URSP规则的验证方法实施例的各个步骤，通信接口用于与外部设备进行通信。该网络侧设备实施例与上述网络侧设备方法实施例对应，上述方法实施例的各个实施过程和实现方式均可适用于该网络侧设备实施例中，且能达到相同的技术效果。
具体地，本申请实施例还提供了一种网络侧设备。如图19所示，该网络侧设备1900包括：处理器1901、网络接口1902和存储器1903。其中，网络接口1902例如为通用公共无线接口(common public radio interface，CPRI)。
具体地，本发明实施例的网络侧设备1900还包括：存储在存储器1903上并可在处理器1901上运行的指令或程序，处理器1901调用存储器1903中的指令或程序执行图15至图17所示各模块执行的方法，并达到相同的技术效果，为避免重复，故不在此赘述。
本申请实施例还提供一种可读存储介质，所述可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述URSP规则的验证方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
其中，所述处理器为上述实施例中所述的终端中的处理器。所述可读存 储介质，包括计算机可读存储介质，如计算机只读存储器ROM、随机存取存储器RAM、磁碟或者光盘等。
本申请实施例另提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现上述URSP规则的验证方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
应理解，本申请实施例提到的芯片还可以称为系统级芯片，系统芯片，芯片系统或片上系统芯片等。
本申请实施例另提供了一种计算机程序/程序产品，所述计算机程序/程序产品被存储在存储介质中，所述计算机程序/程序产品被至少一个处理器执行以实现上述URSP规则的验证方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
本申请实施例还提供了一种URSP规则的验证系统，包括：第一网络侧设备及第二网络侧设备，所述第一网络侧设备可用于执行如上所述的URSP规则的验证方法中第一网络侧设备执行的步骤，所述第二网络侧设备可用于执行如上所述的URSP规则的验证方法中第二网络侧设备执行的步骤。
可选地，所述URSP规则的验证系统还可以包括第三网络侧设备，所述第三网络侧设备可用于执行如上所述的URSP规则的验证方法中第三网络侧设备执行的步骤。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。此外，需要指出的是，本申请实施方式中的方法和装置的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁 碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。
上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (42)

  1. 一种用户设备路由选项策略URSP规则的验证方法，包括：
    第一网络侧设备接收终端发送的上报信息，其中，所述上报信息包括所述终端针对目标应用使用的第一URSP规则以及第一协议数据单元PDU会话标识，所述第一PDU会话标识用于指示承载所述目标应用的第一PDU会话；
    所述第一网络侧设备通过验证所述第一URSP规则与第二URSP规则是否一致，获取第一验证结果，其中，所述第二URSP规则为所述第一网络侧设备发送给所述终端的与所述目标应用对应的至少一个URSP规则；
    在所述第一验证结果指示所述第一URSP规则与所述第二URSP规则中至少一个规则一致的情况下，所述第一网络侧设备通过第二网络侧设备获取第二验证结果，其中，所述第二验证结果指示所述第一PDU会话的第一参数与所述第一URSP规则中的路由选择描述符RSD描述的第二参数是否一致；
    所述第一网络侧设备通过所述第二网络侧设备获取第三验证结果，其中，所述第三验证结果指示所述第一PDU会话中是否包括所述目标应用的数据包。
  2. 根据权利要求1所述的方法，其中，所述第一网络侧设备通过第二网络侧设备，获取第二验证结果，包括：
    所述第一网络侧设备从所述第二网络侧设备获取所述第一PDU会话的第一参数；
    所述第一网络侧设备通过验证所述第一参数与所述第一URSP规则中的路由选择描述符RSD描述的第二参数是否一致，获取所述第二验证结果。
  3. 根据权利要求2所述的方法，其中，所述第一网络侧设备从所述第二网络侧设备获取所述第一PDU会话的第一参数，包括：
    所述第一网络侧设备向所述第二网络侧设备发送第一请求信息，其中，所述第一请求信息包括所述第一PDU会话标识；
    所述第一网络侧设备接收所述第二网络侧设备发送的第一响应信息，其中，所述第一响应信息包括所述第一PDU会话的第一参数。
  4. 根据权利要求3所述的方法，其中，
    所述第一参数包括以下至少一项：PDU会话类型、PDU会话的接入类型、会话和服务连续性SSC模式、网络切片标识符、数据网络名称DNN；和/或，
    所述第二参数包括以下至少一项：PDU会话类型、PDU会话的接入类型、会话和服务连续性SSC模式、网络切片标识符、数据网络名称DNN。
  5. 根据权利要求3所述的方法，其中，所述第一网络侧设备从所述第二网络侧设备获取第三验证结果，包括以下之一：
    所述第一网络侧设备在向所述第二网络侧设备发送第一请求信息之后， 接收所述第二网络侧设备返回的所述第三验证结果，其中，所述第一请求信息还包括所述第一URSP规则；
    在向所述第二网络侧设备发送第一请求信息之后或在接收所述第二网络侧设备发送的第一响应信息之后，所述第一网络侧设备向所述第二网络侧设备发送第二请求信息，接收所述第二网络侧设备返回的所述第三验证结果，其中，所述第二请求信息用于请求获取所述第三验证结果，所述第二请求信息包括所述第一PDU会话标识和所述第一URSP规则。
  6. 根据权利要求5所述的方法，其中，所述第一网络侧设备向所述第二网络侧设备发送第二请求信息，包括：
    在所述第二验证结果指示所述第一参数与所述第二参数一致的情况下，所述第一网络侧设备向所述第二网络侧设备发送所述第二请求信息。
  7. 根据权利要求5所述的方法，其中，所述第一响应信息还包括所述第三验证结果。
  8. 根据权利要求5所述的方法，其中，接收所述第二网络侧设备返回的所述第三验证结果，包括：所述第一网络侧设备接收所述第二网络侧设备返回的第二响应信息，其中，所述第二响应信息包括所述第三验证结果，所述第二响应信息用于响应所述第二请求信息。
  9. 根据权利要求1所述的方法，其中，所述第一网络侧设备通过第二网络侧设备获取所述第二验证结果和所述第三验证结果，包括：
    所述第一网络侧设备向所述第二网络侧设备发送第三请求信息，其中，所述第三请求信息包括所述第一URSP规则以及所述第一PDU会话标识；
    所述第一网络侧设备获取所述第二网络侧设备发送的第三响应信息，其中，所述第三响应信息包括所述第二网络侧设备对所述第一参数与所述第二参数进行验证得到的所述第二验证结果，以及所述第二网络侧设备对所述第一PDU会话中是否包括所述目标应用的数据包进行验证得到的所述第三验证结果。
  10. 根据权利要求1所述的方法，其中，所述第一网络侧设备通过第二网络侧设备获取所述第二验证结果和所述第三验证结果，包括：
    所述第一网络侧设备向所述第二网络侧设备发送第四请求信息，其中，所述第四请求信息包括所述第一URSP规则以及所述第一PDU会话标识，用于请求所述第二网络侧设备对所述第一参数与所述第二参数进行验证；所述第一网络侧设备获取所述第二网络侧设备发送的第四响应信息，其中，所述第四响应信息包括所述第二网络侧设备对所述第一参数与所述第二参数进行验证得到的所述第二验证结果；
    所述第一网络侧设备向所述第二网络侧设备发送第五请求信息，其中， 所述第五请求信息包括所述第一URSP规则以及所述第一PDU会话标识，用于请求所述第二网络侧设备对所述第一PDU会话中是否包括所述目标应用的数据包进行验证；所述第一网络侧设备获取所述第二网络侧设备发送的第五响应信息，其中，所述第五响应信息包括所述第二网络侧设备对所述第一PDU会话中是否包括所述目标应用的数据包进行验证得到的所述第三验证结果。
  11. 根据权利要求1至10中任一项所述的方法，其中，所述方法还包括：
    在以下任一情况下，所述第一网络侧设备向所述第二网络侧设备发送第一指示信息，其中，所述第一指示信息用于指示所述终端未正确使用URSP规则：
    所述第一验证结果指示所述第一URSP规则与所述第二URSP规则不一致；
    所述第二验证结果指示所述第一参数中的至少一项参数与所述第二参数不一致；
    所述第三验证结果指示所述第一PDU会话对应的传输数据包中未包括所述目标应用的数据包。
  12. 根据权利要求1至10中任一项所述的方法，其中，所述方法还包括：
    在以下任一情况下，所述第一网络侧设备更新所述终端的URSP规则：
    所述第一验证结果指示所述第一URSP规则与所述第二URSP规则不一致；
    所述第二验证结果指示所述第一参数中的至少一项参数与所述第二参数不一致；
    所述第三验证结果指示所述第一PDU会话对应的传输数据包中未包括所述目标应用的数据包。
  13. 根据权利要求1至12中任一项所述的方法，其中，所述第一网络侧设备与所述第二网络侧设备之间直接进行信息传输，或者，所述第一网络侧设备与所述第二网络侧设备之间通过第三网络侧设备进行信息传输。
  14. 根据权利要求13所述的方法，其中，所述第三网络侧设备包括：AMF或SM-PCF。
  15. 一种URSP规则的验证方法，包括：
    第二网络侧设备通过与第一网络侧设备交互，确定第二验证结果，其中，所述第二验证结果指示承载终端的目标应用的第一PDU会话的第一参数与所述终端针对所述目标应用使用的第一URSP规则中的RSD描述的第二参数是否一致；
    所述第二网络侧设备通过验证所述第一PDU会话中是否包括所述目标 应用的数据包，获取第三验证结果，其中，所述第三验证结果指示所述第一PDU会话中是否包括所述目标应用的数据包。
  16. 根据权利要求15所述的方法，其中，所述第二网络侧设备通过与第一网络设备交互，获取第二验证结果，包括：
    所述第二网络侧获取所述第一网络侧设备发送的第一请求信息，其中，所述第一请求信息包括第一PDU会话标识，所述第一PDU会话标识用于指示第一PDU会话；
    所述第二网络侧设备获取所述第一PDU会话的第一参数；
    所述第二网络侧设备返回第一响应信息，其中，所述第一响应信息包括所述第一PDU会话的第一参数，指示所述第一网络侧设备验证所述第一参数与所述第二参数是否一致。
  17. 根据权利要求16所述的方法，其中，
    所述第一参数包括以下至少一项：PDU会话类型、PDU会话的接入类型、会话和服务连续性SSC模式、网络切片标识符、数据网络名称DNN；和/或，
    所述第二参数包括以下至少一项：PDU会话类型、PDU会话的接入类型、会话和服务连续性SSC模式、网络切片标识符、数据网络名称DNN。
  18. 根据权利要求17所述的方法，其中，所述第二网络侧设备通过验证所述第一PDU会话中是否包括所述目标应用的数据包，获取第三验证结果，包括：
    所述第二网络侧设备在接收到所述第一请求信息后，根据所述第一请求信息中的所述第一URSP规则，生成包检测规则，将所述包检测规则应用于所述第一PDU会话标识指示的第一PDU会话，获取第三验证结果，其中，所述包检测规则用于验证所述第一PDU会话中是否包括所述目标应用的数据包，所述第一请求信息中还包括所述第一URSP规则。
  19. 根据权利要求18所述的方法，其中，所述第一响应信息中还包括所述第三验证结果。
  20. 根据权利要求17所述的方法，其中，所述第二网络侧设备通过验证所述第一PDU会话中是否包括所述目标应用的数据包，获取第三验证结果，包括：
    在接收到所述第一请求信息后或者在向所述第二网络侧设备返回第一响应信息之后，所述第二网络侧设备获取所述第一网络侧设备发送的第二请求信息，其中，所述第二请求信息用于请求获取所述第三验证结果，所述第二请求信息中携带有所述第一PDU会话标识和所述第一URSP规则；
    所述第二网络侧设备根据第二请求信息中的所述第一URSP规则，生成包检测规则，将所述包检测规则应用于所述第一PDU会话标识所指示的第一 PDU会话，获取第三验证结果，其中，所述包检测规则用于验证所述第一PDU会话中是否包括所述目标应用的数据包。
  21. 根据权利要求20所述的方法，其中，在获取第三验证结果之后，所述方法还包括：向所述第一网络侧设备返回第二响应信息，其中，所述第二响应信息包括所述第三验证结果。
  22. 根据权利要求15所述的方法，其中，所述第二网络侧设备通过与第一网络设备交互，确定所述第二验证结果和获取所述第三验证结果，包括：
    所述第二网络侧设备接收所述第一网络侧设备发送的第三请求信息，其中，所述第三请求信息包括所述第一URSP规则以及所述第一PDU会话标识；
    所述第二网络侧设备获取所述第一PDU会话标识指示的第一PDU会话的第一参数；
    所述第二网络侧设备通过验证所述第一参数与所述第一URSP规则中的路由选择描述符RSD描述的第二参数是否一致，得到所述第二验证结果；
    所述第二网络侧设备根据第三请求信息中的所述第一URSP规则，生成包检测规则，将所述包检测规则应用于所述第一PDU会话标识所指示的第一PDU会话，获取第三验证结果，其中，所述包检测规则用于验证所述第一PDU会话中是否包括所述目标应用的数据包。
  23. 根据权利要求15所述的方法，其中，所述第二网络侧设备通过与第一网络设备交互，确定所述第二验证结果和获取所述第三验证结果，包括：
    所述第二网络侧设备接收所述第一网络侧设备发送的第四请求信息，其中，所述第四请求信息包括所述第一URSP规则以及所述第一PDU会话标识，用于请求所述第二网络侧设备对所述第一PDU会话标识所指示的第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数进行验证；
    所述第二网络侧设备获取所述第一PDU会话标识所指示的第一PDU会话的第一参数；
    所述第二网络侧设备通过验证获取的所述第一参数与所述第一URSP规则中的RSD描述的第二参数是否一致，得到所述第二验证结果；
    所述第二网络侧设备接收所述第一网络侧设备发送的第五请求信息，其中，所述第五请求信息包括所述第一URSP规则以及所述第一PDU会话标识，用于请求所述第二网络侧设备对所述第一PDU会话标识所指示的第一PDU会话中是否包括所述目标应用的数据包进行验证；
    所述第二网络侧设备根据第五请求信息中的所述第一URSP规则，生成包检测规则，将所述包检测规则应用于所述第一PDU会话标识所指示的第一PDU会话，获取第三验证结果，其中，所述包检测规则用于验证所述第一PDU会话中是否包括所述目标应用的数据包。
  24. 根据权利要求22或23所述的方法，其中，在所述确定所述第二验证结果和获取所述第三验证结果之后，所述方法还包括：
    所述第二网络侧设备向所述第一网络侧设备返回所述第二验证结果和所述第三验证结果。
  25. 根据权利要求15至24任一项所述的方法，其中，所述方法还包括：
    所述第二网络侧设备接收所述第一网络侧设备发送的第一指示信息，其中，所述第一指示信息用于指示所述终端未正确使用URSP规则；
    所述第二网络侧设备拒绝所述第一PDU会话标识对应的会话建立请求，或者，所述第二网络侧设备释放所述第一PDU会话标识对应的第一PDU会话；
    其中，所述终端未正确使用URSP规则包括以下之一：
    所述第一URSP规则与第二URSP规则不一致，所述第二URSP规则为所述第一网络侧设备发送给所述终端的与所述目标应用对应的至少一个URSP规则；
    所述第一参数中的至少一项参数与所述第二参数不一致；
    所述第一PDU会话中未包括所述目标应用的数据包。
  26. 根据权利要求15至25中任一项所述的方法，其中，所述第二网络侧设备与所述第一网络侧设备之间直接进行信息传输，或者，所述第二网络侧设备与所述第一网络侧设备之间通过第三网络侧设备进行信息传输。
  27. 一种URSP规则的验证方法，包括：
    第三网络侧设备接收所述第一网络侧设备发送的请求信息，其中，所述请求信息包括：第一PDU会话标识和/或第一URSP规则，所述第一PDU会话标识用于指示承载终端的目标应用的第一PDU会话，所述第一URSP规则为所述终端针对所述目标应用使用的URSP规则；
    所述第三网络侧设备将所述请求信息发送给第二网络侧设备；
    其中，所述请求信息用于以下至少之一：
    请求获取所述第一PDU会话的第一参数；
    请求验证所述第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数是否一致；
    请求根据所述第一URSP规则对所述第一PDU会话中是否包括所述目标应用的数据包。
  28. 根据权利要求27所述的方法，其中，在所述第三网络侧设备将所述请求信息发送给第二网络侧设备之后，所述方法还包括：
    所述第三网络侧设备获取所述第二网络侧设备返回的响应信息；
    所述第三网络侧设备将所述响应信息发送给所述第一网络侧设备。
  29. 根据权利要求28所述的方法，其中，所述响应信息包括以下之一：
    所述第一PDU会话的第一参数以及第三验证结果，其中，所述第三验证结果用于指示所述第一PDU会话中是否包括所述目标应用的数据包；
    第二验证结果和所述第三验证结果，其中，所述第二验证结果指示所述第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数是否一致。
  30. 一种URSP规则的验证装置，包括：
    第一接收模块，用于接收终端发送的上报信息，其中，所述上报信息包括所述终端针对目标应用使用的第一URSP规则以及第一PDU会话标识，所述第一PDU会话标识用于指示承载所述目标应用的第一PDU会话；
    第一获取模块，用于通过验证所述第一URSP规则与第二URSP规则是否一致，获取第一验证结果，其中，所述第二URSP规则为所述第一网络侧设备发送给所述终端的与所述目标应用对应的至少一个URSP规则；
    第二获取模块，用于获取第二验证结果，其中，所述第二验证结果指示所述第一PDU会话的第一参数与所述第一URSP规则中的路由选择描述符RSD描述的第二参数是否一致；通过所述第二网络侧设备获取第三验证结果，其中，所述第三验证结果指示所述第一PDU会话中是否包括所述目标应用的数据包。
  31. 根据权利要求30所述的装置，其中，所述第二获取模块通过第二网络侧设备，获取第二验证结果，包括：
    从所述第二网络侧设备获取所述第一PDU会话的第一参数；
    通过验证所述第一参数与所述第一URSP规则中的路由选择描述符RSD描述的第二参数是否一致，获取所述第二验证结果。
  32. 根据权利要求30所述的装置，其中，所述第二获取模块通过第二网络侧设备，获取第二验证结果和所述第三验证结果，包括：
    向所述第二网络侧设备发送第三请求信息，其中，所述第三请求信息包括所述第一URSP规则以及所述第一PDU会话标识；
    获取所述第二网络侧设备发送的第三响应信息，其中，所述第三响应信息包括所述第二网络侧设备对所述第一参数与所述第二参数进行验证得到的所述第二验证结果，以及所述第二网络侧设备对所述第一PDU会话中是否包括所述目标应用的数据包进行验证得到的所述第三验证结果。
  33. 根据权利要求30所述的装置，其中，所述第二获取模块通过第二网络侧设备，获取第二验证结果和所述第三验证结果，包括：
    向所述第二网络侧设备发送第四请求信息，其中，所述第四请求信息包括所述第一URSP规则以及所述第一PDU会话标识，用于请求所述第二网络 侧设备对所述第一参数与所述第二参数进行验证；
    获取所述第二网络侧设备发送的第四响应信息，其中，所述第四响应信息包括所述第二网络侧设备对所述第一参数与所述第二参数进行验证得到的所述第二验证结果；
    向所述第二网络侧设备发送第五请求信息，其中，所述第五请求信息包括所述第一URSP规则以及所述第一PDU会话标识，用于请求所述第二网络侧设备对所述第一PDU会话中是否包括所述目标应用的数据包进行验证；
    获取所述第二网络侧设备发送的第五响应信息，其中，所述第五响应信息包括所述第二网络侧设备对所述第一PDU会话中是否包括所述目标应用的数据包进行验证得到的所述第三验证结果。
  34. 一种URSP规则的验证装置，包括：
    确定模块，用于通过与第一网络侧设备交互，确定第二验证结果，其中，所述第二验证结果指示承载终端的目标应用的第一PDU会话的第一参数与所述终端针对目标应用使用的第一URSP规则中的RSD描述的第二参数是否一致；
    第三获取模块，用于通过验证所述第一PDU会话中是否包括所述目标应用的数据包，获取第三验证结果，其中，所述第三验证结果指示所述第一PDU会话中是否包括所述目标应用的数据包。
  35. 根据权利要求34所述的装置，其中，所述确定模块通过与第一网络侧设备交互，确定第二验证结果，包括：
    获取所述第一网络侧设备发送的第一请求信息，其中，所述第一请求信息包括第一PDU会话标识，所述第一PDU会话标识用于指示第一PDU会话；
    获取所述第一PDU会话的第一参数；
    返回第一响应信息，其中，所述第一响应信息包括所述第一PDU会话的第一参数，指示所述第一网络侧设备验证所述第一参数与所述第二参数是否一致。
  36. 根据权利要求35所述的装置，其中，所述第三获取模块通过验证所述第一PDU会话中是否包括所述目标应用的数据包，获取第三验证结果，包括：
    在接收到所述第一请求信息后，根据所述第一请求信息中的所述第一URSP规则，生成包检测规则，将所述包检测规则应用于所述第一PDU会话标识指示的第一PDU会话，获取第三验证结果，其中，所述包检测规则用于验证所述第一PDU会话中是否包括所述目标应用的数据包，所述第一请求信息中还包括所述第一URSP规则。
  37. 根据权利要求35所述的装置，其中，所述第三获取模块通过验证所 述第一PDU会话中是否包括所述目标应用的数据包，获取第三验证结果，包括：
    在接收到所述第一请求信息后或者在向所述第二网络侧设备返回第一响应信息之后，获取所述第一网络侧设备发送的第二请求信息，其中，所述第二请求信息用于请求获取所述第三验证结果，所述第二请求信息中携带有所述第一PDU会话标识和所述第一URSP规则；
    根据第二请求信息中的所述第一URSP规则，生成包检测规则，将所述包检测规则应用于所述第一PDU会话标识所指示的第一PDU会话，获取第三验证结果，其中，所述包检测规则用于验证所述第一PDU会话中是否包括所述目标应用的数据包。
  38. 根据权利要求34所述的装置，其中，
    所述确定模块确定所述第二验证结果包括：接收所述第一网络侧设备发送的第三请求信息，其中，所述第三请求信息包括所述第一URSP规则以及所述第一PDU会话标识；获取所述第一PDU会话标识指示的第一PDU会话的第一参数；通过验证所述第一参数与所述第一URSP规则中的路由选择描述符RSD描述的第二参数是否一致，得到所述第二验证结果；
    所述第三获取模块获取所述第三验证结果包括：根据第三请求信息中的所述第一URSP规则，生成包检测规则，将所述包检测规则应用于所述第一PDU会话标识所指示的第一PDU会话，获取第三验证结果，其中，所述包检测规则用于验证所述第一PDU会话中是否包括所述目标应用的数据包。
  39. 根据权利要求34所述的装置，其中，
    所述确定模块确定所述第二验证结果包括：接收所述第一网络侧设备发送的第四请求信息，其中，所述第四请求信息包括所述第一URSP规则以及所述第一PDU会话标识，用于请求对所述第一PDU会话标识所指示的第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数进行验证；获取所述第一PDU会话标识所指示的第一PDU会话的第一参数；通过验证获取的所述第一参数与所述第一URSP规则中的RSD描述的第二参数是否一致，得到所述第二验证结果；
    所述第三获取模块获取所述第三验证结果包括：接收所述第一网络侧设备发送的第五请求信息，其中，所述第五请求信息包括所述第一URSP规则以及所述第一PDU会话标识，用于请求对所述第一PDU会话标识所指示的第一PDU会话中是否包括所述目标应用的数据包进行验证；根据第五请求信息中的所述第一URSP规则，生成包检测规则，将所述包检测规则应用于所述第一PDU会话标识所指示的第一PDU会话，获取第三验证结果，其中，所述包检测规则用于验证所述第一PDU会话中是否包括所述目标应用的数 据包。
  40. 一种URSP规则的验证装置，包括：
    第二接收模块，用于接收所述第一网络侧设备发送的请求信息，其中，所述请求信息包括：第一PDU会话标识和/或第一URSP规则，所述第一PDU会话标识用于指示承载终端的目标应用的第一PDU会话，所述第一URSP规则为所述终端针对所述目标应用使用的URSP规则；
    发送模块，用于将所述请求信息发送给第二网络侧设备；
    其中，所述请求信息用于以下至少之一：
    请求获取所述第一PDU会话的第一参数；
    请求验证所述第一PDU会话的第一参数与所述第一URSP规则中的RSD描述的第二参数是否一致；
    请求根据所述第一URSP规则对所述第一PDU会话中是否包括所述目标应用的数据包。
  41. 一种网络侧设备，包括处理器和存储器，所述存储器存储可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如权利要求1至29任一项所述的URSP规则的验证方法的步骤。
  42. 一种可读存储介质，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如权利要求1至29任一项所述的URSP规则的验证方法的步骤。
PCT/CN2023/092149 2022-05-05 2023-05-05 Ursp规则的验证方法、装置及网络侧设备 WO2023213282A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210482912.1 2022-05-05
CN202210482912.1A CN117062246A (zh) 2022-05-05 2022-05-05 Ursp规则的验证方法、装置及网络侧设备

Publications (1)

Publication Number Publication Date
WO2023213282A1 true WO2023213282A1 (zh) 2023-11-09

Family

ID=88646276

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/092149 WO2023213282A1 (zh) 2022-05-05 2023-05-05 Ursp规则的验证方法、装置及网络侧设备

Country Status (2)

Country Link
CN (1) CN117062246A (zh)
WO (1) WO2023213282A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110418328A (zh) * 2018-04-28 2019-11-05 华为技术有限公司 一种通信方法及装置
CN112087815A (zh) * 2019-06-13 2020-12-15 华为技术有限公司 通信方法、装置及系统
WO2021049782A1 (en) * 2019-09-10 2021-03-18 Samsung Electronics Co., Ltd. Method and apparatus for providing policy of user equipment in wireless communication system
CN113259983A (zh) * 2021-02-07 2021-08-13 中国移动通信有限公司研究院 5g切片测试方法、装置、测试系统及存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110418328A (zh) * 2018-04-28 2019-11-05 华为技术有限公司 一种通信方法及装置
CN112087815A (zh) * 2019-06-13 2020-12-15 华为技术有限公司 通信方法、装置及系统
WO2021049782A1 (en) * 2019-09-10 2021-03-18 Samsung Electronics Co., Ltd. Method and apparatus for providing policy of user equipment in wireless communication system
CN113259983A (zh) * 2021-02-07 2021-08-13 中国移动通信有限公司研究院 5g切片测试方法、装置、测试系统及存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
TENCENT: "KI #1: Update the Conclusion for the EAS discovery", 3GPP DRAFT; S2-2007570, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG2, no. Elbonia; 20201012 - 20201023, 2 October 2020 (2020-10-02), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051938609 *

Also Published As

Publication number Publication date
CN117062246A (zh) 2023-11-14

Similar Documents

Publication Publication Date Title
KR102313165B1 (ko) 데이터 송신 방법, 디바이스 및 시스템
EP3634081B1 (en) Session context deletion methods and apparatus
CN111615217B (zh) 一种会话建立方法及装置
EP3160190B1 (en) Access authentication method and system
CN110831007B (zh) 用户面完整性保护方法、装置及设备
EP3934368A1 (en) Session processing method, communication device and communication system
CN112637819B (zh) 一种融合网络中的业务开通方法及装置
CN110249589A (zh) 一种通信方法及设备
EP4187947A1 (en) Application migration method and apparatus
EP4383664A1 (en) Communication method and apparatus
WO2018161263A1 (zh) 一种会话迁移方法及设备
WO2023213282A1 (zh) Ursp规则的验证方法、装置及网络侧设备
EP4109939A1 (en) Message forwarding method and apparatus
CN113573297A (zh) 一种通信方法及装置
EP4325901A1 (en) Service accessing method and apparatus, and system
EP3316608B1 (en) A communication network and a method for establishing non-access stratum connections in a communication network
WO2023213309A1 (zh) Ursp规则的验证方法、装置及网络侧设备
WO2024061205A1 (zh) 参数获取方法、装置、第一网络功能及第二网络功能
CN111372322B (zh) 一种通信方法及装置
WO2024067331A1 (zh) 个人物联网中的设备切换方法、通信方法及设备
WO2024008182A1 (zh) 信息处理方法、装置、通信设备及可读存储介质
WO2024012238A1 (zh) 通信处理方法、装置、通信设备及可读存储介质
WO2023143417A1 (zh) 策略处理方法、装置及网络功能
CN117580030A (zh) 通信方法和通信装置
WO2018049681A1 (zh) 数据业务处理方法、装置、终端及网络设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23799268

Country of ref document: EP

Kind code of ref document: A1