Communication methods and communication devices

Abstract

Embodiments of the present application provide a communication method and a communication device. The method comprises the steps of: when the communication device detects an application, the communication device determines that the application matches a route selection policy rule based on a second application identifier and a second application distinction parameter associated with the application, and associates the application with a session according to the route selection policy rule. The route selection policy rule includes a first application identifier and a first application distinction parameter. According to the method disclosed herein, the addition of both the first and second application distinction parameters enables the communication device to effectively identify the application.

Description

Technical Field

[0005] , , , ,

[0006] ,

[0001] This application claims priority to Chinese Patent Application No. 202310394661.6, titled "Communication Method and Communication Device", filed with the China National Intellectual Property Administration on April 7, 2023, the entire content of which is incorporated herein by reference.

[0002] This application relates to the field of communications, and more particularly, to communication methods and communication devices.

Background Art

[0003] In a communication system, a communication device or user equipment (UE) may determine a path for transmitting the data traffic of the communication device or user equipment according to a UE route selection policy (URSP). For example, the UE may select an existing session connected to a data network (DN) according to the URSP rule to transmit the UE's data traffic; or the UE may transmit the UE's data traffic by setting up a new session in a specific network slice.

[0004] Currently, how to reduce or avoid potential security risks that a terminal device may encounter in the route selection process is an issue that needs to be considered.

Summary of the Invention

[0005] This application provides a communication method and a communication device to reduce or avoid potential security risks that a terminal device may encounter in the route selection process.

[0006] According to the first embodiment, a communication method is provided. The method may be carried out by a communication device. Optionally, the communication device may be a terminal device, such as a mobile phone, a vehicle, an unmanned aerial vehicle, or a wearable device, or a chip or circuit in a terminal device. In addition, a terminal device may also be referred to as a user device. Therefore, the communication device may alternatively be a user device or a chip in a user device. This is not specifically limited in this application.

[0007] The method includes the step of determining whether an application matches a route selection policy rule based on the application's second application identifier and second application distinction parameter when the communication device detects an application. The route selection policy rule includes a first application identifier and a first application distinction parameter. The communication device associates the application with a session, for example, a protocol data unit (PDU) session, according to the route selection policy rule.

[0008] For example, an application may also be referred to as application traffic. When a communication device determines that an application matches a route selection policy rule, this can be understood as evaluating whether the "application" matches a traffic descriptor in the route selection policy rule, or as evaluating whether application traffic matches a traffic descriptor in the route selection policy rule. These distinctions are not made in this application, and the relevant parts are not explained again below.

[0009] Based on the solution provided in this application, the first and second application distinction parameters are further verified so that the terminal device can effectively identify the detected application and determine whether the application matches the route selection policy rule. This prevents the application's network resources in the route selection policy rule from being compromised and reduces the risk of network nodes being attacked by malicious traffic.

[0010] Referring to the first aspect, in some implementations of the first aspect, before the communication device determines that an application matches a route selection policy rule based on the application's second application identifier and second application distinction parameter, the method further comprises: the step of the communication device receiving the route selection policy rule from a network device.

[0011] Referring to the first embodiment, in some implementations of the first embodiment, the second application distinction parameter includes one or more of the following: an identifier for the application's binding platform, an identifier for the application's application program source, a name for the application's installation package, an identifier for the application's user, an identifier for the application's developer, an identifier for the public land mobile network associated with the application, or an identifier for the application function used to generate route selection policy rules.

[0012] Referring to the first aspect, in some implementations of the first aspect, the communication device performs integrity or authenticity verification on the second application identifier and the second application distinction parameter. The communication device's determination that an application matches a route selection policy rule based on the application's second application identifier and second application distinction parameter includes: when integrity or authenticity verification is successful, the communication device determines that the application matches a route selection policy rule based on the second application identifier and the second application distinction parameter.

[0013] Based on the above solution, integrity or authenticity verification is performed on the second application identifier and second application distinction parameters to ensure that the second application identifier and second application distinction parameters have not been tampered with. This further reduces or avoids potential security risks that terminal devices may encounter during the route selection process.

[0014] Referring to the first aspect, in some implementations of the first aspect, the communication device determining whether an application matches a route selection policy rule based on the application's second application identifier and second application distinction parameter includes: the communication device determining that the first application identifier is identical to the second application identifier, and that the first application distinction parameter is identical to the second application distinction parameter.

[0015] Based on the above solution, when the communication device determines that the first application identifier is the same as the second application identifier, and that the first application distinction parameter is the same as the second application distinction parameter, the communication device determines that the application matches the route selection policy rule. This further reduces or avoids potential security risks that terminal devices may encounter in the route selection process.

[0016] Referring to the first aspect, in some implementations of the first aspect, the communication device includes an operating system and a modem, and the method further comprises: a step in which the operating system receives a first parameter from an application. The first parameter includes one or more of the following: a temporary identifier, a temporary key, or an access token. The operating system determines a second application identifier and a second application distinction parameter based on the first parameter and transmits the second application identifier and the second application distinction parameter to the modem. The communication device determining that an application matches a route selection policy rule based on the application's second application identifier and second application distinction parameter includes the modem determining that the second application identifier is identical to the first application identifier and that the second application distinction parameter is identical to the first application distinction parameter.

[0017] Based on the above solution, the operating system verifies the application's second application identifier and second application distinction parameter to determine the application's authenticity or integrity. In addition, if the first application identifier is the same as the second application identifier and the second application distinction parameter is the same as the first application distinction parameter, the modem determines that the application matches the route selection policy rule. This reduces or avoids potential security risks that terminal devices may encounter during the route selection process.

[0018] Referring to the first aspect, in some implementations of the first aspect, the operating system determining the second application identifier and second application distinguishing parameter based on a first parameter includes: the operating system determining the second application identifier and second application distinguishing parameter based on a temporary identifier and a mapping relationship, where the mapping relationship indicates the relationship between the second application identifier, the second application distinguishing parameter and the temporary identifier; or the operating system determining the second application identifier and second application distinguishing parameter associated with an application based on a temporary key or access token.

[0019] Based on the above solution, the operating system determines the application's second application identifier and second application distinguishing parameters based on a temporary identifier, temporary key, or access token. Considering the uncertainty in generating the temporary identifier, temporary key, or access token, the solution can be made more secure, reducing or avoiding potential security risks that the terminal device may encounter in the root selection process.

[0020] Referring to the first aspect, in some implementations of the first aspect, the operating system receiving the first parameter from the application includes: when the application is activated or used, the operating system receiving the first parameter from the application.

[0021] Referring to the first aspect, in some implementations of the first aspect, before the operating system receives the first parameter from the application, the method further comprises: the steps of the operating system generating the first parameter and sending the first parameter to the application. When the first parameter is a temporary identifier, the operating system stores the mapping relationship.

[0022] Based on the above solution, and taking into account the uncertainty in generating temporary identifiers, temporary keys, or access tokens, the operating system determines a second application identifier associated with the application based on the temporary identifier, temporary key, or access token, thereby making the solution more secure and reducing or avoiding potential security risks that the terminal device may encounter in the root selection process.

[0023] Referring to the first aspect, in some implementations of the first aspect, the communication device sends an authentication request message to the user. The authentication request message includes a second application identifier and a second application distinction parameter, and is used to request the user to verify the second application identifier and the second application distinction parameter. The communication device receives an authentication response message from the user. The authentication response message includes the verification result of the second application identifier and the second application distinction parameter. The communication device's determination that the application matches the route selection policy rule based on the application's second application identifier and second application distinction parameter includes the communication device determining that the application matches the route selection policy rule based on the authentication response message.

[0024] Based on the above solution, an authentication request message is sent to the user, requesting the user to verify the second application identifier and second application distinction parameters. Based on the identification and verification results obtained by the user, it is determined that the application matches the route selection policy rule. This reduces or avoids potential security risks that the terminal device may encounter during the route selection process.

[0025] Referring to the first aspect, in some implementations of the first aspect, the communication device sends an authentication request message to the user. The authentication request message includes a second application identifier and a second application distinction parameter, and is used to request the user to determine whether the second application identifier matches the first application identifier and whether the second application distinction parameter matches the first application distinction parameter. The communication device receives an authentication response message from the user. The authentication response message includes a first matching result for the second application identifier and the first application identifier, and a second matching result for the second application distinction parameter and the first application distinction parameter. The communication device's determination that the application matches the route selection policy rule based on the application's second application identifier and second application distinction parameter includes the communication device's determination that the application matches the route selection policy rule based on the authentication response message.

[0026] Based on the above solution, an authentication request message is sent to the user, asking the user to determine whether the second application identifier matches the first application identifier and whether the second application distinction parameter matches the first application distinction parameter. Based on the identification and verification results obtained by the user, it is determined that the application matches the route selection policy rule. This reduces or avoids potential security risks that the terminal device may encounter during the route selection process.

[0027] Referring to the first aspect, in some implementations of the first aspect, for the communication device to determine that an application matches a route selection policy rule based on an authentication response message: when the verification result indicates that the verification performed by the user on the second application identifier and the second application discrimination parameter is successful, the communication device determines that the application matches the route selection policy rule; or when the first matching result indicates that the second application identifier is the same as the first application identifier, and the second matching result indicates that the second application discrimination parameter is the same as the first application discrimination parameter, the communication device determines that the application matches the route selection policy rule.

[0028] Based on the above solution, the communication device determines that an application matches a route selection policy rule based on the user's verification result or matching result. Thereby, security can be improved, and potential security risks that the terminal device may encounter in the route selection process can be reduced or avoided.

[0029] Referring to the first aspect, in some implementations of the first aspect, the communication device determines the second application discrimination parameter associated with the application based on the result of verifying the second application discrimination parameter associated with the application by the user; or when the matching result indicates that the second application discrimination parameter associated with the application is the same as the first application discrimination parameter, the communication device determines that the application matches the route selection policy rule.

[0030] According to a second aspect, a communication method is provided. The method may be executed by a network device or may be executed by a chip or circuit used in the network device. This is not limited in the present application. For the sake of ease of explanation, an example where the method is executed by a network device is used below for the explanation.

[0031] The method includes: a step in which a network device obtains a route selection policy rule, where the route selection policy rule includes a first application identifier and a first application discrimination parameter; and a step of transmitting the route selection policy rule to a communication device.

[0032] Based on the solution provided in the present application, a first application discrimination parameter is introduced. As a result, the terminal device can effectively identify the detected application, and further, can verify whether the application matches the route selection policy rule. Thereby, it is possible to prevent the network resources of the application associated with the route selection policy rule from being infringed, and reduce the risk that the network node is attacked by malicious traffic.

[0033] For some other specific implementations on the network device side and the beneficial effects of some implementations, refer to the relevant explanations in the first aspect. Details are not described again here.

[0034] According to a third aspect, a communication method is provided. The method may be executed by a communication device or may be executed by a chip or circuit used in the communication device. This is not limited in the present application. For the sake of ease of explanation, an example where the method is executed by a communication device is used below for the explanation.

[0035] The method comprises the steps of: when a communication device detects an application, the communication device determines whether the application matches a route selection policy rule; sending a request message to a network device, where the request message includes the application identifier of the application and is used to request that the network device verify whether the application matches a route selection policy rule; and receiving a response message from the network device.

[0036] Based on the solution provided in this application, the additional step of requiring a network device to verify whether an application matches a route selection policy rule, based on the communication device's determination that the detected application matches a route selection policy rule, ensures the authenticity of applications detected by the communication device, prevents the compromise of network resources of applications associated with route selection policy rules, and reduces the risk of network nodes being attacked by malicious traffic.

[0037] Referring to the third aspect, in some implementations of the third aspect, the application identifier of the application is secured.

[0038] Based on the above solution, the application identifier of an application is secured. This improves network communication security, prevents malicious tampering with the application identifier of an application during the transmission process, and reduces the risk of the application's network resources being compromised in route selection policy rules and network nodes being attacked by malicious traffic.

[0039] Referring to the third aspect, in some implementations of the third aspect, the application identifier of a secure application includes one or more of the following: the application identifier of a digitally signed application, the application identifier of a key-encrypted application, or the application identifier of a hashed application.

[0040] Referring to the third aspect, in some implementations of the third aspect, the request message further includes authentication information, which includes the application identifier of the application and a digital signature used to verify the application identifier of the application, which is used to verify the authenticity or integrity of the application, and which is any one of the following: a digital signature, a hash value, or a message authentication code.

[0041] Based on the above solution, authentication information is maintained, and as a result, network devices verify the authenticity or integrity of newly detected applications by communication devices. This improves security by allowing network devices to verify the application identifier of applications, improves network communication security, and reduces the risk of application network resources being compromised in route selection policy rules and network nodes being attacked by malicious traffic.

[0042] Optionally, the communication device sends the identifier of the route selection policy rule to the network device.

[0043] Referring to the third embodiment, in some implementations of the third embodiment, before the communication device sends a request message to the network device, the method further includes: a step of determining that the communication device will send the application identifier of an application to the network device based on first configuration information, where the first configuration information instructs the communication device to send the application identifier of an application to the network device, and the first configuration information is pre-configured in the communication device; or a step of determining that the communication device will send the application identifier of an application to the network device based on first instruction information from the network device, where the first instruction information instructs the communication device to send the application identifier of an application to the network device.

[0044] Based on the above solution, the communication device may determine, based on the first configuration information or first instruction information, to send a request message containing the application identifier of the application to the network device. An additional step in which the network device verifies whether the application matches the route selection policy rule prevents the communication device from impersonating the application. This improves network communication security and reduces the risk that the application's network resources in the route selection policy rule may be compromised and that network nodes may be attacked by malicious traffic.

[0045] Referring to the third aspect, in some implementations of the third aspect, the request message is either a session setup request message or a session modification request message.

[0046] Based on the above solution, the application identifier of the application is retained in the session setup request message or session modification request message, reducing unnecessary interaction steps and signaling overhead.

[0047] Referring to the third aspect, in some implementations of the third aspect, the request message further includes second directive information, which instructs the request message to hold the application identifier of the application, or which instructs the network device to verify whether the application matches a route selection policy rule.

[0048] Based on the above solution, the second instruction information may instruct the network device to verify the application identifier of the application. Further verification or additional verification processes help improve network communication security and reduce the risk that the application's network resources in route selection policy rules may be compromised and network nodes may be attacked by malicious traffic.

[0049] Referring to the third aspect, in some implementations of the third aspect, the request message further includes application-specific parameters for the application. These application-specific parameters are further validated to more effectively identify the authenticity of the application detected by the communication device and to further determine if the application matches the route selection policy rule. This prevents the application's network resources in the route selection policy rule from being compromised and reduces the risk of network nodes being attacked by malicious traffic.

[0050] Referring to the third aspect, in some implementations of the third aspect, the application's application-specific parameters are secured. Security protection is applied to the application's application-specific parameters, effectively improving network communication security, preventing malicious tampering of the application's application-specific parameters during the transmission process, and reducing the risk of the application's network resources being compromised and network nodes being attacked by malicious traffic in route selection policy rules.

[0051] Referring to the third aspect, in some implementations of the third aspect, the application distinction parameter for a secure application includes one or more of the following: the application distinction parameter for a digitally signed application, the application distinction parameter for a key-encrypted application, or the application distinction parameter for a hashed application.

[0052] Referring to the third embodiment, in some implementations of the third embodiment, before the communication device sends a request message to the network device, the method further includes: the step of the communication device determining, based on second configuration information, that it will send the application identifier and application distinction parameters of the application to the network device, where the second configuration information instructs the communication device to send the application identifier and application distinction parameters of the application to the network device, and the second configuration information is pre-configured in the communication device; or the step of the communication device determining, based on third instruction information from the network device, that it will send the application identifier and application distinction parameters of the application to the network device, where the third instruction information instructs the communication device to send the application identifier and application distinction parameters of the application to the network device.

[0053] Based on the above solution, the communication device may determine, based on the second configuration information or the third instruction information, to send a request message to the network device that includes the application identifier and application distinction parameters of the application. An additional step in which the network device verifies whether the application matches the route selection policy rule helps improve network communication security and reduces the risk that the application's network resources in the route selection policy rule may be compromised and that network nodes may be attacked by malicious traffic.

[0054] Referring to the third aspect, in some implementations of the third aspect, the request message further includes fourth directive information, which instructs the request message to hold the application identifier and application distinction parameters of the application, or instructs the network device to verify whether the application matches the route selection policy rules.

[0055] Based on the above solution, the fourth instruction information may instruct the network device to verify the application identifier and application distinction parameters of the application. Further verification or additional verification processes help improve network communication security and reduce the risk that the application's network resources in route selection policy rules may be compromised and network nodes may be attacked by malicious traffic.

[0056] Referring to the third aspect, in some implementations of the third aspect, when an application matches a route selection policy rule, the response message instructs the network device to accept the request of the communication device.

[0057] Referring to the third aspect, in some implementations of the third aspect, the method further comprises the step that when an application does not match a route selection policy rule, the communication device receives a rejection message from a network device. The rejection message indicates that the network device rejects the communication device's request, and the rejection message includes a rejection cause, which indicates that the application identifier of the application is different from the application identifier in the route selection policy rule, and / or the application distinction parameter of the application is different from the application distinction parameter in the route selection policy rule, i.e., the validation fails.

[0058] Based on the above solution, when an application matches a route selection policy rule, the network device accepts the communication device's request, for example, by setting up or modifying the session associated with the application. When an application does not match a route selection policy rule, the network device does not accept the communication device's request, for example, by not setting up or modifying the session associated with the application. This reduces the risk that the application's network resources in the route selection policy rule may be compromised and that network nodes may be attacked by malicious traffic.

[0059] According to a fourth aspect, a communication method is provided. The method may be performed by a network device or by a chip or circuit used in a network device. This is not limited to the present application. For the sake of clarity, an example in which the method is performed by a network device is used below for illustrative purposes.

[0060] The method comprises: a step in which a network device receives a request message from a communication device, the request message including the application identifier of an application, and the request message is used to request that the device verify whether the application matches a route selection policy rule; a step in which the device determines, based on the application identifier of the application, that the application matches the route selection policy rule; and a step in which the device sends a response message to the communication device.

[0061] Based on the solution provided in this application, the additional step of requiring a network device to verify whether an application matches a route selection policy rule, based on the communication device's determination that the detected application matches a route selection policy rule, ensures the authenticity of applications detected by the communication device, prevents the compromise of network resources of applications associated with route selection policy rules, and reduces the risk of network nodes being attacked by malicious traffic.

[0062] Referring to the fourth aspect, in some implementations of the fourth aspect, the application identifier of the application is secured.

[0063] Based on the above solution, the application identifier of an application is secured. This improves network communication security, prevents malicious tampering with the application identifier of an application during the transmission process, and reduces the risk of the application's network resources associated with route selection policy rules being compromised and network nodes being attacked by malicious traffic.

[0064] Referring to the fourth aspect, in some implementations of the fourth aspect, the application identifier of a secure application includes one or more of the following: the application identifier of a digitally signed application, the application identifier of a key-encrypted application, or the application identifier of a key-encrypted application.

[0065] Referring to the fourth aspect, in some implementations of the fourth aspect, the request message further includes authentication information, which includes the application identifier of the application and a digital signature used to verify the application identifier of the application, which is used to verify the authenticity or integrity of the application, and which is any one of the following: a digital signature, a hash value, or a message authentication code.

[0066] Based on the above solution, authentication information is maintained, and as a result, network devices verify the authenticity or integrity of newly detected applications by communication devices. This improves network communication security and reduces the risk of application network resources being compromised in route selection policy rules and network nodes being attacked by malicious traffic.

[0067] Referring to the fourth aspect, in some implementations of the fourth aspect, the network device determines that an application matches a route selection policy rule based on the application identifier in the route selection policy rule and the application identifier of the application, which includes the network device determining that the application identifier of the application is the same as the application identifier of the application in the route selection policy rule.

[0068] Based on the above solution, the network device determines that the application matches the route selection policy rule when the application identifier of the application is the same as the application identifier in the route selection policy rule. The additional step of the network device verifying the application identifier of the application improves communication security in the route selection process and helps reduce the risk that the network resources of the application in the route selection policy rule may be compromised and that network nodes may be attacked by malicious traffic.

[0069] Referring to the fourth aspect, in some implementations of the fourth aspect, the network device's determination that an application matches a route selection policy rule based on the application identifier in the route selection policy rule and the application identifier of the application includes: verifying the digital signature when the application identifier of the application is digitally signed; and, if the verification of the digital signature is successful, determining that the application matches the route selection policy rule based on the application identifier in the route selection policy rule and the application identifier of the application.

[0070] Based on the above solution, the digital signature of the application identifier of the application is further verified to improve network communication security and reduce the risk that the network resources of the application associated with the route selection policy rule will be compromised and that network nodes will be attacked by malicious traffic.

[0071] Referring to the fourth aspect, in some implementations of the fourth aspect, before the network device receives a request message from the communication device, the method further comprises: the step of the network device sending first instruction information to the communication device, where the first instruction information instructs the communication device to send the application identifier of the application to the network device.

[0072] Based on the above solution, transmitting the first instruction information may enable the communication device to determine that it will send a request message to the network device based on the first instruction information. Additional verification processes in the route selection process help improve network communication security and reduce the risk that network resources of applications associated with route selection policy rules may be compromised and network nodes may be attacked by malicious traffic.

[0073] Referring to the fourth aspect, in some implementations of the fourth aspect, the request message is either a session setup request message or a session modification request message.

