CN111757347A

CN111757347A - Method and communication device for determining bearer type

Info

Publication number: CN111757347A
Application number: CN201910252564.7A
Authority: CN
Inventors: 彭文杰; 王瑞; 仇力炜; 胡星星
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-03-29
Filing date: 2019-03-29
Publication date: 2020-10-09
Anticipated expiration: 2039-03-29
Also published as: CN111757347B; WO2020200103A1

Abstract

The application provides a method and a communication device for determining a bearer type, so that a SN can more reasonably determine the bearer type of QoS or DRB, thereby improving the data transmission efficiency. Specifically, for a QoS flow established by a corresponding SDAP entity in the SN, or a DRB established by a corresponding PDCP entity in the SN, the SN may determine the bearer type of the QoS flow or the DRB according to whether the first message sent by the MN includes the assistance information.

Description

Method and communication device for determining bearer type

Technical Field

The present application relates to the field of communications, and more particularly, to a method and a communications apparatus for determining a bearer type.

Background

In a Dual Connectivity (DC) scenario, a primary node (MN) may determine bearer types of all bearers, and inform a Secondary Node (SN) after determining the bearer types of the bearers. And if the SN accepts the decision of the MN, generating corresponding configuration according to the bearer type indicated by the MN.

In order to improve the flexibility of the configuration of the SN, a bearer is established in the SN for a Service Data Adaptation Protocol (SDAP) entity, and the SN may determine the bearer type. However, if the bearer type of the bearer terminating at the SN is decided entirely by the SN, the following situation may arise: MN is highly loaded and thus tends to establish the entire bearer at the SN, avoiding the use of Master Cell Group (MCG), while SN may not be so loaded, and therefore the bearer type is determined to be split (split) bearer based on its own algorithm, i.e. a part of the data of the bearer is transmitted by the MCG and a part of the data is transmitted by the Secondary Cell Group (SCG). This may result in that the bearer type determined by the SN cannot adapt to the operation of the MN, which may affect data transmission.

Disclosure of Invention

The application provides a method for determining a bearer type, so that an auxiliary network device can more reasonably determine quality of service (QoS) or a bearer type of a Data Radio Bearer (DRB), thereby being beneficial to improving data transmission efficiency.

In a first aspect, a method for determining a bearer type is provided, where the method includes: the auxiliary network equipment receives a first message sent by the main network equipment; the secondary network device determines a bearer type of the first QoS flow based on whether the first message includes the assistance information.

The SDAP entity corresponding to the first QoS flow is established on the secondary network device, or a Packet Data Convergence Protocol (PDCP) corresponding to a bearer corresponding to the first QoS flow is established on the secondary network device. The bearer type includes an MCG bearer, an SCG bearer, or a split (split) bearer.

It should be understood that the bearer type of the first QoS flow may be understood as the bearer type of the bearer corresponding to the first QoS flow.

Based on the method, for the QoS flow established by the corresponding SDAP entity on the secondary network device, the primary network device may assist the secondary network to determine the bearer type of the QoS flow by whether the first message includes the secondary information, and accordingly, the secondary network device may reasonably determine the bearer type of the QoS flow according to whether the first message provided by the primary network device includes the secondary information, thereby ensuring the QoS requirement of the QoS flow as much as possible and improving the data transmission efficiency. Further, by setting a reasonable bearer type for the QoS flow, the problem of a long negotiation process between the secondary network device and the primary network device due to an inappropriate decision of the bearer type of the QoS flow by the secondary network device can also be avoided.

With reference to the first aspect, in some implementations of the first aspect, the first QoS flow is a Guaranteed Bit Rate (GBR) QoS flow, and the auxiliary information is a first GBR QoS parameter. The first GBR QoS parameter is a GBR QoS parameter provided by the main network device for the first QoS flow, or the first GBR QoS parameter is a GBR QoS parameter that the main network device can provide for the first QoS flow; and the secondary network device determines the bearer type of the first quality of service (QoS) flow according to whether the first message includes the secondary information, including: if the first message includes the auxiliary information, the auxiliary network device determines that the bearer type of the first QoS flow is an MCG bearer, an SCG bearer, or a split bearer; and/or if the first message does not include the auxiliary information, the secondary network device determines that the bearer type of the first QoS flow is an SCG bearer.

It should be understood that, if the primary network device carries the first GBR QoS parameter in the first message, it indicates that the primary network device allows the secondary network device to determine (or configure) the bearer type of the first QoS flow as the bearer type related to the MCG air interface resource, that is, an MCG bearer or a split bearer. Thus, in the case that the first GBR QoS parameter is carried in the first message, the secondary network device may determine (or configure) the bearer type of the first QoS flow as a bearer type related to an MCG air interface resource, that is, an MCG bearer or a split bearer. However, the bearer type of the first QoS flow that the secondary network device finally determines may be decided autonomously.

Based on the above technical solution, the primary network device may assist the secondary network device to determine the bearer type of the GBR QoS flow by whether the GBR QoS parameter provided by the primary network device for the GBR QoS flow is carried in the first message, and accordingly, the secondary network device may reasonably determine the bearer type of the GBR QoS flow according to whether the GBR QoS parameter provided by the primary network device for the GBR QoS flow is included in the first message provided by the primary network device.

In this application, optionally, the GBR QoS parameter may include one or more of an uplink Maximum Bit Rate (MBR), a downlink Maximum Bit Rate (MBR), an uplink GBR, and a downlink GBR. The meaning of these four parameters can be found in the prior art, and will not be described in detail here. It should be understood that the first GBR QoS parameter may be one or more of an uplink maximum bit rate, a downlink maximum bit rate, an uplink GBR, and a downlink GBR provided by the primary network device for the first QoS flow.

Further, the first message may also include a second GBR QoS parameter for the first QoS flow. The second GBRQoS parameter is a GBR QoS parameter of the first QoS flow received by the primary network device from the core network device.

Thus, the secondary network device may more reasonably determine the bearer type of the first QoS flow in conjunction with the second GBR QoS parameter.

With reference to the first aspect, in some implementations of the first aspect, the first QoS stream is a non-guaranteed bit rate (non-GBR) QoS stream, and the auxiliary information is an Aggregated Maximum Bit Rate (AMBR) and a first Protocol Data Unit (PDU) session (session) AMBR for a first User Equipment (UE). The first UE AMBR is an AMBR provided by a non-GBR QoS flow established by the auxiliary network equipment for a target UE by the main network equipment, the target UE is a UE corresponding to the first QoS flow, the first PDU session AMBR is an AMBR provided by a non-GBR QoS flow established by the auxiliary network equipment in a target PDU session by the main network equipment, and the target PDU session is a PDU session corresponding to the first QoS flow;

and the secondary network device determines the bearer type of the first quality of service (QoS) flow according to whether the first message includes the secondary information, including:

if the first message includes the first UE AMBR and the first PDU session AMBR, the secondary network device determines that the bearer type of the first QoS flow is the MCG bearer, the SCG bearer, or the split bearer; and/or

If the first message does not include the first UE AMBR and the first PDU session AMBR, the secondary network device determines that the bearer type of the first QoS flow is the SCG bearer; and/or

If the first message includes the first UE AMBR and does not include the first PDU session AMBR, the secondary network device determines that the bearer type of the first QoS flow is the MCG bearer, the SCG bearer, or the split bearer; and/or

If the first message includes the first PDU session AMBR and does not include the first UE AMBR, the secondary network device determines that the bearer type of the first QoS flow is the MCG bearer, the SCG bearer, or the split bearer.

Based on the above technical solution, the secondary network device may determine the bearer type of the first QoS flow according to whether the first message includes the auxiliary information.

It is to be understood that the basic idea of the above-described scheme is that in designing the format of the first message, the positions of two cells, i.e. the cell corresponding to the first UE AMBR and the cell corresponding to the first PDU session AMBR, can be reserved in the first message. However, during specific transmission, the master network device may not fill any one of the two cells or neither cell, thereby implementing the above four cases.

In another possible implementation, whether the first QoS flow can be configured to be a bearer type related to an air interface resource of the MCG depends on whether the secondary network device receives a first PDU session AMBR provided by the primary network device for a PDU session corresponding to the first QoS flow. Specifically, if the secondary network device receives the first PDU session AMBR provided by the primary network device for the PDU session corresponding to the first Qos flow, the secondary network device may consider that the bearer type of the first Qos flow is determined (or configured) as a bearer type related to an MCG air interface resource, that is, an MCG bearer or a separate bearer, that is, an MCG bearer, an SCG bearer, or a separate bearer; if not, the secondary network device determines that the bearer type of the first QoS flow is an SCG bearer.

It should be noted that, in the present application, a non-GBR QoS flow established in the secondary network device refers to a non-GBR QoS flow established in the secondary network device by a corresponding SDAP entity. Similarly, a non-GBR QoS flow established at the primary network device refers to a non-GBR QoS flow established at the primary network device by the corresponding SDAP entity. In addition, the non-GBR QoS flow in the PDU session represents the non-GBR QoS flow corresponding to the PDU session.

With reference to the first aspect, in certain implementations of the first aspect, the first QoS flow is a non-guaranteed bit rate non-GBR QoS flow, and the auxiliary information is a maximum bit rate UE AMBR aggregated for a first user equipment, where the first UE AMBR is an AMBR that is established by a non-GBR QoS flow of the secondary network device for a target UE by the primary network device and provided by the non-GBR QoS flow, and the target UE is a UE corresponding to the first QoS flow; and the secondary network device determines the bearer type of the first quality of service (QoS) flow according to whether the first message includes the secondary information, including: if the first message includes the auxiliary information, the auxiliary network device determines that the bearer type of the first QoS flow is the MCG bearer, the SCG bearer, or the split bearer; and/or if the first message does not include the auxiliary information, the auxiliary network device determines that the bearer type of the first QoS flow is the SCG bearer.

It should be understood that, if the primary network device carries the first UE AMBR in the first message, it indicates that the primary network device allows the secondary network device to determine (or configure) the bearer type of the first QoS flow as the bearer type related to the MCG air interface resource, that is, an MCG bearer or a split bearer. Thus, in the case that the first UE AMBR parameter is carried in the first message, the secondary network device may determine (or configure) the bearer type of the first QoS flow as a bearer type related to an MCG air interface resource, that is, an MCG bearer or a split bearer. However, the bearer type of the first QoS flow that the secondary network device finally determines may be decided autonomously.

Based on the above scheme, the secondary network device may reasonably determine the bearer type of the first QoS flow according to whether the first message includes the first UE AMBR.

With reference to the first aspect, in certain implementations of the first aspect, the first QoS flow is a non-guaranteed bit rate non-GBR QoS flow, and the auxiliary information is a first protocol data unit, PDU, session AMBR, where the first PDU session AMBR is an AMBR established by the primary network device for a target PDU session provided by the non-GBR QoS flow of the secondary network device, and the target PDU session is a PDU session corresponding to the first QoS flow; and the secondary network device determines the bearer type of the first quality of service (QoS) flow according to whether the first message includes the secondary information, including: if the first message includes the auxiliary information, the auxiliary network device determines that the bearer type of the first QoS flow is the MCG bearer, the SCG bearer, or the split bearer; and/or

If the first message does not include the auxiliary information, the auxiliary network device determines that the bearer type of the first QoS flow is the SCG bearer.

It should be understood that, if the primary network device carries the first PDU session AMBR in the first message, it indicates that the primary network device allows the secondary network device to determine (or configure) the bearer type of the first QoS flow as the bearer type related to the MCG air interface resource, that is, an MCG bearer or a split bearer. Thus, in the case that the first PDU session AMBR is carried in the first message, the secondary network device may determine (or configure) the bearer type of the first QoS flow as a bearer type related to an MCG air interface resource, that is, an MCG bearer or a split bearer. However, the bearer type of the first QoS flow that the secondary network device finally determines may be decided autonomously.

Based on the above scheme, the secondary network device may reasonably determine the bearer type of the first QoS flow according to whether the first message includes the first PDU session AMBR.

With reference to the first aspect, in certain implementations of the first aspect, the method may further include: the secondary network device sends bearer type indication information to the primary network device, where the bearer type indication information is used to indicate the bearer type of the first QoS flow determined by the secondary network device.

Optionally, the bearer type indication information may be explicit information, that is, the bearer type indication information is the bearer type of the first QoS flow, or the bearer type indication information is information of whether the bearer type of the first QoS flow relates to an MCG air interface resource. That is, the secondary network device explicitly informs the primary network device of the bearer type of the first QoS flow, or informs the primary network device whether the bearer type of the first QoS flow relates to an MCG air interface resource.

In addition, the bearer type indication information may be implicit information. For example, the bearer type indication information may be uplink transmission network layer (UL TNL) information that is allocated by the secondary network device for the bearer corresponding to the first QoS flow and receives uplink data. It should be understood that, if the bearer type indication information is the uplink transport network layer information, it indicates that the bearer type of the first QoS flow determined by the secondary network device is a bearer type related to an MCG air interface resource. Optionally, the uplink transport network layer information may include an Internet Protocol (IP) address and/or a Tunnel End Identifier (TEID).

It is further understood that the bearer type indication information may also indicate or include an identification of the first QoS flow or an identification of a bearer to which the first QoS flow corresponds.

With reference to the first aspect, in certain implementations of the first aspect, the method may further include: the auxiliary network equipment generates a modification application message, wherein the modification application message is used for applying for modifying the bearer type of the first bearer corresponding to the first QoS flow; and the auxiliary network equipment sends the modification application message to the main network equipment.

Based on the above technical solution, the secondary network device may trigger modification of the bearer type. Therefore, when the air interface state of the auxiliary network equipment side changes, the auxiliary network equipment can modify the bearing type into the bearing type more suitable for the air interface state of the auxiliary network equipment side.

With reference to the first aspect, in some implementation manners of the first aspect, the modification application message includes a bearer establishment list and a bearer deletion list, where the bearer establishment list includes an identifier of the first bearer and information indicating a bearer type that the first bearer needs to be modified, and the bearer deletion list includes the identifier of the first bearer.

Based on the above technical solution, the secondary network device may implement bearer type modification triggered by the secondary network device by carrying the same bearer identifier in the bearer establishment list and the bearer deletion list.

In a second aspect, a method for determining a bearer type is provided, where the method includes: the main network equipment generates a first message according to whether the auxiliary information is included in the first message or not; the primary network device sends the first message to a secondary network device, where the first message is used for the secondary network device to determine a bearer type of a first quality of service (QoS) flow, where a SDAP entity corresponding to the first QoS flow is established on the secondary network device, and the bearer type includes a primary cell group (MCG) bearer, a Secondary Cell Group (SCG) bearer, or a separate bearer.

With reference to the second aspect, in certain implementations of the second aspect, the first QoS flow is a guaranteed bit rate, GBR, QoS flow, the auxiliary information is a first GBR QoS parameter, and the first GBR QoS parameter is a GBR QoS parameter provided by the primary network device for the first QoS flow;

and if the first message includes the auxiliary information, the first message is used to indicate that the secondary network device is allowed to configure the bearer type of the first QoS flow to a bearer type related to an MCG air interface resource, where the bearer type related to the MCG air interface resource includes the MCG bearer or the detached bearer; and/or

If the first message does not include the auxiliary information, the first message is used to instruct the secondary network device to configure the bearer type of the first QoS flow as the SCG bearer.

With reference to the second aspect, in certain implementations of the second aspect, the first QoS flow is a non-guaranteed bit rate non-GBR QoS flow, and the auxiliary information is a first user equipment aggregation maximum bit rate UE AMBR and a first protocol data unit PDU session AMBR, where the first UE AMBR is an AMBR provided by a non-GBR QoS flow established by the primary network device at the secondary network device for a target UE, the target UE is a UE corresponding to the first QoS flow, the first PDU session AMBR is an AMBR provided by a non-GBR QoS flow established by the secondary network device in a target PDU session established by the primary network device for the target PDU session, and the target PDU session is a PDU session corresponding to the first QoS flow;

and if the first message includes the first UE AMBR and the first PDU session AMBR, the first message is used to indicate that the secondary network device is allowed to configure the bearer type of the first QoS flow as a bearer type related to MCG air interface resources; and/or

If the first message does not include the first UE AMBR and the first PDU session AMBR, the first message is used to instruct the secondary network device to configure the bearer type of the first QoS flow as the SCG bearer; and/or

If the first message includes the first UE AMBR and does not include the first PDU session AMBR, the first message is used to indicate that the secondary network device is allowed to configure the bearer type of the first QoS flow as a bearer type related to MCG air interface resources; and/or

If the first message includes the first PDU session AMBR and does not include the first UE AMBR, the first message is used to indicate that the secondary network device is allowed to configure the bearer type of the first QoS flow as a bearer type related to MCG air interface resources;

wherein the bearer type related to the MCG air interface resource includes the MCG bearer or the separate bearer.

