Method, device and storage medium for local offloading

Abstract

The application provides a local offloading implementation method, device and storage medium. The local offloading implementation method applied to a first network element comprises the following steps: obtaining a local offloading strategy; and sending the local offloading strategy to a second network element.

Description

Technical Field

[0001] This application relates to the field of communication technology, specifically to a method, device, and storage medium for implementing local traffic offloading. Background Technology

[0002] Edge computing is one of the key features of 5G. When operators deploy edge computing on their local networks, it impacts existing network infrastructure. For example, when deploying a new edge computing User Plane Function (UPF), the operator's network needs to modify the Session Management Function (SMF) and Policy Control Function (PCF) to support Data Network Access Identifier (DNAI) configuration. Simultaneously, the SMF / PCF needs to participate in edge computing-related processes. This increases the configuration complexity and processing load of the operator's network and hinders rapid local deployment of edge computing. Summary of the Invention

[0003] In view of this, embodiments of this application provide a method, device, and storage medium for implementing local traffic offloading, which reduces the impact on operator networks, thereby enabling operators to quickly deploy edge computing.

[0004] This application provides a method for implementing local traffic offloading, applied to a first network element, including:

[0005] Get the local traffic splitting strategy;

[0006] The local traffic offloading strategy is sent to the second network element.

[0007] This application provides a method for implementing local traffic offloading, applied to a second network element, including:

[0008] Receive the local traffic offloading strategy sent by the first network element;

[0009] Based on the local traffic offloading strategy, a fifth network element is selected, and a control plane connection session is established with the fifth network element.

[0010] Report the data usage information of the offloaded data associated with the fifth network element.

[0011] This application provides a local traffic offloading implementation apparatus, applied to a first network element, comprising:

[0012] The acquisition module is configured to acquire the local traffic distribution strategy.

[0013] The sending module is configured to send the local traffic splitting strategy to the second network element.

[0014] This application provides a local traffic offloading implementation apparatus, applied to a second network element, comprising:

[0015] The receiving module is configured to receive the local traffic offloading strategy sent by the first network element;

[0016] Establish a module, configured to select a fifth network element based on the local traffic splitting strategy, and establish a control plane connection session with the fifth network element;

[0017] The reporting module is configured to report the usage information of the diversion data associated with the fifth network element.

[0018] This application provides a communication device, including: a memory, and one or more processors;

[0019] The memory is configured to store one or more programs;

[0020] When the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any of the above embodiments.

[0021] This application provides a storage medium storing a computer program, which, when executed by a processor, implements the methods described in any of the above embodiments. Attached Figure Description

[0022] Figure 1 This is a structural block diagram of a 5G network architecture provided by existing technology;

[0023] Figure 2 This is a flowchart illustrating a local traffic offloading implementation method provided in an embodiment of this application;

[0024] Figure 3 This is a flowchart of another local traffic splitting implementation method provided in the embodiments of this application;

[0025] Figure 4 This is a flowchart of inserting an I-SMF into an AMF during the PDU session establishment process, as provided in an embodiment of this application.

[0026] Figure 5 This application provides a flowchart of an I-SMF insertion triggered by an SMF after a PDU session is established.

[0027] Figure 6 This is a flowchart illustrating how L-UPF insertion is triggered based on user data after I-SMF insertion, as provided in an embodiment of this application.

[0028] Figure 7This is a structural block diagram of a local traffic offloading implementation device provided in an embodiment of this application.

[0029] Figure 8 This is a structural block diagram of another local traffic splitting implementation device provided in the embodiments of this application;

[0030] Figure 9 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application. Detailed Implementation

[0031] The embodiments of this application will be described below with reference to the accompanying drawings. The examples given are for illustrative purposes only and are not intended to limit the scope of this application.

[0032] Figure 1 This is a structural block diagram of a 5G network architecture provided by existing technology. For example... Figure 1 As shown in the diagram, the following network functions are included:

[0033] User Equipment (UE): The terminal accesses the RAN through the Uu port and the core network element AMF through the N1 interface.

[0034] Radio Access Network (RAN): Also known as a wireless base station, it is responsible for resource allocation of the Uu interface and access control of terminals.

[0035] Access and Mobility Management Function (AMF): Manages user access to the network and is responsible for functions such as NAS (Non-Access Stratum) signaling management and user mobility management from the terminal to the network.

[0036] Unified Data Management (UDM): This is the permanent storage location for user subscription data, located within the user's home network.

[0037] The Unified Data Repository (UDR) is used to provide the following functions: UDM data storage and retrieval, PCF data storage and retrieval, structured data storage and capability exposure, and application data storage and retrieval (including Packet Stream Description (PFD) for application detection, AF request information for multiple UEs, etc.).

[0038] The Session Management Function (SMF) manages user Packet Data Unit (PDU) sessions and QoS flows, and sets packet detection and forwarding rules for the UPF. The SMF is configured locally or receives session policy control rules from the PCF, which control the data transmission path and QoS policies between the UPF and the terminal. The SMF may also be configured with a specific service area. If the terminal moves to an area where the SMF cannot provide service, the PDU session requires an intermediate SMF (I-SMF) to control communication between the I-UPF and the local base station via the N3 interface. The I-SMF can also control the I-UPF and handle local offloading services.

