Communication method and device

Abstract

The invention discloses a communication method and device. The method comprises the following steps: acquiring a flow demand of a service flow; dIP instance information is obtained, the DIP instance information comprises service quality guarantee and / or residual resources of at least one DIP instance, and each DIP instance corresponds to a pre-configured DIP transmission network sub-network; and determining whether the service flow is admitted to a DIP transmission network according to the flow demand of the service flow and the DIP instance information. Through the technical scheme provided by the invention, the admission control of the service flow needing to execute DIP transmission can be realized.

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] Deterministic Internet Protocol (DIP) is a technical architecture for deterministic networking (DetNet) that provides deterministic bearer services. It introduces a periodic scheduling mechanism for forwarding on the data plane and proposes efficient path planning and resource allocation algorithms on the control plane, aiming to achieve a large-scale, scalable, end-to-end deterministic low-latency network system.

[0003] Currently, some mobile communication systems do not support DIP and lack mechanisms and procedures for implementing DIP transmission network access control for service flows. How to implement access control for service flows that need to perform DIP transmission is an unsolved problem. Summary of the Invention

[0004] This application provides a communication method and apparatus that can implement access control for service flows that need to perform DIP transmission.

[0005] In a first aspect, embodiments of this application provide a communication method, including:

[0006] Obtain the flow requirements of the business flow;

[0007] Obtain DIP instance information, which includes the quality of service guarantee and / or remaining resources of at least one DIP instance, and each DIP instance corresponds to a pre-configured DIP transport network subnet;

[0008] The decision on whether a service flow is admitted to the DIP transport network is determined based on the flow requirements of the service flow and the DIP instance information.

[0009] In the above method, a service flow can be understood as a service flow that needs to perform DIP transmission. The quality of service guarantee and / or remaining resources of the DIP instance can be used to indicate the admission threshold of the DIP instance. Based on the flow requirements of the service flow and the DIP instance information, it can be determined whether the flow requirements of the service flow meet the admission threshold of the DIP instance, thereby determining whether the service flow is admitted to the DIP transmission network. In this way, admission control of service flows that need to perform DIP transmission can be achieved.

[0010] In one possible implementation, the quality of service guarantee and / or remaining resources of the DIP instance are used to indicate the admission threshold of the DIP instance;

[0011] The step of determining whether a service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information includes:

[0012] If the at least one DIP instance includes at least one optional DIP instance, then the service flow is determined to be admitted to the DIP transport network; or,

[0013] If the optional DIP instance is not included in the at least one DIP instance, then the service flow is determined not to be admitted to the DIP transport network;

[0014] The optional DIP instance meets the following condition: the flow requirements of the service flow meet the entry requirements of the optional DIP instance.

[0015] In the above embodiments, an optional DIP instance can be understood as a DIP instance that allows a service flow to be admitted. For a DIP instance, if the flow requirements of the service flow meet the admission thresholds of that DIP instance, then that DIP instance can be considered an optional DIP instance. Based on the flow requirements of the service flow and the admission thresholds of the at least one DIP instance, it can be determined whether the at least one DIP instance includes an optional DIP instance. If it does, the service flow is admitted to the DIP transport network; if it does not, the service flow is not admitted to the DIP transport network. This achieves admission determination.

[0016] In one possible implementation, the flow requirements of the service flow include one or more of the following: guaranteed flow bit rate, packet delay budget, maximum frame length, or packet error rate.

[0017] The admission thresholds include one or more of the following: remaining bandwidth resources, latency guarantee, maximum allowed transmission unit, or packet loss rate guarantee.

[0018] The flow requirements of the service flow meet the admission criteria of the optional DIP instance, including one or more of the following:

[0019] The bandwidth resources corresponding to the guaranteed stream bit rate are less than or equal to the remaining bandwidth resources of the optional DIP instance;

[0020] The latency requirement corresponding to the packet latency budget is greater than or equal to the latency guarantee of the optional DIP instance;

[0021] The transmission unit corresponding to the maximum frame length is less than or equal to the maximum transmission unit allowed by the optional DIP instance;

[0022] The packet loss rate corresponding to the error rate is greater than or equal to the packet loss rate guarantee of the optional DIP instance.

[0023] The above embodiments provide some possible conditions for determining whether a DIP instance can be used as an optional DIP instance. By using the above conditions, optional DIP instances can be identified more accurately from the above at least one DIP instance.

[0024] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the method further includes:

[0025] Send information indicating the target DIP instance and the flow requirements of the service flow to the network element storing the DIP instance information, wherein the target DIP instance is one of the at least one optional DIP instance, and is the DIP instance that the service flow is admitted to.

[0026] In the above embodiments, the target DIP instance can be understood as the DIP instance that the service flow is ultimately confirmed to be admitted, or it can be understood as the DIP instance that the service flow will ultimately access. When the execution subject of the above method is not the network element storing the DIP instance information, information indicating the target DIP instance and the flow requirements of the service flow can be sent to the network element storing the DIP instance information. This triggers the network element to update the information of the target DIP instance according to the flow requirements of the service flow, so as to ensure the accuracy of the DIP instance information stored by the network element.

[0027] In another possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the method further includes:

[0028] The information of the target DIP instance is updated based on the flow requirements of the service flow, wherein the target DIP instance is one of the at least one optional DIP instance, and serves as the DIP instance for which the service flow is admitted.

[0029] In the above embodiments, when the execution subject of the above method is the storage network element of DIP instance information, the information of the target DIP instance can be updated based on the flow requirements of the service flow. For example, the current available remaining bandwidth of the target DIP instance can be updated according to the guaranteed flow bit rate in the flow requirements, so as to ensure the accuracy of the DIP instance information stored by the storage network element.

[0030] Optionally, the above method can be applied to the 5th generation (5G) system side. For example, the above method can be executed by user plane function (UPF), radio access network (RAN), session management function (SMF), or policy control function (PCF).

[0031] Optionally, the above method can also be applied to the DIP transport network side. For example, the above method can be executed by the DIP transport network edge node or the DIP transport network controller (e.g., DetNet Controller).

[0032] Optionally, DIP instance information can be stored on the 5G system side. For example, UPF, RAN, or unified data repository (UDR) can serve as the storage network element for DIP instance information.

[0033] Optionally, DIP instance information can also be stored on the DIP transport network side. For example, DIP transport network edge nodes or DIP transport network controllers can serve as network elements for storing DIP instance information.

[0034] It should be understood that the communication systems to which the embodiments of this application are applicable are not limited to 5G systems. The embodiments of this application can also be applied to other communication systems, such as the 6th generation (6G) system or other communication systems that will evolve in the future.

[0035] Furthermore, the network elements (such as UPF, RAN, SMF, PCF, or UDR, etc.) involved in the embodiments of this application are exemplified using names found in 5G systems. In other communication systems, the network elements involved in the embodiments of this application may have other names. Alternatively, in other communication systems, the network elements involved in the embodiments of this application may be replaced by other entities or devices with the same function, and this application does not limit them in any way.

[0036] Secondly, embodiments of this application provide a communication method applied to a UPF, comprising:

[0037] UPF receives the flow requests from SMF for service flows;

[0038] UPF obtains DIP instance information stored in its own memory, or UPF receives DIP instance information from the edge node of the DIP transport network;

[0039] UPF determines whether the service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0040] In the above method, the UPF performs the admission decision. In one scenario, the UPF acts as the storage network element for DIP instance information, thus eliminating the need for additional interaction with the DIP transport network. In another scenario, the edge node of the DIP transport network acts as the storage network element for DIP instance information, providing the DIP instance information to the UPF to assist in admission control.

[0041] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the method further includes:

[0042] UPF identifies a target DIP instance and sends information indicating the target DIP instance and the flow requirements of the service flow to the DIP transport network edge node.

[0043] In the above implementation, the network element storing DIP instance information is the DIP transport network edge node, and the target DIP instance is determined by the UPF. After determining the target DIP instance, the UPF can send information indicating the target DIP instance and the flow requirements of the service flow to the DIP transport network edge node. This triggers the DIP transport network edge node to update the target DIP instance information accordingly based on the flow requirements of the service flow, thereby ensuring the accuracy of the DIP instance information stored by the DIP transport network edge node.

[0044] In another possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the method further includes:

[0045] UPF receives information from SMF indicating the target DIP instance and sends the information indicating the target DIP instance and the flow requirements of the service flow to the DIP transport network edge node.

[0046] In the above implementation, the network element storing DIP instance information is the DIP transport network edge node. The UPF can inform the SMF of the admission judgment result, and the SMF determines the target DIP instance and informs the UPF. After receiving the information indicating the target DIP instance, the UPF can forward the information indicating the target DIP instance and the flow requirements of the service flow to the DIP transport network edge node. This triggers the DIP transport network edge node to update the target DIP instance information accordingly based on the flow requirements of the service flow, thereby ensuring the accuracy of the DIP instance information stored by the DIP transport network edge node.

[0047] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the method further includes:

[0048] UPF identifies the target DIP instance and updates the information of the target DIP instance based on the flow requirements of the service flow.

[0049] In the above implementation, the network element storing DIP instance information is the UPF, which determines the target DIP instance. After determining the target DIP instance, the UPF can update the information of the target DIP instance based on the flow requirements of the service flow. For example, it can update the current available remaining bandwidth of the target DIP instance based on the guaranteed flow bit rate in the flow requirements, thus ensuring the accuracy of the DIP instance information stored in the UPF.

[0050] In another possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the method further includes:

[0051] UPF receives information from SMF indicating the target DIP instance and updates the information of the target DIP instance based on the flow requirements of the service flow.

[0052] In the above implementation, the network element storing DIP instance information is the UPF. The UPF can inform the SMF of the admission judgment result, and the SMF can determine the target DIP instance and inform the UPF. After receiving the information indicating the target DIP instance, the UPF can update the information of the target DIP instance based on the flow requirements of the service flow. For example, it can update the current available remaining bandwidth of the target DIP instance according to the guaranteed flow bit rate in the flow requirements, thus ensuring the accuracy of the DIP instance information stored by the UPF.

[0053] Thirdly, embodiments of this application provide a communication method applied to a RAN, comprising:

[0054] The RAN receives the flow requests from the SMF for service flows;

[0055] The RAN obtains its own stored DIP instance information, or the RAN receives DIP instance information from the edge node of the DIP transport network;

[0056] The RAN determines whether the service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0057] In the above method, the RAN (Radio Access Network) performs the admission decision. In one scenario, the RAN acts as the storage element for DIP instance information, thus eliminating the need for additional interaction with the DIP transport network. In another scenario, the edge node of the DIP transport network acts as the storage element for DIP instance information, providing the RAN with DIP instance information to assist the RAN in implementing admission control.

[0058] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the method further includes:

[0059] The RAN identifies the target DIP instance and sends information indicating the target DIP instance and the flow requirements of the service flow to the DIP transport network edge node.

[0060] In the above implementation, the network element storing DIP instance information is the DIP transport network edge node, and the RAN determines the target DIP instance. After determining the target DIP instance, the RAN can send information indicating the target DIP instance and the flow requirements of the service flow to the DIP transport network edge node. This triggers the DIP transport network edge node to update the target DIP instance information accordingly based on the flow requirements of the service flow, thereby ensuring the accuracy of the DIP instance information stored by the DIP transport network edge node.

[0061] In another possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the method further includes:

[0062] The RAN receives information from the SMF indicating the target DIP instance and sends the information indicating the target DIP instance and the flow requirements of the service flow to the DIP transport network edge node.

[0063] In the above implementation, the network element storing DIP instance information is the DIP transport network edge node. The RAN can inform the SMF of the admission judgment result, and the SMF can determine the target DIP instance and inform the RAN. After receiving the information indicating the target DIP instance, the RAN can forward the information indicating the target DIP instance and the flow requirements of the service flow to the DIP transport network edge node. This triggers the DIP transport network edge node to update the target DIP instance information accordingly based on the flow requirements of the service flow, thereby ensuring the accuracy of the DIP instance information stored by the DIP transport network edge node.

[0064] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the method further includes:

[0065] The RAN determines the target DIP instance and updates the information of the target DIP instance based on the flow requirements of the service flow.

[0066] In the above implementation, the network element storing DIP instance information is the RAN, which determines the target DIP instance. After determining the target DIP instance, the RAN can update the information of the target DIP instance based on the flow requirements of the service flow. For example, it can update the current available remaining bandwidth of the target DIP instance based on the guaranteed flow bit rate in the flow requirements, thus ensuring the accuracy of the DIP instance information stored by the RAN.

[0067] In another possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the method further includes:

[0068] The RAN receives information from the SMF indicating the target DIP instance and updates the information of the target DIP instance based on the flow requirements of the service flow.

[0069] In the above implementation, the network element storing DIP instance information is the RAN. The RAN can inform the SMF of the admission judgment result, and the SMF can determine the target DIP instance and inform the RAN. After receiving the information indicating the target DIP instance, the RAN can update the information of the target DIP instance based on the flow requirements of the service flow. For example, it can update the current available remaining bandwidth of the target DIP instance based on the guaranteed flow bit rate in the flow requirements. This can ensure the accuracy of the DIP instance information stored by the RAN.

[0070] Fourthly, embodiments of this application provide a communication method applied to an SMF, comprising:

[0071] The SMF receives DIP instance information from the UPF, RAN, or DIP transport network controller, or the SMF receives DIP instance information from the UDR via the PCF.

[0072] SMF determines whether the service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0073] In the above methods, the flow requirements of the service flow are known to the SMF. The SMF does not need to obtain the flow requirements from other network elements; the SMF performs the admission judgment. In one scenario, the UPF, RAN, or UDR acts as the network element storing DIP instance information. The UPF, RAN, or UDR provides DIP instance information to the SMF to help the SMF implement admission control, thus eliminating the need for additional interaction with the DIP transport network. In another scenario, the DIP transport network controller acts as the network element storing DIP instance information. The DIP transport network controller provides DIP instance information to the SMF to help the SMF implement admission control.

[0074] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the method further includes:

[0075] The SMF identifies the target DIP instance and sends information indicating the target DIP instance and the flow requirements of the service flow to the UPF, the RAN, or the DIP transport network controller.

[0076] In the above embodiments, the network element storing DIP instance information is the UPF, RAN, or DIP transport network controller, and the SMF determines the target DIP instance. After determining the target DIP instance, the SMF can send information indicating the target DIP instance and the flow requirements of the service flow to the UPF, RAN, or DIP transport network controller. This triggers the UPF, RAN, or DIP transport network controller to update the target DIP instance information accordingly based on the flow requirements of the service flow, thereby ensuring the accuracy of the DIP instance information stored by the UPF, RAN, or DIP transport network controller.

[0077] In another possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the method further includes:

[0078] The SMF identifies the target DIP instance and sends information indicating the target DIP instance and the flow requirements of the service flow to the UDR through the PCF.

[0079] In the above implementation, the network element storing DIP instance information is the UDR, and the SMF determines the target DIP instance. After determining the target DIP instance, the SMF can send information indicating the target DIP instance and the flow requirements of the service flow to the UDR through the PCF. This triggers the UDR to update the information of the target DIP instance accordingly based on the flow requirements of the service flow, so as to ensure the accuracy of the DIP instance information stored in the UDR.

[0080] Fifthly, embodiments of this application provide a communication method applied to a PCF, comprising:

[0081] PCF receives DIP instance information from UDR;

[0082] PCF determines whether a service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0083] In the above method, the flow requirements of the service flow are known to the PCF. The PCF does not need to obtain the flow requirements of the service flow from other network elements; the PCF makes the admission judgment. The UDR, as the network element storing DIP instance information, provides DIP instance information to the SMF to help the PCF implement admission control, thus eliminating the need for additional interaction with the DIP transport network.

[0084] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the method further includes:

[0085] The PCF receives information from the SMF indicating the target DIP instance and sends the information indicating the target DIP instance and the flow requirement of the service flow to the UDR.

[0086] In the above implementation, the PCF can inform the SMF of the admission judgment result, and the SMF can determine the target DIP instance and inform the PCF. After receiving the information indicating the target DIP instance, the PCF can send the information indicating the target DIP instance and the flow requirements of the service flow to the UDR, which can trigger the UDR to update the information of the target DIP instance according to the flow requirements of the service flow, so as to ensure the accuracy of the DIP instance information stored by the UDR.

[0087] Sixthly, embodiments of this application provide a communication method applied to an edge node of a DIP transmission network, comprising:

[0088] DIP transport network edge nodes receive flow requests from UPF / RAN service flows;

[0089] DIP transport network edge nodes obtain their own stored DIP instance information;

[0090] The edge nodes of the DIP transport network determine whether the service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0091] In the above method, the DIP transport network edge node serves as the network element storing DIP instance information, and the admission decision is made by the DIP transport network edge node. The UPF / RAN provides the flow requirements of the service flow to the DIP transport network edge node to help the DIP transport network edge node implement admission control.

[0092] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the method further includes:

[0093] The DIP transport network edge node receives information from UPF / RAN indicating the target DIP instance and updates the information of the target DIP instance based on the flow requirements of the service flow.

[0094] In the above embodiments, the target DIP instance can be determined by the UPF / RAN or the SMF, and the UPF / RAN can inform the DIP transport network edge node of the target DIP instance, or the SMF can inform the DIP transport network edge node of the target DIP instance through the UPF / RAN. After receiving the information indicating the target DIP instance, the DIP transport network edge node can update the information of the target DIP instance based on the flow requirements of the service flow. For example, it can update the current available remaining bandwidth of the target DIP instance according to the guaranteed flow bit rate in the flow requirements. This can ensure the accuracy of the DIP instance information stored by the DIP transport network edge node.

[0095] Seventhly, embodiments of this application provide a communication method applied to a DIP transmission network controller, comprising:

[0096] The DIP transport network controller receives the flow requests for service flows from the SMF;

[0097] The DIP transport network controller obtains the DIP instance information stored within itself;

[0098] The DIP transport network controller determines whether a service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0099] In the above method, the DIP transport network controller serves as the network element storing DIP instance information, and it is responsible for admission control. The SMF provides the DIP transport network controller with the flow requirements of the service traffic to help it implement admission control.

[0100] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the method further includes:

[0101] The DIP transport network controller receives information from the SMF indicating a target DIP instance and updates the information of the target DIP instance based on the flow requirements of the service flow.