With reference to the second aspect, in certain implementations of the second aspect, the first QoS flow is a non-guaranteed bit rate non-GBR QoS flow, and the auxiliary information is a first user equipment aggregated maximum bit rate UE AMBR, where the first UE AMBR is an AMBR provided by a non-GBR QoS flow established by the primary network device at the secondary network device for a target UE, and the target UE is a UE corresponding to the first QoS flow;

With reference to the second aspect, in some implementations of the second aspect, the first QoS flow is a non-guaranteed bit rate non-GBR QoS flow, the auxiliary information is a first protocol data unit, PDU, session AMBR, the first PDU session AMBR is an AMBR provided by a non-GBR QoS flow established at the secondary network device in a target PDU session by the primary network device, and the target PDU session is a PDU session corresponding to the first QoS flow;

With reference to the second aspect, in certain implementations of the second aspect, the method further includes: the primary network device receives bearer type indication information sent by the secondary network device, wherein the bearer type indication information is used for indicating the bearer type of the first QoS flow determined by the secondary network device; and the main network equipment determines the bearer type of the first QoS flow according to the bearer type indication information.

With reference to the second aspect, in some implementations of the second aspect, the bearer type indication information is uplink transport network layer information, which is allocated by the secondary network device for a bearer corresponding to the first QoS flow and used for receiving uplink data.

With reference to the second aspect, in certain implementations of the second aspect, the method further includes: the primary network device receives a modification application message sent by the secondary network device, wherein the modification application message is used for applying for modifying the bearer type of the first bearer corresponding to the first QoS flow; and the main network equipment sends a modification request message to the auxiliary network equipment, wherein the modification request message is used for indicating that the main network equipment agrees to modify the bearer type of the first bearer.

With reference to the second aspect, in some implementation manners of the second aspect, the modification application message includes a bearer establishment list and a bearer deletion list, where the bearer establishment list includes an identifier of the first bearer and information indicating a bearer type that the first bearer needs to be modified, and the bearer deletion list includes the identifier of the first bearer.

For specific details and advantageous effects of various implementations provided by the second aspect, reference may be made to the above description of various implementations of the first aspect, and details are not repeated in the second aspect.

In a third aspect, a method for determining a bearer type is provided, where the method includes: the auxiliary network equipment receives the suggestion information sent by the main network equipment; and the secondary network equipment determines the bearer type of the first QoS flow according to the proposal information. Wherein the suggestion information is used to indicate a bearer type of a first QoS flow suggested by the primary network device, and the meaning of the first QoS flow is as described above. The bearer type includes an MCG bearer, an SCG bearer, or a split bearer.

Specifically, the primary network device may suggest a bearer type for the first QoS flow to the secondary network device, and the secondary network device may determine the bearer type for the first QoS flow according to the suggestion of the primary network device.

Therefore, according to the method for determining the bearer type provided by the present application, the secondary network device may determine the bearer type of the QoS flow more reasonably according to the bearer type suggested by the primary network device.

It should be appreciated that the secondary network device may autonomously determine the bearer type for the first QoS flow. That is, the bearer type finally determined by the secondary network device may or may not be the bearer type suggested by the primary network device. For example, if the bearer type suggested by the primary network device is a split bearer, but the secondary network device can meet the QoS requirement of the first QoS flow, the secondary network device may determine the bearer type of the first QoS flow as an SCG bearer.

With reference to the third aspect, in certain implementations of the third aspect, the method may further include: the secondary network device sends bearer type indication information to the primary network device, where the bearer type indication information is used to indicate the bearer type of the first QoS flow determined by the secondary network device. Wherein the meaning of the bearer type indication information is as described above.

With reference to the third aspect, in some implementations of the third aspect, the method may further include: the auxiliary network equipment generates a modification application message, wherein the modification application message is used for applying for modifying the bearer type of the first bearer corresponding to the first QoS flow; and the auxiliary network equipment sends the modification application message to the main network equipment.

With reference to the third aspect, in some implementation manners of the third aspect, the modification application message includes a bearer establishment list and a bearer deletion list, where the bearer establishment list includes an identifier of the first bearer and information indicating a bearer type that the first bearer needs to be modified, and the bearer deletion list includes the identifier of the first bearer.

In a fourth aspect, a method for determining a bearer type is provided, where the method includes: the main network equipment generates suggestion information; the primary network device sends the advice information to the secondary network device. Wherein the suggestion information is used to indicate a bearer type of a first QoS flow suggested by the primary network device, and the meaning of the first QoS flow is as described above. The bearer type includes an MCG bearer, an SCG bearer, or a split bearer.

With reference to the fourth aspect, in certain implementations of the fourth aspect, the method may further include: the primary network device receives bearer type indication information sent by the secondary network device, wherein the bearer type indication information is used for indicating the bearer type of the first QoS flow determined by the secondary network device; and the main network equipment determines the bearer type of the first QoS flow according to the bearer type indication information.

Based on the above technical solution, the primary network device may obtain the bearer type of the first QoS flow determined by the secondary network device.

With reference to the fourth aspect, in some implementations of the fourth aspect, the bearer type indication information is uplink transport network layer information, which is allocated by the secondary network device for a bearer corresponding to the first QoS flow and used for receiving uplink data.

With reference to the fourth aspect, in certain implementations of the fourth aspect, the method further includes: the primary network device receives a modification application message sent by the secondary network device, wherein the modification application message is used for applying for modifying the bearer type of the first bearer corresponding to the first QoS flow; and the main network equipment sends a modification request message to the auxiliary network equipment, wherein the modification request message is used for indicating that the main network equipment agrees to modify the bearer type of the first bearer.

With reference to the fourth aspect, in some implementation manners of the fourth aspect, the modification application message includes a bearer establishment list and a bearer deletion list, where the bearer establishment list includes an identifier of the first bearer and information indicating a bearer type that the first bearer needs to be modified, and the bearer deletion list includes the identifier of the first bearer.

For specific details and advantageous effects of the various implementations provided by the fourth aspect, reference may be made to the above description of the various implementations of the third aspect, and details are not repeated in the fourth aspect.

In a fifth aspect, a method for determining a bearer type is provided, where the method includes: the auxiliary network equipment receives a first message sent by the main network equipment; the auxiliary network device determines a bearer type of a first Data Radio Bearer (DRB) according to whether the first message includes the auxiliary information.

Wherein, the PDCP entity corresponding to the first DRB is established on the secondary network device. It should be understood that the SDAP entity corresponding to the QoS corresponding to the first DRB is established on the secondary network device. The bearer type includes an MCG bearer, an SCG bearer, or a split (split) bearer.

According to the method for determining the bearer type provided by the application, for the DRB in which the corresponding PDCP entity is established on the secondary network device, the primary network device may assist the secondary network device to determine the bearer type of the DRB by determining whether the first message includes the auxiliary information, and accordingly, the secondary network device may reasonably determine the bearer type of the DRB according to whether the first message provided by the primary network device includes the auxiliary information, so that the QoS requirement of the DRB can be guaranteed as much as possible, and the data transmission efficiency is improved. Further, by setting a reasonable bearer type for the DRB, the problem of a long negotiation process between the secondary network device and the primary network device due to an inappropriate decision of the secondary network device on the bearer type of the DRB can also be avoided.

With reference to the fifth aspect, in some implementations of the fifth aspect, the auxiliary information is a first parameter, and the first parameter is a QoS parameter provided by the primary network device for the first DRB. And the secondary network device determines the bearer type of the first DRB according to whether the first message includes the secondary information, including: if the first message includes the auxiliary information, the auxiliary network device determines that the bearer type of the first DRB is an MCG bearer, an SCG bearer, or a split bearer; and/or if the first message does not include the auxiliary information, the secondary network device determines that the bearer type of the first DRB is an SCG bearer.

It should be understood that, if the primary network device carries the first parameter in the first message, it indicates that the primary network device allows the secondary network device to determine (or configure) the bearer type of the first DRB as a bearer type related to an MCG air interface resource, that is, an MCG bearer or a split bearer. Thus, under the condition that the first parameter is carried in the first message, the secondary network device may determine (or configure) the bearer type of the first DRB as a bearer type related to an MCG air interface resource, that is, an MCG bearer or a detached bearer. However, the bearer type of the first DRB finally determined by the secondary network device may be decided autonomously.

Based on the above technical solution, the primary network device may assist the secondary network device to determine the bearer type of the first DRB by determining whether the first message carries the QoS parameter provided by the primary network device for the first DRB, and accordingly, the secondary network device may reasonably determine the bearer type of the first DRB according to whether the first message provided by the primary network device includes the QoS parameter provided by the primary network device for the first DRB.

Optionally, the first parameter may include one or more of an upstream MBR, a downstream MBR, an upstream GBR, and a downstream GBR.

With reference to the fifth aspect, in some implementations of the fifth aspect, the method may further include: the secondary network device sends bearer type indication information to the primary network device, where the bearer type indication information is used to indicate the bearer type of the first DRB determined by the secondary network device.

Optionally, the bearer type indication information may be explicit information, that is, the bearer type indication information is the bearer type of the first DRB, or the bearer type indication information is information of whether the bearer type of the first DRB relates to an MCG air interface resource. That is, the secondary network device explicitly informs the main network device of the bearer type of the first DRB, or informs the main network device of whether the bearer type of the first DRB relates to an MCG air interface resource.

In addition, the bearer type indication information may be implicit information. For example, the bearer type indication information may be uplink transport network layer information, which is allocated by the secondary network device for the first DRB to receive uplink data. It should be understood that, if the bearer type indication information is the uplink transport network layer information, it indicates that the bearer type of the first DRB determined by the secondary network device is a bearer type related to an MCG air interface resource. Optionally, the upstream transport network layer information may include an IP address and/or a tunnel endpoint identification.

It should also be understood that the bearer type indication information may also indicate or include an identification of the first DRB.

With reference to the fifth aspect, in some implementations of the fifth aspect, the method may further include: the auxiliary network equipment generates a modification application message, wherein the modification application message is used for applying for modifying the bearer type of the first DRB; and the auxiliary network equipment sends the modification application message to the main network equipment.

With reference to the fifth aspect, in some implementation manners of the fifth aspect, the modification application message includes a bearer establishment list and a bearer deletion list, where the bearer establishment list includes an identifier of the first DRB and information indicating a bearer type that the first DRB needs to modify, and the bearer deletion list includes the identifier of the first bearer.

In a sixth aspect, a method for determining a bearer type is provided, where the method includes: the main network equipment generates a first message according to whether the auxiliary information is included in the first message or not; the master network device sends the first message to an auxiliary network device, where the first message is used for the auxiliary network device to determine a bearer type of a first DRB, where a PDCP entity corresponding to the first DRB is established on the auxiliary network device, and the bearer type includes a master cell group MCG bearer, an auxiliary cell group SCG bearer, or a separation bearer.

With reference to the sixth aspect, in some implementations of the sixth aspect, the auxiliary information is a first parameter, and the first parameter is a QoS parameter provided by the primary network device for the first DRB. And if the first message includes the auxiliary information, the first message is used to indicate that the secondary network device is allowed to configure the bearer type of the first DRB to a bearer type related to an MCG air interface resource, where the bearer type related to the MCG air interface resource includes the MCG bearer or the detached bearer; and/or, if the first message does not include the auxiliary information, the first message is used to instruct the secondary network device to configure the bearer type of the first DRB as the SCG bearer.

With reference to the sixth aspect, in certain implementations of the sixth aspect, the method further comprises: the primary network device receives bearer type indication information sent by the secondary network device, where the bearer type indication information is used to indicate a bearer type of the first DRB determined by the secondary network device; and the main network equipment determines the bearer type of the first DRB according to the bearer type indication information.

With reference to the sixth aspect, in some implementation manners of the sixth aspect, the bearer type indication information is uplink transport network layer information, which is allocated by the secondary network device for the first DRB to receive uplink data.

With reference to the sixth aspect, in certain implementations of the sixth aspect, the method further comprises: the primary network device receives a modification application message sent by the secondary network device, wherein the modification application message is used for applying for modifying the bearer type of the first DRB; and the main network device sends a modification request message to the auxiliary network device, wherein the modification request message is used for indicating that the main network device agrees to modify the bearer type of the first DRB.

With reference to the sixth aspect, in some implementations of the sixth aspect, the modify application message includes a bearer establishment list and a bearer deletion list, where the bearer establishment list includes an identifier of the first DRB and information indicating a bearer type that the first DRB needs to be modified, and the bearer deletion list includes the identifier of the first DRB.

For specific details and advantageous effects of the various implementations provided by the sixth aspect, reference may be made to the above description of the various implementations of the fifth aspect, and details are not repeated in the sixth aspect.

In a seventh aspect, a method for determining a bearer type is provided, where the method includes: the auxiliary network equipment receives the suggestion information sent by the main network equipment; and the secondary network equipment determines the bearer type of the first DRB according to the suggestion information. Wherein the suggestion information is used to indicate the bearer type of the first DRB suggested by the master network device, and the meaning of the first DRB is as described in the fifth aspect. The bearer type includes an MCG bearer, an SCG bearer, or a split bearer.

Specifically, the primary network device may suggest the bearer type of the first DRB to the secondary network device, and the secondary network device may determine the bearer type of the first DRB according to the suggestion of the primary network device.

Therefore, according to the method for determining the bearer type provided by the present application, the secondary network device may determine the bearer type of the DRB more reasonably according to the bearer type suggested by the primary network device.

It should be appreciated that the secondary network device may autonomously determine the bearer type of the first DRB. That is, the bearer type finally determined by the secondary network device may or may not be the bearer type suggested by the primary network device. For example, if the bearer type suggested by the primary network device is a split bearer, but the secondary network device can meet the QoS requirement of the first DRB, the bearer type of the first DRB may be determined as an SCG bearer.

With reference to the seventh aspect, in certain implementations of the seventh aspect, the method may further include: the secondary network device sends bearer type indication information to the primary network device, where the bearer type indication information is used to indicate the bearer type of the first DRB determined by the secondary network device. Wherein the meaning of the bearer type indication information is as described in the fifth aspect.

With reference to the seventh aspect, in some implementations of the seventh aspect, the method may further include: the auxiliary network equipment generates a modification application message, wherein the modification application message is used for applying for modifying the bearer type of the first DRB; and the auxiliary network equipment sends the modification application message to the main network equipment.

With reference to the seventh aspect, in some implementations of the seventh aspect, the modification application message includes a bearer establishment list and a bearer deletion list, where the bearer establishment list includes an identifier of the first DRB and information indicating a bearer type that the first DRB needs to be modified, and the bearer deletion list includes the identifier of the first DRB.

In an eighth aspect, a method for determining a bearer type is provided, where the method includes: the main network equipment generates suggestion information; the primary network device sends the advice information to the secondary network device. Wherein the suggestion information is used to indicate the bearer type of the first DRB suggested by the master network device, and the meaning of the first DRB is as described in the fifth aspect. The bearer type includes an MCG bearer, an SCG bearer, or a split bearer.

Therefore, according to the method for determining the bearer type provided by the application, the secondary network device can determine the bearer type of the DRB more reasonably according to the bearer type suggested by the primary network device.

With reference to the eighth aspect, in some implementations of the eighth aspect, the method may further include: the primary network device receives bearer type indication information sent by the secondary network device, where the bearer type indication information is used to indicate a bearer type of the first DRB determined by the secondary network device; and the main network equipment determines the bearer type of the first DRB according to the bearer type indication information.

With reference to the eighth aspect, in some implementation manners of the eighth aspect, the bearer type indication information is uplink transport network layer information, which is allocated by the secondary network device to the first DRB and used for receiving uplink data.

With reference to the eighth aspect, in certain implementations of the eighth aspect, the method further includes: the primary network device receives a modification application message sent by the secondary network device, wherein the modification application message is used for applying for modifying the bearer type of the first DRB; and the main network device sends a modification request message to the auxiliary network device, wherein the modification request message is used for indicating that the main network device agrees to modify the bearer type of the first DRB.

With reference to the eighth aspect, in some implementation manners of the eighth aspect, the modification application message includes a bearer establishment list and a bearer deletion list, where the bearer establishment list includes an identifier of the first DRB and information indicating a bearer type that the first bearer needs to be modified, and the bearer deletion list includes the identifier of the first DRB.

For specific details and advantageous effects of the various implementations provided by the eighth aspect, reference may be made to the above description of the various implementations of the seventh aspect, and details are not repeated in the eighth aspect.

In a ninth aspect, a method for modifying bearer types is provided, including: the auxiliary network equipment generates a request message for modification, wherein the request message is used for requesting for modifying the bearer type of the first bearer; and the auxiliary network equipment sends the modification application message to the main network equipment.

Specifically, when the secondary network device desires to modify the bearer type of the first bearer, the secondary network device may request to modify the bearer type of the first bearer by sending a modification application message to the primary network device.