[0039] User Plane Function (UPF): Based on the rules issued by the SMF, it is responsible for routing and forwarding IP data and non-IP data, as well as usage reporting. UPF is further divided into PDU Session Anchor (PSA, used to access the data network), Local-UPF (L-UPF, used to access the local network of edge computing), and Intermediate UPF (I-UPF, used for data offloading). I-UPF supports two offloading methods: Uplink Classifier and Branch Point.

[0040] Policy Control Function (PCF): Based on user subscriptions, application requirements, and local configuration, the PCF provides session policy rules to the SMF. Simultaneously, the PCF can also send URSP(xxx) rules to the terminal through the AMF, controlling the terminal to generate appropriate PDU session parameters according to different application requests.

[0041] Network Exposure Function (NEF): Its functions include exposing network information capabilities and providing interfaces that enable external applications to dynamically control the 5G core network; NEF is responsible for authorizing and authenticating application requests, converting data formats, and adapting protocols for requests.

[0042] Network Repository Function (NRF): In a service-oriented architecture, the NRF is used to register and store configuration information for network functions and services. It provides functions such as service discovery, network slicing management, and network function configuration information. By providing service registration and discovery, network function management, network slicing management, service policy management, and resource management and optimization, the NRF ensures the availability, discoverability, and efficient utilization of network resources, providing more flexible, scalable, and intelligent services for 5G networks.

[0043] In the above architecture, there is also an N4 interface between the L-UPF and I-SMF in the local network. However, the information on this N4 interface is controlled by the SMF of the operator network. For example, the SMF needs to send the following information from the N4 interface to the L-UPF for different DNAIs:

[0044] Packet Detection Rule (PDR): Used to identify and classify user plane traffic in order to apply specific policies and rules.

[0045] Forwarding Action Rule (FAR): Defines how to handle packets that match the PDR, such as forwarding, dropping, or buffering them.

[0046] QoS Enforcement Rule (QER): Used to ensure the quality of service for data streams, including parameters such as bandwidth, latency, and reliability.

[0047] Usage Reporting Rule (URR): Used to collect and report network resource usage, which is crucial for billing and network management.

[0048] This application proposes a local traffic offloading scheme in which the L-UPF is autonomously controlled by the local I-SMF. All the aforementioned rules are generated by the I-SMF and distributed to the L-UPF, thereby reducing the impact on the operator's network. To achieve this function, the SMF needs to send some necessary information to the I-SMF, and then the I-SMF actively establishes a control plane connection session (e.g., an N4 session) with the L-UPF.

[0049] The solution for implementing local traffic offloading proposed in this application consists of three steps:

[0050] 1. During the establishment of a PDU session, the AMF selects an I-SMF that supports local traffic splitting for the PDU session, or after the PDU session is established, the SMF notifies the AMF to insert an I-SMF that supports local traffic splitting.

[0051] 2. During or after the I-SMF insertion process, the SMF notifies the I-SMF to allow local traffic offloading, optionally carrying the offloading strategy.

[0052] 3. When SMF detects application data that needs to be offloaded, it selects L-PSA and establishes an N4 session to L-PSA, based on the offloading strategy provided by SMF or the local offloading strategy.

[0053] In one embodiment, Figure 2 This is a flowchart illustrating a method for implementing local traffic offloading according to an embodiment of this application. This embodiment is applied to the implementation of local traffic offloading. This embodiment can be executed by a first network element. For example, the first network element can be an SMF; the second network element can be an I-SMF. Figure 2 As shown, this embodiment includes: S110-S120.

[0054] S110, Obtain the local traffic distribution strategy.

[0055] S120, Send the local traffic offloading policy to the second network element.

[0056] In one example, the first network element can obtain local traffic offloading policies from other network elements or configure local traffic offloading policies locally; then, the local traffic offloading policies are sent to the second network element that supports local traffic offloading, so that the second network element can perform local traffic offloading, thereby reducing the impact on the operator's network.

[0057] In one embodiment, before obtaining the local traffic offloading policy, the method further includes receiving a data transmission session establishment request. In one example, the data transmission session establishment request refers to a PDU session establishment request. In one example, the second network element can initiate a data transmission session establishment request to the first network element, and carry information such as S-NSSAI, DNN, SSC mode, user's current location information, user access system information, and I-UPF downlink N9 tunnel identifier in the data transmission session establishment request.

[0058] In one embodiment, obtaining the local traffic offloading strategy includes at least one of the following:

[0059] During the data transmission session establishment process, configure local traffic splitting strategies locally;

[0060] During or after the data transmission session is established, the system receives the session subscription response message returned by the third network element and obtains the local traffic offloading strategy from the session subscription response message.

[0061] During or after the data transmission session is established, the system receives the session policy association creation response message returned by the fourth network element and obtains the local traffic splitting policy from the session policy association creation response message.

[0062] For example, the third network element can be a UDM; the fourth network element can be a PCF. In one example, the first network element can directly implement a local traffic offloading policy. In one example, during the data transmission session establishment process or after the data transmission session is established, the fourth network element can obtain user subscription data from the UDR and generate session policy information (SMPolicy) according to the local policy; then, after receiving a request from the first network element, the fourth network element returns the session policy information to the first network element through a session policy association creation response message, and carries the local traffic offloading policy in the session policy information. In one example, the third network element can return user session subscription data (also referred to as UE session subscription data) to the first network element through a session subscription response message, and include the local traffic offloading policy in the user session subscription data.