[0102] In the above implementation, the SMF can determine the target DIP instance and inform the DIP transport network controller. After receiving the information indicating the target DIP instance, the DIP transport network controller can update the information of the target DIP instance based on the flow requirements of the service flow. For example, it can update the current available remaining bandwidth of the target DIP instance according to the guaranteed flow bit rate in the flow requirements. This can ensure the accuracy of the DIP instance information stored by the DIP transport network controller.

[0103] Eighthly, embodiments of this application provide a communication device that includes modules or units for performing the methods described in the first aspect or any possible implementation thereof.

[0104] In one possible implementation, the device includes:

[0105] The transceiver unit is used to obtain the flow requirements of the service flow and to obtain DIP instance information. The DIP instance information includes the quality of service guarantee and / or remaining resources of at least one DIP instance. Each DIP instance corresponds to a pre-configured DIP transport network subnet.

[0106] The processing unit is used to determine whether the service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0107] In one possible implementation, the quality of service guarantee and / or remaining resources of the DIP instance are used to indicate the admission threshold of the DIP instance;

[0108] The step of determining whether a service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information includes:

[0109] If the at least one DIP instance includes at least one optional DIP instance, then the service flow is determined to be admitted to the DIP transport network; or,

[0110] If the optional DIP instance is not included in the at least one DIP instance, then the service flow is determined not to be admitted to the DIP transport network;

[0111] The optional DIP instance meets the following condition: the flow requirements of the service flow meet the entry requirements of the optional DIP instance.

[0112] In one possible implementation, the flow requirements of the service flow include one or more of the following: guaranteed flow bit rate, packet delay budget, maximum frame length, or packet error rate.

[0113] The admission thresholds include one or more of the following: remaining bandwidth resources, latency guarantee, maximum allowed transmission unit, or packet loss rate guarantee.

[0114] The flow requirements of the service flow meet the admission criteria of the optional DIP instance, including one or more of the following:

[0115] The bandwidth resources corresponding to the guaranteed stream bit rate are less than or equal to the remaining bandwidth resources of the optional DIP instance;

[0116] The latency requirement corresponding to the packet latency budget is greater than or equal to the latency guarantee of the optional DIP instance;

[0117] The transmission unit corresponding to the maximum frame length is less than or equal to the maximum transmission unit allowed by the optional DIP instance;

[0118] The packet loss rate corresponding to the error rate is greater than or equal to the packet loss rate guarantee of the optional DIP instance.

[0119] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the transceiver unit is further configured to:

[0120] Send information indicating the target DIP instance and the flow requirements of the service flow to the network element storing the DIP instance information, wherein the target DIP instance is one of the at least one optional DIP instance, and is the DIP instance that the service flow is admitted to.

[0121] In another possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the processing unit is further configured to:

[0122] The information of the target DIP instance is updated based on the flow requirements of the service flow, wherein the target DIP instance is one of the at least one optional DIP instance, and serves as the DIP instance for which the service flow is admitted.

[0123] Optionally, the above-mentioned device can be applied to the 5G system side. For example, the above-mentioned device can be applied to user plane function (UPF), radio access network (RAN), session management function (SMF), or policy control function (PCF).

[0124] Optionally, the above-described device can also be applied to the DIP transmission network side. For example, the device can be applied to a DIP transmission network edge node or a DIP transmission network controller (e.g., a DetNet Controller).

[0125] Optionally, DIP instance information can be stored on the 5G system side. For example, UPF, RAN, or unified data repository (UDR) can serve as the storage network element for DIP instance information.

[0126] Optionally, DIP instance information can also be stored on the DIP transport network side. For example, DIP transport network edge nodes or DIP transport network controllers can serve as network elements for storing DIP instance information.

[0127] In a ninth aspect, embodiments of this application provide a communication device applied to a UPF, including modules or units for performing the methods described in the second aspect or any possible implementation thereof.

[0128] In one possible implementation, the device includes:

[0129] The transceiver unit is used to receive the flow requirements of the service flow from the SMF, and to obtain the DIP instance information stored in its own storage, or to receive the DIP instance information from the edge node of the DIP transport network.

[0130] The processing unit is used to determine whether the service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0131] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the processing unit is further configured to: determine the target DIP instance;

[0132] The transceiver unit is also configured to: send information indicating the target DIP instance and the flow requirements of the service flow to the edge node of the DIP transport network.

[0133] In another possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the transceiver unit is further configured to: receive information from the SMF indicating the target DIP instance, and send the information indicating the target DIP instance and the flow requirement of the service flow to the edge node of the DIP transport network.

[0134] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the processing unit is further configured to: determine a target DIP instance and update the information of the target DIP instance based on the flow requirements of the service flow.

[0135] In another possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the transceiver unit is further configured to: receive information from the SMF indicating the target DIP instance;

[0136] The processing unit is also configured to: update the information of the target DIP instance based on the flow requirements of the service flow.

[0137] In a tenth aspect, embodiments of this application provide a communication apparatus applied to a RAN, including modules or units for performing the methods described in the third aspect or any possible implementation thereof.

[0138] In one possible implementation, the device includes:

[0139] The transceiver unit is used to receive the flow requirements of the service flow from the SMF, and to obtain the DIP instance information stored in its own storage, or to receive the DIP instance information from the edge node of the DIP transport network.

[0140] The processing unit is used to determine whether the service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0141] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the processing unit is further configured to: determine the target DIP instance;

[0142] The transceiver unit is also configured to: send information indicating the target DIP instance and the flow requirements of the service flow to the edge node of the DIP transport network.

[0143] In another possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the transceiver unit is further configured to: receive information from the SMF indicating the target DIP instance, and send the information indicating the target DIP instance and the flow requirement of the service flow to the edge node of the DIP transport network.

[0144] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the processing unit is further configured to: determine a target DIP instance and update the information of the target DIP instance based on the flow requirements of the service flow.

[0145] In another possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the transceiver unit is further configured to: receive information from the SMF indicating the target DIP instance;

[0146] The processing unit is also configured to: update the information of the target DIP instance based on the flow requirements of the service flow.

[0147] Eleventhly, embodiments of this application provide a communication device applied to an SMF, including modules or units for performing the methods described in the fourth aspect or any possible implementation of the fourth aspect.

[0148] In one possible implementation, the device includes:

[0149] The transceiver unit is used to receive DIP instance information from the UPF, RAN, or DIP transport network controller, or to receive DIP instance information from the UDR via the PCF.

[0150] The processing unit is used to determine whether the service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0151] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the processing unit is further configured to: determine the target DIP instance;

[0152] The transceiver unit is also configured to: send information indicating the target DIP instance and the flow requirements of the service flow to the UPF, the RAN, or the DIP transport network controller.

[0153] In another possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the processing unit is further configured to: determine the target DIP instance;

[0154] The transceiver unit is also configured to: send information indicating the target DIP instance and the flow requirements of the service flow to the UDR via the PCF.

[0155] In a twelfth aspect, embodiments of this application provide a communication device applied to a PCF, including modules or units for performing the methods described in the fifth aspect or any possible implementation thereof.

[0156] In one possible implementation, the device includes:

[0157] The transceiver unit is used to receive DIP instance information from the UDR;

[0158] The processing unit is used to determine whether the service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0159] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the transceiver unit is further configured to: receive information from the SMF indicating the target DIP instance, and send the information indicating the target DIP instance and the flow requirement of the service flow to the UDR.

[0160] In a thirteenth aspect, embodiments of this application provide a communication device applied to an edge node of a DIP transmission network, including modules or units for performing the methods described in the sixth aspect or any possible implementation thereof.

[0161] In one possible implementation, the device includes:

[0162] The transceiver unit is used to receive the flow requests of service flows from UPF / RAN, and to obtain the DIP instance information stored in its own storage.

[0163] The processing unit is used to determine whether the service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0164] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the transceiver unit is further configured to: receive information from the UPF / RAN indicating the target DIP instance;

[0165] The processing unit is also configured to: update the information of the target DIP instance based on the flow requirements of the service flow.

[0166] In a fourteenth aspect, embodiments of this application provide a communication apparatus applied to a DIP transmission network controller, including modules or units for performing the methods described in the seventh aspect or any possible implementation thereof.

[0167] In one possible implementation, the device includes:

[0168] The transceiver unit is used to receive the flow requests of the service flow from SMF and to obtain the DIP instance information stored in its own storage.

[0169] The processing unit is used to determine whether the service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0170] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the transceiver unit is further configured to: receive information from the SMF indicating the target DIP instance;

[0171] The processing unit is also configured to: update the information of the target DIP instance based on the flow requirements of the service flow.

[0172] In a fifteenth aspect, embodiments of this application provide a communication device including a processor for executing computer programs or instructions, which, when executed, cause the methods described in any of the first to seventh aspects or any possible implementations described above to be implemented. Optionally, the communication device further includes a memory. Optionally, the communication device further includes a communication interface, with the processor coupled to the communication interface.

[0173] In a sixteenth aspect, embodiments of this application provide a computer-readable storage medium storing a computer program or instructions that, when executed, cause the method described in any of the first to seventh aspects or any possible implementations to be implemented.

[0174] In a seventeenth aspect, embodiments of this application provide a computer program product comprising a computer program or instructions that, when executed, cause the method described in any of the first to seventh aspects or any possible implementation thereof to be implemented.

[0175] In an eighteenth aspect, embodiments of this application provide a chip including a processor for executing computer programs or instructions. When the processor executes the computer programs or instructions, the chip causes itself to perform the methods described in any one of the first to seventh aspects or any possible implementations described above. Optionally, the chip further includes a communication interface for receiving or transmitting signals.

[0176] In a nineteenth aspect, embodiments of this application provide a chip including logic circuitry and an input / output interface. The logic circuitry is coupled to the input / output interface and transmits data through the input / output interface to perform the method described in any of the first to seventh aspects or any possible implementations described above.

[0177] In a twentieth aspect, embodiments of this application provide a communication system that includes communication devices as described in any of the eighth to fourteenth aspects or any possible implementations above.

[0178] The beneficial effects of aspects eight through twentieth mentioned above can be referred to the descriptions of the beneficial effects in aspects one through seven, and will not be repeated here.

[0179] Furthermore, in the process of implementing any of the first to seventh aspects and any possible implementation thereof, the processes related to sending and / or receiving information in the above methods can be understood as the process of the processor outputting information and / or the processor receiving input information. When outputting information, the processor can output the information to a transceiver (or communication interface, or transmitting module) for transmission. After the information is output by the processor, it may require further processing before reaching the transceiver. Similarly, when the processor receives input information, the transceiver (or communication interface, or transmitting module) receives the information and inputs it to the processor. Furthermore, after the transceiver receives the information, it may require further processing before being input to the processor.

[0180] Based on the above principles, for example, the information sent mentioned in the aforementioned method can be understood as information output by the processor. Similarly, the information received can be understood as information received by the processor from input.

[0181] Alternatively, the operations of transmitting, sending, and receiving involved in the processor can be more generally understood as processor output and receiving, input, etc., unless otherwise specified, or if they do not contradict their actual function or internal logic in the relevant description.

[0182] Optionally, in the process of performing the method described in any of the first to seventh aspects and any possible implementation thereof, the processor may be a processor specifically designed to perform these methods, or it may be a processor that performs these methods by executing computer instructions stored in memory, such as a general-purpose processor. The memory may be a non-transitory memory, such as read-only memory (ROM), which may be integrated with the processor on the same chip or disposed on separate chips. This application does not limit the type of memory or the arrangement of the memory and processor. Attached Figure Description

[0183] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly described below.

[0184] Figure 1 This is a schematic diagram of a 5G system architecture;

[0185] Figure 2 This is a schematic diagram of a DIP (Dielectric Injection Propeller).

[0186] Figure 3 This is a schematic diagram of a distributed architecture provided in an embodiment of this application;

[0187] Figure 4 This is a schematic diagram of a centralized architecture provided in an embodiment of this application;

[0188] Figure 5 This is a flowchart illustrating a communication method provided in an embodiment of this application;

[0189] Figure 6 This is a flowchart illustrating another communication method provided in an embodiment of this application;

[0190] Figure 7 This is a flowchart illustrating another communication method provided in an embodiment of this application;

[0191] Figure 8 This is a flowchart illustrating another communication method provided in an embodiment of this application;

[0192] Figure 9 This is a flowchart illustrating another communication method provided in an embodiment of this application;

[0193] Figure 10 This is a flowchart illustrating another communication method provided in an embodiment of this application;

[0194] Figure 11 This is a flowchart illustrating another communication method provided in an embodiment of this application;

[0195] Figure 12 This is a flowchart illustrating another communication method provided in an embodiment of this application;

[0196] Figure 13 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application;

[0197] Figure 14 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application;

[0198] Figure 15 This is a schematic diagram of the structure of a chip provided in an embodiment of this application. Detailed Implementation

[0199] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described below with reference to the accompanying drawings.

[0200] In this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0201] The terms "first," "second," etc., used in the embodiments of this application do not limit the quantity or order of execution, and "first," "second," etc., are not necessarily different. Furthermore, the terms "comprising," "including," and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0202] The term "embodiment" as used in this application means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various locations throughout the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will explicitly and implicitly understand that, unless otherwise specified or logically conflicting, the terminology and / or descriptions between the various embodiments of this application are consistent and can be mutually referenced, and technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0203] It should be understood that in this application, "at least one" means one or more, and "more than one" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can mean: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0204] In the description of this application, "instruction" can include direct and indirect instructions, as well as explicit and implicit instructions. The information indicated by a certain piece of information is called the information to be instructed. In specific implementations, there are many ways to instruct the information to be instructed. For example, the information to be instructed can be directly instructed, such as by instructing the information itself or its index. Alternatively, the information to be instructed can be indirectly indicated by instructing other information, where there is a relationship between the indicated other information and the information to be instructed. Another example is that only a part of the information to be instructed can be indicated, while the other parts are known or pre-agreed upon. Furthermore, the instruction of specific information can be achieved by using a pre-agreed (e.g., protocol-defined) arrangement of various pieces of information, thereby reducing instruction overhead to some extent.

[0205] To facilitate understanding of the embodiments of this application, the relevant technologies of the embodiments of this application will be introduced first.

[0206] 1. The fifth-generation (5G) mobile communication system architecture (referred to as 5G system architecture)

[0207] Please see Figure 1 , Figure 1 This is a schematic diagram of a 5G system architecture. (For example...) Figure 1 As shown, the system architecture may include: radio access network (RAN), access and mobility management function (AMF), session management function (SMF), user plane function (UPF), policy control function (PCF), application function (AF), data network (DN), and user equipment (UE). Network elements can communicate with each other or with other devices, for example, through interfaces (e.g.,...). Figure 1 Information is exchanged between the following (N1, N2, N3, N4, N5, N6, N7, N11) shown in the figure.

[0208] UE refers to a terminal device with wireless communication capabilities, such as a mobile phone or an IoT terminal device.

[0209] RAN refers to devices that provide wireless access for terminal equipment, including but not limited to base stations, next-generation Node B (gNB), evolved Node B (eNB), access points (AP) in wireless fidelity (WiFi) systems, and base stations (BS) in world interoperability for microwave access (WiMAX) systems.

[0210] AMF can be responsible for mobility management in mobile networks, such as user location updates, user registration with the network, and user handover.

[0211] SMF (Service Provider Function) can be responsible for session management in mobile networks, such as session establishment, modification, and release. Specifically, it can assign Internet Protocol (IP) addresses to users and select a UPF (User Provider Function) to provide packet forwarding functionality.

[0212] UPF can handle user messages, such as forwarding and billing.

[0213] PCF can be responsible for providing policies to AMF or SMF, such as slice selection policies and quality of service (QoS) policies.

[0214] The AF can be responsible for providing services to the 3rd generation partnership project (3GPP) network, such as influencing service routing and interacting with the PCF for policy control.

[0215] DN refers to the operator's network that provides data transmission services to users, such as IP multi-media service (IMS) networks and the Internet.

[0216] The UE accesses the DN by establishing a protocol data unit (PDU) session between the UE, RAN, UPF, and DN.

[0217] It should be noted that, Figure 1The system architecture shown is not limited to the network elements depicted in the diagram; it may also include other network elements not shown in the diagram, and this application embodiment does not limit this. For example, the system architecture may also include a unified data management network element (UDM) or a unified data repository network element (UDR). The UDM is used to store user data, such as subscription information and authentication / authorization information. The UDR can provide storage capabilities for subscription data, policy data, and capability-related data.

[0218] It should be understood that the network elements involved in the embodiments of this application are... Figure 1 The examples used here refer to the names used in 5G mobile communication systems. In future communication systems or other communication systems, such as the 6th generation (6G) mobile communication system, the network elements involved in the embodiments of this application may have other names. Alternatively, in future communication systems or other communication systems, such as the 6G mobile communication system, the network elements involved in the embodiments of this application may be replaced by other entities or devices with the same function, and this application does not limit them in this regard. This is a unified explanation here and will not be repeated hereafter.

[0219] 2. Deterministic Internet Protocol (DIP)

[0220] DIP is a deterministic networking (DetNet) architecture that provides deterministic bearer services. It introduces a periodic scheduling mechanism for forwarding on the data plane and proposes efficient path planning and resource allocation algorithms on the control plane, aiming to achieve a large-scale, scalable, end-to-end deterministic low-latency network system.

[0221] Please see Figure 2 , Figure 2 This is a schematic diagram of a DIP (Dual Injection Propeller). For example... Figure 2 As shown, DIP involves technologies such as edge shaping, label mapping, and SRv6 explicit path planning. SRv6 refers to segment routing (SR) based on the Internet Protocol Version 6 (IPv6) forwarding plane.

[0222] DIP has the following characteristics: 1. It does not allow arbitrary sending (receiving) of data packets. Each data packet is assigned a specific sending (receiving) time period. For example, the current node can calculate the sending period of the data packet at the current node based on the sending period number of the previous node, link delay, clock information, etc., thereby avoiding bursts, controlling queuing delay within the node, and eliminating the long tail effect. 2. It adopts a periodic shaping and scheduling mechanism, thereby forming isolation between periods and avoiding micro-bursts and their hop-by-hop accumulation. 3. The upper bound of the system's end-to-end delay and the upper limit of jitter are determined.

[0223] Specifically, DIP has the following main functions:

[0224] 1. Implement access control on the control plane: Provider edge node (PE) (e.g.) Figure 2 The control plane of the ingress PE (Edge Edge Node) shown can record the resource reservation status of each flow. Based on the resource reservation results, the ingress edge node can determine whether a deterministic flow is allowed to enter the network for deterministic forwarding. The resource reservation status of a data flow can be dynamically refreshed, enabling resource reservation renewal.