[0074] Based on the above solution, the application identifier of the application is retained in the session setup request message or session modification request message, reducing unnecessary interaction steps and signaling overhead.

[0075] Referring to the fourth aspect, in some implementations of the fourth aspect, the request message further includes second directive information which indicates that the request message should hold the application identifier of the application, or the second directive information which indicates that the network device should verify whether the application matches a route selection policy rule. The network device's determination that the application matches a route selection policy rule based on the application identifier of the application and the application identifier in the route selection policy rule includes: the network device determining that the application matches a route selection policy rule based on the second directive information, the application identifier of the application, and the application identifier in the route selection policy rule.

[0076] Based on the above solution, the second instruction information may instruct the network device to verify the application identifier of the application. Further verification or additional verification processes help improve network communication security and reduce the risk that network resources of applications associated with route selection policy rules may be compromised and network nodes may be attacked by malicious traffic.

[0077] Referring to the fourth aspect, in some implementations of the fourth aspect, the request message further includes application-specific parameters for the application. The network device's determination that an application matches a route selection policy rule based on the application identifier of the application and the application identifier in the route selection policy rule includes: the network device determining that an application matches a route selection policy rule based on the application identifier of the application, the application identifier in the route selection policy rule, the application-specific parameters for the application, and the application-specific parameters in the route selection policy rule.

[0078] Referring to the fourth aspect, in some implementations of the fourth aspect, the network device determines that an application matches a route selection policy rule based on the application identifier of the application, the application identifier in the route selection policy rule, the application distinction parameter of the application, and the application distinction parameter of the route selection policy rule, which includes the network device determining that the application identifier of the application is the same as the application identifier in the route selection policy rule, and that the application distinction parameter of the application is the same as the application distinction parameter of the route selection policy rule.

[0079] Based on the above solution, verifying the application's application distinction parameters enables more effective identification of the authenticity of applications detected by communication devices, and further determination of whether the application matches the route selection policy rules. This prevents the application's network resources in the route selection policy rules from being compromised and reduces the risk of network nodes being attacked by malicious traffic.

[0080] Referring to the fourth aspect, in some implementations of the fourth aspect, the application's application-specific parameters are secured. Implementing security measures for the application's application-specific parameters effectively improves network communication security, prevents malicious tampering of the application's application-specific parameters during the transmission process, and helps reduce the risk of the application's network resources being compromised and network nodes being attacked by malicious traffic in route selection policy rules.

[0081] Referring to the fourth aspect, in some implementations of the fourth aspect, the application distinction parameter for a secure application includes one or more of the following: the application distinction parameter for a digitally signed application, the application distinction parameter for a key-encrypted application, or the application distinction parameter for a hashed application.

[0082] Referring to the fourth aspect, in some implementations of the fourth aspect, before the network device receives a request message from the communication device, the method further includes: the step of the network device sending third instruction information to the communication device, where the third instruction information instructs the communication device to send the application identifier and application distinction parameters of the application to the network device.

[0083] Based on the above solution, the communication device may determine, based on the third instruction information, to send a request message to the network device that includes the application identifier and application distinction parameters of the application. An additional step in which the network device verifies whether the application matches the route selection policy rule helps improve network communication security and reduces the risk that the application's network resources in the route selection policy rule may be compromised and that network nodes may be attacked by malicious traffic.

[0084] Referring to the fourth aspect, in some implementations of the fourth aspect, the request message further includes fourth directive information, which indicates that the request message should hold the application identifier and application distinction parameters of the application, or the fourth directive information indicates that the network device should verify whether the application matches a route selection policy rule. The network device's determination that the application matches a route selection policy rule, based on the application identifier of the application, the application identifier in the route selection policy rule, the application distinction parameters of the application, and the application distinction parameters of the route selection policy rule, includes the network device determining that the application matches a route selection policy rule based on the fourth directive information, the application identifier of the application, the application identifier in the route selection policy rule, the application distinction parameters of the application, and the application distinction parameters of the route selection policy rule.

[0085] Based on the above solution, the fourth instruction information may instruct the network device to verify the application identifier and application distinction parameters of the application. Further verification or additional verification processes help improve network communication security and reduce the risk that the application's network resources in route selection policy rules may be compromised and network nodes may be attacked by malicious traffic.

[0086] Referring to the fourth aspect, in some implementations of the fourth aspect, when an application does not match a route selection policy rule, the network device sends a rejection message to the communication device. The rejection message indicates that the network device rejects the communication device's request, and the rejection message includes a reason for rejection, which indicates that the application identifier of the application is different from the application identifier in the route selection policy rule, and / or the application distinction parameter of the application is different from the application distinction parameter in the route selection policy rule.

[0087] Referring to the fourth aspect, in some implementations of the fourth aspect, when an application matches a route selection policy rule, the response message instructs the network device to accept the request of the communication device.

[0088] Referring to the fourth aspect, in some implementations of the fourth aspect, when an application does not match a route selection policy rule, the method further comprises the step of: the network device sending a rejection message to the communication device. The rejection message indicates that the network device rejects the request of the communication device, and the rejection message includes a reason for rejection, which indicates that the application identifier of the application is different from the application identifier in the route selection policy rule, and / or the application distinction parameter of the application is different from the application distinction parameter in the route selection policy rule, i.e., the validation fails.

[0089] Based on the above solution, when an application matches a route selection policy rule, the network device accepts the communication device's request, for example, by setting up or modifying the session associated with the application. When an application does not match a route selection policy rule, the network device does not accept the communication device's request, for example, by not setting up or modifying the session associated with the application. This reduces the risk that the network resources of the application associated with the route selection policy rule may be compromised and that network nodes may be attacked by malicious traffic.

[0090] According to a fifth aspect, a communication method is provided. The method may be performed by a communication device, or by a chip or circuit used in a communication device. This is not limited to the present application. For ease of explanation, an example in which the method is performed by a communication device will be used below. The communication device comprises an operating system and a modem.

[0091] The method comprises the steps of: the operating system receiving a first parameter from the application, where the first parameter includes one or more of the following: a temporary identifier, a temporary key, or an access token; determining the application's second application identifier and second application distinction parameter based on the first parameter; and sending the second application identifier to the modem. The modem determines, based on the second application identifier and the first application identifier, that the application matches a route selection policy rule, where the route selection policy rule includes the first application identifier.

[0092] Optionally, the operating system may further determine a second application-specific parameter of the application based on the first parameter and send the second application-specific parameter to the modem. The modem determines, based on the second application-specific parameter and the first application-specific parameter, that the application matches a route selection policy rule, where the route selection policy rule includes the first application-specific parameter.

[0093] Referring to the fifth aspect, in some implementations of the fifth aspect, the modem's determination that an application matches a route selection policy rule based on a second application identifier and a first application identifier includes the modem determining that the second application identifier is identical to the first application identifier.

[0094] Optionally, the modem may further determine whether an application matches a route selection policy rule based on a second application distinction parameter and a first application distinction parameter. For example, the modem may determine that the second application distinction parameter is identical to the first application distinction parameter.

[0095] Based on the solution provided in this application, the operating system verifies the application's second application identifier (optionally, the operating system may alternatively verify the second application distinction parameter) to determine the application's authenticity or integrity. This reduces or avoids potential security risks that a terminal device may encounter in the route selection process. When the first application identifier is identical to the second application identifier, the modem determines that the application matches the route selection policy rule. This reduces or avoids potential security risks that a terminal device may encounter in the route selection process.

[0096] Referring to the fifth aspect, in some implementations of the fifth aspect, the operating system determining the second application identifier based on a first parameter includes: the operating system determining the second application identifier based on a temporary identifier and a mapping relationship, where the mapping relationship indicates the relationship between the second application identifier and the temporary identifier; or the operating system determining the second application identifier based on a temporary key or access token.

[0097] Optionally, the operating system may further determine a second application-specific parameter based on the first parameter, which includes: the operating system determining the second application-specific parameter based on a temporary identifier and a mapping relationship, where the mapping relationship indicates the relationship between the second application-specific parameter and the temporary identifier; or the operating system determining the second application-specific parameter based on a temporary key or access token.

[0098] Referring to the fifth aspect, in some implementations of the fifth aspect, the operating system receiving the first parameter from the application includes: when the application is activated or used, the operating system receiving the first parameter from the application.

[0099] Referring to the fifth aspect, in some implementations of the fifth aspect, before the operating system receives the first parameter from the application, the method further comprises the steps of: the operating system generating the first parameter and sending the first parameter to the application. When the first parameter is a temporary identifier, the operating system stores the mapping relationship.

[0100] For the beneficial effects of the fifth embodiment and some implementations of the fifth embodiment, please refer to the corresponding description in the first embodiment. Further details will not be explained here.

[0101] According to the sixth aspect, a communication method is provided. The method may be performed by a communication device, or by a chip or circuit used in a communication device. This is not limited to the present application. For ease of explanation, the following examples will use a communication device in which the method is performed. The communication device includes an operating system.

[0102] The method comprises the steps of: the application receiving a first parameter from the operating system, where the first parameter includes one or more of the following: a temporary identifier, a temporary key, or an access token; and the application sending the first parameter to the operating system when the application is activated or used.

[0103] Based on the solution provided in this application, the first parameter is transmitted, and as a result, the operating system can then verify the application's second application identifier and second application distinction parameter to determine the authenticity or integrity of the application. This reduces or avoids potential security risks that a terminal device may encounter in the root selection process.

[0104] According to the seventh aspect, a communication method is provided. The method may be performed by a communication device, or by a chip or circuit used in a communication device. This is not limited to the present application. For ease of explanation, an example in which the method is performed by a communication device is used below for illustrative purposes.

[0105] The method comprises: a step in which a communication device sends an authentication request message to a user, where the authentication request message includes a second application identifier of the application, and the authentication request message is used to request verification of the second application identifier; a step in which an authentication response message is received from the user, where the authentication response message includes the result of the verification of the second application identifier; and a step in which, based on the authentication response message, it is determined that the application matches the route selection policy rule.

[0106] Based on the solution provided in this application, an authentication request message is sent to the user, requesting the user to verify a second application identifier, and based on the identification information and verification results obtained by the user, it is determined that the application matches the route selection policy rule. This reduces or avoids potential security risks that the terminal device may encounter in the route selection process.

[0107] Optionally, the authentication request message may further include a second application-specific parameter for the application. In this case, the authentication request message is further used to request verification of the second application-specific parameter, and the authentication response message further includes the verification result of the second application-specific parameter. The communication device determines whether the application matches the route selection policy rule based on the application's second application identifier and second application-specific parameter.

[0108] In another implementation, the method comprises: a step of a communication device sending an authentication request message to a user, the authentication request message including a second application identifier of the application, which is used to request that the user determine whether the second application identifier matches a first application identifier in a route selection policy rule; a step of receiving an authentication response message, the authentication response message including the first matching result of the second application identifier and the first application identifier of the user; and a step of determining, based on the authentication response message, that the application matches the route selection policy rule.

[0109] Optionally, the authentication request message may further include a second application distinction parameter for the application, which is used to request a determination of whether the second application distinction parameter matches the first application distinction parameter in the route selection policy rule, and the authentication response message may further include a second matching result between the second application distinction parameter and the first application distinction parameter. Based on the authentication response message, the communication device determines that the application matches the route selection policy rule.

[0110] Based on the solution provided in this application, an authentication request message is sent to the user, requesting the user to determine whether a second application identifier matches a first application identifier and whether a second application distinction parameter matches a first application distinction parameter. Based on the identification and verification results obtained by the user, it is determined that the application matches the route selection policy rule. This reduces or avoids potential security risks that terminal devices may encounter in the route selection process.

[0111] For the beneficial effects of the seventh embodiment and some implementations of the seventh embodiment, please refer to the corresponding description in the first embodiment. Further details will not be explained here.

[0112] According to the eighth aspect, a communication device is provided. The device includes a processing unit configured to determine, upon detecting an application, whether the application matches a route selection policy rule based on the application's second application identifier and second application distinction parameters, wherein the route selection policy rule includes a first application identifier and a first application distinction parameter. The processing unit is further configured to associate the application with a session according to the route selection policy rule.

[0113] The transceiver unit may perform reception and transmission in the first embodiment, and the processing unit may perform processing other than reception and transmission in the first embodiment.

[0114] According to the ninth aspect, a communication device is provided. The device comprises: a processing unit configured to acquire a route selection policy rule, wherein the route selection policy rule includes a first application identifier and a first application distinction parameter; and a transceiver unit configured to transmit the route selection policy rule to the communication device.

[0115] The transceiver unit may perform reception and transmission in the second embodiment, and the processing unit may perform processing other than reception and transmission in the second embodiment.

[0116] According to a tenth aspect, a communication device is provided. The device comprises a processing unit configured to detect an application and determine whether the application matches a route selection policy rule; and a transceiver unit configured to send a request message to a network device, the request message including the application identifier of the application, and the request message is used to request that the network device verify whether the application matches a route selection policy rule. The transceiver unit is further configured to receive a response message from the network device.

[0117] The transceiver unit may perform reception and transmission in a third embodiment, and the processing unit may perform processing other than reception and transmission in a third embodiment.

[0118] According to the eleventh aspect, a communication device is provided. The device comprises: a transceiver unit configured to receive a request message from the communication device, wherein the request message includes an application identifier for an application, and the request message is used to request that the device verify whether the application matches a route selection policy rule; and a processing unit configured to determine whether the application matches a route selection policy rule based on the application identifier in the route selection policy rule and the application identifier for the application. The transceiver unit is further configured to send a response message to the communication device.

[0119] The transceiver unit may perform reception and transmission in the fourth embodiment, and the processing unit may perform processing other than reception and transmission in the fourth embodiment.

[0120] According to the twelfth aspect, a communication device is provided. The device comprises a transceiver unit configured to receive a first parameter from an application, wherein the first parameter includes one or more of the following: a temporary identifier, a temporary key, or an access token; and a processing unit configured to determine a second application identifier and a second application distinction parameter of the application based on the first parameter. The second application identifier and the second application distinction parameter are transmitted to the modem by the operating system. The processing unit is further configured to determine whether the application matches a route selection policy rule based on the second application identifier, the first application identifier in the route selection policy rule, the second application distinction parameter, and the first application distinction parameter in the route selection policy rule.

[0121] The transceiver unit may perform reception and transmission in the fifth embodiment, and the processing unit may perform processing other than reception and transmission in the fifth embodiment.

[0122] According to the 13th aspect, a communication device is provided. The device comprises a transceiver unit configured to receive a first parameter from an operating system, the first parameter including one or more of the following: a temporary identifier, a temporary key, or an access token. The transceiver unit is further configured to send the first parameter to the operating system when an application is activated or used.

[0123] The transceiver unit may perform reception and transmission in the sixth embodiment, and the processing unit may perform processing other than reception and transmission in the sixth embodiment.

[0124] According to the 14th aspect, a communication device is provided. The device comprises a transceiver unit configured to send an authentication request message to a user. The authentication request message includes a second application identifier and a second application distinction parameter for an application, and is used to request the user to verify the second application identifier and the second application distinction parameter, or to determine whether the second application identifier matches a first application identifier in a route selection policy rule, and whether the second application distinction parameter matches a first application distinction parameter in a route selection policy rule. The transceiver unit is further configured to receive an authentication response message from the user. The authentication response message includes the verification result of the second application identifier and the second application distinction parameter, or a first matching result of the second application identifier and the first application identifier, and a second matching result of the second application distinction parameter and the first application distinction parameter. The communication device determining that an application matches a route selection policy rule based on the application's second application identifier and the second application distinction parameter includes the communication device determining that an application matches a route selection policy rule based on the authentication response message.

[0125] The transceiver unit may perform reception and transmission in the seventh embodiment, and the processing unit may perform processing other than reception and transmission in the seventh embodiment.

[0126] According to the 15th aspect, a communication device is provided, including a processor. The processor is coupled to memory, which is configured to store computer programs, and the processor is configured to call computer programs from memory, execute computer programs, and cause the communication device to perform methods in the first aspect and any possible implementation of the first aspect, the third aspect and any possible implementation of the third aspect, the fifth aspect and any possible implementation of the fifth aspect, or the seventh aspect and any possible implementation of the seventh aspect; or cause a network device to perform methods in the second aspect and any possible implementation of the second aspect, or the fourth aspect and any possible implementation of the fourth aspect.

[0127] Optionally, there may be one or more processors and one or more memory.

[0128] Optionally, the memory may be integrated with the processor, or the memory and processor may be arranged separately.

[0129] Optionally, the communication device may further include a transceiver.

[0130] According to the 16th aspect, a communication system is provided, which includes one or more of terminal devices, network devices, operating systems, applications, or modems.

[0131] According to the 17th aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program or code. When the computer program or code is executed on a computer, the computer is made to execute the methods of the first to seventh aspects and any possible implementations of the first to seventh aspects.

[0132] According to the 18th aspect, a chip is provided which includes at least one processor. The at least one processor is coupled to memory, which is configured to store a computer program, and the processor is configured to call the computer program from memory and execute the computer program to cause a terminal device on which the chip system is installed to execute a method in the first aspect and any possible implementation of the first aspect, the third aspect and any possible implementation of the third aspect, the fifth aspect and any possible implementation of the fifth aspect, or the seventh aspect and any possible implementation of the seventh aspect; or cause a network device on which the chip system is installed to execute a method in the second aspect and any possible implementation of the second aspect, or the fourth aspect and any possible implementation of the fourth aspect; or cause an application on which the chip system is installed to execute a method in the third aspect and any possible implementation of the third aspect.

[0133] The chip may include input circuits or interfaces for transmitting information or data, and output circuits or interfaces for receiving information or data.

[0134] According to the 19th aspect, a computer program product is provided. The computer program product includes computer program code, and when the computer program code is executed, methods of the first to seventh aspects and any possible implementations of the first to seventh aspects are performed. [Brief explanation of the drawing]

[0135] [Figure 1] This is a diagram of the network architecture structure according to the embodiment of the present invention.

[0136] [Figure 2] This is a schematic flowchart illustrating how a UE receives a URSP according to an embodiment of the present invention.

[0137] [Figure 3] This is a schematic flowchart of the communication method 300 according to the embodiment of the present invention.

[0138] [Figure 4] This is a schematic flowchart of the communication method 400 according to the embodiment of the present invention.

[0139] [Figure 5] This is a schematic flowchart of the communication method 500 according to the embodiment of the present invention.

[0140] [Figure 6] This is a schematic flowchart of the communication method 600 according to an embodiment of the present invention.

[0141] [Figure 7] This is a schematic flowchart of the communication method 700 according to an embodiment of the present invention.

[0142] [Figure 8] This is a schematic flowchart of the communication method 800 according to an embodiment of the present invention.

[0143] [Figure 9] This is a schematic flowchart of the communication method 900 according to the embodiment of the present invention.

[0144] [Figure 10] This is a schematic flowchart of communication method 1000 according to an embodiment of the present invention.

[0145] [Figure 11] This is a diagram of the structure of the communication device 2000 according to an embodiment of the present invention.

[0146] [Figure 12] This is a diagram of the structure of the communication device 3000 according to an embodiment of the present invention.

[0147] [Figure 13] This is a diagram of the structure of the chip system 4000 according to an embodiment of the present invention. [Modes for carrying out the invention]

[0148] The technical solution of this application will be described below with reference to the attached drawings.

[0149] The technical solutions provided in this application can be applied to various communication systems, such as new radio (NR) systems, long-term evolution (LTE) systems, LTE frequency division duplex (FDD) systems, and LTE time division duplex (TDD) systems. The technical solutions provided in this application can further be applied to device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, machine-to-machine (M2M) communication, machine-type communication (MTC), Internet of Things (IoT) communication systems, or other communication systems.

[0150] In a communication system, the portion operated by an operator may be referred to as a public land mobile network (PLMN), also known as an operator network or similar. A PLMN is a network established and operated by a government or authorized operator to provide terrestrial mobile communication services to the public, and primarily functions as a public network where mobile network operators (MNOs) provide mobile broadband access services to users. The PLMN described in the embodiments of this application may specifically be a network conforming to the requirements of the 3rd generation partnership project (3GPP®) standards, abbreviated as a 3GPP® network. A 3GPP® network typically includes, but is not limited to, other future communication systems such as 5th generation (5G) mobile communication networks, 4th generation (4G) mobile communication networks, and 6th generation (6G) networks.

[0151] For the sake of clarity, PLMN or 5G networks are used as illustrative examples in the embodiments of this application.

[0152] Figure 1 is a diagram of the structure of network architecture 100 according to an embodiment of the present invention. A 5G network architecture based on a service-based architecture (SBA) in a non-roaming scenario as defined in the 3GPP® standardization process is used as an example. As shown in Figure 1, the network architecture may include three parts: the terminal device part, the data network (DN) part, and the operator network (PLMN) part. The functions of the network elements in each part are briefly described below.