Therefore, according to the method for modifying the bearer type provided by the present application, the secondary network device may trigger modification (or change) of the bearer type by sending a modification application message to the primary network device, and further may implement modification of the bearer type.

With reference to the ninth aspect, in some implementations of the ninth aspect, the modify application message includes a bearer establishment list and a bearer deletion list, the bearer establishment list includes an identifier of the first bearer and indication information (referred to as indication information for short) indicating a bearer type that the first bearer needs to be modified, and the bearer deletion list includes the identifier of the first bearer.

Optionally, the bearer deletion list may further include a current bearer type of the first bearer.

It should be understood that the bearer type that needs to be modified and indicated by the indication information is a new bearer type of the first bearer determined by the secondary network device. The current bearer type of the first bearer is the original bearer type of the first bearer. That is, the secondary network device desires to modify the first bearer from the original bearer type to the new bearer type.

The indication information may be an explicit bearer type, such as an MCG bearer, an SCG bearer, or a separate bearer. The indication information may also be implicit information, which may indicate a new bearer type for the first bearer. For example, the implicit information may be uplink transmission network layer (UL TNL) information, where the UL TNL information is transmission layer information that is allocated by the secondary network device for the first bearer and used for receiving uplink data sent by the primary network device, where the uplink data is uplink data of the first bearer received by the primary network device from the terminal device. It should be understood that, if the indication information is the uplink transport network layer information, it indicates that the new bearer type is a bearer type related to the MCG air interface resource, that is, an MCG bearer or a detached bearer.

The uplink transport network layer information may include an Internet Protocol (IP) address and a Tunnel End Identifier (TEID). It should be understood that the secondary network device may receive the uplink data of the first bearer sent by the primary network device according to the uplink transport network layer information.