[0225] 2. Implement path planning and resource reservation at the control plane: Based on distributed routing algorithms or centralized path calculation, transmission path planning can be performed for data streams, and necessary deterministic resource reservations can be made in advance along the route.

[0226] 3. Implement path binding on the data plane: The resource reservation for DIP transmission is reflected in the nodes of the data forwarding path. Subsequent data packet transmission needs to be bound to this path. Path binding technology can be coupled with label carrying technology.

[0227] 4. Deterministic periodic forwarding on the data plane: The ingress edge node embeds a time period number into the packet based on the time the data packet is sent. Intermediate nodes (providers, P) (e.g., Figure 2 After receiving the message, P1 and P2 (as shown) perform deterministic periodic forwarding based on the periodic mapping, so that the data packet carries a local time period number when it is sent, until the data packet is delivered to the egress edge node (e.g., Figure 2 The exported PE shown in the figure.

[0228] Specific implementation mechanisms of DIP can include tagged cyclic queuing and forwarding (TCQF) and cycle specified queuing and forwarding (CSQF), etc.

[0229] TCQF supports more than two cycles, indicating the cycle number through an existing or new packet header field called a tag. This replaces the cycle mapping in time-sensitive networking (TSN)'s purely synchronous receive clock-based specified queuing and forwarding (CQF), where the cycle mapping is calculated by the controller plane, taking into account link and intra-node forwarding delays, as well as cycle clock offsets. The TCQF option helps the receiving port identify the time period from which packets are sent from the upstream router; it can be used to determine the output port cycle buffer for queuing packets. TCQF's target advantages include low end-to-end jitter, ease of high-speed hardware implementation, the ability to support a large number of flows in large networks by applying TCQF to DetNet aggregations instead of individually to each DetNet flow (through DiffServ-style aggregation), and support for wide-area DetNet networks with arbitrary link delays and latency variations, and low-precision clock synchronization.

[0230] CSQF improves upon CQF by explicitly specifying the transmission period of each node along the path (using the segment ID (SID) from SR), enabling end-to-end bounded latency. SR is a source routing technique that does not maintain per-flow state at intermediate and egress nodes. CSQF based on SR supports flow aggregation, which is beneficial for scaling to macro networks. CSQF defines a new field called a cycle segment to identify cycle periods. A cycle segment identifies the interface / link and the cycle period of the interface / link. To specify which interface and cycle a packet should be transmitted to, simply append a cycle segment to the packet. By appending a list of cycle segments to a packet, not only can explicit packet routing be achieved, but the transmission period of each node along the path can also be specified without requiring per-flow state at intermediate and egress nodes.

[0231] The following section introduces the relevant concepts of DIP instance.

[0232] DIP instances are configured by the DIP control plane or network management system. Each DIP instance can be understood as a DIP transport network subnet (or DIP subnet), or in other words, each DIP instance corresponds to a pre-configured DIP subnet. Each DIP instance has corresponding DIP transport paths, periodic forwarding, edge shaping, and other DIP configurations.

[0233] DIP instance information can include various information about the DIP instance, such as DIP instance identity information, DIP transmission path information, DIP forwarding configuration information, DIP instance QoS information, DIP instance remaining resources, flow identification information, etc.

[0234] DIP instance identity information refers to the information used to identify or mark a DIP instance. For example, the DIP control plane or network management system can assign a corresponding identifier (DIP Instance ID) to distinguish different DIP instances. Alternatively, different DIP instances can be distinguished based on the interface addresses at both ends of the DIP instance path.

[0235] DIP transmission path information refers to information related to the deterministic path corresponding to a DIP instance. For example, it may include topology and routing information: such as the addresses or identifiers of DIP transmission path nodes and interfaces, SRv6 routing information, etc. It may also include path length or node hop count. Furthermore, it may include the correspondence or connection relationship between the DIP instance and the RAN and UPF: optionally, for example, the gNB ID and UPF ID can be used to indicate the corresponding or connected RAN and UPF, respectively.

[0236] DIP forwarding configuration information refers to the user plane forwarding configuration information of a DIP instance, which is related to the specific implementation of the DIP protocol. For example, it may include DIP cycle configuration: cycle length, number of cycles, start and end times, etc.; it may also include edge shaping configuration: shaping rate, shaping window settings, etc.; and it may also include interface configuration: the interface ID or address that enables DIP, the correspondence between the interface and the cycle, and the interface capabilities (such as the maximum transmission unit allowed by the interface), etc.

[0237] The QoS information of a DIP instance refers to the QoS guarantees that the DIP instance can provide for service flows. For example, it may include latency guarantees, jitter guarantees, and packet loss rate guarantees.

[0238] The remaining resources of a DIP instance refer to the remaining resources currently available to the DIP instance. For example, this may include remaining bandwidth (or the current equivalent link speed), available period or window information, etc.

[0239] Flow identification information refers to the information allocated to a DIP instance to enable flow identification functionality. For example, it may include the N3 tunnel address or address range bound to the DIP instance.

[0240] Based on the aforementioned functions of DIP, DIP transport networks can implement access control for service flows:

[0241] 1. The control plane of the ingress edge node can record the resource reservation status of each flow. Based on the resource reservation results, it can determine whether a deterministic flow is allowed to enter the network for deterministic forwarding. The resource reservation status of a data flow can be dynamically refreshed, enabling the renewal of resource reservations.

[0242] 2. DIP instances can reserve most of their available periodic window resources for DetNet flows (deterministic flows). While non-DetNet flows (non-deterministic flows) can be transmitted within DIP instances, they have the lowest priority and do not execute DIP's various transmission policies or actions (such as label binding). To provide certain resources or QoS guarantees for non-DetNet flows, DIP can implement admission control for DetNet flows, limiting the total resources used by DetNet flows. Conversely, it can also implement admission control for non-DetNet flows to ensure the quality of service for DetNet flows and improve resource utilization.

[0243] 3. The QoS guarantees (such as latency and jitter guarantees) that each DIP instance can provide are limited. As the number or status of the admitted service flows change, the available remaining resources and QoS guarantees of the DIP instance may also change. Therefore, the DIP instance can perform admission control on DetNet flows that need to perform DIP forwarding. If the available remaining resources are insufficient or the service flow demand is higher than the admission threshold, admission can be denied, otherwise admission can be granted.

[0244] Currently, some mobile communication system transport networks (TN) support TSN. Specifically, to support the determinism of the TN, the RAN and UPF can be treated as end users in existing deterministic protocols, i.e., the talker and listener as defined in IEEE 802.1Q TSN. The SMF acts as the centralized user configuration (CUC) element (or the CUC function is shared with the SMF). The SMF provides user / network configuration information (i.e., talker group and listener group information, also known as merged flow requirements) to the centralized network configuration (CNC) element in the TN. The CNC provides the SMF with state group information containing end-station communication configurations.

[0245] However, enabling TSN in a mobile communication system (TN) faces challenges such as the difficulty of achieving accurate time synchronization over a wide range and the deterioration of TSN transmission delay boundaries over long links. New mechanisms are needed to further support deterministic transmission in mobile communication system transport networks. However, since some mobile communication systems (such as 5G systems, future communication systems, or other communication systems) do not yet support DIP (Direct Ingress Protocol), there is a lack of mechanisms and procedures for implementing DIP transport network access control for service flows in scenarios where TN enables DIP. How the TN system can adapt to DIP and perform access control on service flows requiring DIP transmission remains an unresolved issue.

[0246] To address the aforementioned issues, embodiments of this application provide a communication method and apparatus that can perform admission control on service flows requiring DIP transmission.

[0247] The technical solutions of this application can be applied to various communication systems, such as: Long Term Evolution (LTE) systems, LTE Frequency Division Duplex (FDD) systems, LTE Time Division Duplex (TDD) systems, Worldwide Interoperability for Microwave Access (WiMAX) systems, Public Land Mobile Network (PLMN) systems, LTE Advanced (LTE-A) systems, the 5th generation (5G) mobile communication systems, New Radio (NR) systems, Machine-to-Machine (M2M) systems, or other future evolutionary communication systems, etc. This application does not limit these applications.

[0248] For ease of description, the following description uses an embodiment of this application applied to a 5G system as an example.

[0249] Please see Figure 3 , Figure 3 This is a schematic diagram of a distributed architecture provided in an embodiment of this application. For example... Figure 3 As shown, this distributed architecture is illustrated using a 5G transmission network supporting DIP as an example, including 5GS and DIP transmission networks. For an introduction to network elements in 5GS, please refer to the previous section... Figure 1The 5G system architecture shown is not repeated here. The DIP transport network includes one or more DIP instances (DIP instance_1, DIP instance_2, and DIP instance_3 as shown in the figure). Each DIP instance includes one or more edge nodes and one or more core nodes. In this distributed architecture, the RAN and UPF at both ends of the 5GS transport network are connected to or co-located with the corresponding DIP transport network edge nodes, and the control plane function (CPF) is located in the DIP transport network edge nodes.

[0250] Please see Figure 4 , Figure 4 This is a schematic diagram of a centralized architecture provided in an embodiment of this application. For example... Figure 4 As shown, this centralized architecture is illustrated using a 5G transport network supporting DIP as an example, including both 5GS and DIP transport networks. For an introduction to network elements in 5GS, please refer to the previous section... Figure 1 The 5G system architecture shown is not repeated here. The DIP transport network includes one or more DIP instances (DIP instance_1, DIP instance_2, and DIP instance_3 as shown in the figure). Each DIP instance includes one or more edge nodes and one or more core nodes. The DIP transport network also includes a centralized control plane (or DIP transport network controller), such as a deterministic network controller (DetNet Controller). In this centralized architecture, the CPF is located in the DetNet Controller. The DetNet Controller can be co-located with the SMF, and the DetNet Controller can contain a network management entity (NME).

[0251] Optionally, before the arrival of 5G service flows, the DIP transport network can pre-configure DIP instances on transport network nodes via CPF or NME, and the DIP instance information can be stored in a storage network element. A storage network element refers to a carrier used to store DIP instance information. In this application, the DIP instance information can be stored on the DIP transport network side (e.g., a DIP transport network edge node or DetNetController can be used as a storage network element), or it can be stored on the 5GS side (e.g., RAN, UPF, or UDR can be used as a storage network element).

[0252] Optionally, the relevant network element performing the admission control function (which may be SMF, PCF, RAN, UPF, DIP edge node, or DetNet Controller, etc. in this application) determines whether the 5GS service flow is admitted to the DIP transport network and the admitted DIP instance based on the service flow requirements and the DIP instance information stored in the storage network element.

[0253] It should be understood that Figure 3 or Figure 4 The network architecture shown is merely an example, and the architecture applicable to the embodiments of this application is not limited thereto. Any architecture capable of implementing some or all of the functions of the above-described devices is applicable to the embodiments of this application. The communication method provided in the embodiments of this application may only involve... Figure 3 or Figure 4 Some of the devices shown may also involve Figure 3 or Figure 4 The device not shown in the figure is not limited in this application.

[0254] The communication method provided in the embodiments of this application is described below.

[0255] Please see Figure 5 , Figure 5 This is a flowchart illustrating a communication method provided in an embodiment of this application. Figure 5 The illustrated embodiments can be applied to Figure 3 The distributed architecture shown illustrates the method using the interaction process between SMF, UPF, RAN, and DIP transport network edge nodes as an example. In this embodiment, the network element storing DIP instance information is the DIP transport network edge node.

[0256] like Figure 5 As shown, the communication method may include, but is not limited to, the following steps.

[0257] S501, SMF receives a request to perform DIP transmission for the service flow.

[0258] Specifically, the SMF can receive requests from the AF, PCF, UE, or other events to perform DIP transmissions for service flows.

[0259] In this embodiment, a service flow can be understood as a service flow that requires DIP transmission, and the service flow may include uplink service flow and / or downlink service flow. The flow requirements of the service flow are known to SMF, and will not be repeated here.

[0260] After receiving a request to perform DIP transport for a service flow, SMF can trigger a session modification procedure, which may include the following steps.

[0261] S502a, the SMF sends an admission control enforcement request to the UPF, and the UPF receives the admission control enforcement request from the SMF accordingly.

[0262] In step S502a, the admission control execution request may contain the flow requirements of the service flow. After receiving the admission control execution request, the UPF can obtain the flow requirements of the service flow from it. Here, the service flow can be understood as a downlink service flow. This admission control execution request is used to request the execution of DIP transport network admission control on the downlink service flow, or in other words, it is used to request or trigger the UPF to interact with the DIP transport network edge node that stores DIP instance information to execute the admission control function.

[0263] In S502b, the SMF sends an admission control enforcement request to the RAN, and the RAN receives the admission control enforcement request from the SMF accordingly.

[0264] In step S502b, the admission control execution request may include the flow requirements of the service flow. After receiving the admission control execution request, the RAN can obtain the flow requirements of the service flow from it. Here, the service flow can be understood as an uplink service flow. This admission control execution request is used to request the execution of DIP transport network admission control on the uplink service flow, or in other words, it is used to request or trigger the RAN to interact with the DIP transport network edge node that stores DIP instance information to execute the admission control function.

[0265] It should be noted that the name of the access control execution request or the message carrying the access control execution request is not limited in the embodiments of this application, and will not be repeated hereafter.

[0266] In some cases, parameters exchanged between 5GS and DIP may need to be mapped before they can be used by systems or devices operating under two different, non-interoperable protocols. The mapping method can vary depending on the specific implementation. For example, it may be feasible to make some parameters numerically equivalent. Alternatively, some parameters may essentially represent the same requirement, but require certain numerical conversions or calculations. Still others may require unit conversions.

[0267] Optionally, after the UPF / RAN obtains the flow requirements of the service flow, it can also perform the following step S503.

[0268] S503, UPF / RAN execution parameter mapping.

[0269] Parameter mapping refers to the parameter mapping between 5GS and DIP. It can be understood as mapping the flow requirement parameters of the business flow to the corresponding parameters in DIP or mapping the DIP parameters to the corresponding parameters in 5GS.

[0270] Optionally, for downlink traffic flows, parameter mapping is performed by the UPF. Optionally, for uplink traffic flows, parameter mapping is performed by the RAN.

[0271] Optionally, the flow requirements of a service flow may include, but are not limited to, one or more of the following parameters: guaranteed flow bit rate (GFBR), packet delay budget (PDB), maximum frame size (MaxFrameSize), or packet error rate (PER).

[0272] In some possible implementations, taking the mapping of service flow demand parameters to corresponding parameters in the DIP as an example, the Flow Bit Rate (GFBR) can be mapped to the minimum bandwidth (MinBandwidth) of the DIP, specifically through unit conversion. The Packet Delay Budget (PDB) can be the Packet Delay Budget (CN PDB) on the core network (CN) side, which can be mapped to the maximum latency (MaxLatency) of the DIP, specifically through the following mapping: CN PDB - UPF residence time = MaxLatency. The maximum frame size (MaxFrameSize) can be mapped to the maximum payload size (MaxPayloadSize) of the DIP. The Packet Error Rate (PER) can be mapped to the maximum packet loss rate (MaxLoss) of the DIP.

[0273] S504a, the UPF sends an admission request to the DIP transport network edge node, and the DIP transport network edge node receives the admission request from the UPF accordingly.

[0274] In step S504a, the admission request may include the flow requirements of the downlink service flow. After receiving the admission request, the DIP transport network edge node can obtain the flow requirements of the downlink service flow from it. Optionally, if parameter mapping has been performed by the UPF, the admission request may include the mapped parameters of the downlink service flow's flow requirements. This admission request is used to request the DIP transport network to perform admission judgment on the downlink service flow, or in other words, to request or trigger the DIP transport network edge node to determine whether the downlink service flow is admitted to the DIP transport network.

[0275] In S504b, the RAN sends an admission request to the DIP transport network edge node, and the DIP transport network edge node receives the admission request from the RAN accordingly.

[0276] In step S504b, the admission request may include the flow requirements of the uplink service flow. After receiving the admission request, the DIP transport network edge node can obtain the flow requirements of the uplink service flow from it. Optionally, if the RAN has performed parameter mapping, the admission request may include the mapped parameters of the uplink service flow's flow requirements. This admission request is used to request the DIP transport network admission judgment for the uplink service flow, or in other words, to request or trigger the DIP transport network edge node to determine whether the uplink service flow should be admitted to the DIP transport network.

[0277] It should be noted that the name of the access request or the message carrying the access request is not limited in the embodiments of this application, and will not be repeated hereafter.

[0278] Optionally, if no parameter mapping is performed by the UPF / RAN, after the DIP transport network edge node obtains the flow requirements of the service flow, it can also perform the following step S505.

[0279] S505, DIP transmission network edge node performs parameter mapping.

[0280] In some possible implementations, the specific description of the parameter mapping in step S505 can be found in the relevant description in step S503 above, and will not be repeated here.

[0281] In other possible implementations, DIP transport network edge nodes can also map DIP parameters to corresponding 5GS parameters. Here, DIP parameters can be understood as admission-related parameters included in the DIP instance information. For example, DIP parameters may include, but are not limited to, the DIP instance's currently available remaining bandwidth (or current equivalent link speed), the latency guarantee provided by the DIP instance, the maximum transmission unit (MTU) allowed by the DIP instance, or the packet loss rate guarantee provided by the DIP instance. Specifically, the DIP instance's currently available remaining bandwidth can be mapped to bit rate, the DIP instance's latency guarantee can be mapped to transport network latency guarantee, the DIP's allowed MTU can be mapped to the maximum transport network data frame size, and the DIP instance's packet loss rate guarantee can be mapped to the transport network packet error rate.

[0282] Optionally, steps S503 and S505 can be performed separately; that is, parameter mapping can be performed by the UPF / RAN or by the DIP transmission network edge node.

[0283] S506, the edge node of the DIP transmission network determines whether a service flow is allowed to enter the DIP transmission network based on the flow requirements of the service flow and the DIP instance information.

[0284] For downlink traffic, the DIP transmission network edge nodes determine whether a downlink traffic flow is allowed to enter the DIP transmission network based on its flow requirements and DIP instance information. For uplink traffic, the DIP transmission network edge nodes determine whether an uplink traffic flow is allowed to enter the DIP transmission network based on its flow requirements and DIP instance information. The admission determination methods for downlink and uplink traffic flows are similar and will be explained uniformly below.

[0285] In step S506, the DIP instance information comes from the DIP instance information stored by the DIP transport network edge node. That is, the DIP transport network edge node knows the DIP instance information and can obtain the DIP instance information from its own stored information. For example, the DIP instance information can be all the DIP instance information that the DIP transport network edge node supports accessing.

[0286] DIP instance information includes the Quality of Service (QoS) guarantees and / or remaining resources of at least one DIP instance. The QoS guarantees and / or remaining resources of a DIP instance are used to indicate the admission thresholds of the DIP instance. For a DIP instance, if the flow requirements of a service flow meet the admission thresholds of that DIP instance, then that DIP instance can be considered an optional DIP instance. In other words, the conditions for an optional DIP instance include: the flow requirements of the service flow meet the admission thresholds of the optional DIP instance. An optional DIP instance can be understood as a DIP instance that a service flow can be admitted to.

[0287] Specifically, based on the flow requirements of the service flow and the admission thresholds of the at least one DIP instance, it can be determined whether the at least one DIP instance includes optional DIP instances. Then, based on whether optional DIP instances are included, it is determined whether the service flow is admitted to the DIP transport network. One possible scenario is that if at least one optional DIP instance is included, the service flow is admitted to the DIP transport network. Another possible scenario is that if at least one optional DIP instance is not included, the service flow is not admitted to the DIP transport network. This achieves the admission determination.

[0288] Optionally, the admission thresholds for a DIP instance may include, but are not limited to, one or more of the following parameters: the currently available remaining bandwidth (or the currently equivalent link speed) of the DIP instance, the latency guarantee provided by the DIP instance, the maximum transmission unit (MTU) allowed by the DIP instance, or the packet loss rate guarantee provided by the DIP instance.

[0289] Optionally, if a DIP instance meets one or more of the following conditions, it can be determined that the flow requirements of the business flow meet the admission threshold of the DIP instance, that is, the DIP instance can be used as an optional DIP instance:

[0290] 1) The bandwidth resources corresponding to GFBR are less than or equal to the remaining bandwidth resources of the DIP instance. Specifically, this can be: the MinBandwidth after GFBR mapping is less than or equal to the current available remaining bandwidth of the DIP instance, or the bit rate after mapping the current available remaining bandwidth of the DIP instance is greater than or equal to GFBR.

[0291] 2) The latency requirement corresponding to CN PDB is greater than or equal to the latency guarantee of DIP instance. Specifically, it can be: MaxLatency after CN PDB mapping is greater than or equal to the latency guarantee that DIP instance can provide, or the transmission network latency guarantee after mapping the latency guarantee that DIP instance can provide is less than or equal to CN PDB.