[0063] In one embodiment, the local offloading strategy includes: local offloading indication information for the data transmission session.

[0064] In one embodiment, sending the local traffic offloading policy to the second network element includes:

[0065] The local traffic offloading strategy is sent to the second network element through a data transmission session response message.

[0066] Alternatively, the local traffic offloading strategy can be sent to the second network element via a data transmission session update request message.

[0067] In one embodiment, the local offloading policy includes at least one of the following: a data access identifier; local offloading permission indication information; a fourth network element address; a sixth network element address; and a billing identifier. In one example, the local offloading permission indication information is used to indicate whether local offloading is allowed; the fourth network element address refers to the PCF address, and the sixth network element address refers to the CHF address.

[0068] In one embodiment, the local traffic offloading strategy further includes: for each data access identifier, supporting a range of destination addresses or a fully qualified domain name (FQDN) for local traffic offloading. Furthermore, if the local traffic offloading indication information indicates that local traffic offloading is permitted, information such as which destination address ranges or domain names (FQDNs) are allowed for local traffic offloading can be provided for each data access identifier.

[0069] In one embodiment, Figure 3 This is a flowchart illustrating another local traffic offloading implementation method provided in this application embodiment. This embodiment is applied to the dynamic configuration of CPU core frequencies in a high-performance UPF (User-Defined Function) of cloud system infrastructure. This embodiment can be executed by a resource management component. Figure 3 As shown, this embodiment includes: S210-S230.

[0070] S210, Receive the local traffic splitting strategy sent by the first network element.

[0071] S220: Select the fifth network element based on the local traffic splitting strategy and establish a control plane connection session with the fifth network element.

[0072] S230, Report the data usage information of the diversion associated with the fifth network element.

[0073] In one embodiment, the method for implementing local traffic offloading applied to the second network element further includes:

[0074] A traffic splitting detection strategy is generated based on local configuration information and local traffic splitting strategy for data transmission sessions;

[0075] Alternatively, the traffic splitting detection strategy for data transmission sessions can be determined based on local configuration information.

[0076] In one embodiment, the traffic splitting detection strategy includes: the fully qualified domain name and IP address range to be detected.

[0077] In one embodiment, reporting offloaded data usage information includes at least one of the following:

[0078] Report the data usage information of the offloaded data associated with the fifth network element to the fourth network element;

[0079] Report the usage information and billing identifier of the diversion data associated with the fifth network element to the sixth network element.

[0080] In one embodiment, receiving the local traffic offloading strategy sent by the first network element includes:

[0081] Receive a data transmission session establishment response message carrying the local traffic offloading policy sent by the first network element;

[0082] Alternatively, it can receive a data transmission session update request message carrying the local traffic offloading strategy sent by the first network element.

[0083] In one embodiment, the local offloading strategy includes at least one of the following: a data access identifier; local offloading permission indication information; a fourth network element address; a sixth network element address; and a billing identifier.

[0084] It should be noted that the explanations of parameters such as the local traffic splitting strategy, the fourth network element address, and the sixth network element address involved in the implementation method of local traffic splitting applied to the second network element can be found in the descriptions of the corresponding parameters in the implementation method of local traffic splitting applied to the first network element, and will not be repeated here.

[0085] In the following embodiments one to three, the implementation process of local traffic offloading is explained using the following network elements as examples: the first network element is SMF, the second network element is I-SMF, the third network element is UDM, the fourth network element is PCF, the fifth network element is L-UPF, and the sixth network element is CHF.

[0086] Example 1

[0087] Figure 4 This is a flowchart of inserting I-SMF into AMF during the PDU session establishment process, as provided in an embodiment of this application.

[0088] like Figure 4 As shown, in this embodiment, the process of inserting I-SMF into AMF during PDU session establishment includes the following steps:

[0089] 1. The UE sends a PDU Session Establishment Request to the AMF via the RAN. This message carries the S-NSSAI, Data Network Name (DNN), Session and Service Continuity (SSC) mode, and the PDU session identifier assigned by the UE for the PDU session. The UE determines the S-NSSAI, DNN, and SSC mode that the application can use based on local policies.

[0090] 2. The AMF selects a suitable SMF for the UE based on the UE's PDU session establishment request, such as the S-NSSAI and DNN requested by the UE. If the service area of ​​the selected SMF does not include the user's current location, the AMF also selects an I-SMF (Intermediate SMF). If the service area of ​​the SMF includes the current user's local area, the AMF can decide whether to insert an I-SMF for the PDU session to achieve local traffic offloading based on local policies or user subscription information. The aforementioned local policies or user subscription information of the AMF include at least the following: whether local traffic offloading is allowed / required for S-NSSAI and DNN; optionally, it also includes the DNAI (Data Network Access Identifier, used for L-UPF selection) indicating the offloading UPF. If an I-SMF needs to be inserted, the AMF selects an I-SMF based on the user's current location.