[0153] The terminal device portion may include a terminal device 110, which may also be referred to as user equipment (UE). The terminal device 110 in this application is a device having radio transceiver functionality and can communicate with one or more core network (CN) devices through access network devices (which may also be referred to as access devices) in a radio access network (RAN) 120. The terminal device 110 may also be referred to as an access terminal, terminal, subscriber unit, subscriber station, mobile station, mobile console, remote station, remote terminal, mobile device, user terminal, user agent, user equipment, or similar. The terminal device 110 may be deployed on land, including indoor devices, outdoor devices, handheld devices, or vehicle-mounted devices; or on water (e.g., on a ship); or in the air (e.g., on an aircraft, balloon, or satellite). The terminal device 110 may be a cellular phone, cordless phone, session initiation protocol (SIP) phone, smartphone, mobile phone, wireless local loop (WLL) station, personal digital assistant (PDA®), or similar. Alternatively, the terminal device 110 may be a handheld device with wireless communication capabilities, a computing device, another device connected to a wireless modem, an in-vehicle device, a wearable device, an unmanned aerial vehicle device, a terminal in the Internet of Things or Internet of Vehicles, any form of terminal in a 5G network or future networks, relay user equipment, a terminal in a 6G network, or similar. Relay user equipment may be, for example, a 5G residential gateway (RG).For example, terminal device 110 could be a virtual reality (VR) terminal, an augmented reality (AR) terminal, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, or a wireless terminal in a smart home. The terminal device here is a 3GPP® terminal. The types, categories, or similar of terminal devices are not limited to the embodiments of this application. For ease of explanation, examples in this application where UE represents a terminal device are used below.

[0154] The carrier network PLMN portion may include, but is not limited to, the (radio) access network ((R)AN)120 and the core network (CN) portion.

[0155] (R)AN120 can be considered a subnetwork of the carrier network and is an implementation system between service nodes and terminal devices 110 in the carrier network. To access the carrier network, terminal devices 110 can first pass through (R)AN120 and then connect to service nodes in the carrier network through (R)AN120. The access network device (RAN device) in the embodiments of the present application is a device that provides wireless communication functionality to terminal devices 110 and may also be referred to as a network device. RAN devices include, but are not limited to, next-generation node base stations (gNBs) in 5G systems, evolved NodeBs (eNBs) in long-term evolution (LTE), radio network controllers (RNCs), NodeBs (NBs), base station controllers (BSCs), base transceiver stations (BTSs), home base stations (e.g., home evolved NodeBs or home NodeBs, HNBs), baseband units (BBUs), transmitting and receiving points (TRPs), transmitting points (TPs), small cell base station devices (pico), mobile switching centers, network devices in future networks, or similar. In systems using different radio access technologies, devices with access network device functionality may have different names. For the sake of clarity, in all embodiments of this application, the devices that provide wireless communication functionality to the terminal device 110 are collectively referred to as access network devices, or simply as RAN or AN. It should be understood that the specific types of access network devices are not limited herein.

[0156] The CN portion may include, but is not limited to, the following network functions (NF): user plane function (UPF)130, network exposure function (NEF)131, network repository function (NRF)132, policy control function (PCF)133, unified data management (UDM) function134, unified data repository (UDR) function135, application function (AF)136, authentication server function (AUSF)137, access and mobility management function (AMF)138, and session management function (SMF)139.

[0157] The data network DN140, also known as a packet data network (PDN), is typically a network located outside the carrier network, such as a third-party network. Naturally, in some implementations, the DN may be deployed by the carrier, i.e., the DN belongs to the PLMN. Whether the DN belongs to the PLMN is not limited in this application. The carrier network PLMN may access multiple DN140s, multiple services may be deployed on the DN140s, and services such as data services and / or voice services may be provided to terminal devices 110. For example, the DN140 may be a private network of a smart factory, sensors installed in the smart factory's workshops may be terminal devices 110, a sensor control server may be deployed on the DN140, and the control server may provide services to the sensors. The sensors may communicate with the control server to obtain commands from the control server, transmit collected sensor data to the control server according to the commands, and similar actions. In another example, DN140 could be a company's internal network, and a company employee's mobile phone or computer could be a terminal device 110, which can access information, data resources, and similar on the company's internal network. Terminal device 110 can establish a connection to the carrier network through an interface provided by the carrier network (e.g., N1) and can use data services, voice services, and / or similar provided by the carrier network. Terminal device 110 can access DN140 through the carrier network and can use carrier services deployed on DN140 and / or services provided by a third party.

[0158] Below, we will briefly explain the NF function included in CN.

[0159] 1. UPF130 is a gateway provided by the carrier and functions as a gateway for communication between the carrier network and DN140. UPF network functions 130 include user plane-related functions, including data packet routing and transmission, data packet inspection, traffic utilization reporting, quality of service (QoS) processing, lawful interception, uplink data packet detection and downlink data packet storage, and similar functions.

[0160] 2. NEF131 is a control plane function provided by the operator, primarily enabling third parties to use services provided by the network, supporting the network's exposure of network capabilities, events, and data analysis, providing security configuration information for PLMN from external applications, transforming information exchanged internally and externally within PLMN, and similar functions.

[0161] 3. NRF132 is a control plane function provided by the operator and can be configured to maintain real-time information on network functions and services in the network. For example, NRF132 supports network service discovery, maintains services supported by NF configuration data (NF profiles) of NF instances, supports service discovery of service communication proxies (SCPs), maintains SCP configuration data (SCP profiles) of SCP instances, sends notifications about newly registered, deregistered and updated NFs and SCPs, maintains the health status of NFs and SCPs, and does the same.

[0162] 4. PCF133 is a control plane function provided by the operator, and a unified policy framework supports managing network behavior, providing subscription information for policy rules and policy decisions for other control functions, and doing the same.

[0163] 5. UDM 134 is a control plane function provided by the operator and is responsible for storing the subscriber's subscription permanent identifier (SUPI), generic public subscription identifier (GPSI), credentials, and other information of the operator network subscriber. The SUPI is first encrypted during transmission, and the encrypted SUPI is referred to as the subscription concealed identifier (SUCI). The information stored in UDM network function 134 can be used for authentication and authorization when the terminal device 110 accesses the operator network. Specifically, the operator network subscriber may be a user who uses services provided by the operator network, for example, a user who uses a China Telecom subscriber identity module (SIM) card, or a user who uses a China Mobile subscriber identity module card. The subscriber credentials may be a long-term key stored on the subscriber identity module card, or a small file stored thereon, for example, information regarding the encryption of the subscriber identity module card, and are used for authentication and / or authorization. For the sake of clarity, it should be noted that information such as persistent identifiers, credentials, security context, authentication data (cookies), and tokens relating to verification / authentication and authorization are not limited to or distinguished in the embodiments of this application.

[0164] 6. UDR135 is a control plane function provided by the service provider, which provides the UDM with the ability to store and retrieve subscription data, provides the PCF with the ability to store and retrieve policy data, stores and retrieves user NF group ID information, and performs similar functions.

[0165] 7. AF136 is a control plane function provided by the operator, primarily interacting with other NFs in the PLMN to provide corresponding services, such as providing visiting network selection information to roaming UEs, guiding data flow routing, and accessing NEF131. AF can be deployed by the operator either within the PLMN or outside the operator network.

[0166] 8. AUSF 137 is a control plane function provided by the carrier and is typically used for primary authentication, i.e., authentication between the terminal device 110 (subscriber) and the carrier network. After receiving an authentication request initiated by the subscriber, the AUSF network function 137 may perform authentication and / or authorization on the subscriber based on the authentication and / or authorization information stored in the UDM network function 134, or may generate the subscriber's authentication and / or authorization information by using the UDM network function 134. The AUSF network function 137 may feed back the authentication and / or authorization information to the subscriber.

[0167] 9. AMF138 is a control plane network function provided by the carrier network, which is responsible for access control and mobility management when the terminal device 110 accesses the carrier network, and includes functions such as mobility status management, temporary user identity assignment, user authentication and authorization, and similar functions.

[0168] 10. SMF139 is a control plane network function provided by the carrier network and is responsible for managing the protocol data unit (PDU) sessions of the terminal device 110. A PDU session is a channel used to transmit PDUs, and the terminal device and DN140 need to transmit PDUs to each other via the PDU session. SMF network function 139 is responsible for setting up, maintaining, deleting, and similar operations of PDU sessions. SMF network function 139 includes session management (e.g., session setup modification and release, including tunnel maintenance between user plane functions UPF130 and (R)AN120), selection and control of UPF network function 130, service and session continuity (SSC) mode selection, and session-related functions such as roaming.

[0169] The network elements or functions described above can be understood as physical entities in hardware devices, software instances running on dedicated hardware, or virtualization functions instantiated on a shared platform (e.g., a cloud platform). In short, NF can be implemented in hardware or software.

[0170] In Figure 1, Nnef, Nnrf, Npcf, Nudm, Nudr, Naf, Nausf, Namf, Nsmf, N1, N2, N3, N4, and N6 are interface sequence numbers. For example, for the meaning of interface sequence numbers, refer to the meanings defined in the 3GPP® standard protocol. The meaning of interface sequence numbers is not limited in this application. It should be noted that the interface names between network functions in Figure 1 are merely examples. In a specific implementation, the interface names of the system architecture may be alternative names. This is not limited in this application. In addition, the names of messages (or signaling) transmitted between network elements are merely examples and do not constitute any limitation on the function of the message.

[0171] For the sake of clarity, in the embodiments of this application, network functions (such as NEF131, ..., and SMF139) are collectively / simply referred to as NF. In other words, the NF described below in the embodiments of this application can be replaced by any network function. In addition, Figure 1 illustrates only some network functions as examples, and the NF described below is not limited to the network functions shown in Figure 1.

[0172] The network architecture 100 applied to the embodiments of this application is merely a network architecture described in terms of a service-based architecture, and it should be understood that the network architectures applicable to the embodiments of this application are not limited thereto. Any network architecture capable of implementing the functions of the above network elements is applicable to the embodiments of this application. In a service-based architecture, the PLMN can implement customization of network capabilities and services by systematically combining some or all of the necessary network functions based on specific scenario requirements, deploying dedicated networks for different services, i.e., implementing 5G network slicing. Network slicing technology allows operators to respond to customer requirements more flexibly and quickly and supports flexible allocation of network resources.

[0173] Network slicing (abbreviated as slicing) can be understood as dividing an operator's physical network into multiple virtual end-to-end networks, where the virtual networks (including devices, access networks, transport networks, and core networks) are logically independent of each other, preventing a failure in any virtual network from affecting another. To meet diverse requirements and isolation between slices, independent management, operation, and maintenance of services are necessary, and customized service functions and analytical capabilities must be provided. Instances of different service types may be deployed on different network slices, or different instances of the same service type may be deployed on different network slices. A slice may contain groups of NFs and / or subnetworks. For example, a slice may contain subnetworks (R) AN150, AMF137, SMF138, and UPF139 in Figure 1. It should be understood that only one network function of each type is schematically shown in Figure 1. In actual network deployment, there may be multiple or dozens of network functions or subnetworks of each type. Multiple slices may be deployed in a PLMN. All slices may have different performance characteristics to meet the requirements of different applications and vertical industries. Operators may "customize" slices based on the requirements of customers in different vertical industries.

[0174] Typically, the information used to identify a slice is network slice selection assistance information (NSSAI). NSSAI is actually a list or set containing one or more single network slice selection assistance information entries (single NSSAIs, i.e., S-NSSAIs). A single S-NSSAI is used to identify a single network slice; that is, an S-NSSAI can be understood as slice identification information.

[0175] The AMF, SMF, UPF, NEF, AUSF, NRF, PCF, and UDM shown in Figure 1 can be understood as network elements configured to implement different functions in the core network, and it should be further understood that they can be combined as needed to form network slices, for example. The network elements of the core network may be independent devices or integrated into the same device, implementing different functions. The specific form of the network elements is not limited to this invention.

[0176] It should be further understood that the names are defined solely to facilitate the distinction between different functions and should not constitute any limitation to this application. This application does not preclude the possibility that different names may be used in 5G networks and other future networks. For example, in a 6G network, some or all of the network elements may continue to use the terminology used in 5G, or they may use other names or similar terms.

[0177] For the sake of clarity, in the embodiments of this application, the session management function SMF139 is abbreviated as SMF, the terminal device 110 is abbreviated as UE, and the policy control function PCF133 is abbreviated as PCF. In other words, in the embodiments of this application, the SMF described below may be replaced by the session management function, the PCF may be replaced by the policy control function, and the UE may be replaced by the terminal device.

[0178] To facilitate understanding of the technical solution of this application, we will first briefly explain the UE route selection policy (URSP).

[0179] URSP can be pre-configured by the operator at the UE, or it can be dynamically delivered to the UE via PCF. Furthermore, the UE determines the path through which its data traffic is transmitted across the network according to the URSP rules in the URSP. For example, the UE may select a PDU session currently connected to the DN according to the URSP rules and send its data traffic to that session; or the UE may set up a new PDU session in a particular network slice and send its data traffic to that session.

[0180] It should be understood that URSP is typically defined as a list in the standard. A list contains one or more rules, for example, URSP Rule 1 shown in Table 1. Different rules have different priorities and a set of parameters related to route selection. Specifically, one URSP rule contains the following three (or three groups of) parameters: rule precedence, traffic descriptor, and route selection descriptor.

[0181] (1) Rule priority is a single-value parameter that represents the priority level.

[0182] (2) A traffic descriptor is an attribute used to determine traffic and includes one or a set of subparameters: application descriptor, internet protocol (IP) descriptor, domain descriptor, non-IP descriptor, data network name (DN Name, DNN), and connection capabilities. The application descriptor is used to identify the application program and the operating system (OS) of the application program. The OS includes two parameters: operating system ID (OSId) and operating system application ID (OSAppID), which identify the operating system (OS) of the UE running the application program and the application program, respectively. Since the application descriptor is insufficient to uniquely identify the traffic of an application program, it is recommended that other identifying information, such as information about the application program's App Store for installation, be introduced in this application. Typically, application programs released in an application store can be uniquely identified in the application store. It should be noted that the operating system ID (OSId) and operating system application ID (OSAppID) are application descriptors and are used to distinguish different applications. In addition, the operating system ID and operating system application ID are also parameters of the traffic descriptor and can be used to distinguish between different traffic or traffic from different applications. In this application, there is no strict distinction as to whether the operating system ID and operating system application ID are used to distinguish between applications or between application traffic.

[0183] (3) The list of route selection descriptors includes one or more route selection descriptors, each of which may include a route selection descriptor priority, route selection components, and route selection validation criteria. The route selection components may include sub-parameters, such as network slice selection and DNN selection, which define the route (slice, DN, or similar).

[0184] When a UE discovers a new application, or when a UE discovers a new application, the UE evaluates whether the application matches a traffic descriptor in a URSP rule, i.e., determines whether a URSP rule is applicable to or matches the application. For example, a UE may discover an application by using an application discovery filter and identify the packet header or payload of the application traffic data packet. Alternatively, a UE may discover an application based on other methods, and the method by which the UE performs discovery is not limited to the present invention. If an application matches a traffic descriptor, the UE selects the corresponding route selection descriptor in the URSP rule to route the application's traffic. In other words, if the route selection descriptor matches an existing PDU session, the UE may associate the application with the PDU session, i.e., when it determines that a newly discovered application matches a URSP rule, the UE may map the traffic of the newly discovered application to a slice or data network in the URSP rule based on the PDU session. If the route selection descriptor does not match an existing PDU session, the UE attempts to set up a new PDU session that matches the route selection descriptor. In other words, the UE may initiate a procedure to set up a new PDU session on the network side. After the setup of the new PDU session is complete, the UE matches the newly set up PDU session to the root selection descriptor and associates the newly discovered application with the newly set up PDU session. Alternatively, in a PDU session modification procedure, the UE may match the modified PDU session to the root selection descriptor and associate the newly discovered application with the modified PDU session.It should be noted that the manner in which newly detected applications are associated with PDU sessions (e.g., based on existing PDU sessions or newly set up or modified PDU sessions) is not specifically limited in this application.

[0185] For the sake of clarity, unless otherwise specified, communication devices that match newly detected applications to existing PDU sessions, or newly detected applications to newly set up or modified PDU sessions, will be uniformly described below as UEs as associating applications with sessions.

[0186] For example, suppose an application is installed on the UE and its application ID is App1. The operator delivers a URSP to the UE via the PCF, and the URSP contains one URSP rule as shown in Table 1. When the UE runs application App1, the UE triggers the identification of application App1. When the UE correctly identifies that the application ID is App1, the UE can evaluate whether the URSP rule matches the application. From Table 1, it can be seen that application App1 matches the application descriptor = App1 in rule 1. Furthermore, the UE can perform the corresponding route selection for application App1 according to URSP rule 1. For example, the UE maps the traffic for application App1 to the corresponding slice S-NSSAI-1 and data network DNN1. Optionally, if another application, for example an application with ID App2, is further installed on the UE, the operator can deliver a URSP rule 2 corresponding to application App2 to the UE via the PCF. When the UE is running App1 and App2, and the UE determines that App1 matches URSP rule 1 and App2 matches URSP rule 2, the UE may sequentially map the traffic of App1 and the traffic of App2 to their corresponding slices and data networks based on the priority of URSP rule 1 and URSP rule 2. Optionally, if suitable PDU sessions currently exist to connect App1 and App2 to their corresponding slices and data networks, the UE may use existing PDU sessions to carry the traffic of both applications. If suitable PDU sessions currently do not exist to connect App1 and App2 to their corresponding slices and data networks, the UE may use newly set up or modified PDU sessions to carry the traffic of both applications. Table 1 [Table 1]

[0187] Optionally, when an application (for ease of distinction, the application is referred to as the "current application") is newly detected by the UE, the UE evaluates whether the traffic of the current application matches the traffic descriptor in the URSP rule and determines whether to execute the route selection rule in the URSP rule. If the traffic descriptor includes an application descriptor, i.e., includes OSAppID and OSId, the UE retrieves the application ID of the current application (which may be abbreviated as the "current application ID") and compares the application ID of the application included in the URSP rule (for ease of distinction, the application is referred to as the "target application") (which may be abbreviated as the "target application ID") to determine whether the current application ID matches the target application ID.

[0188] Figure 2 is a schematic flowchart illustrating an embodiment of the present invention in which a UE receives a URSP, and is illustrated using an example in which application App1 is installed on the UE. As shown in Figure 2, the internal components of the UE include the OS, App1, and a modem. The modem includes the protocol stack. Intf-1, Intf-3, and Intf-4 represent the interfaces between the OS and App1, the OS and the modem, and the OS and the user using the UE, respectively. The internal structure of the UE shown in Figure 2 should be understood as merely an optional implementation method. This is not specifically limited in the present invention.

[0189] For example, a network PLMN (e.g., PCF) may send a URSP to the UE, and the UE may store the URSP after receiving it. For a specific description of URSPs and URSP rules, see the relevant descriptions above. For example, the URSP shown in Table 1 includes one URSP rule and a corresponding application descriptor which is App1. When the UE runs the current application whose application ID is App1, App1 sends its application ID (i.e., App1) to the OS via interface Intf-1, and the OS then sends the current application ID to the modem via interface Intf-3. Optionally, the method by which the current application sends messages to the OS may be that App1 actively sends its application ID to the OS, or the OS triggers a request message and App1 sends its application ID to the OS based on a response message. This is not specifically limited in this application. After obtaining the current application ID (e.g., App1), the modem may compare the current application ID contained in the stored URSP rule with the target application ID (e.g., App1 shown in Table 1). If the current application ID and the target application ID are the same (e.g., current application ID = App1 = target application ID), the UE may map the traffic of the discovered application App1 to the slice S-NSSAI and data network DNN corresponding to the application descriptor = App1 in the URSP rule.

[0190] The above describes the process by which the UE determines whether a URSP rule matches a newly detected application, that is, whether the target application ID in the URSP rule is the same as the current application ID. Two security risks may exist in this implementation.

[0191] (1) An application with the same application ID as the target application is installed, and the target application is impersonated.

[0192] For applications installed in the Unreal Engine (UE), the application ID is generated by the developer during development. There is no unified specification for naming application IDs, nor is there a unified ID protection mechanism. As a result, it is not guaranteed that application IDs are unique within the same operating system (i.e., the OSId may be the same).

[0193] For example, a newly installed application on a UE is not a target application to be matched in the URSP policy. This is equivalent to the UE installing a "fake" application, but the "fake" application uses the same application ID as the "real" application (i.e., the target application) that is matched and indicated in the URSP. In another example, an attacker could develop a "fake" application and deliberately configure its ID to be identical to the application ID of the "real" application (i.e., the target application). The "fake" application creates a potential security risk to the network using URSP. For example, the network resources of the "real" application may be mistakenly allocated to transmit traffic from the "fake" application. As a result, the network resources of the "real" application may be occupied and consumed, the resources of the "real" application may be compromised, and a denial of service (DoS) attack may occur on the "real" application. Alternatively, the attacker could use this method of spoofing the target application ID to send malicious traffic from the "fake" application to the network node housing the "real" application. As a result, network nodes can be attacked by malicious traffic.

[0194] (2) A forged application ID (identical to the target application ID) is transmitted, and the target application is forged.

[0195] The UE's modem or network layer / network interface layer (abbreviated as "modem") can obtain the application ID by using the UE's OS. For example, the current application sends its application ID (i.e., the current application ID) to the OS, which then sends the current application ID to the modem. The modem then compares the current application ID with the target application ID included in the URSP. A malicious application may send a false application ID to the OS, for example, a false application ID that is identical to the "genuine" target application ID included in the URSP. In this case, the modem considers the detected malicious application's traffic as traffic from the "genuine" application (i.e., the target application ID) and sends the malicious application's traffic to the network. As a result, the network resources of the "genuine" application are compromised, or network nodes are attacked by the malicious traffic.

[0196] In conclusion, the application identification process for UE route selection can be spoofed. As a result, the network resources of the target application are compromised, and a potential security risk exists in network communications.