[0292] 3) The transmission unit corresponding to MaxFrameSize is less than or equal to the maximum transmission unit allowed by the DIP instance. Specifically, it can be: MaxPayloadSize mapped from MaxFrameSize is less than or equal to the MTU allowed by the DIP instance, or the maximum transmission network data frame size mapped from the MTU allowed by the DIP instance is greater than or equal to MaxFrameSize.

[0293] 4) The packet loss rate corresponding to PER is greater than or equal to the packet loss rate guarantee of the DIP instance. Specifically, this can be: MaxLoss after PER mapping is greater than or equal to the packet loss rate guarantee provided by the DIP instance, or the packet loss rate guarantee provided by the DIP instance after mapping the transmission network packet error rate is less than or equal to PER.

[0294] The above conditions can be used to identify the possible DIP instances relatively accurately from at least one DIP instance.

[0295] Optionally, after determining whether a service flow is admitted to the DIP transport network, the edge node of the DIP transport network can also generate admission control indication information, which is used to indicate whether the service flow is admitted to the DIP transport network.

[0296] S507a, the DIP transmission network edge node returns admission control indication information to the UPF, and correspondingly, the UPF receives the admission control indication information from the DIP transmission network edge node.

[0297] In step S507a, the admission control indication information is used to indicate whether the downlink service flow is admitted to the DIP transport network. After generating the admission control indication information, the DIP transport network edge node returns the admission control indication information to the UPF to inform the UPF whether the downlink service flow is admitted to the DIP transport network.

[0298] In one possible scenario, the admission control indication information indicates that the downlink traffic flow is admitted to the DIP transport network, meaning the DIP transport network allows the downlink traffic flow to access. In this case, the admission control indication information may include indication information that the downlink traffic flow is admitted to the DIP transport network, used to inform the UPF that the downlink traffic flow is admitted to the DIP transport network. The admission control indication information may also include information about the DIP instances that the downlink traffic flow can be admitted to (i.e., the at least one optional DIP instance mentioned above), used to inform the UPF about the information of the at least one optional DIP instance. For example, the information of the optional DIP instance may include the identifier, remaining resources, QoS guarantees, etc., of the optional DIP instance, used to assist in the subsequent selection of DIP instances.

[0299] Another possible scenario is that the admission control indication information indicates that the downlink traffic flow is not allowed to enter the DIP transport network, meaning the DIP transport network denies the downlink traffic flow access. In this case, the admission control indication information may include indication information that the downlink traffic flow is not allowed to enter the DIP transport network, used to inform the UPF that the downlink traffic flow is not allowed to enter the DIP transport network.

[0300] S507b, the DIP transport network edge node returns access control indication information to the RAN, and correspondingly, the RAN receives the access control indication information from the DIP transport network edge node.

[0301] In step S507b, the admission control indication information is used to indicate whether the uplink service flow is admitted to the DIP transport network. After generating the admission control indication information, the DIP transport network edge node returns the admission control indication information to the RAN to inform the RAN whether the uplink service flow is admitted to the DIP transport network.

[0302] In one possible scenario, the admission control indication information indicates that the uplink traffic flow is admitted to the DIP transport network, meaning the DIP transport network allows the uplink traffic flow to access. In this case, the admission control indication information may include indication information that the uplink traffic flow is admitted to the DIP transport network, used to inform the RAN that the uplink traffic flow is admitted to the DIP transport network. The admission control indication information may also include information about the DIP instances that the uplink traffic flow can be admitted to (i.e., the at least one optional DIP instance mentioned above), used to inform the RAN about the information of the at least one optional DIP instance. For example, the information of the optional DIP instance may include the identifier, remaining resources, QoS guarantees, etc., of the optional DIP instance, used to assist in the subsequent selection of DIP instances.

[0303] Another possible scenario is that the admission control indication information indicates that the uplink traffic flow is not allowed to enter the DIP transport network, meaning the DIP transport network denies the uplink traffic flow access. In this case, the admission control indication information may include indication information that the uplink traffic flow is not allowed to enter the DIP transport network, used to inform the RAN that the uplink traffic flow is not allowed to enter the DIP transport network.

[0304] It should be noted that the name of the access control indication information or the message carrying the access control indication information is not limited in the embodiments of this application, and will not be described again in the following text.

[0305] S508, UPF / RAN confirms whether a service flow is allowed to enter the DIP transport network based on the access control instruction information.

[0306] Based on the received admission control indication information, the UPF confirms whether the downlink traffic flow is admitted to the DIP transport network. In one possible scenario, if the admission control indication information indicates that the downlink traffic flow is admitted to the DIP transport network, the UPF confirms that the downlink traffic flow has been admitted to the DIP transport network.

[0307] The RAN confirms whether the uplink traffic flow is admitted to the DIP transport network based on the received admission control indication information. In one possible scenario, if the admission control indication information indicates that the uplink traffic flow is admitted to the DIP transport network, then the RAN confirms that the uplink traffic flow has been admitted to the DIP transport network.

[0308] Optionally, if the UPF / RAN confirms that the service flow is admitted to the DIP transport network, the following steps S509a to S509g may also be included.

[0309] S509a, UPF / RAN determines the target DIP instance.

[0310] When the admission control indication information returned by the DIP transport network edge node to the UPF indicates that the downlink service flow is admitted to the DIP transport network, the admission control indication information may include information of at least one optional DIP instance (which can be understood as the DIP instance that the downlink service flow can be admitted to), so that the UPF can obtain the information of at least one optional DIP instance after receiving the admission control indication information.

[0311] The target DIP instance determined by the UPF (referred to as the first target DIP instance for distinction) can be understood as the DIP instance that the downlink service flow is ultimately confirmed to be admitted to, or as the DIP instance that the downlink service flow will ultimately access. The first target DIP instance is one of the at least one optional DIP instance mentioned above, and the UPF can determine the first target DIP instance from the at least one optional DIP instance mentioned above. For example, if the at least one optional DIP instance includes only one optional DIP instance, the UPF can use that optional DIP instance as the first target DIP instance. As another example, if the at least one optional DIP instance includes multiple optional DIP instances, the UPF can select one from the multiple optional DIP instances as the first target DIP instance. The selection method can be random selection, selection based on the information of each optional DIP instance (such as the remaining resource size, latency guarantee size, and other reference information), or other possible selection methods. This application embodiment does not limit this.

[0312] When the admission control indication information returned by the DIP transport network edge node to the RAN indicates that the uplink service flow is admitted to the DIP transport network, the admission control indication information may include information of at least one optional DIP instance (which can be understood as the DIP instance that the uplink service flow can be admitted to), so that the RAN can obtain the information of at least one optional DIP instance from the admission control indication information.

[0313] The target DIP instance determined by the RAN (referred to as the second target DIP instance for distinction) can be understood as the DIP instance that the uplink service flow is ultimately confirmed to be admitted to, or as the DIP instance that the uplink service flow will ultimately access. The second target DIP instance is one of the at least one optional DIP instance mentioned above, and the RAN can determine the second target DIP instance from the at least one optional DIP instance mentioned above. For example, if the at least one optional DIP instance includes only one optional DIP instance, the RAN can use that optional DIP instance as the second target DIP instance. As another example, if the at least one optional DIP instance includes multiple optional DIP instances, the RAN can select one from the multiple optional DIP instances as the second target DIP instance. The selection method can be random selection, selection based on the information of each optional DIP instance (such as the remaining resource size, latency guarantee size, and other reference information), or other possible selection methods. This application embodiment does not limit this.

[0314] The first target DIP instance mentioned above may be the same as or different from the second target DIP instance mentioned above.

[0315] S509b, the UPF sends information indicating the target DIP instance to the DIP transport network edge node, and correspondingly, the DIP transport network edge node receives the information indicating the target DIP instance from the UPF.

[0316] In step S509b, the target DIP instance refers to the aforementioned first target DIP instance. After the UPF determines the first target DIP instance, it can send information indicating the first target DIP instance to the DIP transport network edge node, which is used to inform the DIP transport network edge node of the DIP instance that needs to be updated (i.e., the first target DIP instance), or to trigger the DIP transport network edge node to update the information of the first target DIP instance.

[0317] S509c, the RAN sends information indicating the target DIP instance to the DIP transport network edge node, and correspondingly, the DIP transport network edge node receives the information indicating the target DIP instance from the RAN.

[0318] In step S509c, the target DIP instance refers to the aforementioned second target DIP instance. After the RAN determines the second target DIP instance, it can send information indicating the second target DIP instance to the DIP transport network edge node. This information is used to inform the DIP transport network edge node of the DIP instance that needs to be updated (i.e., the second target DIP instance), or to trigger the DIP transport network edge node to update the information of the second target DIP instance.

[0319] For example, the information used to indicate the target DIP instance may be the identifier of the target DIP instance or other information that can represent the identity of the target DIP instance.

[0320] Optionally, after the UPF / RAN confirms that the service flow has been admitted to the DIP transport network, it can also generate an admission success acknowledgement message, which is used to confirm that the service flow has been admitted to the DIP transport network.

[0321] S509d, the UPF returns an admission success confirmation message to the SMF, and the SMF receives the admission success confirmation message from the UPF accordingly.

[0322] After generating the admission success confirmation message, the UPF returns the admission success confirmation message to the SMF to inform the SMF that the downlink service flow has been admitted to the DIP transport network.

[0323] In S509e, the RAN returns an admission success confirmation message to the SMF, and the SMF receives the admission success confirmation message from the RAN accordingly.

[0324] After generating the admission success confirmation information, the RAN returns the admission success confirmation information to the SMF to inform the SMF that the uplink service flow has been admitted to the DIP transport network.

[0325] It should be noted that the name of the access success confirmation information or the message carrying the access success confirmation information is not limited in the embodiments of this application, and will not be described again in the following text.

[0326] In step S509a above, the target DIP instance is determined by the UPF / RAN. It should be understood that in other possible implementations, the target DIP instance may also be determined by the SMF.

[0327] Optionally, steps S509a to S509e can be replaced by steps S509d to S509e and the following steps S509f and S509g.

[0328] In the replaced step S509d, the admission success confirmation information includes information about at least one of the aforementioned optional DIP instances (i.e., DIP instances that can be admitted to the downlink service flow), which is used to instruct the SMF to determine the target DIP instance (referred to as the third target DIP instance for distinction). The third target DIP instance can be understood as the DIP instance that the downlink service flow is ultimately confirmed to be admitted to, or it can be understood as the DIP instance that the downlink service flow will ultimately access.

[0329] In the replaced step S509e, the admission success confirmation information includes information about at least one of the aforementioned optional DIP instances (i.e., DIP instances that the uplink service flow can be admitted to), which is used to instruct the SMF to determine the target DIP instance (referred to as the fourth target DIP instance for distinction). The fourth target DIP instance can be understood as the DIP instance that the uplink service flow is ultimately confirmed to be admitted to, or it can be understood as the DIP instance that the uplink service flow will ultimately access.

[0330] S509f, SMF determines the target DIP instance.

[0331] After receiving the admission success confirmation information from the UPF, the SMF can obtain information about at least one of the above-mentioned optional DIP instances (i.e., DIP instances that can be admitted to the downlink service flow), and determine the third target DIP instance from the above-mentioned at least one optional DIP instance.

[0332] After receiving the admission success confirmation information from the RAN, the SMF can obtain information on at least one of the above-mentioned optional DIP instances (i.e., DIP instances that can be admitted to the uplink service flow), and determine the fourth target DIP instance from the above-mentioned at least one optional DIP instance.

[0333] For a detailed description of determining the target DIP instance in step S509f, please refer to the relevant description in step S509a above, which will not be repeated here.

[0334] The third target DIP instance mentioned above may be the same as or different from the fourth target DIP instance mentioned above. Furthermore, the third target DIP instance mentioned above may be the same as or different from the first target DIP instance mentioned above. The fourth target DIP instance mentioned above may be the same as or different from the second target DIP instance mentioned above.

[0335] In S509g, the SMF sends information indicating the target DIP instance to the DIP transport network edge node via the UPF / RAN, and correspondingly, the DIP transport network edge node receives the information indicating the target DIP instance from the SMF via the UPF / RAN.

[0336] Specifically, after the SMF determines the third target DIP instance, it sends information indicating the third target DIP instance to the UPF. The UPF then forwards this information to the edge nodes of the DIP transport network to inform them of the DIP instance (i.e., the third target DIP instance) that needs to be updated, or to trigger the edge nodes of the DIP transport network to update the information of the third target DIP instance.

[0337] After receiving information indicating a third target DIP instance, the DIP transport network edge node can determine the third target DIP instance and update its stored information about the third target DIP instance based on the flow requirements of the downlink traffic. For example, the DIP transport network edge node can update the current available remaining bandwidth of the third target DIP instance based on the GFBR in the flow requirements of the downlink traffic.

[0338] After the SMF determines the fourth target DIP instance, it sends information indicating the fourth target DIP instance to the RAN. The RAN forwards this information to the DIP transport network edge node to inform the DIP transport network edge node of the DIP instance that needs to be updated (i.e., the fourth target DIP instance), or to trigger the DIP transport network edge node to update the information of the fourth target DIP instance.

[0339] After receiving information indicating a fourth target DIP instance, the DIP transport network edge node can determine the fourth target DIP instance and update its stored information about it based on the uplink traffic flow requirements. For example, the DIP transport network edge node can update the current available remaining bandwidth of the fourth target DIP instance based on the GFBR in the uplink traffic flow requirements.

[0340] It is understandable that since the DIP transmission network edge node has already obtained the flow requirements of the service flow in the above steps S504a to S504b, there is no need to send the flow requirements of the service flow to the DIP transmission network edge node again in the above steps S509b, S509c and S509g.

[0341] In another possible scenario, if the admission control indication information received by the UPF indicates that the downlink traffic flow is not allowed to enter the DIP transport network, then the UPF confirms that the downlink traffic flow is not allowed to enter the DIP transport network.

[0342] In another possible scenario, if the admission control indication information received by the RAN indicates that the uplink traffic flow is not allowed to enter the DIP transport network, then the RAN confirms that the uplink traffic flow is not allowed to enter the DIP transport network.

[0343] Optionally, after the UPF / RAN confirms that the service flow is not admitted to the DIP transport network, it can also generate an admission failure acknowledgment message, which is used to confirm that the service flow is not admitted to the DIP transport network.

[0344] Optionally, if the UPF / RAN confirms that the service flow is not allowed to enter the DIP transport network, the following steps S510a to S510b may also be included.

[0345] S510a, the UPF returns an admission failure confirmation message to the SMF, and the SMF receives the admission failure confirmation message from the UPF accordingly.

[0346] In step S510a, the admission failure confirmation information is used to confirm that the downlink service flow is not admitted to the DIP transport network. After generating the admission failure confirmation information, the UPF returns the admission failure confirmation information to the SMF to inform the SMF that the downlink service flow is not admitted to the DIP transport network.

[0347] In S510b, the RAN returns an admission failure confirmation message to the SMF, and the SMF receives the admission failure confirmation message from the RAN accordingly.

[0348] In step S510b, the admission failure confirmation information is used to confirm that the uplink service flow is not admitted to the DIP transport network. After generating the admission failure confirmation information, the RAN returns the admission failure confirmation information to the SMF to inform the SMF that the uplink service flow is not admitted to the DIP transport network.

[0349] Optionally, after receiving the admission failure confirmation information, the SMF can also inform the requesting party (e.g., AF, PCF, or UE) that the service flow admission has failed, or reject the service flow request (such as a QoS request), or delete the corresponding service flow. For example, the SMF can send an indication message to the requesting party to indicate that the DIP transport network has rejected the service flow admission request. Optionally, the indication message can also include a reason value to indicate the reason why the DIP transport network rejected the service flow admission request.

[0350] It should be noted that the name of the access failure confirmation information or the message carrying the access failure confirmation information is not limited in the embodiments of this application, and will not be described again in the following text.