With reference to the ninth aspect, in certain implementations of the ninth aspect, the method further includes: the secondary network device receives a modification request (request) message sent by the primary network device, wherein the modification request message is used for indicating that the primary network device agrees to modify the bearer type of the first bearer; the auxiliary network device sends a modification request acknowledgement (acknowledgement) message to the main network device, where the modification request acknowledgement message includes air interface Radio Resource Control (RRC) configuration, the air interface RRC configuration (note: air interface RRC configuration #1) is air interface RRC configuration generated by the auxiliary network device for a terminal device, and the air interface RRC configuration is used for the terminal device to configure the first bearer; and the secondary network equipment receives a modification confirmation message (confirm) sent by the primary network equipment, wherein the modification confirmation message is used for indicating that the modification of the bearer type of the first bearer is completed.

Specifically, after the primary network device receives the modification request from the secondary network device, the modification request message may be sent to the secondary network device, so as to inform the secondary network device that the primary network device receives the modification request from the secondary network device, and to request the secondary network device to generate a corresponding air interface RRC configuration for the first bearer. After the secondary network device generates a corresponding air interface RRC configuration #1 for the first bearer, the secondary network device sends the configuration to the primary network device through a modification request acknowledgement message. After receiving the modification request acknowledgement message, the master network device generates an air interface RRC configuration #2, and sends the air interface RRC configuration #1 and the air interface RRC configuration #2 to the terminal device together, thereby completing the configuration of the first bearer. Further, the primary network device informs the secondary network device that the primary network device has completed configuring the first bearer by sending a modification confirmation message to the secondary network device.

In this application, for example, if the original bearer type is a split bearer and the new bearer type is an SCG bearer, the secondary network device needs to generate a PDCP recovery configuration (i.e., an example of an air interface RRC configuration #1) for the terminal device, and instruct the PDCP entity of the first bearer to perform data recovery; the master network device needs to generate a configuration for the terminal device to delete the MCG Radio Link Control (RLC) bearer (i.e., an example of an air interface RRC configuration # 2). Or, if the original bearer type is an SCG bearer and the new bearer type is an MCG bearer, the secondary network device needs to generate a configuration for releasing the SCG RLC bearer for the terminal device (i.e., an example of an air interface RRC configuration #1), and the primary network device needs to generate a configuration for increasing the MCG RLC bearer for the terminal device (i.e., an example of an air interface RRC configuration # 2).

With reference to the ninth aspect, in certain implementations of the ninth aspect, the modification request message includes the uplink transport network layer information.

If the new bearer type of the first bearer is an MCG bearer or a split bearer, the primary network device may further carry the uplink transport network layer information in the modification request message. Or, if the indication information is uplink transmission network layer information, the primary network device may not carry the uplink transmission network layer information in the modification request message.

With reference to the ninth aspect, in some implementation manners of the ninth aspect, the modification application message further includes an air interface RRC configuration (note: air interface RRC configuration #1), where the air interface RRC configuration is configured to an RRC configuration generated by the auxiliary network device for a terminal device, and the air interface RRC configuration is used by the terminal device to configure the first bearer; and, the method further comprises: and the auxiliary network equipment receives a modification confirmation message sent by the main network equipment, wherein the modification confirmation message is used for indicating that the modification of the bearer type of the first bearer is completed.

In particular, the primary network device cannot reject the bearer modification request initiated by the secondary network device for the first bearer. At this time, the secondary network device may carry the air interface RRC configuration #1 in the modification application message. After receiving the air interface RRC configuration #1 sent by the secondary network device, the primary network device generates an air interface RRC configuration #2, and sends the air interface RRC configuration #1 and the air interface RRC configuration #2 to the terminal device together, thereby completing the configuration of the first bearer. Further, the primary network device informs the secondary network device that the primary network device has completed configuring the first bearer by sending a modification confirmation message to the secondary network device.

Optionally, if the original bearer type of the first bearer is an SCG bearer, and the new bearer type is an MCG bearer or a split bearer, the primary network device may further carry the uplink transport network layer information in the modification confirmation message. Or, if the indication information is uplink transport network layer information, the primary network device may not carry the uplink transport network layer information in the modification confirmation message.

In a tenth aspect, there is provided a method of modifying bearer types, comprising: the method comprises the steps that a main network device receives a modification application message sent by an auxiliary network device, wherein the modification application message is used for applying for modifying the bearing type of a first bearing; the primary network device sends a modification request message to the secondary network device. The modification request message is used to instruct the primary network device to grant the modification request of the secondary network device.

Specifically, when the secondary network device desires to modify the bearer type of the first bearer, the secondary network device may send a modification request message to the primary network device, and if the primary network device accepts the request of the secondary network device to modify the bearer type of the first bearer, send a modification request message to the secondary network device. Further, the secondary network device may implement a modification of the bearer type of the first bearer.

With reference to the tenth aspect, in some implementation manners of the tenth aspect, the modification application message includes a bearer establishment list and a bearer deletion list, the bearer establishment list includes an identifier of the first bearer and indication information (referred to as indication information for short) indicating a bearer type that the first bearer needs to be modified, and the bearer deletion list includes the identifier of the first bearer.

The uplink transport network layer information may include an Internet Protocol (IP) address and a Tunnel End Identifier (TEID), and the auxiliary network device may receive, according to the uplink transport network layer information, the uplink data of the first bearer sent by the main network device.

With reference to the tenth aspect, in certain implementations of the tenth aspect, the modification request message includes the uplink transport network layer information.

With reference to the tenth aspect, in certain implementations of the tenth aspect, the method may further include: the primary network device receives a modification request confirmation message sent by the secondary network device, where the modification request confirmation message includes an air interface RRC configuration, the air interface RRC configuration is an RRC configuration generated by the secondary network device for a terminal device, and the air interface RRC configuration is used by the terminal device to configure the first bearer; and the primary network device sends a modification confirmation message to the secondary network device, wherein the modification confirmation message is used for indicating that the modification of the bearer type of the first bearer is completed.

Based on the above technical solution, modification of the bearer type of the first bearer can be achieved.

In an eleventh aspect, a method for modifying bearer types is provided, including: receiving, by a primary network device, a modification application message sent by an auxiliary network device, where the modification application message is used to apply for modifying a bearer type of a first bearer, where the modification application message includes an air interface RRC configuration (written as air interface RRC configuration #1), where the air interface RRC configuration is an RRC configuration generated by the auxiliary network device for a terminal device, and the air interface RRC configuration is used by the terminal device to configure the first bearer; the primary network device sends a modification confirmation message to the secondary network device. The modification confirmation message is used for indicating that the modification of the bearer type of the first bearer is completed.

With reference to the eleventh aspect, in certain implementations of the eleventh aspect, the modify application message includes a bearer establishment list and a bearer deletion list, the bearer establishment list includes an identifier of the first bearer and indication information (referred to as indication information for short) indicating a bearer type that the first bearer needs to be modified, and the bearer deletion list includes the identifier of the first bearer.

In a twelfth aspect, a communication method is provided, which includes: the auxiliary network device receives time domain configuration information from the main network device; the auxiliary network equipment determines hybrid automatic repeat request (HARQ) offset (offset) according to the time domain configuration information; the secondary network device sends the first HARQ offset to a primary network device.

By adopting the communication method provided by the embodiment of the application, the SN can determine the first HARQ offset for the MN or the terminal by combining the running condition of the SN, so that the accuracy of uplink and downlink time domain allocation of the MN or the terminal equipment can be improved, and the communication quality is improved.

With reference to the twelfth aspect, in certain implementations of the twelfth aspect, the method further comprises: the auxiliary network equipment determines time division multiplexing mode configuration according to the time domain configuration information; and the auxiliary network equipment informs the terminal equipment of the time division multiplexing mode configuration, wherein the time division multiplexing mode configuration comprises the first HARQ offset.

Alternatively, the secondary network device may directly send the time division multiplexing mode configuration to the terminal device.

Optionally, the secondary network device may forward the time division multiplexing mode configuration to the terminal device through the primary network device.

Optionally, the first HARQ offset is 0.

Optionally, the determining, by the secondary network device, the first HARQ offset according to the time domain configuration information includes: and the auxiliary network equipment adjusts the first HARQ offset to 0 according to the time domain configuration information.

Optionally, the time domain configuration information includes a second HARQ offset, and the determining, by the secondary network device, the first HARQ offset according to the time domain configuration information includes: the secondary network device determines that the first HARQ offset is different from the second HARQ offset.

In a thirteenth aspect, a communication method is provided, the method comprising: the method comprises the steps that a main network device sends time domain configuration information to an auxiliary network device, wherein the time domain configuration information is used for the auxiliary network device to determine a first HARQ offset; the primary network device receives the first HARQ offset from the secondary network device.

With reference to the thirteenth aspect, in certain implementations of the thirteenth aspect, the method further includes: and the main network equipment adjusts the ratio of uplink and downlink subframes according to the first HARQ offset.

With reference to the thirteenth aspect, in certain implementations of the thirteenth aspect, the method further includes: the master network device receives the time division multiplexing mode configuration determined by the secondary network device from the secondary network device, wherein the time division multiplexing mode configuration comprises the first HARQ offset; and the main network equipment sends the time division multiplexing mode configuration to the terminal equipment. The secondary network device may send the time division multiplexing mode configuration to the primary network device in an RRC container mode, and the primary network device sends the RRC container including the time division multiplexing mode configuration to the terminal device.

In a fourteenth aspect, a communication apparatus is provided, which includes a transceiving unit, configured to receive a first message sent by a main network device; a processing unit, configured to determine a bearer type of a first quality of service QoS flow according to whether the first message includes auxiliary information, where a service data adaptation protocol, SDAP, entity corresponding to the first QoS flow is established on the communications apparatus, and the bearer type includes a master cell group MCG bearer, a secondary cell group SCG bearer, or a split bearer.

With reference to the fourteenth aspect, in certain implementations of the fourteenth aspect, the first QoS flow is a guaranteed bit rate, GBR, QoS flow, the auxiliary information is a first GBR QoS parameter, and the first GBR QoS parameter is a GBR QoS parameter provided by the primary network device for the first QoS flow;

and the processing unit is specifically configured to: if the first message includes the auxiliary information, determining that the bearer type of the first QoS flow is the MCG bearer, the SCG bearer or the separation bearer; and/or

If the first message does not include the auxiliary information, determining that the bearer type of the first QoS flow is the SCG bearer.

With reference to the fourteenth aspect, in certain implementations of the fourteenth aspect, the first QoS flow is a non-guaranteed bit rate non-GBR QoS flow, and the auxiliary information is a first user equipment aggregation maximum bit rate UE AMBR and a first protocol data unit PDU session AMBR, where the first UE AMBR is an AMBR that the main network equipment establishes a non-GBR QoS flow at the communication device for a target UE, the target UE is a UE corresponding to the first QoS flow, the first PDU session AMBR is an AMBR that the main network equipment establishes in a target PDU session, the AMBR is an AMBR provided in a non-GBR QoS flow at the communication device, and the target PDU session is a PDU session corresponding to the first QoS flow;

and the processing unit is specifically configured to:

if the first message includes the first UE AMBR and the first PDU session AMBR, determining that the bearer type of the first QoS flow is the MCG bearer, the SCG bearer, or the split bearer; and/or

If the first message does not include the first UE AMBR and the first PDU session AMBR, determining that the bearer type of the first QoS flow is the SCG bearer; and/or

If the first message includes the first UE AMBR and does not include the first PDU session AMBR, determining that the bearer type of the first QoS flow is the MCG bearer, the SCG bearer, or the split bearer; and/or

If the first message includes the first PDU session AMBR and does not include the first UE AMBR, determining that the bearer type of the first QoS flow is the MCG bearer, the SCG bearer, or the split bearer.

With reference to the fourteenth aspect, in certain implementations of the fourteenth aspect, the first QoS flow is a non-guaranteed bit rate non-GBR QoS flow, and the auxiliary information is a first user equipment aggregated maximum bit rate UE AMBR, where the first UE AMBR is an AMBR provided by a non-GBR QoS flow established at the communication apparatus by the primary network device for a target UE, and the target UE is a UE corresponding to the first QoS flow;

and the processing unit is specifically configured to:

if the first message includes the auxiliary information, determining that the bearer type of the first QoS flow is the MCG bearer, the SCG bearer or the separation bearer; and/or

With reference to the fourteenth aspect, in some implementations of the fourteenth aspect, the first QoS flow is a non-guaranteed bit rate non-GBR QoS flow, and the auxiliary information is a first protocol data unit, PDU, session AMBR, where the first PDU session AMBR is an AMBR that is established by the master network device for a target PDU session and provided by the non-GBR QoS flow of the communication apparatus, and the target PDU session is a PDU session corresponding to the first QoS flow;

and the processing unit is specifically configured to:

With reference to the fourteenth aspect, in some implementations of the fourteenth aspect, the transceiver unit is further configured to: sending bearer type indication information to the master network device, wherein the bearer type indication information is used for indicating the bearer type of the first QoS flow determined by the communication device.

With reference to the fourteenth aspect, in some implementations of the fourteenth aspect, the bearer type indication information is uplink transport network layer information, allocated by the communication device for the bearer corresponding to the first QoS flow, for receiving uplink data.

With reference to the fourteenth aspect, in some implementations of the fourteenth aspect, the processing unit is further configured to generate a modification application message, where the modification application message is used to apply for modifying a bearer type of a first bearer corresponding to the first QoS flow; the transceiver unit is further configured to: and sending the modification application message to the main network equipment.

With reference to the fourteenth aspect, in some implementation manners of the fourteenth aspect, the modification application message includes a bearer establishment list and a bearer deletion list, where the bearer establishment list includes an identifier of the first bearer and information indicating a bearer type that the first bearer needs to be modified, and the bearer deletion list includes the identifier of the first bearer.

In a fifteenth aspect, a communication device is provided, which includes a processing unit configured to generate a first message according to whether auxiliary information is included in the first message; a transceiver unit, configured to send the first message to an auxiliary network device, where the first message is used for the auxiliary network device to determine a bearer type of a first quality of service QoS flow, where a service data adaptation protocol SDAP entity corresponding to the first QoS flow is established on the auxiliary network device, and the bearer type includes a master cell group MCG bearer, an auxiliary cell group SCG bearer, or a separation bearer.

With reference to the fifteenth aspect, in certain implementations of the fifteenth aspect, the first QoS flow is a guaranteed bit rate, GBR, QoS flow, the assistance information is a first GBR QoS parameter, and the first GBR QoS parameter is a GBR QoS parameter provided by the communication device for the first QoS flow;

With reference to the fifteenth aspect, in certain implementations of the fifteenth aspect, the first QoS flow is a non-guaranteed bit rate non-GBR QoS flow, and the assistance information is a first user equipment aggregation maximum bit rate UE AMBR and a first protocol data unit PDU session AMBR, where the first UE AMBR is an AMBR that the communication device establishes for a target UE a non-GBR QoS flow provided at the secondary network equipment, the target UE is a UE corresponding to the first QoS flow, the first PDU session AMBR is an AMBR that the communication device establishes for a target PDU session an AMBR provided for the non-GBR QoS flow of the secondary network equipment, and the target PDU session is a PDU session corresponding to the first QoS flow;

With reference to the fifteenth aspect, in certain implementations of the fifteenth aspect, the first QoS flow is a non-guaranteed bit rate non-GBR QoS flow, and the assistance information is an aggregate maximum bit rate UE AMBR for a first user equipment, where the first UE AMBR is an AMBR provided by a non-GBR QoS flow established by the communication device at the secondary network equipment for a target UE, and the target UE is a UE corresponding to the first QoS flow;

With reference to the fifteenth aspect, in certain implementations of the fifteenth aspect, the first QoS flow is a non-guaranteed bit rate non-GBR QoS flow, the auxiliary information is a first protocol data unit, PDU, session AMBR, which is an AMBR provided by the communication device for a non-GBR QoS flow established in the secondary network device in a target PDU session, and the target PDU session is a PDU session corresponding to the first QoS flow;

With reference to the fifteenth aspect, in certain implementations of the fifteenth aspect, the transceiver unit is further configured to: receiving bearer type indication information sent by the secondary network device, where the bearer type indication information is used to indicate a bearer type of the first QoS flow determined by the secondary network device; the processing unit is further configured to determine a bearer type for the first QoS flow.

With reference to the fifteenth aspect, in certain implementations of the fifteenth aspect, the bearer type indication information is uplink transport network layer information, allocated by the secondary network device for a bearer corresponding to the first QoS flow, for receiving uplink data.

With reference to the fifteenth aspect, in certain implementations of the fifteenth aspect, the transceiver unit is further configured to: receiving a modification application message sent by the auxiliary network device, where the modification application message is used to apply for modifying a bearer type of a first bearer corresponding to the first QoS flow; sending a modification request message to the secondary network device, where the modification request message is used to indicate that the communication apparatus agrees to modify the bearer type of the first bearer.

With reference to the fifteenth aspect, in certain implementations of the fifteenth aspect, the modify application message includes a bearer establishment list and a bearer deletion list, where the bearer establishment list includes an identifier of the first bearer and information indicating a bearer type that the first bearer needs to be modified, and the bearer deletion list includes the identifier of the first bearer.

In a sixteenth aspect, a communication device is provided, which includes various units or units for performing the methods in the third to thirteenth aspects in any possible implementation manner of the third to thirteenth aspects.

In a seventeenth aspect, a communication apparatus is provided that includes a processor. The processor is coupled to the memory and is operable to execute the instructions in the memory to implement the method of any one of the possible implementations of the first to thirteenth aspects. Optionally, the communication device further comprises a memory. Optionally, the communication device further comprises an interface circuit, the processor being coupled to the interface circuit.

Alternatively, the interface circuit may be a transceiver, or an input/output interface.

Alternatively, the transceiver may be a transmit-receive circuit. Alternatively, the input/output interface may be an input/output circuit.

In an eighteenth aspect, there is provided a processor comprising: input circuit, output circuit and processing circuit. The processing circuit is configured to receive a signal through the input circuit and transmit a signal through the output circuit, so that the processor performs the method of any one of the possible implementations of the first to thirteenth aspects and the first to thirteenth aspects.

In a specific implementation process, the processor may be a chip, the input circuit may be an input pin, the output circuit may be an output pin, and the processing circuit may be a transistor, a gate circuit, a flip-flop, various logic circuits, and the like. The input signal received by the input circuit may be received and input by, for example and without limitation, a receiver, the signal output by the output circuit may be output to and transmitted by a transmitter, for example and without limitation, and the input circuit and the output circuit may be the same circuit that functions as the input circuit and the output circuit, respectively, at different times. The embodiment of the present application does not limit the specific implementation manner of the processor and various circuits.

In a nineteenth aspect, a processing apparatus is provided that includes a processor and a memory. The processor is configured to read instructions stored in the memory, and may receive a signal via the receiver and transmit a signal via the transmitter to perform the method of any one of the possible implementations of the first aspect to the thirteenth aspect.

Optionally, the number of the processors is one or more, and the number of the memories is one or more.

Alternatively, the memory may be integral to the processor or provided separately from the processor.

In a specific implementation process, the memory may be a non-transient memory, such as a Read Only Memory (ROM), which may be integrated on the same chip as the processor, or may be separately disposed on different chips.

It will be appreciated that the associated data interaction process, for example, sending the first message may be the process of outputting the first message from the processor and receiving the information may be the process of receiving the information by the processor. In particular, the data output by the processor may be output to a transmitter and the input data received by the processor may be from a receiver. The transmitter and receiver may be collectively referred to as a transceiver, among others.

The processing device in the above nineteenth aspect may be a chip, the processor may be implemented by hardware or may be implemented by software, and when implemented by hardware, the processor may be a logic circuit, an integrated circuit, or the like; when implemented in software, the processor may be a general-purpose processor implemented by reading software code stored in a memory, which may be integrated with the processor, located external to the processor, or stand-alone.

In a twentieth aspect, there is provided a computer program product comprising: a computer program (which may also be referred to as code, or instructions), which when executed, causes a computer to perform the method of any one of the possible implementations of the first to thirteenth aspects described above.

A twenty-first aspect provides a computer-readable medium storing a computer program (which may also be referred to as code or instructions) which, when run on a computer, causes the computer to perform the method of any one of the possible implementations of the first to thirteenth aspects.

In a twenty-second aspect, there is provided a communication system comprising a primary network device and a secondary network device as described above,

optionally, the communication system further includes a core network device, configured to send the QoS parameter to the primary network device.

Optionally, the communication system further comprises a terminal device.

Drawings

FIG. 1 is a schematic diagram of a communication system suitable for use in the present application;

fig. 2-5 are schematic diagrams of DC architectures suitable for use in the present application;

fig. 6 is a schematic diagram of multiple bearer types supported under a DC architecture;

fig. 7 is a schematic flow chart diagram of a method for determining a bearer type provided herein;

fig. 8 is a schematic flow chart diagram of another method of determining a bearer type provided herein;

fig. 9 is a schematic flow chart diagram of yet another method for determining a bearer type provided by the present application;

fig. 10 is a schematic flow chart diagram of yet another method of determining a bearer type provided by the present application;

fig. 11 is a schematic flow chart diagram of a method of modifying bearer types provided herein;

FIG. 12 is a schematic flow chart diagram of a communication method provided herein;

fig. 13 is a schematic structural diagram of a communication device provided in the present application;

fig. 14 is a schematic structural diagram of a network device provided in the present application.

Detailed Description

The technical solution in the present application will be described below with reference to the accompanying drawings.

The technical scheme of the embodiment of the application can be applied to various communication systems, for example: a global system for mobile communications (GSM) system, a Code Division Multiple Access (CDMA) system, a Wideband Code Division Multiple Access (WCDMA) system, a General Packet Radio Service (GPRS), a long term evolution (long term evolution, LTE) system, a LTE Frequency Division Duplex (FDD) system, a LTE Time Division Duplex (TDD), a Universal Mobile Telecommunications System (UMTS), a Worldwide Interoperability for Microwave Access (WiMAX) communication system, a fifth generation (5, 5) radio (NR) system, etc., a New Radio (NR) system, a fifth generation (5, 5) radio (G) system, a New Radio (NR) system, etc., or other new radio communication systems.

Terminal equipment in the embodiments of the present application may refer to user equipment, access terminals, subscriber units, subscriber stations, mobile stations, remote terminals, mobile devices, user terminals, wireless communication devices, user agents, or user devices. The terminal device may also be a cellular phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a Wireless Local Loop (WLL) station, a Personal Digital Assistant (PDA), a handheld device with wireless communication function, a computing device or other processing device connected to a wireless modem, a vehicle-mounted device, a wearable device, a terminal device in a future 5G network or a terminal device in a future evolved Public Land Mobile Network (PLMN), and the like, which are not limited in this embodiment.

The network device (primary network device or secondary network device) in the embodiments of the present application may be a device for communicating with the terminal device, the network device may be a Base Transceiver Station (BTS) in a global system for mobile communications (GSM) system or a Code Division Multiple Access (CDMA) system, a base station (NodeB, NB) in a Wideband Code Division Multiple Access (WCDMA) system, an evolved node b (eNB, eNodeB) in an LTE system, or a wireless controller in a Cloud Radio Access Network (CRAN) scenario, or the network device may be a relay station, an access point, a vehicle-mounted device, a wearable device, a network device in a PLMN network in which a network device in a future 5G network evolves in the future, and the like. The network devices in the 5G network may be, for example, a gNB or a transmission point (TRP). Or the network device in this embodiment may be composed of a Central Unit (CU) and a Distributed Unit (DU), where the CU may also be referred to as a control unit (control unit), and the protocol layers of the base station may be split by using a structure of CU-DU, a part of the functions of the protocol layers are placed in the CU for centralized control, and the rest or all of the functions of the protocol layers are distributed in the DU, and the DU is controlled by the CU for centralized control. ) Or network equipment in a PLMN network evolved in the future, and the embodiments of the present application are not limited.

In the embodiment of the present application, the terminal device or the network device (the primary network device or the secondary network device) includes a hardware layer, an operating system layer running on the hardware layer, and an application layer running on the operating system layer. The hardware layer includes hardware such as a Central Processing Unit (CPU), a Memory Management Unit (MMU), and a memory (also referred to as a main memory). The operating system may be any one or more computer operating systems that implement business processing through processes (processes), such as a Linux operating system, a Unix operating system, an Android operating system, an iOS operating system, or a windows operating system. The application layer comprises applications such as a browser, an address list, word processing software, instant messaging software and the like. Furthermore, the embodiment of the present application does not particularly limit the specific structure of the execution subject of the method provided by the embodiment of the present application, as long as the communication can be performed according to the method provided by the embodiment of the present application by running the program recorded with the code of the method provided by the embodiment of the present application, for example, the execution subject of the method provided by the embodiment of the present application may be a terminal device or a network device, or a functional unit capable of calling the program and executing the program in the terminal device or the network device.

In addition, various aspects or features of the present application may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques. The term "article of manufacture" as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. For example, computer-readable media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips, etc.), optical disks (e.g., Compact Disk (CD), Digital Versatile Disk (DVD), etc.), smart cards, and flash memory devices (e.g., erasable programmable read-only memory (EPROM), card, stick, or key drive, etc.). In addition, various storage media described herein can represent one or more devices and/or other machine-readable media for storing information. The term "machine-readable medium" can include, without being limited to, wireless channels and various other media capable of storing, containing, and/or carrying instruction(s) and/or data.

Fig. 1 is a schematic diagram of a communication system suitable for use in the present application. As shown in fig. 1, the communication system 100 may include at least two network devices, such as network device 110 and network device 120, and the communication system 100 may also include at least one terminal device, such as terminal device 130. Additionally, communication system 100 may also include at least one core network device, such as core network device 140. It should be understood that fig. 1 is only a schematic diagram, and other network devices, such as a wireless relay device and a wireless backhaul device, may also be included in the communication system. In addition, the embodiments of the present application do not limit the number of network devices and terminal devices included in the mobile communication system.

In fig. 1, terminal device 130 may connect network device 110 and network device 120 via an air interface, network device 110 may be connected to network device 120 via a wired or wireless connection, and network device 110 and network device 120 may be connected to core network device 140 via a wired connection. The core network device 140 may be a 4G core network device, or may be a 5G core network device. The network device 110 may be an LTE base station or an NR base station; network device 120 may be an LTE base station or an NR base station. The terminal device 130 may communicate with the network devices 110 and 120 by employing DC technology. One of network devices 110 and 120 is a MN and the other is a SN.

Among them, there are various combinations of DC:

(1) the core network is an Evolved Packet Core (EPC), the LTE base station serves as the MN, and the NR base station serves as the SN. Referring to fig. 2, at this time, the LTE base station and the NR base station may be connected through an X2 interface, and at least a control plane connection and a user plane connection may be provided; the LTE base station and the EPC can be connected through an S1 interface, at least control plane connection is provided, and user plane connection is provided; the NR base stations and the EPC may be connected via an S1-U interface, i.e. only a user plane connection may be available. At this time, the LTE base station may provide air interface resources for the UE through at least one LTE cell, and at this time, the at least one LTE cell is referred to as an MCG. Correspondingly, the NR base station may also provide an air interface resource for the UE through at least one NR cell, where the at least one NR cell is referred to as an SCG.

(2) The core network is a 5G core (5G core, 5GC), the LTE base station is used as MN, and the NR base station is used as SN. Referring to fig. 3, at this time, the LTE base station and the NR base station may be connected through an Xn interface, at least a control plane is connected, and a user plane may be connected; the LTE base station and the 5GC can be connected through an NG interface, at least a control plane is connected, and a user plane can be connected; the NR base stations and the 5GC may be connected via an NG-U interface, i.e., only a user plane connection may be available. At this time, the LTE base station may provide air interface resources for the UE through at least one LTE cell, and at this time, the at least one LTE cell is referred to as an MCG. Correspondingly, the NR base station may also provide an air interface resource for the UE through at least one NR cell, where the at least one NR cell is referred to as an SCG.

(3) When the core network is 5GC, the NR base station is used as MN, and the LTE base station is used as SN. Referring to fig. 4, at this time, the NR base station and the LTE base station may be connected through an Xn interface, at least a control plane is connected, and a user plane may be connected; the NR base station and the 5GC can be connected through an NG interface, at least a control plane is connected, and a user plane can be connected; there is an NG-U interface between the LTE station and the 5GC, i.e. there may only be a user plane connection. At this time, the NR base station may provide an air interface resource for the UE through at least one NR cell, and at this time, the at least one NR cell is referred to as an MCG. Correspondingly, the LTE base station may also provide air interface resources for the UE through at least one LTE cell, where the at least one LTE cell is referred to as an SCG.

(4) When the core network is 5GC, both MN and SN are NR base stations. Referring to fig. 5, the NR primary base station and the NR secondary base station may be connected through an Xn interface, and at least a control plane may be connected, and a user plane may also be connected; an NG interface exists between the NR main base station and the 5GC, at least a control plane is connected, and a user plane can be connected; there is an NG-U interface between the NR secondary base station and the 5GC, i.e., there can only be a user plane connection. At this time, the NR master base station may provide an air interface resource for the UE through at least one NR cell, and at this time, the at least one NR cell is referred to as an MCG. Correspondingly, the NR secondary base station may also provide an air interface resource for the UE through at least one NR cell, where the at least one NR cell is referred to as an SCG.

It should be understood that, in fig. 2 to fig. 5, an LTE base station is taken as an eNB, and an NR base station is taken as a gNB for example, but this should not limit the present application in any way.

As shown in fig. 6, the DC architecture supports multiple bearer types, including:

an MN terminated MCG bearer, i.e., an MCG bearer terminated at an MN;

the MN terminated SCG bearer, i.e. the SCG bearer terminated at the MN;

MN terminated split bearer, i.e. terminated at the split bearer of the MN;

SN terminated MCG bearer, i.e., MCG bearer terminated at SN;

the SN terminated SCG bearer, that is, the SCG bearer terminated at the SN;

SN terminated split bearer, i.e., a split bearer terminated at SN.

The MCG bearer refers to a bearer only related to MCG air interface resources, the SCG bearer refers to a bearer only related to SCG air interface resources, and the separate bearer refers to a bearer related to both MCG air interface resources and SCG air interface resources. The termination of the MN or at the MN means that a Packet Data Convergence Protocol (PDCP) entity is at the MN, and the termination of the SN or at the SN means that a PDCP entity is at the SN.

It should be understood that, in fig. 6, the MN RLC denotes a Radio Link Control (RLC) entity of the MN side. Accordingly, the SN RLC denotes an RLC entity of the SN side. MN MAC denotes a Media Access Control (MAC) entity of the MN side. Accordingly, the SN MAC denotes a MAC entity on the SN side.

In the prior art, the MN may determine bearer types of all bearers and inform the SN after determining the bearer types of the bearers. If the SN accepts the bearer type, a corresponding configuration is generated according to the bearer type indicated by the MN.

The flexibility of SN configuration is improved, and the SN can determine the bearer type aiming at the bearer established by the SDAP entity at the SN. However, if the SN determines the bearer type of the bearer terminated by the SN completely, the SN may not adapt to the operation of the MN, which may affect data transmission. Therefore, the SN is required to set the bearer type of the bearer established at the SN by the SDAP entity more reasonably.

In view of the above, the present application provides various methods for determining a bearer type. In one method, the SN may determine the bearer type of the QoS flow or the bearer type of the DRB more reasonably according to whether the MN provides the assistance information. In another method, the SN can more reasonably determine the bearer type of the QoS flow or the bearer type of the DRB according to the advice information provided by the MN. The suggested information may be the QoS flow of the SDAP entity at the SN or the bearer type of the DRB suggested by the MN.

It should be understood that the bearer type of the QoS flow described herein actually refers to the bearer type of the bearer corresponding to the QoS flow, or the bearer type of the bearer to which the QoS flow belongs.

It should be understood that the methods provided herein may be applied to, but are not limited to, the DC architectures shown in fig. 2-5. The method of the present application is explained below.

It should also be understood that, for ease of understanding, the method of the present application is mainly described below by taking the MN as the primary network device and the SN as the secondary network device as examples. It should be noted that, in practice, the operations performed by the MN may also be performed by a chip in the MN, and similarly, the operations performed by the SN may also be performed by a chip in the SN.

The first method provided by the application mainly comprises the following steps: the main network equipment generates a first message according to whether the auxiliary information is included in the first message or not; the primary network device sends the first message to the secondary network device. Accordingly, the secondary network device receives a first message sent by the primary network device and determines a bearer type for the QoS flow based on whether the first message includes the assistance information. And establishing the SDAP entity corresponding to the QoS flow on the secondary network equipment.

Based on the method, for the QoS flow established by the corresponding SDAP entity on the secondary network device, the primary network device may assist the secondary network to determine the bearer type of the QoS flow by whether the secondary information is included in the first message, and accordingly, the secondary network device may reasonably determine the bearer type of the QoS flow according to whether the secondary information is included in the first message provided by the primary network device. Therefore, the purpose that the auxiliary network equipment reasonably sets the bearing type of the QoS flow can be achieved. In addition, the problem of long negotiation process between the auxiliary network device and the main network device caused by the fact that the auxiliary network device is not appropriate for the bearer type decision of the QoS flow can be avoided. This method will be described in detail below with reference to fig. 7.

Fig. 7 illustrates an exemplary flow chart of a method 200 for determining a bearer type provided herein. The method 200 mainly includes S210 to S230. The respective steps will be explained below.

S210, the MN generates a first message according to whether the first message includes the auxiliary information.

The first message is used for the SN to determine a bearer type for the first QoS flow. Or, the result of whether the first message includes the assistance information, is used by the SN to determine the bearer type for the first QoS flow. That is, the SN may determine the bearer type for the first QoS flow based on whether the first message includes assistance information. The first QoS flow may be any QoS flow that the corresponding SDAP entity establishes on the SN. It should be understood that the SDAP entity corresponding to the first QoS flow is established at the SN, and it may also be understood that the PDCP entity corresponding to the bearer corresponding to the first QoS flow is established at the SN.

Among them, the bearer types described herein include an MCG bearer, an SCG bearer, or a split bearer. The MCG bearer and the split bearer are bearers related to MCG air interface resources. Or, the bearer related to the MCG air interface resource includes an MCG bearer or a separate bearer.

It should be appreciated that since the SDAP entity to which the first QoS flow corresponds is established on the SN, the bearer type of the first QoS flow is actually an SCG bearer terminated at the SN, an MCG bearer terminated at the SN, or a split bearer terminated at the SN.

For example, if the MN is capable of providing air interface resources for the first QoS flow, the MN may include the assistance information in the first message. For another example, if the MN cannot provide air interface resources for the first QoS flow, the MN may not include the assistance information in the first message. Wherein the air interface resource is used for providing a transmission bit rate of the first QoS flow.

S220, the MN sends a first message to the SN. Accordingly, the SN receives the first message.

S230, the SN determines the bearer type of the first QoS flow according to whether the first message includes the auxiliary information.

According to the method for determining the bearer type provided by the application, for the QoS flow established by the corresponding SDAP entity on the SN, the MN may assist the SN to determine the bearer type of the QoS flow by whether the first message includes the auxiliary information, and accordingly, the SN may reasonably determine the bearer type of the QoS flow according to whether the first message provided by the MN includes the auxiliary information. Therefore, the purpose of reasonably setting the bearing type of the QoS flow by the SN can be realized. And the problem of long negotiation process between the MN and the SN caused by the fact that the auxiliary network equipment is not suitable for the bearer type decision of the QoS flow can be avoided.

The following is a description of possible implementations of the present application. Wherein, the following manner one is for GBR QoS flows, and the manner two to four are for non-GBR QoS flows.

In a first mode

The first QoS flow is a GBR QoS flow and the auxiliary information is a first GBR QoS parameter. The first GBR QoS parameter is a GBR QoS parameter provided by the MN for the first QoS flow, or the first GBR QoS parameter is a GBR QoS parameter that the MN can provide for the first QoS flow.

In this scenario, if the first message includes the auxiliary information, the first message may indicate that the SN is allowed to configure the bearer type of the first QoS flow as a bearer type related to an MCG air interface resource; alternatively, if the first message includes the assistance information, the SN may consider configuring the first QoS flow as a bearer type involving MCG air interface resources. And/or, if the first message does not include the auxiliary information, the first message may indicate the SN to determine the bearer type of the first QoS flow as an SCG bearer; alternatively, if the first new message does not include the side information, the SN may configure the first QoS flow as an SCG bearer, or the SN may determine that the bearer type of the first QoS flow is an SCG bearer.

Correspondingly, S230 specifically includes: if the first message comprises the auxiliary information, the SN determines that the bearing type of the first QoS flow is MCG bearing, SCG bearing or separation bearing; if the first message does not include the auxiliary information, the SN determines that the bearer type of the first QoS flow is an SCG bearer.

Specifically, if the MN carries the first GBR QoS parameter in the first message, it indicates that the MN can provide the GBR QoS parameter for the first QoS flow, or the MN can allocate an MCG air interface resource to the first QoS flow, so that the SN may determine (or configure) the bearer type of the first QoS flow as a bearer type related to the MCG air interface resource, that is, an MCG bearer or a split bearer. That is, the SN may or may have an opportunity to determine the bearer type of the first QoS flow as an MCG bearer or a split bearer. However, the bearer type of the first QoS flow finally determined by the SN may be decided autonomously, for example, the bearer type of the first QoS flow finally determined by the SN may not be an MCG bearer or a split bearer, i.e., may be an SCG bearer. For example, if the SN is capable of providing the GBR QoS parameters required for the first QoS flow, the SN may determine that the bearer type of the first QoS flow is an SCG bearer. It should be understood that the GBR QoS parameters required for the first QoS flow have the same meaning as the second GBR QoS parameters described below.

In contrast, if the MN does not carry the first GBR QoS parameter in the first message, it indicates that the MN cannot provide the GBR QoS parameter for the first QoS flow, or the MN cannot allocate air interface resources related to MCG for the first QoS flow, so that the SN may determine the bearer type of the first QoS flow as an SCG bearer.

Based on the above technical solution, the MN may assist the SN to determine the bearer type of the GBR QoS flow by whether the first message carries the GBR QoS parameter provided by the MN for the GBR QoS flow, and accordingly, the SN may reasonably determine the bearer type of the GBR QoS flow according to whether the first message provided by the MN includes the GBR QoS parameter provided by the MN for the GBR QoS flow.

In the present application, the GBR QoS parameter may include one or more of an uplink maximum bit rate, a downlink maximum bit rate, an uplink GBR, and a downlink GBR. The meaning of these four parameters can be found in the prior art, and will not be described in detail here. It should be understood that the first GBR QoS parameter may be one or more of an uplink maximum bit rate, a downlink maximum bit rate, an uplink GBR, and a downlink GBR provided by the MN for the first QoS flow.

Optionally, in one example, the MN may also carry the second GBR QoS parameter for the first QoS flow in the first message.

The second GBR QoS parameter is the GBR QoS parameter of the first QoS flow received by the MN from the core network equipment. It should be understood that the second GBR QoS parameter may be one or more of an uplink maximum bit rate, a downlink maximum bit rate, an uplink GBR, and a downlink GBR of the first QoS flow received by the MN from the core network device. It is also understood that the second GBR QoS parameter may contain the same type of parameters as the first GBR QoS parameter. For example, the parameters included in the first GBR QoS parameter are the uplink maximum bit rate and the downlink maximum bit rate, and the parameters included in the second GBR QoS parameter may also be the uplink maximum bit rate and the downlink maximum bit rate. However, this is not limited in this application, for example, the type of the parameter included in the second GBR QoS parameter may be more than the type of the parameter included in the first GBR QoS parameter.

Accordingly, in S230, the SN may determine the bearer type of the first QoS flow in conjunction with the second GBR QoS parameter.

For example, if the value of the second GBR QoS parameter is greater than the value of the first GBR QoS parameter, it indicates that the SN is required to provide SCG air interface resources, and at this time, the SN may determine the bearer type of the first QoS flow as a separate bearer.

For another example, if the value of the second GBR QoS parameter is equal to the value of the first GBR QoS parameter, it indicates that the SN may not provide SCG air interface resources, and at this time, the SN may determine the bearer type of the first QoS flow as an MCG bearer.

The SN may also determine the bearer type for the first QoS flow in conjunction with its ability to provide GBR QoS parameters for the first QoS flow.

For example, although the first GBR QoS parameter is included in the first message, the SN may provide a GBR QoS parameter that is greater than a value of the second GBR QoS parameter, and the SN may determine the bearer type of the QoS flow as an SCG bearer.

Based on the above technical solution, the SN may combine with more information, for example, the GBR QoS parameter of the first QoS flow received by the MN from the core network device and/or the SN may provide the GBR QoS parameter for the first QoS flow, so as to determine the bearer type of the first QoS flow more reasonably.

In the above embodiment, when comparing the magnitude relationship between the value of the second GBR QoS parameter and the value of the first GBR QoS parameter, it is assumed that the types of parameters included in the second GBR QoS parameter and the first GBR QoS parameter are the same, and the same type of parameters are compared. When the second GBR QoS parameter and the first GBR QoS parameter contain multiple types of parameters, the meaning that the value of the second GBR QoS parameter is equal to the value of the second GBR QoS parameter is that the values of any parameters of the same type are the same; similarly, the fact that the value of the second GBR QoS parameter is equal to the value of the second GBR QoS parameter means that, for any parameter of the same type, the value of the parameter of the type in the second GBR QoS parameter is greater than the value of the parameter of the type in the first GBR QoS parameter; the meaning that the value of the second GBR QoS parameter is less than the value of the second GBR QoS parameter and equal is that, for any parameter of the same type, the value of the parameter of the type in the second GBR QoS parameter is less than the value of the parameter of the type in the first GBR QoS parameter.

For example, if the parameters included in the first GBR QoS parameter and the second GBR QoS parameter are both the uplink maximum bit rate and the downlink maximum bit rate, if the uplink maximum bit rate in the first GBR QoS parameter is equal to the uplink maximum bit rate in the second GBR QoS parameter, and the downlink maximum bit rate in the first GBR QoS parameter is equal to the downlink maximum bit rate in the second GBR QoS parameter, the value of the first GBR QoS parameter and the value of the second GBR QoS parameter are considered to be equal. And if the uplink maximum bit rate in the first GBR QoS parameter is greater than the uplink maximum bit rate in the second GBR QoS parameter, and the downlink maximum bit rate in the first GBR QoS parameter is greater than the downlink maximum bit rate in the second GBR QoS parameter, the value of the first GBR QoS parameter is considered to be greater than the value of the second GBR QoS parameter. And if the uplink maximum bit rate in the first GBR QoS parameter is less than the uplink maximum bit rate in the second GBR QoS parameter, and the downlink maximum bit rate in the first GBR QoS parameter is less than the downlink maximum bit rate in the second GBR QoS parameter, the value of the first GBR QoS parameter is considered to be less than the value of the second GBR QoS parameter.

Mode two

The first QoS flow is a non-GBR QoS flow, and the auxiliary information is a first UE AMBR and a first PDU session AMBR.

The AMBR of the first UE is provided for a non-GBR QoS flow established in SN by the MN for the target UE, and the target UE is the UE corresponding to the first QoS flow. That is, all non-GBR QoS flows of the target UE are composed of non-GBR QoS flows established at the MN (denoted as a first part of non-GBR QoS flows) and non-GBR QoS flows established at the SN (denoted as a second part of non-GBRQoS flows), and the first UE AMBR is the AMBR provided by the MN for the second part of non-GBR QoS flows. It should be understood that the second partial non-GBR QoS flow comprises the first QoS flow. The UE AMBR may include one or both of a UE downlink AMBR and a UE uplink AMBR.

The first PDU session AMBR is the AMBR provided by the MN for non-GBR QoS flows established at the SN in the target PDU session. Wherein the first QoS flow corresponds to a target PDU session, i.e., the non-GBR QoS flow established at the SN in the target PDU session comprises the first QoS flow. It should be understood that the non-GBR QoS flow established at the SN in the target PDU session is all or a portion of the second partial non-GBR QoS flow. The PDU session AMBR may include one or both of a PDU session downlink AMBR and a PDU session uplink AMBR.

It should be noted that, in the present application, a non-GBR QoS flow established in a SN refers to a non-GBR QoS flow established in a SN by a corresponding SDAP entity. Similarly, a non-GBR QoS flow at the MN refers to a non-GBRQoS flow at the MN established by the corresponding SDAP entity.

In the above scenario, there are four cases, which will be described in detail below.

Case 1

The first message (or the assistance information) includes a first UE AMBR and a first PDU session AMBR.

At this time, the first message may indicate that the SN is allowed to configure the bearer type of the first QoS flow as a bearer type related to MCG air interface resources. Or, if the first message includes the first UE AMBR and the first PDU session AMBR, the SN may consider configuring the first QoS flow as a bearer type related to an air interface resource of the MCG.

Correspondingly, S230 specifically includes: if the first message (or the auxiliary information) includes the first UE AMBR and the first PDU session AMBR, the SN determines that the bearer type of the first QoS flow is an MCG bearer, an SCG bearer, or a split bearer.

Specifically, if the MN carries the first UE AMBR and the first PDU session AMBR in the first message, it indicates that the MN can provide MCG air interface resources for the second part of non-GBR QoS flows including the first QoS flow, that is, the MN can provide MCG air interface resources for the non-GBR QoS flows including the first QoS flow. And, the MN can provide MCG air interface resources for the non-GBR QoS flow established in the SN in the target PDU session, and the non-GBR QoS flow established in the SN in the target PDU session also comprises the first QoS flow. The MN may allocate MCG air interface resources for the first QoS flow, so that the SN may determine (or configure) the bearer type of the first QoS flow as a bearer type related to the MCG air interface resources, that is, an MCG bearer or a split bearer. That is, the SN may be either allowed to determine the bearer type of the first QoS flow as an MCG bearer or a split bearer. However, the bearer type of the first QoS flow finally determined by the SN may not be an MCG bearer or a split bearer, i.e., may be an SCG bearer.

Case 2

The first message does not include the first UE AMBR and the first PDU session AMBR.

At this time, the first message may instruct the SN to determine the bearer type of the first QoS flow as an SCG bearer.

Correspondingly, S230 specifically includes: if the first message does not include the first UE AMBR and the first PDU session AMBR, the SN determines that the bearer type of the first QoS flow is SCG bearer.

Specifically, if the MN does not carry the first UE AMBR and the first PDU session AMBR in the first message, it indicates that the MN cannot provide MCG air interface resources for the second part of non-GBR QoS flows including the first QoS flow, so that the SN may consider determining the bearer type of the first QoS flow as the SCG bearer.

Case 3

The first message includes the first UE AMBR and does not include the first PDU session AMBR.

At this time, the first message may indicate that the SN is allowed to configure the bearer type of the first QoS flow as a bearer type related to MCG air interface resources.

Correspondingly, S230 specifically includes: if the first message includes the first UE AMBR and does not include the first PDU session AMBR, the SN determines that the bearer type of the first QoS flow is an MCG bearer, an SCG bearer, or a split bearer.

Specifically, if the MN carries the first UE AMBR in the first message, it indicates that the MN can provide MCG air interface resources for the second part of non-GBR QoS flows including the first QoS flow. At this time, although the MN does not carry the first PDU session AMBR in the first message, the first UE AMBR is applicable to the second part of non-GBR QoS flows including the first QoS flow, so at this time, the MN may also consider that the bearer type of the first QoS flow is determined (or configured) as a bearer type related to an MCG air interface resource, that is, an MCG bearer or a split bearer. However, the bearer type of the first QoS flow finally determined by the SN may not be an MCG bearer or a split bearer, i.e., may be an SCG bearer.

Case 4

The first message includes the first PDU session AMBR and does not include the first UE AMBR.

Correspondingly, S230 specifically includes: if the first message includes the first PDU session AMBR and does not include the first UEAMBR, the SN determines that the bearer type of the first QoS flow is an MCG bearer, an SCG bearer, or a split bearer.

Specifically, although the MN does not carry the first UE AMBR in the first message, the MN carries the first PDU session AMBR in the first message, which indicates that the MN can provide MCG air interface resources for the non-GBR QoS flow including the first QoS flow. Since the first QoS flow belongs to the target PDU session, the MN may guarantee the QoS requirements of the first QoS flow, so that the SN may consider determining (or configuring) the bearer type of the first QoS flow as the bearer type related to the MCG air interface resources. That is, the SN may or may have an opportunity to determine the bearer type of the first QoS flow as an MCG bearer or a split bearer. However, the bearer type of the first QoS flow finally determined by the SN may not be an MCG bearer or a split bearer, i.e., may be an SCG bearer.

In addition, for a non-GBR QoS flow that does not belong to the target PDU session, the SN may determine the bearer type of the non-GBR QoS flow as an SCG bearer, but the application is not limited thereto.

In summary, with the method in the second manner, the SN may determine the bearer type of the first QoS flow according to whether the first message includes the auxiliary information, and further according to the content included in the auxiliary information.

It should be understood that the basic idea of the second approach is that in designing the format of the first message, the positions of two cells, i.e. the cell corresponding to the first UE AMBR and the cell corresponding to the first PDU session AMBR, can be reserved in the first message. However, in a specific transmission, the MN may not fill either or both of the two cells, thereby realizing the meaning indicated in cases 1 to 4 above.

In another possible implementation manner, whether the first QoS flow can be configured to be a bearer type related to an air interface resource of the MCG depends on whether the SN receives a first PDU session AMBR provided by the MN for a target PDU session corresponding to the first QoS flow. Specifically, if the SN receives the first PDU session AMBR provided by the MN for the target PDU session corresponding to the first Qos flow, the SN may determine (or configure) the bearer type of the first Qos flow as a bearer type related to an MCG air interface resource, that is, an MCG bearer or a separate bearer, that is, an MCG bearer, an SCG bearer, or a separate bearer; if not, the SN may determine that the bearer type of the first QoS flow is an SCG bearer.

Mode III

The first QoS flow is a non-GBR QoS flow, and the auxiliary information is a first UE AMBR. The meaning of the AMBR of the first UE is described above and is not repeated.

In this scenario, if the first message includes the auxiliary information, the first message may indicate that the SN is allowed to configure the bearer type of the first QoS flow as the bearer type related to the MCG air interface resource; alternatively, if the first message includes the assistance information, the SN may consider configuring the first QoS flow as a bearer type involving MCG air interface resources. And/or, if the first message does not include the assistance information, the first message may indicate the SN to configure the bearer type of the first QoS flow as an SCG bearer.

Correspondingly, S230 specifically includes: if the first message includes the auxiliary information, the SN determines that the bearer type of the first QoS flow is an MCG bearer, an SCG bearer, or a split bearer. If the first message does not include the auxiliary information, the SN determines that the bearer type of the first QoS flow is an SCG bearer.

Specifically, if the MN carries the first UE AMBR in the first message, it indicates that the MN can provide MCG air interface resources for the second part of non-GBR QoS flows including the first QoS flow. Thus, the SN may consider determining (or configuring) the bearer type of the first QoS flow as a bearer type that involves MCG air interface resources. That is, the SN may or may have an opportunity to determine the bearer type of the first QoS flow as an MCG bearer or a split bearer. However, the bearer type of the first QoS flow finally determined by the SN may not be an MCG bearer or a split bearer, i.e., may be an SCG bearer.

In contrast, if the MN does not carry the first UE AMBR in the first message, it indicates that the MN cannot provide MCG air interface resources for the second part of non-GBR QoS flows including the first QoS flow, and thus the SN may consider that the bearer type of the first QoS flow is determined as an SCG bearer.

In summary, by the method of the third embodiment, the SN may reasonably determine the bearer type of the first QoS flow according to whether the first message includes the auxiliary information.

Mode IV

The first QoS flow is a non-GBR QoS flow, and the auxiliary information is a first PDU session AMBR. The meaning of the first PDU session AMBR is described above and is not described in detail.

Correspondingly, S230 specifically includes: if the first message includes the auxiliary information, the SN determines that the bearer type of the first QoS flow is an MCG bearer, an SCG bearer, or a split bearer. And/or if the first message does not include the auxiliary information, the SN determines that the bearer type of the first QoS flow is an SCG bearer.

Specifically, if the MN carries the first PDU session AMBR in the first message, it indicates that the MN can provide an MCG air interface resource for a non-GBR QoS flow established in the SN in the target PDU session, so that the SN may determine (or configure) the bearer type of the first QoS flow as the bearer type related to the MCG air interface resource. That is, the SN may or may have an opportunity to determine the bearer type of the first QoS flow as an MCG bearer or a split bearer. However, the bearer type of the first QoS flow finally determined by the SN may not be an MCG bearer or a split bearer, i.e., may be an SCG bearer.

In contrast, if the MN does not carry the first PDU session AMBR in the first message, it indicates that the MN cannot provide MCG air interface resources for the non-GBR QoS flow established in the SN in the target PDU session, so that the SN may determine that the bearer type of the first QoS flow is an SCG bearer.

In summary, by the method of the fourth mode, the SN may reasonably determine the bearer type of the first QoS flow according to whether the first message includes the auxiliary information.

Optionally, in an example, the MN may also carry the second UE AMBR and/or the second PDU session AMBR of the first QoS flow in the first message.

Wherein the second UE AMBR may be determined by the MN from the UE AMBR received from the core network device. The second PDU session AMBR may be determined by the MN from the PDU session AMBR received from the core network device. The second UE AMBR is the AMBR that the SN needs to provide for the second part of non-GBR QoS flows. The second PDU session AMBR is the AMBR that the SN needs to provide for non-GBR QoS flow in the target PDCP entity.

Accordingly, the SN may determine the bearer type of the first QoS flow in conjunction with the second UE AMBR and/or the second PDU session AMBR at S230.

For example, if the first UE AMBR is equal to the second UE AMBR, the SN may determine the bearer type of the first QoS flow as an MCG bearer. Alternatively, if the first PDU session AMBR is equal to the second PDU session AMBR, the SN may determine the bearer type of the first QoS flow as an MCG bearer.

For another example, if the first UE AMBR is smaller than the second UE AMBR, the SN may determine the bearer type of the first QoS flow as a split bearer. Or, if the first PDU session AMBR is smaller than the second PDU session AMBR, the SN may determine the bearer type of the first QoS flow as a split bearer.

It should be understood that the meaning of the size relationship between the first UE AMBR and the second UE AMBR, and the meaning of the size relationship between the first PDU session AMBR and the second PDU session AMBR are similar to the meaning of the size relationship between the first GBR QoS parameter and the second GBR QoS parameter, and are not repeated herein.

Optionally, as another implementation manner, if the first message includes the auxiliary information, but the value of the auxiliary information is 0, this is equivalent to a scheme that the first message does not include the auxiliary information.

Optionally, the method may further include:

s240, the SN sends bearer type indication information to the MN. Accordingly, the MN receives the bearer type indication information sent by the SN.

S250, the MN determines the bearing type of the first QoS flow according to the bearing type indication information.

Wherein the bearer type indication information is used for indicating the bearer type of the first QoS flow determined by the SN.

Specifically, after determining the bearer type of the first QoS flow, the SN may inform the MN of the determined bearer type of the first QoS flow through the bearer type indication information. Thus, the MN can determine the bearer type of the first QoS flow according to the bearer type indication information.

Optionally, the bearer type indication information may be explicit information, that is, the bearer type indication information is the bearer type of the first QoS flow, or the bearer type indication information is information of whether the bearer type of the first QoS flow relates to an MCG air interface resource. That is, the SN explicitly informs the MN of the bearer type of the first QoS flow, or informs the MN whether the bearer type of the first QoS flow relates to MCG air interface resources.

In addition, the bearer type indication information may be implicit information. For example, the bearer type indication information may be uplink transport network layer (UL TNL) information that is allocated by the SN for the bearer corresponding to the first QoS flow and receives uplink data. Optionally, the uplink transport network layer information may include an Internet Protocol (IP) address and/or a Tunnel End Identifier (TEID).

It should be understood that, if the bearer type indication information is the uplink transport network layer information, it indicates that the bearer type of the first QoS flow determined by the SN is a bearer type related to an MCG air interface resource. In this case, the MN may generate the RLC configuration and the logical channel configuration for the first QoS flow or a bearer corresponding to the first QoS flow. For details on how to generate the RLC configuration and the logical channel configuration, reference may be made to the prior art, and details are not described here.

It should be understood that the bearer type indication information may also indicate or include an identification of the first QoS flow or an identification of a bearer to which the first QoS flow corresponds.

In view of the foregoing problems in the prior art, the present application also provides three other methods for determining a bearer type. The following description will be made with reference to fig. 8 to 10, respectively.

Fig. 8 illustrates an exemplary flow chart of another method 300 for determining a bearer type provided herein. The method 300 mainly includes S310 to S330. The respective steps will be explained below.

S310, the MN generates advice information. Wherein the suggestion information is used for indicating the bearer type of the first QoS flow suggested by the MN. The definition of the first QoS flow is the same as that of the first QoS flow in the method 200, and is not described herein again.

S320, the MN sends the advice information to the SN. Accordingly, the SN receives the advice information sent by the MN.

S330, the SN determines the bearing type of the first QoS flow according to the proposal information.

Specifically, the MN can suggest the bearer type of the first QoS flow to the SN, and the SN can determine the bearer type of the first QoS flow according to the suggestion of the MN.

Therefore, according to the method for determining the bearer type provided by the application, the SN can determine the bearer type of the QoS flow more reasonably according to the bearer type suggested by the MN.

It should be appreciated that the SN may autonomously determine the bearer type for the first QoS flow. That is, the bearer type finally determined by the SN may or may not be the bearer type suggested by the MN. For example, if the bearer type suggested by the MN is a split bearer, but the SN can satisfy the QoS requirement of the first QoS flow, the bearer type of the first QoS flow may be determined as an SCG bearer.

Optionally, the method may further include:

s340, the SN sends bearer type indication information to the MN. Accordingly, the MN receives the bearer type indication information sent by the SN.

S350, the MN determines the bearing type of the first QoS flow according to the bearing type indication information.

Specifically, after determining the bearer type of the first QoS flow, the SN may notify the network device of the determined bearer type of the first QoS flow through the bearer type indication information. Thus, the network device may determine the bearer type of the first QoS flow according to the bearer type indication information.

For S340 and S350, reference may be specifically made to descriptions of S240 and S250 in the method 200, and details are not described here.

The method of determining the bearer type for a QoS flow is described above in connection with fig. 7 and 8. The method for determining the bearer type of the DBR is described in detail below with reference to fig. 9 and 10.

Fig. 9 illustrates an exemplary flow chart of yet another method 400 for determining a bearer type provided herein. The method 400 mainly includes S410 to S430. The respective steps will be explained below.

S410, the MN generates a first message according to whether the first message includes the auxiliary information.

The first message is used for the SN to determine the bearer type of the first DRB. Or, the result of whether the first message includes the assistance information, is used for the SN to determine the bearer type of the first DRB. That is, the SN may determine the bearer type of the first DRB according to whether the first message includes the assistance information. The first DRB may be any DRB that the corresponding PDCP entity establishes on the SN.

For example, if the MN can provide air interface resources for the first DRB, the MN may include the assistance information in the first message. For another example, if the MN cannot provide air interface resources for the first DRB, the MN may not include the assistance information in the first message. Wherein the air interface resource is used for providing the transmission bit rate of the first DRB.

S420, the MN sends the first message to the SN. Accordingly, the SN receives the first message sent by the MN.

S430, the SN determines the bearer type of the first DRB according to whether the first message includes the auxiliary information.

According to the method for determining the bearer type provided by the application, for the DRB established on the SN by the corresponding PDCP entity, the MN may assist the SN to determine the bearer type of the DRB by whether the first message includes the auxiliary information, and accordingly, the SN may reasonably determine the bearer type of the DRB according to whether the first message provided by the MN includes the auxiliary information. Therefore, the purpose of reasonably setting the bearer type of the DRB by the SN can be realized, and the problem of longer protocol process caused by inappropriate decision of the SN on the bearer type of the DRB in the prior art can be further avoided.

In a possible implementation manner, the auxiliary information is a first parameter, and the first parameter is a QoS parameter provided by the MN for the first DRB. Optionally, the QoS parameter may include one or more of an uplink MBR, a downlink MBR, an uplink GBR, and a downlink GBR.

In this scenario, if the first message includes the assistance information, the first message may indicate that the SN is allowed to configure the bearer type of the first DRB as the bearer type related to the MCG air interface resource. Or, if the first message includes the assistance information, the SN may consider configuring the first DRB as a bearer type related to an air interface resource of the MCG. And/or, if the first message does not include the assistance information, the first message may instruct the SN to determine the bearer type of the first DRB as the SCG bearer.

Correspondingly, S430 specifically includes: if the first message comprises the auxiliary information, the SN determines that the bearing type of the first DRB is MCG bearing, SCG bearing or separated bearing; if the first message does not include the auxiliary information, the SN determines that the bearer type of the first DRB is an SCG bearer.

Specifically, if the MN carries the first parameter in the first message, it indicates that the MN can provide the QoS parameter for the first DRB, or indicates that the MN can allocate an air interface resource related to an MCG to the first DRB, so that the SN may determine (or configure) the bearer type of the first DRB as the bearer type related to the air interface resource of the MCG, that is, an MCG bearer or a split bearer. That is, the SN may or may have an opportunity to determine the bearer type of the first DRB as an MCG bearer or a split bearer. However, the bearer type of the first DRB finally determined by the SN may not be an MCG bearer or a split bearer, i.e., may be an SCG bearer. For example, if the SN can provide the QoS parameter required by the first DRB for the first DRB, it may be determined that the bearer type of the first DRB is an SCG bearer.

In contrast, if the MN does not carry the first parameter in the first message, it indicates that the MN cannot allocate an air interface resource related to the MCG to the first DRB, so that the SN may determine the bearer type of the first DRB as the SCG bearer.

Based on the above technical solution, the MN may assist the SN to determine the bearer type of the first DRB by determining whether the first message carries the QoS parameter provided by the MN for the DRB, and accordingly, the SN may reasonably determine the bearer type of the first DRB according to whether the first message provided by the MN includes the QoS parameter provided by the MN for the first DRB.

Optionally, the method may further include:

s440, the SN sends bearer type indication information to the MN. Accordingly, the MN receives the bearer type indication information sent by the SN.

S450, the MN determines the bearing type of the first DRB according to the bearing type indication information.

Wherein, the bearer type indication information is used for indicating the bearer type of the first DRB determined by the SN.

Specifically, after determining the bearer type of the first DRB, the SN may inform the MN of the determined bearer type of the first DRB through the bearer type indication information. Thus, the MN can know the bearer type of the first DRB determined by the SN.

Optionally, the bearer type indication information may be explicit information, that is, the bearer type indication information is the bearer type of the first DRB, or the bearer type indication information is information of whether the bearer type of the first DRB relates to an MCG air interface resource. That is, the SN explicitly informs the MN of the bearer type of the first DRB, or informs the MN of whether the bearer type of the first DRB relates to an MCG air interface resource.

In addition, the bearer type indication information may be implicit information. For example, the bearer type indication information may be uplink transport network layer information that is allocated by the SN for the first DRB to receive uplink data. The uplink transport network layer information may include an Internet Protocol (IP) address and a Tunnel End Identifier (TEID), and the SN may receive the uplink data of the first DRB sent by the MN according to the uplink transport network layer information.

It should be understood that, if the bearer type indication information is the transport layer information, the bearer type of the first DRB determined by the SN is a bearer type related to an MCG air interface resource. In this case, the MN may generate an RLC entity and logical channel configuration for the first DRB.

It should be understood that the bearer type indication information may also include or indicate an identity of the first DRB.

Fig. 10 illustrates an exemplary flow chart of another method 500 for determining a bearer type provided herein. The method 500 generally includes S510 to S530. The respective steps will be explained below.

S510, the MN generates suggestion information. Wherein the suggestion information is used for indicating the bearer type of the first DRB suggested by the MN. The definition of the first DRB is the same as that of the first DRB in the method 400, and is not described herein again.

For example, the MN may generate the recommendation information according to whether it can provide an air interface resource for the first DRB. Wherein the air interface resource is used for providing the transmission bit rate of the first DRB. For example, if the MN can provide air interface resources for the first DRB, the SN may be suggested to determine the bearer type as a split bearer or an MCG bearer. For another example, if the MN cannot provide air interface resources for the first DRB, the SN may be suggested to determine the bearer type as an SCG bearer.

S520, the MN sends the advice information to the SN. Accordingly, the SN receives the advice information sent by the MN.

S530, the SN determines the bearing type of the first DRB according to the suggestion information.

Specifically, the MN may suggest the bearer type of the first DRB to the SN, and the SN may determine the bearer type of the DRB according to the suggestion of the MN.

Therefore, according to the method for determining the bearer type provided by the application, the SN can determine the bearer type of the DRB more reasonably according to the suggested bearer type provided by the MN.

It should be understood that the bearer type ultimately determined by the SN may or may not be the bearer type suggested by the MN. For example, if the bearer type suggested by the MN is a split bearer, but the SN can satisfy the QoS requirement of the first DRB, the bearer type of the first DRB may be determined as an SCG bearer.

Optionally, the method may further include:

s540, the SN sends bearer type indication information to the MN. Accordingly, the MN receives the bearer type indication information sent by the SN.

S550, the MN determines the bearer type of the first DRB according to the bearer type indication information.

Specifically, after determining the bearer type of the first DRB, the SN may notify the network device of the determined bearer type of the first DRB through the bearer type indication information. Thus, the network device may determine the bearer type of the first DRB according to the bearer type indication information.

For S540 and S550, reference may be specifically made to descriptions of S440 and S450 in the method 400, and details are not described here.

The method for determining bearer types provided by the present application is mainly described above with reference to fig. 7 to 10. In addition, the application also provides a method for modifying the bearing type. The method provides possibility for SN to modify the bearing type of the bearing. The method for modifying the bearer type is described below with reference to fig. 11.

It should be noted that the method shown in fig. 11 may be performed after any one of the methods shown in fig. 7 to 10. For example, the first bearer in the method shown in fig. 11 may be a bearer corresponding to the first QoS flow in the methods shown in fig. 7 and fig. 8. After determining the bearer type according to the method shown in fig. 7 or fig. 8 and further establishing the bearer, when the SN needs to modify the bearer type, the method shown in fig. 11 may be used to modify the bearer type. As another example, the first bearer in the method shown in fig. 11 may be the first DRB in the methods shown in fig. 9 and 10. After determining the bearer type according to the method shown in fig. 9 or fig. 10 and further establishing the bearer, when the SN needs to modify the bearer type, the method shown in fig. 11 may be used to modify the bearer type.

Fig. 11 shows a schematic flow diagram of a method of modifying a bearer type. The method mainly includes S610 to S620. The respective steps will be described in detail below.

S610, the SN generates a request for modification (required) message. The modification application message is used for applying for modifying the bearer type of the first bearer.

Wherein, the PDCP entity corresponding to the first bearer is established at the SN. Or, it can be said that the SDAP entity of the QoS flow corresponding to the first bearer is established at the SN.

S620, the SN sends the modification application message to the MN. Accordingly, the MN receives the modification request message sent by the SN.

In particular, when the SN desires to modify the bearer type of the first bearer, it may request modification of the bearer type of the first bearer by sending a modification application message to the MN.

In one implementation, the modify application message may include a bearer establishment list and a bearer deletion list. The bearer establishment list comprises an identifier of the first bearer and indication information (simply referred to as indication information) indicating a bearer type which needs to be modified by the first bearer; the bearer deletion list may include an identification of the first bearer.

It should be understood that the bearer type that needs to be modified indicated by the indication information is a new bearer type of the first bearer determined by the SN. The current bearer type of the first bearer is the original bearer type of the first bearer. That is, the SN expects to modify the first bearer from the original bearer type to a new bearer type.

By deleting the first bearer which is the original bearer type and establishing the first bearer as the bearer of the new bearer type, the modification of the bearer type of the first bearer can be realized.

The indication information may be an explicit bearer type, such as an MCG bearer, an SCG bearer, or a separate bearer. The indication information may also be implicit information, which may indicate a new bearer type for the first bearer. For example, the implicit information may be uplink transmission network layer (UL TNL) information, where the UL TNL information is transport layer information that is allocated by the SN for the first bearer and is used for receiving uplink data sent by the MN, and the uplink data is uplink data of the first bearer received by the MN from the terminal device. It should be understood that, if the indication information is the uplink transport network layer information, it indicates that the new bearer type is a bearer type related to the MCG air interface resource, that is, an MCG bearer or a detached bearer.

The uplink transport network layer information may include an Internet Protocol (IP) address and a Tunnel End Identifier (TEID), and the SN may receive the first-bearer uplink data sent by the MN according to the uplink transport network layer information.

Therefore, according to the method for modifying the bearer type provided by the present application, the SN may trigger modification (or change) of the bearer type by sending a modification application message to the MN, and further may implement modification of the bearer type.

Further, the SN may implement SN-triggered bearer type modification by carrying the same bearer identifier in the bearer establishment list and the bearer deletion list.

The following description is directed to different scenarios.

Scene one

The MN can autonomously decide whether to accept the SN modification application.

After receiving the SN, the MN may autonomously decide whether to accept the SN modification application. If the MN decides to accept the request for modification of the first bearer by the SN, the method may further include S630 to S650.

S630, the MN sends a modification request (request) message to the SN. Accordingly, the SN receives the modification request message sent by the MN.

The modification request message is for indicating that the MN agrees to modify the bearer type of the first bearer. That is, the SN receives the modification request message sent by the MN, and can know that the MN agrees to modify the bearer type of the first bearer.

Optionally, if the new bearer type of the first bearer is an MCG bearer or a separate bearer, the MN may further carry the uplink transport network layer information in the modification request message. Or, if the indication information is the uplink transport network layer information, the MN may not carry the uplink transport network layer information in the modification request message.

S640, the SN sends a modification request acknowledge (acknowledge) message to the MN. Accordingly, the MN receives the modification request acknowledgement message sent by the SN.

The modification request acknowledgement message includes an air interface RRC configuration #1, where the air interface RRC configuration #1 is an air interface RRC configuration #1 generated by the terminal device for the SN, and the air interface RRC configuration #1 is used for the terminal device to configure the first bearer.

After that, the MN may send the air interface RRC configuration #1 and the air interface RRC configuration #2 to the terminal device. Accordingly, the terminal device receives the air interface RRC configuration #1 and the air interface RRC configuration # 2.

For example, if the original bearer type is a split bearer and the new bearer type is an SCG bearer, the SN needs to generate a PDCP recovery configuration for the UE (i.e., an example of an air interface RRC configuration #1), instruct the PDCP entity of the bearer to perform data recovery, and the MN needs to generate a MCG RLC bearer deletion configuration for the UE (i.e., an example of an air interface RRC configuration # 2).

For example, if the original bearer type is an SCG bearer and the new bearer type is an MCG bearer, the SN needs to generate a configuration for releasing the SCG RLC bearer for the UE (i.e., an example of an air interface RRC configuration #1), and the MN needs to generate a configuration for increasing the MCG RLC bearer for the UE (i.e., an example of an air interface RRC configuration # 2).

S650, the MN sends a modification confirm (confirm) message to the SN. Accordingly, the SN receives the modification confirm message sent by the MN.

Wherein the modification confirmation message is used for indicating that the modification of the bearer type of the first bearer is completed.

Specifically, after the MN accepts the modification application of the SN, the MN may send a modification request message to the SN, on one hand, to notify the SN that the MN accepts the modification application of the SN, and on the other hand, to request the SN to generate a corresponding air interface RRC configuration #1 for the first bearer. After the SN generates the first bearer and generates corresponding air interface RRC configuration #1, the SN sends the configuration to the MN through a modification request acknowledgement message. After receiving the modification request confirmation message, the MN generates an air interface RRC configuration #2, and sends the air interface RRC configuration #1 and the air interface RRC configuration #2 to the terminal device together, thereby completing the configuration of the first bearer. And, the MN informs the SN that the MN has completed configuring the first bearer by sending a modification acknowledgement message to the SN.

Scene two

The MN must accept the SN modification application. I.e. the MN cannot reject the bearer modification request initiated by the SN for the first bearer.

In this scenario, the SN may carry the air interface RRC configuration #1 in the modify application message. In this scenario, the method may further include S650 and S660 described above. That is, in scene two, S630 and S640 may not be performed, and S650 and S660 may be performed after S620.

That is, after receiving the air interface RRC configuration #1 sent by the SN, the MN generates an air interface RRC configuration #2, and sends the air interface RRC configuration #1 and the air interface RRC configuration #2 to the terminal device together, thereby completing the configuration of the first bearer. And, the MN informs the SN that the MN has completed configuring the first bearer by sending a modification acknowledgement message to the SN.

Optionally, if the original bearer type of the first bearer is an SCG bearer, and the new bearer type is an MCG bearer or a split bearer, the MN may further carry the uplink transport network layer information in the modification acknowledgement message in S660. Or, if the indication information is the uplink transport network layer information, the MN may not carry the uplink transport network layer information in the modification confirmation message.

In summary, based on the above method, when the air interface state of the secondary network device changes, the secondary network device may modify the bearer type to a bearer type more suitable for the air interface state of the secondary network device.

In this application, after determining the bearer type through negotiation with the SN by using the method for determining the bearer type shown in fig. 6 to 11, the MN and the SN may also negotiate the uplink transmission time of the terminal device at the MN or the SN. The following description is made with reference to fig. 13. It should be understood that the communication method shown in fig. 13 can be applied to various DC scenarios shown in fig. 2 to 5, such as NE-DC scenarios in which the primary base station is a 5G base station and the secondary base station is an LTE base station.

Fig. 13 is a schematic flow chart diagram of a communication method 700 provided herein. The method 700 mainly includes S710 to S730. The respective steps will be explained below.

S710, the MN sends time domain configuration information to the SN. Correspondingly, the SN receives the time domain configuration information.

Optionally, when the MN confirms that the terminal device needs to perform single uplink transmission due to power control or inter modulation interference (inter modulation interference), the MN sends the time domain configuration information to the SN. The time domain configuration information may be uplink and downlink time domain allocation of the terminal device in the SN. The single uplink transmission refers to that the terminal device only sends data or signals to the MN or the SN cell in one time unit, that is, the terminal device cannot send data or signals through the MN or the SN cell at the same time in the same time unit. The time unit may be a subframe, a slot, a mini-subframe, or the like, without limitation. In this embodiment, a subframe is taken as an example for explanation.

Optionally, the uplink and downlink time domain allocation is in an uplink and downlink time domain allocation form corresponding to a Radio Access Technology (RAT) of the SN, or may be in an uplink and downlink time domain allocation form corresponding to an RAT of the MN, which is not limited. For example, the uplink and downlink time domain allocation may be uplink and downlink time domain allocation (subframe Assignment) defined in the LTE protocol TS36.331, and the uplink and downlink time domain allocation is an uplink-downlink allocation form corresponding to LTE, and a specific form may be referred to as uplink-downlink configuration in TS 36.211. The uplink and downlink time domain allocation may also be TDD-UL-DL-Pattern or TDD-UL-DL-ConfigCommon defined in TS38.331, indicating time division multiplex (TDD) configuration of uplink and downlink.

Optionally, the time domain configuration information includes a second HARQ offset.

S720, the SN determines the first HARQ offset according to the time domain configuration information.

In addition, the SN may also determine uplink and downlink time domain allocation according to the time domain configuration information. Wherein, the uplink and downlink time domain allocation may be a subframe allocation. Optionally, the SN allocates the time domain configuration information received from the MN as uplink and downlink time domains.

Alternatively, the first HARQ offset may be preset to 0.

Alternatively, the SN may determine the first HARQ offset by combining the time domain configuration information with other information, for example, cell load under the SN, and uplink resource usage of one or more terminal devices accessed under the SN.

In one implementation, the SN may adjust the first HARQ offset to 0, so that the uplink and downlink time domain allocation of the SN is the same as the uplink and downlink time domain allocation sent by the MN.

In one implementation, if the time domain configuration information includes a second HARQ offset, the SN determines the first HARQ offset as a value different from the second HARQ offset, and sends the value to an MN.

In one implementation, the SN may adjust the first HARQ offset to be a non-0 constant, so that the uplink and downlink time domain allocation of the SN is the same as the uplink and downlink time domain allocation sent by the MN.

The HARQ offset is used for indicating the deviation of the HARQ subframe, and the HARQ offset refers to the deviation of the HARQ subframe performed by the terminal equipment on the basis of the uplink subframe corresponding to the uplink and downlink time domain allocation. The HARQ offset is used to indicate the HARQ subframe offset, and can be used for the design in subframe allocation related to the uplink subframe, and the details can be found in 3GPP TS36.213[23 ].

S730, the SN sends the first HARQ offset to the MN.

Accordingly, the MN receives the first HARQ offset. Furthermore, the MN can obtain uplink time domain information that can be used by the serving cell of the terminal device under the MN according to the first HARQ offset and the time domain configuration information previously sent to the SN. The uplink time domain information includes TDD ratio of uplink time units.

The MN can use the first HARQ offset obtained from the SN for uplink and downlink time domain allocation.

Alternatively, in an embodiment of the present application, if the SN sets the first HARQ offset to 0, the SN may not send the first HARQ offset to MN., and the MN may use the original time domain configuration information for uplink and downlink time domain allocation.

In another embodiment, the SN may send the uplink and downlink time domain allocations and the first harq offset acknowledged for the terminal device to the MN. The MN can obtain uplink time domain information that can be used by the serving cell of the terminal device under the MN according to the uplink time domain allocation and the downlink time domain allocation and the first HARQ offset.

In another embodiment, the SN may send a time domain allocation message to the MN, where the time domain configuration message may be uplink and downlink time domain allocations used by the terminal device at the SN or the MN.

Optionally, in another embodiment, the method further comprises:

s740, the SN determines a time division multiplexing (TDM-pattern configuration) configuration for the terminal according to the time domain configuration information received from the MN.

Specifically, after receiving the time domain configuration information sent by the MN, the SN may determine, for the terminal device, a time division multiplexing mode configuration provided for the terminal device to use.

The time division multiplexing mode configuration may include uplink and downlink time domain allocation and the first HARQ offset. And the uplink and downlink time domain allocation is in an uplink and downlink time domain allocation form corresponding to the RAT of the SN. For the terminal device, the terminal device only sends uplink information on the subframe after the uplink subframe corresponding to the uplink time domain allocation is offset by using the first HARQ offset.

And S750, the SN informs the terminal equipment of the time division multiplexing mode configuration determined by the terminal equipment.

In one embodiment, the SN may first send the tdm configuration to the MN, which then passes it through to the terminal device. For example, the terminal may be informed of the time division multiplexing mode configuration in an implicit indication manner. Specifically, the SN may encapsulate the time-division multiplexing mode configuration in a container (container), which is carried in a first message sent to the MN, so as to send the time-division multiplexing mode configuration to the MN. And the MN receives the message containing the container, and then the container is carried in a second message sent by the MN as the terminal equipment, so that the time division multiplexing mode configuration is sent to the terminal. Wherein the first message or the second message may be a radio resource control Connection Reconfiguration (RRC Connection Reconfiguration) message. For another example, the terminal device may be notified of the time division multiplexing mode configuration by displaying an indication. Specifically, the SN may directly send the time division multiplexing mode configuration or a message including the time division multiplexing mode configuration to the MN, and the MN reads the time division multiplexing mode configuration and then sends the time division multiplexing mode configuration to the terminal.

In another embodiment, the SN may directly send the time division multiplexing mode configuration to the terminal device.

Optionally, in an embodiment, the SN may send the time division multiplexing mode configuration sent to the terminal and the first HARQ offset sent by the SN to the MN and/or the uplink and downlink time domain allocation determined for the terminal device to the MN in the same message.

Accordingly, the terminal device receives the time division multiplexing mode configuration.

Specifically, after receiving the time division multiplexing mode configuration, the terminal device may send uplink information on a subframe after performing the first HARQ offset on the uplink subframe corresponding to the uplink time domain allocation.

It should be noted that the embodiment shown in fig. 12 may be implemented alone, or may be combined with any one or more of the embodiments shown in fig. 7 to 11, which is not limited herein.

The method provided by the present application is described above mainly in conjunction with fig. 2 to 12. The apparatus provided by the present application will be described below.

Fig. 13 is a schematic block diagram of a communication device provided in an embodiment of the present application. As shown in fig. 13, the communication device 800 may include a processing unit 810 and a transceiving unit 820.

In one possible design, the communication apparatus 800 may correspond to the secondary network device in the above method embodiment, and may be, for example, an SN or a chip configured in the SN. When the communication device is an SN, the processing unit may be a processor and the transceiving unit may be a transceiver. The communication device may further comprise a storage unit, which may be a memory. The storage unit is used for storing instructions, and the processing unit executes the instructions stored by the storage unit so as to enable the communication device to execute the method. When the communication device is a chip in the SN, the processing unit may be a processor, and the transceiving unit may be an interface circuit, an input/output interface, a pin or a circuit, etc.; the processing unit executes the instructions stored in the storage unit (e.g., register, cache, etc.) in the chip or outside the chip (e.g., ROM, RAM, etc.) to make the communication device execute the operations performed by the SN in the methods described above

In one implementation, the units and other operations and/or functions described above in the communication device 800 are for implementing the corresponding flows of the method in fig. 7. Specifically, the processing unit 810 may be configured to perform S230 in the method shown in fig. 7, and the transceiving unit 820 may be configured to perform S220 and S240 in the method shown in fig. 7.

In one implementation, the units and other operations and/or functions described above in the communication device 800 are for implementing the corresponding flow of the method in fig. 8. Specifically, the processing unit 810 may be configured to perform S330 in the method shown in fig. 8, and the transceiving unit 820 may be configured to perform S320 and S340 in the method shown in fig. 8.

In yet another implementation, the units and other operations and/or functions described above in the communication device 800 are for implementing the corresponding flow of the method in fig. 9. Specifically, the processing unit 810 may be configured to perform S430 in the method shown in fig. 9, and the transceiving unit 820 may be configured to perform S420 and S440 in the method shown in fig. 9.

In yet another implementation, the units and other operations and/or functions described above in the communication device 800 are for implementing the corresponding flows of the method in fig. 10. Specifically, the processing unit 810 may be configured to perform S530 in the method illustrated in fig. 10, and the transceiving unit 820 may be configured to perform S520 and S540 in the method illustrated in fig. 10.

In yet another implementation, the units and other operations and/or functions described above in the communication device 800 are for implementing the corresponding flow of the method in fig. 11. Specifically, the processing unit 810 may be configured to perform S610 in the method shown in fig. 11, and the transceiving unit 820 may be configured to perform S620 to S650 in the method shown in fig. 11.

In yet another implementation, the units and other operations and/or functions described above in the communication device 800 are for implementing the corresponding flows of the method in fig. 12. Specifically, the processing unit 810 may be configured to perform S720 and S740 in the method illustrated in fig. 12, and the transceiving unit 820 may be configured to perform S710, S730, and S750 in the method illustrated in fig. 12.

In another possible design, the communication apparatus 800 may correspond to the primary network device in the above method embodiment, and may be, for example, a MN or a chip configured in the MN. When the communication device is a MN, the processing unit may be a processor and the transceiving unit may be a transceiver. The communication device may further comprise a storage unit, which may be a memory. The storage unit is used for storing instructions, and the processing unit executes the instructions stored by the storage unit so as to enable the communication device to execute the method. When the communication device is a chip within the MN, the processing unit may be a processor, and the transceiving unit may be an interface circuit, an input/output interface, a pin or a circuit, etc.; the processing unit executes instructions stored by a storage unit (e.g., a register, a cache memory, etc.) within the chip or a storage unit (e.g., a read-only memory, a random access memory, etc.) external to the chip to cause the communication device to perform the operations performed by the MN in the above-described method.

In one implementation, the units and other operations and/or functions described above in the communication device 800 are for implementing the corresponding flows of the method in fig. 7. Specifically, the processing unit 810 may be configured to perform S210 and S250 in the method illustrated in fig. 7, and the transceiving unit 820 may be configured to perform S220 and S240 in the method illustrated in fig. 7.

In one implementation, the units and other operations and/or functions described above in the communication device 800 are for implementing the corresponding flow of the method in fig. 8. Specifically, the processing unit 810 may be configured to perform S310 and S350 in the method illustrated in fig. 8, and the transceiving unit 820 may be configured to perform S320 and S340 in the method illustrated in fig. 8.

In yet another implementation, the units and other operations and/or functions described above in the communication device 800 are for implementing the corresponding flow of the method in fig. 9. Specifically, the processing unit 810 may be configured to perform S410 and S450 of the method illustrated in fig. 9, and the transceiving unit 820 may be configured to perform S420 and S440 of the method illustrated in fig. 9.

In yet another implementation, the units and other operations and/or functions described above in the communication device 800 are for implementing the corresponding flows of the method in fig. 10. Specifically, the processing unit 810 may be configured to perform S510 and S550 in the method illustrated in fig. 10, and the transceiving unit 820 may be configured to perform S520 and S540 in the method illustrated in fig. 10.

In yet another implementation, the units and other operations and/or functions described above in the communication device 800 are for implementing the corresponding flow of the method in fig. 11. Specifically, the transceiving unit 820 may be configured to perform S620 to S650 in the method illustrated in fig. 11.

In yet another implementation, the units and other operations and/or functions described above in the communication device 800 are for implementing the corresponding flows of the method in fig. 12. Specifically, the transceiving unit 820 may be configured to perform S710 and S730 in the method illustrated in fig. 12.

In the above-mentioned various apparatus embodiments, the primary network device completely corresponds to the MN or SN in the secondary network device and method embodiment, and the corresponding unit or unit performs the corresponding steps, for example, the transceiver unit (transceiver) method performs the steps of transmitting and/or receiving in the method embodiment, and other steps except for transmitting and receiving may be performed by the processing unit (processor). The functions of the specific elements may be referred to in the respective method embodiments. The transceiver unit may include a transmitting unit and/or a receiving unit, and the transceiver may include a transmitter and/or a receiver, which implement transceiving functions respectively; the processor may be one or more.

It should be understood that the above division of the units is only a functional division, and other division methods may be possible in actual implementation.

The primary network device or the secondary network device may be a chip, the processing unit may be implemented by hardware or software, and when implemented by hardware, the processing unit may be a logic circuit, an integrated circuit, or the like; when implemented in software, the processing unit may be a general-purpose processor implemented by reading software code stored in a memory unit, which may be integrated in the processor or located external to the processing unit and stand alone.

Fig. 14 is a schematic structural diagram of a network device provided in the present application, where the network device may be a base station, for example. As shown in fig. 14, the base station may be applied to the communication system shown in fig. 1, and performs the functions of the primary network device or the secondary network device in the above method embodiment. The base station 20 may include one or more radio frequency units, such as a Remote Radio Unit (RRU) 201 and one or more baseband units (BBUs) (which may also be referred to as Digital Units (DUs)) 202. The RRU 201 may be referred to as a transceiver unit, transceiver circuit, or transceiver, etc., which may include at least one antenna 2011 and a radio unit 2012. The RRU 201 is mainly used for transceiving radio frequency signals and converting radio frequency signals and baseband signals, for example, for sending the BFR configuration of the above method embodiment. The BBU202 is mainly used for performing baseband processing, controlling a base station, and the like. The RRU 201 and the BBU202 may be physically disposed together or may be physically disposed separately, that is, distributed base stations.

The BBU202 is a control center of a base station, and may also be referred to as a processing unit, and is mainly used for performing baseband processing functions, such as channel coding, multiplexing, modulation, spreading, and the like. For example, the BBU (processing unit) 202 can be used to control the base station to execute the operation flow related to the network device in the above method embodiment.

In an embodiment, the BBU202 may be formed by one or more boards, and the boards may jointly support a radio access network (e.g., an LTE network) with a single access indication, or may respectively support radio access networks with different access schemes (e.g., an LTE network, a 5G network, or other networks). The BBU202 also includes a memory 2021 and a processor 2022, the memory 2021 for storing the necessary instructions and data. The processor 2022 is configured to control the base station to perform necessary actions, for example, to control the base station to perform the operation procedures related to the network device in the above method embodiments. The memory 2021 and the processor 2022 may serve one or more boards. That is, the memory and processor may be provided separately on each board. Multiple boards may share the same memory and processor. In addition, each single board can be provided with necessary circuits.

The network device is not limited to the above-described embodiment, and may be in another embodiment: for example: the antenna comprises a BBU (baseband unit) and an Adaptive Radio Unit (ARU), or the BBU and an Active Antenna Unit (AAU); the CPE may be a Customer Premise Equipment (CPE) or another type, and the present application is not limited thereto.

It should be noted that the processor in the embodiments of the present application may be an integrated circuit chip having signal processing capability. In implementation, the steps of the above method embodiments may be performed by integrated logic circuits of hardware in a processor or instructions in the form of software. The processor may be a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic device, or discrete hardware components. The various methods, steps, and logic blocks disclosed in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the embodiments of the present application may be embodied directly in a hardware decoding processor, or in a combination of hardware and software elements in a decoding processor. The software elements may be located in ram, flash, rom, prom, or eprom, registers, among other storage media that are well known in the art. The storage medium is located in a memory, and a processor reads information in the memory and completes the steps of the method in combination with hardware of the processor.

It will also be appreciated that the memory in the embodiments of the subject application can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. The non-volatile memory may be a read-only memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable PROM (EEPROM), or a flash memory. Volatile memory can be Random Access Memory (RAM), which acts as external cache memory. By way of example, but not limitation, many forms of Random Access Memory (RAM) are available, such as Static RAM (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), synchlink DRAM (SLDRAM), and direct bus RAM (DR RAM).

According to the method provided by the embodiment of the present application, the present application further provides a computer program product, which includes: computer program code which, when run on a computer, causes the computer to perform the methods described above.

There is also provided, in accordance with a method provided by an embodiment of the present application, a computer-readable medium having program code stored thereon, which, when run on a computer, causes the computer to perform the above-described parties.

According to the method provided by the embodiment of the present application, the present application further provides a system, which includes the foregoing one or more terminal devices and one or more network devices.

The above embodiments may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, the above-described embodiments may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded or executed on a computer, cause the flow or functions according to embodiments of the invention to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored on a computer readable storage medium or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains one or more collections of available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., Digital Versatile Disk (DVD)), or a semiconductor medium. The semiconductor medium may be a solid state disk.

It should be understood that, in the various embodiments of the present application, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

It should also be understood that, in the present application, "when …", "if" and "if" all refer to the terminal device or the network device making corresponding processing under certain objective conditions, and are not time-limited, and do not require certain judgment actions when the terminal device or the network device is implemented, and do not mean that there are other limitations.

The term "and/or" herein is merely an association describing an associated object, meaning that three relationships may exist, e.g., a and/or B, may mean: a exists alone, A and B exist simultaneously, and B exists alone.

Herein, the term "at least one of … …" or "at least one of … …" or "at least one of … …" means all or any combination of the listed items, e.g., "at least one of A, B and C", may mean: there are six cases of a alone, B alone, C alone, a and B together, B and C together, and A, B and C together.

It should be understood that in the embodiments of the present application, "B corresponding to a" means that B is associated with a, from which B can be determined. It should also be understood that determining B from a does not mean determining B from a alone, but may be determined from a and/or other information.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

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.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a read-only memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

Claims

1. A method for determining a bearer type, comprising:

the auxiliary network equipment receives a first message sent by the main network equipment;

and the auxiliary network equipment determines the bearer type of a first quality of service (QoS) flow according to whether the first message comprises auxiliary information or not, wherein a Service Data Adaptation Protocol (SDAP) entity corresponding to the first QoS flow is established on the auxiliary network equipment, and the bearer type comprises a Master Cell Group (MCG) bearer, an auxiliary cell group (SCG) bearer or a separation bearer.

2. The method of claim 1, wherein the first QoS flow is a guaranteed bit rate, GBR, QoS flow, the assistance information is a first GBR QoS parameter, the first GBR QoS parameter being a GBR QoS parameter provided by the primary network device for the first QoS flow;

if the first message includes the auxiliary information, the auxiliary network device determines that the bearer type of the first QoS flow is the MCG bearer, the SCG bearer, or the split bearer; and/or

3. The method of claim 1, wherein the first QoS flow is a non-guaranteed bit rate non-GBRQoS flow and the assistance information aggregates a maximum bit rate UE AMBR and a first protocol data unit, PDU, session AMBR for a first user equipment, wherein the first UE AMBR establishes an AMBR provided by a non-GBR QoS flow at the secondary network device for a target UE for the primary network device, the target UE is a UE corresponding to the first QoS flow, the first PDU session AMBR establishes an AMBR provided by a non-GBR QoS flow at the secondary network device for a target PDU session for the primary network device, and the target PDU session is a PDU session corresponding to the first QoS flow;

4. The method of claim 1, wherein the first QoS flow is a non-guaranteed bit rate non-GBRQoS flow and the assistance information aggregates a maximum bit rate UE AMBR for a first user equipment, wherein the first UE AMBR establishes an AMBR provided by a non-GBR QoS flow at the secondary network device for a target UE for the primary network device, and the target UE is a UE corresponding to the first QoS flow;

5. The method of claim 1, wherein the first QoS flow is a non-guaranteed bit rate non-GBRQoS flow and the assistance information is a first protocol data unit, PDU, session AMBR, wherein the first PDU session AMBR is an AMBR established by the primary network device for a non-GBR QoS flow at the secondary network device in a target PDU session, the target PDU session being a PDU session corresponding to the first QoS flow;

6. The method of any of claims 1 to 5, further comprising:

the secondary network device sends bearer type indication information to the primary network device, where the bearer type indication information is used to indicate the bearer type of the first QoS flow determined by the secondary network device.

7. The method of claim 6, wherein the bearer type indication information is uplink transport network layer information of the secondary network device for receiving uplink data allocated for the bearer corresponding to the first QoS flow.

8. The method of any of claims 1 to 7, further comprising:

the auxiliary network equipment generates a modification application message, wherein the modification application message is used for applying for modifying the bearer type of the first bearer corresponding to the first QoS flow;

and the auxiliary network equipment sends the modification application message to the main network equipment.

9. The method of claim 8, wherein the modify application message comprises a bearer establishment list and a bearer deletion list, the bearer establishment list comprising an identification of the first bearer and information indicating a bearer type that the first bearer needs to be modified, the bearer deletion list comprising the identification of the first bearer.

10. A method for determining a bearer type, comprising:

the main network equipment generates a first message according to whether the auxiliary information is included in the first message or not;

the primary network device sends the first message to a secondary network device, where the first message is used for the secondary network device to determine a bearer type of a first quality of service (QoS) flow, where a SDAP entity corresponding to the first QoS flow is established on the secondary network device, and the bearer type includes a primary cell group (MCG) bearer, a Secondary Cell Group (SCG) bearer, or a separate bearer.

11. The method of claim 10, wherein the first QoS flow is a guaranteed bit rate, GBR, QoS flow, the assistance information is a first GBR QoS parameter that the primary network device provides for the first QoS flow;

12. The method of claim 10, wherein the first QoS flow is a non-guaranteed bit rate non-GBRQoS flow and the assistance information aggregates a maximum bit rate UE AMBR and a first protocol data unit, PDU, session AMBR for a first user equipment, wherein the first UE AMBR establishes an AMBR provided by a non-GBR QoS flow at the secondary network device for a target UE for the primary network device, the target UE is a UE corresponding to the first QoS flow, the first PDU session AMBR establishes an AMBR provided by a non-GBR QoS flow at the secondary network device for a target PDU session for the primary network device, and the target PDU session is a PDU session corresponding to the first QoS flow;

13. The method of claim 10, wherein the first QoS flow is a non-guaranteed bit rate non-GBRQoS flow and the assistance information aggregates a maximum bit rate UE AMBR for a first user equipment, wherein the first UE AMBR establishes an AMBR provided by a non-GBR QoS flow at the secondary network device for a target UE for the primary network device, and the target UE is a UE corresponding to the first QoS flow;

14. The method of claim 10, wherein the first QoS flow is a non-guaranteed bit rate non-GBRQoS flow, the assistance information is a first protocol data unit, PDU, session AMBR that is an AMBR established by the primary network device for a non-GBR QoS flow of the secondary network device in a target PDU session, the target PDU session being a PDU session corresponding to the first QoS flow;

15. The method of any of claims 10 to 14, further comprising:

the primary network device receives bearer type indication information sent by the secondary network device, wherein the bearer type indication information is used for indicating the bearer type of the first QoS flow determined by the secondary network device;

and the main network equipment determines the bearer type of the first QoS flow according to the bearer type indication information.

16. The method of claim 15, wherein the bearer type indication information is uplink transport network layer information of the secondary network device for receiving uplink data allocated for the bearer corresponding to the first QoS flow.

17. The method of any of claims 10 to 16, further comprising:

the primary network device receives a modification application message sent by the secondary network device, wherein the modification application message is used for applying for modifying the bearer type of the first bearer corresponding to the first QoS flow;

and the main network equipment sends a modification request message to the auxiliary network equipment, wherein the modification request message is used for indicating that the main network equipment agrees to modify the bearer type of the first bearer.

18. The method of claim 17, wherein the modify application message comprises a bearer establishment list and a bearer deletion list, the bearer establishment list comprising an identification of the first bearer and information indicating a bearer type that the first bearer needs to be modified, the bearer deletion list comprising the identification of the first bearer.

19. A communications device comprising means for performing the method of any of claims 1-9 or 10-18.

20. A communications device comprising a processor and interface circuitry for receiving and transmitting signals from or sending signals to other communications devices than the communications device, the processor being arranged to implement the method of any one of claims 1 to 9 or 10 to 18 by means of logic circuitry or executing code instructions.

21. A computer-readable storage medium, in which a program or instructions are stored which, when executed, implement the method of any one of claims 1 to 9 or 10 to 18.