A communication method and apparatus

Abstract

The application discloses a communication method and device, and belongs to the technical field of communication. The method comprises the following steps: acquiring a first requirement of a host device for establishing a packet data unit (PDU) session; determining a processing strategy of the PDU session according to an existing state of a user equipment route selection policy (URSP) rule and an existing state of an existing PDU session matched with the first requirement; the processing strategy comprises the following steps: multiplexing the existing PDU session, establishing a PDU session associated with the URSP rule, establishing a common PDU session, or establishing a local URSP rule and a PDU session associated with the local URSP rule; and sending a first response to the host device based on the processing strategy, wherein the first response comprises a processing result of the PDU session. In this way, different session processing strategies can be supported, and session requirements in different scenarios can be met.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication method and apparatus. Background Technology

[0002] Currently, user terminals can leverage the mobile network attributes of mobile broadband (MBB) devices to better experience the services provided by mobile networks. For example, laptops can use 5G internet services provided by mobile operators by connecting to MBB devices. Given the diverse usage scenarios for user terminals, there is an urgent need to develop solutions that enable user terminals to access network services through MBB devices in various scenarios. Summary of the Invention

[0003] A communication method and apparatus are provided to support user terminals in using network services through MBB devices in different scenarios.

[0004] In a first aspect, a communication method is provided, which can be applied to MBB devices (which may be complete devices or chips). The method includes: obtaining a first request from a host device to establish a Packet Data Unit (PDU) session; determining a processing strategy for the PDU session based on the existence status of User Equipment Routing Policy (URSP) rules and the existence status of existing PDU sessions matching the first request; the processing strategy includes: reusing the existing PDU session, establishing a PDU session associated with the URSP rule, establishing a normal PDU session, or establishing a local URSP rule and a PDU session associated with the local URSP rule; and sending a first response to the host device based on the processing strategy, the first response including the processing result of the PDU session.

[0005] Optionally, based on the existence status of the User Equipment Routing Policy (URSP) rules and the existence status of existing PDU sessions matching the first requirement, the processing strategy for the PDU session is determined, including: If the URSP rule exists: if an existing PDU session associated with the URSP rule exists, the existing PDU session associated with the URSP rule is reused; or, if an existing PDU session associated with the URSP rule does not exist, a PDU session associated with the URSP rule is established. Alternatively, if the URSP rule does not exist: if an existing PDU session associated with the first requirement exists, the existing PDU session associated with the first requirement is reused; or, if an existing PDU session associated with the first requirement does not exist, the ordinary PDU session is established; or, if an existing PDU session associated with the first requirement does not exist, the local URSP rule and the PDU session associated with the local URSP rule are established.

[0006] Optionally, the first requirement includes activation information and slice parameters for activating the default rule; If an existing PDU session associated with the first requirement exists, reusing the existing PDU session associated with the first requirement includes: If an existing PDU session exists that is associated with the slice parameter, the existing PDU session is reused.

[0007] Optionally, the first requirement includes activation information for activating the default rule; If no existing PDU session associated with the first requirement exists, establish the local URSP rule and the PDU session associated with the local URSP rule, including: The first requirement includes slice parameters, and if there is no existing PDU session associated with the slice parameters, the local URSP rule is established, and the PDU session is established based on the local URSP rule; If no existing PDU session associated with the first requirement exists, establish the ordinary PDU session, including: If the first requirement does not include the slice parameters, then establish the normal PDU session.

[0008] Optionally, the first requirement includes activation information and path descriptor TD for activating non-default rules; the method further includes: Based on the TD, determine the matching route selection descriptor RSD in the non-default URSP rule that matches the TD; If no matching RSD is found in a non-default URSP rule, then the matching RSD in the default URSP rule that matches the TD is determined.

[0009] Optionally, if an existing PDU session associated with the URSP rule exists, reusing the existing PDU session associated with the URSP rule includes: If an existing PDU session's RSD corresponds to the matching RSD, the existing PDU session is reused. If the existing PDU session associated with the URSP rule does not exist, establish the PDU session associated with the URSP rule, including: If there is no existing PDU session RSD corresponding to the matching RSD, a PDU session associated with the URSP rule to which the matching RSD belongs is established.

[0010] Optionally, it also includes: If an update to the URSP rule is detected, the updated URSP rule is sent to the host device.

[0011] Optionally, it also includes: Receive a rule query request from the host device, the rule query request being used to request a query for URSP rules.

[0012] Optionally, it also includes: Receive a service query request from the host device, the service query request being used to query the services supported by the MBB device under the Mobile Broadband Interface Model (MBIM) Extended Protocol; Send device service information to the host device, wherein the device service information is used to indicate the services supported by the MBB device under the MBIM extension protocol; Receive a handover request from the host device, the handover request being used to request the MBB device to switch to the extended protocol; Based on the switching request, switch to the extended protocol and send a switching instruction to the host device, the switching instruction being used to instruct the host device to switch to the extended protocol.

[0013] In a second aspect, a communication device is also provided, including a processor and a communication interface, the communication interface being used to receive and / or transmit signals, and the processor being configured to enable the method described in any one of the first aspects to be executed.

[0014] Thirdly, a computer program product is also provided, including a program or instructions that, when the computer program product is run on a computer, cause the computer to perform the method as described in any one of the first aspects.

[0015] Fourthly, a computer-readable storage medium is provided, including a program or instructions that, when executed, implement the method as described in any one of the first aspects.

[0016] In this application, the processing strategy for a PDU session can be jointly determined by the existence status of URSP rules and the existence status of existing sessions, enabling fine-grained and adaptive PDU session management. Furthermore, based on the existence status of URSP rules and the existence status of existing sessions, different processing strategies can be supported in different scenarios, meeting the session requirements of various situations. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] To gain a more complete understanding of this application and its beneficial effects, the following description will be provided in conjunction with the accompanying drawings, wherein the same reference numerals in the following description denote the same parts.

[0019] Figure 1 This is a schematic diagram of the architecture of an MBB device provided as an exemplary embodiment of this disclosure.

[0020] Figure 2 This is yet another schematic diagram of the architecture of an MBB device provided as an exemplary embodiment of the present disclosure.

[0021] Figure 3 , Figure 4 This is a flowchart illustrating a communication method provided in an exemplary embodiment of the present disclosure.