[0351] The above embodiments provide a process for performing DIP transport network access control on 5G service flows in a scenario where 5GS supports DIP. The DIP transport network edge node serves as the storage network element for DIP instance information. The access control function is executed by the interaction between the 5GS side and the DIP transport network side. Specifically, the access judgment is made by the DIP transport network edge node, which is suitable for a distributed architecture.

[0352] It should be understood that in the embodiments of this application, the steps on both sides of RAN and UPF correspond to the admission control procedures for uplink and downlink service flows, respectively. In some possible implementations, admission control may be performed only on uplink service flows, or only on downlink service flows, or on both uplink and downlink service flows. This is explained uniformly here and will not be repeated hereafter.

[0353] Please see Figure 6 , Figure 6 This is a flowchart illustrating another communication method provided in an embodiment of this application. Figure 6 The illustrated embodiments can be applied to Figure 3 The distributed architecture shown illustrates the method using the interaction process between SMF, UPF, RAN, and DIP transport network edge nodes as an example. In this embodiment, the network element storing DIP instance information is the DIP transport network edge node.

[0354] like Figure 6 As shown, the communication method may include, but is not limited to, the following steps.

[0355] S601, SMF receives a request to perform DIP transmission for the service flow.

[0356] S602a, the SMF sends an admission control enforcement request to the UPF, and the UPF receives the admission control enforcement request from the SMF accordingly.

[0357] S602b, the SMF sends an admission control enforcement request to the RAN, and the RAN receives the admission control enforcement request from the SMF accordingly.

[0358] For a detailed description of steps S601, S602a, and S602b, please refer to the relevant descriptions of steps S501, S502a, and S502b above; they will not be repeated here.

[0359] S603a, the UPF sends an acquisition request to the DIP transport network edge node, and the DIP transport network edge node receives the acquisition request from the UPF accordingly.

[0360] S603b, the RAN sends an acquisition request to the DIP transport network edge node, and the DIP transport network edge node receives the acquisition request from the RAN accordingly.

[0361] In steps S603a and S603b, the request is used to request the acquisition of DIP instance information, or in other words, to request or trigger the DIP transmission network edge node to return DIP instance information.

[0362] It should be noted that the embodiments of this application do not limit the name of the acquisition request or the message carrying the acquisition request, and will not be repeated hereafter.

[0363] S604a, the DIP transmission network edge node returns DIP instance information to the UPF, and correspondingly, the UPF receives the DIP instance information from the DIP transmission network edge node.

[0364] S604b, the DIP transmission network edge node returns DIP instance information to the RAN, and correspondingly, the RAN receives the DIP instance information from the DIP transmission network edge node.

[0365] In steps S604a and S604b, the DIP instance information returned by the DIP transport network edge node comes from the DIP instance information stored by the DIP transport network edge node. This DIP instance information includes information about at least one DIP instance, which may include the DIP instance's identity information (e.g., DIP instance identifier), as well as the DIP instance's quality of service guarantees and / or remaining resources.

[0366] Optionally, the DIP transport network edge node can also perform parameter mapping. When parameter mapping is performed at the DIP transport network edge node, the DIP instance information received by the UPF / RAN may include the mapped parameters for the DIP instance's Quality of Service (QoS) guarantees and / or remaining resources.

[0367] Optionally, parameter mapping can also be performed by the UPF / RAN. For example, if parameter mapping is not performed at the DIP transport network edge node, the UPF / RAN can also perform the following step S605.

[0368] S605, UPF / RAN execution parameter mapping.

[0369] For a detailed description of the parameter mapping in step S605, please refer to the relevant descriptions in steps S503 and / or S505 above, which will not be repeated here.

[0370] S606, UPF / RAN determines whether a service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0371] Unlike Figure 5 In the illustrated embodiment, the DIP transport network edge node determines whether a service flow is allowed to enter the DIP transport network. Figure 6 The illustrated embodiment uses UPF / RAN to determine whether a service flow is admitted to the DIP transport network.

[0372] For downlink traffic, the UPF determines whether the downlink traffic is allowed to enter the DIP transport network based on the downlink traffic's flow requirements and DIP instance information. For uplink traffic, the RAN determines whether the uplink traffic is allowed to enter the DIP transport network based on the uplink traffic's flow requirements and DIP instance information.

[0373] For a detailed description of the admission determination in step S606, please refer to the relevant description in step S506 above, which will not be repeated here.

[0374] One possible scenario is that the UPF determines that downlink traffic is admitted to the DIP transport network. Another possible scenario is that the RAN determines that uplink traffic is admitted to the DIP transport network.

[0375] Optionally, if the UPF / RAN determines that the service flow is admitted to the DIP transport network, the following steps S607a to S607g may also be included.

[0376] S607a, UPF / RAN identifies the target DIP instance.

[0377] S607b, the UPF sends flow requests for information indicating the target DIP instance and service flow to the DIP transport network edge node, and correspondingly, the DIP transport network edge node receives the flow requests for information indicating the target DIP instance and service flow from the UPF.

[0378] In step S607b, the target DIP instance refers to the aforementioned first target DIP instance. After the UPF determines the first target DIP instance, it can send information indicating the first target DIP instance and the flow requirements of the downlink service flow to the DIP transport network edge node. This is used to inform the DIP transport network edge node of the DIP instance that needs to be updated (i.e., the first target DIP instance) and the flow requirements of the downlink service flow, or in other words, to trigger the DIP transport network edge node to update the information of the first target DIP instance according to the flow requirements of the downlink service flow.

[0379] S607c, the RAN sends information and service flow requests indicating the target DIP instance to the DIP transport network edge node, and correspondingly, the DIP transport network edge node receives the information and service flow requests indicating the target DIP instance from the RAN.

[0380] In step S607c, the target DIP instance refers to the aforementioned second target DIP instance. After the RAN determines the second target DIP instance, it can send information indicating the second target DIP instance and the uplink service flow requirements to the DIP transport network edge node. This is used to inform the DIP transport network edge node of the DIP instance that needs to be updated (i.e., the second target DIP instance) and the uplink service flow requirements, or in other words, to trigger the DIP transport network edge node to update the information of the second target DIP instance according to the uplink service flow requirements.

[0381] Optionally, after the UPF / RAN determines that the service flow has been admitted to the DIP transport network, it can also generate admission success confirmation information, which is used to confirm that the service flow has been admitted to the DIP transport network.

[0382] S607d, the UPF returns an admission success confirmation message to the SMF, and the SMF receives the admission success confirmation message from the UPF accordingly.

[0383] After generating the admission success confirmation message, the UPF returns the admission success confirmation message to the SMF to inform the SMF that the downlink service flow has been admitted to the DIP transport network.

[0384] S607e, the RAN returns an admission success confirmation message to the SMF, and the SMF receives the admission success confirmation message from the RAN accordingly.

[0385] After generating the admission success confirmation information, the RAN returns the admission success confirmation information to the SMF to inform the SMF that the uplink service flow has been admitted to the DIP transport network.

[0386] In step S607a above, the target DIP instance is determined by the UPF / RAN. It should be understood that in other possible implementations, the target DIP instance may also be determined by the SMF.

[0387] Optionally, the above steps S607a to S607e can be replaced by the above steps S607d to S607e and the following steps S607f and S607g.

[0388] In the replaced step S607d, the admission success confirmation information includes information about at least one optional DIP instance (i.e., the DIP instance that the downlink service flow can be admitted to), which is used to instruct the SMF to determine the target DIP instance (i.e., the third target DIP instance mentioned above).

[0389] In the replaced step S607e, the admission success confirmation information includes information about at least one optional DIP instance (i.e., the DIP instance that the uplink traffic flow can be admitted), which is used to instruct the SMF to determine the target DIP instance (i.e., the fourth target DIP instance mentioned above).

[0390] S607f, SMF determines the target DIP instance.

[0391] After receiving the admission success confirmation information from the UPF, the SMF can obtain information about at least one of the above-mentioned optional DIP instances (i.e., DIP instances that can be admitted to the downlink service flow), and determine the third target DIP instance from the above-mentioned at least one optional DIP instance.

[0392] After receiving the admission success confirmation information from the RAN, the SMF can obtain information on at least one of the above-mentioned optional DIP instances (i.e., DIP instances that can be admitted to the uplink service flow), and determine the fourth target DIP instance from the above-mentioned at least one optional DIP instance.

[0393] In S607g, the SMF sends information indicating the target DIP instance and flow requirements for service flows to the DIP transport network edge node via the UPF / RAN. Correspondingly, the DIP transport network edge node receives information indicating the target DIP instance and flow requirements for service flows from the SMF via the UPF / RAN.

[0394] Specifically, after the SMF determines the third target DIP instance, it sends information indicating the third target DIP instance to the UPF (since the UPF has already obtained the flow requirements of the downlink service flow in step S602a above, there is no need to send the flow requirements of the downlink service flow to the UPF again here). The UPF forwards the information indicating the third target DIP instance and the flow requirements of the downlink service flow to the edge node of the DIP transmission network. This is used to inform the edge node of the DIP instance that needs to be updated (i.e., the third target DIP instance) and the flow requirements of the downlink service flow, or in other words, to trigger the edge node of the DIP transmission network to update the information of the third target DIP instance according to the flow requirements of the downlink service flow.

[0395] After receiving information indicating a third target DIP instance and the flow requirements of downlink traffic, the edge node of the DIP transport network can determine the third target DIP instance and update its stored information about the third target DIP instance based on the flow requirements of the downlink traffic. For example, the edge node can update the current available remaining bandwidth of the third target DIP instance based on the GFBR in the flow requirements of the downlink traffic.

[0396] After the SMF determines the fourth target DIP instance, it sends information indicating the fourth target DIP instance to the RAN (since the RAN has already obtained the uplink service flow requirements in step S602b above, it is not necessary to send the uplink service flow requirements to the RAN again here). The RAN forwards the information indicating the fourth target DIP instance and the uplink service flow requirements to the DIP transmission network edge node, which is used to inform the DIP transmission network edge node of the DIP instance (i.e., the fourth target DIP instance) and the uplink service flow requirements, or in other words, to trigger the DIP transmission network edge node to update the information of the fourth target DIP instance according to the uplink service flow requirements.

[0397] After receiving information indicating a fourth target DIP instance and the flow requirements of the uplink traffic, the DIP transport network edge node can determine the fourth target DIP instance and update its stored information about the fourth target DIP instance based on the flow requirements of the uplink traffic. For example, the DIP transport network edge node can update the current available remaining bandwidth of the fourth target DIP instance based on the GFBR in the flow requirements of the uplink traffic.

[0398] For the content not specifically described in steps S607a to S607g, please refer to the relevant descriptions in steps S509a to S509g above, which will not be repeated here.

[0399] Another possible scenario is that the UPF determines that downlink traffic is not allowed into the DIP transport network. Another possible scenario is that the RAN determines that uplink traffic is not allowed into the DIP transport network.

[0400] Optionally, after the UPF / RAN determines that the service flow is not admitted to the DIP transport network, it can also generate admission failure confirmation information, which is used to confirm that the service flow is not admitted to the DIP transport network.

[0401] Optionally, if the UPF / RAN determines that the service flow is not allowed to enter the DIP transport network, the following steps S608a to S608b may also be included.

[0402] S608a, the UPF returns an admission failure confirmation message to the SMF, and the SMF receives the admission failure confirmation message from the UPF accordingly.

[0403] In step S608a, the admission failure confirmation information is used to confirm that the downlink service flow is not admitted to the DIP transport network. After generating the admission failure confirmation information, the UPF returns the admission failure confirmation information to the SMF to inform the SMF that the downlink service flow is not admitted to the DIP transport network.

[0404] S608b, the RAN returns an admission failure confirmation message to the SMF, and the SMF receives the admission failure confirmation message from the RAN accordingly.

[0405] In step S608b, the admission failure confirmation information is used to confirm that the uplink service flow is not admitted to the DIP transport network. After generating the admission failure confirmation information, the RAN returns the admission failure confirmation information to the SMF to inform the SMF that the uplink service flow is not admitted to the DIP transport network.

[0406] Optionally, after receiving the admission failure confirmation information, the SMF can also inform the requesting party (e.g., AF, PCF, or UE) that the service flow admission has failed, or reject the service flow request (such as a QoS request), or delete the corresponding service flow. For example, the SMF can send an indication message to the requesting party to indicate that the DIP transport network has rejected the service flow admission request. Optionally, the indication message can also include a reason value to indicate the reason why the DIP transport network rejected the service flow admission request.

[0407] The above embodiments provide a process for performing DIP transport network access control on 5G service flows in a scenario where 5GS supports DIP. The DIP transport network edge node acts as a storage network element for DIP instance information. The 5GS side interacts with the DIP transport network side to perform the access control function. Specifically, the UPF / RAN makes the access judgment. The DIP transport network edge node provides DIP instance information to the UPF / RAN to help the UPF / RAN achieve access control. This is suitable for a distributed architecture.

[0408] Please see Figure 7 , Figure 7 This is a flowchart illustrating another communication method provided in an embodiment of this application. Figure 7 The illustrated embodiments can be applied to Figure 3 The distributed architecture shown illustrates this method using the interaction process between SMF, UPF, and RAN as an example. In this embodiment, the network element for storing DIP instance information is UPF / RAN.

[0409] like Figure 7 As shown, the communication method may include, but is not limited to, the following steps.

[0410] S701, SMF receives a request to perform DIP transmission for the service flow.

[0411] S702a, the SMF sends an admission control enforcement request to the UPF, and the UPF receives the admission control enforcement request from the SMF accordingly.

[0412] S702b, the SMF sends an admission control enforcement request to the RAN, and the RAN receives the admission control enforcement request from the SMF accordingly.

[0413] For a detailed description of steps S701, S702a, and S702b, please refer to the relevant descriptions of steps S501, S502a, and S502b above; they will not be repeated here.

[0414] S703, UPF / RAN execution parameter mapping.

[0415] For a detailed description of the parameter mapping in step S703, please refer to the relevant descriptions in steps S503 and / or S505 above, which will not be repeated here.

[0416] S704, UPF / RAN determines whether a service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0417] In step S704, the DIP instance information comes from the DIP instance information stored in the UPF / RAN, meaning the UPF / RAN knows the DIP instance information and can obtain it from its own stored information. For example, this DIP instance information can be all DIP instance information supported by the UPF / RAN for access.

[0418] For downlink traffic, the UPF determines whether the downlink traffic is allowed to enter the DIP transport network based on the downlink traffic's flow requirements and its stored DIP instance information. For uplink traffic, the RAN determines whether the uplink traffic is allowed to enter the DIP transport network based on the uplink traffic's flow requirements and its stored DIP instance information.

[0419] For a detailed description of the admission determination in step S704, please refer to the relevant description in step S506 above, which will not be repeated here.

[0420] One possible scenario is that the UPF determines that downlink traffic is admitted to the DIP transport network. Another possible scenario is that the RAN determines that uplink traffic is admitted to the DIP transport network.

[0421] Optionally, if the UPF / RAN determines that the service flow is admitted to the DIP transport network, the following steps S705a to S705g may also be included.

[0422] S705a, UPF / RAN determines the target DIP instance.

[0423] S705b, UPF / RAN updates the information of the target DIP instance based on the flow requirements of the service flow.

[0424] After determining the target DIP instance (i.e., the first target DIP instance mentioned above), the UPF can update the information of the first target DIP instance stored in its own memory based on the flow requirements of the downlink service flow. For example, the UPF can update the current available remaining bandwidth of the first target DIP instance based on the GFBR in the flow requirements of the downlink service flow.

[0425] After the RAN determines the target DIP instance (i.e., the second target DIP instance mentioned above), it can update the information of the second target DIP instance stored in its own memory based on the flow requirements of the uplink traffic. For example, the RAN can update the current available remaining bandwidth of the second target DIP instance based on the GFBR in the flow requirements of the uplink traffic.

[0426] Optionally, after the UPF / RAN determines that the service flow has been admitted to the DIP transport network, it can also generate admission success confirmation information, which is used to confirm that the service flow has been admitted to the DIP transport network.

[0427] S705c, the UPF returns an admission success confirmation message to the SMF, and the SMF receives the admission success confirmation message from the UPF accordingly.

[0428] After generating the admission success confirmation message, the UPF returns the admission success confirmation message to the SMF to inform the SMF that the downlink service flow has been admitted to the DIP transport network.

[0429] S705d, the RAN returns an admission success confirmation message to the SMF, and the SMF receives the admission success confirmation message from the RAN accordingly.

[0430] After generating the admission success confirmation information, the RAN returns the admission success confirmation information to the SMF to inform the SMF that the uplink service flow has been admitted to the DIP transport network.

[0431] In step S705a above, the target DIP instance is determined by the UPF / RAN. It should be understood that in other possible implementations, the target DIP instance may also be determined by the SMF.

[0432] Optionally, steps S705a to S705d can be replaced by steps S705c to S705d, steps S706e and S706g, and step S705b.

[0433] In the replaced step S705c, the admission success confirmation information includes information about at least one of the above-mentioned optional DIP instances (i.e., DIP instances that can be admitted to the downlink service flow), which is used to instruct the SMF to determine the target DIP instance (for distinction, it is referred to as the third target DIP instance).

[0434] In the replaced step S607e, the admission success confirmation information includes information about at least one of the above-mentioned optional DIP instances (i.e., DIP instances that can be admitted to the uplink traffic flow), which is used to instruct the SMF to determine the target DIP instance (for distinction, it is referred to as the fourth target DIP instance).

[0435] S705e, SMF identifies the target DIP instance.

[0436] After receiving the admission success confirmation information from the UPF, the SMF can obtain information about at least one of the above-mentioned optional DIP instances (i.e., DIP instances that can be admitted to the downlink service flow), and determine the third target DIP instance from the above-mentioned at least one optional DIP instance.

[0437] After receiving the admission success confirmation information from the RAN, the SMF can obtain information on at least one of the above-mentioned optional DIP instances (i.e., DIP instances that can be admitted to the uplink service flow), and determine the fourth target DIP instance from the above-mentioned at least one optional DIP instance.

[0438] S705f, the SMF sends information to the UPF to indicate the target DIP instance, and the UPF receives the information from the SMF to indicate the target DIP instance accordingly.

[0439] After the SMF identifies the third target DIP instance, it can send information to the UPF to indicate the third target DIP instance, which informs the UPF of the DIP instance that needs to be updated (i.e., the third target DIP instance), or to trigger the UPF to update the information of the third target DIP instance.

[0440] It is understandable that since the UPF has already obtained the flow requirements of the downlink service flow in step S702a above, there is no need to send the flow requirements of the downlink service flow to the UPF again in step S705f above.