[0091] 3. The AMF sends a PDU session context establishment request to the I-SMF. The message carries the S-NSSAI, DNN and SSC modes requested by the UE, the SMF address information selected by the AMF, and the user's current access system information and location information.

[0092] 4. The I-SMF returns a response message to the AMF, indicating that the I-SMF has received the above request message.

[0093] 5. The I-SMF selects the I-UPF and then establishes N4 session information with the I-UPF. The I-SMF initiates a PDU session establishment request to the SMF, and the message carries information such as S-NSSAI, DNN, SSC mode, user's current location information, user access system information, and I-UPF downlink N9 tunnel identifier.

[0094] 6. The SMF initiates a session subscription data acquisition request to the UDM, carrying the S-NSSAI and DNN requested by the UE, the user's current location information, and the user's access system information.

[0095] 7. The UDM returns the UE session subscription data for the S-NSSAI and DNN to the SMF. Optionally, this subscription information includes a local offloading policy, such as: local offloading indication information, an indication of whether local offloading is allowed, and information on which destination address ranges or domain names (Fully Qualified Domain Names) are allowed for local offloading for each DNAI.

[0096] 8. The SMF selects a suitable PCF and then sends a session policy association creation request to the PCF, carrying the S-NSSAI and DNN requested by the UE, the user's current location information, and the user's access system information.

[0097] 9. The PCF obtains user subscription data from the User Data Repository (UDR), generates Session Policy Information (SM Policy) based on the local policy, and then returns the Session Policy Information (SM Policy) to the SMF after receiving the SMF request. In this application, the SM Policy returned by the PCF may also include a local offloading policy, which indicates whether local offloading is allowed, and optionally, for each DNAI, which destination addresses or domain names (FQDNs) are allowed for local offloading.

[0098] 10. Based on information such as S-NSSAI, DNN, and user location (UE location), the SMF selects a suitable UPF and then establishes an N4 session with that UPF, sending the tunnel information of the I-UPF to the UPF. The UPF allocates uplink tunnel information, and the UPF responds to the SMF's request, establishing an N4 session. The UPF allocates an uplink N9 tunnel identifier for this PDU session and returns an N4 session establishment response to the SMF. After the N4 session is successfully established, the SMF returns a PDU session establishment response to the I-SMF, which carries information indicating that the PDU session was successfully established.

[0099] Based on the user's subscription, session policy, and user location, the SMF determines whether the PDU session allows local offloading. If so, the response message also carries the following local offloading information: whether local offloading is allowed, PCF address information, CHF (Charging Function) address information, and the billing identifier of the PDU session. If the SMF has configured a local offloading policy, or if the SMF receives a local offloading policy from the PCF in step 9, or from the UDM in step 7, the message also carries the local offloading policy, which indicates which destination addresses or domain names (FQDNs) are allowed for local offloading.

[0100] If the I-SMF receives an indication to allow traffic offloading from the SMF, the I-SMF generates a traffic offloading detection policy for the PDU session based on the offloading policy received from the SMF and its local configuration. If the I-SMF receives an indication to allow local traffic offloading from the SMF but does not receive an offloading policy, the I-SMF can determine the traffic offloading detection policy for the PDU session based on its local configuration. This traffic offloading detection policy includes information such as the FQDN and IP address range to be detected. The I-SMF configures the traffic offloading detection policy into the I-UPF via the N4 interface. The I-UPF will start detecting user plane data according to this detection policy and report to the I-SMF after detecting the target data (see Example 3).

[0101] 11. The I-SMF sends an N1 / N2 message transfer request to the AMF. This message carries a NAS (Non-access stratum) message to the UE and an AS (N2 Session Setup) message to the RAN. The NAS message is a PDU Session Establishment Accept message, and the AS message contains context information for the PDU session, such as the list of created QoS flow configuration information and the PDU session uplink tunnel identifier assigned by the UPF.

[0102] 12. The AMF sends an N2 interface PDU Session Request message to the RAN, which carries the NAS message and AS message received from the SMF.

[0103] 13. The RAN sends an RRC (Radio Resource Connection Reconfiguration) procedure to the UE, and establishes a suitable radio bearer for the UE based on the PDU session information provided by the SMF; at the same time, the RAN sends a NAS message to the UE.

[0104] 14. After creating radio resources, the RAN returns an N2 interface PDU session ack message to the AMF, which carries the N3 interface resources allocated by the RAN for the PDU session, such as the downlink tunnel identifier.

[0105] On the 15th and 16th, the AMF sends an Update SMContext Request to the I-SMF to update the RAN tunnel identifier of the UPF on the N3 interface. The I-SMF sends an N4 SessionUpdate Request to the I-UPF to update the RAN tunnel identifier on the N3 interface.

[0106] In step 10, the SMF can allocate an IP address to the terminal via the control plane, or it may allocate an IP address to the terminal via the user plane. Afterwards, the SMF registers with the UDM, and the UDM stores the SMF address and the user's IP address in the user session context corresponding to S-NSSAI and DNN.