[0197] In view of this, the present invention provides a communication method and a communication device. An application-distinguishing parameter is introduced into the communication of the communication device, or a verification step is introduced into the network device, so that the communication device and / or the network device can effectively identify or verify in the verification step whether an application matches the route selection policy rule. This ensures that the communication device associates a genuine application with a session in accordance with the route selection policy rule, prevents the network resources of the application in the route selection policy rule from being compromised, and reduces the risk of network nodes being attacked by malicious traffic.

[0198] To facilitate understanding of the embodiments of this application, the following explanation is provided.

[0199] Firstly, in this application, unless otherwise specified or unless a logical contradiction arises, the terminology and / or descriptions in different embodiments are consistent and can be referenced to one another, and the technical features in different embodiments can be combined based on their internal logical relationships to form new embodiments.

[0200] Secondly, in this application, “at least one” means one or more, and “multiple” means two or more. “And / or” describes the relationship between the associated objects and explains that three relationships may exist. For example, A and / or B may represent the following cases: only A exists, both A and B exist, and only B exists, where A and B can be singular or plural. In the description of the text of this application, the letter “ / ” usually indicates an “or” relationship between the associated objects. “At least one of the following items” or similar expressions refer to any combination of these items, including any combination of singular or plural items. For example, at least one of a, b and c may represent: a, b, c, a and b, a and c, b and c, or a, b and c. a, b and c can be singular or plural.