[0441] After receiving the information indicating the third target DIP instance, the UPF can determine the third target DIP instance and execute the replacement step S705b, specifically updating the information of the third target DIP instance stored in its own memory based on the flow requirements of the downlink service flow. For example, the UPF can update the current available remaining bandwidth of the third target DIP instance based on the GFBR in the flow requirements of the downlink service flow.

[0442] In S705g, the SMF sends information to the RAN indicating the target DIP instance, and the RAN receives the information from the SMF indicating the target DIP instance accordingly.

[0443] After the SMF determines the fourth target DIP instance, it can send information to the RAN to indicate the fourth target DIP instance, which is used to inform the RAN of the DIP instance that needs to be updated (i.e., the fourth target DIP instance), or to trigger the RAN to update the information of the fourth target DIP instance.

[0444] It is understandable that since the RAN has already obtained the uplink service flow requirements in step S702b above, there is no need to send the uplink service flow requirements to the RAN again in step S705g above.

[0445] After receiving the information indicating the fourth target DIP instance, the RAN can determine the fourth target DIP instance and execute the replacement step S705b, specifically updating the information of the fourth target DIP instance stored in its own memory based on the flow requirements of the uplink service flow. For example, the RAN can update the current available remaining bandwidth of the fourth target DIP instance based on the GFBR in the flow requirements of the uplink service flow.

[0446] For the content not specifically described in steps S705a to S705g, please refer to the relevant descriptions in steps S509a to S509g above, which will not be repeated here.

[0447] Another possible scenario is that the UPF determines that the service flow is not allowed into the DIP transport network. Another possible scenario is that the RAN determines that the uplink service flow is not allowed into the DIP transport network.

[0448] Optionally, after the UPF / RAN determines that the service flow is not admitted to the DIP transport network, it can also generate admission failure confirmation information, which is used to confirm that the service flow is not admitted to the DIP transport network.

[0449] Optionally, if the UPF / RAN determines that the service flow is not allowed to enter the DIP transport network, the following steps S706a to S706b may also be included.

[0450] S706a, the UPF returns an admission failure confirmation message to the SMF, and the SMF receives the admission failure confirmation message from the UPF accordingly.

[0451] In step S706a, the admission failure confirmation information is used to confirm that the downlink service flow is not admitted to the DIP transport network. After generating the admission failure confirmation information, the UPF returns the admission failure confirmation information to the SMF to inform the SMF that the downlink service flow is not admitted to the DIP transport network.

[0452] S706b, the RAN returns an admission failure confirmation message to the SMF, and the SMF receives the admission failure confirmation message from the RAN accordingly.

[0453] In step S706b, the admission failure confirmation information is used to confirm that the uplink service flow is not admitted to the DIP transport network. After generating the admission failure confirmation information, the RAN returns the admission failure confirmation information to the SMF to inform the SMF that the uplink service flow is not admitted to the DIP transport network.

[0454] Optionally, after receiving the admission failure confirmation information, the SMF can also inform the requesting party (e.g., AF, PCF, or UE) that the service flow admission has failed, or reject the service flow request (such as a QoS request), or delete the corresponding service flow. For example, the SMF can send an indication message to the requesting party to indicate that the DIP transport network has rejected the service flow admission request. Optionally, the indication message can also include a reason value to indicate the reason why the DIP transport network rejected the service flow admission request.

[0455] The above embodiments provide a process for performing DIP transport network access control on 5G service flows in a scenario where 5GS supports DIP. The UPF / RAN serves as the storage network element for DIP instance information, and the access control function is performed by the 5GS side. Specifically, the UPF / RAN makes the access judgment, without the need for additional interaction with the DIP transport network, which is suitable for distributed architecture.

[0456] Please see Figure 8 , Figure 8 This is a flowchart illustrating another communication method provided in an embodiment of this application. Figure 8 The illustrated embodiments can be applied to Figure 3 The distributed architecture shown illustrates this method using the interaction process between SMF, UPF, and RAN as an example. In this embodiment, the network element for storing DIP instance information is UPF / RAN.

[0457] like Figure 8 As shown, the communication method may include, but is not limited to, the following steps.

[0458] S801, SMF receives a request to perform DIP transmission for the service flow.

[0459] For a detailed description of step S801, please refer to the relevant description of step S501 above, which will not be repeated here.

[0460] S802a, the SMF sends an acquisition request to the UPF, and the UPF receives the acquisition request from the SMF accordingly.

[0461] In step S802a, the request is used to request the DIP instance information, or in other words, to request or trigger the UPF to return the DIP instance information.

[0462] In S802b, the SMF sends an acquisition request to the RAN, and the RAN receives the acquisition request from the SMF accordingly.

[0463] In step S802b, the request is used to request the acquisition of DIP instance information, or in other words, to request or trigger the RAN to return DIP instance information.

[0464] S803a, the UPF returns DIP instance information to the SMF, and correspondingly, the SMF receives the DIP instance information from the UPF.

[0465] In step S803a, the DIP instance information returned by the UPF comes from the DIP instance information stored in the UPF. This DIP instance information includes information about at least one DIP instance, which may include the DIP instance's identity information (e.g., DIP instance identifier), as well as the DIP instance's quality of service guarantees and / or remaining resources.

[0466] S803b, the RAN returns DIP instance information to the SMF, and correspondingly, the SMF receives the DIP instance information from the RAN.

[0467] In step S803b, the DIP instance information returned by the RAN comes from the DIP instance information stored by the RAN. This DIP instance information includes information about at least one DIP instance, which may include the DIP instance's identity information (e.g., DIP instance identifier), as well as the DIP instance's quality of service guarantees and / or remaining resources.

[0468] Optionally, UPF / RAN can also perform parameter mapping. When UPF / RAN performs parameter mapping, the DIP instance information received by SMF may include the DIP instance's quality of service guarantees and / or remaining resource mapping parameters.

[0469] Optionally, parameter mapping can also be performed by the SMF. For example, if parameter mapping is not performed by the UPF / RAN, the SMF can also perform the following step S804.

[0470] S804, SMF execution parameter mapping.

[0471] For a detailed description of the parameter mapping in step S804, please refer to the relevant descriptions in steps S503 and / or S505 above, which will not be repeated here.

[0472] S805, SMF determines whether a service flow is allowed to enter the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0473] Unlike Figure 7 In the illustrated embodiment, the UPF / RAN determines whether a service flow is admitted to the DIP transport network. Figure 8 The embodiment shown uses SMF to determine whether a service flow is admitted to the DIP transport network.

[0474] For downlink traffic, the SMF determines whether the downlink traffic is admitted to the DIP transport network based on the downlink traffic's flow requirements and DIP instance information from the UPF. For uplink traffic, the RAN determines whether the uplink traffic is admitted to the DIP transport network based on the uplink traffic's flow requirements and DIP instance information from the RAN.

[0475] For a detailed description of the admission determination in step S805, please refer to the relevant description in step S506 above, which will not be repeated here.

[0476] One possible scenario is that the SMF determines the service flow is admitted to the DIP transport network. Another possible scenario is that the SMF determines the service flow is not admitted to the DIP transport network.

[0477] Optionally, if the SMF determines that the service flow is admitted to the DIP transport network, the steps S806a to S806c may also be included.

[0478] S806a, SMF determines the target DIP instance.

[0479] For downlink traffic, the target DIP instance determined by SMF is the first target DIP instance mentioned above. For uplink traffic, the target DIP instance determined by SMF is the second target DIP instance mentioned above.

[0480] For a detailed description of determining the target DIP instance in step S806a, please refer to the relevant description in step S509a above, which will not be repeated here.

[0481] S806b, the SMF sends flow requirements for information indicating the target DIP instance and service flow to the UPF, and correspondingly, the UPF receives flow requirements for information indicating the target DIP instance and service flow from the SMF.

[0482] In step S806b, the target DIP instance refers to the aforementioned first target DIP instance. After determining the first target DIP instance, the SMF can send information indicating the first target DIP instance and the flow requirements of the downlink service flow to the UPF. This is used to inform the UPF of the DIP instance that needs to be updated (i.e., the first target DIP instance) and the flow requirements of the downlink service flow, or in other words, to trigger the UPF to update the information of the first target DIP instance according to the flow requirements of the downlink service flow.

[0483] After receiving information indicating the first target DIP instance and the flow requirements of the downlink traffic, the UPF can determine the first target DIP instance and update the information of the first target DIP instance stored in its own database based on the flow requirements of the downlink traffic. For example, the UPF can update the current available remaining bandwidth of the first target DIP instance based on the GFBR in the flow requirements of the downlink traffic.

[0484] In S806c, the SMF sends flow requirements to the RAN to indicate the target DIP instance and the service flow. In turn, the RAN receives the flow requirements from the SMF to indicate the target DIP instance and the service flow.

[0485] In step S806c, the target DIP instance refers to the aforementioned second target DIP instance. After determining the second target DIP instance, the SMF can send information indicating the second target DIP instance and the uplink service flow requirements to the RAN. This is used to inform the RAN of the DIP instance that needs to be updated (i.e., the second target DIP instance) and the uplink service flow requirements, or in other words, to trigger the RAN to update the information of the second target DIP instance according to the uplink service flow requirements.

[0486] After receiving information indicating the second target DIP instance and the flow requirements of the uplink traffic, the RAN can determine the second target DIP instance and update its stored information about the second target DIP instance based on the flow requirements of the uplink traffic. For example, the RAN can update the current available remaining bandwidth of the second target DIP instance based on the GFBR in the flow requirements of the uplink traffic.

[0487] Optionally, if the SMF determines that a service flow is not permitted to enter the DIP transport network, the SMF can also inform the requesting party (e.g., AF, PCF, or UE) that the service flow admission has failed, or reject the service flow request (such as a QoS request), or delete the corresponding service flow. For example, the SMF can send an indication message to the requesting party to indicate that the DIP transport network has rejected the service flow admission request. Optionally, this indication message can also include a reason value to indicate the reason why the DIP transport network rejected the service flow admission request.

[0488] The above embodiment provides a process for performing DIP transport network access control on 5G service flows in a scenario where 5GS supports DIP. The UPF / RAN serves as the network element storing DIP instance information, and the access control function is performed by the 5GS side. Specifically, the SMF makes the access judgment, and the UPF / RAN provides DIP instance information to the SMF to help the SMF achieve access control. No additional interaction with the DIP transport network is required, which is suitable for a distributed architecture.

[0489] Please see Figure 9 , Figure 9 This is a flowchart illustrating another communication method provided in an embodiment of this application. Figure 9 The illustrated embodiments can be applied to Figure 3 The distributed architecture shown or Figure 4 The centralized architecture shown illustrates the method using the interaction process between SMF, UPF, RAN, PCF, and UDR as an example. In this embodiment, the network element for storing DIP instance information is the UDR.

[0490] like Figure 9 As shown, the communication method may include, but is not limited to, the following steps.

[0491] S901, SMF receives a request to perform DIP transmission for the service flow.

[0492] For a detailed description of step S901, please refer to the relevant description of step S501 above, which will not be repeated here.

[0493] S902, the SMF sends an acquisition request to the UDR through the PCF, and correspondingly, the UDR receives the acquisition request from the SMF through the PCF.

[0494] In step S902, the retrieval request is used to request the retrieval of DIP instance information, or in other words, to request or trigger the UDR to return DIP instance information. Specifically, the SMF sends a retrieval request to the PCF, and the PCF forwards the retrieval request to the UDR.

[0495] S903, UDR returns DIP instance information to SMF through PCF, and correspondingly, SMF receives DIP instance information from UDR through PCF.

[0496] In step S903, the DIP instance information returned by the UDR comes from the DIP instance information stored in the UDR. For example, the DIP instance information may be the DIP instance information supported by the RAN and / or UPF corresponding to the current session, or it may be the DIP instance information supported by the RAN for all access.

[0497] Specifically, the UDR sends DIP instance information to the PCF, and the PCF forwards the DIP instance information to the SMF. The DIP instance information includes information about at least one DIP instance, which may include the DIP instance's identity information (e.g., DIP instance identifier), as well as the DIP instance's quality of service guarantees and / or remaining resources.

[0498] Optionally, the DIP instance information stored in the UDR may include parameters related to the DIP instance's Quality of Service (QoS) assurance and / or remaining resource mapping. These parameters can be mapped by other network elements (such as edge nodes) and then stored in the UDR, or the UDR itself can perform the parameter mapping. In this case, the DIP instance information received by the PCF and SMF may include parameters related to the DIP instance's QoS assurance and / or remaining resource mapping.

[0499] Optionally, parameter mapping can also be performed by the PCF. For example, if the UDR does not perform parameter mapping or does not store the parameters after mapping the QoS guarantees and / or remaining resources of the DIP instance, the PCF can perform parameter mapping so that the DIP instance information received by the SMF can include the parameters after mapping the QoS guarantees and / or remaining resources of the DIP instance.

[0500] Optionally, parameter mapping can also be performed by the SMF. For example, if the UDR does not perform parameter mapping or does not store the parameters after the Quality of Service Guarantee and / or Remaining Resources mapping for the DIP instance, or if the PCF does not perform parameter mapping, the SMF can also perform the following step S904.

[0501] S904, SMF execution parameter mapping.

[0502] For a detailed description of the parameter mapping in step S904, please refer to the relevant descriptions in steps S503 and / or S505 above, which will not be repeated here.

[0503] S905, SMF determines whether a service flow is allowed to enter the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0504] For a detailed description of the admission determination in step S905, please refer to the relevant description in step S506 above, which will not be repeated here.

[0505] One possible scenario is that the SMF determines the service flow is admitted to the DIP transport network. Another possible scenario is that the SMF determines the service flow is not admitted to the DIP transport network.

[0506] Optionally, if the SMF determines that a service flow has been admitted to the DIP transport network, the SMF may trigger a session modification procedure, which may include the following steps.

[0507] S906a, SMF determines the target DIP instance.

[0508] The target DIP instance can be understood as the DIP instance that the service flow is ultimately confirmed to be admitted to, or it can be understood as the DIP instance that the service flow will ultimately access. For a detailed description of determining the target DIP instance in step S906a, please refer to the relevant description in step S509a above, which will not be repeated here.

[0509] Optionally, after the SMF determines that the service flow has been admitted to the DIP transport network, it can trigger a session modification process, which may include the following steps.

[0510] S906b, the SMF sends information about the service flow and the target DIP instance to the UPF, and correspondingly, the UPF receives information about the service flow and the target DIP instance from the SMF.

[0511] In S906c, the SMF sends information about the service flow and the target DIP instance to the RAN, and the RAN receives the information about the service flow and the target DIP instance from the SMF.

[0512] In steps S906b and S906c, the target DIP instance can also be understood as the DIP instance bound to the service flow. The service flow information may include the service flow's identity information (e.g., service flow identifier). The target DIP instance information may include the DIP instance's identity information (e.g., DIP instance identifier), DIP end-station configuration (e.g., data packet sending period, maximum packet length, etc.).

[0513] S906d, the SMF sends information and flow requests for the target DIP instance to the UDR via the PCF, and correspondingly, the UDR receives information and flow requests for the target DIP instance from the SMF via the PCF.

[0514] Specifically, after the SMF identifies the target DIP instance, it sends information indicating the target DIP instance and the flow requirements of the service flow to the PCF. The PCF then forwards this information to the UDR, informing the UDR of the DIP instance (i.e., the target DIP instance) and the flow requirements of the service flow, or in other words, triggering the UDR to update the information of the target DIP instance according to the flow requirements of the service flow.

[0515] After receiving information indicating the target DIP instance and the flow requirements of the service flow, the UDR can determine the target DIP instance and update the information of the target DIP instance in its own storage based on the flow requirements of the service flow. For example, the UDR can update the current available remaining bandwidth of the target DIP instance based on the GFBR in the flow requirements.

[0516] Optionally, if the SMF determines that a service flow is not permitted to enter the DIP transport network, the SMF can also inform the requesting party (e.g., AF, PCF, or UE) that the service flow admission has failed, or reject the service flow request (such as a QoS request), or delete the corresponding service flow. For example, the SMF can send an indication message to the requesting party to indicate that the DIP transport network has rejected the service flow admission request. Optionally, this indication message can also include a reason value to indicate the reason why the DIP transport network rejected the service flow admission request.

[0517] The above embodiments provide a process for performing DIP transport network access control on 5G service flows in a scenario where 5GS supports DIP. The UDR, as the storage network element for DIP instance information, performs the access control function on the 5GS side. Specifically, the SMF makes the access judgment. The UDR provides DIP instance information to the SMF through the PCF to help the SMF achieve access control. No additional interaction with the DIP transport network is required, which is suitable for distributed and centralized architectures.

[0518] Please see Figure 10 , Figure 10 This is a flowchart illustrating another communication method provided in an embodiment of this application. Figure 10 The illustrated embodiments can be applied to Figure 3 The distributed architecture shown or Figure 4 The centralized architecture shown illustrates the method using the interaction process between SMF, UPF, RAN, PCF, and UDR as an example. In this embodiment, the network element for storing DIP instance information is the UDR.

[0519] like Figure 10 As shown, the communication method may include, but is not limited to, the following steps.

[0520] S1001, PCF receives a request to perform DIP transmission for the service flow.

[0521] Specifically, the PCF can receive requests from the AF or other events to perform DIP transmission for the service flow. In this embodiment, the flow requirements of the service flow are known to the PCF.

[0522] S1002, PCF sends an acquisition request to UDR, and UDR receives the acquisition request from SMF accordingly.

[0523] In step S1002, the request is used to request the DIP instance information, or in other words, to request or trigger the UDR to return the DIP instance information.

[0524] S1003, UDR returns DIP instance information to PCF, and correspondingly, PCF receives DIP instance information from UDR.

[0525] In step S1003, the DIP instance information returned by the UDR comes from the DIP instance information stored in the UDR. This DIP instance information includes information about at least one DIP instance, which may include the DIP instance's identity information (e.g., DIP instance identifier), as well as the DIP instance's quality of service guarantees and / or remaining resources.

[0526] Optionally, the DIP instance information stored in the UDR may include parameters related to the DIP instance's Quality of Service (QoS) assurance and / or remaining resource mapping. These parameters can be mapped by other network elements (such as edge nodes) and then stored in the UDR, or the UDR itself can perform the parameter mapping. In this case, the DIP instance information received by the PCF may include parameters related to the DIP instance's QoS assurance and / or remaining resource mapping.

