CN109429267B - Data transmission method, related device and system - Google Patents

Data transmission method, related device and system Download PDF

Info

Publication number
CN109429267B
CN109429267B CN201810152265.1A CN201810152265A CN109429267B CN 109429267 B CN109429267 B CN 109429267B CN 201810152265 A CN201810152265 A CN 201810152265A CN 109429267 B CN109429267 B CN 109429267B
Authority
CN
China
Prior art keywords
network device
data flow
split bearer
message
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201810152265.1A
Other languages
Chinese (zh)
Other versions
CN109429267A (en
Inventor
李小仙
方平
程勇
庞高昆
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to PCT/CN2018/101848 priority Critical patent/WO2019042205A1/en
Publication of CN109429267A publication Critical patent/CN109429267A/en
Application granted granted Critical
Publication of CN109429267B publication Critical patent/CN109429267B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0268Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H04W28/065Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information using assembly or disassembly of packets

Landscapes

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

Abstract

The application discloses a data transmission method, which can comprise the following steps: the method comprises the steps that first network equipment receives a first message sent by second network equipment, wherein the first message is used for indicating that a first data flow and/or a data transmission channel of the first data flow between terminal equipment and a core network are configured to a first segmentation bearer, QoS (quality of service) capability of the first segmentation bearer and QoS requirements of the first data flow and/or the data transmission channel of the first data flow; the first network device determines to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer according to the QoS capability of the first network device, the QoS capability of the second network device and the QoS requirement of the first data flow and/or the data transmission channel of the first data flow, and indicates the QoS which the second network device needs to bear to the second network device. The scheme can realize that the QoS requirement of the data flow is considered when the data flow or the data transmission channel is configured to the SCG split bearer.

Description

Data transmission method, related device and system
Technical Field
The present application relates to the field of wireless communication technologies, and in particular, to a data transmission method, a related apparatus and a system.
Background
The5th Generation (5G) mobile communication technology is an extension of the 4 th Generation (4G) mobile communication technology. Therefore, the 5G communication system is called a "super 4G network" or a "Long Term Evolution (LTE) system" or a New Radio (NR).
An existing evolved universal terrestrial radio access network (E-UTRAN) standard supports Dual Connectivity (DC), that is, a User Equipment (UE) configured with multiple Rx/Tx may utilize radio resources scheduled by 2 enbs (evolved node bs) when in an RRC _ CONNECTED state. The 2 enbs (evolved nodes b) are connected to each other via a non-ideal backhaul (non-ideal backhaul) on the X2 interface, where one eNB acts as a master eNB (MeNB) and one as a slave eNB (SeNB).
The LTE standard 3GPP TS 36.300V14.2.0 defines the air interface protocol architecture for DC. As shown in fig. 1, one bearer (bearer) in the DC scenario can be established as 3 different bearer types: a master cell group bearer (MCG bearer), a secondary cell group bearer (SCG bearer), and a split bearer (split bearer).
Wherein the MCG bearer is a bearer whose radio protocol is located only in the MeNB to use only MeNB resources in dual connectivity. The SCG bearer is a bearer whose radio protocol is located only in the SeNB to use only SeNB resources in dual connectivity. Split bearers are bearers whose radio protocols are located in both MeNB and SeNB to use MeNB resources and SeNB resources in dual connectivity.
In NR, multiple radio access technology Dual Connectivity (MR-DC) defines different multiple Connectivity types, such as E-UTRA-NR Dual Connectivity (E-UTRA-NR Dual Connectivity, EN-DC), NGEN-DC Dual Connectivity (NG-RAN E-UTRA-NR Dual Connectivity, NGEN-DC), NE Dual Connectivity (NR-E-UTRA Dual Connectivity, NE-DC), and defines 4 bearer types: MCG bearer, SCG bearer, MCG split bearer and SCG split bearer. Fig. 2A shows the radio protocol architecture for 4 types of bearers in an EN-DC scenario. Fig. 2B shows the radio protocol architecture of 4 types of bearers in the NGEN-DC scenario and the NE-DC scenario.
Disclosure of Invention
The application provides a data transmission method, a related device and a system, which can realize that the QoS (quality of service) requirement of a data stream is considered when the data stream or a data transmission channel is configured to a bearer.
In a first aspect, the present application provides a data transmission method, which is applied to a first network device side, and the method may include: the first network device receives a first message sent by the second network device, wherein the first message is used for indicating that the first data flow and/or the data transmission channel of the first data flow between the terminal device and the core network is configured to the first split bearer, so as to indicate the QoS capability of the second network device available for the first split bearer, and the QoS requirement of the first data flow and/or the data transmission channel of the first data flow. The first network device may then determine the QoS that the second network device needs to assume based on the QoS capabilities of the first network device, the QoS capabilities of the second network device, and the QoS requirements of the first data flow and/or the data transmission channel of the first data flow. Finally, the first network device may send a second message to the second network device, where the second message may be used to confirm that the first data flow and/or the data transmission channel of the first data flow is configured to the first split bearer, and to indicate the QoS that the second network device needs to assume.
In a second aspect, the present application provides a data transmission method, which is applied to a second network device side, and the method may include: the second network device determines to configure the first data flow between the terminal device and the core network and/or a data transmission channel of the first data flow to the first split bearer. The second network device may then send a first message to the first network device, where the first message is used to indicate that the first data flow and/or the data transmission channel of the first data flow between the terminal device and the core network is configured to the first split bearer, so as to indicate the QoS capability of the second network device that may be used for the first split bearer, the QoS requirement of the first data flow and/or the data transmission channel of the first data flow. Accordingly, the second network device may receive a second message sent by the first network device, where the second message is used to confirm that the first data flow and/or the data transmission channel of the first data flow is configured to the first split bearer, and is used to indicate the QoS that the second network device needs to assume.
In this application, the QoS capability of the first network device (or the second network device) may include one or more of an Aggregated Maximum Bit Rate (AMBR), a Maximum Bit Rate (MBR), a Guaranteed Bit Rate (GBR), an Allocation And Retention Priority (ARP), a packet forwarding policy, a Priority policy, a notification policy, And other indicators that the first network device (or the second network device) can support. For specific definitions of various parameters, reference may be made to the 3GPP TS 23.401 standard and the 3GPP TS23.501 standard, which are not described herein in detail.
In the present application, the QoS requirement of the data flow or the data transmission channel may include at least one of the following QoS parameters: QoS Class Identifier (QCI), Allocation and Retention Priority (ARP), Guaranteed Bit Rate (GBR), Maximum Bit Rate (MBR), 5G quality of service Indicator (5G QoS Indicator, 5QI), Guaranteed Flow Bit Rate (GFBR), Maximum Flow Bit Rate (MBR), notification control (notification control), and the like. For specific definitions of various parameters, reference may be made to the 3GPP TS 23.401 standard and the 3GPP TS23.501 standard, which are not described herein in detail.
In this application, the first data stream may be one or more data streams. When the first data flow is a plurality of data flows, the first network device may configure the first data flow and/or a data transmission channel of the first data flow into one or more first split bearers. Optionally, the first network device may configure a plurality of data streams in the data transmission channel of the first data stream onto a plurality of first split bearers. For example, in an MR-DC with NGC scenario, multiple QoS flows in a PDU Session can be configured onto different SCG split bearer. The examples are merely illustrative of the present application and should not be construed as limiting.
By implementing the methods described in the first aspect and the second aspect, QoS requirements of data streams can be considered when configuring the data streams or the data transmission channels to the SCG split bearer, and it can be ensured that QoS that the main network node needs to bear does not exceed QoS capability of the main network node, thereby improving success rate of configuring the data streams or the data transmission channels to the SCG split bearer.
With reference to the first aspect or the second aspect, in some optional embodiments, the first data flow may be one or more of Service Data Flow (SDF), service data flow aggregation (SDF Aggregate), data flow (data flow), QoS flow (QoS flow), packet flow (packet flow), and the like. The data transmission path of the first data stream may be an evolved packet system bearer (EPS bearer), an evolved radio access bearer (E-RAB), a protocol data unit session (PDU session), or the like.
With reference to the first aspect or the second aspect, in some optional embodiments, the specific implementation of the second network device (as the master network node) determining to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer may include the following manners:
(1) first, if the data plane interface of the first data flow and/or the data transmission channel of the first data flow is connected to the second network device and the QoS capability of the second network device available for the first split bearer cannot meet the QoS requirement of the first data flow and/or the data transmission channel of the first data flow, the second network device determines to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer.
For example, the second network device (as the master network node) may determine its own QoS capabilities available for the first split bearer based on the load conditions or link conditions of its own bearer. If the QoS capability available to the second network device (as the master network node) for the first split bearer fails to meet the QoS requirements of the first data flow and/or the data transmission channel of the first data flow, it is determined to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer.
It should be understood that the PDCP layer of the first split bearer is located in the first network device (as a secondary network node), i.e. the first network device is responsible for more data processing in the data transmission process. Therefore, configuring the first data stream and/or the data transmission channel of the first data stream to the first split bearer may greatly reduce the burden of the second network device (as the primary network node). Therefore, reasonable configuration of data service among different network nodes can be realized, and influence on network transmission efficiency caused by overload of a main network node is avoided.
In this application, the QoS capabilities of the second network device available for the first split bearer may be all or part of the available QoS capabilities of the second network device. In some possible scenarios, the second network device needs to reserve part of the available QoS capabilities for transmitting some emergency or special traffic, in which case the QoS capabilities of the second network device available for the first split bearer are the available QoS capabilities of the part of the second network device.
(2) In a second manner, if the data plane interface of the first data stream and/or the data transmission channel of the first data stream is connected to the first network device, the second network device determines to configure the first data stream and/or the data transmission channel of the first data stream to the first split bearer.
For example, in an EN-DC scenario, it is assumed that an eNB (as a primary network node) learns, through a Mobility Management Entity (MME), that a certain E-RAB is established between a terminal device, a gNB (as a secondary network node) and an S-GW (serving gateway in a core network), i.e., that a data plane interface of the E-RAB is connected to the gNB (as a secondary network node). Then the eNB (as the primary network node) may determine to configure the E-RAB onto the SCG split bearer. In this way, the primary data processing work of the E-RAB is performed on the gNB (as a secondary network node), and data is prevented from being processed by switching to the eNB (as a primary network node), so that the efficiency of data transmission can be improved.
Not limited to the above-mentioned two implementations, in practical applications, the second network device (as the master network node) may also determine to configure the first data stream and/or the data transmission channel of the first data stream to the first split bearer according to other conditions. For example, the second network device (as the master network node) may determine whether to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer according to a traffic allocation policy set by the core network. The present application does not limit the condition under which the second network device (as the master network node) determines to configure the first data stream and/or the data transmission channel of the first data stream to the first split bearer.
With reference to the first aspect or the second aspect, in some optional embodiments, a specific implementation of the first message may be as follows:
(1) the first message may be used to instruct the first network device to configure the first data flow and/or a data transmission channel of the first data flow to the first split bearer
In particular, the first message may carry an indication information, which may be used to instruct the first network device (as a secondary network node) to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer.
Alternatively, the indication information may be embodied by a field or information related to the first split bearer (e.g., SCG split bearer).
For example, in an EN-DC scenario, the first message may carry a field for the name "E-RABs-ToBeAdded-Item-SCG-Split-Bearer". The name of this field is related to the SCG split bearer, which may be used to instruct the secondary network node to configure the first data stream and/or the data transmission channel of the first data stream to the SCG split bearer.
For another example, in an MR-DC with NGC scenario, the first message may carry a field of a name "PDU sessions-tobeaded-Item-SCG Split-Bearer", where the PDU in this application is an english abbreviation of a protocol data unit (protocol data unit). The name of this field is related to the SCG split bearer, which may be used to instruct the secondary network node to configure the first data stream and/or the data transmission channel of the first data stream to the SCG split bearer.
The examples are merely illustrative of the present application and should not be construed as limiting. In practical applications, other named fields or indication modes can be used for indication, and the application is not limited.
Optionally, the first message may also implicitly instruct the first network device to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer. For example, if the first message includes indication information of QoS capabilities of the second network device available for the first split bearer, the first network device may know an indication of the second network device (indicating that the first data flow and/or a data transmission channel of the first data flow is configured to the first split bearer). The examples are merely illustrative of the present application and should not be construed as limiting.
(2) The first message may be used to indicate QoS requirements of the first data flow and/or a data transmission channel of the first data flow
The first message may carry characteristic information of the first data flow and/or the data transmission channel of the first data flow, and the characteristic information may include an identifier and a QoS parameter of the first data flow and/or the data transmission channel of the first data flow. For the identification of the first data stream and/or the data transmission channel of the first data stream, and the definition and description of the QoS parameter, reference may be made to relevant contents in S101, and details are not repeated here.
(3) The first message may be used to indicate QoS requirements of the first data flow and/or a data transmission channel of the first data flow
The first message may carry an indication of QoS capabilities available to the second network device (as the primary network node) for the first split bearer. The QoS capability available to the second network device (as the primary network node) for the first split bearer may be represented by at least one parameter selected from the group consisting of: AMBR values, MBR values, GBR bit rates, ARP, packet forwarding policy, priority policy, notification policy, etc. The indication information may typically be a QCI.
Further, the first message may also carry other information.
(1) The first message may further carry key information, where the key information may include a root key, and the root key may be used to generate a key for data encryption and/or integrity protection, so that security of the first data stream and/or a data transmission channel of the first data stream may be guaranteed.
In an alternative implementation, the root key may be generated by the second network device. For example, the root key may be generated by the second network device according to KeNB or KAN, such as a root key KDF (KeNB/KAN, other input information), where KDF is a key generation algorithm, and the other input information may include a Count value Count, and the Count value Count may be used to maintain the freshness of the root key during key update. In another alternative implementation, the root key may be sent to the second network device by a key management unit in the core network.
(2) The first message may also carry security capability information of the terminal device. Specifically, the security capability information of the terminal device may include algorithm information of data encryption and/or integrity protection that the terminal device may support.
(3) The first message may also carry address information used by the second network device for the first split bearer, for example, an address on an X2 or Xn interface, such as X2DL TNL address information or Xn DL TNL address information.
Optionally, the first message may be an SgNB Addition Request (or SgNB Modification Request) extended in an EN-DC scenario, and a field of the name of "E-RABs-tobeaded-Item-SCG-Split-Bearer" mentioned above and a field indicating QoS capability available to the second network device (as the master network node) for the first Split Bearer are added to the signaling. The first message may be an extended SN Addition Request/SN Modification Request in an MR-DC with NGC scenario, where a field of the above-mentioned "PDU sessions-to-obeadd-Item-SCG Split-Bearer" name is added to the signaling, and a field indicating QoS capability available to the second network device (as the master network node) for the first Split Bearer.
Without being limited thereto, the first message may also be other extended signaling, and may also be a newly defined message, which is not limited in this application.
In combination with the first or second aspect, in some optional embodiments, the QoS that the second network device needs to undertake may be represented by at least one of the following parameters: AMBR values, MBR values, GBR bit rates, ARP, packet forwarding policy, priority policy, notification policy, etc.
With reference to the first aspect or the second aspect, in some optional embodiments, the QoS that the second network device needs to assume may also take the following forms:
first, the QoS that the second network device needs to undertake may be a share of one or more QoS parameters (e.g., MBR value, AMBR value, GBR bit rate) of the second network device that may be used to support the first split bearer, the QoS parameters (e.g., MBR value, AMBR value, GBR bit rate) representing the data transmission rate in the first data stream and/or the data transmission channel of the first data stream.
For example, assume that the first data stream and/or the data transmission channel of the first data stream requires a GBR of 10Gbps and the GBR of the second network device that is available to support the first split bearer is 1 Gbps. Then the QoS that the second network device needs to assume is 10% of the GBR required for the first data flow and/or the data transmission channel of the first data flow. The examples are merely illustrative of the present application and should not be construed as limiting.
Second, the QoS that the second network device needs to assume may be a maximum QoS capability value of one or more QoS parameters (e.g., MBR value, AMBR value, GBR bit rate, packet error loss rate, ARP capability, etc.) of the second network device that may be used to support the first split bearer.
For example, assuming that the maximum MBR value of the second network device available to support the first split bearer is 100Gbps, the minimum packet error loss rate is 0.5%. Then, the QoS that the second network device needs to assume is: MBR is 100Gbps, and packet error loss rate is 0.5%. The examples are merely illustrative of the present application and should not be construed as limiting.
With reference to the first aspect or the second aspect, in some optional embodiments, the specific implementation of the second message may be as follows:
(1) the second message may be used to instruct the first network device to confirm the configuration of the first data flow and/or the data transmission channel of the first data flow to the first split bearer
Optionally, the second message may carry an indication information, where the indication information may be used to indicate that the first network device confirms to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer.
Alternatively, the indication information may be a field or information related to the first split bearer (e.g., SCG split bearer).
For example, in an EN-DC scenario, the second message may carry a field for the name "E-RABs-Admitted-ToBeBeAdded-Item-Split-Bearer". The name of this field is related to the SCG split bearer, and may be used to instruct the secondary network node to confirm that the first data stream and/or the data transmission channel of the first data stream is configured to the SCG split bearer.
For another example, in an MR-DC with NGC scenario, the second message may carry a field for the name "PDU sessions-Admitted-ToBe-Admitted-Item-SCG Split-Bearer". The name of this field is related to the SCG split bearer, and may be used to instruct the secondary network node to confirm that the first data stream and/or the data transmission channel of the first data stream is configured to the SCG split bearer.
The examples are merely illustrative of the present application and should not be construed as limiting. In practical applications, other named fields or indication modes can be used for indication, and the application is not limited.
Optionally, the second message may also implicitly indicate that the first network device confirms to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer. For example, if the second message includes information indicating the QoS that the second network device needs to assume, the second network device may determine that the first network device confirms the configuration of the first data flow and/or the data transmission channel of the first data flow to the first split bearer. The examples are merely illustrative of the present application and should not be construed as limiting.
(2) The second message may be for a QoS that the second network device needs to assume
Optionally, the second message carries an indication information, where the indication information explicitly indicates the QoS that the second network device needs to bear.
Optionally, the QoS that the second network device needs to assume is implicitly indicated in the second message. For example, the second message includes QoS class information assumed by the first network device, and then the second network device may determine to obtain the QoS class information that the second network device needs to assume according to the QoS class information assumed by the first network device and the QoS requirement of the first data flow and/or the data transmission channel of the first data flow.
In addition, the second message may also carry configuration information of the first split bearer. Wherein: the configuration information of the first split bearer may comprise at least an identification of the first split bearer. If the first split bearer is not established, the configuration information of the first split bearer may further include configuration information of each layer protocol stack of the first split bearer, such as PDCP layer configuration information, RLC layer configuration information, and MAC layer configuration information. For specific content of configuration information of each layer protocol stack, reference may be made to 3GPP TS 36.331 standard, which is not described herein in detail.
Further, the second message may also carry: the first network device determines algorithm information to be applied to data encryption and/or integrity protection of the first split bearer.
Further, the second message may also carry: the address information of the first network device for the first split bearer, such as an address on an X2 or Xn interface (e.g., X2UL TNL address information or Xn UL TNL address information or X2DL TNL address information or Xn DL TNL address information), an address on an S1 interface (e.g., S1DL TNL address information or S1UL TNL address information), or an address on an NG-U interface (e.g., NG-U DL TNL address information or NG-U UL TNL address information).
Optionally, the second message may be an extended SgNB Addition Request ACK (or SgNB Modification Request ACK) in the EN-DC scenario, and the above-mentioned "E-RABs-Admitted-tobebaded-Item-Split-
A bear "name, and a field indicating the QoS that the second network device (as the primary network node) needs to assume. The second message may be an SN Addition Request acknowledgement (or SN Modification Request acknowledgement) extended in the MR-DC with NGC scenario, where a field of the above-mentioned "PDU sessions-accepted-to be Added-Item-SCG Split-Bearer" name and a field indicating the QoS that the second network device (as the master network node) needs to bear are Added to the signaling.
Without being limited thereto, the second message may also be other extended signaling, and may also be a newly defined message, which is not limited in this application.
In combination with the first or second aspect, in some optional embodiments, the second network device may further instruct the terminal device to configure the first split bearer. The method specifically comprises the following steps:
1. the second network device (as the master network node) sends a configuration message of the first split bearer to the terminal device. The configuration message may be used for the terminal device to configure the first split bearer.
2. Correspondingly, the terminal device receives the configuration message of the first segmentation bearer sent by the second network device. After that, the terminal device may configure the first split bearer according to the configuration message of the first split bearer, and send a configuration confirmation message to the second network device. The configuration confirm message may be used to indicate that the terminal device has completed configuring the first split bearer.
3. Correspondingly, the second network device receives the configuration confirmation message sent by the terminal device. Thereafter, the second network device may send a third message to the first network device, where the third message may be used to indicate that the terminal device has completed configuring the first split bearer.
Optionally, the configuration message may be an RRC connection reconfiguration message. Optionally, the configuration confirmation message may be an RRC connection reconfiguration response message.
In combination with the first or second aspect, in some optional embodiments, if the user plane interface of the first data stream and/or the data transmission channel of said first data stream is connected to a second network device, the second network device (as the primary network node) may send a status transfer message, such as a serial number status transfer (SN status transfer) message, to the first network device (as the secondary network node). Then, the terminal device, the first network device, the second network device and the core network execute a path switching process.
In a third aspect, a network device is provided, where the network device is a first network device and may include a plurality of functional units, configured to perform the method provided in the first aspect or any one of the possible implementations of the first aspect.
In a fourth aspect, a network device is provided, which is a second network device and may include a plurality of functional units for performing the method provided by the second aspect or any one of the possible implementations of the second aspect.
In a fifth aspect, a network device is provided, where the network device is a first network device and is configured to perform the data transmission method described in the first aspect. The network device may include: a memory and a processor, a transmitter, and a receiver coupled with the memory, wherein: the transmitter is configured to transmit a signal to another wireless communication device, the receiver is configured to receive a signal transmitted by the another wireless communication device, the memory is configured to store implementation codes of the data transmission method described in the first aspect, and the processor is configured to execute the program codes stored in the memory, that is, to execute the data transmission method described in the first aspect or any one of the possible implementations of the first aspect.
In a sixth aspect, a network device is provided, where the network device is a second network device, and is configured to execute the data transmission method described in the second aspect. The network device may include: a memory and a processor, a transmitter, and a receiver coupled with the memory, wherein: the transmitter is configured to transmit a signal to another wireless communication device, the receiver is configured to receive a signal transmitted by the another wireless communication device, the memory is configured to store implementation codes of the data transmission method described in the second aspect, and the processor is configured to execute the program codes stored in the memory, that is, execute the data transmission method described in any one of the possible implementations of the second aspect or the second aspect.
In a seventh aspect, a communication system is provided, which includes: a first network device and a second network device, wherein: the first network device may be the network device described in the third or fifth aspect. The second network device may be the network device described in the fourth or sixth aspect.
In an eighth aspect, there is provided a computer-readable storage medium having stored thereon instructions which, when run on a computer, cause the computer to perform the data transmission method described in the above first aspect.
In a ninth aspect, there is provided another computer-readable storage medium having stored thereon instructions which, when run on a computer, cause the computer to perform the data transmission method described in the second aspect above.
In connection with the tenth aspect, there is provided a computer program product containing instructions which, when run on a computer, cause the computer to perform the data transmission method described in the first aspect above.
With reference to the eleventh aspect, there is provided another computer program product containing instructions which, when run on a computer, cause the computer to perform the data transmission method described in the second aspect above.
The application relates to the abbreviations listed in the following table:
Figure BDA0001580184630000071
Figure BDA0001580184630000081
Figure BDA0001580184630000091
Figure BDA0001580184630000101
TABLE 1
Drawings
In order to more clearly illustrate the technical solutions in the embodiments or the background art of the present application, the drawings required to be used in the embodiments or the background art of the present application will be described below.
Fig. 1 shows 3 bearer types in a DC scenario in the LTE standard to which the present application relates;
fig. 2A shows a radio protocol architecture for 4 types of bearers in an EN-DC scenario to which the present application relates;
FIG. 2B illustrates radio protocol architectures for 4 types of bearers in an NGEN-DC scenario and an NE-DC scenario to which the present application relates;
fig. 3 illustrates a system architecture of a wireless communication system to which the present application relates;
FIG. 4A illustrates an EN-DC architecture to which the present application relates;
FIG. 4B illustrates the wireless protocol architecture of SCG split bearer in the EN-DC scenario to which the present application relates;
FIG. 4C illustrates a wireless protocol architecture of the MCG split bearer in the EN-DC scenario to which the present application relates;
FIG. 5A illustrates the NGEN-DC architecture to which the present application relates;
FIG. 5B illustrates the wireless protocol architecture of SCG split bearer in the NGEN-DC scenario to which the present application relates;
fig. 6 shows various bearer implementations of data flows or data transmission channels between a core network and a terminal device;
FIG. 7 illustrates a hardware architecture of a network device provided herein;
fig. 8 shows an overall flow of the data transmission method provided by the present application;
fig. 9A shows a case where a data flow or a data transmission channel between a core network and a terminal device is configured to the SCG split bearer;
fig. 9B shows another case where a data flow or a data transmission channel between a core network and a terminal device is configured to the SCG split bearer;
FIG. 10 shows a specific flow of the data transmission method provided by the present application applied to an EN-DC scenario;
FIG. 11 shows a specific flow of the data transmission method provided by the present application applied to an MR-DC with NGC scenario;
FIG. 12A is a diagram illustrating an example of the signaling format of the SN Addition Request/SN Modification Request provided herein;
FIG. 12B is a diagram illustrating an example of the signaling format of the SN Addition Request acknowledgement/SN Modification Request acknowledgement provided herein;
fig. 13 shows a functional structure of a wireless communication system and a network device provided in the present application.
Detailed Description
The terminology used in the description of the embodiments section of the present application is for the purpose of describing particular embodiments of the present application only and is not intended to be limiting of the present application.
Fig. 3 shows a wireless communication system to which the present application relates. The wireless communication system may operate in a high frequency band, and is not limited to a Long Term Evolution (LTE) system, but may also be a fifth Generation mobile communication (the5th Generation, 5G) system, a new air interface (NR) system, a Machine to Machine (M2M) system, and the like. As shown in fig. 3, the wireless communication system 100 may include: a Master network Node (MN) 101, a Secondary network Node (SN) 103, one or more terminal devices 107, and a core network 105. Wherein the terminal device 107 establishes a connection with the primary network node 101 and the secondary network node 103, respectively.
The primary network node 101 and the secondary network node 103 are network devices. Specifically, the primary network Node 101 (or the secondary network Node 103) may be a Base Transceiver Station (BTS) in a Time Division Synchronous Code Division Multiple Access (TD-SCDMA) system, or may be an evolved Node B (eNB) in an LTE system, or a gbb in a 5G system or a new air interface (NR) system. In addition, the primary network node 101 (or the secondary network node 103) may also be an Access Point (AP), a transmission node (Trans TRP), a Central Unit (CU) or other network entities, and may include some or all of the functions of the above network entities.
The terminal devices 107 may be distributed throughout the wireless communication system 100 and may be stationary or mobile. In some embodiments of the present application, the terminal device 107 may be a mobile device, a mobile station (mobile station), a mobile unit (mobile unit), an M2M terminal, a wireless unit, a remote unit, a user agent, a mobile client, and the like.
(1) Communication interface between a network node and a core network
The primary network node 101 may transmit control information or user data to the core network 105 via a backhaul (blackhaul) interface 111 (e.g., S1 interface), and the secondary network node 103 may transmit user data to the core network 105 via a backhaul (blackhaul) interface 112 (e.g., S1 interface).
(2) Communication interface between a primary network node and a secondary network node
The primary network node 101 and the secondary network node 103 may communicate with each other directly or indirectly through a Non-ideal (Non-ideal) backhaul (blackhaul) interface 113.
(3) Communication interface between a primary network node and a secondary network node
The primary network node 101 interacts with the terminal device 107 via a wireless interface 114 and the secondary network node 103 interacts with the terminal device 107 via a wireless interface 115. Specifically, the interfaces 114 and 115 may be Uu interfaces.
The communication interface in the wireless communication system 100 is described in detail below by taking an EN-DC scenario and an NGEN-DC scenario as examples.
FIG. 4A shows the architecture of EN-DC. The wireless protocol architecture of SCG split bearer in the EN-DC scenario can be as shown in FIG. 4B.
As shown in fig. 4A, in an EN-DC scenario, the primary network node 101 may be an eNB in an LTE communication system, the secondary network node 103 may be a gNB in a 5G or NR communication system, and the core network 105 may be an EPC (network element including a Mobility Management Entity (MME), a serving Gateway (S-GW), and the like), where the eNB is connected with the MME through an S1-C interface. The backhaul interface 111 between the master network node 101 and the core network 105 may comprise a control plane interface S1-C and a data plane interface S1-U. The backhaul interface 112 between the secondary network node 103 and the core network 105 may be a data plane interface S1-U. The non-ideal backhaul interface 113 between the primary network node 101 and the secondary network node 103 may be an X2 interface (in the existing standard, the X2 interface refers to the interface between eNB and eNB/gNB).
FIG. 5A illustrates the architecture of NGEN-DC. The wireless protocol architecture of SCG split bearer in the NGEN-DC scenario can be as shown in FIG. 5B.
As shown in fig. 5A, in an NGEN-DC scenario, the primary network node 101 may be an eNB in an LTE communication system, the secondary network node 103 may be a gbb in a 5G or NR communication system, and the core network 105 may be an NGC (including network elements such as AMF, UPF, and SMF), where the eNB is connected to the AMF through an NG-C interface. The backhaul interface 111 between the main network node 101 and the core network 105 may comprise a control plane interface NG-C and a data plane interface NG-U. The backhaul interface 112 between the secondary network node 103 and the core network 105 may be a data plane interface NG-U. The non-ideal backhaul interface 113 between the primary network node 101 and the secondary network node 103 may be an Xn interface (in the existing standard, an Xn interface refers to an interface between a gNB and an eNB/gNB).
In the present application, the data flow or data transmission channel between the core network 105 and the terminal device 107 is based on the logical concept of bearer. Bearers are also logical concepts, referring to logical paths between the core network 105 and the terminal devices 107.
In a Dual Connectivity (DC) scenario, there may be multiple bearer implementations for data flow or data transmission channels between the core network 105 and the terminal device 107. As shown in fig. 6:
the implementation method comprises the following steps of 1: S1-Uu (air bearing MCG bearer)
And implementation 2: S1-Xn-Uu' and S1-Uu (air interface bearing MCG split bearer)
And (3) realization: s1 '-Uu' (SCG bearer is adopted for air interface bearing)
And (4) realization: s1 '-Xn' -Uu and S1 '-Uu' (air bearing SCG split bearer)
The various bearer implementations described above all include S1 bearers and radio bearers (radio bearers). The air interface bearer in implementation 2 adopts MCG split bearer, where the MCG split bearer includes 2 logic paths, a shunting anchor point of the two logic paths is the main network node 101, one logic path is transmitted to the terminal device 107 through the main network node 101, and the other logic path is transmitted to the terminal device 107 through the auxiliary network node 103. The air interface bearer in implementation 4 adopts SCG split bearer, where the SCG split bearer includes 2 logic paths, a shunting anchor point of the two logic paths is the auxiliary network node 103, one logic path is transmitted to the terminal device 107 through the auxiliary network node 103, and the other logic path is transmitted to the terminal device 107 through the main network node 101.
In the present application, the data offloading anchor point is a network device where a PDCP layer for splitting bearers is located. As shown in fig. 4B, the PDCP layer of the SCG split bearer is located in the gNB (secondary network node), i.e. the data splitting anchor point of the SCG split bearer is the gNB (secondary network node). As shown in fig. 4C, the PDCP layer of the MCG split bearer is at the eNB (master network node), i.e. the data offloading anchor point of the MCG split bearer is the eNB (master network node).
In the prior art, for a data stream or a data transmission channel between the core network 105 and the terminal device 107, the master network node 101 may configure the data stream or the data transmission channel to the MCG split bearer. The specific mode can include: the primary network node 101 directly indicates to the secondary network node 103 the QoS that the secondary network node 103 needs to assume. If the QoS capabilities of the secondary network node 103 are able to meet the QoS that the secondary network node 103 needs to assume, then confirmation is made to the primary network node 101. If the QoS capability of the secondary network node 103 is not able to meet the QoS that the secondary network node 103 needs to assume, then feedback to the primary network node 101 that it is not able to assume is made and the primary network node 101 may then configure the data flow or data transmission channel on another type of bearer.
However, when the data stream or the data transmission channel is considered to be arranged in the SCG split bearer, it is not suitable to adopt the conventional method of arranging the data stream or the data transmission channel in the MCG split bearer. Because: the primary network node 101 needs to instruct the secondary network node 103 to configure a data flow or data transmission channel to the SCG split bearer. It is assumed that the secondary network node 103 directly indicates the QoS that the primary network node 101 needs to assume, i.e. like in the prior art. If the QoS capability of the primary network node 101 cannot meet the QoS that the primary network node 101 needs to assume, it may cause the data stream or the data transmission channel to fail to be configured to the SCG split bearer, and after the failure, the primary network node 101 needs to indicate the secondary network node 103 again. This increases the signalling overhead between the primary network node 101 and the secondary network node 103. Therefore, when configuring the data stream or the data transmission channel to the SCG split bearer, the problem of signaling overhead increase can be effectively avoided by ensuring successful configuration as much as possible.
The technical scheme provided by the application can realize that the QoS requirement of the data flow is considered when the data flow or the data transmission channel is configured to the SCG split bearer, and the success rate of configuring the data flow or the data transmission channel to the SCG split bearer can be ensured as much as possible. The specific scheme will be described in detail in the following, which is not repeated herein.
It should be noted that the wireless communication system 100 shown in fig. 3 is only for more clearly illustrating the technical solution of the present application, and does not constitute a limitation to the present application, and as a person having ordinary skill in the art knows, the technical solution provided in the present application is also applicable to similar technical problems as the network architecture evolves and new service scenarios emerge.
Referring to fig. 7, fig. 7 illustrates a network device 200 provided by some embodiments of the present application. As shown in fig. 7, the network device 200 may include: one or more network device processors 201, memory 202, communication interface 203, transmitter 205, receiver 206, coupler 207, and antenna 208. These components may be connected by a bus 204, or otherwise, as illustrated in FIG. 7 by a bus. Wherein:
the communication interface 203 may be used for the network device 200 to communicate with other communication devices, such as terminal devices or other network devices. Specifically, the communication interface 203 may be a Long Term Evolution (LTE) (4G) communication interface, or may be a communication interface of a 5G or future new air interface. The wireless communication interface may include an S1 interface (or NG interface), a Uu interface, and the like. Without being limited to a wireless communication interface, the network appliance 200 may also be configured with a wired communication interface 203 to support wired communication, e.g., a backhaul link between one network appliance 200 and other network appliances 200 may be a wired communication connection.
The transmitter 205 may be configured to perform transmit processing, such as signal modulation, on the signal output by the network device processor 201. Receiver 206 may be used for receive processing of mobile communication signals received by antenna 208. Such as signal demodulation. In some embodiments of the present application, the transmitter 205 and the receiver 206 may be considered as one wireless modem. In the network device 200, the number of the transmitters 205 and the receivers 206 may be one or more. The antenna 208 may be used to convert electromagnetic energy in the transmission line to electromagnetic energy in free space, or vice versa. The coupler 207 may be used to multiplex the mobile communications signal for distribution to a plurality of receivers 206.
The memory 202 is coupled to the network device processor 201 for storing various software programs and/or sets of instructions. In particular, the memory 202 may include high speed random access memory, and may also include non-volatile memory, such as one or more magnetic disk storage devices, flash memory devices, or other non-volatile solid state storage devices. The memory 202 may store an operating system (hereinafter, referred to as a system), such as an embedded operating system like upos, VxWorks, RTLinux, etc. The memory 202 may also store a network communication program that may be used to communicate with one or more additional devices, one or more terminal devices, one or more network devices.
The network device processor 201 may be used to perform radio channel management, implement call and communication link setup and teardown, provide cell switching control for users within the control area, and the like. Specifically, the network device processor 201 may include: an Administration/Communication Module (AM/CM) (a center for voice channel switching and information switching), a Basic Module (BM) (for performing call processing, signaling processing, radio resource management, management of radio links, and circuit maintenance functions), a code conversion and sub-multiplexing unit (TCSM) (for performing multiplexing/demultiplexing and code conversion functions), and so on.
Herein, the network device processor 201 may be configured to read and execute computer readable instructions. Specifically, the network device processor 201 may be configured to call a program stored in the memory 202, for example, an implementation program of the data transmission method provided in one or more embodiments of the present application on the network device 200 side, and execute instructions contained in the program.
It is to be understood that the network device 200 may be the primary network node 101 in the wireless communication system 100 shown in fig. 3, or may be the secondary network node 103 in the wireless communication system 100 shown in fig. 3. The network device 200 may be implemented as any one of or some combination of a gNB, a New radio base station (New radio eNB), a transmission point (TRP), a macro base station, a micro base station, a high frequency base station, an LTE macro or micro eNB, a Customer Premises Equipment (CPE), an access point AP), a WLAN GO, and the like. For example, the primary network node 101 (or the secondary network node 103) may be a gNB, which performs the functions referred to by the primary network node 101 (or the secondary network node 103) in the present application. For another example, the primary network node 101 (or the secondary network node 103) may be a combination of a gNB and a TRP, the gNB may perform a resource allocation function of the primary network node 101 (or the secondary network node 103), and the TRP may perform a transceiving function of the primary network node 101 (or the secondary network node 103). The examples are merely some implementations provided in the present application, and may be different in practical applications, and should not be construed as limiting.
It should be noted that the network device 200 shown in fig. 7 is only one implementation manner provided in the present application, and in practical applications, the network device 200 may further include more or less components, which is not limited herein.
Based on the foregoing embodiments corresponding to the wireless communication system 100 and the network device 200, respectively, the present application provides a data transmission method.
The main inventive principles of the present application may include: and when determining that the data stream or the data transmission channel is configured in the SCG split bearer, the main network node indicates the QoS capability of the main network node to the auxiliary network node. And the auxiliary network node determines the QoS required to be borne by the main network node according to the QoS capability of the auxiliary network node, the QoS capability of the main network node and the QoS requirement of the data stream or the data transmission channel, and determines to configure the data stream or the data transmission channel on the SCG split bearer. In this way, when the data stream or the data transmission channel is configured to the SCG split bearer based on the QoS requirement of the data stream, the QoS that the main network node needs to bear is determined by the auxiliary network node according to the QoS capability of the main network node, and the QoS capability of the main network node is not exceeded, so that the success rate of configuring the data stream or the data transmission channel to the SCG split bearer can be ensured as much as possible.
In this application, the secondary network node may be referred to as a first network device and the primary network node may be referred to as a second network device. Not limited to the primary network node and the secondary network node in the existing dual connectivity scenario, the first network device and the second network device may also be transmission points or other types of network devices with the same functions, and roles of the two network devices (the primary network node and the secondary network node) in the dual connectivity scenario may be dynamically configured, for example, roles and functions of respective transmission points in a super cell (supercell) may be configured by a global controller.
In this application, the SCG split bearer may be referred to as a first split bearer. The first split bearer is a bearer type, and is not limited to the SCG split bearer defined in the existing dual connectivity scenario, and in the evolution of the future communication system, the first split bearer may also be defined as a split bearer in another form or name, which is not limited herein.
In this application, the QoS capability of the network node may include one or more of an Aggregated Maximum Bit Rate (AMBR), a Maximum Bit Rate (MBR), a Guaranteed Bit Rate (GBR), an Allocation And Retention Priority (ARP), a packet forwarding policy, a Priority policy, a notification policy, And other indexes that the network node can support. For specific definitions of various parameters, reference may be made to the 3GPP TS 23.401 standard and the 3GPP TS23.501 standard, which are not described herein in detail.
In the present application, the QoS requirement of the data flow or the data transmission channel may include at least one of the following QoS parameters: QoS Class Identifier (QCI), Allocation and Retention Priority (ARP), Guaranteed Bit Rate (GBR), Maximum Bit Rate (MBR), 5G quality of service Indicator (5G QoS Indicator, 5QI), Guaranteed Flow Bit Rate (GFBR), Maximum Flow Bit Rate (MBR), notification control (notification control), and the like. For specific definitions of various parameters, reference may be made to the 3GPP TS 23.401 standard and the 3GPP TS23.501 standard, which are not described herein in detail.
The data transmission method provided by the present application is not limited to configuring the data stream or the data transmission channel to the SCG split bearer based on the QoS requirement of the data stream or the data transmission channel in the dual connection scenario, and may also be applied to other multi-connection scenarios that require configuring the data stream or the data transmission channel to any type of split bearer, which is not limited herein.
Based on the above-mentioned main inventive principle, the following describes the general flow of the data transmission method provided in the present application. As shown in fig. 8, the data transmission method provided by the present application may include:
s101, a data transmission channel of a first data stream is established between the terminal equipment and the core network.
Here, the first data flow may be one or more of Service Data Flow (SDF), service data flow aggregation (SDF Aggregate), data flow (data flow), QoS flow (QoS flow), packet flow (packet flow), and the like. The data transmission path of the first data stream may be an evolved packet system bearer (EPS bearer), an evolved radio access bearer (E-RAB), a protocol data unit session (PDU session), or the like.
In establishing the data transmission path of the first data flow, the second network device (as the master network node) may obtain characteristic information of the data transmission path of the first data flow, which may include an identification of the data transmission path and QoS parameters. The identifier of the data transmission path may be an EPS bearer ID, an E-RAB ID, a PDU Session ID, or the like. The QoS parameter of the data transmission path may be used to indicate the QoS requirement of the data transmission path. The QoS parameter of the data transmission path may include at least one of: QCI, ARP, GBR, MBR, 5QI, GFBR, MFBR, notification control, and the like. For specific definitions of various parameters, reference may be made to the 3GPP TS 23.401 standard and the 3GPP TS23.501 standard, which are not described herein in detail.
During the process of establishing the data transmission path of the first data flow, the second network device (as the master network node) may obtain characteristic information of the first data flow, which may include an identification of the first data flow and QoS parameters. The identifier of the first data flow may be service ID, SDF Aggregate ID, data flow ID, service data flow ID, QoS flow ID, packet flow ID, or the like. The QoS parameter for the first data flow may be used to indicate the QoS requirement for the first data flow. The QoS parameters of the first data flow may include at least one of: QCI, ARP, GBR, MBR, 5QI, GFBR, MFBR, notification control, and the like. For specific definitions of various parameters, reference may be made to the 3GPP TS 23.203 standard and the 3GPP TS23.501 standard, which are not described herein in detail.
Optionally, the QoS parameter of the data transmission path of the first data flow may include a QoS parameter of the first data flow, and the QoS parameter of the first data flow may be derived from the QoS parameter of the data transmission path of the first data flow.
In an EN-DC scenario, the first data stream may be an SDF and the data transmission path of the first data stream may be an E-RAB. One E-RAB may be used to transport multiple SDFs, and the QoS parameters of each SDF in the E-RAB may be similar or identical. The embodiment of fig. 10 will be described in detail later to describe the specific implementation of the data transmission method provided by the present application in an EN-DC scenario.
In the MR-DC with NGC scenario, the first data flow may be QoS flow, and the data transmission path of the first data flow may be PDU Session. One PDU Session may be used to transmit multiple QoS flows, which may have different QoS parameters than those of the PDU Session level. The embodiment of fig. 11 will be described in detail later on to describe the specific implementation of the data transmission method provided by the present application in MR-DC with NGC scenario.
S102, the second network device (as the master network node) determines to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer. Here, the data offloading anchor point of the first split bearer is a first network device (as a secondary network node), and the first split bearer is available for jointly transmitting data through the first network device and a second network device.
Specifically, the specific implementation of the second network device (as the master network node) determining to configure the first data stream and/or the data transmission channel of the first data stream to the first split bearer may include the following several ways:
(1) first, if the data plane interface of the first data flow and/or the data transmission channel of the first data flow is connected to the second network device and the QoS capability of the second network device available for the first split bearer cannot meet the QoS requirement of the first data flow and/or the data transmission channel of the first data flow, the second network device determines to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer.
For example, the second network device (as the master network node) may determine its own QoS capabilities available for the first split bearer based on the load conditions or link conditions of its own bearer. If the QoS capability available to the second network device (as the master network node) for the first split bearer fails to meet the QoS requirements of the first data flow and/or the data transmission channel of the first data flow, it is determined to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer.
It should be understood that the PDCP layer of the first split bearer is located in the first network device (as a secondary network node), i.e. the first network device is responsible for more data processing in the data transmission process. Therefore, configuring the first data stream and/or the data transmission channel of the first data stream to the first split bearer may greatly reduce the burden of the second network device (as the primary network node). Therefore, reasonable configuration of data service among different network nodes can be realized, and influence on network transmission efficiency caused by overload of a main network node is avoided.
In this application, the QoS capabilities of the second network device available for the first split bearer may be all or part of the available QoS capabilities of the second network device. In some possible scenarios, the second network device needs to reserve part of the available QoS capabilities for transmitting some emergency or special traffic, in which case the QoS capabilities of the second network device available for the first split bearer are the available QoS capabilities of the part of the second network device.
(2) In a second manner, if the data plane interface of the first data stream and/or the data transmission channel of the first data stream is connected to the first network device, the second network device determines to configure the first data stream and/or the data transmission channel of the first data stream to the first split bearer.
For example, in an EN-DC scenario, it is assumed that an eNB (primary network node) knows through an MME that a certain E-RAB is established between a terminal device, a gNB (secondary network node) and an S-GW (serving gateway in the core network), i.e. that the data plane interface of the E-RAB is connected to the gNB (secondary network node). Then the eNB (the master network node) may determine to configure the E-RAB onto the SCG split bearer. In this way, the main data processing work of the E-RAB is performed on the gNB (secondary network node), and data is prevented from being processed by switching to the eNB (primary network node), so that the efficiency of data transmission can be improved.
Not limited to the above-mentioned two implementations, in practical applications, the second network device (as the master network node) may also determine to configure the first data stream and/or the data transmission channel of the first data stream to the first split bearer according to other conditions. For example, the second network device (as the master network node) may determine whether to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer according to a traffic allocation policy set by the core network. The present application does not limit the condition under which the second network device (as the master network node) determines to configure the first data stream and/or the data transmission channel of the first data stream to the first split bearer.
S103, the second network device (as a primary network node) sends a first message to the first network device (as a secondary network node). Here, the first message may be used to instruct the first network device (as a secondary network node) to configure the first data flow and/or a data transmission channel of the first data flow to the first split bearer. The first message may also be used to indicate QoS capabilities of the second network device that may be used for the first split bearer, the QoS requirements of the first data flow and/or the data transmission channel of the first data flow.
Specific implementations of the first message are described in detail below.
(1) The first message may be used to instruct the first network device to configure the first data flow and/or a data transmission channel of the first data flow to the first split bearer
In particular, the first message may carry an indication information, which may be used to instruct the first network device (as a secondary network node) to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer.
Alternatively, the indication information may be embodied by a field or information related to the first split bearer (e.g., SCG split bearer).
For example, in an EN-DC scenario, the first message may carry a field for the name "E-RABs-ToBeAdded-Item-SCG-Split-Bearer". The name of this field is related to the SCG split bearer, which may be used to instruct the secondary network node to configure the first data stream and/or the data transmission channel of the first data stream to the SCG split bearer.
For another example, in an MR-DC with NGC scenario, the first message may carry a field for the name "PDU sessions-ToBeBeBeAdded-Item-SCG Split-Bearer". The name of this field is related to the SCG split bearer, which may be used to instruct the secondary network node to configure the first data stream and/or the data transmission channel of the first data stream to the SCG split bearer.
The examples are merely illustrative of the present application and should not be construed as limiting. In practical applications, other named fields or indication modes can be used for indication, and the application is not limited.
Optionally, the first message may also implicitly instruct the first network device to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer. For example, if the first message includes indication information of QoS capabilities of the second network device available for the first split bearer, the first network device may know an indication of the second network device (indicating that the first data flow and/or a data transmission channel of the first data flow is configured to the first split bearer). The examples are merely illustrative of the present application and should not be construed as limiting.
(2) The first message may be used to indicate QoS requirements of the first data flow and/or a data transmission channel of the first data flow
The first message may carry characteristic information of the first data flow and/or the data transmission channel of the first data flow, and the characteristic information may include an identifier and a QoS parameter of the first data flow and/or the data transmission channel of the first data flow. For the identification of the first data stream and/or the data transmission channel of the first data stream, and the definition and description of the QoS parameter, reference may be made to relevant contents in S101, and details are not repeated here.
(3) The first message may be used to indicate QoS requirements of the first data flow and/or a data transmission channel of the first data flow
The first message may carry an indication of QoS capabilities available to the second network device (as the primary network node) for the first split bearer. The QoS capability available to the second network device (as the primary network node) for the first split bearer may be represented by at least one parameter selected from the group consisting of: AMBR values, MBR values, GBR bit rates, ARP, packet forwarding policy, priority policy, notification policy, etc. The indication information may typically be a QCI.
Further, the first message may also carry other information.
(1) The first message may further carry key information, where the key information may include a root key, and the root key may be used to generate a key for data encryption and/or integrity protection, so that security of the first data stream and/or a data transmission channel of the first data stream may be guaranteed.
In an alternative implementation, the root key may be generated by the second network device. For example, the root key may be generated by the second network device according to KeNB or KAN, such as a root key KDF (KeNB/KAN, other input information), where KDF is a key generation algorithm, and the other input information may include a Count value Count, and the Count value Count may be used to maintain the freshness of the root key during key update. In another alternative implementation, the root key may be sent to the second network device by a key management unit in the core network.
(2) The first message may also carry security capability information of the terminal device. Specifically, the security capability information of the terminal device may include algorithm information of data encryption and/or integrity protection that the terminal device may support.
(3) The first message may also carry address information used by the second network device for the first split bearer, for example, an address on an X2 or Xn interface, such as X2DL TNL address information or Xn DL TNL address information.
Optionally, the first message may be an SgNB Addition Request (or SgNB Modification Request) extended in an EN-DC scenario, and a field of the name of "E-RABs-tobeaded-Item-SCG-Split-Bearer" mentioned above and a field indicating QoS capability available to the second network device (as the master network node) for the first Split Bearer are added to the signaling. The first message may be an extended SN Addition Request/SN Modification Request in an MR-DC with NGC scenario, where a field of the above-mentioned "PDU sessions-to-obeadd-Item-SCG Split-Bearer" name is added to the signaling, and a field indicating QoS capability available to the second network device (as the master network node) for the first Split Bearer.
Without being limited thereto, the first message may also be other extended signaling, and may also be a newly defined message, which is not limited in this application.
S104, the first network device (as a secondary network node) may determine to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer according to the QoS capability of the first network device, the QoS capability of the second network device, and the QoS requirement of the data transmission channel of the first data flow and/or the first data flow, and determine the QoS that the second network device needs to bear. Specifically, if the QoS capability of the first network device and the QoS capability of the second network device available for the first split bearer satisfy the QoS requirement of the first data flow and/or the data transmission channel of the first data flow, the first network device determines that the first data flow and/or the data transmission channel of the first data flow is configured to the first split bearer.
Specifically, the QoS capability of the first network device may be determined by the first network device in combination with current configuration conditions, load conditions, link conditions, and the like. The QoS capability of the first network device may include one or more of AMBR values, MBR values, GBR bit rates, ARP, packet forwarding policies, priority policies, notification policies, etc. that the first network device may support.
In the application, the QoS that the second network device needs to bear determined by the first network device does not exceed the maximum QoS capability that the second network device can support.
Specifically, the QoS that the second network device needs to undertake may be represented by at least one of the following parameters: AMBR values, MBR values, GBR bit rates, ARP, packet forwarding policy, priority policy, notification policy, etc.
In some alternative embodiments, the QoS that the second network device needs to assume may also take the following forms.
Optionally, the QoS that the second network device needs to undertake may be a share of one or more QoS parameters (e.g., MBR value, AMBR value, GBR bit rate) of the second network device that are available to support the first split bearer and that represent the data transmission rate in the QoS parameters (e.g., MBR value, AMBR value, GBR bit rate) of the first data stream and/or the data transmission channel of the first data stream that represent the data transmission rate.
For example, assume that the first data stream and/or the data transmission channel of the first data stream requires a GBR of 10Gbps and the GBR of the second network device that is available to support the first split bearer is 1 Gbps. Then the QoS that the second network device needs to assume is 10% of the GBR required for the first data flow and/or the data transmission channel of the first data flow. The examples are merely illustrative of the present application and should not be construed as limiting.
Optionally, the QoS that the second network device needs to bear may be a maximum QoS capability value of one or more QoS parameters (such as MBR value, AMBR value, GBR bit rate, packet error loss rate, ARP capability, etc.) of the second network device that may be used to support the first split bearer.
For example, assuming that the maximum MBR value of the second network device available to support the first split bearer is 100Gbps, the minimum packet error loss rate is 0.5%. Then, the QoS that the second network device needs to assume is: MBR is 100Gbps, and packet error loss rate is 0.5%. The examples are merely illustrative of the present application and should not be construed as limiting.
In this application, the first data stream may be one or more data streams. When the first data flow is a plurality of data flows, the first network device may configure the first data flow and/or a data transmission channel of the first data flow into one or more first split bearers. Optionally, the first network device may configure a plurality of data streams in the data transmission channel of the first data stream onto a plurality of first split bearers. For example, in an MR-DC with NGC scenario, multiple QoS flows in a PDU Session can be configured onto different SCG split bearer. The examples are merely illustrative of the present application and should not be construed as limiting.
S105, the first network device (as a secondary network node) sends a second message to the second network device (as a primary network node), where the second message is used to instruct the first network device to confirm that the first data stream and/or the data transmission channel of the first data stream are configured to the first split bearer, and is used to instruct the second network device to need to bear QoS.
Specific implementations of the second message are described in detail below.
(1) The second message may be used to instruct the first network device to confirm the configuration of the first data flow and/or the data transmission channel of the first data flow to the first split bearer
Optionally, the second message may carry an indication information, where the indication information may be used to indicate that the first network device confirms to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer.
Alternatively, the indication information may be a field or information related to the first split bearer (e.g., SCG split bearer).
For example, in an EN-DC scenario, the second message may carry a field for the name "E-RABs-Admitted-ToBeBeAdded-Item-Split-Bearer". The name of this field is related to the SCG split bearer, and may be used to instruct the secondary network node to confirm that the first data stream and/or the data transmission channel of the first data stream is configured to the SCG split bearer.
For another example, in an MR-DC with NGC scenario, the second message may carry a field for the name "PDU sessions-Admitted-ToBe-Admitted-Item-SCG Split-Bearer". The name of this field is related to the SCG split bearer, and may be used to instruct the secondary network node to confirm that the first data stream and/or the data transmission channel of the first data stream is configured to the SCG split bearer.
The examples are merely illustrative of the present application and should not be construed as limiting. In practical applications, other named fields or indication modes can be used for indication, and the application is not limited.
Optionally, the second message may also implicitly indicate that the first network device confirms to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer. For example, if the second message includes information indicating the QoS that the second network device needs to assume, the second network device may determine that the first network device confirms the configuration of the first data flow and/or the data transmission channel of the first data flow to the first split bearer. The examples are merely illustrative of the present application and should not be construed as limiting.
(2) The second message may be for a QoS that the second network device needs to assume
Optionally, the second message carries an indication information, where the indication information explicitly indicates the QoS that the second network device needs to bear.
Optionally, the QoS that the second network device needs to assume is implicitly indicated in the second message. For example, the second message includes QoS class information assumed by the first network device, and then the second network device may determine to obtain the QoS class information that the second network device needs to assume according to the QoS class information assumed by the first network device and the QoS requirement of the first data flow and/or the data transmission channel of the first data flow.
In addition, the second message may also carry configuration information of the first split bearer. Wherein: the configuration information of the first split bearer may comprise at least an identification of the first split bearer. If the first split bearer is not established, the configuration information of the first split bearer may further include configuration information of each layer protocol stack of the first split bearer, such as PDCP layer configuration information, RLC layer configuration information, and MAC layer configuration information. For specific content of configuration information of each layer protocol stack, reference may be made to 3GPP TS 36.331 standard, which is not described herein in detail.
Further, the second message may also carry: the first network device determines algorithm information to be applied to data encryption and/or integrity protection of the first split bearer.
Further, the second message may also carry: the address information of the first network device for the first split bearer, such as an address on an X2 or Xn interface (e.g., X2UL TNL address information or Xn UL TNL address information or X2DL TNL address information or Xn DL TNL address information), an address on an S1 interface (e.g., S1DL TNL address information or S1UL TNL address information), or an address on an NG-U interface (e.g., NG-U DL TNL address information or NG-U UL TNL address information).
Optionally, the second message may be an extended SgNB Addition Request ACK (or SgNB Modification Request ACK) in the EN-DC scenario, and the above-mentioned "E-RABs-Admitted-tobebaded-Item-Split-
A bear "name, and a field indicating the QoS that the second network device (as the primary network node) needs to assume. The second message may be an SN Addition Request acknowledgement (or SN Modification Request acknowledgement) extended in the MR-DC with NGC scenario, where a field of the above-mentioned "PDU sessions-accepted-to be Added-Item-SCG Split-Bearer" name and a field indicating the QoS that the second network device (as the master network node) needs to bear are Added to the signaling.
Without being limited thereto, the second message may also be other extended signaling, and may also be a newly defined message, which is not limited in this application.
S106, the second network device (as the master network node) sends a configuration message of the first split bearer to the terminal device. The configuration message may be used for the terminal device to configure the first split bearer.
Specifically, the configuration message may be an RRC Connection Reconfiguration (RRC Connection Reconfiguration) message.
Optionally, the configuration message may carry the root key mentioned in the foregoing S103. Optionally, if the root key has already been sent to the terminal device, the configuration message may carry other input information, such as Count, for generating the root key.
Optionally, the configuration message may carry algorithm information determined by the first network device and applied to data encryption and/or integrity protection of the first split bearer.
S107, the terminal device configures the first segmentation bearer according to the configuration message of the first segmentation bearer, and sends a configuration confirmation message to the second network device. The configuration confirm message may be used to indicate that the terminal device has completed configuring the first split bearer.
Alternatively, the configuration confirmation message may be an RRC Connection Reconfiguration Response (RRC Connection Reconfiguration Response) message.
S108, the second network device sends a third message to the first network device, where the third message may be used to indicate that the terminal device has completed configuring the first split bearer.
S109, the terminal device may perform random access to the first network device (as a secondary network node). S109 is an optional step, which is performed on condition that the terminal device does not access the first network device (as a secondary network node). The execution time of S109 is also not limited to that shown in fig. 8, and may be earlier or later.
S110, the first network device, the second network device and the terminal device respectively establish protocol stacks corresponding to the first segmentation bearer. Specifically, reference may be made to fig. 4B or fig. 5B, which is not described herein again. S110 is an optional step of performing a first split bearer which has not yet been established in the first split bearer. The execution time of S110 is also not limited to that shown in fig. 8, and may be earlier or later.
S111-S112, the second network device (acting as a primary network node) sends a status transfer message, such as a serial number status transfer (SN status transfer) message, to the first network device (acting as a secondary network node). Then, the terminal device, the first network device, the second network device and the core network execute a path switching process.
It should be understood that S111-S112 are optional steps, being performed only if the user plane interface of the first data stream and/or the data transmission channel of said first data stream is connected to the second network device. This is illustrated in FIGS. 9A-9B.
As shown in fig. 9A, the first data stream and/or the user plane interface of the data transmission channel of the first data stream is connected to a first network device (SN). As shown in fig. 9B, the first data flow and/or the user plane interface of the data transmission channel of the first data flow is connected to the second network device (MN).
It can be understood that, in the scenario illustrated in fig. 9B, since the first data stream and/or the data transmission channel of the first data stream is configured to the first split bearer (SCG split bearer), the first data stream and/or the split anchor point of the data transmission channel of the first data stream needs to be switched to the first network device (SN). By executing S111-S112, it may be achieved that a offloading anchor point of a first data stream and/or a data transmission channel of the first data stream needs to be switched to a first network device (SN).
By implementing the embodiment of fig. 8, the first network device (as a secondary network node) configures the first data flow and/or the data transmission channel of the first data flow to the first split bearer (SCG split bearer) according to the available QoS capability of the second network device (as a primary network node), and determines the QoS that the second network device needs to bear. Therefore, the QoS which the main network node needs to bear can be ensured not to exceed the QoS capability of the main network node, and the success rate of configuring the data flow or the data transmission channel to the SCG split bearer is improved.
The data transmission method provided by the application is described in detail below by taking an EN-DC scenario and an MR-DC with NGC scenario as examples. Without being limited to the multi-connection scenario related to the embodiment of fig. 10 or fig. 11, the data transmission method provided by the present application may also be applied to other multi-connection scenarios, and the specific implementation may refer to the embodiment of fig. 8.
Fig. 10 shows an implementation flow of the data transmission method provided by the present application in an EN-DC scenario. In an EN-DC scenario, the SgNB may be SgNB, the MeNB may be MeNB, the core network is an EPC core network, and the MeNB is connected to an MME in the EPC core network. The following is developed:
s201, an E-RAB is established between the terminal equipment and an EPC core network.
Specifically, during the process of establishing the E-RAB, the MeNB may obtain the characteristic information of the E-RAB, which may include the identity (e.g., E-RAB ID) and QoS parameters of the E-RAB.
S202, the MeNB determines to configure the E-RAB to the SCG split bearer. Here, the data splitting anchor point of the SCG split bearer is SgNB, and the SCG split bearer can be used for jointly transmitting data through SgNB and MeNB.
S203, the MeNB sends a SgNB Addition Request (or SgNB Modification Request) to the SgNB. Here, the SgNB Addition Request (or SgNB Modification Request) may be used to instruct the SgNB to configure the E-RAB to the SCG split bearer. The SgNB Addition Request (or SgNB Modification Request) may also be used to indicate QoS capabilities of MeNB available for SCG split bearer, QoS requirements of E-RAB.
S204, the SgNB can determine to configure the E-RAB to the SCG split bearer and determine the QoS required to be undertaken by the MeNB according to the QoS capability of the SgNB, the QoS capability of the MeNB and the QoS requirement of the E-RAB.
S205, the SgNB sends SgNB Addition Request ACK (or SgNB Modification Request ACK) to the MeNB, wherein the SgNB Addition Request ACK (or SgNB Modification Request ACK) is used for instructing the SgNB to confirm that the E-RAB is configured to the SCG split bearer, and is used for instructing the MeNB to need to bear the QoS.
S206, the MeNB sends a configuration message of the SCG split bearer to the terminal device. The configuration message may be used for the terminal device to configure the SCG split bearer.
S207, the terminal equipment configures the SCG split bearer according to the configuration message of the SCG split bearer, and sends a configuration confirmation message to the MeNB. The configuration confirm message may be used to indicate that the terminal device has completed configuring the SCG split bearer.
S208, the MeNB sends a third message to the SgNB, where the third message may be used to indicate that the terminal device has completed configuring the SCG split bearer.
S209, the terminal device may perform random access to the SgNB. S209 is an optional step, which is performed on the condition that the terminal device does not access the SgNB. The execution time of S209 is also not limited to that shown in fig. 8, and may be earlier or later.
S210, the protocol stacks corresponding to the SCG split bearer are respectively established by the SgNB, the MeNB and the terminal equipment. Specifically, reference may be made to fig. 4B or fig. 5B, which is not described herein again. S210 is an optional step, SCG split bearer not yet established at SCG split bearer. The execution time of S210 is also not limited to that shown in fig. 10, and may be earlier or later.
S211-S212, the MeNB sends a status transfer message, such as an SN status transfer message, to the SgNB. Then, the terminal device, SgNB, MeNB, and core network perform a path switching procedure.
It should be understood that S211-S212 are optional steps, performed only on condition that the user plane interface of the E-RAB is connected to the MeNB.
In this embodiment, a field (named "MN maximum QoS") may be extended in the SgNB Addition Request (or SgNB Modification Request) and may be used to indicate the QoS capability of the MeNB available for the SCG split bearer.
FIG. 12A exemplarily shows an SN Addition Request/SN Modification Request. As shown in fig. 12A, the SN Addition Request/SN Modification Request may include at least: a field "SCG split Bearer SN Addition Item", a field "E-RAB/PDU session ID", a field "Total E-RAB/PDU session Level QoS Parameter", an extension field "MN maximum QoS", and a field "MN GTP Tunnel Endpoint". The field 'SCG split Bearer SN Addition Item' can be used for indicating that the E-RAB/PDU session is configured to the SCG split Bearer, the field 'E-RAB/PDU session ID' is the identification of the E-RAB/PDU session, the field 'Total E-RAB/PDU session Level QoS Parameter' can be used for indicating the QoS requirement of the E-RAB/PDU, the extension field 'MN maximum QoS' can be used for indicating the QoS capability of the MN which can be used for the SCG split Bearer, and the field 'MN GTP Tunnel Endpoint' can be used for indicating the address information of the MN which can be used for the SCG split Bearer.
In an EN-DC scenario, the SN Addition Request/SN Modification Request shown in fig. 12A may be specifically implemented as a SgNB Addition Request/SgNB Modification Request. Except for the extension field "MN maximum QoS", each field in the SN Addition Request/SN Modification Request may be implemented as a corresponding field in the SgNB Addition Request/SgNB Modification Request, which may specifically refer to standard 3GPP TS38.423, and is not described herein.
Fig. 12A only exemplarily shows a signaling format of the SN Addition Request/SN Modification Request, where names of fields/information segments may be different, a position relationship between fields/information segments is not limited by the drawing, and other fields/information segments may also be included, specifically, the SgNB Addition Request/SgNB Modification Request defined in standard 3GPP TS38.423 may be used as a reference, or signaling with similar functions may be defined in the future as a reference.
FIG. 12B exemplarily shows SN Addition Request acknowledgement/SN Modification Request acknowledgement. As shown in fig. 12B, the SN Addition Request acknowledgement/SN Modification Request acknowledgement may include at least: a field "SCG split Bearer SN Addition Item", a field "E-RAB/PDU session ID", an extension field "MN QoS support", and a field "SN GTP Tunnel Endpoint". The field 'SCG split Bearer SN Addition Item' can be used for indicating that the E-RAB/PDU session is configured to the SCG split Bearer, the field 'E-RAB/PDU session ID' is the identification of the E-RAB/PDU session, the extension field 'MN QoS support' can be used for indicating the QoS which the MN needs to bear, and the field 'SN GTP Tunnel Endpoint' can be used for indicating the address information of the SN used for the SCG split Bearer.
In an EN-DC scenario, the SN Addition Request acknowledgement/SN Modification Request acknowledgement shown in fig. 12B may be specifically implemented as SgNB Addition Request acknowledgement/SgNB Modification Request acknowledgement. Except for the extension field "MN QoS support", each field in the SN Addition Request acknowledgement/SN Modification Request acknowledgement may be implemented as a corresponding field in the SgNB Addition Request acknowledgement/SgNB Modification Request acknowledgement, which may specifically refer to standard 3GPP TS38.423, and is not described herein.
Fig. 12B only exemplarily shows a signaling format of an SN Addition Request acknowledgement/SN Modification Request acknowledgement, where names of respective fields/information segments may be different, a position relationship between the respective fields/information segments is not limited by the drawings, and other fields/information segments may also be included, and specifically may be based on SgNB Addition Request acknowledgement/SgNB Modification Request acknowledgement defined in standard 3GPP TS38.423, or may be based on signaling defining similar functions in the future.
It can be understood that specific implementation of each step in the embodiment of fig. 10 may refer to the embodiment of fig. 8, and is not described herein again.
Fig. 11 shows an implementation flow of the data transmission method provided by the present application in an MR-DC with NGC scenario. In an MR-DC with NGC scenario, MN can be SN, SN can be MN, core network is NGC core network, MN connects with AMF in NGC core network. The following is developed:
s301, PDU session is established between the terminal equipment and the core network.
Specifically, in the process of establishing the PDU session, the MN may obtain characteristic information of the PDU session, where the characteristic information may include an identifier of the PDU session (e.g., a PDU session ID) and a QoS parameter.
S302, the MN determines to configure the PDU session to the SCG split bearer. Here, the data offloading anchor point of the SCG split bearer is SN, and the SCG split bearer can be used for jointly transmitting data through MN and SN.
S303, the MN sends an SN Addition Request (or an SN Modification Request) to the SN. Here, an SN Addition Request (or an SN Modification Request) may be used to instruct an SN to configure the above PDU session to an SCG split bearer. The SN Addition Request (or SN Modification Request) may also be used to indicate the QoS capability of the SN available to the SCG split bearer, the QoS requirement of the PDU session.
S304, the SN can determine to configure the PDU session to the SCG split bearer and determine the QoS that the SN needs to bear according to the QoS capability of the MN, the QoS capability of the SN and the QoS requirement of the PDU session.
S305, the SN sends SN Addition Request acknowledgement (or SN Modification Request acknowledgement) to the MN, wherein the SN Addition Request acknowledgement (or SN Modification Request acknowledgement) is used for indicating the MN to confirm to configure the PDU session to the SCG split bearer and indicating the QoS required to be undertaken by the SN.
S306, the MN sends the SCG split bearer configuration message to the terminal equipment. The configuration message may be used for the terminal device to configure the SCG split bearer.
S307, the terminal equipment configures the SCG split bearer according to the configuration message of the SCG split bearer, and sends a configuration confirmation message to the SN. The configuration confirm message may be used to indicate that the terminal device has completed configuring the SCG split bearer.
S308, the SN sends a third message to the MN, where the third message may be used to indicate that the terminal device has completed configuring the SCG split bearer.
S309, the terminal device may perform random access to the SN. S309 is an optional step, which is performed on the condition that the terminal device does not access the SN. The execution time of S309 is also not limited to that shown in fig. 8, and may be earlier or later.
S310, the MN, the SN and the terminal equipment respectively establish a protocol stack corresponding to the SCG split bearer. Specifically, reference may be made to fig. 4B or fig. 5B, which is not described herein again. S310 is an optional step, SCG split bearer not yet established at SCG split bearer. The execution time of S310 is also not limited to that shown in fig. 10, and may be earlier or later.
S311-S312, the MN sends a status transfer message, such as an SN status transfer message, to the SN. Then, the terminal device, the MN, the SN, and the core network perform a path switching process.
It should be understood that S311-S312 are optional steps, performed only on condition that the user plane interface of the PDU session is connected to the SN.
In this embodiment, a field (named "MN maximum QoS") may be extended in the SN Addition Request (or SN Modification Request) and may be used to indicate the QoS capability of the MN that is available for the SCG split bearer.
FIG. 12A exemplarily shows an SN Addition Request/SN Modification Request. As shown in fig. 12A, the SN Addition Request/SN Modification Request may include at least: a field "SCG split Bearer SN Addition Item", a field "E-RAB/PDU session ID", a field "Total E-RAB/PDU session Level QoS Parameter", an extension field "MN maximum QoS", and a field "MN GTP Tunnel Endpoint". The field 'SCG split Bearer SN Addition Item' can be used for indicating that the E-RAB/PDU session is configured to the SCG split Bearer, the field 'E-RAB/PDU session ID' is the identification of the E-RAB/PDU session, the field 'Total E-RAB/PDU session Level QoS Parameter' can be used for indicating the QoS requirement of the E-RAB/PDU, the extension field 'MN maximum QoS' can be used for indicating the QoS capability of the MN which can be used for the SCG split Bearer, and the field 'MN GTP Tunnel Endpoint' can be used for indicating the address information of the MN which can be used for the SCG split Bearer.
In an MR-DC with NGC scenario, the SN Addition Request/SN Modification Request shown in fig. 12A may be specifically implemented as SgNB Addition Request/SgNB Modification Request, or may also be implemented as SeNB Addition Request/SeNB Modification Request. Except for the extension field "MN maximum QoS", each field in the SN Addition Request/SN Modification Request may be implemented as a corresponding field in the SgNB Addition Request/SgNB Modification Request, or the SeNB Addition Request/SeNB Modification Request, which may specifically refer to standard 3GPP TS38.423, and is not described herein.
Fig. 12A only exemplarily shows a signaling format of the SN Addition Request/SN Modification Request, where names of fields/information segments may be different, a position relationship between fields/information segments is not limited by the drawing, and other fields/information segments may also be included, specifically, the SgNB Addition Request/SgNB Modification Request defined in standard 3GPP TS38.423 may be used as a reference, or signaling with similar functions may be defined in the future as a reference.
FIG. 12B exemplarily shows SN Addition Request acknowledgement/SN Modification Request acknowledgement. As shown in fig. 12B, the SN Addition Request acknowledgement/SN Modification Request acknowledgement may include at least: a field "SCG split Bearer SN Addition Item", a field "E-RAB/PDU session ID", an extension field "MN QoS support", and a field "SN GTP Tunnel Endpoint". The field 'SCG split Bearer SN Addition Item' can be used for indicating that the E-RAB/PDU session is configured to the SCG split Bearer, the field 'E-RAB/PDU session ID' is the identification of the E-RAB/PDU session, the extension field 'MN QoS support' can be used for indicating the QoS which the MN needs to bear, and the field 'SN GTP Tunnel Endpoint' can be used for indicating the address information of the SN used for the SCG split Bearer.
In the MR-DC with NG scenario, the SN Addition Request acknowledgement/SN Modification Request acknowledgement shown in fig. 12B may be specifically implemented as SgNB Addition Request acknowledgement/SgNB Modification Request acknowledgement, or may be implemented as SeNB Addition Request/SeNB Modification Request. Except for the extension field "MN QoS support", each field in the SN Addition Request acknowledgement/SN Modification Request acknowledgement may be implemented as a corresponding field in an SgNB Addition Request acknowledgement/SgNB Modification Request acknowledgement, or a SeNB Addition Request/SeNB Modification Request, which may specifically refer to standard 3GPP TS38.423, and is not described herein.
Fig. 12B only exemplarily shows a signaling format of an SN Addition Request acknowledgement/SN Modification Request acknowledgement, where names of respective fields/information segments may be different, a position relationship between the respective fields/information segments is not limited by the drawings, and other fields/information segments may also be included, and specifically may be based on SgNB Addition Request acknowledgement/SgNB Modification Request acknowledgement defined in standard 3GPP TS38.423, or may be based on signaling defining similar functions in the future.
It can be understood that specific implementation of each step in the embodiment of fig. 11 may refer to the embodiment of fig. 8, and is not described herein again.
Referring to fig. 13, fig. 13 is a wireless communication system 20 provided by an embodiment of the present application, and a first network device 300 and a second network device 500 in the wireless communication system 20. The first network device 300 may be the above-mentioned first network device (as a secondary network node) in the above-mentioned method embodiment, and the second network device 500 may be the above-mentioned second network device (as a primary network node) in the above-mentioned method embodiment. The following are described separately.
As shown in fig. 13, the first network device 300 may include: a determining unit 301, a transmitting unit 303 and a receiving unit 305. Wherein:
the receiving unit 305 may be configured to receive a first message sent by the second network device 500, where the first message may be used to indicate that a first data flow between the terminal device and the core network and/or a data transmission channel of the first data flow is configured to the first split bearer, and the first message may also be used to indicate a QoS capability of the second network device 500 that may be used for the first split bearer, and a QoS requirement of the first data flow and/or the data transmission channel of the first data flow.
The determining unit 301 may be configured to determine the QoS that the second network device 500 needs to assume according to the QoS capability of the first network device 300, the QoS capability of the second network device 500, and the QoS requirement of the first data flow and/or the data transmission channel of the first data flow.
A sending unit 303, configured to send a second message to the second network device 500, where the second message is configured to confirm that the first data flow and/or the data transmission channel of the first data flow is configured to the first split bearer, and is configured to indicate the QoS that the second network device 500 needs to assume.
In this application, the data offloading anchor point of the first split bearer is the first network device 300, and the first split bearer may be used to transmit data together through the first network device 300 and the second network device 500. Specifically, the first split bearer may be a secondary cell group split bearer SCG split bearer, the first network device 300 may be a secondary network node, and the second network device 500 may be a primary network node.
In some optional embodiments, the first message may carry address information for the second network device 500 to use for the first split bearer. The second message may carry address information for the first network device 300 for the first split bearer.
Specifically, the determining unit 301 is specifically configured to determine that the first data flow and/or the data transmission channel of the first data flow is configured to the first split bearer SCG split bearer if the QoS capability of the first network device 300 and the QoS capability of the second network device 500 available for the first split bearer satisfy the QoS requirement of the first data flow and/or the data transmission channel of the first data flow. Furthermore, the QoS that the second network device 500 needs to bear determined by the determining unit 301 does not exceed the maximum QoS capability that the second network device 500 can support.
The QoS capability of the first network device 300 may be determined by the determining unit 301 in combination with the current configuration situation, load situation, link condition, etc. The QoS capabilities of the first network device 300 may include one or more of AMBR values, MBR values, GBR bit rates, ARP, packet forwarding policies, priority policies, notification policies, etc. that the first network device 300 may support.
Wherein the QoS that the second network device 500 needs to undertake can be represented by at least one of the following parameters: AMBR values, MBR values, GBR bit rates, ARP, packet forwarding policy, priority policy, notification policy, etc.
In some optional embodiments, the receiving unit 305 is specifically configured to receive a third message sent by the second network device 500 after the sending unit 303 sends the second message, where the third message may be sent by the second network device 500 after the terminal device completes configuring the first split bearer, and is used to instruct the terminal device to complete configuring the first split bearer.
It can be understood that specific implementations of the functional units included in the first network device 300 may refer to the foregoing method embodiments, and are not described herein again.
As shown in fig. 13, the second network device 500 may include: a determining unit 501, a receiving unit 503 and a transmitting unit 505. Wherein:
the determining unit 501 may be configured to determine to configure a first data flow between a terminal device and a core network and/or a data transmission channel of the first data flow to a first split bearer.
A sending unit 505, configured to send a first message to the first network device 300, where the first message may be used to instruct the first network device to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer, and the first message may also be used to instruct the QoS capability of the second network device 500, which may be used for the first split bearer, and the QoS requirement of the first data flow and/or the data transmission channel of the first data flow.
The receiving unit 503 may be configured to receive a second message sent by the first network device 300, where the second message is used to confirm that the first data flow and/or the data transmission channel of the first data flow is configured to the first split bearer, and is used to indicate the QoS that needs to be assumed by the second network device 500.
In this application, the data offloading anchor point of the first split bearer is the first network device 300, and the first split bearer may be used to transmit data together through the first network device 300 and the second network device 500. Specifically, the first split bearer may be a secondary cell group split bearer SCG split bearer, the first network device 300 may be a secondary network node, and the second network device 500 may be a primary network node.
In some optional embodiments, the determining unit 501 is specifically configured to determine to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer if the data plane interface of the first data flow and/or the data transmission channel of the first data flow is connected to the second network device, and the QoS capability of the second network device available for the first split bearer cannot meet the QoS requirement of the first data flow and/or the data transmission channel of the first data flow.
In some optional embodiments, the determining unit 501 is specifically configured to determine to configure the first data stream and/or the data transmission channel of the first data stream to the first split bearer if a data plane interface of the first data stream and/or the data transmission channel of the first data stream is connected to the first network device.
In some optional embodiments, the sending unit 505 may be further configured to send, to the terminal device, a configuration message of the first split bearer after the receiving unit 503 receives the second message, where the configuration message is used for the terminal device to configure the first split bearer. Then, the receiving unit 503 may be further configured to receive a configuration confirmation message returned by the terminal device, where the configuration confirmation message is used to indicate that the terminal device has completed configuring the first split bearer. Thereafter, the sending unit 505 may be further configured to send a third message to the first network device 300, where the third message is used to indicate that the terminal device has completed configuring the first split bearer.
It can be understood that specific implementations of the functional units included in the second network device 500 may refer to the foregoing method embodiments, and are not described herein again.
In addition, an embodiment of the present invention further provides a wireless communication system, where the wireless communication system may be the wireless communication system 100 shown in fig. 3, and the wireless communication system may include: a first network device and a second network device. The first network device may be the first network device in the foregoing embodiment, and the second network device may be the second network device in the foregoing embodiment. Specifically, the structures of the first network device and the second network device may be as shown in a network device 200 shown in fig. 7. When the network device 200 is the first network device, the transmitter 205 may implement the functions as implemented by the sending unit 303 of the first network device, the receiver 206 may implement the functions as implemented by the receiving unit 305 of the first network device, and the processor 201 may implement the functions as implemented by the determining unit 301 of the first network device. When the network device 200 is a second network device, the transmitter 205 may implement the functions as implemented by the sending unit 505 of the second network device, the receiver 206 may implement the functions as implemented by the receiving unit 503 of the second network device, and the processor 201 may implement the functions as implemented by the determining unit 501 of the second network device. For specific implementation of the first network device and the second network device, reference may be made to the foregoing embodiments, which are not described herein again.
An embodiment of the present application further provides an apparatus, including: a processing module and a communication interface, wherein the processing module is capable of executing the method flows related to the first network device in any of the above method embodiments. Further, the apparatus may further include a storage module (e.g., a memory) configured to store instructions, and the processing module is configured to execute the instructions stored by the storage module, and the execution of the instructions stored in the storage module causes the processing module to execute the method flow related to the first network device in any of the above method embodiments. The apparatus may be a chip or a system of chips.
An embodiment of the present application further provides an apparatus, including: a processing module and a communication interface, wherein the processing module is capable of executing the method flows related to the second network device in any of the above method embodiments. Further, the apparatus may further include a storage module (e.g., a memory) configured to store instructions, and the processing module is configured to execute the instructions stored by the storage module, and the execution of the instructions stored in the storage module causes the processing module to execute the method flow related to the second network device in any of the above method embodiments. The apparatus may be a chip or a system of chips.
It should also be understood that the reference herein to first, second, and various numerical designations is merely a convenient division to describe and is not intended to limit the scope of the present application.
In the present application, "and/or" describes an association relationship of associated objects, which means that there may be three relationships, for example, a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone, wherein A and B can be singular or plural. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.
In the present application, "at least one" means one or more, "a plurality" means two or more. "at least one of the following" or similar expressions refer to any combination of these items, including any combination of the singular or plural items. For example, "at least one (a), b, or c", or "at least one (a), b, and c", may each represent: a, b, c, a-b (i.e., a and b), a-c, b-c, or a-b-c, wherein a, b, and c may be single or plural, respectively.
In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.
Relevant parts among the method embodiments of the application can be mutually referred; the apparatus provided in the respective apparatus embodiments is adapted to perform the method provided in the respective method embodiments, so that the respective apparatus embodiments may be understood with reference to the relevant parts in the relevant method embodiments.
The device structure diagrams given in the device embodiments of the present application only show simplified designs of the corresponding devices. In practical applications, the apparatus may comprise any number of transmitters, receivers, processors, memories, etc. to implement the functions or operations performed by the apparatus in the embodiments of the apparatus of the present application, and all apparatuses that can implement the present application are within the scope of the present application.
The names of the messages/frames/indication information, modules or units, etc. provided in the embodiments of the present application are only examples, and other names may be used as long as the roles of the messages/frames/indication information, modules or units, etc. are the same.
One of ordinary skill in the art will appreciate that all or part of the processes in the methods of the above embodiments may be implemented by hardware related to instructions of a computer program, which may be stored in a computer-readable storage medium, and when executed, may include the processes of the above method embodiments. And the aforementioned storage medium includes: various media capable of storing program codes, such as ROM or RAM, magnetic or optical disks, etc.