[0201] Thirdly, in this application, "First," "Second," and various numbers (e.g., #1 and #2) indicate distinctions for the sake of clarity, but are not intended to limit the scope of the embodiments of this application. For example, they are intended to distinguish different messages, but not to describe a specific order or sequence. It should be understood that the subjects described in this manner are interchangeable in appropriate contexts, and as a result, solutions other than the embodiments of this application can be described.

[0202] Fourth, in this application, all descriptions such as "when," "in the case," "in the event," and similar phrases mean that the device performs the corresponding process in an objective case, but are not intended to limit the time. The above descriptions do not necessarily mean that the device performs a definitive action during implementation, nor do they imply any other limitations.

[0203] Fifth, in this application, the terms “includes,” “have,” and any derived thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, and may include other steps or units that are not explicitly listed or are specific to the process, method, product, or device.

[0204] Sixth, in this application, “indication” may include direct and indirect indications. When a single piece of indication information is described as indicating A, the indication information may directly or indirectly indicate A, but it does not indicate that the indication information will reliably hold A.

[0205] The instruction methods in the embodiments of this application should be understood to cover a variety of ways that enable the recipient of the instruction to recognize the instruction information. The instruction information may be transmitted as a whole, or it may be divided into multiple sub-informations for separate transmissions. In addition, the transmission cycle and / or transmission opportunities of the sub-informations may be the same or different. Specific transmission methods are not limited in this application.

[0206] In embodiments of the present application, “indicative information” may be explicit indication, specifically direct indication via signaling, or indication obtained based on a parameter indicated by signaling in combination with another rule or parameter, or obtained through inference; or implicit indication, specifically indication obtained based on a rule, relation, or another parameter, or obtained through inference. This is not specifically limited in the present application.

[0207] Seventh, in this application, “protocol” can be a standard protocol in the field of communications, and may include, for example, 5G protocols, NR protocols, and related protocols used in future communications systems. This is not limited to this application. “Predefined” may include being defined in advance, for example, being defined in a protocol. “Preconfigured” may be implemented by pre-storing corresponding codes or corresponding tables in a device, or by another means that can indicate the relevant information. The specific implementation is not limited to this application.

[0208] Eighth, in this application, “storage” may mean storage in one or more memories. One or more memories may be located separately or may be integrated into an encoder, decoder, processor, or communication device. Alternatively, parts of one or more memories may be located separately, and parts of one or more memories may be integrated into a decoder, processor, or communication device. The type of memory may be any form of storage medium; this is not limited in this application.

[0209] Ninth, in this application, “communication” may also be described as “data transmission,” “information transmission,” “data processing,” or similar. “Transmission” includes “transmission” and “reception.”

[0210] Tenth, in this application, the terms “application” and “application traffic” are not strictly distinguished. For example, evaluating whether an “application” matches a traffic descriptor in a route selection policy rule can also be understood as evaluating whether “application traffic” matches a traffic descriptor in a route selection policy rule. Similarly, in this application, there is no strictly distinguished whether a second application distinction parameter is used to distinguish between an “application” and “application traffic.” It should be understood that both are applicable. For example, if a second application distinction parameter is used to distinguish an “application,” it may be classified as a parameter of an application descriptor or an attribute of an application, such as a second application identifier. If a second application distinction parameter is used to distinguish “application traffic,” it may be classified as a parameter of a traffic descriptor or an attribute of traffic. This is not distinguished in this application.

[0211] The communication method provided in the embodiments of the present application will be described in detail below with reference to the accompanying drawings. For example, the communication method may be applied to the communication system shown in Figure 1. In the embodiments of the present application, an application distinguishing parameter (App Distinguisher, AppD) of a newly added application (e.g., App1) is used, along with the application identifier of the application, to uniquely identify or label the application. In addition, the communication device or network device verifies the application identifier or application distinguishing parameter of the application to ensure that the authenticity of the application is effectively identified. This prevents the application from being maliciously tampered with, further prevents the application's network resources in URSP rules from being compromised, and prevents the application from being attacked by malicious traffic.

[0212] For the sake of clarity, in the embodiments of this application, the application distinction parameter in the URSP rule is referred to as the first application distinction parameter, and the application distinction parameter corresponding to the application detected by the communication device is referred to as the second application distinction parameter. Similarly, the application identifier in the URSP rule is referred to as the first application identifier, and the application identifier corresponding to the application detected by the terminal device is referred to as the second application identifier. Relevant parts will not be repeated below.

[0213] Figure 3 is a schematic flowchart of communication method 300 according to an embodiment of the present invention. As shown in Figure 3, the communication device and the network device interact as the implementing entities. This method includes the following steps. For parts not described in detail, please refer to existing protocols. It should be noted that the steps of method 300 may be optional. In other words, when an application is activated or used, or when a communication device detects an application, steps S310 to S340 are not necessarily performed; for example, steps S310 or S320 may be optional. When an application is activated or used multiple times, steps S340 and S340 may be performed, and steps S310 and S320 do not need to be performed repeatedly.

[0214] S310: The network device retrieves the route selection policy rules.

[0215] The route selection policy rule includes a first application identifier and a first application distinction parameter.

[0216] For example, a route selection policy rule includes, but is not limited to, rule priority, traffic descriptors, and a list of route selection descriptors. For the specific meaning of the parameters, please refer to the relevant explanations above. For brevity, we will not go into detail again here.

[0217] For example, the first application identifier of an application may be the application's AppID (e.g., AppID#1), and the first application distinguishing parameter of an application may be AppD (e.g., AppD#1). The first application distinguishing parameter and the first application identifier are used to uniquely identify or label the application. The first application distinguishing parameter includes one or more of the following: the application's installer identifier or the application's binding platform identifier, the application's application program source identifier, the application's installation package name, the application's user identifier, the application's developer identifier, the public land mobile network identifier associated with the application, or the identifier of an application function used to generate route selection policy rules. It should be noted that “identifier” here may be a name, identifier, identity, parameter value, or similar. For example, the binding platform identifier may also be called the binding platform name or binding platform identifier. For ease of explanation, in this application, name, identifier and identity are collectively referred to as identifiers.

[0218] (1) The Installer identifier (Installer) of the application or the identifier of the binding platform of the application. For example, if the application is downloaded and installed from Google Play, the value of the application's Installer parameter is "com.android.vending", meaning the identifier of the application's "installation program" or "binding platform" is Google Play. In another example, if the application is downloaded and installed from Huawei AppGallery, the value of the application's Installer parameter is "com.Huawei.appmarket", meaning the identifier of the application's "installation program" or "binding platform" is Huawei AppGallery.

[0219] (2) An identifier for the application program source of the application. This parameter indicates the source of the application program, and the parameter value is usually "pre-installed" (value is pre-installed), "Google Play" (from Google Play), "unknown" (unknown source), or similar.

[0220] (3) The name of the application's installation package. The name is usually unique within a single platform.

[0221] (4) The application's user ID (App UID). The ID may not be unique within the platform.

[0222] Optionally, the first application-specific parameter may be a 3GPP®-related parameter. For example, the 3GPP®-related parameter may be a PLMN ID, an AF ID, or another parameter defined by any business / service provider.

[0223] Optionally, the first application-specific parameter may be further pre-processed, for example, by performing mapping or masking on the first application-specific parameter to avoid leakage of confidential information in the 3GPP® system.

[0224] S320: The network device sends route selection policy rules to the communication device, and the communication device receives route selection policy rules from the network device.

[0225] For example, a session management function network element sends route selection policy rules to a communication device, or a policy control function network element forwards route selection policy rules to a communication device via a session management function network element. Furthermore, the communication device can determine the path to which the data traffic of an application detected by the communication device is sent, according to the route selection policy rules.

[0226] Optionally, route selection policy rules may be pre-configured by the carrier in the communication equipment.

[0227] S330: When the communication device detects an application, it determines whether the application matches the route selection policy rule based on the application's second application identifier and second application distinction parameters.

[0228] Optionally, the specific implementation of this step may be as follows: The communication device determines whether the application matches a route selection policy rule based on the application's second application identifier and second application distinction parameter; if the application matches a route selection policy rule, it executes step S340; or if the application does not match a route selection policy rule, it skips mapping the detected application to slices and networks in the route selection policy rule. The following describes how it is determined whether the application matches a route selection policy rule.

[0229] In the embodiments of the present invention, the application is a newly detected application by the communication device and corresponds to the current application described above. Subsequently, when it is determined that the application matches the route selection policy rule, it is indicated that the application in the route selection policy rule (i.e., the target application described above) is the same as the application detected by the communication device (i.e., the current application described above).

[0230] When a communication device detects an application, it should be understood that this may mean the communication device has installed or is running the application, or the application is transmitting data, or the communication device has detected the application's data, traffic, or similar. In addition, when a communication device determines that an application matches a route selection policy rule, this may mean that the communication device has determined that the application's secondary application identifier is the same as the primary application identifier in the route selection policy rule, and / or the application's secondary application distinction parameter is the same as the secondary application distinction parameter in the route selection policy rule, and / or other parameters corresponding to the application's data, traffic, and similar (e.g., Internet protocol address (IP Address) and DNN) are the same as the parameters in the route selection policy rule.

[0231] For example, the second application identifier of an application may be the application's AppID (e.g., AppID#2), and the second application distinguishing parameter of an application may be AppD (e.g., AppD#2). The second application distinguishing parameter includes one or more of the following: the application's Installer identifier or the application's binding platform identifier, the application's application program source identifier, the application's installation package name, the application's user identifier, the application's developer identifier, the public land mobile network identifier associated with the application, or the identifier of the application function used to generate route selection policy rules. For specific definitions of the parameters, see the relevant description of the first application distinguishing parameter in step S310. For brevity, further details are not described here. It should be noted that the above parameters are merely examples provided for ease of understanding and should not constitute any limitation to the technical solutions of this application. Parameters that can be used to further distinguish applications are included within the scope of protection of this application.

[0232] In the embodiments of the present application, the number of URSP rules is not limited, and there may be one or more URSP rules. Therefore, in step S320, the communication device may receive one or more URSP rules, for example, URSP rule 1 and URSP rule 2, from the network device. Each URSP rule may correspond to one application, and each URSP rule includes a rule priority, a traffic descriptor, and a list of route selection descriptors.

[0233] In possible implementations, the communication device determines whether an application matches a route selection policy rule based on the application's second application identifier and second application distinction parameters.

[0234] For example, suppose a communication device receives two URSP rules: URSP Rule 1 and URSP Rule 2. The communication device separately determines whether an application matches URSP Rule 1 and URSP Rule 2. For example, the communication device determines whether the first application identifier in URSP Rule 1 is the same as the second application identifier of the detected application, and whether the first application distinction parameter in URSP Rule 1 is the same as the second application distinction parameter of the detected application. Specifically, if the first application identifier in URSP Rule 1 is the same as the second application identifier of the application, and the first application distinction parameter in URSP Rule 1 is the same as the second application distinction parameter of the application, the communication device determines that the application matches URSP Rule 1. Conversely, if the first application identifier in URSP Rule 1 is different from the second application identifier of the application, and / or the first application distinction parameter in URSP Rule 1 is different from the second application distinction parameter of the application, the communication device determines that the application does not match URSP Rule 1. Similarly, the communication device determines whether the first application identifier in URSP Rule 2 is the same as the second application identifier of the application, and whether the first application distinction parameter in URSP Rule 2 is the same as the second application distinction parameter of the application. If the first application identifier in URSP Rule 2 is the same as the second application identifier of the application, and the first application distinction parameter in URSP Rule 2 is the same as the second application distinction parameter of the application, the communication device determines that the application matches URSP Rule 2. Otherwise, the communication device determines that the application does not match URSP Rule 2.

[0235] For example, the modem or operating system of the communication device receives a second application identifier and a second application distinction parameter from the application program, and receives URSP rule 1 from the network device, where URSP rule 1 holds the first application identifier and the first application distinction parameter. Assume that the first application identifier and first application distinction parameter are AppID#1 and AppD#1, and the second application identifier and second application distinction parameter are AppID#2 and AppD#2. The communication device determines whether the application matches the route selection policy rule, i.e., it compares whether AppID#1 is the same as AppID#2 and whether AppD#1 is the same as AppD#2. If AppID#1 = "weixin" and AppID#2 = "QQ", and the two are different, the communication device considers that the application does not match the route selection policy rule. If AppID#1 = AppID#2 = "weixin", the communication device further compares whether AppD#1 is the same as AppD#2. Assume that the application distinction parameter is determined based on the Installer. For example, if the Installer for AppD#1 is "Huawei AppGallery" and the Installer for AppD#2 is "Google Play", these two are different. In this case, the communication device will consider the application not to match the root selection policy rule. In another example, if the Installer for AppD#1 is "Huawei AppGallery" and the Installer for AppD#2 is "Huawei AppGallery", these two are the same. In this case, the communication device will consider the application to match the root selection policy rule and then associate the application with URSP rule 1. It is assumed that the application distinction parameter is determined based on the Installer and application source.For example, the Installer for AppD#1 is "Huawei AppGallery" and the application source is "pre-installed," while the Installer for AppD#2 is "Google Play" and the application source is "unknown." These two are different. In this case, the communication device will consider the application not to match the route selection policy rule. In another example, the Installer for AppD#1 is "Huawei AppGallery" and the application source is "Google Play," while the Installer for AppD#2 is "Huawei AppGallery" and the application source is "Google Play." These two are identical. In this case, the communication device will consider the application to match the route selection policy rule.

[0236] The above is merely an example provided for the sake of clarity and should be understood as not constituting any limitation on the technical solution. In addition, the order of comparison between AppID#1 and AppID#2 and between AppD#1 and AppD#2 is not limited to this embodiment of the present application.

[0237] Optionally, if security measures are applied to the application's AppID#2 and AppD#2 before determining whether the detected application matches the URSP rules, for example, by adding digital signatures, key encryption, or hashing, the communication device may perform integrity verification or authenticity verification on AppID#2 and AppD#2. If the integrity verification or authenticity verification is successful, i.e., if it is determined that AppID#2 and AppD#2 have not been tampered with, the communication device determines, based on AppID#2 and AppD#2, whether the detected application matches the URSP rules. A specific implementation is described above. If the verification fails or is unsuccessful, the communication device does not need to further determine whether the application matches the URSP rules.

[0238] The communication device performing authenticity or integrity verification on AppID#2 and AppD#2 can be understood as the communication device obtaining or determining that the genuine AppID#2 and genuine AppD#2 are real, or performing integrity verification on the application's AppID#2 and AppD#2 to determine whether AppID#2 and AppD#2 have been forged or tampered with.

[0239] It should be noted that authenticity verification or verification of an identifier generally means that the identifier is authenticated or confirmed not to be forged, while integrity verification of an identifier means that the identifier has not been tampered with. Both authenticity verification and integrity verification ensure that the identifier is the genuine identifier for the application. For ease of explanation, unless otherwise specified, authenticity verification and integrity verification are not strictly distinguished in this application.

[0240] The following describes an implementation in which a communication device performs authenticity or integrity verification on a second application identifier and second application distinguishing parameters (e.g., AppID#2 and AppD#2).

[0241] In a certain method, authenticity or completeness verification includes the following two steps:

[0242] (1) The App Store verifies the application (e.g., AppID#2 and AppD#2).

[0243] It should be understood that after application development is complete, the application developer or publisher typically digitally signs and / or secures the integrity of the application program's associated file package (including one or more files) by using the developer's or publisher's private key, and the App Store verifies and / or performs integrity verification on the application program's file package by using the public key corresponding to the private key (i.e., verifies whether the digital signature has been forged or tampered with). The App Store may have the public key stored in advance, or it may obtain the public key by receiving a digital certificate from the application developer or publisher. In the latter case, the App Store further has the ability to verify the certificate issuer. For example, the App Store may have the public key used to verify the certificate issuer in advance and further verify the digital signature of the certificate by using the public key. The methods by which the App Store obtains the public key of the application developer, application publisher, or certificate issuer are not limited in this application.

[0244] For example, an application developer or publisher first performs a hash operation on the application program's file package according to a hash function (also known as a hashing function). For example, the hash function could be HMAC-SHA256. Next, the application developer or publisher encrypts the hash value (also known as a hash value, digest, or digest) generated through the operation using the application developer or publisher's private key, and sends the encrypted ciphertext along with the application program's file package to the App Store. The above process of generating a hash value based on the file package can be concisely referred to as hashing the file package. Hashing may also include the above encryption process. This is not limited to the present invention.

[0245] After receiving the application program's file package and ciphertext, the App Store performs a hash operation on the application program's file package according to the same hash function (e.g., HMAC-SHA256) to obtain a hash value; and then, using the stored / obtained public key, decrypts the received ciphertext to obtain another hash value. The App Store verifies the authenticity or integrity of the application's file package by comparing whether the two hash values ​​are identical, that is, it determines whether the application is from a genuine application developer or publisher (who possesses the corresponding private key and signs the application using that private key).

[0246] It should be noted that the procedure by which the App Store verifies an application by verifying its digital signature is provided merely as an example for ease of understanding and does not constitute any limitation on the technical solution. Optionally, the App Store may have alternative verification methods, for example, based on a hash-based message authentication code (i.e., Hash-based Message Authentication Code: HMAC) or simply based on hashing. For example, an application developer or publisher may perform an operation on the application program's file package using a shared key and an HMAC function to generate a message authentication code (MAC) (the process of generating the message authentication code may also be referred to as hashing the file package, and this is not limited herein), and send the message authentication code along with the application program's file package to the App Store. The App Store performs a hash operation on the application program's file package using the same shared key and HMAC function and compares the result with the received MAC. If the result and the received MAC are identical, the verification of the digital signature and / or integrity of the application program's file package may be deemed successful. The method by which the App Store obtains the shared key is not limited herein. In another example, if a trust relationship is established between the App Store and the application developer, the App Store will, by default, consider the application to be authenticated based on that trust relationship.

[0247] It should be further noted that the verification performed on the target application by the App Store is outside the control of the communication device, i.e., the UE does not perform any additional operations. In this embodiment of the Application, if AppID#1 in the URSP rule includes a parameter related to the App Store (e.g., Installer), the App Store indicated by that parameter may be considered to have verified the target application, or to have established a relationship of trust with the developer or publisher of the target application. By default, the verification in step (1) may be considered to have been performed on the target application. In actual application, a business operator may specify an App Store that is trusted by the business operator based on the parameter related to the App Store in the URSP rule (e.g., Installer), i.e., the App Store verifies the target application by default.

[0248] (2) The OS verifies the application platform / store (App Store).

[0249] The operating system of the communication device may verify the App Store in multiple ways, not limited to those described herein.

[0250] For example, the App Store may be pre-installed on the communication device and verified by default. In another example, the public key used to verify the App Store may be pre-configured on the communication device, or the communication device may obtain the public key from the certificate in the installation package when installing the App Store. The method by which the communication device obtains the App Store's public key is not limited in this application. Optionally, if the communication device further verifies the authenticity of the App Store's certificate, the communication device further obtains the public key of the App Store's certificate issuer and verifies the authenticity of the App Store's certificate by using the certificate issuer's public key. The method by which the UE obtains the public key of the App Store's certificate issuer is also not limited in this application. For specific implementations of how the communication device's OS verifies the App Store, please refer to the relevant description of the digital signature verification process in step (1) above. In other words, the digital signature of the application developer or application publisher in step (1) is replaced by the App Store's digital signature, and the App Store performing the verification in step (1) is replaced by the OS. For brevity, further details will not be explained here.

[0251] In another method, the communication device (or OS) may directly verify the application. For example, the current application's file package includes the application's digital certificate. The digital certificate includes a public key used to verify the application's integrity, information about the certificate authority (CA) issuing the certificate, and the CA's signature on the public key. It should be understood that a prerequisite for using this method is that the communication device trusts the CA or can verify the authenticity of the CA. Furthermore, the communication device may verify the integrity of the file package (including the AppID, or AppID and AppD) by using the application's public key in the certificate. In addition, the communication device may verify the authenticity of the public key by using the information about the CA in the certificate. For specific implementations of the communication device directly verifying the application's digital certificate, please refer to the relevant description of the digital signature verification process in step (1). For brevity, further details will not be provided here. It should be noted that the methods by which the communication device verifies the AppID or AppID and AppD are not specifically limited in this application.

[0252] S340: The communication device associates the application with the session according to the route selection policy rules.

[0253] It should be understood that when a communication device detects a new application, it evaluates whether the application matches a traffic descriptor in a route selection policy rule, that is, it determines whether the route selection policy rule is applicable to or matches the application. If the application matches a traffic descriptor, the communication device selects the corresponding route selection descriptor in the route selection policy rule and routes the application's traffic. In other words, if the route selection descriptor matches an existing PDU session, the UE may associate the application with the PDU session; that is, if the UE determines that a newly discovered application matches a URSP rule, it may map the traffic of the newly discovered application to a slice or data network in the URSP rule based on the PDU session. If the route selection descriptor does not match an existing PDU session, the UE attempts to set up a new PDU session that matches the route selection descriptor. In other words, the UE may initiate the procedure to set up a new PDU session on the network side. After the new PDU session is set up, the UE matches the newly set up PDU session with the route selection descriptor and associates the newly discovered application with the newly set up PDU session. Alternatively, in the PDU session correction procedure, the UE may match the corrected PDU session to a route selection descriptor and associate newly discovered applications with the corrected PDU session. In other words, associating an application with a PDU session may mean that the communication device can determine the path through which the device's data traffic is sent, based on the matched route selection policy rules.For example, a communication device may select an existing session connected to the DNN according to route selection policy rules and send its data traffic; or it may send its data traffic by setting up a new session in a specific network slice.

[0254] In the solution provided in this application, application distinction parameters are introduced into the process of interaction between network devices and communication devices, i.e., newly detected applications by the communication device are further identified and verified, and as a result, in addition to verifying the application identifier, the communication device further verifies the application distinction parameters. This allows for more effective identification or verification of whether an application matches a route selection policy rule. For example, a newly installed application on a communication device is not an application that matches a URSP rule. However, since applications have the same application identifier, a newly installed application may be mistaken for a "real" application, and a "fake" application creates a potential security risk to a network using URSP rules. For example, network resources of a "real" application may be mistakenly allocated to transmit traffic for a "fake" application. As a result, the network resources of the "genuine" application in the route selection policy rules may be occupied and consumed, the resources of the "genuine" application may be compromised, a denial of service (DoS) attack may even occur against the "genuine" application, or an attacker may send malicious traffic from a "fake" application to the network node housing the "genuine" application, and the network node may be attacked by the malicious traffic. Therefore, in this scheme where application distinction parameters are further validated and identified, the risk of the network resources of the application in the route selection policy rules being compromised and the network node being attacked by malicious traffic can be reduced or avoided.

[0255] Figure 4 is a schematic flowchart of a communication method 400 according to an embodiment of the present invention. It should be understood that the communication device includes a modem and an operating system (OS). As shown in Figure 4, the modem and the operating system are used as the implementing bodies for interaction. This method includes the following steps. For parts not described in detail, please refer to existing protocols. It should be understood that the modem may be replaced by another part of the communication device, and this is not limited to the present invention.

[0256] S410: The application sends the first parameter to the operating system, and in response, the operating system receives the first parameter from the application.

[0257] The first parameter includes at least one of the following: a temporary identifier, a temporary key, or an access token.

[0258] For example, when an application is activated or used, the application sends a first parameter to the operating system. Activation or use of an application can be understood as a communication device detecting the application's data or traffic, a communication device detecting that the application is running, or similar.

[0259] Optionally, the operating system generates the first parameter before receiving it from the application and sends the first parameter to the application.

[0260] For example, when the first parameter is a temporary identifier, the operating system stores a mapping relationship. This mapping relationship indicates the relationship between the application's second application identifier, second application distinction parameter, and temporary identifier.

[0261] For example, when the first parameter is a temporary key or access token, the operating system may not store a mapping relationship between the temporary key or access token, the application's second application identifier, and the second application distinguishing parameter. This is because the temporary key or access token holds the application's second application identifier and second application distinguishing parameter. Subsequently, when the operating system receives the temporary key or access token, it may determine the corresponding application's second application identifier and second application distinguishing parameter.

[0262] S420: The operating system determines the second application identifier of the application based on the first parameter.

[0263] For example, the operating system determines the application's second application identifier based on a temporary identifier and mapping relationships.

[0264] For example, the operating system determines the application's secondary application identifier based on a temporary key or access token.

[0265] Optionally, the operating system may further determine a second application-specific parameter based on the first parameter. For example, the operating system may determine that the second application distinguishes application parameters based on temporary identifiers and mapping relationships; or the operating system may determine that the second application distinguishes application parameters based on temporary keys or access tokens.

[0266] S430: The operating system sends the application's second application identifier to the modem, and in response, the modem receives the application's second application identifier from the operating system.

[0267] Optionally, if the operating system further determines a second application distinction parameter based on the first parameter in step S420, the operating system may further send the second application distinction parameter of the application to the modem.

[0268] For example, as shown in Figure 2, the operating system sends the application's second application identifier to the modem via Intf-3. Optionally, the operating system may also send a second application distinction parameter.

[0269] S440: The modem determines that the application matches the route selection policy rule.

[0270] Optionally, the specific implementation of this step could be as follows: the modem determines whether the application matches a route selection policy rule; if the application matches a route selection policy rule, it associates the application with the session according to the route selection policy rule; or, if the application does not match a route selection policy rule, it skips associating the application with the session. The following describes how to determine whether the application matches a route selection policy rule.

[0271] The following is illustrated by an example in which the modem determines whether an application matches a route selection policy rule based on the application's second application identifier and second application distinction parameter. The second application distinction parameter in this implementation is optional; that is, the modem may determine whether an application matches a route selection policy rule based on the application's second application identifier. Details are as follows: It should be noted that the method by which the modem determines whether an application matches a route selection policy rule is the same as in step S330 of method 300 above. Furthermore, after determining that an application matches a route selection policy rule, the modem may associate the application with a session, as shown in step S340. For specific implementations, please refer to the relevant explanations above. For brevity, details will not be explained again here.

[0272] In possible implementations, the modem determines whether an application matches a route selection policy rule based on the application's second application identifier and second application distinction parameters.

[0273] For example, suppose a modem receives a URSP rule (e.g., URSP rule 1). The modem determines whether an application matches URSP rule 1. For example, the modem determines whether a second application identifier is the same as the first application identifier in URSP rule 1, and whether a first application distinguishing parameter in URSP rule 1 is the same as a second application distinguishing parameter. Specifically, if the first application identifier is the same as the second application identifier and the first application distinguishing parameter is the same as the second application distinguishing parameter, the modem determines that the application matches URSP rule 1. Conversely, if the first application identifier is different from the second application identifier, and / or the first application distinguishing parameter is different from the second application distinguishing parameter, the modem determines that the application does not match URSP rule 1.

[0274] Optionally, if security measures are applied to the application's AppID#2 and AppD#2 before determining whether the detected application matches the URSP rules, for example, by adding digital signatures, key encryption, or hashing, the modem may perform integrity verification or authenticity verification on AppID#2 and AppD#2. If the integrity verification or authenticity verification is successful, i.e., if AppID#2 and AppD#2 are determined not to have been tampered with, the modem determines, based on AppID#2 and AppD#2, whether the detected application matches the URSP rules. A specific implementation is described above. If verification fails or is unsuccessful, the modem does not need to further determine whether the application matches the URSP rules.

[0275] Optionally, method 400 may be considered a detailed explanation of step S330, namely, the modem of the communication device determines that the application matches the route selection policy rule based on the application's second application identifier. Step S330 in method 300 may further be implemented by using steps S410 to S490. Therefore, the relevant explanations in method 300 are also applicable to method 400. Identical or similar technical means may exist between the two methods, and similar content will not be explained again here.

[0276] In the solution provided in this application, the operating system assigns a dynamic temporary identifier (or temporary key or access token) to the application, and as a result, when the application is activated or used, it sends the temporary identifier (or temporary key or access token) to the operating system to protect the interaction between the application and the operating system and improve security during parameter transfer.

[0277] Furthermore, this implementation introduces a mapping relationship between temporary identifiers (or temporary keys or access tokens) and application identifiers and application-specific parameters of an application, improving security during parameter transfer and increasing the matching granularity between applications and route selection policy rules. For example, a modem or network layer / network interface layer may obtain a second application identifier from an application by using the operating system. A malicious application may send a false application identifier when interacting with the operating system. If the application identifier of the malicious application received by the modem is identical to the application identifier of the "genuine" application in the URSP rule, the modem may consider the malicious application's traffic as "genuine" application traffic and send the malicious application's traffic to the network. As a result, the network resources of the "genuine" application may be compromised, or network nodes may be attacked by the malicious traffic. In this implementation, a temporary identifier (or temporary key) or access token is introduced that is maintained during the interaction between the application and the operating system. This prevents malicious tampering with the application's second identifier and / or second distinction parameter, ensuring the security of network communications and reducing the risk of the application's network resources being compromised in route selection policy rules and network nodes being attacked by malicious traffic.

[0278] Figure 5 is a schematic flowchart of the communication method 500 according to an embodiment of the present invention. As shown in Figure 5, the method includes the following steps. For parts not described in detail, please refer to existing protocols.

[0279] S510: The communication device sends an authentication request message to the user, and in response, the user receives an authentication request message from the communication device.

[0280] The authentication request message includes the application's secondary application identifier, and is used to request the user to verify the application's secondary application identifier, or to request the user to determine whether the application's secondary application identifier is the same as the first application identifier.

[0281] For example, the operating system of a communication device may trigger a user request to ask the user to identify an application. For instance, the operating system might trigger a pop-up window or send a short message or message to the user, asking the user to determine whether the application's second application identifier is the same as the first application identifier. If the user determines that the application's second application identifier is the same as the first application identifier, the user may tap on the pop-up window to confirm, reply with a short message, or do something similar.

[0282] Optionally, the authentication request message may further include a second application-specific parameter, which may be used to request the user to verify the second application-specific parameter, or to request the user to determine whether the second application-specific parameter is identical to the first application-specific parameter. For specific methods by which the operating system prompts the user to verify the second application-specific parameter, see the relevant explanation above regarding verifying the second application identifier. Further details are not provided here.

[0283] S520: The user sends an authentication response message to the communication device, and in response, the communication device receives an authentication response message from the user.

[0284] The authentication response message includes the verification result of the second application identifier, or the authentication response message includes the first matching result of the second application identifier and the first application identifier of the application.

[0285] Optionally, if the authentication request message further includes a second application differentiation parameter, the authentication response message further includes the verification result of the second application differentiation parameter, or further includes the second matching result of the second application differentiation parameter and the first application differentiation parameter.

[0286] S530: The communication device determines that the application matches the route selection policy rule based on the authentication response message.

[0287] Optionally, the specific implementation of this step may be as follows: The communication device determines whether the application matches the route selection policy rule based on the authentication response message; if the application matches the route selection policy rule, associate the application with the session according to the route selection policy rule; or if the application does not match the route selection policy rule, skip associating the application with the session. Hereinafter, how to determine whether the application matches the route selection policy rule will be described.

[0288] For example, when the verification result indicates that the verification performed by the user on the second application identifier is successful, the communication device determines that the application matches the route selection policy rule. On the contrary, when the verification result indicates that the verification performed by the user on the second application identifier is not successful, that is, when the verification fails, the communication device determines that the application does not match the route selection policy rule.

[0289] If the verification result indicates that the user's optional verification of the second application distinction parameter is successful, the communication device determines that the application matches the route selection policy rule. Conversely, if the verification result indicates that the user's verification of the second application distinction parameter is unsuccessful, i.e., the verification fails, the communication device determines that the application does not match the route selection policy rule.

[0290] For example, if the first matching result indicates that the second application identifier is the same as the first application identifier, the communication device determines that the application matches the route selection policy rule. Conversely, if the first matching result indicates that the second application identifier is different from the first application identifier, i.e., that the verification fails, the communication device determines that the application does not match the route selection policy rule.

[0291] If the second matching result indicates that the second application distinction parameter is identical to the first application distinction parameter, the communication device determines that the application matches the route selection policy rule. Conversely, if the second matching result indicates that the second application distinction parameter is different from the first application distinction parameter, i.e., that the verification fails, the communication device determines that the application does not match the route selection policy rule.

[0292] It should be noted that the above is merely an example provided for ease of understanding. The implementations provided above may be implemented independently or in combination. In other words, the second application identifier and the second application distinguishing parameter may be validated separately or together. When validation of both the second application identifier and the second application distinguishing parameter is successful, the communication device determines that the application matches the route selection policy rule. Conversely, if validation of the second application identifier and / or the second application distinguishing parameter fails, i.e., if the second matching result indicates that the second application distinguishing parameter is different from the first application distinguishing parameter and / or the second application identifier is different from the first application identifier, the communication device determines that the application does not match the route selection policy rule.

[0293] Optionally, method 500 may be considered a detailed explanation of step S330, namely, the communication device determines, based on the user's authentication response message, that the application matches the route selection policy rule. Step S330 in method 300 may further be implemented by using steps S510-S520. Therefore, the relevant explanations in method 300 are also applicable to method 500. Identical or similar technical means may exist between the two methods, and similar content will not be explained again here.

[0294] According to the solution provided in this application, the communication device requests the user to perform authentication and determines whether the application matches the route selection policy rule based on the user's verification result or the first and second matching results. This improves verification flexibility. In addition, a second application distinction parameter is further verified, reducing the risk that the application's network resources in the route selection policy rule may be compromised and that network nodes may be attacked by malicious traffic.

[0295] Figure 6 is a schematic flowchart of communication method 600 according to an embodiment of the present invention. As shown in Figure 6, the communication device and the network device interact as the implementing entity. This method includes the following steps. For parts not described in detail, please refer to the existing protocols and related descriptions in Methods 300 to 500. Details are not described herein. In comparison, in Methods 300 to 500, the communication device (including the modem) determines whether the application matches the route selection policy rule based on the application identifier and application distinction parameters of the application. In Method 600, based on the communication device's determination that the application matches the route selection policy rule, the network device further verifies whether the application matches the route selection policy rule based on the application's second application identifier or the application's second application identifier and second application distinction parameters. More implementations are provided to ensure the authenticity of application identification.

[0296] S610: When the communication device detects an application, it determines that the application matches a route selection policy rule.

[0297] The route selection policy rule includes a first application identifier for the application. For example, referring to the relevant description in an existing solution, the communication device may determine whether an application matches the route selection policy rule, for example, by comparing whether the second application identifier of the detected application is the same as the first application identifier in the URSP rule. For specific implementations, please refer to the relevant description above. Details are not described herein.

[0298] Optionally, the route selection policy rule includes a first application identifier and a first application distinction parameter. For example, referring to the relevant description in step S330 of method 300 above, the communication device may determine whether an application matches the route selection policy rule by comparing, for example, whether the second application identifier of the detected application is the same as the first application identifier in the URSP rule, and whether the second application distinction parameter of the detected application is the same as the first application distinction parameter in the URSP rule. For specific implementations, please refer to the relevant description above. Further details will not be explained here.

[0299] When an application is optionally detected, the communication device determines whether the application matches a route selection policy rule. For further details, please refer to the relevant descriptions in existing solutions, which are not limited to those described herein.

[0300] S620: The communication device sends a request message to the network device, and in response, the network device receives the request message from the communication device.

[0301] The request message includes a second application identifier for the application, and is used to request that the application be verified to determine if it matches a route selection policy rule. Optionally, the request message may further include a route selection policy rule identifier, which is used to identify the route selection policy rule (URSP rule). The representation of the route selection policy rule identifier is not limited herein. For example, the identifier may be the ID of the route selection policy rule or the precedence of the route selection policy rule.

[0302] For example, in the case of a newly detected application by a communication device, the following implementation may determine whether or not to send the application identifier of the application to the network side.

[0303] Optionally, before sending a request message to the network device, the communication device determines, based on the first configuration information, to send a second application identifier to the network device. The first configuration information instructs the network device to send the second application identifier.

[0304] For example, if the first configuration information indicates that the communication device should transmit the application identifier of an application when the AppID#2 of the application detected by the communication device is "weixin", the communication device transmits the application identifier of the application to the network device after detecting that the application is "weixin". Optionally, the first configuration information of the communication device may be for the application ID of a newly detected application (i.e., AppID#2) or for the application ID of an application held in a route selection policy rule (i.e., AppID#1). This is not specifically limited in this application.

[0305] Optionally, the first configuration information is pre-configured in the communication device.

[0306] Optionally, before the communication device sends a request message to the network device, the network device sends first instruction information to the communication device. The first instruction information instructs the communication device to send the application's second application identifier to the network device. In response, the communication device determines, based on the first instruction information, to send the second application identifier to the network device.

[0307] Optionally, the communication device transmits the application identifier of the application to the network side in any case.

[0308] Optionally, the request message further includes second indication information, where the second indication information indicates that the request message holds a second application identifier, or the second indication information instructs the network device to verify whether the application matches the route selection policy rule.

[0309] Optionally, security protection is performed on the second application identifier of the application. For example, the second application identifier on which security protection is performed can be the second application identifier to which a digital signature is added, the second application identifier on which key encryption processing is performed, or the second application identifier on which hash processing is performed.

[0310] Optionally, the request message is a session setup request message or a session modification request message. The session setup request message or the session modification request message holds the identifier of the route selection policy rule verified on the network side and the application identifier of the application, reducing unnecessary procedures and signaling overhead.

[0311] Optionally, the request message further includes the second application differentiation parameter of the application. Further, security protection is performed on the second application differentiation parameter of the application. For example, the second application differentiation parameter of the application on which security protection is performed can be the second application differentiation parameter to which a digital signature is added, the second application differentiation parameter on which key encryption processing is performed, or the second application differentiation parameter on which hash processing is performed.

[0312] Optionally, the communication device determines, based on the second configuration information, to send the second application identifier and second application distinction parameters of the application to the network device, where the second configuration information instructs the network device to send the second application identifier and second application distinction parameters.

[0313] Optionally, the communication device may decide to send a second application identifier and a second distinction parameter to the network device based on third instruction information from the network device, where the third instruction information instructs the network device to send the second application identifier and the second application distinction parameter.

[0314] Optionally, the second configuration information is pre-configured in the communication device.

[0315] Optionally, the request message may further include a fourth directive, which instructs the request message to retain the application's second application identifier and second application distinction parameters, or instructs the network device to verify whether the application matches the route selection policy rules.

[0316] Optionally, the request message may further include authentication information, which is used to verify the authenticity or integrity of the application, and the authentication information is one of the following: a digital signature, a hash value, or a message authentication code.

[0317] Optionally, the application identifier of an application, the application distinction parameter of an application, and the authentication information in the request message may be transmitted in the same message or separately in different messages. This is not limited to the present invention.

[0318] S630: The network device determines whether an application matches a route selection policy rule based on the first application identifier in the route selection policy rule and the second application identifier of the application.

[0319] Optionally, the specific implementation of this step could be as follows: The network device determines whether the application matches the route selection policy rule based on the first and second application identifiers, and then executes step S640. The following describes how it determines whether the application matches the route selection policy rule.

[0320] If a request message optionally does not contain a route selection policy rule identifier, the network device may traverse the locally stored route selection policy rules and compare the first and second application identifiers in each rule. If the first application identifier is the same as the second application identifier, the network device determines that the application matches the route selection policy rule. Conversely, if the first application identifier is different from the second application identifier, the network device determines that the application does not match the route selection policy rule.

[0321] If the request message optionally does not contain a route selection policy rule identifier, the request message can also be understood as the communication device requesting the network device to determine whether the application has a matched route selection policy rule. If the application has a matched route selection policy rule, the application's traffic may be routed to the slice and network associated with the route selection policy rule; otherwise, the communication device's request is rejected.

[0322] If the request message optionally contains a route selection policy rule identifier, the network device determines the route selection policy rule based on the identifier and then compares whether the second application identifier is the same as the first application identifier. Specifically, if the second application identifier is the same as the first application identifier, the network device determines that the application matches the route selection policy rule. Conversely, if the second application identifier is different from the first application identifier, the network device determines that the application does not match the route selection policy rule.

[0323] Optionally, if the request message further includes a second application differentiation parameter for the application, the network device may further determine whether the second application differentiation parameter is identical to the first application differentiation parameter. Specifically, if the first application identifier is identical to the second application identifier and the first application differentiation parameter is identical to the second application differentiation parameter, the network device determines that the application matches the route selection policy rule. Conversely, if the first application identifier is different from the second application identifier and / or the second application differentiation parameter is different from the second application differentiation parameter, the network device determines that the application does not match the route selection policy rule.

[0324] Optionally, when a network device receives a digitally signed or integrity-protected second application identifier, it verifies the digital signature or integrity protection. If the verification is successful, the network device determines whether the application matches the route selection policy rule based on the first application identifier in the route selection policy rule and the received second application identifier. Optionally, the network device determines whether the application matches the route selection policy rule based on the first application distinction parameter in the route selection policy rule and the received second distinction parameter. For specific implementations of determining whether an application matches the route selection policy rule, please refer to the relevant explanations above. Details will not be explained again here. For verification performed by the network device against digital signatures or integrity protection, please refer to existing solutions. For brevity, details will not be explained again here.

[0325] For example, an application's secondary application identifier (e.g., AppID#2 or AppID#2 and the application's secondary application identifier parameter AppD#2) may be held in a digital certificate, which further includes a public key used to verify the digital signature of the application's secondary application identifier. In this case, a network device can verify the digital signature of the application's secondary application identifier by using the public key, thereby ensuring the authenticity of the application's secondary application identifier.

[0326] For example, an application's secondary application identifier (e.g., AppID#2 or AppID#2 and the application's secondary application identifier parameter AppD#2) may be held in an access token, which further includes a digital signature of the application's secondary application identifier. In this case, a network device can verify the digital signature of the application's secondary application identifier to ensure its authenticity.

[0327] For example, an application's second application identifier (e.g., AppID#2 or AppID#2 and the application's second application distinguishing parameter AppD#2) may be stored in the fingerprint information containing the application, which is generated by performing a hash operation on the application's digital certificate. The fingerprint information is used to verify the authenticity of the application.

[0328] Optionally, if the request message further includes a message authentication code, the network device may alternatively verify the integrity protection of the application's second application identifier (e.g., AppID#2 or AppID#2, and the application's second application distinction parameter AppD#2) based on the message authentication code to ensure that the application's second application identifier has not been tampered with. For methods of verifying the integrity protection of the information to be verified based on digital signatures and message authentication codes, see the relevant description of step S530 in Method 500 below. For brevity, further details are not provided here.

[0329] Optionally, the application's second application identifier (e.g., AppID#2 or AppID#2, and the application's second application distinction parameter AppD#2) may be held in the authentication information of a newly discovered application by a communication device, or the application's application identifier may include or be equivalent to the application's authentication information. Typically, authentication information is used to verify the authenticity of an application. It should be understood that the carriers of the application's second application identifier, or other information contained within the application's second application identifier, are not limited in this application.

[0330] If validation fails, it is not subsequently determined whether the application matches the route selection policy rule. When security validation is successful, the network device compares the received second application identifier of the application (e.g., AppID#2 or AppID#2 and the second application distinction parameter AppD#2) with the information about the application contained in the route selection policy rule obtained by the network device (e.g., AppID#1 or AppID#1 and AppD#1) to determine whether the application detected by the communication device matches the route selection policy rule. Specifically, if the second application identifier of the application held in the request message is AppID#2 and AppID#2 = "weixin" = AppID#1, it indicates that the application matches the route selection policy rule. If the second application identifier and second application distinction parameters held in the request message are AppID#2 and AppD#2, and AppID#2 = "weixin" = AppID#1, and AppD#2 ≠ AppD#1 (for example, AppD#2 = "Google Play" and AppD#1 = "unknown"), then it indicates that the application does not match the route selection policy rule.

[0331] S640: The network device sends a response message to the communication device, and the communication device receives the response message from the network device.

[0332] Optionally, the response message may be a session setup response message (including session setup acceptance / rejection messages) or a session modification response message (including session modification acceptance / rejection messages).

[0333] For example, when an application matches a route selection policy rule, the response message instructs the network device to accept the communication device's request. For instance, the second application identifier held in the request message is identical to the first application identifier held in the route selection policy rule; that is, the verification is successful.

[0334] Furthermore, optionally, if the request message includes application-specific parameters for the application, the response message instructs the network device to accept the communication device's request when the application matches the route selection policy rule. For example, the second application-specific parameter held in the request message is identical to the first application-specific parameter held in the route selection policy rule.

[0335] For example, when an application does not match a route selection policy rule, the response message instructs the network device to reject the communication device's request. The response message includes a reason for rejection, which indicates that the application's validation against a second application identifier failed. For example, the second application identifier held in the request message is different from the first application identifier held in the route selection policy rule.

[0336] Optionally, if the request message further includes application-specific parameters for the application, and the application does not match the route selection policy rule, the response message indicates that the network device rejects the communication device's request, and the response message includes a reason for rejection, which indicates that the second application identifier is different from the first application identifier and / or the second application-specific parameter is different from the second application-specific parameter.

[0337] In the solution provided in this application, a step is introduced in which a network device verifies whether an application matches a route selection policy rule, based on the communication device's determination that a detected application matches a route selection policy rule, thereby more effectively ensuring matching between applications and route selection policy rules. For example, a newly installed application on a communication device is not an application that matches a URSP rule. However, since applications have the same application identifier, a newly installed application may be mistaken for a "real" application, and the "fake" application creates a potential security risk to the network using the URSP rule. For example, the network resources of a "real" application may be mistakenly allocated to transmit traffic from a "fake" application. As a result, the network resources of the "real" application in the route selection policy rule may be occupied and consumed, the resources of the "real" application may be compromised, a denial-of-service attack may even occur against the "real" application, or an attacker may send malicious traffic from the "fake" application to a network node housing the "real" application, and the network node may be attacked by the malicious traffic. Therefore, in this scheme, where application-specific parameters are further validated and identified, it prevents the compromise of network resources for applications associated with route selection policy rules and reduces the risk of network nodes being attacked by malicious traffic.

[0338] The following specifically describes the identification of applications for terminal route selection, using an example where the communication device is a UE and the network device is a PCF. For ease of understanding and explanation, the application detected by the UE may be referred to as the “current application,” the application identifier and application distinction parameters of the current application shall be referred to as the second application identifier and second application distinction parameters, and the application associated with the URSP rule, which includes the first application identifier and first application distinction parameters, distributed by the network side shall be referred to as the “target application.” Further details will not be described again below. In this embodiment of the present application, the URSP rule distributed by the network side is integrity protected. In other words, the URSP rule is assumed by default to be tamper-proof. The technical solution of the present application focuses primarily on verifying whether the current application matches the URSP rule, thereby preventing the network resources of the target application from being compromised and reducing the risk of network nodes being attacked by malicious traffic.

[0339] Figure 7 is a schematic flowchart of communication method 700 according to an embodiment of the present application. The method can be considered a detailed description of method 300. It should be understood that the embodiment shown in Figure 7 and the embodiment shown in Figure 3 can be combined with and referenced to one another. Therefore, relevant descriptions in method 300 are also applicable to this implementation. The same or similar technical means may exist between the two methods, and what was described in the embodiment shown in Figure 3 is not described again here. Referring to Figure 2, an example in which the UE includes one current application (e.g., App1) is used for explanation. It should be understood that the number of current applications is not limited in the present application. In this implementation, an application distinction parameter is introduced so that the UE can identify whether the current application matches the URSP rule. As shown in Figure 7, the method includes the following steps. For parts not described in detail, please refer to existing protocols.

[0340] S710:PCF consists of the target application ID (i.e., the first application identifier) ​​and the target application distinction parameter AppD (i.e., the first application distinction parameter). For ease of explanation and distinction, the target application ID and target application distinction parameter of the target application in the URSP rule distributed by the network side are represented by AppID#1 and AppD#1, respectively. Correspondingly, the current application ID (i.e., the second application identifier) ​​and current application distinction parameter (i.e., the second application distinction parameter) of the current application received from the OS (i.e., the application discovered by the UE) are represented by AppID#2 and AppD#2, respectively. Further details will not be explained below.

[0341] The target application distinguishing parameter AppD#1 should be understood as a parameter used to determine or distinguish a target application. The name of the target application distinguishing parameter is merely an example, and the target application distinguishing parameter may also be called target application specific information or similar. This is not specifically limited in this application.

[0342] AppD#1 and AppD#2 may be represented in the form of Installer, application source, package name, 3GPP® related parameters, or similar. For specific meanings, please refer to the relevant explanation in step S330. For brevity, further details will not be explained here.

[0343] S720: The PCF sends the URSP rule to the UE. In response, the UE receives the URSP rule from the PCF.

[0344] Optionally, the PCF sends URSP rules to the UE via the AMF or SMF.

[0345] The URSP rule includes AppID#1 and AppD#1. For specific details on other contents, other uses, alternative configurations, and similar aspects of the URSP rule, please refer to the relevant explanation in Method 300. For brevity, further details will not be provided here.

[0346] S730:UE determines whether the current application matches the URSP rule based on the current application ID and current application distinction parameters.

[0347] Optionally, the specific implementation of this step could be as follows: The network device determines whether the application matches a route selection policy rule based on the current application ID and current application distinction parameters; if the application matches a route selection policy rule, it associates the application with the session according to the route selection policy rule; or, if the application does not match a route selection policy rule, it skips associating the application with the session. The following describes how it determines whether the application matches a route selection policy rule.

[0348] For example, the UE compares whether the current application ID is the same as the target application ID and whether the current application differentiation parameters are the same as the target application differentiation parameters. Specifically, if the current application ID is the same as the target application ID and the current application differentiation parameters are the same as the target application differentiation parameters, the UE determines that the current application matches the URSP rule. Conversely, if the current application ID is different from the target application ID and / or the current application differentiation parameters are different from the target application differentiation parameters, the UE determines that the current application does not match the URSP rule.

[0349] For example, the UE's modem receives AppID#2 and AppD#2 from application App1 and the URSP rule from the PCF. The URSP rule holds AppID#1 and AppD#1. Specifically, determining whether the current application matches the URSP rule involves comparing whether AppID#1 is the same as AppID#2, and whether AppD#1 is the same as AppD#2. If AppID#1 = "weixin" and AppID#2 = "QQ" and the two are different, the UE considers the current application not to match the URSP rule. If AppID#1 = AppID#2 = "weixin", then it further compares whether AppD#1 is the same as AppD#2. It is assumed that the application distinction parameter is determined based on the Installer. For example, if the Installer of AppD#1 is "Huawei AppGallery" and the Installer of AppD#2 is "Google Play", and the two are different, in this case the UE considers the current application not to match the URSP rule. In another example, the Installer for AppD#1 is "Huawei AppGallery" and the Installer for AppD#2 is "Huawei AppGallery," and these two are identical. In this case, the UE assumes that the current application matches the URSP rule and then executes the route selection rule in the URSP rule associated with App1. The above is merely an example provided for ease of understanding and should not be understood as constituting any limitation on the technical solution. In addition, the order of comparison between AppID#1 and AppID#2, and between AppD#1 and AppD#2, is not limited in this application.

[0350] Optionally, before determining whether the current application matches a URSP rule, the UE first verifies the authenticity or integrity of AppID#2 and AppD#2 to determine if they have been forged or tampered with. If the verification is successful, i.e., if AppID#2 and AppD#2 have not been forged or tampered with, the UE determines whether the current application matches a URSP rule. If the verification fails or is unsuccessful, the UE does not need to further determine whether the current application matches a URSP rule.

[0351] For authenticity or integrity verification of AppID#2 and AppD#2, please refer to the relevant explanation in step S330 of Method 300 above. For brevity, details will not be explained again here. Furthermore, if the verification is successful, the UE determines whether the current application matches the URSP rule. For the specific determination method, please refer to the relevant explanation above. For brevity, details will not be explained again here.

[0352] In the solution provided herein, the introduction of the application identification parameter AppD results in the addition of a parameter for the UE to identify and verify whether the current application matches the URSP rule. This improves application identification security.

[0353] In method 700 described above, the UE identifies and verifies whether the current application matches the URSP rule, but it may not detect if the current application ID has been maliciously tampered with by an attacker. Therefore, the following method 800 is proposed: When the communication device determines that the current application matches the URSP rule, the network side further identifies and verifies whether the current application matches the URSP rule to ensure the security of the route selection performed by the terminal.

[0354] Figure 8 is a schematic flowchart of communication method 800 according to an embodiment of the present application. The method can be considered a detailed description of method 600. It should be understood that the embodiment shown in Figure 8 and the embodiment shown in Figure 6 can be combined and referenced to one another. Therefore, the relevant descriptions in method 600 are also applicable to this implementation. The same or similar technical means may exist between the two methods, and what is described in the embodiment shown in Figure 6 is not described again here. Referring to Figure 2, an example in which the UE includes one current application (e.g., App1) is used for illustrative purposes. It should be understood that the number of current applications is not limited in this application. In this implementation, interaction and verification of information to be verified (e.g., AppID, or AppID and AppD) are introduced so that the network side can identify whether the current application matches the URSP rule. As shown in Figure 8, the method comprises the following steps. For parts not described in detail, please refer to existing protocols.

[0355] S810:PCF constitutes the target application ID (AppID).

[0356] Optionally, the PCF may further constitute the target application distinction parameter AppD. For specific implementations, please refer to the relevant explanation in step S510 of Method 700. For brevity, further details will not be explained here.

[0357] S820: The PCF sends a URSP rule to the UE. In response, the UE receives a URSP rule from the PCF.

[0358] For example, PCF sends URSP rules to UE via AMF or SMF. URSP rules include AppID, or URSP rules include AppID and AppD.

[0359] S830:UE determines, based on the current application ID, whether the current application matches the URSP rule.

[0360] For example, when the UE detects the current application, it compares whether the target application ID is the same as the current application ID, that is, whether AppID#1 is the same as AppID#2. Specifically, if the current application ID is the same as the target application ID, the UE determines that the current application matches the URSP rule. Conversely, if the current application ID is different from the target application ID, the UE determines that the current application does not match the URSP rule.

[0361] Optionally, if the URSP rule includes a target application distinguishing parameter, the UE may further compare whether the current application distinguishing parameter is identical to the target application distinguishing parameter, i.e., whether AppD#1 is identical to AppD#2. Specifically, if the current application ID is identical to the target application ID and the current application distinguishing parameter is identical to the target application distinguishing parameter, the UE determines that the current application matches the URSP rule. Conversely, if the current application ID is different from the target application ID and / or the current application distinguishing parameter is different from the target application distinguishing parameter, the UE determines that the current application does not match the URSP rule.

[0362] For specific implementations of steps S810-S830 and other contents, other uses, alternative configurations, and similar aspects included in the URSP rules, please refer to the relevant explanations in Figure 7. For brevity, further details will not be explained here.

[0363] S840: Optionally, the UE decides whether to send the information to be verified to the network side.

[0364] The information to be verified includes the AppID#2 of the current application, or the information to be verified includes both the AppID#2 and AppD#2 of the current application.

[0365] Optionally, the information to be validated includes the identifier of the URSP rule, which allows the network device to quickly determine the route selection policy rule and then determine whether the application matches the route selection policy rule.

[0366] For example, for a newly detected current application by the UE, the following implementations may determine whether to send the verification information to the network side (e.g., PCF).

[0367] (1) Default transmission: In all cases, the UE will send the information to be verified to the network side.

[0368] (2) UE configuration information (i.e., first configuration information): Based on the configuration information, the UE determines whether to send the information to be verified to the network side. For example, if the first configuration information indicates that the information to be verified should be sent when the AppID#2 of the current application detected by the UE is "weixin", the UE sends the information to be verified to the PCF after newly detecting that the current application is "weixin", i.e., executes step S850. Conversely, if the first configuration information indicates that the information to be verified does not need to be sent when the AppID#2 of the current application detected by the UE is not "weixin", the UE does not need to execute the subsequent step S850.

[0369] (3) Network Instructions (i.e., First Instruction Information): The UE further determines whether to send the information to be verified to the network based on instructions delivered by the network. Optionally, in step S820, the URSP rule additionally holds instruction information #1 (i.e., First Instruction Information), which instructs the UE to send the information to be verified to the network when the application identifier of the current application discovered by the UE is AppID#2.

[0370] Optionally, if in step S820 the URSP rule further includes the target application distinction parameter AppD#1, instruction information #1 further indicates that the UE should send the information to be verified to the network side when the application identifier of the current application detected by the UE is AppID#2 and the application distinction parameter of the current application is AppD#2.

[0371] It should be noted that the above implementations are merely examples provided for ease of understanding and should not constitute any limitation on the technical solutions of this application. Optionally, the UE may further limit the transmission of the verification information to the network for the three implementations described above. In other words, the UE may determine whether to transmit the verification information to the network based on one or more of the following: specific application parameters (e.g., the application ID is a specific ID such as "weixin"), specific slice information (e.g., the slice selection assistance information is S-NSSAI-1), and specific DNs (e.g., the DN name is DNN1).

[0372] For example, the ID of the current application detected by the UE is "weixin," and in step S830, the UE evaluates that the URSP rule matches the current application (for example, the matched target application ID is "weixin"). Furthermore, based on configuration information or network instructions, the UE may determine that the verification information for the current application with the ID "weixin" needs to be sent to the network side, and then execute step S850.

[0373] In another example, the slice that the current application, as detected by the UE, requests to use is S-NSSAI-1, and in step S830, the UE evaluates that the URSP rule matches the current application (for example, the matched slice is selected as S-NSSAI-1). Furthermore, based on configuration information or network instructions, the UE may determine that the verification information for the current application using slice S-NSSAI-1 needs to be sent to the network side, and then perform step S850.

[0374] In another example, the data network that the current application, as detected by the UE, requests to access is DNN1, and in step S830, the UE evaluates that the URSP rule matches the current application (for example, the matching DNN is selected as DNN1). Furthermore, based on configuration information or network instructions, the UE may determine that the verification information for the current application using DNN1 needs to be sent to the network side, and then perform step S850.

[0375] Optionally, the information to be verified is held in the authentication credentials, which are used to verify the authenticity or integrity of the current (untampered) application, and the authentication credentials include one or more of the following: a digital signature, a hash value, or a message authentication code.

[0376] Optionally, the UE uses authentication information as the information to be verified. In other words, the UE sends authentication information to the PCF. Authentication information includes, but is not limited to, the digital signature of the current application, the hash value of the current application, the MAC address of the current application, or similar. Optionally, the authentication information holds AppID#2, or holds AppID#2 and AppD#2. Optionally, the UE obtains authentication information by using the OS. It should be understood that the method by which the UE obtains the information to be verified is not specifically limited in this application.

[0377] Optionally, the UE determines whether to send instruction information #2 (i.e., second instruction information) to the network side. For a specific definition of instruction information #2, please refer to the relevant explanation in step S850. Further details are not provided herein.

[0378] S850: The UE sends a PDU session setup / modification request message (i.e., a request message) to the SMF. In response, the SMF receives a PDU session setup / modification request message from the UE.

[0379] The PDU session setup / modification request message includes information to be verified.

[0380] Optionally, the UE sends a PDU session setup / modification request message to the SMF. Furthermore, the SMF forwards the information to be verified in the PDU session setup / modification request message to the PCF, and as a result, the PCF verifies the information to be verified in step S870. In other words, in step S870, if the PCF performs verification, the SMF must send the information to be verified to the PCF; or if the SMF performs verification, the SMF may not send the information to be verified to the PCF. For the sake of clarity, the SMF and PCF are not specifically distinguished in the following steps.

[0381] Optionally, a PDU session setup / modification request message may further include instruction information #2, which may instruct the PDU session setup / modification request message to hold the information to be verified, or may instruct the network-side PCF (or SMF) to verify the information to be verified.

[0382] S860: The PCF (or SMF) verifies the information to be validated, that is, it verifies whether the current application matches the routing selection policy rule. A specific implementation of this step may be as follows: Based on the information to be validated, the PCF determines whether the application matches the route selection policy rule and executes step S870. The following describes how it determines whether the application matches the route selection policy rule.

[0383] For example, PCF (or SMF) may determine, based on the received instruction information #2, whether the information to be verified needs to be verified. This implementation allows for better backward compatibility.

[0384] For example, the information to be verified (e.g., AppID#2, or AppID#2 and AppD#2) may be held in a digital certificate, which further includes a public key used to verify the digital signature of the information to be verified. In this case, the PCF (or SMF) can verify the digital signature of the information to be verified by using the public key, thereby ensuring the authenticity of the information to be verified.

[0385] For example, the information to be verified (e.g., AppID#2, or AppID#2 and AppID#2) may be held in an access token, which further includes a digital signature of the information to be verified. In this case, the PCF (or SMF) can verify the digital signature of the information to be verified to ensure its authenticity.

[0386] For example, the information to be verified (e.g., AppID#2, or AppID#2 and AppD#2) may be held in fingerprint information containing the current application, for example, the fingerprint information is generated by performing a hash operation on the current application's digital certificate. The fingerprint information is used to verify the authenticity of the application.

[0387] Optionally, if the information to be verified also includes a message authentication code, the PCF (or SMF) may alternatively verify the integrity protection of the information to be verified based on the message authentication code to ensure that the information to be verified has not been tampered with. For methods of verifying the integrity protection of the information to be verified based on digital signatures and message authentication codes, see the relevant explanation in step S530. For brevity, further details will not be provided here.

[0388] Optionally, the information to be verified may be held in the current application's credentials, or the information to be verified may include or be equivalent to the current application's credentials. Typically, credentials are used to verify the authenticity of the current application. It should be understood that the carrier of the information to be verified, or the information contained in the information to be verified, is not limited in this application.

[0389] If the validation fails, it is not determined whether the current application matches the URSP rule; in other words, step S870 is executed. If the validation is successful, the PCF (or SMF) compares the information to be validated (e.g., AppID#2, or AppID#2 and AppD#2) with the information about the target application contained in the locally stored URSP rule (e.g., AppID#1, or AppID#1 and AppD#1) to determine whether the current application detected by the UE matches the URSP rule. Specifically, if the information to be validated is AppID#2 and AppID#2 = "weixin" = AppID#1, this indicates that the current application matches the URSP rule. If the information being validated is AppID#2 and AppD#2, and AppID#2 = "weixin" = AppID#1, and AppD#2 ≠ AppD#1 (for example, AppD#2 = "Google Play" and AppD#1 = "unknown"), then this indicates that the current application does not fully match the URSP rule.

[0390] S870: The SMF sends a PDU session setup / correction response message (i.e., a response message) to the UE. In response, the UE receives a PDU session setup / correction response message from the SMF.

[0391] For example, a session setup response message includes a session setup acceptance / rejection message, and a session modification response message includes a session modification acceptance / rejection message. If the verification of the information to be verified in step S860 is unsuccessful or fails, for example, if the verification of the authenticity or completeness of the current application is unsuccessful and / or the current application does not match the URSP rule, for example, if the application identifier of the current application is different from the application identifier of the target application in the URSP rule and / or the application distinction parameter of the current application is different from the application distinction parameter of the target application in the URSP rule, the SMF may reject the UE's PDU session setup / modification request in step S850. Optionally, the PDU session setup / modification response message may contain the reason for rejection, for example, if the verification of the information to be verified fails.

[0392] For example, if the verification of the information to be verified in step S860 is successful, the SMF accepts the UE's PDU session setup / modification request in step S850.

[0393] It should be noted that when the PCF verifies the information to be verified in step S860, the PCF then needs to send the verification result (e.g., verification successful or verification failed) to the SMF, which then sends the verification result to the UE based on the PDU session setup / correction response message.

[0394] According to the solution provided in this application, the information to be verified is newly introduced into the existing PDU session request, resulting in no need to add new procedures and reducing step and signaling overhead. In addition, the network side verifies whether the current application matches the URSP rule, reducing computational complexity on the UE side and improving the user experience.

[0395] In methods 700 and 800 described above, an application distinction parameter is added, and it should be understood that as a result, the UE determines whether the current application matches the URSP rule. In addition, when the UE verifies that the application matches the route selection policy, the network device further performs a verification step to reduce the risk of the target application's network resources being compromised and attacked. Furthermore, when the current application is executed within or transferred to the UE, the application ID may be spoofed. As a result, the UE's modem may send traffic from a malicious application to the network as traffic from the target application, the target application's network resources may be compromised, or network nodes may be attacked by malicious traffic. Therefore, methods 900 and 1000 are proposed below: The OS or user verifies the current application to ensure that information about the current application has not been tampered with during transmission, thereby avoiding potential risks and ensuring network security.

[0396] Figure 9 is a schematic flowchart of communication method 900 according to an embodiment of the present application. The method can be considered a further detailed description of method 400. It should be understood that the embodiment shown in Figure 9 and the embodiment shown in Figure 4 can be combined with each other and referenced to one another. Therefore, the relevant descriptions in method 400 are also applicable to this implementation. The same or similar technical means may exist between the two methods, and what is described in the embodiment shown in Figure 4 is not described again here. Referring to Figure 2, an example in which the UE includes one current application (e.g., App1) is used for illustrative purposes. It should be understood that the number of current applications is not limited in this application. In this implementation, the OS performs security protection and security verification on the information exchanged through the OS interface to avoid the security risk of a spoofed application ID. As shown in Figure 9, the method comprises the following steps. For parts not described in detail, please refer to existing protocols.

[0397] Follow the installation instructions for S910:App1.

[0398] Optionally, App1 can be an application executed by the UE or a new application discovered by the UE.

[0399] For example, when an application is installed, the UE's OS verifies the application developer's or publisher's certificate, or verifies the application based on the App Store (see the relevant explanation in step S330 for specific implementations) to ensure that App1 is not tampered with during installation. For the installation procedure of App1, please refer to the existing application installation procedure. For brevity, the details will not be explained again here. Assume that the OS can distinguish between different installed applications. For example, different installed applications are distinguished based on different application IDs. In other words, the OS can identify App1 based on its original ID (for example, the original ID of App1 may be abbreviated as original ID1). Alternatively, see method 500 above. The OS can distinguish between applications based on different application IDs and application distinction parameter AppD. In other words, the OS can identify App1 based on its original ID and AppD (for example, the application distinction parameter AppD of App1 may be abbreviated as AppD1).

[0400] S920: The OS generates temporary ID1 for App1.

[0401] Furthermore, the OS stores the mapping relationship between App1's original ID1 and temporary ID1. Optionally, if the application distinction parameter AppD is further configured for the current application, the OS stores the mapping relationship between App1's original ID1, AppD1, and temporary ID1.

[0402] S930: The OS sends temporary ID1 to App1. In response, App1 receives temporary ID1 from the OS.

[0403] Steps S710 to S730 described above are a solution by which the OS assigns a temporary ID to the current application. When the user decides to trigger or activate the application, the subsequent steps S740 to S780 are performed, and this is illustrated by using an example in which App1 is used to request that data be transmitted by using a modem or network when App1 is activated or used.

[0404] S940: Optionally, App1 triggers the activation.

[0405] S950: App1 sends temporary ID1 to the OS. In response, the OS receives temporary ID1 from App1.

[0406] Optionally, App1 sends the original ID1 to the OS.

[0407] S960: The OS determines the original ID of application App1 based on the stored mapping relationship between temporary ID1 and the original ID1 of App1 and temporary ID1.

[0408] If the OS optionally stores the mapping relationship between the original ID1, AppD1, and temporary ID1 of App1 in step S910, the OS may further determine the AppD1 of App1 in step S960.

[0409] S970: The OS sends the original ID1 of App1 to the modem. Correspondingly, the modem receives the original ID1 of App1 from the OS.

[0410] Optionally, the OS sends application-specific parameters AppD1 and another parameter for App1 to the modem.

[0411] S980: The modem determines the matched URSP rule based on the original ID1 of App1.

[0412] Optionally, the specific implementation of this step could be as follows: The modem determines, based on the original ID1 of App1, whether the application matches a route selection policy rule; if the application matches a route selection policy rule, associate the application with the session according to the route selection policy rule; or, if the application does not match a route selection policy rule, skip associating the application with the session. The following describes how it determines whether the application matches a route selection policy rule.

[0413] Optionally, the modem determines the matched URSP rule based on the original ID1 and AppD1 of App1.

[0414] For example, after obtaining the original ID1 of App1, the modem may compare the original ID1 with the target application ID (or the target application ID and the target application distinction parameter AppD) in the locally stored URSP rule. If the original ID1 is the same as the target application ID (for example, the original ID1 of App1 = the ID of target application App1, and AppD1 = the AppD of target application App1), the modem may determine to execute the route selection rule corresponding to App1 in the URSP rule.

[0415] Optionally, in method 900, the risk of a spoofed application ID is reduced based on a temporary ID generated by the OS. Further implementations may be used in the present application to reduce the risk of a malicious application spoofing the ID of another application.

[0416] In implementation, the UE verifies the current application based on the access token (token). Specifically, the OS generates token#1 for App1, where the claim in the token may include the application ID of App1 (or the application ID of App1 and the application distinction parameter AppD); and sends token#1 to App1. The difference between using a temporary ID and using a token is that the OS does not need to store a mapping relationship between the original ID1 of App1 and token#1. If the example of application App1 being activated / used is still used in step S740, the temporary ID1 in step S750 is replaced with token#1. Correspondingly, in step S760, the OS verifies the integrity and authenticity of token#1 based on the digital signature held in token#1. If the integrity and authenticity verification is successful, the UE determines the original ID1 of App1 (or the original ID1 of App1 and AppD1) based on the claim in token#1, and then determines the matched URSP rule based on the original ID1 of App1 (or the original ID1 of App1 and AppD1). For specific implementations, please refer to the relevant explanation of Method 200 above. For brevity, further details will not be explained here.

[0417] In another implementation, the UE verifies the current application based on the secure channel. Specifically, the OS generates a temporary key (e.g., key#1) for App1 and sends the temporary key key#1 to App1. The difference between using a temporary ID and using a temporary key is that the OS does not need to store the mapping relationship between App1's original ID1 and key#1. If the example of App1 being activated / used is still used in step S740, App1 can use key#1 to ensure the integrity of App1's original ID1 (or App1's original ID1 and AppD1). Correspondingly, in step S780, if the verification for integrity protection is successful or decryption is successful, the OS retrieves App1's original ID1 (or App1's original ID1 and AppD1) and further determines the matched URSP rule based on App1's original ID1 (or App1's original ID1 and AppD1). For specific implementations, see the relevant explanation in Method 200. For the sake of brevity, I will not go into detail again here.

[0418] In the solution provided in this application, the OS identifies and verifies the application (e.g., App1) based on a dynamic temporary ID (or token, temporary key, or similar) to protect the interaction between the application and the OS (e.g., through interface Intf-1) and prevent malicious impersonation of the application's (e.g., App1) temporary ID (or token, temporary key, or similar). This further reduces the risk of App1 being impersonated or attacked. This is because it is difficult for a malicious application to predict and impersonate the temporary ID (or token, temporary key, or similar) of another application during the development phase. When a malicious application is executed, it needs to have the ability to dynamically obtain the temporary ID (or token, temporary key, or similar) of another application for impersonation, and this ability usually requires the destruction of the UE's operating system OS. This application is primarily about malicious applications, not scenarios where the OS is destroyed. Therefore, the modem trusts the OS verification result, i.e., security protection is provided between the modem and the OS, and the OS is not destroyed.

[0419] Based on method 900 above, the OS identifies and verifies the application based on a dynamic temporary identity (or token, temporary key, or similar) to protect the interaction between the application and the OS. In contrast, method 1000 below relies on the user to identify and verify the application to mitigate the security risks of a forged application identity.

[0420] Figure 10 is a schematic flowchart of communication method 1000 according to an embodiment of the present application. The method may be considered a detailed description of method 500. It should be understood that the embodiment shown in Figure 10 and the embodiment shown in Figure 5 can be combined with and referenced to one another. Therefore, the relevant descriptions in method 500 are also applicable to this implementation. The same or similar technical means may exist between the two methods, and what is described in the embodiment shown in Figure 5 is not described again here. Referring to Figure 2, an example in which the UE includes one current application (e.g., App1) is used for explanation. It should be understood that the number of current applications is not limited in this application. As shown in Figure 8, the method comprises the following steps. For parts not described in detail, please refer to existing protocols.

[0421] Perform the installation procedure for S1010:App1.

[0422] S1020: App1 optionally triggers activation.

[0423] For specific implementations of steps S1010 and S1020, please refer to the relevant explanations of steps S710-S740 in Method 700. For brevity, further details will not be explained here.

[0424] S1030: App1 sends the original ID1 to the OS. In response, the OS receives the original ID1 from App1.

[0425] Optionally, App1 sends the application identification parameter AppD1 to the OS.

[0426] S1040: The OS sends an authentication request message to the user. In response, the user receives an authentication request message from the OS.

[0427] S1050: The user sends an authentication response message to the OS. In response, the OS receives an authentication response message from the user.

[0428] For example, the OS may trigger a user request to ask the user to identify an application. For example, the OS may trigger a pop-up window asking the user to determine whether the current application is App1, or whether the application ID of App1 is AppID#1. If the user determines that the application ID of App1 is AppID#1, the user can tap on the pop-up window to confirm. Optionally, the user request may further be used to ask the user to determine whether the application distinction parameter of the current application is AppD1. Furthermore, if the user determines that the current application is App1 (for example, the application ID of App1 is AppID#1, or the application ID of App1 is AppID#1 and the application distinction parameter of App1 is AppD1), the authentication response message will hold a verification result indicating that user verification for AppID#1 was successful, or that user verification for AppID#1 and AppD1 was successful. Optionally, the authentication response message may contain "yes" or "no" to indicate whether the current application ID is AppID#1, or whether the current application ID is AppID#1 and the current application distinction parameter is AppD1.

[0429] For example, the authentication request message may further request the user to determine whether the application identifier of the current application matches the application identifier of the target application, and whether the application distinction parameters of the current application match the distinction parameters of the target application. Correspondingly, the authentication response message holds a first matching result and a second matching result, the first matching result indicating whether the application identifier of the current application is identical to the application identifier of the target application, and the second matching result indicating whether the application distinction parameters of the current application are identical to the application distinction parameters of the target application.

[0430] As shown in Figure 2, in steps S1040 and S1050 above, messages exchanged between the OS and the user may be received and transmitted through interface Intf-4, which is a logical interface. Optionally, the interaction between the OS and the user may also be implemented through Intf-1 and the interface between App1 and the user (not shown in Figure 2). In this embodiment of the present application, security protection is provided to the interfaces, i.e., it is assumed that information exchanged between App1, or between App1 and the OS, is not tampered with.

[0431] S1060: The OS sends the original ID1 of App1 to the modem. Correspondingly, the modem receives the original ID1 of App1 from the OS.

[0432] Optionally, the OS sends application-specific parameters AppD1 and another parameter for App1 to the modem.

[0433] S1070: The modem determines the matched URSP rule based on the original ID1 of App1.

[0434] Optionally, the specific implementation of this step could be as follows: The modem determines, based on the original ID1 of App1, whether the application matches a route selection policy rule; if the application matches a route selection policy rule, associate the application with the session according to the route selection policy rule; or, if the application does not match a route selection policy rule, skip associating the application with the session. The following describes how it determines whether the application matches a route selection policy rule.

[0435] Optionally, the modem determines the matched URSP rule based on the original ID1 and AppD1 of App1.

[0436] For specific implementations of steps S1060 and S1070, please refer to the relevant explanations of steps S770-S780 in Method 700. For brevity, further details will not be explained here.

[0437] In the solution provided in this application, the OS triggers a user request, and the user identifies and verifies the current application ID (or application ID and AppD) to reduce the security risk of application ID spoofing.

[0438] The above describes in detail the embodiments of the communication method of the present application with reference to Figures 1 to 10. Below, the embodiments of the communication device of the present application will be described in detail with reference to Figures 11 and 12. Please understand that the description of the device embodiments corresponds to the description of the method embodiments. Therefore, for parts not described in detail, please refer to the method embodiments described above.

[0439] Figure 11 is a diagram of the structure of a communication device or network device 2000 according to an embodiment of the present application. As shown in Figure 11, the device 2000 may include a transceiver unit 2010 and a processing unit 2020. The transceiver unit 2010 can communicate with the outside, and the processing unit 2020 is configured to process data. The transceiver unit 2010 may also be referred to as a communication interface or transceiver unit.

[0440] In a possible design, device 2000 may implement steps or procedures performed by the communication device in the embodiment of the method described above. Processing unit 2020 is configured to perform processing-related operations of the communication device in the embodiment of the method described above, and transceiver unit 2010 is configured to perform receiving / transmitting-related operations of the communication device in the embodiment of the method described above.

[0441] In another possible design, device 2000 may implement steps or procedures performed by the network device in the embodiment of the method described above. Transceiver unit 2010 is configured to perform the receive / transmit related operations of the network device in the embodiment of the method described above. Processing unit 2020 is configured to perform the processing related operations of the network device in the embodiment of the method described above.

[0442] It should be understood that device 2000 is implemented in the form of a functional unit. The term “unit” here may refer to an application-specific integrated circuit (ASIC), electronic circuitry, a processor (e.g., a shared processor, an application processor, or a group processor) configured to run one or more software or firmware programs, memory, integrated logic circuits, and / or other suitable components supporting the described function. In an optional example, a person skilled in the art will understand that device 2000 may specifically be the transmission side in the above embodiment and may be configured to perform the procedures and / or steps corresponding to the transmission side in the above embodiment of the method. Alternatively, device 2000 may specifically be the receiver in the above embodiment and may be configured to perform the procedures and / or steps corresponding to the receiver in the above embodiment of the method. To avoid repetition, further details are not described here again.

[0443] The device 2000 in the above solution has the function of implementing the corresponding steps performed by the transmitting side in the above method. Alternatively, the device 2000 in the above solution has the function of implementing the corresponding steps performed by the receiving side in the above method. The above function may be implemented by hardware or by hardware running corresponding software. The hardware or software includes one or more modules corresponding to the functions described above. For example, a transceiver unit may be replaced by a transceiver (for example, the transmitting unit in a transceiver unit may be replaced by a transmitter, and the receiving unit in a transceiver unit may be replaced by a receiver), and another unit, for example, a processing unit, may be replaced by a processor, which may separately perform the receiving and transmitting operations and the related processing operations in the embodiment of the method.

[0444] In addition, the transceiver unit may alternatively be a transceiver circuit (for example, including a receiving circuit and a transmitting circuit), and the processing unit may be a processing circuit. In this embodiment of the present application, the device in Figure 11 may be the receiving side or the transmitting side in the above embodiment, or it may be a chip or chip system, such as a system on a chip (SoC). The transceiver unit may be an input / output circuit or a communication interface. The processing unit may be a processor, a microprocessor, or an integrated circuit on a chip. This is not limited to the present specification.

[0445] Figure 12 is a diagram of the structure of a communication device or network device 3000 according to an embodiment of the present invention. As shown in Figure 12, the device 3000 includes a processor 3010 and a transceiver 3020. The processor 3010 and the transceiver 3020 communicate with each other through an internal connection path. The processor 3010 is configured to execute instructions and control the transceiver 3020 to transmit and / or receive signals.

[0446] Optionally, device 3000 may further include memory 3030. Memory 3030 communicates with processor 3010 and transceiver 3020 through an internal connection path. Memory 3030 is configured to store instructions. Processor 3010 can execute instructions stored in memory 3030.

[0447] In possible implementations, device 3000 is configured to implement the procedures and steps corresponding to the communication device in the embodiment of the method described above.

[0448] In another possible implementation, device 3000 is configured to implement the procedures and steps corresponding to the network device in the embodiment of the method described above.

[0449] It should be understood that device 3000 may specifically be the transmitting or receiving side in the above embodiments, or it may be a chip or a chip system. Correspondingly, transceiver 3020 may be a chip transceiver circuit. This is not limited herein. Specifically, device 3000 may be configured to perform steps and / or procedures corresponding to the transmitting or receiving side in the above embodiments of the method.

[0450] Optionally, memory 3030 may include read-only memory and random access memory and may provide instructions and data to the processor. A portion of the memory may further include non-volatile random access memory. For example, the memory may further store device type information. The processor 3010 may be configured to execute instructions stored in memory. When the processor 3010 executes instructions stored in memory, the processor 3010 is configured to perform steps and / or procedures corresponding to the transmission side or reception side in the embodiments of the method described above.

[0451] In the implementation process, steps in the method can be completed by using hardware-integrated logic circuits in the processor or by using instructions in software form. Steps in the methods disclosed with reference to embodiments of this application can be performed and achieved directly by using a hardware processor or by using a combination of hardware and software modules in the processor. The software modules may reside in storage media that are mature in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. The storage medium resides in memory, and the processor reads information from memory and, in combination with the processor's hardware, completes the steps in the method described above. To avoid repetition, further details are not described here again.

[0452] In embodiments of the present application, the processor may be an integrated circuit chip and should be noted to have signal processing capabilities. In the implementation process, the steps in the embodiments of the method can be completed by using hardware-integrated logic circuits in the processor or by using instructions in software form. The processor may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array, or another programmable logic device, discrete gate or transistor logic device, or discrete hardware component. The processor in embodiments of the present application can implement or execute the methods, steps and logical block diagrams disclosed in embodiments of the present application. The general-purpose processor may be a microprocessor, or the processor may be any conventional processor or similar. The steps in the methods disclosed with reference to embodiments of the present application may be performed and achieved directly by using a hardware decoding processor, or by using a combination of hardware and software modules in the decoding processor. The software modules may reside in storage media that are mature in the art, such as random-access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. The storage medium is located in memory, and the processor reads the information from memory and, in combination with the processor's hardware, completes the steps in the method described above.

[0453] The memory in this embodiment of the Application may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may be random access memory (RAM) used as an external cache. Several forms of RAM are available, not limited to but including, static random access memory, dynamic random access memory, synchronous dynamic random access memory, double data rate synchronous dynamic random access memory, enhanced synchronous dynamic random access memory, sync-link dynamic random access memory, and direct RAMbus random access memory. It should be noted that the memory of the systems and methods described herein includes, but is not limited to, these and any other suitable types of memory.

[0454] Figure 13 is a diagram of the structure of a chip system 4000 according to an embodiment of the present invention. As shown in Figure 13, the chip system 4000 (which may also be referred to as a processing system) includes a logic circuit 4010 and an input / output interface 4020.

[0455] The logic circuit 4010 may be a processing circuit in the chip system 4000. The logic circuit 4010 is coupled to and connected to a storage unit and can call instructions in the storage unit, so that the chip system 4000 can implement the methods and functions of the embodiments of the present invention. The input / output interface 4020 is an input / output circuit in the chip system 4000 that can output information to be processed by the chip system 4000, or input data to be processed or signaling information to the chip system 4000 for processing.

[0456] In the solution, the chip system 4000 is configured to implement the operations performed by the communication device and network device in the embodiment of the above method.

[0457] One embodiment of the present invention further provides a computer-readable storage medium. The computer-readable storage medium stores computer instructions used to implement the method performed by the device in the embodiment of the above method.

[0458] Embodiments of the present invention further provide a computer program product comprising instructions. When the instructions are executed by a computer, the method of execution by a device in the embodiments of the above method is implemented.

[0459] Embodiments of the present invention further provide a communication system including, for example, one or more communication devices or network devices.

[0460] For a description of any one relevant aspect and beneficial effects of the apparatus provided above, please refer to the corresponding embodiment of the method provided above. Further details will not be provided here.

[0461] Those skilled in the art will notice, by referring to the examples described in the embodiments disclosed herein, that units and algorithmic steps may be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether the functions are performed by hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art may use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of the Application.

[0462] Those skilled in the art will clearly understand that, for the purpose of convenient and simple explanation, the detailed operating processes of the above systems, apparatuses, and units will be described by referring to the corresponding processes in the embodiments of the methods. Further details will not be described here.

[0463] It should be understood that, in some embodiments provided herein, the systems, apparatus, and methods disclosed may be implemented in other ways. For example, the embodiments of the apparatus described are merely examples. For example, the division into units is merely a logical functional division, and other divisions may be possible in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the mutual coupling, direct coupling, or communication connection shown or described may be implemented through some interfaces. Indirect coupling or communication connection between apparatus or units may be implemented in electronic, mechanical, or other forms.

[0464] Units described as separate parts may or may not be physically separate, and parts shown as units may or may not be physical units, and may be located in one location or distributed across multiple network units. Some or all of the units may be selected based on actual requirements in order to achieve the objectives of the solution of the embodiment.

[0465] In addition, the functional units in the embodiments of the present invention may be integrated into a single processing unit, or each of those units may exist physically independently, or two or more units may be integrated into a single unit.

[0466] When a function is implemented in the form of a software function unit and sold or used as an independent product, the function may be stored on a computer-readable storage medium. Based on such understanding, the technical solution of the present application, or a portion of its contribution to the prior art, or a part of the technical solution, may be implemented in the form of a software product. The computer software product is stored on a storage medium and includes a number of instructions for instructing a computer device to perform all or some of the steps of the method described in the embodiments of the present application. The storage medium includes any medium capable of storing program code, such as a USB flash drive, a removable hard disk, a read-only memory, a random-access memory, a magnetic disk, or an optical disk.

[0467] The above description is merely a specific implementation of the present application, and the scope of protection of the present application is not limited thereto. Any modification or substitution within the scope of the art disclosed herein that is readily understandable to a person skilled in the art shall fall within the scope of protection of the present application. Accordingly, the scope of protection of the present application shall be subject to the scope of protection of the claims.

Claims

1. When a communication device detects an application, the communication device determines, based on the application's second application identifier and second application distinction parameter, that the application matches a route selection policy rule, where the route selection policy rule includes a first application identifier and a first application distinction parameter; and The communication device associates the application with the session according to the route selection policy rule. A communication method that includes the following features.

2. Prior to the step in which the communication device determines, based on the second application identifier and second application distinction parameter of the application, that the application matches the route selection policy rule, the method further: The communication device receives the route selection policy rule from the network device. The method according to claim 1, comprising:

3. The second application distinction parameter is as follows: The identifier of the binding platform for the application, the identifier of the application program source for the application, the name of the installation package for the application, the user identifier of the application, the identifier of the developer of the application, the identifier of the public land mobile network associated with the application, or the identifier of the application function used to generate the route selection policy rules. The method according to claim 1 or 2, comprising one or more of the above.

4. The aforementioned method further: Steps to perform integrity or authenticity verification on the second application identifier and the second application distinction parameter using the communication device. Equipped with; The steps by which the communication device determines whether the application matches the route selection policy rule based on the application's second application identifier and second application distinction parameter are as follows: If the integrity or authenticity verification is successful, the communication device determines, based on the second application identifier and the second application distinction parameter, that the application matches the route selection policy rule. The method according to any one of claims 1 to 3, comprising:

5. The steps by which the communication device determines whether the application matches the route selection policy rule based on the application's second application identifier and second application distinction parameter are as follows: The communication device determines that the first application identifier is the same as the second application identifier, and that the first application distinction parameter is the same as the second application distinction parameter. The method according to any one of claims 1 to 4, including the method described in any one of claims 1 to 4.

6. The communication device comprises an operating system and a modem, and the method further includes: The operating system receives a first parameter from the application, wherein the first parameter includes one or more of the following: a temporary identifier, a temporary key, or an access token; The steps include: determining the second application identifier and the second application distinction parameter based on the first parameter using the operating system; and The operating system transmits the second application identifier and the second application distinction parameter to the modem. Equipped with; The steps by which the communication device determines whether the application matches the route selection policy rule based on the application's second application identifier and second application distinction parameter are as follows: The modem determines that the second application identifier is the same as the first application identifier, and that the second application distinction parameter is the same as the first application distinction parameter. The method according to any one of claims 1 to 5, including the method described in any one of claims 1 to 5.

7. The steps by which the operating system determines the second application identifier and the second application distinction parameter based on the first parameter are as follows: The operating system determines the second application identifier and the second application distinguishing parameter based on the temporary identifier and the mapping relationship, where the mapping relationship indicates the relationship among the second application identifier, the second application distinguishing parameter, and the temporary identifier; or The operating system determines the second application identifier and the second application distinction parameter based on the temporary key or the access token. The method according to claim 6, having the following characteristics.

8. The step by which the operating system receives the first parameter from the application is: When the application is activated or used, the operating system receives the first parameter from the application. The method according to claim 6 or 7, having the following characteristics.

9. Prior to the stage in which the operating system receives the first parameter from the application, the method further: The step of generating the first parameter using the operating system; and The operating system sends the first parameter to the application. Equipped with, here When the first parameter is the temporary identifier, the operating system stores the mapping relationship. The method according to any one of claims 6 to 8.

10. The aforementioned method further: The communication device transmits an authentication request message to the user, wherein the authentication request message includes the second application identifier and the second application distinction parameter, and the authentication request message is used to request the user to verify the second application identifier and the second application distinction parameter, or the authentication request message is used to request the user to determine whether the second application identifier is the same as the first application identifier and whether the second application distinction parameter is the same as the first application distinction parameter; and In the step of receiving an authentication response message from the user via the communication device, the authentication response message includes the verification result of the second application identifier and the second application distinction parameter, or the authentication response message includes a first matching result of the second application identifier and the first application identifier, and a second matching result of the second application distinction parameter and the first application distinction parameter. Equipped with; The steps by which the communication device determines whether the application matches the route selection policy rule based on the application's second application identifier and second application distinction parameter are as follows: The communication device determines, based on the authentication response message, that the application matches the route selection policy rule. The method according to any one of claims 1 to 5, including the method described in any one of claims 1 to 5.

11. The steps by which the communication device determines, based on the authentication response message, that the application matches the route selection policy rule are as follows: When the verification result indicates that the verification performed by the user on the second application identifier and the second application distinction parameter is successful, the communication device determines that the application matches the route selection policy rule; or When the first matching result indicates that the second application identifier is the same as the first application identifier, and the second matching result indicates that the second application distinction parameter is the same as the first application distinction parameter, the communication device determines that the application matches the route selection policy rule. The method according to claim 10, including the method described in claim 10.

12. The aforementioned method further: The step of obtaining the route selection policy rule by the network device; and The network device transmits the route selection policy rule to the communication device. The method according to any one of claims 1 to 11, comprising:

13. The network device acquires a route selection policy rule, which includes a first application identifier and a first application distinction parameter; and the network device transmits the route selection policy rule to a communication device. A communication method that includes the following features.

14. When a communication device detects an application, the communication device determines that the application matches a route selection policy rule; The communication device sends a request message to a network device, wherein the request message includes the application identifier of the application, and the request message is used to request that the application verify whether it matches the route selection policy rule; and The communication device receives a response message from the network device. A communication method that includes the following features.

15. The method according to claim 14, wherein the application identifier of the application is securely protected.

16. The secure application identifier for the aforementioned application is as follows: The application identifier of the said application, the application identifier of the said application encrypted with a key, or the application identifier of the said application The method according to claim 15, comprising one or more of the above.

17. The method according to any one of claims 14 to 16, wherein the request message further includes authentication information, the authentication information includes the application identifier of the application and a digital signature used to verify the application identifier of the application, the authentication information is used to verify the authenticity or integrity of the application, and the authentication information is one of the following: the digital signature, a hash value, or a message authentication code.

18. Prior to the step of the communication device sending the request message to the network device, the method further: The communication device determines, based on first configuration information, to transmit the application identifier of the application to the network device, where the first configuration information instructs the network device to transmit the application identifier of the application; or the communication device determines, based on first instruction information from the network device, to transmit the application identifier of the application to the network device, where the first instruction information instructs the network device to transmit the application identifier of the application; The method according to any one of claims 14 to 17, comprising:

19. The method according to any one of claims 14 to 18, wherein the request message is a session setup request message or a session modification request message.

20. The method according to any one of claims 14 to 19, wherein the request message further includes second instruction information, the second instruction information instructs the request message to hold the application identifier of the application, or the second instruction information instructs the network device to verify whether the application matches the route selection policy rule.

21. The method according to any one of claims 14 to 20, wherein the request message further includes an application-specific parameter for the application.

22. The method according to claim 21, wherein the application-specific parameter of the application is securely protected.

23. The application distinction parameters for the aforementioned secure application are as follows: The method according to claim 22, comprising one or more of the following: application-specific parameters of the application digitally signed, application-specific parameters of the application encrypted with a key, or application-specific parameters of the application hashed.

24. Prior to the step of the communication device sending the request message to the network device, the method further: In the communication device, the communication device determines, based on the second configuration information, that it transmits the application identifier and application distinction parameters of the application to the network device, where the second configuration information instructs that the application identifier and application distinction parameters of the application be transmitted to the network device, and the second configuration information is pre-configured in the communication device; or In the step where the communication device determines, based on third instruction information from the network device, to transmit the application identifier and application distinction parameters of the application to the network device, the third instruction information instructs the transmission of the application identifier and application distinction parameters of the application to the network device. The method according to any one of claims 21 to 23, comprising:

25. The request message further includes fourth instruction information, which instructs the request message to hold the application identifier and the application distinction parameters of the application, or instructs the network device to verify whether the application matches the route selection policy rule. The method according to any one of claims 21 to 24.

26. The method according to any one of claims 14 to 25, wherein when the application matches the route selection policy rule, the response message instructs the network device to accept the request of the communication device.

27. The aforementioned method further: When the application does not match the route selection policy rule, the communication device receives a rejection message from the network device, wherein the rejection message indicates that the network device rejects the request of the communication device, the rejection message includes a reason for rejection, the reason for rejection indicating that the application identifier of the application is different from the application identifier in the route selection policy rule, and / or that the application distinction parameter of the application is different from the application distinction parameter in the route selection policy rule. The method according to any one of claims 21 to 26, comprising:

28. The network device receives a request message from a communication device, the request message including the application identifier of the application, and the request message is used to request that the application be verified to determine whether it matches the route selection policy rule; The step of the network device determining, based on the application identifier of the application, that the application matches the route selection policy rule; and The network device transmits a response message to the communication device. A communication method that includes the following features.

29. The method of claim 28, wherein the application identifier of the application is securely protected.

30. The secure application identifier for the aforementioned application is as follows: The application identifier of the said application, the application identifier of the said application encrypted with a key, or the application identifier of the said application The method according to claim 29, comprising one or more of the above.

31. The method according to any one of claims 28 to 30, wherein the request message further includes authentication information, the authentication information includes the application identifier of the application and a digital signature used to verify the application identifier of the application, the authentication information is used to verify the authenticity or integrity of the application, and the authentication information is one of the following: the digital signature, a hash value, or a message authentication code.

32. The method according to any one of claims 28 to 31, wherein the step of the network device determining that the application matches the route selection policy rule based on the application identifier in the route selection policy rule and the application identifier of the application includes: the step of the network device determining that the application identifier of the application is the same as the application identifier of the application in the route selection policy rule.

33. The step by which the network device determines that the application matches the route selection policy rule based on the application identifier in the route selection policy rule and the application identifier of the application is: When the application identifier of the application is digitally signed, the network device verifies the digital signature; and When the verification of the digital signature is successful, the network device determines that the application matches the route selection policy rule based on the application identifier in the route selection policy rule and the application identifier of the application. The method according to any one of claims 28 to 31, including the method described in any one of claims 28 to 31.

34. Prior to the stage in which the network device receives the request message from the communication device, the method further: In the step of the network device transmitting the first instruction information to the communication device, the first instruction information instructs the communication device to transmit the application identifier of the application to the network device. The method according to any one of claims 28 to 33, comprising:

35. The method according to any one of claims 28 to 34, wherein the request message is a session setup request message or a session modification request message.

36. The request message further includes second instruction information, the second instruction information instructs the request message to hold the application identifier of the application, or the second instruction information instructs the network device to verify whether the application matches the route selection policy; and The method according to any one of claims 28 to 35, wherein the step of the network device determining that the application matches the route selection policy rule based on the application identifier of the application and the application identifier in the route selection policy rule includes: the step of the network device determining that the application matches the route selection policy rule based on the second instruction information, the application identifier of the application and the application identifier in the route selection policy rule.

37. The request message further includes application-specific parameters for the application; The method according to any one of claims 28 to 36, wherein the step of the network device determining that the application matches the route selection policy rule based on the application identifier of the application and the application identifier in the route selection policy rule includes: the step of the network device determining that the application matches the route selection policy rule based on the application identifier of the application, the application identifier in the route selection policy rule, the application distinction parameter of the application, and the application distinction parameter in the route selection policy rule.

38. The method according to claim 37, wherein the step by which the network device determines that the application matches the route selection policy rule based on the application identifier of the application, the application identifier in the route selection policy rule, the application distinction parameter of the application, and the application distinction parameter in the route selection policy rule includes: the step by which the network device determines that the application identifier of the application is the same as the application identifier in the route selection policy rule, and the application distinction parameter of the application is the same as the application distinction parameter in the route selection policy rule.

39. The method according to claim 37 or 38, wherein the application-specific parameter of the application is securely protected.

40. The application distinction parameters for the aforementioned secure application are as follows: The method according to claim 39, comprising one or more of the following: application-specific parameters of the application digitally signed, application-specific parameters of the application encrypted with a key, or application-specific parameters of the application hashed.

41. Prior to the stage in which the network device receives the request message from the communication device, the method further: In the step where the network device transmits the third instruction information to the communication device, the third instruction information instructs the communication device to transmit the application identifier and the application distinction parameters of the application to the network device. The method according to any one of claims 37 to 40, comprising:

42. The request message further includes fourth instruction information, which indicates that the request message holds the application identifier and the application distinction parameters of the application, or the fourth instruction information indicates that the network device verifies whether the application matches the route selection policy; and The method according to any one of claims 37 to 41, wherein the step by which the network device determines that the application matches the route selection policy rule based on the application identifier of the application, the application identifier in the route selection policy rule, the application distinction parameter of the application, and the application distinction parameter in the route selection policy rule includes: the step by which the network device determines that the application matches the route selection policy rule based on the fourth instruction information, the application identifier of the application, the application identifier in the route selection policy rule, the application distinction parameter of the application, and the application distinction parameter in the route selection policy rule.

43. The method according to any one of claims 37 to 42, wherein when the application does not match the route selection policy rule, the network device sends a rejection message to the communication device, wherein the rejection message indicates that the network device rejects the request of the communication device, the rejection message includes a reason for rejection, the reason for rejection indicating that the application identifier of the application is different from the application identifier in the route selection policy rule, and / or the application distinction parameter of the application is different from the application distinction parameter in the route selection policy rule.

44. The method according to any one of claims 28 to 43, wherein when the application matches the route selection policy rule, the response message instructs the network device to accept the request of the communication device.

45. The operating system then receives a first parameter from the application, where the first parameter is as follows: Includes one or more of the following: temporary identifier, temporary key, or access token; A step in which the operating system determines the second application identifier and second application distinction parameter of the application based on the first parameter; The operating system transmits the second application identifier to the modem; and The modem determines, based on the second application identifier and the first application identifier, that the application matches the route selection policy rule, where the route selection policy rule includes the first application identifier. A communication method that includes the following features.

46. The method according to claim 45, wherein the step of the modem determining, based on the second application identifier and the first application identifier, that the application matches the route selection policy rule includes: the step of the modem determining that the second application identifier is the same as the first application identifier.

47. The steps by which the operating system determines the second application identifier of the application based on the first parameter are: The operating system determines the second application identifier based on the temporary identifier and the mapping relationship, where the mapping relationship indicates the relationship between the second application identifier and the temporary identifier; or The operating system determines the second application identifier based on the temporary key or the access token. The method according to claim 45 or 46, including the method described in claim 45 or 46.

48. The step by which the operating system receives the first parameter from the application is: When the application is activated or used, the operating system receives the first parameter from the application. The method according to any one of claims 45 to 47, comprising:

49. Prior to the stage in which the operating system receives the first parameter from the application, the method further: The step of generating the first parameter using the operating system; and The operating system sends the first parameter to the application. Equipped with, here When the first parameter is the temporary identifier, the operating system stores the mapping relationship. The method according to claim 47 or 48.

50. Depending on the application, the first parameter is received from the operating system, where the first parameter is as follows: Temporary identifier, temporary key, or access token This includes one or more of the following; and When the application is activated or used, the application sends the first parameter to the operating system. A communication method that includes the following features.

51. The communication device sends an authentication request message to the user, where the authentication request message includes a second application identifier of the application, and the authentication request message is used to request verification of the second application identifier; The communication device receives an authentication response message from the user, where the authentication response message includes the verification result of the second application identifier; and The communication device determines, based on the authentication response message, that the application matches the route selection policy rule. A communication method that includes the following features.

52. The processing unit is configured to detect an application and determine whether the application matches a route selection policy rule based on the application's second application identifier and second application distinction parameter, wherein the route selection policy rule includes a first application identifier and a first application distinction parameter, where The processing unit is further configured to associate the application with the session in accordance with the route selection policy rules. Communication device.

53. The aforementioned device further: Transceiver unit configured to receive the aforementioned route selection policy rules from network devices The apparatus according to claim 52, comprising:

54. The second application distinction parameter is as follows: The identifier of the binding platform for the application, the identifier of the application program source for the application, the name of the installation package for the application, the user identifier of the application, the identifier of the developer of the application, the identifier of the public land mobile network associated with the application, or the identifier of the application function used to generate the route selection policy rules. The apparatus according to claim 52 or 53, comprising one or more of the above.

55. The processing unit is further configured to perform integrity or authenticity verification on the second application identifier and the second application distinction parameter; The processing unit is further configured to determine, when the integrity or authenticity verification is successful, that the application matches the route selection policy rule based on the second application identifier and the second application distinction parameter. The apparatus according to any one of claims 52 to 54.

56. The apparatus according to any one of claims 52 to 55, wherein the processing unit is further configured to determine that the first application identifier is the same as the second application identifier and that the first application distinction parameter is the same as the second application distinction parameter.

57. The transceiver unit is further configured to receive a first parameter from the application, where the first parameter includes one or more of the following: a temporary identifier, a temporary key, or an access token; The processing unit is further configured to determine the second application identifier and the second application distinction parameter based on the first parameter; The transceiver unit is further configured to transmit the second application identifier and the second application distinction parameter to the modem; The processing unit is further configured to determine that the second application identifier is the same as the first application identifier, and that the second application distinction parameter is the same as the first application distinction parameter. The apparatus according to any one of claims 52 to 56.

58. The processing unit is further configured to determine the second application identifier and the second application distinction parameter based on the temporary identifier and the mapping relationship, where the mapping relationship indicates the relationship between the second application identifier, the second application distinction parameter, and the temporary identifier; or The processing unit is further configured to determine the second application identifier and the second application distinction parameter based on the temporary key or the access token. The apparatus according to claim 57.

59. The apparatus according to claim 57 or 58, wherein the transceiver unit is further configured to receive the first parameter from the application when the application is activated or used.

60. The processing unit is further configured to generate the first parameter; The transceiver unit is further configured to transmit the first parameter to the application; The processing unit is further configured to store the mapping relationship when the first parameter is the temporary identifier. The apparatus according to any one of claims 57 to 59.

61. The transceiver unit is further configured to send an authentication request message to a user, the authentication request message comprising the second application identifier and the second application distinction parameter, and the authentication request message is used to request the user to verify the second application identifier and the second application distinction parameter, or to determine whether the second application identifier is the same as the first application identifier and whether the second application distinction parameter is the same as the first application distinction parameter; The transceiver unit is further configured to receive an authentication response message from the user, wherein the authentication response message includes the verification result of the second application identifier and the second application distinction parameter, or the first matching result of the second application identifier and the first application identifier, and the second matching result of the second application distinction parameter and the first application distinction parameter; The processing unit is further configured to determine, based on the authentication response message, that the application matches the route selection policy rule. The apparatus according to any one of claims 52 to 56.

62. The aforementioned processing unit further: When the verification result indicates that the verification performed by the user on the second application identifier and the second application distinction parameter is successful, the application is determined to match the route selection policy rule; or When the first matching result indicates that the second application identifier is the same as the first application identifier, and the second matching result indicates that the second application distinction parameter is the same as the first application distinction parameter, it is determined that the application matches the route selection policy rule. The apparatus according to claim 61, configured in such a way.

63. A communication device comprising a processor configured to execute a computer program stored in memory to cause the device to perform the method described in any one of claims 1 to 12, or the method described in claim 13, or the method described in any one of claims 14 to 27, or the method described in any one of claims 28 to 44, or the method described in any one of claims 45 to 49, or the method described in claim 50, or the method described in claim 51. A communication device equipped with the following features.

64. The apparatus according to claim 63, further comprising the memory and / or communication interface, wherein the communication interface is coupled to the processor and the communication interface is configured to input and / or output information.

65. A communication system comprising one or more of a terminal device, a network device, an operating system, an application, or a modem, wherein the terminal device is configured to perform the method described in any one of claims 1 to 12, the network device is configured to perform the method described in claim 13 or any one of claims 28 to 44, the communication device is configured to perform the method described in any one of claims 14 to 27 or the method described in claim 51, and the operating system is configured to perform the method described in any one of claims 45 to 49 or the method described in claim 50.

66. A computer-readable storage medium for storing a computer program, wherein when the computer program is executed on a computer, the computer is made to execute the method according to any one of claims 1 to 51.

67. A computer program product comprising instructions for performing the method described in any one of claims 1 to 51.

Images