[0527] Optionally, parameter mapping can also be performed by the PCF. For example, if the UDR does not perform parameter mapping or does not store the parameters after mapping the quality of service guarantees and / or remaining resources of the DIP instance, the PCF can also perform the following step S1004.

[0528] S1004, PCF execution parameter mapping.

[0529] For a detailed description of the parameter mapping in step S1004, please refer to the relevant descriptions in steps S503 and / or S505 above, which will not be repeated here.

[0530] S1005, PCF determines whether a service flow is allowed to enter the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0531] Unlike Figure 9 In the illustrated embodiment, the SMF determines whether a service flow is allowed into the DIP transport network. Figure 10 The embodiment shown uses the PCF to determine whether a service flow is admitted to the DIP transport network.

[0532] For a detailed description of the admission determination in step S1005, please refer to the relevant description in step S506 above, which will not be repeated here.

[0533] One possible scenario is that the PCF determines the service flow is admitted to the DIP transport network. Another possible scenario is that the PCF determines the service flow is not admitted to the DIP transport network.

[0534] Optionally, if the PCF determines that the service flow is admitted to the DIP transport network, the following step S1006 may also be included.

[0535] S1006, PCF sends a session modification request to SMF, and SMF receives the session modification request from PCF accordingly.

[0536] The session modification request may include information about at least one of the aforementioned optional DIP instances. After receiving the session modification request, the SMF can obtain the information about at least one of the aforementioned optional DIP instances from it. The session modification request is used to request the SMF to trigger a session modification process, which may include the following steps.

[0537] S1007a, SMF identifies the target DIP instance.

[0538] The target DIP instance can be understood as the DIP instance that the service flow is ultimately confirmed to be admitted to, or it can be understood as the DIP instance that the service flow will ultimately access. For a detailed description of determining the target DIP instance in step S1007a, please refer to the relevant description in step S509a above, which will not be repeated here.

[0539] S1007b, the SMF sends information about the service flow and the target DIP instance to the UPF, and correspondingly, the UPF receives information about the service flow and the target DIP instance from the SMF.

[0540] S1007c, the SMF sends information about the service flow and the target DIP instance to the RAN, and the RAN receives the information about the service flow and the target DIP instance from the SMF accordingly.

[0541] For a detailed description of steps S1007b and S1007c, please refer to the relevant descriptions of steps S906b and S906c above, which will not be repeated here.

[0542] S1007d, the SMF sends information and flow requests for the target DIP instance to the UDR via the PCF, and correspondingly, the UDR receives information and flow requests for the target DIP instance from the SMF via the PCF.

[0543] Specifically, after the SMF determines the target DIP instance, it sends information indicating the target DIP instance to the PCF (since the PCF already knows the flow requirements of the service flow, there is no need to send the flow requirements of the service flow to the PCF here). The PCF forwards the information indicating the target DIP instance and the flow requirements of the service flow to the UDR, which is used to inform the UDR of the DIP instance (i.e. the target DIP instance) that needs to be updated and the flow requirements of the service flow, or in other words, to trigger the UDR to update the information of the target DIP instance according to the flow requirements of the service flow.

[0544] After receiving information indicating the target DIP instance and the flow requirements of the service flow, the UDR can determine the target DIP instance and update the information of the target DIP instance in its own storage based on the flow requirements of the service flow. For example, the UDR can update the current available remaining bandwidth of the target DIP instance based on the GFBR in the flow requirements.

[0545] Optionally, if the PCF determines that a service flow is not permitted to enter the DIP transport network, the PCF can also inform the requesting party (e.g., AF) that the service flow admission has failed, or reject the service flow request (such as a QoS request), or delete the corresponding service flow. For example, the PCF can send an indication message to the requesting party to indicate that the DIP transport network has rejected the service flow admission request. Optionally, this indication message can also include a reason value to indicate the reason why the DIP transport network rejected the service flow admission request.

[0546] The above embodiments provide a process for performing DIP transport network access control on 5G service flows in a scenario where 5GS supports DIP. The UDR, as the storage network element for DIP instance information, performs the access control function on the 5GS side. Specifically, the PCF makes the access judgment. The UDR provides DIP instance information to the PCF to help the PCF achieve access control. No additional interaction with the DIP transport network is required, which is suitable for distributed and centralized architectures.

[0547] Please see Figure 11 , Figure 11 This is a flowchart illustrating another communication method provided in an embodiment of this application. Figure 11 The illustrated embodiments can be applied to Figure 4 The centralized architecture shown illustrates the method using the interaction process between the SMF, UPF, RAN, and DIP transport network controller as an example. In this embodiment, the network element storing DIP instance information is the DIP transport network controller.

[0548] like Figure 11 As shown, the communication method may include, but is not limited to, the following steps.

[0549] S1101, SMF receives a request to perform DIP transmission for the service flow.

[0550] For a detailed description of step S1101, please refer to the relevant description of step S501 above, which will not be repeated here.

[0551] S1102, SMF execution parameter mapping.

[0552] For a detailed description of the parameter mapping in step S1102, please refer to the relevant description in step S503 above, which will not be repeated here.

[0553] S1103, the SMF sends an admission request to the DIP transport network controller, and the DIP transport network controller receives the admission request from the SMF accordingly.

[0554] In step S1103, the admission request may include the flow requirements of the service flow. After receiving the admission request, the DIP transport network controller can obtain the flow requirements of the service flow from it. Optionally, if the SMF has performed parameter mapping, the admission request may include the mapped parameters of the service flow's flow requirements. This admission request is used to request the DIP transport network admission judgment for the service flow, or in other words, to request or trigger the DIP transport network controller to determine whether the service flow is admitted to the DIP transport network.

[0555] Optionally, if the SMF does not perform parameter mapping, the DIP transport network controller may also perform the following step S1104 after obtaining the flow requirements of the service flow.

[0556] S1104, DIP transmission network controller performs parameter mapping.

[0557] For a detailed description of the parameter mapping in step S1104, please refer to the relevant descriptions in steps S503 and / or S505 above, which will not be repeated here.

[0558] Optionally, steps S1102 and S1104 can be executed in one of them. That is, the parameter mapping can be performed by the SMF or by the DIP transmission network controller.

[0559] S1105, the DIP transport network controller determines whether a service flow is allowed to enter the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0560] In step S1105, the DIP instance information comes from the DIP instance information stored by the DIP transport network controller. That is, the DIP transport network controller knows the DIP instance information and can obtain it from its own stored information. For example, the DIP instance information can be all DIP instance information configured in the current DIP transport network, or it can be the DIP instance information supported by the RAN and / or UPF corresponding to the current session.

[0561] For a detailed description of the admission determination in step S1105, please refer to the relevant description in step S506 above, which will not be repeated here.

[0562] Optionally, after determining whether a service flow is admitted to the DIP transport network, the DIP transport network controller can also generate admission control indication information, which is used to indicate whether a service flow is admitted to the DIP transport network.

[0563] S1106, the DIP transmission network controller returns admission control indication information to the SMF, and correspondingly, the SMF receives the admission control indication information from the DIP transmission network controller.

[0564] After generating the admission control indication information, the DIP transport network controller returns the admission control indication information to the SMF to inform the SMF whether the service flow is admitted to the DIP transport network.

[0565] In one possible scenario, the admission control indication information indicates that the service flow is admitted to the DIP transport network. In this case, the admission control indication information may include information about at least one of the optional DIP instances mentioned above. In another possible scenario, the admission control indication information indicates that the service flow is not admitted to the DIP transport network.

[0566] Optionally, if the admission control indication information indicates that the service flow is admitted to the DIP transport network, the SMF can trigger a session modification procedure, which may include the following steps.

[0567] S1107a, SMF identifies the target DIP instance.

[0568] The target DIP instance can be understood as the DIP instance that the service flow is ultimately confirmed to be admitted to, or it can be understood as the DIP instance that the service flow will ultimately access. For a detailed description of determining the target DIP instance in step S1107a, please refer to the relevant description in step S509a above, which will not be repeated here.

[0569] S1107b, the SMF sends information about the service flow and the target DIP instance to the UPF, and correspondingly, the UPF receives information about the service flow and the target DIP instance from the SMF.

[0570] S1107c, the SMF sends information about the service flow and the target DIP instance to the RAN, and the RAN receives the information about the service flow and the target DIP instance from the SMF accordingly.

[0571] For a detailed description of steps S1107b and S1107c, please refer to the relevant descriptions of steps S906b and S906c above, which will not be repeated here.

[0572] S1107d, the SMF sends information to the DIP transport network controller to indicate the target DIP instance, and the DIP transport network controller receives the information from the SMF to indicate the target DIP instance accordingly.

[0573] After identifying the target DIP instance, the SMF can send information to the DIP transport network controller to indicate the target DIP instance. This information informs the DIP transport network controller which DIP instance needs to be updated (i.e., the target DIP instance), or triggers the DIP transport network controller to update the information of the target DIP instance.

[0574] It is understandable that since the DIP transport network controller has already obtained the flow requirements of the service flow in step S1103 above, there is no need to send the flow requirements of the service flow to the DIP transport network controller again in step S1107d above.

[0575] After receiving information indicating a target DIP instance, the DIP transport network controller can determine the target DIP instance and update its stored information about the target DIP instance based on the flow requirements of the service flow. For example, the DIP transport network controller can update the current available remaining bandwidth of the target DIP instance based on the GFBR in the flow requirements.

[0576] Optionally, if the admission control indication information indicates that a service flow is not admitted to the DIP transport network, the SMF can also inform the requesting party (e.g., AF, PCF, or UE) that the service flow admission has failed, or reject the service flow request (such as a QoS request), or delete the corresponding service flow. For example, the SMF can send indication information to the requesting party to indicate that the DIP transport network has rejected the service flow's admission request. Optionally, this indication information can also include a reason value to indicate the reason why the DIP transport network rejected the service flow's admission request.

[0577] The above embodiments provide a process for performing DIP transport network access control on 5G service flows in a scenario where 5GS supports DIP. The DIP transport network controller, as the storage network element for DIP instance information, performs the access control function through interaction between the 5GS side and the DIP transport network side. Specifically, the DIP transport network controller makes the access judgment, which is suitable for a centralized architecture.

[0578] Please see Figure 12 , Figure 12 This is a flowchart illustrating another communication method provided in an embodiment of this application. Figure 12 The illustrated embodiments can be applied to Figure 4 The centralized architecture shown illustrates the method using the interaction process between the SMF, UPF, RAN, and DIP transport network controller as an example. In this embodiment, the network element storing DIP instance information is the DIP transport network controller.

[0579] like Figure 12 As shown, the communication method may include, but is not limited to, the following steps.

[0580] S1201, SMF receives a request to perform DIP transmission for the service flow.

[0581] S1202, the SMF sends an acquisition request to the DIP transport network controller, and the DIP transport network controller receives the acquisition request from the SMF accordingly.

[0582] In step S1202, the request is used to request the acquisition of DIP instance information, or to request or trigger the DIP transport network controller to return DIP instance information.

[0583] S1203, the DIP transport network controller returns DIP instance information to the SMF, and correspondingly, the SMF receives the DIP instance information from the DIP transport network controller.

[0584] In step S1203, the DIP instance information returned by the DIP transport network controller comes from the DIP instance information stored by the DIP transport network controller. This DIP instance information includes information about at least one DIP instance, which may include the DIP instance's identity information (e.g., DIP instance identifier), as well as the DIP instance's quality of service guarantees and / or remaining resources.

[0585] S1204, SMF execution parameter mapping.

[0586] For a detailed description of the parameter mapping in step S1204, please refer to the relevant description in step S503 above, which will not be repeated here.

[0587] S1205, SMF determines whether a service flow is allowed to enter the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0588] Unlike Figure 11 In the illustrated embodiment, the DIP transport network controller determines whether a service flow is allowed to enter the DIP transport network. Figure 12 The embodiment shown uses SMF to determine whether a service flow is admitted to the DIP transport network.

[0589] For a detailed description of the admission determination in step S1205, please refer to the relevant description in step S506 above, which will not be repeated here.

[0590] One possible scenario is that the SMF determines the service flow is admitted to the DIP transport network. Another possible scenario is that the SMF determines the service flow is not admitted to the DIP transport network.

[0591] Optionally, if the SMF determines that a service flow has been admitted to the DIP transport network, the SMF may trigger a session modification procedure, which may include the following steps.

[0592] S1206a, SMF determines the target DIP instance.

[0593] The target DIP instance can be understood as the DIP instance that the service flow is ultimately confirmed to be admitted to, or it can be understood as the DIP instance that the service flow will ultimately access. For a detailed description of determining the target DIP instance in step S1206a, please refer to the relevant description in step S509a above, which will not be repeated here.

[0594] S1206b, the SMF sends information about the service flow and the target DIP instance to the UPF, and correspondingly, the UPF receives information about the service flow and the target DIP instance from the SMF.

[0595] S1206c, the SMF sends information about the service flow and the target DIP instance to the RAN, and the RAN receives the information about the service flow and the target DIP instance from the SMF accordingly.

[0596] For a detailed description of steps S1206b and S1206c, please refer to the relevant descriptions of steps S906b and S906c above, which will not be repeated here.

[0597] S1206d, the SMF sends a flow request for information indicating the target DIP instance and the service flow to the DIP transport network controller, and correspondingly, the DIP transport network controller receives the flow request for information indicating the target DIP instance and the service flow from the SMF.

[0598] After identifying the target DIP instance, SMF can send information indicating the target DIP instance and the flow requirements of the service flow to the DIP transport network controller. This informs the DIP transport network controller of the DIP instance (i.e., the target DIP instance) that needs to be updated and the flow requirements of the service flow, or in other words, it triggers the DIP transport network controller to update the information of the target DIP instance according to the flow requirements of the service flow.

[0599] After receiving information indicating the target DIP instance and the flow requirements of the service flow, the DIP transport network controller can determine the target DIP instance and update the information of the target DIP instance in its own storage based on the flow requirements of the service flow. For example, the DIP transport network controller can update the current available remaining bandwidth of the target DIP instance based on the GFBR in the flow requirements.

[0600] Optionally, if the SMF determines that a service flow is not permitted to enter the DIP transport network, the SMF can also inform the requesting party (e.g., AF, PCF, or UE) that the service flow admission has failed, or reject the service flow request (such as a QoS request), or delete the corresponding service flow. For example, the SMF can send an indication message to the requesting party to indicate that the DIP transport network has rejected the service flow admission request. Optionally, this indication message can also include a reason value to indicate the reason why the DIP transport network rejected the service flow admission request.

[0601] The above embodiments provide a process for performing DIP transport network access control on 5G service flows in a scenario where 5GS supports DIP. The DIP transport network controller acts as a storage network element for DIP instance information. The 5GS side interacts with the DIP transport network side to perform the access control function. Specifically, the SMF makes the access judgment, and the DIP transport network controller provides DIP instance information to the SMF to help the UPF / RAN achieve access control. This is suitable for centralized architectures.

[0602] Furthermore, in this embodiment, the DIP instance information is stored on the DIP transport network side (e.g., DIP transport network edge node or DIP transport network controller), which has the following advantages: saving storage resources of 5GS network elements; subsequent changes in the DIP transport network mechanism, improvements or modifications to the DIP instance information will not have a significant impact on 5GS; the update process of the DIP instance information depends on the internal implementation of DIP and does not require frequent interaction between the DIP transport network and 5GS.

[0603] In this embodiment, storing DIP instance information on the 5GS side (e.g., UPF, RAN, or UDR) offers the following advantages: it facilitates the execution of functions such as service flow admission and flow identification information generation on the 5GS side without requiring frequent interaction between the 5GS and the DIP transport network. Furthermore, storing DIP instance information in the RAN and UPF requires consideration of DIP instance information synchronization. For example, in scenarios where different RANs (or UPFs) share the same DIP instance, when the DIP instance information needs updating, all different RANs (or UPFs) connected to the DIP instance need to synchronously update the DIP instance information. Storing DIP instance information in the UDR eliminates this need for consideration.

[0604] The methods of the embodiments of this application have been described in detail above. The following provides an apparatus for implementing any one of the methods in the embodiments of this application. For example, an apparatus is provided that includes a unit (or means) for implementing the steps performed by the network element / device in any of the above methods.

[0605] Please see Figure 13 , Figure 13 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application.

[0606] like Figure 13 As shown, the communication device 1300 may include a transceiver unit 1301 and a processing unit 1302. The transceiver unit 1301 and the processing unit 1302 may be software, hardware, or a combination of software and hardware.

[0607] The transceiver unit 1301 can implement sending and / or receiving functions, and can also be described as a communication unit. The transceiver unit 1301 can also be a unit integrating an acquisition unit and a sending unit, wherein the acquisition unit is used to implement the receiving function, and the sending unit is used to implement the sending function. Optionally, the transceiver unit 1301 can be used to receive information sent by other devices, and can also be used to send information to other devices.

[0608] In one possible implementation, the various units are described as follows:

[0609] The transceiver unit 1301 is used to obtain the flow requirements of the service flow and to obtain DIP instance information. The DIP instance information includes the quality of service guarantee and / or remaining resources of at least one DIP instance. Each DIP instance corresponds to a pre-configured DIP transport network subnet.

[0610] Processing unit 1302 is used to determine whether the service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0611] In one possible implementation, the quality of service guarantee and / or remaining resources of the DIP instance are used to indicate the admission threshold of the DIP instance;

[0612] The step of determining whether a service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information includes:

[0613] If the at least one DIP instance includes at least one optional DIP instance, then the service flow is determined to be admitted to the DIP transport network; or,

[0614] If the optional DIP instance is not included in the at least one DIP instance, then the service flow is determined not to be admitted to the DIP transport network;

[0615] The optional DIP instance meets the following condition: the flow requirements of the service flow meet the entry requirements of the optional DIP instance.

[0616] In one possible implementation, the flow requirements of the service flow include one or more of the following: guaranteed flow bit rate, packet delay budget, maximum frame length, or packet error rate.

[0617] The admission thresholds include one or more of the following: remaining bandwidth resources, latency guarantee, maximum allowed transmission unit, or packet loss rate guarantee.

[0618] The flow requirements of the service flow meet the admission criteria of the optional DIP instance, including one or more of the following:

[0619] The bandwidth resources corresponding to the guaranteed stream bit rate are less than or equal to the remaining bandwidth resources of the optional DIP instance;

[0620] The latency requirement corresponding to the packet latency budget is greater than or equal to the latency guarantee of the optional DIP instance;