[0022] Figure 5A , Figure 5B This is a flowchart illustrating a communication method provided in an exemplary embodiment of this disclosure.

[0023] Figures 6-8 This is a flowchart illustrating a communication method provided in an exemplary embodiment of the present disclosure.

[0024] Figure 9 This is a schematic diagram of the architecture of an electronic device provided as an exemplary embodiment of this disclosure. Detailed Implementation

[0025] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the protection scope of this application.

[0026] In the embodiments of this application, "at least one" refers to one or more; "multiple" refers to two or more. In the description of this application, the terms "first," "second," "third," etc., are used only for the purpose of distinguishing descriptions and should not be construed as indicating or implying relative importance, nor should they be construed as indicating or implying order.

[0027] References such as “one embodiment” or “some embodiments” as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the terms “comprising,” “including,” “having,” and variations thereof, as used in this specification, mean “including, but not limited to,” unless otherwise specifically emphasized.

[0028] It should be noted that in the embodiments of this application, "and / or" describes the relationship between associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. In addition, the character " / ", unless otherwise specified, generally indicates that the associated objects before and after it are in an "or" relationship.

[0029] This application provides a communication method applied to a system including an MBB device and a host device. The MBB device has data network communication capabilities, and the data network includes, but is not limited to, 5G, 6G, or future evolved network types. The data network may also be called a mobile network or have other names. This document primarily uses 5G as an example for description, but this does not constitute a limitation on the data network.

[0030] In some embodiments, the MBB device can implement 5G network access, Mobile Broadband Interface Model (MBIM) protocol parsing, User Equipment Route Selection Policy (URSP) rule management, and Packet Data Unit (PDU) session establishment.

[0031] For example, the MBB device can be a 5G industrial plug-in module, a 5G data card, a 5G portable Wi-Fi device, a 5G customer premise equipment (CPE), a 5G vehicle-mounted communication terminal, or an IoT 5G gateway. The embodiments in this application do not limit the specific form or implementation of the MBB device.

[0032] Please see Figure 1 This is an example of the architecture of an MBB device provided in the embodiments of this application. An MBB device may include an application layer, a kernel layer, and a modem layer.

[0033] The application layer may include information interfaces, basic connectivity services, basic connectivity extension services, and other private services.

[0034] For example, the aforementioned information interface could be (Qualcomm Message Interface, QMI).

[0035] The information interface can be used to access the non-access stratum (NAS) of the modem layer through the information interface of the modem layer.

[0036] For example, the host device sends control messages related to the MBIM protocol. These control messages can be routed through the application layer's information interface to the modem layer's information interface, and then to the NAS, thus completing the stacking of the control message. Examples of MBIM-related protocols include MBIMExt4.0 / MBIM1.0.

[0037] As one possible implementation, such as Figure 2 MBB devices can register an MBIM Protocol Control Request Processing path, allowing them to transmit control messages according to the corresponding control path.

[0038] like Figure 2 MBB devices can also register MBIM Protocol Data Request Processing path, so that MBB devices can transmit data packets according to the corresponding data path.

[0039] The application layer provides basic connectivity services that can be used to establish, manage, and release data connections.

[0040] like Figure 2 The basic connectivity service can mount (hook) the URSP rule management component (URSP Cache). URSPCache can also be called a policy cache.

[0041] For example, this policy cache is built on the CONNECT sessions process.

[0042] A connection session, also known as a PDU session, or simply a session, is used in this application embodiment. The session is based on MBIM-related protocols and can also be referred to as an MBIM session. For example, an MBIMExt4.0 session.

[0043] As one possible implementation, in response to a session request initiated by a host device, the MBB device can assign a unique tag ID to the session request, and the policy cache can be used to record this unique tag ID.

[0044] As one possible implementation, the MBB device can also record the dialing (data call) type of the session request in the policy cache.

[0045] As one possible implementation, MBB devices can also record URSP rules established based on the current session in the policy cache.

[0046] like Figure 2 The basic connectivity service can also mount a CID CONNECT module to handle CID CONNECT signaling. The CID CONNECT module can also be understood as a sub-service under the basic connectivity service. The CID CONNECT module can also be called a connectivity module.

[0047] As one possible implementation, the CID CONNECT signaling is obtained by reconstructing the MBIM1.0 CID CONNECT TLV.

[0048] As one possible implementation, the CID CONNECT signaling waits for the activation of the CID VERSION signaling.

[0049] like Figure 2 The connection module can register a default data call request (RegisterDefault (not 5G SA / 5G SA local configuration) DataCall Request) with the NAS via the information interface. Subsequently, the host device can request to complete normal data call services from the MBB device based on CID CONNECT signaling.

[0050] This standard data dialing service corresponds to a standard PDU session and is distinct from dialing services based on network slicing.

[0051] like Figure 2 The connection module can also register a Not-Default URSP Rules DataCall Request with the NAS via the information interface to complete data dialing services based on the non-default URSP rules.

[0052] like Figure 2 The connection module can also register a default URSP rules data call request with the NAS via the information interface to complete data dialing services based on the default URSP rules.

[0053] like Figure 2 The basic connection service also includes a session management component (SessionCache), which can also be called a session cache.

[0054] As one possible implementation, the MBB device may record one or more of the following session-related information in the session cache: whether the established session successfully establishes URSP rules, the list of traffic descriptors (TD) associated with the established session, the single network slice selection assistance information (S-NSSAI) associated with the established session, URSP rules, or DNN.

[0055] like Figure 2 The aforementioned basic connection extension service can be equipped with a CID MS UE POLICY module, which can also be called a policy module. This module can be used to process CID MS UE POLICY signaling. CID MS UE POLICY signaling can be referred to as policy signaling.

[0056] MBB devices can notify host devices of URSP TD information through the CID MS UE POLICY module. As one possible implementation, this basic connectivity extension service can register with the NAS in the modem layer via an information interface to request or subscribe to URSP TD information. TD information, for example, is a TD list.

[0057] Still Figure 2 The basic connectivity extension service can also mount the CID_MS NETWORK PARAMS module, which can also be called the network parameter module.

[0058] As one possible implementation, such as Figure 2The network parameter module can register with the NAS through the information interface to request or subscribe to one or more of the following information: local area data network (LADN), tracking area identifier (nr5g_tai), and network slice selection assistance information (NSSAI).

[0059] Optionally, the MBB device can also report its own capabilities to the host device through this network parameter module.

[0060] like Figure 2 The aforementioned basic connection extension service can also mount the CID VERSION module, which can also be called the version module.

[0061] MBB devices can use this version module to report their protocol negotiation and switching capabilities to the host device. As one possible implementation, CID VERSION activation means that the protocol versions negotiated between the host device and the MBB device are consistent.

[0062] like Figure 2 The basic connection extension service can register an MBIMExt4.0 hook API for Request Negotiate, thus enabling the registration of the hook API for CID VERSION signaling, providing dedicated interface call capabilities for dynamic negotiation of the MBIMExt4.0 protocol version.

[0063] like Figure 2 The basic connectivity extension service can also mount the CID MS REGISTRATION PARAMS module, which can also be called a registration parameter module. MBB devices can use this registration parameter module to report their capabilities to the host device. As one possible implementation method, such as... Figure 2 This registration parameter module can register with the NAS through the information interface to request or subscribe to registration information.

[0064] Optionally, this basic connectivity extension service can also mount the CID MS_DEVICE_CAPS_V2 module, which can be simply referred to as the device capability module. As one possible implementation, this module is used to process DEVICE_CAPS_V2 signaling, which is a reconstruction of MBIM1.0 MS_DEVICE_CAPS_V2 signaling.

[0065] As one possible implementation, the DEVICE_CAPS_V2 signaling waits for the CID VERSION to be activated. In other words, the DEVICE_CAPS_V2 signaling-related procedures are executed only if the protocol versions negotiated between the host device and the MBB device are consistent.

[0066] The host device can use this signaling to query the MBB device for feature supplementation capabilities. Feature supplementation capabilities include URSP and / or eSIM.

[0067] Optionally, this basic connectivity extension service can also mount a network parameter cache component. The network parameter cache component can also be called a network state cache component or a network parameter cache.

[0068] Network parameter caching can be used to aggregate recurring service requests for extended signaling of an instance. For example, extended signaling includes CID MS UE POLICY, CID_MS NETWORK PARAMS, CID VERSION, and CID MSREGISTRATION PARAMS.

[0069] Network parameter caching can also be used to synchronize the subscription status of extended signaling information interfaces registered to the NAS. For example, it can record the subscription relationships of instance information interfaces such as CID MS UE POLICY, CID_MS NETWORK PARAMS, CID VERSION, or CID MSREGISTRATION PARAMS.

[0070] Network parameter caching can also be used to decide whether to synchronize changes in the NAS status to the host device.

[0071] For example, the MBB device determines whether key states on the 5G network side (such as slicing rules and network parameters) have changed. If there are changes, the change information can be pushed to the host device.

[0072] One possible implementation is to synchronize state changes to the host device, which can be achieved by pushing notifications onto the stack. For example, this could involve pushing MBB device capability changes via CID MS UE POLICY, CID_MS NETWORK PARAMS, or CIDMS REGISTRATION PARAMS signaling; pushing updated protocol negotiation and handover capabilities via CID VERSION signaling; and pushing updated feature supplementation capabilities via CID MS_DEVICE_CAPS_V2 signaling.

[0073] The kernel layer may include a Universal Serial Bus (USB) / Peripheral Component Interconnect Express (PCIe) Driver and a USB / PCIe Hardware. Host devices can access the PCIe / USB Driver via the USB / PCIe Hardware interface to push and pop control and data packets onto or from the stack. For example, control packets are forwarded to the application layer, and data packets are forwarded to the modem layer's AS (Application Server).

[0074] like Figure 2 The PCIe / USB Driver can register with the PCIe / USB HW so that the PCIe / USB Driver can establish communication with the Driver HW.

[0075] The modulation and demodulation layer may include an information interface, NAS, access stratum (AS), RF driver, and RF hardware.

[0076] The NAS can receive control messages via an information interface. The NAS may include session management (SM) and mobility management (MM) functions.

[0077] For example, the NAS sends information interface messages from different services to the application layer via the information interface. The application layer then assembles the information interface messages into a stack message of the MBIMExt4.0 / MBIM1.0 protocol.

[0078] AS may include radio resource control (RRC), packet data convergence protocol (PDCP), radio link control (RLC), medium access control (MAC), and physical layer (PHY).

[0079] Please see Figure 3 , Figure 3 A first flowchart of a communication method provided in an embodiment of this application. Specifically, the method may include: S101, MBB device obtains the first requirement of host device to establish PDU session.

[0080] As one possible implementation, such as Figure 4S101 can be implemented as follows: S101a, the MBB device receives the first request from the host device. That is, the host device initiates a PDU session request.

[0081] As another possible implementation, the network side can initiate a PDU session request. This article mainly uses the host device initiating a PDU session request as an example, but this does not constitute a limitation on the solution presented here, and this is hereby stated uniformly.

[0082] S102, the MBB device determines the processing strategy for the PDU session based on the existence status of the URSP rules and the existence status of the existing PDU sessions that match the first requirement.

[0083] The processing strategy includes: reusing existing PDU sessions, establishing PDU sessions associated with URSP rules, establishing ordinary PDU sessions, or establishing local URSP rules and PDU sessions associated with local URSP rules.

[0084] The existence status of URSP rules is either present or absent. The existence status of existing PDU sessions matching the first requirement is also either present or absent.

[0085] The solution provided in this application can jointly determine the processing strategy for a PDU session by considering the existence status of URSP rules and the existence status of existing sessions, thereby achieving fine-grained and adaptive PDU session management. Furthermore, based on the existence status of URSP rules and the existence status of existing sessions, different processing strategies can be supported in different scenarios, meeting the session requirements of various situations.

[0086] S103 and MBB devices send a first response to the host device based on the processing policy. The first response includes the processing result of the PDU session.

[0087] For example, if the processing strategy is to reuse existing PDU sessions, the MBB device can carry the identifier (such as Session ID) and type (Session type) of the existing PDU session in the first response.

[0088] The following section provides a detailed description of the method flow of this application embodiment, taking the host device initiating a session request as an example. Please refer to... Figure 4 The process may include the following steps: S101a, The host device sends the first request to the MBB device.

[0089] Accordingly, the MBB device receives the first request from the host device.

[0090] The first request is used to request the establishment of a Packet Data Unit (PDU) session.

[0091] As one possible implementation, after receiving the first request, the MBB device can execute one of the steps in S102a-S102e, depending on the circumstances, to establish a new PDU session or reuse an existing PDU session. The specific details are described below.

[0092] If S102a and URSP rules exist, and there is an existing PDU session associated with the URSP rules, the MBB device reuses the existing PDU session associated with the URSP rules.

[0093] "Existing PDU session" can be understood / replaced as: a PDU session that has been established and has not been released.

[0094] As one possible implementation, the MBB device determines whether a URSP rule exists. If the URSP rule exists, the MBB device searches for an existing PDU session associated with that URSP rule. If an existing PDU session associated with the URSP rule is found, the MBB device does not need to create a new PDU session and can reuse the existing PDU session. The host device can then use this existing PDU session to implement communication services.

[0095] If S102b and URSP rules exist, and there is no existing PDU session associated with the URSP rules, the MBB device establishes a PDU session associated with the URSP rules.

[0096] As one possible implementation, the MBB device determines whether a URSP rule exists. If the URSP rule exists, the MBB device searches for an existing PDU session associated with that URSP rule. If no existing PDU session associated with the URSP rule is found, the MBB device needs to establish a new PDU session for the host device to use.

[0097] Therefore, the solution provided in this application adopts the principle of "reuse priority" when URSP rules exist. If there is an existing PDU session associated with the URSP rule, the existing PDU session is reused first to avoid creating a new PDU session. This saves the resource overhead caused by creating a new PDU session.

[0098] If S102c and URSP rules do not exist, and there is an existing PDU session associated with the first request, the MBB device reuses the existing PDU session associated with the first request.

[0099] As one possible implementation, the MBB device determines whether a URSP rule exists. If the URSP rule does not exist, the MBB device searches for an existing PDU session associated with the first request. If an existing PDU session associated with the first request is found, the MBB device does not need to create a new PDU session and can reuse the existing PDU session. The host device can then use this existing PDU session to implement communication services.

[0100] If S102d and URSP rules do not exist, and there is no existing PDU session associated with the first request, the MBB device establishes a normal PDU session.

[0101] As one possible implementation, the MBB device determines whether a URSP rule exists. If the URSP rule does not exist, the MBB device searches for an existing PDU session associated with the first request. If no existing PDU session associated with the first request is found, the MBB device can establish a regular PDU session for use by the host device.

[0102] A regular PDU session can be a non-network slicing-based session. Regular PDU sessions differ from network slicing-based sessions. Network slicing-based sessions can divide the network into independent virtual networks according to different service requirements, providing targeted bandwidth, latency, and reliability guarantees.

[0103] For example, a network slice-based session is a session based on URSP rules.

[0104] If S102e and URSP rules do not exist, and there is no existing PDU session associated with the first request, the MBB device establishes local URSP rules and the PDU session associated with the local URSP rules.

[0105] As one possible implementation, the MBB device determines whether a URSP rule exists. If the URSP rule does not exist, the MBB device searches for an existing PDU session associated with the first request. If no existing PDU session associated with the first request is found, the MBB device can establish a new PDU session based on the URSP rule for use by the host device.

[0106] Specifically, considering that no URSP rule exists, the MBB device can create a new local URSP rule and establish a new PDU session based on the local URSP rule for use by the host device.

[0107] Therefore, in this embodiment of the application, even without URSP rules, the principle of "reuse priority" is also adopted. If there is an existing PDU session associated with the first request, the existing PDU session is reused first, which can avoid creating a new PDU session.

[0108] S103, MBB device sends first response to host device.

[0109] Accordingly, the host device receives the first response.

[0110] The first response includes one or more of the following information: the type of PDU session established or reused, the identifier of the PDU session, the slice information of the PDU session, or the data network information of the PDU session.

[0111] The communication method provided in this application embodiment can be adapted to two types of scenarios: "with URSP rules" and "without URSP rules", realizing PDU sessions in all scenarios.

[0112] Furthermore, the "reuse priority" principle is adopted in all scenarios, which can avoid repeatedly creating redundant PDU sessions, thereby reducing network-side resource consumption (such as bandwidth and slice resources) and device processing overhead, shortening session establishment latency, and thus improving session establishment efficiency and resource utilization.

[0113] In addition, in scenarios without URSP rules, it supports the creation of local URSP rules and the establishment of PDU sessions based on local URSP rules, thus providing better network performance for host devices.

[0114] The aforementioned host device can request data dialing services based on the default URSP rules or data dialing services based on non-default URSP rules through a first request. The following sections will describe each case separately: Scenario 1: The host device requests data dialing service based on the default URSP rules. In scenario one, the MBB device is not registered with the SA or the SA does not have a matching URSP rule for the host device. This corresponds to the case where the URSP rule does not exist.

[0115] For example, Figure 5A This is a flowchart example of a method according to an embodiment of this application. The method may include steps S101a1, S201-S202, and S103a. The specific implementation of each step is described below: S101a1, The host device sends a connection request (MBIM_CID_CONNECT Set request). Correspondingly, the MBB device receives this connection request.

[0116] This connection request is an example of a first request used by a host device to request the establishment of a PDU session (PDU data dialing). This connection request may include activation information for activating the default rule (MBIMActivationOptionDefault).

[0117] As one possible implementation, the host device does not obtain the URSP rules associated with the current SIM and sends the connection request to the MBB device through the basic connection service to request the reconstructed CID CONNECT service.

[0118] Optionally, the connection request may also include an active state, used to control the establishment, modification, or release of the PDU session.

[0119] Optionally, the connection request may also include a Session ID and / or Session type.

[0120] S201, MBB devices execute URSP rule processing.

[0121] As one possible implementation, after receiving a connection request (an example of a first request), the connection module does not find an available URSP rule in the policy cache. In this case, the connection module can determine whether a PDU session is associated with the connection request. The following describes three sub-cases: Sub-case 1: In this seed scenario, the first request also includes a slice parameter, and there exists an existing PDU session associated with the first request, which can refer to the existence of a PDU session associated with the slice parameter. In this case, the existing PDU session is reused.

[0122] Slice parameters are parameters that characterize slice attributes and are used to determine network slices. As one possible implementation, slice parameters include a slice identifier and / or data network information. For example, the slice identifier could be S-NSSAI. The data network information could be a data network name (DNN).

[0123] As one possible implementation, the connection request may include an Access Point Name (APN). The connection module can determine whether the APN indicates a Data Network Node (DNN). For example, if the APN contains an underscore ("_"), it is considered to indicate a DNN. This means that the host device is requesting a PDU session based on network slicing. The connection module can then parse the DNN and search for an existing PDU session associated with that DNN in the session cache. If an existing PDU session associated with the DNN is found, the connection request from the host device can be associated with that existing PDU session in the session cache to reuse the PDU session.

[0124] Sub-case 2: In this seed scenario, there is no existing PDU session associated with the first request. Specifically, the first request includes slice parameters, and there is no existing PDU session associated with those slice parameters. In this case, the MBB device establishes local URSP rules and establishes a PDU session based on those local URSP rules.

[0125] Unlike sub-case 1, in sub-case 2, since there is no existing reusable PDU session, the MBB device can create a PDU session for communication with the host device. As a possible implementation, if the APN in the first request does not indicate a DNN, or if the APN in the first request indicates a DNN but the MBB device does not find a URSP rule associated with that DNN in the session cache, then the MBB device determines that there is no URSP rule associated with that DNN, nor is there an existing PDU session associated with that URSP rule. In this case, the MBB device can determine whether the first request includes S-NSSAI. If the first request includes S-NSSAI, the MBB device can attempt to create a local URSP rule and, based on the local URSP rule, request the modem layer to establish a new PDU session.

[0126] As one possible implementation, the connection module initiates a session establishment request to the NAS through the information interfaces of the application layer and the modem layer, in order to establish a PDU session based on network slices. For example, the session establishment request may include one or more of the following information: S-NSSAI, DNN, or Session type.

[0127] As one possible implementation, the MBB device can record the session performance (such as packet loss rate and latency) corresponding to local URSP rules. When the session performance corresponding to a URSP rule falls below a threshold, the local URSP rule is automatically adjusted, and the adjusted URSP rule is synchronized to the policy cache. This improves the adaptability of local URSP rules, thereby enhancing the communication performance of the corresponding session.

[0128] Sub-case 3: In sub-case 3, there is no existing PDU session associated with the first request. Specifically, the first request does not include slicing parameters, meaning that the host device is not requesting a PDU session based on network slicing. In this case, the MBB device can initiate a session establishment request to the modem layer through the connection module to establish a regular PDU session for the host device to use.

[0129] S202, MBB devices record connection session information.

[0130] As one possible implementation, MBB devices record connection session information through a session cache for session management. The following sections describe different scenarios: Corresponding to sub-case 1 above, the connection module can indicate the information of reusable sessions to the session cache, and the session cache can associate the reusable sessions with the corresponding URSP rules.

[0131] Corresponding to sub-case 2 above, the MBB device can associate the created session with the local URSP rule and record it in the session cache.

[0132] Corresponding to sub-case 3 above, the MBB device will record the created ordinary PDU session in the SessionsCache.

[0133] S103a, the MBB device sends a connection response (MBIM_CID_CONNECT Set Response). Correspondingly, the host device receives the MBIM_CID_CONNECT Set Response.

[0134] This connection response is an example of the first response.

[0135] For example, the connection response may include one or more of the following information: Success, S-NSSAI, DNN, Session type, or Session ID. Among them, Success is used to indicate that the connection was successful.

[0136] The solution provided in this application embodiment can also support PDU sessions based on network slicing in scenarios where the host device requests activation information for the default rule, thereby improving the communication performance of the host device.

[0137] Furthermore, this scenario also supports session reuse at the slice level, making session matching more accurate and saving resources.

[0138] Scenario 2: The host device requests data dialing service based on a non-default URSP rule. This situation corresponds to the case where the URSP rule exists.

[0139] For example, Figure 5B This is a flowchart example of a method according to an embodiment of this application. The method may include steps S101a2, S301-S302, and S103b. The specific implementation of each step is described below: S101a2, The host device sends a connection request (MBIM_CID_CONNECT Set request). Correspondingly, the MBB device receives the MBIM_CID_CONNECT Set request.

[0140] The connection request may include activation information for activating non-default rules and TD. The activation information for activating non-default rules may be: MBIM activation option non-default user equipment routing policy rule (MBIMactiveOptionPerNonDefaultURSPRule).

[0141] Optionally, the connection request may also include one or more of the following information: Active, Session ID, S-NSSAI, DNN, or Session type.

[0142] As one possible implementation, the MBB device can receive a TD list from the network side. This TD list can be obtained by the MBB device through a query, or it can be actively sent to the MBB device by the network side. Specific implementation details can be found in subsequent embodiments.

[0143] S301 and MBB devices perform URSP rule processing.

[0144] As one possible implementation, after receiving a connection request, the MBB device can match the route selection descriptor (RSD) in the corresponding URSP rule based on the TD in the connection request.

[0145] As one possible implementation, the MBB device prioritizes matching non-default URSP rules. In other words, non-default URSP rules have higher priority than default URSP rules. Specifically, the MBB device determines the matching RSD among the non-default URSP rules that match the TD based on the TD. Conversely, if no matching RSD is found among the non-default URSP rules, the matching RSD among the default URSP rules that match the TD is determined.

[0146] Here, "matching RSD" refers to the RSD that matches the TD in the connection request.

[0147] As one possible implementation, the connection module can query the modem layer for a matching RSD. For example, the connection module can query the NAS via an information interface to see if a matching RSD exists; the NAS returns a matching RSD from a non-default URSP rule, or a matching RSD from the default URSP rule.

[0148] Based on the matching results of RSD, the following are the different scenarios: Sub-case A: In some embodiments, when there is an existing PDU session associated with an URSP rule, reusing the existing PDU session associated with the URSP rule can be implemented as follows: if there is an existing PDU session RSD that corresponds to a matching RSD, the existing PDU session can be reused.

[0149] As one possible implementation, the connection module queries the policy cache for the URSP rule corresponding to the matching RSD. If the URSP rule is found and it is associated with an existing PDU session, it means that the RSD of the existing PDU session corresponds to the matching RSD, and the existing PDU session meets the session conditions requested by the host device. In this case, the connection module can instruct the host device to reuse the existing PDU session without creating a new one.

[0150] In some scenarios, the non-default URSP rule to which the matching RSD belongs is associated with an existing PDU session. In this case, the MBB device can create a non-default URSP rule for the host device and associate the created non-default URSP rule with the existing PDU session.

[0151] In other scenarios, the default URSP rule to which the matching RSD belongs is associated with an existing PDU session. In this case, the MBB device can create a default URSP rule for the host device and associate the created default URSP rule with the existing PDU session.

[0152] Sub-case B: If no existing PDU session is associated with a URSP rule, establishing a PDU session associated with a URSP rule can be achieved as follows: if there is no existing PDU session corresponding to an RSD, a PDU session associated with the URSP rule to which the matching RSD belongs is established. In other words, if there is no existing PDU session corresponding to a matching RSD, the MBB device establishes a new PDU session, which is associated with the aforementioned matching RSD or with the URSP rule to which the aforementioned matching RSD belongs.

[0153] As one possible implementation, the connection module queries the policy cache for the URSP rule corresponding to the matching RSD. If the URSP rule is found and it is not associated with an existing PDU session, it means that the existing PDU session does not meet the session conditions requested by the host device. In this case, the connection module can request the modem layer to establish a new PDU session.

[0154] In some scenarios, the non-default URSP rule to which the aforementioned matching RSD belongs is not associated with an existing PDU session. In this case, the MBB device can create a non-default URSP rule for the host device and request the modem layer to establish a new PDU session.

[0155] In some scenarios, the default URSP rule to which the aforementioned matching RSD belongs is not associated with an existing PDU session. In this case, the MBB device can create a default URSP rule for the host device and request the modem layer to establish a new PDU session.

[0156] S302, MBB devices record connection session information.

[0157] For example, if the non-default URSP rule to which the matching RSD belongs is not associated with an existing PDU session, the MBB device can associate the PDU session created for the host device and the non-default URSP rule created for the host device with the session cache.

[0158] Alternatively, if the non-default URSP rule to which the matching RSD belongs is associated with an existing PDU session, then MBB can associate the existing PDU session and the non-default URSP rule created for the host device with the session cache.

[0159] Alternatively, if the default URSP rule to which the above-mentioned matching RSD belongs is not associated with an existing PDU session, the MBB device can associate the PDU session created for the host device and the default URSP rule created for the host device with the session cache.

[0160] Alternatively, if the default URSP rule to which the matching RSD belongs is associated with an existing PDU session, then the MBB can associate the existing PDU session and the default URSP rule created for the host device with the session cache.

[0161] S103b: The MBB device sends a connection response (MBIM_CID_CONNECT Set Response). Correspondingly, the host device receives this MBIM_CID_CONNECT Set Response.

[0162] For example, the connection response may include one or more of the following information: Success, S-NSSAI, DNN, Session type, or Session ID.

[0163] The communication method in this application also provides a URSP rule query function. (See reference...) Figure 6 This is an example of a process for querying URSP rules. The process may include the following steps: S401. The host device sends a device capability query request (Query DEVICE_CAPS_V2). Correspondingly, the MBB device receives this device capability query request.

[0164] Specifically, the device capability query request is used to query the capability information of MBB devices. For example, it can query the feature supplementation capabilities of an MBB device.

[0165] As one possible implementation, the host device requests the service DEVICE_CAPS_V2 from the MBB device through the basic connectivity extension service to obtain the feature supplement capabilities of the MBB device.

[0166] S402, the MBB device sends a device capability query response (Rsp DEVICE_CAPS_V2). Correspondingly, the host device receives the Rsp DEVICE_CAPS_V2.

[0167] As one possible implementation, the MBB device sends a device capability query response through the device capability module.

[0168] The device capability query response may include supplementary features of the MBB device. For example, Rsp DEVICE_CAPS_V2 includes the MBIM control capability UE policy routing (MBIMCtrlCapsUEpolicyRouteSelection), which identifies whether the MBB device has UE policy routing functionality. For example, a bit of 1 indicates that UE policy routing functionality is supported.

[0169] Through the above interaction, the host device can know that the MBB device supports the URSP rule query function, and subsequently, the host device can initiate a URSP rule query to the MBB device accordingly.

[0170] As one possible implementation, when the MBB device detects that a Modem SIM card has been inserted, it can activate a policy module. This policy module registers with the NAS via an information interface and subscribes to the relevant statuses of URSP rules. This policy module can also synchronize the subscribed URSP rules associated with the current SIM card to the network parameter cache.

[0171] As one possible implementation, when the MBB device detects that a Modem SIM has been inserted, it can also trigger the MBIM Subscription Ready Status (MBIM_CID_SUBSCRIBER_READY_STATUS) sub-service of the basic connectivity service to notify the host device of relevant information about the currently inserted SIM card. For example, the SIM card information may include one or more of the following: SIM ready status, integrated circuit card identifier (ICCID), or subscription permanent identifier (SUPI).

[0172] S403, the MBB device sends a user subscription readiness status notification (MBIM_CID_SUBSCRIBER_READY_STATUSnotification). Correspondingly, the host device receives the MBIM_CID_SUBSCRIBER_READY_STATUSnotification.

[0173] The user's subscription readiness status notification may include one or more of the following information: SIM ready, ICCID, or SUPI.

[0174] As one possible implementation, the MBB device sends a notification of the user's subscription readiness status via the basic connectivity service.

[0175] S404. The host device sends a policy query request (Query MBIM_CID_MS_UE_POLICY). Correspondingly, the MBB device receives the Query MBIM_CID_MS_UE_POLICY.

[0176] This policy query request is used to retrieve information about the URSP rules of the MBB device. The relevant information for the URSP rules includes the TD List within the URSP rules.

[0177] As one possible implementation, the host device sends a policy query request to the policy module of the MBB device through the basic connectivity extension service to obtain the TD List information of the MBB device's URSP rules.

[0178] Since the MBB device has subscribed to the TD List in the NAS into the network parameter cache, the policy module can read the TD List associated with the current SIM from the network parameter cache.

[0179] The S405 MBB device sends a policy query response (Rsp MBIM_CID_MS_UE_POLICY). The host device then receives this policy query response.

[0180] The strategy query response includes a list of TDs.

[0181] As one possible implementation, the MBB device sends the query response through the policy module.

[0182] Please refer to Figure 7 This is another example of a process for querying URSP rules. This process may include the following steps: S501, The network side sends the updated URSP rules. Correspondingly, the MBB device receives the updated URSP rules.