Claims (38)

1. A data transmission method is applied to a first network device, and is characterized by comprising the following steps:
a first network device receives a first message sent by a second network device, wherein the first message is used for indicating that a first data flow between a terminal device and a core network and/or a data transmission channel of the first data flow are configured to a first segmentation bearer; the data distribution anchor point of the first split bearer is first network equipment, and the first split bearer is used for jointly transmitting data through the first network equipment and the second network equipment; the first message is further used for indicating the QoS capability of the second network equipment available for the first split bearer, the QoS requirement of the first data flow and/or the data transmission channel of the first data flow; the first network device is an auxiliary network device, and the second network device is a main network device; in the process of establishing the data transmission path of the first data flow, the characteristic information of the data transmission path of the first data flow and/or the characteristic information of the first data flow is obtained by the second network device, the characteristic information of the data transmission path of the first data flow includes the identifier and the QoS parameter of the data transmission path of the first data flow, and the characteristic information of the first data flow includes the identifier and the QoS parameter of the first data flow;
the first network equipment determines the QoS required to be undertaken by the second network equipment according to the QoS capability of the first network equipment, the QoS capability of the second network equipment and the QoS requirement of the first data flow and/or the data transmission channel of the first data flow;
and the first network equipment sends a second message to the second network equipment, wherein the second message is used for confirming that the first data flow and/or the data transmission channel of the first data flow is configured to the first segmentation bearer, and is used for indicating the QoS required to be assumed by the second network equipment.
2. The method according to claim 1, wherein the first network device determines to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer according to the QoS capability of the first network device, the QoS capability of the second network device, and the QoS requirement of the data transmission channel of the first data flow and/or the first data flow, and specifically includes:
if the QoS capability of the first network device and the QoS capability of the second network device available for the first split bearer satisfy the QoS requirement of the first data flow and/or the data transmission channel of the first data flow, the first network device determines that the first data flow and/or the data transmission channel of the first data flow is configured to the first split bearer.
3. The method of claim 1, further comprising:
after sending the second message, the first network device receiving a third message sent by the second network device; the third message is sent by the second network device after the terminal device completes configuring the first split bearer, and is used for instructing the terminal device to complete configuring the first split bearer.
4. The method of claim 2, further comprising:
after sending the second message, the first network device receiving a third message sent by the second network device; the third message is sent by the second network device after the terminal device completes configuring the first split bearer, and is used for instructing the terminal device to complete configuring the first split bearer.
5. The method of any of claims 1-4, wherein the first message comprises: the second network device is used for address information of the first segmentation bearer.
6. The method of any of claims 1-4, wherein the second message comprises: the first network device is configured to use address information of the first split bearer.
7. The method of claim 5, wherein the second message comprises: the first network device is configured to use address information of the first split bearer.
8. The method of claim 6, wherein the second message comprises: the first network device is configured to use address information of the first split bearer.
9. The method of any of claims 1-4, 7, 8, wherein the first split bearer is a secondary cell group split bearer, the first network device is a secondary network node, and the second network device is a primary network node.
10. The method of claim 5, wherein the first split bearer is a secondary cell group split bearer, the first network device is a secondary network node, and the second network device is a primary network node.
11. The method of claim 6, wherein the first split bearer is a secondary cell group split bearer, the first network device is a secondary network node, and the second network device is a primary network node.
12. A data transmission method is applied to a second network device, and is characterized by comprising the following steps:
the second network equipment determines to configure a first data flow between the terminal equipment and a core network and/or a data transmission channel of the first data flow to a first segmentation bearer; the data distribution anchor point of the first split bearer is first network equipment, and the first split bearer is used for jointly transmitting data through the first network equipment and the second network equipment; the first network device is an auxiliary network device, and the second network device is a main network device; in the process of establishing the data transmission path of the first data flow, the characteristic information of the data transmission path of the first data flow and/or the characteristic information of the first data flow is obtained by the second network device, the characteristic information of the data transmission path of the first data flow includes the identifier and the QoS parameter of the data transmission path of the first data flow, and the characteristic information of the first data flow includes the identifier and the QoS parameter of the first data flow;
the second network device sends a first message to the first network device, wherein the first message is used for instructing the first network device to configure the first data flow and/or a data transmission channel of the first data flow to a first split bearer; the first message is further used for indicating the QoS capability of the second network equipment available for the first split bearer, the QoS requirement of the first data flow and/or the data transmission channel of the first data flow; wherein the QoS capability of the first network device, the QoS capability of the second network device available for the first split bearer, and the QoS requirement of the first data flow and/or the data transmission channel of the first data flow are used for the first network device to determine the QoS that the second network device needs to bear;
and the second network equipment receives a second message sent by the first network equipment, wherein the second message is used for confirming that the first data flow and/or a data transmission channel of the first data flow is configured to the first segmentation bearer, and is used for indicating the QoS required to be assumed by the second network equipment.
13. The method of claim 12, wherein the determining, by the second network device, to configure the first data flow and/or the data transmission channel of the first data flow to the first split bearer specifically includes:
if the data plane interface of the first data flow and/or the data transmission channel of the first data flow is connected to the second network device and the QoS capability of the second network device available for the first split bearer cannot meet the QoS requirement of the data transmission channel of the first data flow and/or the first data flow, the second network device determines to configure the data transmission channel of the first data flow and/or the first data flow to the first split bearer;
alternatively, the first and second electrodes may be,
the second network device determines to configure the first data flow and/or the data transmission channel of the first data flow to a first split bearer if a data plane interface of the first data flow and/or the data transmission channel of the first data flow is connected to the first network device.
14. The method of claim 12, wherein the first message comprises: the second network device is used for address information of the first segmentation bearer.
15. The method of claim 13, wherein the first message comprises: the second network device is used for address information of the first segmentation bearer.
16. The method of any of claims 12-15, wherein the second message comprises: the first network device is configured to use address information of the first split bearer.
17. The method of any one of claims 12-15, further comprising:
after receiving the second message, the second network device sends a configuration message of the first split bearer to a terminal device, wherein the configuration message is used for the terminal device to configure the first split bearer;
the second network equipment receives a configuration confirmation message returned by the terminal equipment; the configuration confirmation message is used for indicating that the terminal equipment has finished configuring the first segmentation bearer;
and the second network equipment sends a third message to the first network equipment, wherein the third message is used for indicating that the terminal equipment finishes configuring the first segmentation bearer.
18. The method of claim 16, further comprising:
after receiving the second message, the second network device sends a configuration message of the first split bearer to a terminal device, wherein the configuration message is used for the terminal device to configure the first split bearer;
the second network equipment receives a configuration confirmation message returned by the terminal equipment; the configuration confirmation message is used for indicating that the terminal equipment has finished configuring the first segmentation bearer;
and the second network equipment sends a third message to the first network equipment, wherein the third message is used for indicating that the terminal equipment finishes configuring the first segmentation bearer.
19. A network device, the network device being a first network device, comprising:
a receiving unit, configured to receive a first message sent by a second network device, where the first message is used to instruct to configure a first data flow between a terminal device and a core network and/or a data transmission channel of the first data flow to a first split bearer; the data distribution anchor point of the first split bearer is the first network device, and the first split bearer is used for jointly transmitting data through the first network device and the second network device; the first message is further used for indicating the QoS capability of the second network equipment available for the first split bearer, the QoS requirement of the first data flow and/or the data transmission channel of the first data flow; the first network device is an auxiliary network device, and the second network device is a main network device; in the process of establishing the data transmission path of the first data flow, the characteristic information of the data transmission path of the first data flow and/or the characteristic information of the first data flow is obtained by the second network device, the characteristic information of the data transmission path of the first data flow includes the identifier and the QoS parameter of the data transmission path of the first data flow, and the characteristic information of the first data flow includes the identifier and the QoS parameter of the first data flow;
a determining unit, configured to determine, after the receiving unit receives the first message, a QoS that needs to be assumed by the second network device according to the QoS capability of the first network device, the QoS capability of the second network device, and the QoS requirement of the data transmission channel of the first data flow and/or the first data flow;
a sending unit, configured to send a second message to the second network device, where the second message is used to confirm that the first data flow and/or the data transmission channel of the first data flow is configured to the first split bearer, and to indicate the QoS that needs to be assumed by the second network device.
20. The network device of claim 19, wherein the determining unit is specifically configured to determine that the first data flow and/or the data transmission channel of the first data flow is configured to the first split bearer if the QoS capabilities of the first network device and the QoS capabilities of the second network device available for the first split bearer satisfy the QoS requirements of the first data flow and/or the data transmission channel of the first data flow.
21. The network device of claim 19, wherein the receiving unit is further to: after the sending unit sends the second message, receiving a third message sent by the second network equipment; the third message is sent by the second network device after the terminal device completes configuring the first split bearer, and is used for instructing the terminal device to complete configuring the first split bearer.
22. The network device of claim 20, wherein the receiving unit is further to: after the sending unit sends the second message, receiving a third message sent by the second network equipment; the third message is sent by the second network device after the terminal device completes configuring the first split bearer, and is used for instructing the terminal device to complete configuring the first split bearer.
23. The network device of any one of claims 19-22, wherein the first message comprises: the second network device is used for address information of the first segmentation bearer.
24. The network device of any one of claims 19-22, wherein the second message comprises: the first network device is configured to use address information of the first split bearer.
25. The network device of claim 23, wherein the second message comprises: the first network device is configured to use address information of the first split bearer.
26. The network device of any one of claims 19-22, wherein the first split bearer is a secondary cell group split bearer, the first network device is a secondary network node, and the second network device is a primary network node.
27. The network device of any of claims 19-22, 25, wherein the first split bearer is a secondary cell group split bearer, the first network device is a secondary network node, and the second network device is a primary network node.
28. The network device of claim 23, wherein the first split bearer is a secondary cell group split bearer, the first network device is a secondary network node, and the second network device is a primary network node.
29. The network device of claim 24, wherein the first split bearer is a secondary cell group split bearer, the first network device is a secondary network node, and the second network device is a primary network node.
30. A network device, the network device being a second network device, comprising:
a determining unit, configured to determine that a first data flow between a terminal device and a core network and/or a data transmission channel of the first data flow are configured to a first split bearer; the data distribution anchor point of the first split bearer is first network equipment, and the first split bearer is used for jointly transmitting data through the first network equipment and the second network equipment; the first network device is an auxiliary network device, and the second network device is a main network device; in the process of establishing the data transmission path of the first data flow, the characteristic information of the data transmission path of the first data flow and/or the characteristic information of the first data flow is obtained by the second network device, the characteristic information of the data transmission path of the first data flow includes the identifier and the QoS parameter of the data transmission path of the first data flow, and the characteristic information of the first data flow includes the identifier and the QoS parameter of the first data flow;
a sending unit, configured to send a first message to the first network device, where the first message is used to instruct the first network device to configure the first data flow and/or a data transmission channel of the first data flow to the first split bearer; the first message is further used for indicating the QoS capability of the second network equipment available for the first split bearer, the QoS requirement of the first data flow and/or the data transmission channel of the first data flow; wherein the QoS capability of the first network device, the QoS capability of the second network device available for the first split bearer, and the QoS requirement of the first data flow and/or the data transmission channel of the first data flow are used for the first network device to determine the QoS that the second network device needs to bear;
a receiving unit, configured to receive, after the sending unit sends the first message, a second message sent by the first network device, where the second message is used to confirm that the first data flow and/or the data transmission channel of the first data flow is configured to the first split bearer, and is used to indicate QoS that the second network device needs to undertake.
31. The network device of claim 30, wherein the determining unit is specifically configured to:
determining to configure the first data flow and/or the data transmission channel of the first data flow to a first split bearer if a data plane interface of the first data flow and/or the data transmission channel of the first data flow is connected to the second network device and a QoS capability of the second network device available for the first split bearer cannot meet a QoS requirement of the first data flow and/or the data transmission channel of the first data flow;
alternatively, the first and second electrodes may be,
determining to configure the first data flow and/or the data transmission channel of the first data flow to a first split bearer if a data plane interface of the first data flow and/or the data transmission channel of the first data flow is connected to the first network device.
32. The network device of claim 30, wherein the first message comprises: the second network device is used for address information of the first segmentation bearer.
33. The network device of claim 31, wherein the first message comprises: the second network device is used for address information of the first segmentation bearer.
34. The network device of any one of claims 30-33, wherein the second message comprises: the first network device is configured to use address information of the first split bearer.
35. The network device of any one of claims 30-33,
the sending unit is further configured to send a configuration message of the first split bearer to a terminal device after the receiving unit receives the second message, where the configuration message is used for the terminal device to configure the first split bearer;
the receiving unit is further configured to receive a configuration confirmation message returned by the terminal device; the configuration confirmation message is used for indicating that the terminal equipment has finished configuring the first segmentation bearer;
the sending unit is further configured to send a third message to the first network device, where the third message is used to indicate that the terminal device has completed configuring the first split bearer.
36. The network device of claim 35,
the sending unit is further configured to send a configuration message of the first split bearer to a terminal device after the receiving unit receives the second message, where the configuration message is used for the terminal device to configure the first split bearer;
the receiving unit is further configured to receive a configuration confirmation message returned by the terminal device; the configuration confirmation message is used for indicating that the terminal equipment has finished configuring the first segmentation bearer;
the sending unit is further configured to send a third message to the first network device, where the third message is used to indicate that the terminal device has completed configuring the first split bearer.
37. A network device, the network device being a first network device, comprising: a transmitter, a receiver, and a processor, wherein:
the receiver is configured to receive a first message sent by a second network device, where the first message is used to instruct to configure a first data flow between a terminal device and a core network and/or a data transmission channel of the first data flow to a first split bearer; the data distribution anchor point of the first split bearer is the first network device, and the first split bearer is used for jointly transmitting data through the first network device and the second network device; the first message is further used for indicating the QoS capability of the second network equipment available for the first split bearer, the QoS requirement of the first data flow and/or the data transmission channel of the first data flow; the first network device is an auxiliary network device, and the second network device is a main network device; in the process of establishing the data transmission path of the first data flow, the characteristic information of the data transmission path of the first data flow and/or the characteristic information of the first data flow is obtained by the second network device, the characteristic information of the data transmission path of the first data flow includes the identifier and the QoS parameter of the data transmission path of the first data flow, and the characteristic information of the first data flow includes the identifier and the QoS parameter of the first data flow;
the processor is configured to determine, after the receiver receives the first message, a QoS that the second network device needs to bear according to the QoS capability of the first network device, the QoS capability of the second network device, and the QoS requirement of the data transmission channel of the first data flow and/or the first data flow;
the transmitter is configured to send a second message to the second network device, where the second message is used to confirm that the first data flow and/or the data transmission channel of the first data flow is configured to the first split bearer, and to indicate the QoS that needs to be assumed by the second network device.
38. A network device, the network device being a second network device, comprising: a transmitter, a receiver, and a processor, wherein:
the processor is configured to determine to configure a first data flow between a terminal device and a core network and/or a data transmission channel of the first data flow to a first split bearer; the data distribution anchor point of the first division bearer is first network equipment and is used for jointly transmitting data through the first network equipment and the second network equipment; the first network device is an auxiliary network device, and the second network device is a main network device; in the process of establishing the data transmission path of the first data flow, the characteristic information of the data transmission path of the first data flow and/or the characteristic information of the first data flow is obtained by the second network device, the characteristic information of the data transmission path of the first data flow includes the identifier and the QoS parameter of the data transmission path of the first data flow, and the characteristic information of the first data flow includes the identifier and the QoS parameter of the first data flow;
the transmitter is configured to send a first message to the first network device, where the first message is used to instruct the first network device to configure the first data stream and/or a data transmission channel of the first data stream to a first split bearer; the first message is further used for indicating the QoS capability of the second network equipment available for the first split bearer, the QoS requirement of the first data flow and/or the data transmission channel of the first data flow; wherein the QoS capability of the first network device, the QoS capability of the second network device available for the first split bearer, and the QoS requirement of the first data flow and/or the data transmission channel of the first data flow are used for the first network device to determine the QoS that the second network device needs to bear;
the receiver is configured to receive a second message sent by the first network device, where the second message is used to confirm that the first data flow and/or the data transmission channel of the first data flow is configured to the first split bearer, and is used to indicate the QoS that needs to be assumed by the second network device.
CN201810152265.1A 2017-08-29 2018-02-14 Data transmission method, related device and system Active CN109429267B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2018/101848 WO2019042205A1 (en) 2017-08-29 2018-08-23 Data transmission method, related apparatus, and system

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN201710758152 2017-08-29
CN2017107581521 2017-08-29
CN201810062950 2018-01-23
CN2018100629505 2018-01-23

