Detailed Description
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required to be used in the embodiments of the present invention will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive labor.
First, some concepts involved in the embodiments of the present invention are explained.
1. Data replication (PDCP replication) introduction of Packet Data Convergence Protocol (PDCP)
In a New Radio (NR), a PDCP duty function is introduced to improve reliability of data transmission. A network side configures whether a PDCP layer corresponding to a Radio Bearer (RB) of a terminal, such as User Equipment (User Equipment, UE), needs to copy data of a PDCP entity, and then sends the copied data through two (or more) different paths (e.g., two different Radio Link Control (RLC) entities), where the different RLC entities correspond to different logical channels.
The PDCP data copy function may indicate whether to start (i.e., activate) or stop (i.e., deactivate) through a Medium Access Control Element (MAC CE). When configuring the PDCP copy data function of the RB, the network side can configure whether the function is turned on immediately after configuration, i.e., no additional activation of MAC CE signaling is required.
2. Bearer type of PDCP data copying function
In the 5G system, because a Dual Connectivity (DC) architecture (including two Cell groups, namely, a Master Cell Group (MCG) and a Secondary Cell Group (SCG)) is adopted, the MCG corresponds to a Master Node (Master Node, MN) on a network side, and the SCG corresponds to a Secondary Node (SN) on the network side, the bearer types of the PDCP data replication function include two types shown in fig. 1 and fig. 2:
a11, Split bearer (Split bearer): the bearer has a corresponding PDCP entity in 1 cell group and corresponding 2 (or more) RLC and 2 (or more) MAC in different cell groups.
A12, Duplicate bearer (Duplicate bearer): the bearer has 1 PDCP entity, 2 (or more) RLC entities and 1 MAC entity in 1 cell group.
Wherein, MCG corresponds to MCG MAC entity, and SCG corresponds to SCG MAC. The network entity corresponding to the MCG is a Master Node (MN), and the network entity corresponding to the SCG is a Slave Node (SN).
3. Multi-path PDCP data replication (Multple Leg PDCP duplicate)
As shown in fig. 3 and 4, the PDCP data duplication function may configure more than two (e.g., 3) transmission paths (e.g., 1 PDCP entity corresponds to more than 3 RLC entities), and the configured transmission paths may correspond to only one MAC entity or two MAC entities.
The present invention will be described in detail below with reference to examples and the accompanying drawings.
Referring to fig. 5, fig. 5 is a flowchart of a configuration negotiation method provided in an embodiment of the present invention, where the method is applied to a first network node, and as shown in fig. 5, the method includes the following steps:
step 501: a configuration request message is sent to the second network node.
Wherein, the configuration request message is used for requesting to negotiate a transmission path corresponding to the radio bearer. The radio bearer may be selected as the certain determined radio bearer or the certain plurality of determined radio bearers. The Radio Bearer may be selected as a Signaling Radio Bearer (SRB) or a Data Radio Bearer (DRB). The transmission path corresponding to the radio bearer may be understood as a transmission path corresponding to the PDCP data duplication function of the radio bearer, and is generally configured to be more than two (e.g., 3).
The radio bearer involved in this embodiment may be the above-mentioned split bearer or the duplicate bearer, and the PDCP data duplication function in this embodiment may be as described above, which is not described herein again.
Optionally, the first network node is an MN, and the second network node is an SN;
or, the first network node is a SN, and the second network node is a MN.
Wherein the first network node is a network node where a PDCP entity of the radio bearer is located.
For example, when the first network node is an MN and the second network node is an SN, the MN requests to negotiate the radio bearer type of the transmission path to be an MN-terminated split bearer (MN-terminated split bearer) or an MN-terminated SCG bearer (MN-terminated SCG bearer).
For example, when the first network node is an SN and the second network node is an MN, the radio bearer type of the SN request negotiation transmission path is an SN terminated split bearer (SN terminated split bearer) or an SN terminated MCG bearer (SN terminated MCG bearer).
In the configuration negotiation method of the embodiment of the present invention, the first network node sends the configuration request message to the second network node, where the configuration request message is used to request for negotiating the transmission path corresponding to the radio bearer, and for example, under a DC architecture, the configuration condition of the transmission path corresponding to the radio bearer by the other side is known between the two network nodes by means of the negotiation process of the first and second network nodes, so as to effectively coordinate the resource condition of the network side node and flexibly configure the number of the transmission paths corresponding to the radio bearer.
In this embodiment of the present invention, optionally, the configuration request message includes at least one of the following:
a radio bearer identity; such as SRB ID or DRB ID;
the total number of transmission paths which are needed to be configured by the radio bearer and are determined by the first network node;
the first network node suggests the number of transmission paths needed to be configured by the second network node;
the number of transmission paths configured by the first network node;
the applicable data transmission direction; such as uplink only, downlink only, or both uplink and downlink.
In one embodiment, the configuration request message includes a total number of transmission paths that the first network node determines that the radio bearer needs to be configured. In this way, by means of the total number of transmission paths determined by the first network node, it may be ensured that the total number of transmission paths corresponding to the respective radio bearer does not exceed the predefined maximum configurable number of transmission paths corresponding to the radio bearer.
In one embodiment, the configuration request message includes a number of transmission paths that the first network node proposes that the second network node needs to be configured. Therefore, by means of the first network node suggesting the number of transmission paths required to be configured by the second network node, the second network node can be prevented from being configured with excessive transmission paths, resource waste is avoided, and the second network node is prevented from being configured with insufficient transmission paths, so that the reliability requirement corresponding to the corresponding radio bearer cannot be met.
In one embodiment, the configuration request message includes the number of transmission paths configured by the first network node. In this way, by means of the number of transmission paths configured by the first network node, the second network node can acquire the number of transmission paths configured by the first network node, thereby avoiding configuring excessive transmission paths by itself, and avoiding that the total number of transmission paths corresponding to corresponding radio bearers exceeds the maximum configurable number of transmission paths corresponding to the radio bearers agreed in advance.
Optionally, after step 501, the method further includes:
receiving a configuration response message from the second network node;
wherein the configuration response message is any one of the following:
configuration confirmation information of a transmission path corresponding to the radio bearer;
configuration change information of a transmission path corresponding to the radio bearer;
configuration reject message of transmission path corresponding to radio bearer.
In this way, with the aid of the configuration response message, the first network node can be caused to determine the response of the second network node to the configuration request message.
Further, the configuration confirmation message may include at least one of the following:
an identification of one or more transmission paths configured by the second network node; for example, the identifier may be selected as a Logical Channel Identity (LCID), and/or an RLC entity identity;
the number of transmission paths configured by the second network node; therefore, by means of the number of the transmission paths configured by the second network node, the first network node can know the configuration condition of the second network node;
a default transmission path; for example, the number of the default transmission paths may be selected as one or more; the default transmission path may be a path through which the radio bearer may perform data transmission through the second network node after the PDCP data copy function of the corresponding radio bearer is deactivated;
an initially active transmission path; for example, the number of the initially activated transmission paths may be selected to be one or more. The initially activated transmission path may be a transmission path initially available to the data duplication function of the radio bearer in which the data duplication function is configured after initial configuration or reconfiguration of the transmission path of the radio bearer. The available transmission path of the radio bearer can then be changed by network signaling (such as MAC CE) or by the UE according to certain rules.
Further, the configuration change message may include at least one of:
the number of transmission paths configured by the second network node;
the reason why the second network node changes the number of transmission paths; the number of the transmission paths is that the first network node suggests that the second network node needs to be configured, or the number of the transmission paths is that the first network node determines that the second network node needs to be configured according to the total number of the transmission paths that the first network node determines that the radio bearer needs to be configured and the number of the transmission paths that the first network node configures; for example, the reason may be that the current LCID resource is insufficient, thereby reducing the number of transmission paths configured by the second network node;
an identification of one or more transmission paths configured by the second network node; for example, the identifier may be selected as LCID, and/or RLC entity identifier;
a default transmission path; for example, the number of the default transmission paths may be selected as one or more; the default transmission path may be a path through which the radio bearer may perform data transmission through the second network node after the PDCP data copy function of the corresponding radio bearer is deactivated;
an initially active transmission path; for example, the number of the initially activated transmission paths may be selected to be one or more. The initially activated transmission path may be a transmission path initially available to the data duplication function of the radio bearer in which the data duplication function is configured after initial configuration or reconfiguration of the transmission path of the radio bearer. The available transmission path of the radio bearer can then be changed by network signaling (such as MAC CE) or by the UE according to certain rules.
Further, the configuration rejection message may include:
a reason for rejection; for example, the reject reason may be that the current LCID resource is insufficient, or the active cell corresponding to the current second network node is overloaded.
In this embodiment of the present invention, optionally, after receiving the configuration response message from the second network node, the method may further include:
performing any one of the following operations:
1) and adjusting the number of the transmission paths configured by the first network node according to the number of the transmission paths configured by the second network node and the total number of the transmission paths determined by the first network node.
The total number of transmission paths determined by the first network node may be configured by the first network node, and the total number of transmission paths may be equal to or less than a maximum configurable number of transmission paths agreed by a protocol. This adjustment of the number of transmission paths configured by the first network node may be understood as: if the number of the transmission paths configured by the second network node is not equal to the number of the transmission paths that the second network node needs to configure, the first network node may adjust the number of the transmission paths configured by itself to ensure that the total number of the transmission paths determined by the first network node is unchanged.
2) And determining the number of the transmission paths configured by the first network node according to the number of the transmission paths configured by the second network node and the total number of the transmission paths determined by the first network node.
3) And determining the number of the transmission paths configured by the first network node according to the number of the transmission paths configured by the second network node and the maximum total number of the transmission paths configurable by the pre-agreed radio bearer.
For example, the pre-agreed may be selected as a protocol agreement. If the second network node configures 1 transmission path and the total maximum number of transmission paths agreed by the protocol is 4, the first network node may determine the number of transmission paths configured by itself, for example, the determined number of transmission paths configured is 1, 2, or 3.
4) And adjusting the number of the transmission paths configured by the first network node according to the number of the transmission paths configured by the second network node and the maximum total number of the transmission paths configurable by the pre-agreed radio bearer.
For example, the pre-agreed may be selected as a protocol agreement. If the configuration request message indicates that the first network node may configure 2 transmission paths, and the second network node feeds back that 3 transmission paths are configured, and the total maximum number of transmission paths agreed by the protocol is 4, the first network node may adjust the configured transmission paths to be 1.
Thus, by means of the above-mentioned executed operations, it can be ensured that the total number of transmission paths corresponding to the corresponding radio bearers does not exceed the maximum configurable number of transmission paths corresponding to the radio bearers agreed in advance, thereby flexibly configuring the number of transmission paths corresponding to the radio bearers.
Optionally, after receiving the configuration response message from the second network node, the method may further include:
sending a configuration message of a transmission path corresponding to a radio bearer to a terminal;
wherein the configuration message includes at least one of transmission path information configured by the first network node and transmission path information configured by the second network node.
Therefore, by sending the configuration message of the transmission path corresponding to the radio bearer to the terminal, the terminal can know the configuration message of the corresponding transmission path, and the smooth proceeding of the corresponding communication process is ensured.
In this embodiment of the present invention, optionally, the sending of the configuration request message is initiated by any one of the following manners:
a first network node initiates actively;
the second network node triggers the first network node to initiate.
Optionally, the reason for sending the configuration request message (such as the reason for the first network node to initiate actively or the reason for the second network node to trigger the first network node to initiate) includes at least one of the following:
initially configuring a transmission path for a radio bearer;
adding a transmission path for the radio bearer;
deleting transmission paths for radio bearers;
the transmission path is changed for the radio bearer.
In this embodiment of the present invention, optionally, after step 501, the method may further include:
starting a timer;
determining that the second network node refuses to respond to the configuration request message when the timer is expired and a configuration response message is not received from the second network node;
or, when a configuration response message is received from the second network node before the timer times out, the timer is stopped.
Therefore, by means of the timer, the negotiation process of the first network node and the second network node can be effectively controlled, and the effectiveness of the corresponding communication process is improved.
Referring to fig. 6, fig. 6 is a flowchart of another configuration negotiation method provided in the embodiment of the present invention, where the method is applied to a second network node, and as shown in fig. 6, the method includes the following steps:
step 601: receiving a configuration request message from a first network node;
wherein, the configuration request message is used for requesting to negotiate a transmission path corresponding to the radio bearer.
In the embodiment of the present invention, for example, under a DC architecture, by means of a negotiation process of the first and second network nodes, the configuration condition of the transmission path corresponding to the corresponding radio bearer by the other network node is known between the two network nodes, so that the resource condition of the network side node is effectively coordinated, and the number of the transmission paths corresponding to the radio bearer is flexibly configured.
Furthermore, by means of the negotiation process of the first network node and the second network node, it can be ensured that too many transmission paths are not configured, thereby avoiding resource waste, and that too few transmission paths are not configured, thereby avoiding that the reliability requirements corresponding to the corresponding radio bearers cannot be met.
Optionally, after step 601, the method further includes:
sending a configuration response message to the first network node;
wherein the configuration response message is any one of the following:
configuration confirmation information of a transmission path corresponding to the radio bearer;
configuration change information of a transmission path corresponding to the radio bearer;
configuration reject message of transmission path corresponding to radio bearer.
Optionally, the configuration request message includes at least one of the following:
a radio bearer identity;
the total number of transmission paths which are needed to be configured by the radio bearer and are determined by the first network node;
the first network node suggests the number of transmission paths needed to be configured by the second network node;
the number of transmission paths configured by the first network node;
the applicable data transmission direction.
Optionally, the configuration confirmation message includes at least one of the following:
an identification of one or more transmission paths configured by the second network node;
the number of transmission paths configured by the second network node;
a default transmission path;
the initially active transmission path.
Optionally, the configuration change message includes at least one of the following:
the number of transmission paths configured by the second network node;
the reason why the second network node changes the number of transmission paths; the number of the transmission paths is that the first network node suggests that the second network node needs to be configured, or the number of the transmission paths is that the first network node determines that the second network node needs to be configured according to the total number of the transmission paths that the first network node determines that the radio bearer needs to be configured and the number of the transmission paths that the first network node configures;
an identification of one or more transmission paths configured by the second network node;
a default transmission path;
the initially active transmission path.
Optionally, the configuration rejection message includes: reason for rejection.
Optionally, the first network node is an MN, and the second network node is an SN;
or, the first network node is a SN, and the second network node is a MN.
Wherein the first network node is a network node where a Packet Data Convergence Protocol (PDCP) entity of the radio bearer is located.
For example, when the first network node is an MN and the second network node is an SN, the MN requests to negotiate the radio bearer type of the transmission path to be an MN-terminated split bearer (MN-terminated split bearer) or an MN-terminated SCG bearer (MN-terminated SCG bearer).
For example, when the first network node is an SN and the second network node is an MN, the radio bearer type of the SN request negotiation transmission path is an SN terminated split bearer (SN terminated split bearer) or an SN terminated MCG bearer (SN terminated MCG bearer).
Next, taking the first network node as MN and the second network node as SN as an example, the configuration negotiation process of the embodiment of the present invention will be described with reference to fig. 7.
Example 1
In example 1, as shown in fig. 7, the corresponding configuration negotiation process may include the following steps:
s1: the MN sends a configuration request message to the SN.
Wherein the configuration request message is used for requesting to negotiate a transmission path corresponding to a radio bearer (such as SRB1 or DRB 2). The configuration request message includes the following contents:
a radio bearer identity; such as SRB ID or DRB ID;
the total number of transmission paths which need to be configured for the radio bearer and are determined by the MN;
the number of transmission paths configured by the MN, or the number of transmission paths required to be configured by the SN suggested by the MN;
the applicable data transmission direction; such as uplink only, downlink only, or both uplink and downlink.
S2: after receiving the configuration request message sent by the MN, the SN sends a configuration response message to the MN.
Wherein the configuration response message is any one of the following:
configuration confirmation information of a transmission path corresponding to the radio bearer;
configuration change information of a transmission path corresponding to the radio bearer;
configuration reject message of transmission path corresponding to radio bearer.
Further, the configuration confirmation message may include at least one of the following:
an identification of one or more transmission paths of the SN configuration; for example, the identifier may be selected as LCID, and/or RLC entity identifier;
a default transmission path; for example, the number of the default transmission paths may be selected as one or more; the default transmission path may be a path through which the radio bearer may perform data transmission through the SN after the PDCP data copy function of the corresponding radio bearer is deactivated;
an initially active transmission path; for example, the number of the initially activated transmission paths may be selected to be one or more.
Further, the configuration change message may include at least one of:
the number of transmission paths configured by SN;
the SN changes the reason of the transmission path number, wherein the transmission path number is required to be configured by the MN suggesting the SN, or the transmission path number is the total number of the transmission paths required to be configured by the MN according to the radio bearer determined by the MN, and the transmission path number configured by the MN, the determined transmission path number required to be configured by the SN; for example, the reason may be that the current LCID resource is insufficient, thus reducing the number of transmission paths configured by the SN;
an identification of one or more transmission paths of the SN configuration; for example, the identifier may be selected as LCID, and/or RLC entity identifier;
a default transmission path; for example, the number of the default transmission paths may be selected as one or more; the default transmission path may be a path through which the radio bearer may perform data transmission through the SN after the PDCP data copy function of the corresponding radio bearer is deactivated;
the initially active transmission path.
Further, the configuration rejection message may include:
a reason for rejection; for example, the reason for rejection may be that the current LCID resource is insufficient, or the active cell corresponding to the current SN is overloaded.
S3: after receiving the configuration response message sent by the SN, the MN performs at least one of the following operations:
adjusting the number of the transmission paths configured by the MN according to the number of the transmission paths configured by the SN and the total number of the transmission paths determined by the MN;
sending a configuration message of a transmission path corresponding to a radio bearer to a terminal; the configuration message includes at least one of transmission path information configured by the MN and transmission path information configured by the SN.
Therefore, the total number of the transmission paths required to be configured by the radio bearer can be determined by the MN, the total number of the transmission paths and the number of the transmission paths configured by the MN are indicated to the SN, and the SN can change the number of the transmission paths required to be configured and feed back to the MN.
Example 2
In example 2, as shown in fig. 7, the corresponding configuration negotiation process may include the following steps:
s1: the MN sends a configuration request message to the SN.
Wherein the configuration request message is used for requesting to negotiate a transmission path corresponding to a radio bearer (such as SRB1 or DRB 2). The configuration request message includes the following contents:
a radio bearer identity; such as SRB ID or DRB ID;
the total number of transmission paths which need to be configured for the radio bearer and are determined by the MN;
the applicable data transmission direction; such as uplink only, downlink only, or both uplink and downlink.
S2: after receiving the configuration request message sent by the MN, the SN sends a configuration response message to the MN.
Wherein the configuration response message is any one of the following:
configuration confirmation information of a transmission path corresponding to the radio bearer;
configuration reject message of transmission path corresponding to radio bearer.
Further, the configuration confirmation message may include at least one of the following:
the number of transmission paths configured by SN;
an identification of one or more transmission paths of the SN configuration; for example, the identifier may be selected as LCID, and/or RLC entity identifier;
a default transmission path; for example, the number of the default transmission paths may be selected as one or more; the default transmission path may be a path through which the radio bearer may perform data transmission through the SN after the PDCP data copy function of the corresponding radio bearer is deactivated;
an initially active transmission path; for example, the number of the initially activated transmission paths may be selected to be one or more.
Further, the configuration rejection message may include:
a reason for rejection; for example, the reason for rejection may be that the current LCID resource is insufficient, or the active cell corresponding to the current SN is overloaded.
S3: after receiving the configuration response message sent by the SN, the MN performs at least one of the following operations:
determining the number of transmission paths configured by the MN according to the number of the transmission paths configured by the SN and the total number of the transmission paths determined by the MN;
sending a configuration message of a transmission path corresponding to a radio bearer to a terminal; the configuration message includes at least one of transmission path information configured by the MN and transmission path information configured by the SN.
Therefore, the total number of the transmission paths required to be configured by the radio bearer can be determined by the MN, the total number of the transmission paths is indicated to the SN, the SN can automatically determine the number of the transmission paths required to be configured by the SN and feed back the number of the transmission paths to the MN, and the further MN can determine the number of the transmission paths required to be configured by the MN according to the number of the transmission paths configured by the SN.
Example 3
In example 3, as shown in fig. 7, the corresponding configuration negotiation process may include the following steps:
s1: the MN sends a configuration request message to the SN.
Wherein the configuration request message is used for requesting to negotiate a transmission path corresponding to a radio bearer (such as SRB1 or DRB 2). The configuration request message includes the following contents:
a radio bearer identity; such as SRB ID or DRB ID;
the MN suggests the number of transmission paths required to be configured by the SN;
the applicable data transmission direction; such as uplink only, downlink only, or both uplink and downlink.
S2: after receiving the configuration request message sent by the MN, the SN sends a configuration response message to the MN.
Wherein the configuration response message is any one of the following:
configuration confirmation information of a transmission path corresponding to the radio bearer;
configuration change information of a transmission path corresponding to the radio bearer;
configuration reject message of transmission path corresponding to radio bearer.
Further, the configuration confirmation message may include at least one of the following:
an identification of one or more transmission paths of the SN configuration; for example, the identifier may be selected as LCID, and/or RLC entity identifier;
a default transmission path; for example, the number of the default transmission paths may be selected as one or more; the default transmission path may be a path through which the radio bearer may perform data transmission through the SN after the PDCP data copy function of the corresponding radio bearer is deactivated;
an initially active transmission path; for example, the number of the initially activated transmission paths may be selected to be one or more.
Further, the configuration change message may include at least one of:
the number of transmission paths configured by SN;
the reason why the SN changes the number of transmission paths; the number of the transmission paths is that the MN suggests SN to be configured, or the number of the transmission paths is that the MN determines the number of the transmission paths that the SN needs to be configured according to the total number of the transmission paths that the MN determines to be configured for the radio bearer, the number of the transmission paths that the MN configures, and the number of the transmission paths that the SN needs to be configured; for example, the reason may be that the current LCID resource is insufficient, thus reducing the number of transmission paths configured by the SN;
an identification of one or more transmission paths of the SN configuration; for example, the identifier may be selected as LCID, and/or RLC entity identifier;
a default transmission path; for example, the number of the default transmission paths may be selected as one or more; the default transmission path may be a path through which the radio bearer may perform data transmission through the SN after the PDCP data copy function of the corresponding radio bearer is deactivated;
the initially active transmission path.
Further, the configuration rejection message may include:
a reason for rejection; for example, the reason for rejection may be that the current LCID resource is insufficient, or the active cell corresponding to the current SN is overloaded.
S3: after receiving the configuration response message sent by the SN, the MN performs at least one of the following operations:
determining the number of transmission paths configured by the MN according to the number of transmission paths configured by the SN and the configurable maximum total number of transmission paths of the radio bearer agreed in advance (for example agreed by a protocol);
sending a configuration message of a transmission path corresponding to a radio bearer to a terminal; the configuration message includes at least one of transmission path information configured by the MN and transmission path information configured by the SN.
Therefore, under the condition that the MN does not determine the total number of the transmission paths needing to be configured by the radio bearer, the MN indicates the number of the transmission paths needing to be configured by the SN, the SN can change the number of the transmission paths needing to be configured by the SN and feed back the number to the MN, and the subsequent MN determines the number of the transmission paths needing to be configured by the MN.
Example 4
In example 4, as shown in fig. 7, the corresponding configuration negotiation process may include the following steps:
s1: the MN sends a configuration request message to the SN.
Wherein the configuration request message is used for requesting to negotiate a transmission path corresponding to a radio bearer (such as SRB1 or DRB 2). The configuration request message includes the following contents:
a radio bearer identity; such as SRB ID or DRB ID;
the number of transmission paths configured by the MN, or the number of transmission paths required to be configured by the SN suggested by the MN;
the applicable data transmission direction; such as uplink only, downlink only, or both uplink and downlink.
S2: after receiving the configuration request message sent by the MN, the SN sends a configuration response message to the MN.
Wherein the configuration response message is any one of the following:
configuration confirmation information of a transmission path corresponding to the radio bearer;
configuration reject message of transmission path corresponding to radio bearer.
Further, the configuration confirmation message may include at least one of the following:
the number of transmission paths configured by SN;
an identification of one or more transmission paths of the SN configuration; for example, the identifier may be selected as LCID, and/or RLC entity identifier;
a default transmission path; for example, the number of the default transmission paths may be selected as one or more; the default transmission path may be a path through which the radio bearer may perform data transmission through the SN after the PDCP data copy function of the corresponding radio bearer is deactivated;
an initially active transmission path; for example, the number of the initially activated transmission paths may be selected to be one or more.
Further, the configuration rejection message may include:
a reason for rejection; for example, the reason for rejection may be that the current LCID resource is insufficient, or the active cell corresponding to the current SN is overloaded.
S3: after receiving the configuration response message sent by the SN, the MN performs at least one of the following operations:
adjusting the number of transmission paths configured by the MN according to the number of the transmission paths configured by the SN and the maximum total number of the transmission paths configurable by the pre-agreed radio bearer;
sending a configuration message of a transmission path corresponding to a radio bearer to a terminal; the configuration message includes at least one of transmission path information configured by the MN and transmission path information configured by the SN.
Therefore, the MN can indicate the quantity of the transmission paths configured by the MN to the SN under the condition that the MN does not determine the total quantity of the transmission paths required to be configured by the radio bearer, the SN can automatically determine the quantity of the transmission paths configured by the MN and feed back the quantity to the MN, and the MN can further adjust the quantity of the transmission paths required to be configured by the MN according to the quantity of the transmission paths configured by the SN.
Example 5
In example 5, as shown in fig. 7, the corresponding configuration negotiation process may include the following steps:
s1: the MN sends a configuration request message to the SN.
Wherein the configuration request message is used for requesting to negotiate a transmission path corresponding to a radio bearer (such as SRB1 or DRB 2). The configuration request message includes the following contents:
a radio bearer identity; such as SRB ID or DRB ID;
the applicable data transmission direction; such as uplink only, downlink only, or both uplink and downlink.
S2: after receiving the configuration request message sent by the MN, the SN sends a configuration response message to the MN.
Wherein the configuration response message is any one of the following:
configuration confirmation information of a transmission path corresponding to the radio bearer;
configuration reject message of transmission path corresponding to radio bearer.
Further, the configuration confirmation message may include at least one of the following:
the number of transmission paths configured by SN;
an identification of one or more transmission paths of the SN configuration; for example, the identifier may be selected as LCID, and/or RLC entity identifier;
a default transmission path; for example, the number of the default transmission paths may be selected as one or more; the default transmission path may be a path through which the radio bearer may perform data transmission through the SN after the PDCP data copy function of the corresponding radio bearer is deactivated;
an initially active transmission path; for example, the number of the initially activated transmission paths may be selected to be one or more.
Further, the configuration rejection message may include:
a reason for rejection; for example, the reason for rejection may be that the current LCID resource is insufficient, or the active cell corresponding to the current SN is overloaded.
S3: after receiving the configuration response message sent by the SN, the MN performs at least one of the following operations:
determining the number of transmission paths configured by the MN according to the number of the transmission paths configured by the SN and the maximum total number of the transmission paths configurable by the pre-agreed radio bearer;
sending a configuration message of a transmission path corresponding to a radio bearer to a terminal; the configuration message includes at least one of transmission path information configured by the MN and transmission path information configured by the SN.
Therefore, under the condition that the MN does not determine the total number of the transmission paths required to be configured by the radio bearer, the SN can automatically determine the number of the transmission paths configured by the SN and feed back the number of the transmission paths to the MN, and further the MN can automatically determine the number of the transmission paths configured by the MN.
It can be understood that, in the above example, the first network node is an MN and the second network node is an SN, but in other examples, the first network node may be an SN and the second network node is an MN, and the specific implementation process is similar, and will not be described herein again.
The above embodiments describe the configuration negotiation method of the present invention, and the network node of the present invention will be described with reference to the embodiments and the accompanying drawings.
Referring to fig. 8, fig. 8 is a schematic structural diagram of a network node according to an embodiment of the present invention, where the network node 80 is a first network node, and as shown in fig. 8, the network node 80 includes:
a first sending module 81, configured to send a configuration request message to a second network node;
wherein, the configuration request message is used for requesting to negotiate a transmission path corresponding to the radio bearer.
In the embodiment of the present invention, for example, under a DC architecture, by means of a negotiation process of the first and second network nodes, the configuration condition of the transmission path corresponding to the corresponding radio bearer by the other network node is known between the two network nodes, so that the resource condition of the network side node is effectively coordinated, and the number of the transmission paths corresponding to the radio bearer is flexibly configured.
Optionally, the network node 80 further includes:
a first receiving module for receiving a configuration response message from the second network node;
wherein the configuration response message is any one of the following:
configuration confirmation information of a transmission path corresponding to the radio bearer;
configuration change information of a transmission path corresponding to the radio bearer;
configuration reject message of transmission path corresponding to radio bearer.
Optionally, the configuration request message includes at least one of the following:
a radio bearer identity;
the total number of transmission paths which are needed to be configured by the radio bearer and are determined by the first network node;
the first network node suggests the number of transmission paths needed to be configured by the second network node;
the number of transmission paths configured by the first network node;
the applicable data transmission direction.
Optionally, the configuration confirmation message includes at least one of the following:
an identification of one or more transmission paths configured by the second network node;
the number of transmission paths configured by the second network node;
a default transmission path;
the initially active transmission path.
Optionally, the configuration change message includes at least one of the following:
the number of transmission paths configured by the second network node;
the reason why the second network node changes the number of transmission paths; the number of the transmission paths is that the first network node suggests that the second network node needs to be configured, or the number of the transmission paths is that the first network node determines that the second network node needs to be configured according to the total number of the transmission paths that the first network node determines that the radio bearer needs to be configured and the number of the transmission paths that the first network node configures;
an identification of one or more transmission paths configured by the second network node;
a default transmission path;
the initially active transmission path.
Optionally, the configuration rejection message includes:
reason for rejection.
Optionally, the network node 80 further includes:
an execution module to perform any one of the following operations:
adjusting the number of transmission paths configured by the first network node according to the number of transmission paths configured by the second network node and the total number of transmission paths determined by the first network node;
determining the number of transmission paths configured by the first network node according to the number of transmission paths configured by the second network node and the total number of transmission paths determined by the first network node;
determining the number of transmission paths configured by the first network node according to the number of transmission paths configured by the second network node and the pre-agreed maximum total number of transmission paths configurable by the radio bearer;
and adjusting the number of the transmission paths configured by the first network node according to the number of the transmission paths configured by the second network node and the maximum total number of the transmission paths configurable by the pre-agreed radio bearer.
Optionally, the network node 80 further includes:
a third sending module, configured to send a configuration message of a transmission path corresponding to the radio bearer to the terminal; wherein the configuration message includes at least one of transmission path information configured by the first network node and transmission path information configured by the second network node.
Optionally, the sending of the configuration request message is initiated by any one of the following manners:
a first network node initiates actively;
the second network node triggers the first network node to initiate.
Optionally, the reason for sending the configuration request message includes at least one of the following:
initially configuring a transmission path for a radio bearer;
adding a transmission path for the radio bearer;
deleting transmission paths for radio bearers;
the transmission path is changed for the radio bearer.
Optionally, the network node 80 further includes:
the starting module is used for starting the timer;
a determining module, configured to determine that the second network node refuses to respond to the configuration request message when the timer expires and a configuration response message is not received from the second network node;
a stopping module for stopping the timer when a configuration response message is received from the second network node before the timer expires.
Optionally, the first network node is an MN, and the second network node is an SN;
or, the first network node is a SN, and the second network node is a MN.
Wherein the first network node is a network node where a PDCP entity of the radio bearer is located.
Referring to fig. 9, fig. 9 is a schematic structural diagram of a network node according to an embodiment of the present invention, where the network node 90 is a second network node, and as shown in fig. 9, the network node 90 includes:
a second receiving module 91, configured to receive a configuration request message from a first network node;
wherein, the configuration request message is used for requesting to negotiate a transmission path corresponding to the radio bearer.
In the embodiment of the present invention, for example, under a DC architecture, by means of a negotiation process of the first and second network nodes, the configuration condition of the transmission path corresponding to the corresponding radio bearer by the other network node is known between the two network nodes, so that the resource condition of the network side node is effectively coordinated, and the number of the transmission paths corresponding to the radio bearer is flexibly configured.
Optionally, the network node 90 further includes:
a second sending module, configured to send a configuration response message to the first network node;
wherein the configuration response message is any one of the following:
configuration confirmation information of a transmission path corresponding to the radio bearer;
configuration change information of a transmission path corresponding to the radio bearer;
configuration reject message of transmission path corresponding to radio bearer.
Optionally, the configuration request message includes at least one of the following:
a radio bearer identity;
the total number of transmission paths which are needed to be configured by the radio bearer and are determined by the first network node;
the first network node suggests the number of transmission paths needed to be configured by the second network node;
the number of transmission paths configured by the first network node;
the applicable data transmission direction.
Optionally, the configuration confirmation message includes at least one of the following:
an identification of one or more transmission paths configured by the second network node;
the number of transmission paths configured by the second network node;
a default transmission path;
the initially active transmission path.
Optionally, the configuration change message includes at least one of the following:
the number of transmission paths configured by the second network node;
the reason why the second network node changes the number of transmission paths; the number of the transmission paths is that the first network node suggests that the second network node needs to be configured, or the number of the transmission paths is that the first network node determines that the second network node needs to be configured according to the total number of the transmission paths that the first network node determines that the radio bearer needs to be configured and the number of the transmission paths that the first network node configures;
an identification of one or more transmission paths configured by the second network node;
a default transmission path;
the initially active transmission path.
Optionally, the configuration rejection message includes: reason for rejection.
Optionally, the first network node is an MN, and the second network node is an SN;
or, the first network node is a SN, and the second network node is a MN.
Wherein the first network node is a network node where a PDCP entity of the radio bearer is located.
The embodiment of the present invention further provides a network node, which includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein when executed by the processor, the computer program implements each process of the configuration negotiation method embodiment applied to the network node, and can achieve the same technical effect, and is not described herein again to avoid repetition. Optionally, the network node is a first network node or a second network node.
Specifically, fig. 10 is a schematic diagram of a hardware structure of a network node for implementing various embodiments of the present invention, where the network node 110 includes, but is not limited to: bus 111, transceiver 112, antenna 113, bus interface 114, processor 115, and memory 116.
In this embodiment of the present invention, the network node 110 further includes: a computer program stored in the memory 116 and capable of running on the processor 115, where the computer program, when executed by the processor 115, may implement the processes of the configuration negotiation method embodiment applied to the first network node or the processes of the configuration negotiation method embodiment applied to the second network node, and may achieve the same technical effects, and in order to avoid repetition, details are not described here again.
A transceiver 112 for receiving and transmitting data under the control of a processor 115.
In FIG. 10, a bus architecture (represented by bus 111), bus 111 may include any number of interconnected buses and bridges, bus 111 linking together various circuits including one or more processors, represented by processor 115, and memory, represented by memory 116. The bus 111 may also link together various other circuits such as peripherals, voltage regulators, power management circuits, and the like, which are well known in the art, and therefore, will not be described any further herein. A bus interface 114 provides an interface between the bus 111 and the transceiver 112. The transceiver 112 may be one element or may be multiple elements, such as multiple receivers and transmitters, providing a means for communicating with various other apparatus over a transmission medium. The data processed by the processor 115 is transmitted over a wireless medium via the antenna 113, and further, the antenna 113 receives the data and transmits the data to the processor 115.
The processor 115 is responsible for managing the bus 111 and general processing and may also provide various functions including timing, peripheral interfaces, voltage regulation, power management, and other control functions. And the memory 116 may be used to store data used by the processor 115 in performing operations.
Alternatively, the processor 115 may be a CPU, ASIC, FPGA or CPLD.
An embodiment of the present invention further provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when executed by a processor, the computer program may implement each process of the configuration negotiation method embodiment applied to the first network node or each process of the configuration negotiation method embodiment applied to the second network node, and may achieve the same technical effect, and in order to avoid repetition, details are not described here again. The computer-readable storage medium is, for example, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
Through the above description of the embodiments, those skilled in the art will clearly understand that the method of the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better implementation manner. Based on such understanding, the technical solutions of the present invention may be embodied in the form of a software product, which is stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal (such as a mobile phone, a computer, a server, an air conditioner, or a network node) to execute the method according to the embodiments of the present invention.
While the present invention has been described with reference to the embodiments shown in the drawings, the present invention is not limited to the embodiments, which are illustrative and not restrictive, and it will be apparent to those skilled in the art that various changes and modifications can be made therein without departing from the spirit and scope of the invention as defined in the appended claims.