[0183] One possible implementation is that the network side (such as an SA network) triggers URSP rule updates and sends the updated URSP rules to the MBB device. The MBB device stores the updated URSP rules in its network parameter cache. Since the policy module has registered with the NAS and subscribed to URSP rule changes, when the URSP rules are updated, the network parameter cache can send a Basic Connection Extension Service Notification (BC_Ext Service) to the policy module. This notification can carry CID MSUE POLICY signaling. The CID MSUE POLICY signaling can carry the updated TD list.

[0184] The S502 and MBB devices send policy notifications (CID MS UE POLICY notifications). Correspondingly, the host devices receive these policy notifications.

[0185] The policy notification includes an updated list of TDs.

[0186] As one possible implementation, the sub-service policy module of the basic connectivity extension service sends an updated TD List to the host device.

[0187] The communication method in this application embodiment also supports protocol capability negotiation, see reference. Figure 8 This is another example flow of the method. The flow may include the following steps: S601, The host device sends a service query request (Query DEVICE_SERVICES). Correspondingly, the MBB device receives the service query request from the host device.

[0188] This service query request is used to query the services supported by MBB devices under the Mobile Broadband Interface Model (MBIM) extension protocol. The MBIM extension protocol includes MBIMExt4.0.

[0189] As one possible implementation, the host device can request the sub-service DEVICE_SERVICES from the MBB device through the basic connectivity service to obtain the services supported by the MBB device under the MBIM extension protocol. For example, through the above service query request, the host device can obtain the sub-services supported by the basic connectivity service and the sub-services supported by the basic connectivity extension service under MBIMExt4.0.

[0190] The S602 and MBB devices send device service information to the host device. Correspondingly, the host device receives the device service information.

[0191] This device service information is used to indicate the services supported by the MBB device under the MBIM extended protocol.

[0192] As one possible implementation, the MBB device sends a query response that may carry the device's service information. For example, this query response could be a device service response (Rsp DEVICE_SERVICES).

[0193] S603, The host device sends a second request. Accordingly, the MBB device receives the second request from the host device.

[0194] This second request is used to request the MBB device to switch to the extended protocol. This second request can also be referred to as a handover request.

[0195] For example, the second request could be a version query request (Query MBIM_CID_VERSION). This second request could also indicate that the host device supports MBIMext 4.0.

[0196] As one possible implementation, the host device requests the protocol version (MBIM_CID_VERSION) sub-service from the MBB device through the Basic Connectivity Extensions service to request the MBB device to switch to MBIMExt4.0.

[0197] S604 and MBB devices switch to extended protocols based on a second request from the host device.

[0198] As one possible implementation, MBB devices can switch to an extended protocol via a version module.

[0199] The S605 and MBB devices send a handover instruction to the host device. The host device then receives the handover instruction.

[0200] This handover indication is used to instruct the host device to switch to the extended protocol. It can also be understood / replaced as: the handover indication is used to indicate that the MBB device has switched to the extended protocol. Thus, the host device can know from this handover indication that the MBB device has switched to the extended protocol, and therefore, the host device will also switch to the extended protocol accordingly to ensure consistency with the MBB device's protocol.

[0201] For example, the switching indication could be a version response (Rsp MBIM_CID_VERSION).

[0202] For example, an MBB device can register an MBIM_CID_VERSION signaling processing instance and register the activation function of the MBIMExt4.0 hook API. Once the MBIMExt4.0 hook API is successfully activated, the MBB device can send a switching instruction to the host device, informing the host device that it has completed the switch to the MBIMExt4.0 protocol.

[0203] S606. The host device switches to the extended protocol based on the switching instruction.

[0204] For example, after the host device knows that the MBB device has successfully switched to MBIMExt4.0 based on the switching instruction, it also enters MBIMExt4.0 mode to complete the MBIMExt4.0 negotiation.

[0205] This application also provides a solution to multi-slice session conflicts. In this method, when multiple sessions request slice resources corresponding to the same URSP rule, the MBB device can dynamically allocate slice resources based on service priority. When a high-priority service (such as industrial control service) preempts resources, a low-priority service (such as ordinary internet access service) is automatically downgraded to a normal session or queued. After the conflict is resolved, the slice connection of the low-priority service can be automatically restored.

[0206] The above primarily describes the solutions provided by the embodiments of this application from a methodological perspective. It is understood that, in order to achieve the above functions, the electronic device includes hardware structures and / or software modules corresponding to the execution of each function. Based on the units and algorithm steps of the various examples described in the embodiments disclosed in this application, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by a computer driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the technical solutions of the embodiments of this application.

[0207] This application embodiment can divide the electronic device into functional modules according to the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional module. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0208] For example, Figure 9 A schematic diagram of an electronic device provided in an embodiment of this application is shown. This electronic device may be an MBB device.

[0209] like Figure 9 As shown, the electronic device 500 may include a processor 510. Optionally, the electronic device may also include a memory 520, etc.

[0210] Processor 510 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors. The processor may correspond to... Figure 1 The processing module.

[0211] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0212] The processor 510 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 510 is a cache memory. This memory can store instructions or data that the processor 510 has just used or that are used repeatedly. If the processor 510 needs to use the instruction or data again, it can directly retrieve it from the memory. This avoids repeated accesses, reduces the waiting time of the processor 510, and thus improves the efficiency of the system.

[0213] In some embodiments, processor 510 may include one or more interfaces. These one or more interfaces may be used to connect processor 510 to memory 520.

[0214] The memory 520 can be used to store computer executable program code, which includes instructions. The memory 520 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as image playback), etc. The data storage area may store data created during the use of the electronic device 500, etc. The processor 510 executes various functional applications and data processing of the electronic device 500 by running instructions stored in the memory 520 and / or instructions stored in memory located within the processor.

[0215] The memory can correspond to Figure 1 Storage module.

[0216] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device. In other embodiments of this application, the electronic device may include... Figure 9The diagram shows more or fewer components, or combinations of components, or separate components, or different arrangements of components. The components shown can be implemented in hardware, software, or a combination of both.

[0217] This application also provides a chip system including at least one processor 2301 and at least one interface circuit 2302. The processor 2301 and the interface circuit 2302 are interconnected via lines. For example, the interface circuit 2302 can be used to receive signals from other devices. As another example, the interface circuit 2302 can be used to send signals to other devices (e.g., the processor 2301). Exemplarily, the interface circuit 2302 can read instructions stored in a memory and send those instructions to the processor 2301. When the instructions are executed by the processor 2301, the electronic device can perform the various steps performed by the electronic device in the above embodiments. Of course, the chip system may also include other discrete devices, and this application does not specifically limit this.

[0218] Optionally, the chip system may contain one or more processors. These processors can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, an integrated circuit, etc. When implemented in software, the processor can be a general-purpose processor, implemented by reading software code stored in memory.

[0219] Optionally, the chip system may contain one or more memories. The memory may be integrated with the processor or disposed separately from it; this application does not limit this. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or disposed separately on different chips. This application does not specifically limit the type of memory or the arrangement of the memory and processor.

[0220] For example, the chip system can be a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a micro controller unit (MCU), a programmable logic device (PLD), or other integrated chips.

[0221] It should be understood that each step in the above method embodiments can be completed by integrated logic circuits in the processor hardware or by instructions in software form. The method steps disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules in the processor.

[0222] It should be noted that the electronic device provided in this application embodiment belongs to the same concept as the method in the above embodiment. Any of the methods provided in the method embodiment can be run on the electronic device. For details of the specific implementation process, please refer to the method embodiment, which will not be repeated here. The embodiments, implementation methods and related technical features of this application can be combined and substituted with each other without conflict.

[0223] This application also provides a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer to perform the methods described in any of the above embodiments.

[0224] In the embodiments of this application, the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM), etc.

[0225] It should be noted that, for the methods of the embodiments of this application, those skilled in the art will understand that all or part of the processes of the methods of the embodiments of this application can be implemented by a computer program controlling related hardware. This computer program can be stored in a computer-readable storage medium, such as in the memory of an electronic device, and executed by at least one processor within the electronic device. During execution, it can include the processes of the embodiments of the method. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, etc.

[0226] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0227] The above are merely preferred embodiments of this application and are not intended to limit this application in any way. Although this application has disclosed preferred embodiments as above, it is not intended to limit this application. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the technical solution of this application. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of this application without departing from the scope of the technical solution of this application shall still fall within the scope of the technical solution of this application.

Claims

1. A communication method, characterized in that, Applied to mobile broadband (MBB) devices, the method includes: The first requirement for obtaining host devices to establish Packet Data Unit (PDU) sessions; Based on the existence status of the User Equipment Routing Policy (URSP) rules and the existence status of existing PDU sessions matching the first requirement, a processing strategy for the PDU session is determined; the processing strategy includes: reusing the existing PDU session, establishing a PDU session associated with the URSP rule, establishing a normal PDU session, or establishing a local URSP rule and a PDU session associated with the local URSP rule. Based on the processing strategy, a first response is sent to the host device, the first response including the processing result of the PDU session.

2. The method according to claim 1, characterized in that, Based on the existence status of the User Equipment Routing Policy (URSP) rules and the existence status of existing PDU sessions matching the first requirement, the processing strategy for the PDU session is determined, including: If the URSP rule exists: if an existing PDU session associated with the URSP rule exists, the existing PDU session associated with the URSP rule is reused; or, if an existing PDU session associated with the URSP rule does not exist, a PDU session associated with the URSP rule is established. Alternatively, if the URSP rule does not exist: if an existing PDU session associated with the first requirement exists, the existing PDU session associated with the first requirement is reused; or, if an existing PDU session associated with the first requirement does not exist, the ordinary PDU session is established; or, if an existing PDU session associated with the first requirement does not exist, the local URSP rule and the PDU session associated with the local URSP rule are established.

3. The method according to claim 2, characterized in that, The first requirement includes activation information and slice parameters for activating the default rule; If an existing PDU session associated with the first requirement exists, reusing the existing PDU session associated with the first requirement includes: If an existing PDU session exists that is associated with the slice parameter, the existing PDU session is reused.

4. The method according to claim 2, characterized in that, The first requirement includes activation information for activating the default rule; If no existing PDU session associated with the first requirement exists, establish the local URSP rule and the PDU session associated with the local URSP rule, including: The first requirement includes slice parameters, and if there is no existing PDU session associated with the slice parameters, the local URSP rule is established, and the PDU session is established based on the local URSP rule; If no existing PDU session associated with the first requirement exists, establish the ordinary PDU session, including: If the first requirement does not include the slice parameters, then establish the normal PDU session.

5. The method according to claim 2, characterized in that, The first requirement includes activation information and path descriptor TD for activating non-default rules; the method further includes: Based on the TD, determine the matching route selection descriptor RSD in the non-default URSP rule that matches the TD; If no matching RSD is found in a non-default URSP rule, then the matching RSD in the default URSP rule that matches the TD is determined.

6. The method according to claim 5, characterized in that, If an existing PDU session associated with the URSP rule exists, reusing the existing PDU session associated with the URSP rule includes: If an existing PDU session's RSD corresponds to the matching RSD, the existing PDU session is reused. If the existing PDU session associated with the URSP rule does not exist, establish the PDU session associated with the URSP rule, including: If there is no existing PDU session RSD corresponding to the matching RSD, a PDU session associated with the URSP rule to which the matching RSD belongs is established.

7. The method according to any one of claims 1-6, characterized in that, Also includes: If an update to the URSP rule is detected, the updated URSP rule is sent to the host device.

8. The method according to claim 7, characterized in that, Also includes: Receive a rule query request from the host device, the rule query request being used to request a query for URSP rules.

9. The method according to any one of claims 1-6, characterized in that, Also includes: Receive a service query request from the host device, the service query request being used to query the services supported by the MBB device under the Mobile Broadband Interface Model (MBIM) Extended Protocol; Send device service information to the host device, wherein the device service information is used to indicate the services supported by the MBB device under the MBIM extension protocol; Receive a handover request from the host device, the handover request being used to request the MBB device to switch to the extended protocol; Based on the switching request, switch to the extended protocol and send a switching instruction to the host device, the switching instruction being used to instruct the host device to switch to the extended protocol.

10. A communication device, characterized in that, It includes a processor and a communication interface, the communication interface being used to receive and / or transmit signals, and the processor being configured to enable the method of any one of claims 1 to 9 to be executed.

11. A computer-readable storage medium, characterized in that, Includes a program or instructions, which, when executed, implement the method as described in any one of claims 1 to 9.

Images