[0107] Through the above process, the terminal successfully establishes a PDU session and inserts I-SMF and I-UPF into the session. In this embodiment, the SMF sends information on whether local traffic offloading is allowed and the optional local traffic offloading policy to the I-SMF in step 10. The I-SMF then configures the local traffic offloading policy information into the I-UPF. Another embodiment allows the SMF to send the aforementioned information on whether local traffic offloading is allowed and the optional policy information to the I-SMF in a subsequent PDU session update request message; the specific process is similar to the above. Applications on the terminal can use this session to initiate services, such as DNS query requests; refer to Embodiment 3 for subsequent steps.

[0108] Example 2

[0109] Figure 5 This is a flowchart provided in an embodiment of this application, illustrating how an SMF triggers the insertion of an I-SMF after a PDU session is established. Figure 5 As shown, in this embodiment, after the PDU session is established, the SMF triggers the insertion of I-SMF, and the implementation process includes the following steps:

[0110] 1. The UE sends a PDU Session Establishment Request to the AMF via the RAN. This message carries the S-NSSAI, Data Network Name (DNN), Session and Service Continuity (SSC) mode, and the PDU session identifier assigned by the UE for the PDU session. The UE determines the S-NSSAI, DNN, and SSC mode that the application can use based on local policies.

[0111] 2. The AMF selects a suitable SMF for the UE based on the UE's PDU session establishment request, such as the S-NSSAI and DNN requested by the UE. If the service area of ​​the selected SMF does not include the user's current location, the AMF also selects an I-SMF (Intermediate SMF). If the service area of ​​the SMF includes the current user's local area, the AMF can decide not to insert an I-SMF based on local policies.

[0112] 3. The AMF sends a PDU session context establishment request to the SMF. The message carries the S-NSSAI, DNN and SSC modes requested by the UE, as well as the user's current access system information and location information.

[0113] 4. The SMF initiates a session subscription data acquisition request to the UDM, carrying the S-NSSAI and DNN requested by the UE, the user's current location information, and the user's access system information.

[0114] 5. The UDM returns the UE session subscription data for the S-NSSAI and DNN to the SMF. Optional subscription information includes a local offloading policy, such as an indication of whether local offloading is allowed, and information on which destination address ranges or Fully Qualified Domain Names (FQDNs) are allowed for local offloading for each DNAI. [This step is the same as in Example 1]

[0115] 6. The SMF selects a suitable PCF and then sends a session policy association creation request to the PCF, carrying the S-NSSAI and DNN requested by the UE, the user's current location information, and the user's access system information.

[0116] 7. The PCF obtains user subscription data from the UDR (User Data Repository), generates Session Policy Information (SM Policy) based on the local policy, and then returns the Session Policy Information (SM Policy) to the SMF after receiving the SMF request. In this application, the SM Policy returned by the PCF may also include a local offloading policy, which indicates whether local offloading is allowed, and optionally, for each DNAI, which destination addresses or domain names (FQDNs) are allowed for local offloading.

[0117] 8. The SMF returns a PDU session context establishment response to the AMF, indicating that the PDU session has been successfully established.

[0118] 9. The AMF sends a PDU session establishment response to the UE, indicating that the PDU session has been successfully established. If it is necessary to request the base station to allocate user plane resources, the AMF needs to execute steps 12-16 in Example 1.

[0119] 10. If the SMF determines that the PDU session allows local offloading, it sends a PDU session context state notification message to the AMF. This notification message carries an indication of whether local offloading is allowed, as well as optional information such as the DNAI (Distribution Identity) that supports offloading. The SMF may also omit the offloading DNAI information in this step.

[0120] 11. When the AMF receives an indication from the SMF that the PDU session is allowed to be offloaded locally, it determines that no I-SMF has been inserted into the current PDU session, and selects an I-SMF if necessary. If the AMF receives the DNAI for offloading from the SMF, it selects the I-SMF for offloading based on the DNAI.

[0121] 12. The AMF initiates a PDU session context establishment request to the I-SMF. This message carries the user's current location information and the SMF's address information.

[0122] 13. The I-SMF selects the I-UPF and then establishes N4 session information with the I-UPF. The I-SMF initiates a PDU session establishment request to the SMF, and the message carries information such as S-NSSAI, DNN, SSC mode, user's current location information, user access system information, and I-UPF downlink N9 tunnel identifier.

[0123] 14. The I-SMF initiates a PDU session update request to the SMF, which carries information such as the I-UPF downlink N9 tunnel identifier.

[0124] 15. The SMF initiates an N4 session update request to the UPF, sending the N9 tunnel information of the I-UPF to the UPF. The UPF allocates uplink tunnel information, the UPF allocates an uplink N9 tunnel identifier, and returns an N4 session establishment response to the SMF, carrying the uplink N9 tunnel information; the SMF returns a PDU session establishment response to the I-SMF, which carries the N9 tunnel information of the UPF.

[0125] Based on the user's subscription, session policy, and user location, the SMF determines whether the PDU session allows local offloading. If so, the response message also carries the following local offloading information: whether local offloading is allowed, PCF address information, CHF (Charging Function) address information, and the billing identifier of the PDU session. If the SMF has configured a local offloading policy, or if the SMF receives a local offloading policy from the PCF in step 9, or from the UDM in step 7, the message also carries the local offloading policy, which indicates which destination addresses or domain names (FQDNs) are allowed for local offloading.