[0621] The transmission unit corresponding to the maximum frame length is less than or equal to the maximum transmission unit allowed by the optional DIP instance;

[0622] The packet loss rate corresponding to the error rate is greater than or equal to the packet loss rate guarantee of the optional DIP instance.

[0623] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the transceiver unit 1301 is further configured to:

[0624] Send information indicating the target DIP instance and the flow requirements of the service flow to the network element storing the DIP instance information, wherein the target DIP instance is one of the at least one optional DIP instance, and is the DIP instance that the service flow is admitted to.

[0625] In another possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the processing unit 1302 is further configured to:

[0626] The information of the target DIP instance is updated based on the flow requirements of the service flow, wherein the target DIP instance is one of the at least one optional DIP instance, and serves as the DIP instance for which the service flow is admitted.

[0627] Optionally, the communication device 1300 may correspond to the UPF, RAN, SMF, PCF, DIP transmission network edge node or DIP transmission network controller in the above method embodiments. For example, the communication device 1300 may be the UPF, RAN, SMF, PCF, DIP transmission network edge node or DIP transmission network controller in the above method embodiments, or it may be a chip in the UPF, RAN, SMF, PCF, DIP transmission network edge node or DIP transmission network controller.

[0628] Optionally, the network element storing DIP instance information can be a UPF, RAN, UDR, DIP transport network edge node, or DIP transport network controller.

[0629] In one possible design, the communication device 1300 may correspond to the UPF in the above method embodiments. For example, the communication device 1300 may be the UPF in the above method embodiments, or it may be a chip within the UPF. The communication device 1300 may include units for performing the operations performed by the UPF in the above method embodiments, and each unit in the communication device 1300 is for implementing the operations performed by the UPF in the above method embodiments. The descriptions of each unit are as follows:

[0630] The transceiver unit 1301 is used to receive the flow requirements of the service flow from the SMF, and to obtain the DIP instance information stored in its own storage, or to receive the DIP instance information from the edge node of the DIP transmission network.

[0631] Processing unit 1302 is used to determine whether the service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0632] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the processing unit 1302 is further configured to: determine the target DIP instance;

[0633] The transceiver unit 1301 is further configured to: send information indicating the target DIP instance and the flow requirements of the service flow to the DIP transport network edge node.

[0634] In another possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the transceiver unit 1301 is further configured to: receive information from the SMF indicating the target DIP instance, and send the information indicating the target DIP instance and the flow requirement of the service flow to the edge node of the DIP transport network.

[0635] In one possible implementation, when it is determined that the service flow is admitted to the DIP transport network, the processing unit 1302 is further configured to: determine the target DIP instance and update the information of the target DIP instance based on the flow requirements of the service flow.

[0636] In another possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the transceiver unit 1301 is further configured to: receive information from the SMF indicating the target DIP instance;

[0637] The processing unit 1302 is further configured to: update the information of the target DIP instance based on the flow requirements of the service flow.

[0638] In another possible design, the communication device 1300 may correspond to the RAN in the above method embodiments. For example, the communication device 1300 may be the RAN in the above method embodiments, or it may be a chip in the RAN. The communication device 1300 may include units for performing the operations performed by the RAN in the above method embodiments, and each unit in the communication device 1300 is for implementing the operations performed by the RAN in the above method embodiments. The descriptions of each unit are as follows:

[0639] The transceiver unit 1301 is used to receive the flow requirements of the service flow from the SMF, and to obtain the DIP instance information stored in its own storage, or to receive the DIP instance information from the edge node of the DIP transmission network.

[0640] Processing unit 1302 is used to determine whether the service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0641] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the processing unit 1302 is further configured to: determine the target DIP instance;

[0642] The transceiver unit 1301 is further configured to: send information indicating the target DIP instance and the flow requirements of the service flow to the DIP transport network edge node.

[0643] In another possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the transceiver unit 1301 is further configured to: receive information from the SMF indicating the target DIP instance, and send the information indicating the target DIP instance and the flow requirement of the service flow to the edge node of the DIP transport network.

[0644] In one possible implementation, when it is determined that the service flow is admitted to the DIP transport network, the processing unit 1302 is further configured to: determine the target DIP instance and update the information of the target DIP instance based on the flow requirements of the service flow.

[0645] In another possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the transceiver unit 1301 is further configured to: receive information from the SMF indicating the target DIP instance;

[0646] The processing unit 1302 is further configured to: update the information of the target DIP instance based on the flow requirements of the service flow.

[0647] In another possible design, the communication device 1300 may correspond to the SMF in the above method embodiments. For example, the communication device 1300 may be the SMF in the above method embodiments, or it may be a chip within the SMF. The communication device 1300 may include units for performing the operations performed by the SMF in the above method embodiments, and each unit in the communication device 1300 is for implementing the operations performed by the SMF in the above method embodiments. The descriptions of each unit are as follows:

[0648] The transceiver unit 1301 is used to receive DIP instance information from the UPF, RAN or DIP transport network controller, or to receive DIP instance information from the UDR via the PCF;

[0649] Processing unit 1302 is used to determine whether the service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0650] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the processing unit 1302 is further configured to: determine the target DIP instance;

[0651] The transceiver unit 1301 is further configured to: send information indicating the target DIP instance and the flow requirements of the service flow to the UPF, the RAN, or the DIP transport network controller.

[0652] In another possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the processing unit 1302 is further configured to: determine the target DIP instance;

[0653] The transceiver unit 1301 is further configured to: send information indicating the target DIP instance and the flow requirements of the service flow to the UDR via the PCF.

[0654] In another possible design, the communication device 1300 may correspond to the PCF in the above method embodiments. For example, the communication device 1300 may be the PCF in the above method embodiments, or it may be a chip within the PCF. The communication device 1300 may include units for performing the operations performed by the PCF in the above method embodiments, and each unit in the communication device 1300 is for implementing the operations performed by the PCF in the above method embodiments. The descriptions of each unit are as follows:

[0655] Transceiver unit 1301 is used to receive DIP instance information from UDR;

[0656] Processing unit 1302 is used to determine whether the service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0657] In one possible implementation, when it is determined that the service flow is admitted to the DIP transport network, the transceiver unit 1301 is further configured to: receive information from the SMF indicating the target DIP instance, and send the information indicating the target DIP instance and the flow requirement of the service flow to the UDR.

[0658] In another possible design, the communication device 1300 may correspond to the DIP transmission network edge node in the above method embodiments. For example, the communication device 1300 may be the DIP transmission network edge node in the above method embodiments, or it may be a chip in the DIP transmission network edge node. The communication device 1300 may include units for performing the operations performed by the DIP transmission network edge node in the above method embodiments, and each unit in the communication device 1300 is respectively for implementing the operations performed by the DIP transmission network edge node in the above method embodiments.

[0659] The descriptions of each unit are as follows:

[0660] The transceiver unit 1301 is used to receive the flow requirements of the service flow from the UPF / RAN, and to obtain the DIP instance information stored in its own storage.

[0661] Processing unit 1302 is used to determine whether the service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0662] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the transceiver unit 1301 is further configured to: receive information from the UPF / RAN indicating the target DIP instance;

[0663] The processing unit 1302 is further configured to: update the information of the target DIP instance based on the flow requirements of the service flow.

[0664] In another possible design, the communication device 1300 may correspond to the DIP transmission network controller in the above method embodiments. For example, the communication device 1300 may be the DIP transmission network controller in the above method embodiments, or it may be a chip in the DIP transmission network controller. The communication device 1300 may include units for performing the operations performed by the DIP transmission network controller in the above method embodiments, and each unit in the communication device 1300 is for implementing the operations performed by the DIP transmission network controller in the above method embodiments. The descriptions of each unit are as follows:

[0665] The transceiver unit 1301 is used to receive the flow requirements of the service flow from the SMF and to obtain the DIP instance information stored in its own storage.

[0666] Processing unit 1302 is used to determine whether the service flow is admitted to the DIP transport network based on the flow requirements of the service flow and the DIP instance information.

[0667] In one possible implementation, if it is determined that the service flow is admitted to the DIP transport network, the transceiver unit 1301 is further configured to: receive information from the SMF indicating the target DIP instance;

[0668] The processing unit 1302 is further configured to: update the information of the target DIP instance based on the flow requirements of the service flow.

[0669] According to the embodiments of this application, Figure 13 The various units in the illustrated device can be individually or entirely combined into one or more other units, or some of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effects of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can be implemented by multiple units, or the function of multiple units can be implemented by one unit. In other embodiments of this application, the above device may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units.

[0670] It should be noted that the implementation of each unit can also refer to the corresponding description in the above method embodiments.

[0671] Please see Figure 14 , Figure 14 This is a schematic diagram of a communication device provided in an embodiment of this application. The communication device 1400 may include a processor 1401. Optionally, the communication device 1400 may also include a memory 1402. Further optionally, the communication device 1400 may also include a communication interface 1403 and a bus 1404. The processor 1401, memory 1402, and communication interface 1403 are interconnected via the bus 1404. The communication interface 1403 is used for data interaction with other devices.

[0672] The processor 1401 is a module that performs arithmetic and logical operations, and can be one or a combination of processing modules such as a central processing unit (CPU), a graphics processing unit (GPU), or a microprocessor unit (MPU). The processor 1401 can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0673] The memory 1402 is used to provide storage space, in which data such as the operating system and computer programs can be stored. The memory 1402 includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM).

[0674] In some possible designs, the communication device 1400 may correspond to the UPF, RAN, SMF, PCF, DIP transmission network edge node, or DIP transmission network controller in the above method embodiments. For example, the communication device 1400 may be the UPF, RAN, SMF, PCF, DIP transmission network edge node, or DIP transmission network controller in the above method embodiments, or it may be a processor, circuit, chip, or chip system in the UPF, RAN, SMF, PCF, DIP transmission network edge node, or DIP transmission network controller. The communication device 1400 may include components for performing the operations performed by the UPF, RAN, SMF, PCF, DIP transmission network edge node, or DIP transmission network controller in the above method embodiments. Each component in the communication device 1400 is for implementing the operations performed by the UPF, RAN, SMF, PCF, DIP transmission network edge node, or DIP transmission network controller in the above method embodiments. The processor 1401 calls the computer program stored in the memory 1402 to execute the method shown in the above method embodiments.

[0675] Optionally, the communication device 1400 may be a chip or a chip system. For the case where the communication device 1400 is a chip or a chip system, please refer to [link to relevant documentation]. Figure 15 The diagram shows the structure of the chip.

[0676] like Figure 15 As shown, chip 1500 includes processor 1501 and interface 1502. The number of processors 1501 can be one or more, and the number of interfaces 1502 can be multiple. It should be noted that the functions of processor 1501 and interface 1502 can be implemented through hardware design, software design, or a combination of both; no restrictions are placed here.

[0677] Optionally, the chip 1500 may also include a memory 1503 for storing necessary program instructions and data.

[0678] In this application, processor 1501 can be used to call an implementation program of the communication method in an electronic device provided by one or more embodiments of this application from memory 1503, and execute the instructions contained in the program. Interface 1502 can be used to output the execution result of processor 1501. In this application, interface 1502 can be specifically used to output various messages or information from processor 1501.

[0679] The communication methods provided by one or more embodiments of this application can be referred to the above-described method embodiments, and will not be repeated here.

[0680] According to the method provided in the embodiments of this application, the embodiments of this application also provide a computer-readable storage medium storing a computer program or instructions, which can implement the method shown in the above-described method embodiments when the computer program or instructions are run on a processor.

[0681] According to the method provided in the embodiments of this application, the embodiments of this application also provide a computer program product, which includes a computer program or instructions. When the computer program or instructions are run on a processor, they can implement the method shown in the above-described method embodiments.

[0682] According to the method provided in the embodiments of this application, the embodiments of this application also provide a communication system, which includes at least one of the above-described communication devices 1300, 1400, or 1500.

[0683] It should be understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be a hard disk drive (HDD), a solid-state drive (SSD), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DRRAM). It should be noted that the memories described herein are intended to include, but are not limited to, these and any other suitable types of memory.

[0684] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this application are performed entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video optical disc; or it can be a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both types of storage media.

[0685] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments provided herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software 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 beyond the scope of this application.

[0686] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0687] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0688] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0689] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0690] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the technology, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0691] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A communication method characterized by comprising: The method comprises: obtaining flow requirements of a service flow; obtaining DIP instance information, wherein the DIP instance information comprises quality of service guarantee and / or residual resources of at least one DIP instance, and each DIP instance corresponds to a pre-configured DIP transport network subnet; determining whether the service flow is admitted into the DIP transport network according to the flow requirements of the service flow and the DIP instance information.

2. The method of claim 1, wherein, The quality of service guarantee and / or residual resources of the DIP instance are used to indicate an admission threshold of the DIP instance; The determining whether the service flow is admitted into the DIP transport network according to the flow requirements of the service flow and the DIP instance information comprises: if the at least one DIP instance comprises at least one optional DIP instance, determining that the service flow is admitted into the DIP transport network; or if the at least one DIP instance does not comprise the optional DIP instance, determining that the service flow is not admitted into the DIP transport network; The optional DIP instance meets the following condition: the flow requirements of the service flow meet the admission threshold of the optional DIP instance.

3. The method of claim 2, wherein, The flow requirements of the service flow comprise one or more of guaranteed bit rate, packet delay budget, maximum frame length or packet loss rate; The admission threshold comprises one or more of residual bandwidth resource, delay guarantee, maximum transmission unit allowed or packet loss rate guarantee; The flow requirements of the service flow meet the admission threshold of the optional DIP instance comprise one or more of: the bandwidth resource corresponding to the guaranteed bit rate is less than or equal to the residual bandwidth resource of the optional DIP instance; the delay requirement corresponding to the packet delay budget is greater than or equal to the delay guarantee of the optional DIP instance; the transmission unit corresponding to the maximum frame length is less than or equal to the maximum transmission unit allowed by the optional DIP instance; the packet loss rate corresponding to the packet loss rate is greater than or equal to the packet loss rate guarantee of the optional DIP instance.

4. The method according to any one of claims 1 to 3, characterized in that, The obtaining the flow requirements of the service flow comprises: a radio access network element, a user plane function network element or a DIP transport network controller receives the flow requirements of the service flow from a session management network element; or a DIP transport network edge node receives the flow requirements of the service flow from a radio access network element or a user plane function network element.

5. The method according to any one of claims 1 to 4, characterized in that, The obtaining the DIP instance information comprises: a radio access network element or a user plane function network element receives the DIP instance information from a DIP transport network edge node; or a session management network element receives the DIP instance information from a radio access network element, a user plane function network element or a DIP transport network controller; or a session management network element receives the DIP instance information from a unified data storage network element through a policy control network element; or a policy control network element receives the DIP instance information from a unified data storage network element.

6. The method according to claim 2 or 3, characterized in that, In a case where it is determined that the service flow is admitted into the DIP transport network, the method further comprises: sending, to a storage network element of the DIP instance information, information indicating a target DIP instance and the flow requirements of the service flow, wherein the target DIP instance is one of the at least one optional DIP instance, and the target DIP instance is the DIP instance to which the service flow is admitted.

7. The method of claim 6, wherein, The storage network element of the DIP instance information is a DIP transport network edge node; The sending, to the storage network element of the DIP instance information, of information indicating a target DIP instance and flow requirements of the service flow includes: The radio access network network element or the user plane function network element determines a target DIP instance and sends, to the DIP transport network edge node, information indicating the target DIP instance and flow requirements of the service flow; or The radio access network network element or the user plane function network element receives information indicating a target DIP instance from a session management network element and sends, to the DIP transport network edge node, the information indicating the target DIP instance and flow requirements of the service flow.

8. The method of claim 6, wherein, The storage network element of the DIP instance information is a radio access network network element, a user plane function network element, or a DIP transport network controller; The sending, to the storage network element of the DIP instance information, of information indicating a target DIP instance and flow requirements of the service flow includes: The session management network element determines a target DIP instance and sends, to the radio access network network element, the user plane function network element, or the DIP transport network controller, information indicating the target DIP instance and flow requirements of the service flow.

9. The method of claim 6, wherein, The storage network element of the DIP instance information is a unified data storage network element; The sending, to the storage network element of the DIP instance information, of information indicating a target DIP instance and flow requirements of the service flow includes: The session management network element determines a target DIP instance and sends, to the unified data storage network element, information indicating the target DIP instance and flow requirements of the service flow through a policy control network element; or The policy control network element receives information indicating a target DIP instance from a session management network element and sends, to the unified data storage network element, the information indicating the target DIP instance and flow requirements of the service flow.

10. The method of claim 2 or 3, wherein, In a case where it is determined that the service flow is admitted to a DIP transport network, the method further includes: Updating information of a target DIP instance based on flow requirements of the service flow, wherein the target DIP instance is one of the at least one optional DIP instance and is a DIP instance to which the service flow is admitted.

11. The method of claim 10, wherein, The storage network element of the DIP instance information is a radio access network network element or a user plane function network element; The updating, based on flow requirements of the service flow, of information of a target DIP instance includes: The radio access network network element or the user plane function network element determines a target DIP instance and updates information of the target DIP instance based on flow requirements of the service flow; or The radio access network network element or the user plane function network element receives information indicating a target DIP instance from a session management network element and updates information of the target DIP instance based on flow requirements of the service flow.

12. The method of claim 10, wherein, The storage network element of the DIP instance information is a DIP transport network edge node; The updating, based on flow requirements of the service flow, of information of a target DIP instance includes: The DIP transport network edge node receives information indicating a target DIP instance from a radio access network element or a user plane function network element, and updates information of the target DIP instance based on flow requirements of the service flow.

13. The method of claim 10, wherein, The storage network element of the DIP instance information is a DIP transport network controller; The updating of the information of the target DIP instance based on the flow requirements of the service flow comprises: The DIP transport network controller receives information indicating a target DIP instance from a session management network element, and updates information of the target DIP instance based on flow requirements of the service flow.

14. A communications device, characterized by Comprise: Units for performing the method as claimed in any one of claims 1 to 13.

15. A communications device, characterized by Comprise: Comprise a processor for executing a computer program or instructions, which when executed by the processor, cause the method as claimed in any one of claims 1 to 13 to be implemented.

16. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program or instructions, which when executed, cause the method as claimed in any one of claims 1 to 13 to be implemented.

17. A computer program product, characterised in that, Comprise a computer program or instructions, which when executed, cause the method as claimed in any one of claims 1 to 13 to be implemented.

Images