Publications (2)

Publication Number Publication Date
CN109429267A CN109429267A (en) 2019-03-05
CN109429267B true CN109429267B (en) 2021-01-29

Family

ID=65514460

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810152265.1A Active CN109429267B (en) 2017-08-29 2018-02-14 Data transmission method, related device and system

Country Status (2)

Country Link
CN (1) CN109429267B (en)
WO (1) WO2019042205A1 (en)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111757397B (en) * 2019-03-28 2021-11-16 大唐移动通信设备有限公司 Method and device for forwarding data
CN110536346B (en) * 2019-05-16 2022-01-11 Oppo广东移动通信有限公司 Power consumption control method and device of terminal and storage medium
CN110677925B (en) * 2019-08-30 2021-08-20 华为技术有限公司 Method for processing radio bearer and terminal equipment
CN112825583B (en) * 2019-11-20 2022-08-30 中国电信股份有限公司 Method and device for positioning service quality problem and communication system
US20230319921A1 (en) * 2020-10-13 2023-10-05 Peng Cheng Protocol stacks and bearer modeling for rsu assisted uu connectivity

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015167546A1 (en) * 2014-04-30 2015-11-05 Hitachi, Ltd. Transmission control for bearer split under dual connectivity
CN105338572A (en) * 2014-06-23 2016-02-17 北京三星通信技术研究有限公司 Data distribution method and device for segmented bearing in double-connection
WO2016047904A1 (en) * 2014-09-25 2016-03-31 Lg Electronics Inc. Method for handling of data transmission and reception for senb related bearer release at a user equipment in a dual connectivity system and device therefor
CN106304411A (en) * 2015-05-15 2017-01-04 上海贝尔股份有限公司 The method and device of the up-link segmentation carrying in dual link system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015167546A1 (en) * 2014-04-30 2015-11-05 Hitachi, Ltd. Transmission control for bearer split under dual connectivity
CN105338572A (en) * 2014-06-23 2016-02-17 北京三星通信技术研究有限公司 Data distribution method and device for segmented bearing in double-connection
WO2016047904A1 (en) * 2014-09-25 2016-03-31 Lg Electronics Inc. Method for handling of data transmission and reception for senb related bearer release at a user equipment in a dual connectivity system and device therefor
CN106304411A (en) * 2015-05-15 2017-01-04 上海贝尔股份有限公司 The method and device of the up-link segmentation carrying in dual link system

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
QoS configuration for SCG split bearers;NOKIA et al.;《3GPP TSG-RAN WG3 meeting #97》;20170811;参见第2部分 *
SCG Split Bearer Support in Qptions R3-172235;SAMSUNG;《3GPP TSG-RAN WG3 NR AdHoc》;20170620;参见第2部分 *