[0126] If the I-SMF receives an indication to allow traffic offloading from the SMF, the I-SMF generates a traffic offloading detection policy for the PDU session based on the offloading policy received from the SMF and its local configuration. If the I-SMF receives an indication to allow local traffic offloading from the SMF but does not receive an offloading policy, the I-SMF can determine the traffic offloading detection policy for the PDU session based on its local configuration. This traffic offloading detection policy includes information such as the FQDN and IP address range to be detected. The I-SMF configures the traffic offloading detection policy into the I-UPF via the N4 interface. The I-UPF will start detecting user plane data according to this detection policy and report to the I-SMF after detecting the target data (see Example 3).

[0127] 16. If it is necessary to request the base station to update user plane resources, the AMF needs to perform steps 12-16 in Implementation Example 1.

[0128] In step 8, the SMF can allocate an IP address to the terminal via control plane or via user plane. Afterwards, the SMF registers with the UDM, which stores the SMF address and the user's IP address in the user session context corresponding to S-NSSAI and DNN.

[0129] Through the above process, the terminal successfully establishes a PDU session and inserts I-SMF and I-UPF into the session. In this embodiment, the SMF sends information on whether local traffic offloading is allowed and the optional offloading policy to the I-SMF in step 15. The I-SMF then configures the offloading policy information into the I-UPF. Another embodiment allows the SMF to send the aforementioned information on whether local traffic offloading is allowed and the optional policy to the I-SMF in a subsequent PDU session update request message; the specific process is similar to the above. Applications on the terminal can use this session to initiate services, such as DNS query requests; refer to Embodiment 3 for subsequent steps.

[0130] Example 3

[0131] Figure 6 This is a flowchart illustrating how, after I-SMF insertion, L-UPF insertion is triggered based on user data, as provided in an embodiment of this application. Figure 6 As shown, the implementation process of triggering L-UPF insertion based on user data after I-SMF insertion in this embodiment includes the following steps:

[0132] 1. The UE initiates a DNS query request to the network through the established PDU session, carrying parameters such as FQDN.

[0133] 2. I-UPF determines whether the FQDN in the DNS query request matches according to the local traffic splitting detection strategy configured in Embodiment 1 or Embodiment 2. If it matches, the local DNS query request is forwarded to the DNS server in the local network.

[0134] 3. The local network's DNS server performs local DNS resolution to obtain the local server's IP address.

[0135] 4. The local network returns a DNS query response to the I-UPF, carrying the FQDN and the resolved local server IP address.

[0136] 5. If the I-UPF finds that the local server IP address or FQDN matches the detection policy according to the detection policy issued by the I-SMF, the I-UPF will cache the DNS query response locally and report the DNS query response to the I-SMF.

[0137] 6. The I-SMF determines the DNAI for traffic splitting based on the traffic splitting strategy of the PDU session, and then selects the local L-UPF based on the DNAI.

[0138] 7. The I-SMF initiates an N4 session establishment request to the L-PSA. The I-SMF generates N4 session rules based on the local traffic splitting policy. These rules include PDR, FAR, QER, URR, and other rules, as well as local server downlink data to PDU session and QoSflow mapping information. The request also carries the N9 downlink tunnel information allocated by the I-UPF.

[0139] 8. L-UPF allocates uplink tunnel information and returns an N4 session establishment request response.

[0140] 9. The SMF updates the N9 tunnel information of the L-UPF to the I-UPF, thus establishing the N9 tunnel between the I-UPF and the L-UPF. Afterwards, the I-SMF sends a cached DNS query response request to the I-UPF.

[0141] 10. I-UPF returns a cached DNS query response to the terminal, carrying the address information of the local server.

[0142] 11-12, Uplink and Downlink communication occurs between the terminal and the local server. The I-UPF performs local traffic splitting according to the traffic splitting policy. The L-UPF maps the downlink data to the QoS flow in the N9 tunnel of this PDU session.

[0143] 13. According to the URR traffic reporting rules configured in I-SMF, when L-UPF detects that a user's data traffic has reached the threshold, it triggers an event to report to I-SMF.

[0144] 14-15, the I-SMF directly reports traffic events to the PCF / CHF based on the PCF address and / or CHF address received from the SMF. The PCF can adjust its QoS policy and update the PCC rules in the SMF based on the traffic event. When reporting usage to the CHF, the I-SMF also carries the billing identifier of the PDU session, so that the CHF can perform traffic billing for the PDU session based on the usage event.

[0145] In this embodiment, the SMF only needs to authorize local traffic offloading when establishing a PDU session. The offloading user plane and the generation of offloading rules are controlled by the local I-SMF, and the SMF does not need to participate. Therefore, the impact on the operator's network is reduced in the process. At the same time, the PCF and CHF can also monitor the usage of offloaded data, which is conducive to the operator's rapid deployment of edge computing.

[0146] In one embodiment, Figure 7 This is a structural block diagram of a local traffic offloading implementation device provided in an embodiment of this application. This embodiment is applied to a first network element. Figure 7 As shown, the local traffic splitting implementation device in this embodiment includes: an acquisition module 710 and a sending module 720.

[0147] Get module 710, configured to get local traffic distribution strategy;

[0148] The sending module 720 is configured to send the local traffic splitting strategy to the second network element.

[0149] In one embodiment, before obtaining the local traffic offloading strategy, the implementation device for local traffic offloading applied to the first network element further includes:

[0150] The receiving module is configured to receive data transmission session establishment requests.

[0151] In one embodiment, the acquisition module 710 is further configured to be at least one of the following:

[0152] During the data transmission session establishment process, configure local traffic splitting strategies locally;

[0153] During or after the data transmission session is established, a session subscription response message returned by a third network element is received, and a local traffic offloading strategy is obtained from the session subscription response message.

[0154] During or after the data transmission session is established, the system receives a session policy association creation response message returned by the fourth network element and obtains the local traffic splitting policy from the session policy association creation response message.

[0155] In one embodiment, the local traffic offloading strategy includes: local traffic offloading indication information for the data transmission session.

[0156] In one embodiment, the sending module 720 is further configured to:

[0157] The local traffic offloading strategy is sent to the second network element through a data transmission session establishment response message;

[0158] Alternatively, the local traffic splitting strategy can be sent to the second network element via a data transmission session update request message.

[0159] In one embodiment, the local traffic offloading strategy includes at least one of the following: a data access identifier; local traffic offloading permission indication information; a fourth network element address; a sixth network element address; and a billing identifier.

[0160] In one embodiment, the local traffic offloading strategy further includes: for each data access identifier, supporting a destination address range or a fully qualified domain name for local traffic offloading.

[0161] The local traffic splitting implementation device provided in this embodiment is configured to implement... Figure 2 The implementation method of local traffic splitting applied to the first network element in the embodiment shown is similar in principle and technical effect to the local traffic splitting implementation device provided in this embodiment, and will not be described again here.

[0162] In one embodiment, Figure 8 This is a structural block diagram of another local traffic offloading implementation device provided in this application embodiment. This embodiment is applied to a second network element. Figure 8 As shown, the local traffic splitting implementation device in this embodiment includes: a receiving module 810, an establishment module 820, and a reporting module 830.

[0163] The receiving module 810 is configured to receive the local traffic splitting strategy sent by the first network element.

[0164] Establish module 820, configure it to select the fifth network element based on the local traffic splitting strategy, and establish a control plane connection session with the fifth network element.

[0165] The reporting module 830 is configured to report the usage information of the diversion data associated with the fifth network element.

[0166] In one embodiment, the local traffic offloading implementation device applied to the second network element further includes:

[0167] The generation module is configured to generate a traffic splitting detection strategy for data transmission sessions based on local configuration information and local traffic splitting strategy;

[0168] Alternatively, the module can be configured to determine the traffic splitting detection strategy for data transmission sessions based on local configuration information.

[0169] In one embodiment, the traffic splitting detection strategy includes: the fully qualified domain name and IP address range to be detected.

[0170] In one embodiment, reporting offloaded data usage information includes at least one of the following:

[0171] Report the data usage information of the offloaded data associated with the fifth network element to the fourth network element;

[0172] Report the usage information and billing identifier of the diversion data associated with the fifth network element to the sixth network element.

[0173] In one embodiment, the receiving module 810 is further configured to:

[0174] Receive a data transmission session establishment response message carrying the local traffic offloading policy sent by the first network element;

[0175] Alternatively, it can receive a data transmission session update request message carrying the local traffic offloading strategy sent by the first network element.

[0176] In one embodiment, the local offloading strategy includes at least one of the following: a data access identifier; local offloading permission indication information; a fourth network element address; a sixth network element address; and a billing identifier.

[0177] The local traffic splitting implementation device provided in this embodiment is configured to implement... Figure 3 The implementation method of local traffic splitting applied to the second network element in the embodiment shown is similar in principle and technical effect to the local traffic splitting implementation device provided in this embodiment, and will not be described again here.

[0178] In one embodiment, Figure 9 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application. Figure 9 As shown, the device provided in this application includes: a processor 910, a memory 920, and a communication module 930. The device may contain one or more processors 910. Figure 9 Taking a processor 910 as an example, the number of memory units 920 in this device can be one or more. Figure 9Taking a memory 920 as an example, the processor 910, memory 920, and communication module 930 of this device can be connected via a bus or other means. Figure 9 Taking a bus connection as an example, in this embodiment, the device can be either a first network element or a second network element.

[0179] The memory 920, as a computer-readable storage medium, can be configured to store software programs, computer-executable programs, and modules, such as program instructions / modules corresponding to the device in any embodiment of this application (e.g., the acquisition module 710 and the transmission module 720 in the implementation device for local traffic distribution of the first network element, or the receiving module 810, the establishment module 820, and the reporting module 830 in the implementation device for local traffic distribution of the second network element). The memory 920 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and at least one application program required for a function; the data storage area may store data created according to the use of the device, etc. In addition, the memory 920 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 920 may further include memory remotely located relative to the processor 910, and these remote memories can be connected to the device via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0180] When the communication device is the first network element, the device provided above can be configured to execute the local traffic offloading implementation method for the first network element provided in any of the above embodiments, and has the corresponding functions and effects.

[0181] When the communication device is a second network element, the device provided above can be configured to execute the local traffic offloading implementation method for the second network element provided in any of the above embodiments, and has the corresponding functions and effects.

[0182] This application embodiment also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to execute a method for implementing local traffic splitting applied to a first network element. The method includes: obtaining a local traffic splitting strategy; and sending the local traffic splitting strategy to a second network element.

[0183] This application embodiment also provides a storage medium containing computer-executable instructions. When executed by a computer processor, the computer-executable instructions are used to execute a method for implementing local traffic offloading applied to a second network element. The method includes: receiving a local traffic offloading strategy sent by a first network element; selecting a fifth network element based on the local traffic offloading strategy and establishing a control plane connection session with the fifth network element; and reporting the offloading data usage information associated with the fifth network element.

[0184] Those skilled in the art will understand that the term user equipment covers any suitable type of wireless user equipment, such as mobile phones, portable data processing devices, portable web browsers, or vehicle-mounted mobile stations.

[0185] Generally, the various embodiments of this application can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. For example, some aspects can be implemented in hardware, while others can be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device, although this application is not limited thereto.

[0186] Embodiments of this application can be implemented by executing computer program instructions through the data processor of a mobile device, for example, in a processor entity, or through hardware, or through a combination of software and hardware. The computer program instructions can be assembly instructions, Instruction Set Architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages.

[0187] Any block diagram of logical flow in the accompanying drawings of this application may represent program steps, or may represent interconnected logic circuits, modules, and functions, or may represent a combination of program steps and logic circuits, modules, and functions. The computer program may be stored on memory. Memory may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as, but not limited to, read-only memory (ROM), random access memory (RAM), optical storage devices and systems (Digital Video Disc (DVD) or Compact Disk (CD)), etc. Computer-readable media may include non-transitory storage media. The data processor may be of any type suitable to the local technical environment, such as, but not limited to, general-purpose computers, special-purpose computers, microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and processors based on multi-core processor architectures.

[0188] This application also provides a computer program product, including a computer program that, when executed by a processor, can implement the local offloading method provided in any embodiment of this application.

[0189] In the implementation of the computer program product, computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0190] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for implementing local traffic offloading, characterized in that, Applied to the first network element, including: Get the local traffic splitting strategy; The local traffic offloading strategy is sent to the second network element.

2. The method according to claim 1, characterized in that, Before obtaining the local traffic splitting strategy, the following is also included: Receives a data transmission session establishment request.

3. The method according to claim 2, characterized in that, The local traffic distribution strategy includes at least one of the following: During the data transmission session establishment process, configure local traffic splitting strategies locally; During or after the data transmission session is established, a session subscription response message returned by a third network element is received, and a local traffic offloading strategy is obtained from the session subscription response message. During or after the data transmission session is established, the system receives a session policy association creation response message returned by the fourth network element and obtains the local traffic splitting policy from the session policy association creation response message.

4. The method according to claim 1, characterized in that, The local traffic offloading strategy includes: local traffic offloading indication information for data transmission sessions.

5. The method according to claim 1, characterized in that, Sending the local traffic offloading policy to the second network element includes: The local traffic offloading strategy is sent to the second network element through a data transmission session establishment response message; Alternatively, the local traffic splitting strategy can be sent to the second network element via a data transmission session update request message.

6. The method according to any one of claims 1-5, characterized in that, The local traffic offloading strategy includes at least one of the following: data access identifier; local traffic offloading permission indication information; fourth network element address; sixth network element address; billing identifier.

7. The method according to claim 6, characterized in that, The local traffic offloading strategy also includes: for each data access identifier, supporting a range of destination addresses or a fully qualified domain name for local traffic offloading.

8. A method for implementing local traffic offloading, characterized in that, Applied to the second network element, including: Receive the local traffic offloading strategy sent by the first network element; Based on the local traffic offloading strategy, a fifth network element is selected, and a control plane connection session is established with the fifth network element. Report the data usage information of the offloaded data associated with the fifth network element.

9. The method according to claim 8, characterized in that, The method further includes: A traffic splitting detection strategy is generated based on local configuration information and the local traffic splitting strategy to generate a data transmission session; Alternatively, the traffic splitting detection strategy for the data transmission session can be determined based on local configuration information.

10. The method according to claim 9, characterized in that, The traffic diversion detection strategy includes: the fully qualified domain name and IP address range to be detected.

11. The method according to claim 8, characterized in that, The reported data usage information includes at least one of the following: Report the traffic usage information associated with the fifth network element to the fourth network element; The sixth network element reports the diversion data usage information and billing identifier associated with the fifth network element.

12. The method according to claim 8, characterized in that, The local traffic splitting strategy received from the first network element includes: Receive a data transmission session establishment response message carrying the local traffic offloading policy sent by the first network element; Alternatively, it can receive a data transmission session update request message carrying the local traffic offloading strategy sent by the first network element.

13. The method according to any one of claims 8-12, characterized in that, The local traffic offloading strategy includes at least one of the following: data access identifier; local traffic offloading indication information; fourth network element address; sixth network element address and billing identifier.

14. A communication device, characterized in that, include: Memory, and one or more processors; The memory is configured to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors perform the method as described in any one of claims 1-7 or 8-13.

15. A storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1-7 or 8-13.

Images