Also Published As

Publication number Publication date
CN109429267A (en) 2019-03-05
WO2019042205A1 (en) 2019-03-07

Similar Documents

Publication Publication Date Title
US10925106B2 (en) Mobile communication system, control apparatus, base station, and user terminal supporting dual connectivity
US11576080B2 (en) Radio access network node, core network node, radio terminal, and methods therefor
CN109429267B (en) Data transmission method, related device and system
CN110383915B (en) Radio access network node, radio terminal, method thereof and non-transitory computer readable medium
KR101998016B1 (en) Method for controlling transmission of data
JP7043506B2 (en) Multi-technology aggregation architecture for long-term evolution communication systems
US20150215162A1 (en) System and Method of Radio Bearer Management for Multiple Point Transmission
KR102569090B1 (en) Signal transmission method, network device, and system
US11937319B2 (en) Integrity protection handling at the gNB-CU-UP
US20230189091A1 (en) Iab node configuration method and communication apparatus
US20220225209A1 (en) Data packet transmission method and apparatus
US10631215B2 (en) Method and apparatus for communicating with a wireless local area network in a mobile communication system
US20150296495A1 (en) Radio communication system and communication control method
US9699698B2 (en) Network controller within core network and method for connection with terminal by network controller
CN114026929A (en) F1 interface management method and device
EP3534662B1 (en) Bearer configuration method and related product
CN112566186B (en) Communication method and device
CN109803390B (en) Message and strategy sending method and device, storage medium and processor
CN115804241A (en) Wireless communication method, network node and device
RU2803196C1 (en) Data package transmission method and device
US20240073736A1 (en) Communication control method
RU2782866C2 (en) Architecture with aggregation of technologies for communication systems of long-term development standard
CN111406393A (en) Parameter adjusting method and related equipment

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant