CN106941700A

CN106941700A - A kind of data transmission method and device and base station and UE

Info

Publication number: CN106941700A
Application number: CN201610005639.8A
Authority: CN
Inventors: 施小娟; 黄河
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2016-01-04
Filing date: 2016-01-04
Publication date: 2017-07-11
Anticipated expiration: 2036-01-04
Also published as: CN106941700B; WO2017118186A1

Abstract

The invention discloses a kind of data transmission method and device and base station and UE, including：It is to need to use the RB of SeNB resources to set up preliminary data transmission channel on MCG；During SeNB changes, data are transmitted using preliminary data transmission channel, wherein, the data of transmission are at least included in the RLC entities that source SCG is had been distributed to before SeNB changes but the data that transmission is not completed in source SCG.The foundation that the technical scheme that the present invention is provided passes through preliminary data transmission channel, during SeNB changes, data are transmitted using preliminary data transmission channel, ensure that SeNB change during data transfer continuity, realize the smooth transfer of data, user data transmission speed is improved, so as to enhance Consumer's Experience.

Description

Data transmission method and device, base station and UE

Technical Field

The present invention relates to mobile communication technologies, and in particular, to a data transmission method and apparatus, a base station, and a UE.

Background

Cellular wireless mobile communication systems began in the 80's of the 20 th century and have evolved from meeting the human voice communication needs at the outset to gradually meet the human basic data communication needs at a later date based on voice services. A conventional cellular wireless communication system is deployed and operated by a wireless network operator, the network construction is carefully planned by the operator, fig. 1 is a schematic diagram of a network topology of a conventional cellular wireless access network, as shown in fig. 1, the selection of each macro base station (macro (e) NB) is determined by the plan of the operator, and each macro base station can achieve wireless coverage of hundreds of meters or even thousands of meters, thereby achieving nearly continuous seamless coverage in an operation area of the operator.

With the advent of the mobile internet age, there has been a explosive growth in new mobile application requirements, particularly those requiring high quality, high rate, low latency. According to the industry prediction, on one hand, the wireless mobile service volume will be increased by thousands of times in the next 10 years, and the traditional wireless communication system realizing long-distance macro coverage cannot realize the huge capacity requirement; on the other hand, the industry finds that most of mobile services with high data traffic are concentrated in indoor environments and hot spots, such as shopping malls, schools, user homes, large-scale performances, meeting places and the like, and the indoor environments and the hot spots have the characteristics of wide and scattered area distribution, small single-area range, concentrated users and the like, that is, the characteristics of wide coverage, uniform coverage and fixed coverage of the traditional cellular wireless network make the wireless network not well adapt to the characteristic of concentrated service occurrence in the small-area range. In addition, the cellular wireless network may cause cellular wireless signals in indoor environment to be inferior to outdoor environment due to various reasons, such as blocking of buildings, which also makes the cellular wireless network unable to meet the large data capacity requirement in future indoor environment.

In order to solve the above problem, a Low Power Node (LPN) is developed. Conceptually, the LPN refers to a base station Node having a lower transmission power than that of a conventional macro base station and a smaller coverage area (for example, several tens of meters) than that of the conventional macro base station, and specifically may be a micro base station (Pico Node), a home base station (Femto/home (e) NB), a radio Relay access device (Relay), and any other base station Node or network access Node of a wireless network that may be present and satisfy the above concept. In contrast to a macro cell (macro cell) under coverage of a macro base station, which may cover several hundred meters or even several kilometers, a cell covering several tens of meters under coverage of an LPN is referred to as a small cell (small cell).

To meet the huge capacity increase demand of future wireless communication systems, especially to adapt to the centralized large data volume demand in a specific area, the industry predicts that the LPN deployment density can be increased in a specific area to realize the increase of network capacity and meet the user demand. Such a Network densely deployed in a specific area is referred to as an Ultra Dense Network (UDN) by the industry. Figure 2 is a schematic diagram of UDNs deployed in a particular area of a conventional cellular radio access network, as shown in figure 2, where a large number of low power nodes are deployed in a building 200, in a stadium 210, in a hotspot 230 area.

After the UDN network is deployed, when a User Equipment/User terminal (UE) moves in such a dense network, compared to an original macro network with wide coverage, even if the UE moves at a walking speed, the small cell may be frequently changed, and as shown by a moving path 240 of the UE shown by a thick solid arrow in fig. 2, the UE may frequently change the small cell in a short time. In the related art, when the UE moves between different cells, a handover technique is used to implement the continuous transmission of data between different cells, and the handover technique provided in the related art is suitable for a wide-coverage macro network or a non-densely deployed network.

Disclosure of Invention

The invention provides a method and a device for realizing data transmission, a base station and UE, which can realize smooth transmission of data and improve the data transmission rate of a user, thereby enhancing the user experience.

In order to achieve the object of the present invention, the present invention provides a data transmission method, including: establishing a standby data transmission path for a radio bearer RB needing to use the secondary base station SeNB resource on a master control service cell group MCG;

during the SeNB change, data is transmitted using a backup data transmission path, wherein the transmitted data comprises at least data that has been distributed to the radio link control, RLC, entity of the source secondary serving cell group, S-SCG, but has not completed transmission at S-SCG, prior to the SeNB change.

Optionally, the method further comprises, before: establishing the RB needing to use the SeNB resource;

the establishing of the standby data transmission path comprises:

when the RB needing to use the SeNB resource is established, the standby data transmission path is established for the RB; or,

and when the SeNB is changed, establishing the standby data transmission path for the established RB needing to use the SeNB resource.

Optionally, the spare data transmission path is: a backup forked bearer of RBs using SeNB resources is required, or a backup forked logical channel of RBs using SeNB resources is required.

Optionally, the backup data transmission path is a backup split bearer;

the standby forked bearer comprises at least one standby RLC entity and at least one standby logical dedicated traffic channel DTCH.

Optionally, the backup data transmission path is a backup split bearer;

the standby forked bearer uses the security configuration of the MCG, and the standby RLC entity included in the standby forked bearer is connected with a packet data control protocol PDCP entity which is established on the MCG by the RB needing to use the SeNB resource; or,

and the standby forked bearer uses the security configuration of the S-SCG, and the standby forked bearer comprises a standby RLC entity connected with a PDCP entity established on the S-SCG by the RB needing to use the SeNB resources.

Optionally, the spare data transmission path is a spare branched logical channel;

the standby forked logical channel comprises: at least one backup DTCH established for RBs using SeNB resources; wherein the standby DTCH is connected between the RLC entity on the MCG that has been set up for the RB that needs to use SeNB resources and the MAC entity on the MCG.

Optionally, the changing of the SeNB includes: after the MeNB to which the MCG belongs requests the target SeNB to allocate resources after the SeNB is changed and receives a positive reply of a target SeNB response;

or after the MeNB to which the MCG belongs receives data from the source SeNB that has been distributed to the RLC entity of the source SeNB before the SeNB change but has not completed transmission at the source SeNB;

or after the user terminal UE receives the notification message sent by the MeNB to which the MCG belongs.

Optionally, the transmitting data using the data transmission path includes:

when the standby data transmission path is a standby forked bearer, using one standby RLC entity and one standby DTCH in the at least one standby RLC entity and the at least one standby DTCH to transmit data;

when the standby data transmission path is a standby forked logical channel, one of the standby DTCHs and the RLC entity which is already established for the RB needing to use the SeNB resource are used for transmitting data.

Optionally, when the backup forked bearer uses the security configuration of the MCG, and the backup RLC entity is connected to a PDCP entity that is established on the MCG by an RB that needs to use SeNB resources, the transmitted data includes:

PDCP packet data packet PDUs distributed by the PDCP entity of the MCG to the RLC entity of the S-SCG but not completed in the S-SCG.

Optionally, the transmitted data further includes:

and the PDCP PDUs which are transmitted by the PDCP entity of the MCG except the PDCP PDUs which are distributed to the RLC entity of the S-SCG by the PDCP entity of the MCG but are not transmitted in the S-SCG are transmitted.

Optionally, when the standby forked bearer uses the security configuration of the S-SCG, and the standby RLC entity is connected to the PDCP entity that is established on the S-SCG by the RB that needs to use the SeNB resource, the transmitted data includes:

and the source SeNB receives downlink data from the core network but does not finish transmission at the source SeNB, and the generated PDCP PDU is processed by a PDCP entity established on the source SeNB by the RB needing to use the SeNB resource.

Optionally, the transmitted data includes: PDCP PDUs distributed by the PDCP entity of the MCG to the RLC entity of the source SCG but not completed in transmission at the source SCG.

Optionally, the transmitted data further includes: and the other PDCP PDUs sent by the PDCP entity of the MCG except the PDCP PDUs which are distributed to the RLC entity of the source SCG by the PDCP entity of the MCG but are not completely transmitted in the source SCG.

Optionally, the method further comprises: and stopping transmitting data by using the standby data transmission path.

Optionally, when the backup data transmission path is a backup forked bearer and the backup forked bearer on the MCG uses the security configuration of the MCG, the backup RLC entity is connected to a PDCP entity established on the MCG by an RB that needs to use SeNB resources, or the backup data transmission path is a backup forked logical channel,

the stopping of the transmission of data using the standby forked bearer comprises:

after the UE successfully accesses the target SeNB after the SeNB is changed, the UE informs the MeNB to which the MCG belongs, the UE stops using the standby data transmission path to transmit data, and the MeNB to which the MCG belongs stops using the standby data transmission path to transmit data after receiving the notice; or,

the UE stops using the standby data transmission path to transmit data after successfully accessing the target SeNB after the SeNB is changed, the target SeNB sends a notification that the UE has successfully accessed to the MeNB to which the MCG belongs, and the MeNB to which the MCG belongs stops using the standby data transmission path to transmit data after receiving the notification; or,

and the UE stops using the standby data transmission path to transmit data after receiving the change notice of the SeNB sent by the MeNB to which the MCG belongs for a preset time T.

Optionally, when the backup data transmission path is a backup forked bearer and the security configuration of the S-SCG is performed, and the backup RLC entity is connected to a PDCP entity that is established on the S-SCG by an RB that needs to use SeNB resources, the stopping of using the backup forked bearer to transmit data includes:

and when the transmission of the downlink data which is received by the source SeNB from the core network but is not transmitted in the source SeNB is finished in the standby data transmission path, stopping transmitting the data by using the standby data transmission path.

Optionally, the method further comprises: and the standby RLC entity is connected with a PDCP entity which is established on a target SCG T-SCG after the change of the SeNB by the RB needing to use the SeNB resources, and uses the security configuration of the T-SCG.

The present invention also provides a data transmission apparatus, comprising:

the establishing module is used for establishing a standby data transmission path for the RB needing to use the SeNB resource on the MCG;

and a data transmission module, configured to transmit data using the standby data transmission path during the SeNB change, where the transmitted data includes at least data that has been distributed to the RLC entity of the S-SCG but has not been completely transmitted in the S-SCG before the SeNB change.

Optionally, the establishing module is specifically configured to: when the RB needing to use the SeNB resource is established, a standby data transmission path is established for the RB; or when the SeNB is changed, establishing a standby data transmission path for the established RB needing to use the SeNB resource.

Optionally, the backup data transmission path is a backup split bearer;

the backup forked bearer comprises at least one backup RLC entity and at least one backup DTCH.

Optionally, the backup data transmission path is a backup split bearer;

the standby forked bearer uses the security configuration of the MCG, and a standby RLC entity included in the standby forked bearer is connected with a PDCP entity established on the MCG by an RB needing to use SeNB resources; or,

the standby forked bearer uses the security configuration of the S-SCG, and the standby RLC entity included in the standby forked bearer is connected with the PDCP entity established on the S-SCG by the RB needing to use the SeNB resources.

Optionally, when the apparatus is separately disposed in a network side or an MeNB, the data transmission module is specifically configured to:

after the MeNB to which the MCG belongs requests the target SeNB to allocate resources after the SeNB is changed and receives a positive reply of a target SeNB response, transmitting data by using a standby data transmission path;

or, after the MeNB to which the MCG belongs receives data from the source SeNB that has been distributed to the RLC entity of the source SeNB before the SeNB change but has not completed transmission at the source SeNB, transmitting the data using the spare data transmission path.

Optionally, when the apparatus is separately disposed in a user side or a UE, the data transmission module is specifically configured to: and after receiving the notification message sent by the MeNB to which the MCG belongs, the UE transmits data by using the standby data transmission path.

Optionally, when the standby data transmission path is a standby forked bearer, the data transmission module is specifically configured to: transmitting data using one of at least one standby RLC entity and at least one standby DTCH established for RBs requiring use of SeNB resources;

when the spare data transmission path is a spare fork logical channel, the data transmission module is specifically configured to: data is transmitted using one of the at least one backup DTCH and the RLC entities that have been established for the RBs that need to use the SeNB resources.

Optionally, the setup module establishes a backup forked bearer on the MCG using security configuration of the MCG, and when the backup RLC entity is connected to a PDCP entity established on the MCG by an RB that needs to use SeNB resources,

the data transmitted by the data transmission module comprises: PDCP PDUs distributed by the PDCP entity of the MCG to the RLC entity of the S-SCG but not completed in the S-SCG.

Optionally, the data transmitted by the data transmission module further includes: and the PDCP PDUs which are transmitted by the PDCP entity of the MCG except the PDCP PDUs which are distributed to the RLC entity of the S-SCG by the PDCP entity of the MCG but are not transmitted in the S-SCG are transmitted.

Optionally, the setup module establishes a backup forked bearer on the MCG using security configuration of the SCG, and when the backup RLC entity is connected to a PDCP entity established on the SCG by an RB that needs to use SeNB resources,

the data transmitted by the data transmission module comprises: and the source SeNB receives downlink data from the core network but does not finish transmission at the source SeNB, and the generated PDCP PDU is processed by a PDCP entity established on the source SeNB by the RB needing to use the SeNB resources.

Optionally, the data transmitted by the data transmission module includes: PDCP PDUs distributed by the PDCP entity of the MCG to the RLC entity of the source SCG but not completed in transmission at the source SCG.

Optionally, the data transmitted by the data transmission module further includes: and the other PDCP PDUs sent by the PDCP entity of the MCG except the PDCP PDUs which are distributed to the RLC entity of the source SCG by the PDCP entity of the MCG but are not completely transmitted in the source SCG.

Optionally, the setup module establishes a backup forked bearer on the MCG using security configuration of the MCG, and when the established backup RLC entity is connected to a PDCP entity established on the MCG by an RB that needs to use SeNB resources, or when the backup data transmission path is a backup forked logical channel,

when the apparatus is separately provided in a user side or a UE, the data transmission module is further configured to: stopping transmitting data by using the standby data transmission path after the UE successfully accesses the target SeNB after the SeNB is changed or the UE receives a change notification of the SeNB sent by the MeNB to which the MCG belongs for a preset time T;

when the apparatus is separately disposed in a network side or an MeNB, the data transmission module is further configured to: and stopping transmitting data by using the standby data transmission path after the MeNB to which the MCG belongs receives the notification that the UE or the UE of the target SeNB after the SeNB is changed successfully accesses the target SeNB after the SeNB is changed.

Optionally, the setup module establishes a backup forked bearer on the MCG using security configuration of the SCG, and when the backup RLC entity is connected with a PDCP entity established on the SCG by an RB that needs to use SeNB resources,

when the apparatus is separately disposed in a network side or an MeNB, the data transmission module is further configured to: and after the transmission of the downlink data which is received by the source SeNB from the core network but is not transmitted by the source SeNB is finished, stopping transmitting the data by using the standby data transmission channel.

The invention further provides a base station comprising the apparatus of any of the above. A UE comprising the apparatus of any of the above.

The present invention further provides a computer-readable storage medium storing computer-executable instructions for performing any of the above-described data transmission methods.

Compared with the prior art, the technical scheme of the application comprises the following steps: establishing a standby data transmission path for the RB needing to use the SeNB resource on the MCG; during the SeNB change, data is transmitted using the backup data transmission path, wherein the transmitted data includes at least data that has been distributed to the RLC entity of the source SCG prior to the SeNB change but has not completed transmission at the source SCG. According to the technical scheme provided by the invention, the standby data transmission path is used for transmitting data in the change process of the SeNB through the establishment of the standby data transmission path, so that the continuity of data transmission in the change process of the SeNB is ensured, the smooth transmission of the data is realized, the data transmission rate of a user is improved, and the user experience is enhanced.

Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objectives and other advantages of the invention will be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

Drawings

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the invention and together with the description serve to explain the invention without limiting the invention. In the drawings:

fig. 1 is a schematic diagram of a network topology of a related art cellular radio access network;

figure 2 is a schematic diagram of deployment of UDNs within a particular area of a conventional cellular radio access network;

FIG. 3 is a diagram illustrating a DC 3C protocol architecture in the related art;

FIG. 4 is a diagram illustrating a DC 1A protocol architecture in the related art;

FIG. 5 is a flow chart of a method for implementing data transmission according to the present invention;

FIG. 6 is a flowchart illustrating a first embodiment of implementing data transmission according to the present invention;

fig. 7(a) is a radio protocol architecture diagram of a downlink split bearer established on the base station side and one spare split bearer thereof in the first embodiment of the present invention;

fig. 7(b) is a radio protocol architecture diagram on the UE side, corresponding to the radio protocol architecture diagram on the base station side in fig. 7(a), in accordance with the first embodiment of the present invention;

fig. 7(c) is a radio protocol architecture diagram of a downlink split bearer and a standby split logical channel established on the base station side in the first embodiment of the present invention;

fig. 7(d) is a radio protocol architecture diagram on the UE side, which corresponds to the radio protocol architecture diagram on the base station side of fig. 7(c), according to the first embodiment of the present invention;

fig. 8 is a radio protocol architecture diagram of an uplink split bearer established at the UE side and one of the standby split bearers according to the first embodiment of the present invention;

fig. 9 is a radio protocol architecture diagram of a downlink split bearer and two standby split bearers thereof established by the present invention;

FIG. 10 is a flow chart illustrating another embodiment of the present invention for implementing data transmission;

FIG. 11 is a flowchart illustrating a second embodiment of data transmission according to the present invention;

fig. 12(a) is a schematic radio protocol architecture of a secondary enb before changing a downlink split bearer according to a second embodiment of the present invention;

fig. 12(b) is a schematic diagram of a radio protocol architecture of a downlink split bearer in a SeNB change process according to a second embodiment of the present invention;

fig. 12(c) is a schematic diagram of a radio protocol architecture of a downlink split bearer after a change of the SeNB according to the second embodiment of the present invention;

FIG. 13 is a flowchart illustrating a third embodiment of data transmission according to the present invention;

fig. 14(a) is a radio protocol architecture diagram of a downlink split bearer established on the base station side and one spare split bearer thereof in the third embodiment of the present invention;

fig. 14(b) is a radio protocol architecture diagram of an uplink split bearer established on the UE side and one of its standby split bearers in a third embodiment of the present invention;

FIG. 15 is a flowchart illustrating a fourth embodiment of data transmission according to the present invention;

fig. 16(a) is a schematic diagram of a radio protocol architecture of a downlink SCG bearer before a SeNB changes a bearer in a fourth embodiment of the present invention;

fig. 16(b) is a schematic diagram of a radio protocol architecture of a downlink SCG bearer in a SeNB change process according to a fourth embodiment of the present invention;

fig. 16(c) is a schematic diagram of a radio protocol architecture of a downlink SCG bearer after a SeNB is changed in the fourth embodiment of the present invention;

fig. 17 is a schematic structural diagram of an apparatus for implementing data transmission according to the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention more apparent, embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be noted that the embodiments and features of the embodiments in the present application may be arbitrarily combined with each other without conflict.

Taking Long Term Evolution (LTE) as an example, in a conventional macro network, when a UE performing service transmission moves from one macro cell to another macro cell, a hard handover mode is adopted, that is, the UE is disconnected from a source macro cell first and then accesses a target macro cell. In order to prevent data interruption in the process, the source macro cell sends data that is not transmitted in the source macro cell or has been transmitted but has not been successfully transmitted to the target macro cell, which is referred to as data forwarding (data forwarding) in the industry, and data forwarding ensures data connection transmission in the hard handover process. Although data forwarding can ensure lossless (lossless) continuous transmission of data in the cell change process, in the hard handover mode, no data can be transmitted between the UE and the network in the time (referred to as data interruption transmission time herein) from the disconnection of the UE from the source cell to the successful access of the UE to the target cell until data transmission can be started in the target cell, so that the data rate of the user is inevitably reduced. When the UE can start data Transmission in the target cell, due to the data Transmission rate sliding caused by the Transmission time interruption of the previous data, the processing mechanism of the existing related communication Protocol, such as the slow start mechanism of the Transmission Control Protocol (TCP), causes the data rate to rise as a process of ascending a ramp, and cannot directly recover the data Transmission rate of the UE in the source cell before handover, that is, the hard handover process inevitably causes the data Transmission rate to fall. Since the coverage radius of the conventional macro network cell is large, in terms of statistical probability, compared with the service transmission life cycle of the UE, the probability of cell change, that is, hard handover, of the UE is low, and the influence on the overall service transmission rate of the UE is not large.

In order to improve the user throughput and the system throughput, a Dual Connectivity (DC) function is introduced in the 3GPP R12 stage, and a UE can be connected to two base stations at the same time, and perform traffic data transmission on the two base stations at the same time. Among two base stations connected to the UE, one base station terminates a control plane interface between a radio access network and a core network, that is, an S1-mobility management entity (S1-MME) interface, called a Master base station (MeNB, Master eNB), one or more serving cells of the UE on the MeNB are called Master serving Cell groups (MCG, Master Cell Group), among the one or more serving cells of the MCG, one of the cells is a Primary Cell (Pcell, Primary Cell), the Pcell establishes an initial connection between the UE and the MeNB, or reestablishes a connected Cell, or the MeNB is designated as a Cell of the Pcell during handover, the other remaining cells are secondary cells on the MeNB, the secondary Cell on the MeNB provides additional resources between the MeNB and the UE, and when only one serving Cell exists on the MCG, the serving Cell is the Pcell; another base station provides additional radio resources for the UE, which is called a Secondary base station (SeNB, Secondary eNB), one or more serving cells of the UE on the SeNB are called a Secondary Serving Cell Group (SCG), one of the one or more serving cells of the SCG is a Primary Secondary Cell (PScell), the PScell is a Cell performing random access between the UE and the SeNB, the other remaining serving cells are Secondary cells on the SeNB, the Secondary Cell on the SeNB provides additional resources between the SeNB and the UE, and when there is only one serving Cell on the SCG, the serving Cell is the PScell. In DC, the UE is connected to two base stations simultaneously, and there can be two architectures from the radio protocol stack, referred to in the industry as architecture 3C and architecture 1A.

Fig. 3 is a schematic diagram of a DC 3C protocol architecture in the related art, and as shown in fig. 3, a UE is simultaneously connected to an MeNB and an SeNB, where the MeNB terminates a control plane interface between a radio access network and a core network on one hand, and also terminates a User plane (S1-U, User plane) interface between the radio access network and the core network on the other hand (S1 interface is a User plane interface between a base station and the core network). As shown in fig. 3, in the 3C downlink architecture, there are two Radio bearers (RBs, Radio bearers), that is, RB1 and RB2, where all Radio protocol stacks of RB1 are located on the MeNB, and only Radio resources of the MeNB can be used, which are called Master Cell Group Bearer (MCG Bearer), and a Radio protocol stack of RB2 may be located on both the MeNB and the SeNB, and may simultaneously use Radio resources of the MeNB and the SeNB, which are called split Bearer (split Bearer). Specifically, a Packet Data Convergence Protocol (PDCP) of RB2 is located on the MeNB, and protocols below the PDCP include a Radio Link Control (RLC) Protocol, a Media Access Control (MAC) Protocol, and the like both on the MeNB and the SeNB, so that, taking downlink Data as an example, when a Packet arrives at the MeNB through the S1-U interface, the PDCP of the MeNB performs header compression, encryption, and the like to generate a PDCP PDU, and the MeNB transmits a generated PDCP PDU portion to the RLC layer of RB2 in the MeNB and transmits a portion to the RLC layer of RB2 in the SeNB, thereby realizing that Data of RB2 is transmitted simultaneously between the MeNB and the SeNB, and improving the throughput rate of user Data.

Fig. 4 is a schematic diagram of a DC 1A protocol architecture in the related art, and as shown in fig. 4, a UE is simultaneously connected to an MeNB and an SeNB, and in the 1A architecture, there are independent S1-U interfaces between the MeNB and the SeNB and a core network, respectively. As shown in fig. 4, in the 1A downlink architecture, there are two RBs, that is, RB3 and RB4, and all radio protocol stacks of the two RBs are independently located on their respective enbs, where RB1 can only use radio resources of MeNB, which is MCG bearer; however, RB2 can only use SeNB radio resources, and is called Secondary Cell Group bearer (SCG bearer).

In R12 DC, the MeNB is typically a macro base station, the SeNB is typically an LPN, and regardless of the DC 1A architecture or the DC 3C architecture, there are RBs that need to use the SeNB resources, and when the SeNB changes, the MeNB deletes the source SeNB and adds the target SeNB on the radio interface, which is a hard handover behavior in nature, and causes a drop in the user data rate, such as a drop in the RB2 data rate in fig. 3 and a drop in the RB4 data rate in fig. 4, within the time when the UE disconnects from the source SeNB to successfully access the target SeNB and can perform data transmission in the target SeNB. In a network in which the SeNB deployment is not dense, frequent change of the SeNB does not occur, so the above problem does not significantly affect the user service experience, however, in future UDNs, dense deployment of small cells may cause frequent change of the SeNB even if the UE moves at walking speed, and at this time, it inevitably causes a zigzag jitter of user data throughput, and cannot provide smooth and consistent user experience for the user.

Fig. 5 is a flowchart of a method for implementing data transmission according to the present invention, as shown in fig. 5, including:

step 500: a backup data transmission path is established on the MCG for RBs that need to use SeNB resources.

The spare data transmission path in this step is a spare forked bearer of the RB that needs to use the SeNB resource, or a spare forked logical channel of the RB that needs to use the SeNB resource.

Specifically, when the standby data transmission path is a standby forked bearer:

at least one standby RLC entity and at least one standby logical Dedicated Traffic CHannel (DTCH) may be established on the MCG as standby forked bearers for RBs that need to use SeNB resources. The standby DTCH is used for connecting the standby RLC entity and the MAC entity on the MCG, namely the standby RLC entity sends data to the MAC entity on the MCG through the standby DTCH, and the standby RLC entity receives the data sent by the MAC entity on the MCG through the standby DTCH. Here, the standby RLC entity transmits data to the MAC entity on the MCG through the standby DTCH means that the standby RLC entity transmits data to the standby DTCH, and the MAC entity on the MCG receives the data from the standby DTCH. It should be noted that, here, data is mutually transmitted (or referred to as transfer) between the standby RLC entity and the MAC entity on the MCG through the standby DTCH, and when the implementation is specifically implemented, the following may be adopted: for data transmitted by different DTCHs, different memory pointers are adopted, for example, when data is transmitted to a MAC entity from a standby RLC entity 1 connected to a standby DTCH1 through a standby DTCH1, a pointer 1 used by the standby DTCH1 is transmitted to the MAC entity from the standby RLC entity 1, and the MAC entity accesses the data pointed by the pointer 1 according to the received pointer 1, that is, when the data is specifically implemented, the data is mutually transmitted (or transferred) between the standby RLC entity and the MAC entity on the MCG through the standby DTCH, and the storage position of the actual data in the storage space does not necessarily need to be really moved.

the standby fork bearer on the MCG uses the security configuration of the MCG, and the standby RLC entity is connected with a PDCP entity which is established on the MCG by the RB needing to use the SeNB resource; or,

the standby forked bearer on the MCG uses the security configuration of the SCG, and the standby RLC entity is connected with the PDCP entity of the RB that needs to use the SeNB resource, which is established on the SCG, i.e., the source SCG (S-SCG) during the change of the SeNB.

Specifically, when the backup data transmission path is a backup branched logical channel,

at least one standby logical Dedicated Traffic Channel (DTCH) can be established on the MCG for RBs that need to use SeNB resources. The standby DTCH connects the RLC entity on the MCG that has been set up for the RB that needs to use SeNB resources and the MAC entity on the MCG.

In this step, when an RB that requires SeNB resources to be used is established, a standby bifurcated data transmission path may be established for the RB; or,

and when the SeNB is changed, establishing a standby data transmission path for the established RB needing to use the SeNB resource.

In the invention, the MCG is located on the MeNB, the MeNB may be a conventional macro base station (macro eNB) or an LPN in terms of physical characteristics, and when the MeNB is the macro eNB, each cell in the MCG is a macro cell (macro cell); when the MeNB is the LPN, each cell in the MCG is a small cell (small cell).

Step 501: during the SeNB change, data is transmitted using the backup data transmission path, wherein the transmitted data includes at least data that has been distributed to the RLC entity of the source SCG prior to the SeNB change but has not completed transmission at the source SCG.

The SeNB changing process in this step specifically includes:

after the MeNB to which the MCG belongs requests the SeNB to change, the target SeNB may allocate resources and receive a positive reply of the target SeNB response; or,

it is also possible that after the MeNB receives data from the source SeNB that has been distributed to the RLC entity of the source SeNB before the SeNB change but has not completed transmission at the source SeNB; or,

the notification message sent by the MeNB can be received by the UE; the notification message is an RRC layer message, such as an RRC connection reconfiguration message, or an MAC layer message.

The data transmission using the spare data transmission path in this step includes: when the standby data transmission path is a standby forked bearer, the data is transmitted using one of the at least one standby RLC entity and the at least one standby DTCH established for the RB that needs to use the SeNB resource in step 500.

When the standby data transmission path is a standby forked logical channel, one of the at least one standby DTCH established for the RBs requiring the use of the SeNB resources in step 500 and the RLC entity that has been established for the RBs requiring the use of the SeNB resources are used to transmit data.

The data transmitted in this step, that is, the data that has been distributed to the RLC entity of the source SCG before the SeNB change but has not completed transmission in the source SCG, includes, when the standby data transmission path is a standby forked bearer:

for the situation that the backup forked bearer on the MCG uses the security configuration of the MCG, and the backup RLC entity is connected to the PDCP entity that is established on the MCG by the RB that needs to use the SeNB resource, the data transmitted in this step includes: PDCP Packet Data Packets (PDUs) distributed by the PDCP entity of the MCG to the RLC entity of the source SCG but not transmitted in the source SCG; or,

for the situation that the backup forked bearer on the MCG uses the security configuration of the SCG, and the backup RLC entity is connected to the PDCP entity that is established on the source SCG by the RB that needs to use the SeNB resource, the data transmitted in this step includes: and the source SeNB receives the downlink data from the core network but does not finish transmission at the source SeNB, and the generated PDCP PDU is processed by a PDCP entity established on the source SeNB by the RB needing to use the SeNB resources.

Further, for the situation that the standby forked bearer on the MCG uses the security configuration of the MCG, and the standby RLC entity is connected to the PDCP entity that is established on the MCG by the RB that needs to use the SeNB resource, the data transmitted in this step further includes: and other PDCP PDUs issued by the PDCP entity of the MCG except the PDCP PDUs distributed to the RLC entity of the source SCG but not completely transmitted in the source SCG by the PDCP entity of the MCG.

The data transmitted in this step, that is, the data that has been distributed to the RLC entity of the source SCG before the SeNB is changed but has not completed transmission in the source SCG, when the standby data transmission path is a standby forked logical channel, the data transmitted in this step includes:

PDCP PDUs distributed by the PDCP entity of the MCG to the RLC entity of the source SCG but not completed in transmission at the source SCG.

Further, the method also comprises the following steps of,

and other PDCP PDUs issued by the PDCP entity of the MCG except the PDCP PDUs distributed to the RLC entity of the source SCG but not completely transmitted in the source SCG by the PDCP entity of the MCG.

According to the invention, through the establishment of the standby data transmission path, the standby data transmission path is used for transmitting data in the change process of the SeNB, so that the continuity of data transmission in the change process of the SeNB is ensured, the smooth transmission of the data is realized, the user data transmission rate is improved, and the user experience is enhanced.

The method of the invention also comprises the following steps:

step 502: and stopping transmitting data by using the standby data transmission path.

For the case that the standby data transmission path is a standby forked bearer and the standby forked bearer on the MCG uses the security configuration of the MCG, the standby RLC entity is connected to the PDCP entity that is established on the MCG by the RB that needs to use the SeNB resource, or for the case that the standby data transmission path is a standby forked logical channel, this step specifically includes:

after the UE successfully accesses the target SeNB, the UE notifies the MeNB, the UE stops using the standby data transmission path to transmit data, and the MeNB stops using the standby data transmission path to transmit data after receiving the notification; or,

the UE stops using the standby data transmission path to transmit data after successfully accessing the target SeNB, the target SeNB sends a notification that the UE has successfully accessed to the MeNB, and the MeNB stops using the standby data transmission path to transmit data after receiving the notification; or,

and the MeNB sends the change notice of the SeNB to the UE for a preset time length T and then stops using the standby data transmission path to transmit data, and the UE stops using the standby data transmission path to transmit data after receiving the change notice of the SeNB sent by the MeNB for the preset time length T.

Wherein, the successful access of the UE to the target SeNB comprises: the UE is successfully accessed to the target SeNB randomly; or, the UE completes the adjustment and configuration of the device-related module after receiving the SeNB change notification sent by the MeNB.

For the situation that the standby data transmission path is a standby forked bearer, the standby forked bearer on the MCG uses the security configuration of the SCG, and the standby RLC entity is connected with the PDCP entity established on the SCG by the RB that needs to use the SeNB resource, this step specifically includes:

when the transmission of the downlink data which is received by the source SeNB from the core network but is not transmitted by the source SeNB is completed on the standby data transmission path, i.e. the standby forked bearer, the use of the standby data transmission path, i.e. the standby forked bearer, for transmitting the data is stopped.

When the transmission of the downlink data, which is received by the source SeNB from the core network but not transmitted by the source SeNB, is completed on the standby data transmission path, i.e., the standby forked bearer, the method further includes: the standby RLC entity is connected with a PDCP entity which is established on the T-SCG by the RB needing to use the SeNB resources, and uses the security configuration of the target SCG.

The present invention also provides a computer-readable storage medium storing computer-executable instructions for performing any of the above-described data transmission methods.

The technical solution for implementing data transmission proposed by the present invention is described in detail below with reference to specific embodiments. Unless otherwise stated, the steps in the following embodiments of the present invention are all described with reference to the case where the standby data transmission path is used as the standby bearer.

In the first embodiment and the second embodiment, it is assumed that there is an X2 interface with a large enough capacity between the MeNB and the SeNB, so that a bifurcated bearer can be established between the MeNB and the SeNB, the S1-U interface is terminated on the MeNB, all downlink data sent on the SeNB are acquired by the MeNB from the core network and then generated into PDCP PDUs, and then sent to the SeNB through the X2 interface with a large enough capacity, and similarly, all uplink data received on the SeNB are sent to the MeNB through the X2 interface with a large enough capacity, and then processed by the PDCP layer of the MeNB and sent to the core network. The spare data transmission path in the first and second embodiments may be a spare forked bearer or may be a spare forked logical channel. In the embodiments, except for special description, the entire implementation flow is described with the case where the standby data transmission path is a standby forking bearer, and for the case where the standby data transmission path is a standby forking logical channel, the implementation flows in the first embodiment (fig. 6, fig. 10, and fig. 11) and the second embodiment (fig. 11) are also applicable, and the details of the present invention are not repeated.

Fig. 6 is a flowchart illustrating a first embodiment of implementing data transmission according to the present invention, where in the first embodiment, a backup bearer is established for a forked bearer while establishing the forked bearer, and a concept of establishing the forked bearer includes a case where the forked bearer is directly established when the bearer is established, and also includes a case where an MCG bearer or an SCG bearer is initially established and then re-established as the forked bearer. As shown in fig. 6, includes:

step 600: and establishing the branched bearer and the standby branched bearer of the branched bearer, namely establishing at least one standby branched bearer of the branched bearer on the MCG when the branched bearer is established.

Taking the establishment of the downlink split bearer as an example, as shown in fig. 7(a), it is a radio protocol architecture diagram of the downlink split bearer established on the base station side and one of the standby split bearers in the first embodiment of the present invention, as shown in fig. 7(a), there are two RBs: RB1 establishes MCG bearer, RB2 establishes split bearer. Wherein, the PDCP700 entity of RB2 is located on the MeNB (or MCG of MeNB, or MCG, which is described later herein as being directly expressed by MeNB or MCG for convenience of description), two RLC entities, namely RLC710 on MeNB and RLC730 of a bifurcated bearer on S-SeNB, and DTCH710-1 between RLC710 and MAC740 of MeNB and DTCH730-1 between RLC730 and MAC750 of S-SeNB, are respectively established on the MeNB and Source SeNB (or SCG of S-SeNB, or SCG, which is described later herein as being directly expressed by SeNB or SCG for convenience of description). In addition, when RB2 is established, a backup forked bearer is also established for RB2 on the MeNB, i.e., backup RLC720 established on the MeNB as shown in fig. 7(a) and backup DTCH720-1 between RLC720 and MAC740 in fig. 7 (a). Standby forking bearer Security configuration Using MCG, such as user plane Security Key (K) Using MCG_UPenc) RLC720 is connected with RB2 PDCP700 on MeNB.

Fig. 7(b) is a radio protocol architecture diagram on the UE side corresponding to the radio protocol architecture diagram on the base station side in fig. 7(a), in which the protocol architecture is consistent with that on the base station side, and only the MeNB and the S-SeNB on the base station side are located on different physical devices, and the MeNB and the S-SeNB are connected through an X2 interface in the first embodiment of the present invention; on the UE side, the protocol architecture corresponding to the MeNB side and the protocol architecture corresponding to the S-SeNB side are located on the same physical device, and the two are connected through an internal hardware interface, a software interface, or a software code. All protocol stacks in the following embodiments are only illustrated on the base station side or the UE side, if not specifically illustrated.

If the established backup data transmission path is not a backup forked bearer but a backup forked logical channel in this embodiment, fig. 7(c) is a radio protocol architecture diagram of a downlink forked bearer and a backup forked logical channel established on the base station side, where there are two RBs in the diagram: RB1 establishes MCG bearer, RB2 establishes split bearer. Similarly, the PDCP700 entity of RB2 is located on the MeNB, and two RLC entities are established on the MeNB and the source SeNB, namely RLC710X on the MeNB and RLC720X of the forked bearer on the S-SeNB, and DTCH710X-1 between RLC710X and MAC730X of the MeNB and DTCH720X-1 of the forked bearer between RLC720X and MAC740X of the S-SeNB, respectively. In addition, when RB2 is established, a spare forked logical channel 710X-2 is also established on the MeNB for RB2, i.e., a spare DTCH710X-2 between RLC710X and MAC730X is established on the MeNB as shown in FIG. 7 (c). Here, DTCH710X-1 and standby DTCH710X-2 are both connected to RLC entity 710X and MAC entity 730X established on MeNB for RB2, but DTCH710X-2 may be configured with a higher logical channel priority than DTCH 710X-1. Fig. 7(d) is a diagram of a UE-side radio protocol architecture corresponding to the diagram of the base station-side radio protocol architecture of fig. 7(c) in the first embodiment of the present invention, and the detailed description is the same as the description of fig. 7 (b).

It should be noted that, as described in step 500 of fig. 5, the standby DTCH is connected to the RLC entity already established for the RB requiring SeNB resource on the MCG and the MAC entity on the MCG, in the first embodiment, since the standby forked logical channel is established at the same time of establishing the forked bearer RB2, taking fig. 7(c) as an example, the standby DTCH710X-2 is connected to the RLC entity 710X established for the RB2 requiring SeNB resource on the MCG and the MAC entity 730X on the MCG, that is, the DTCH710X-2 and the DTCH710X-1 established for the split RB2 on the MCG share the protocol entities at both ends of the channel.

Similarly, for the case of establishing an uplink split bearer, fig. 8 is a radio protocol architecture diagram of an uplink split bearer established by the UE side and one of its standby split bearers in the first embodiment of the present invention; as shown in fig. 8, all protocol layer entities are located in the same physical device, for example, in the same UE. Similarly to fig. 7(a), also in fig. 8 there are two RBs: RB1 establishes MCG bearer, RB2 establishes split bearer, PDCP800 entity of RB2 is located on MCG (i.e. PDCP entity established on MeNB for RB2 on UE side), two RLC entities are established on MCG and SCG respectively, namely RLC810 on MCG (i.e. split RLC entity established on MeNB for RB2 on UE side) and RLC830 on SCG (i.e. split RLC entity established on S-SeNB for RB2 on UE side), DTCH810-1 between RLC810 and MAC840 of MCG, and DTCH830-1 between RLC830 and MAC850 of SCG. In addition, when RB2 is established, a backup forked bearer is also established on the MCG for RB2, i.e., a backup RLC entity 820 established on the MCG and a backup DTCH820-1 between RLC820 and MAC840 as shown in fig. 8 (i.e., a backup RLC entity and a backup DTCH established on the MeNB for RB2 on the UE side). Standby forking bearer Security configuration Using MCG, such as user plane Security Key (K) Using MCG_UPenc) The RLC820 is connected with the PDCP800 of RB2 on MCG. When establishing the RLC820 and the standby DTCH between the RLC820 and the MAC840, the relevant parameters may be configured to be the same as the DTCH between the RLC830 and the MAC850 on the SCG, or may be configured to be different parameters, such as configuring a higher logical channel priority for the standby DTCH, and the like.

Taking the establishment of the downlink forked bearer as an example, a plurality of standby forked bearers may also be established for the downlink forked bearer. Fig. 9 is a radio protocol architecture diagram of a downlink split bearer established by the present invention and two spare split bearers thereof, as shown in fig. 9, when RB2 is established, 2 spare split bearers are also established for RB2 on the MeNB, such as spare RLC920, spare RLC930 established on the MeNB shown in fig. 9, and spare DTCH920-1 between RLC920 and MAC950, and spare DTCH930-1 between RLC930 and MAC 950.

Step 601: when the MeNB determines that a SeNB change needs to be initiated, the MeNB sends a SeNB Addition Request (SeNB Addition Request) to the Target SeNB (T-SeNB, Target SeNB).

The SeNB add request is for: the MeNB requests the T-SeNB to allocate resources, i.e., requests the T-SeNB to allocate resources for migrating RB2 on the S-SeNB to the T-SeNB.

Step 602: the T-SeNB sends a SeNB Addition acknowledgement (SeNB Addition RequestAcknowledgeage) to the MeNB.

Step 603: data is transmitted using the alternate forked bearer. For downlink transmission, the MeNB uses the standby forked bearer to transmit data, which includes at least data that the MeNB has distributed to the RLC of the S-SeNB before the SeNB change, such as RLC730 in fig. 7(a), but has not completed transmission at the S-SeNB. For uplink transmission, the UE transmits data using the backup forked bearer, the transmitted data including at least data that the PDCP entity of the MCG had distributed to the RLC entity of the SCG, such as the RLC830 in fig. 8, but did not complete transmission at the SCG before the SeNB change.

In the first embodiment, it is assumed that after the MeNB distributes the data to the S-SeNB, the distributed data is not deleted from the buffer of the MeNB, and therefore, in this step, the data can be directly transmitted using the standby forked bearer.

In another case, if the MeNB deletes data from the buffer of the MeNB after distributing the data to the S-SeNB, and fig. 10 is a flowchart illustrating another embodiment of implementing data transmission according to the present invention, then, as shown in fig. 10, after receiving an SeNB addition confirmation from the T-SeNB (step 1003), the MeNB may initiate a SeNB deletion request to the S-SeNB (step 1004), in which the MeNB provides an address of data forwarding to the S-SeNB, and after receiving the data forwarding address provided by the MeNB, the S-SeNB performs data forwarding in step 1004), that is, sends data to the MeNB, which has been distributed to the RLC entity of the S-SeNB before the change of the SeNB but has not completed transmission in the S-SeNB, and the MeNB uses a backup bifurcated bearer to transmit the data forwarded by the S-SeNB (step 1005). The other steps of fig. 10 are identical to those of fig. 6, and fig. 10 will not be described in detail later.

For fig. 7(a), in the case that only one backup forked bearer is established as shown in fig. 8, the backup forked bearer is only used for transmitting data. For the case that fig. 9 establishes two or more than two standby forked bearers when establishing RB2, the MeNB selects at least one of the standby forked bearers for transmitting data, wherein the MeNB may select the at least one standby forked bearer in consideration of the traffic characteristics, the logical channel priority, and the like of the data to be transmitted on the standby forked bearers.

In the first embodiment, taking fig. 7(a) as an example, it is assumed that before the SeNB is changed, the PDCP700 of the MeNB has already distributed PDCP PDUs with SNs 2,3,4,6,7,8,10 to the S-SeNB, where the data packet with SN 2,3,4 is transmitted in the S-SeNB and receives successful reception feedback from the UE, while the data packet with SN 6 is transmitted to the UE via the radio frequency of the S-SeNB but does not receive successful reception feedback from the UE, and the data with SNs 7,8,10 has not yet been transmitted via the SeNB. Then, in this step, the backup forking bearer on the MeNB is at least used for transmitting data packets with SN 6,7,8, 10.

It should be noted that, if the PDCP PDU that is distributed by the PDCP entity of the MCG to the RLC entity of the source SCG but not transmitted in the source SCG is completely transmitted on the standby forked bearer before the SeNB change is successful, that is, the UE successfully accesses to the T-SeNB, the standby forked bearer may also be used to transmit other PDCP PDUs delivered by the PDCP entity of the MCG, for example, the PDCP PDU after the MCG PDCP processing of new data from the core network during the SeNB change.

It should be noted that, in this embodiment, the uplink uses the standby forked bearer to transmit data, that is, the UE needs to execute the transmission after receiving the notification message sent by the MeNB when sending data to the base station using the standby forked bearer transmission data, where the notification message is an RRC layer message (for example, an RRC connection reconfiguration message in subsequent step 605) or an MAC layer message.

The above describes the technical solution of using the backup data transmission path to transmit data in the case that the backup data transmission path is the backup branch bearer, and similarly, when the backup data transmission path is the backup branch logical channel, all the above descriptions are equally applicable. Taking fig. 7(c) as an example, the only difference is that when the data is transmitted using the spare forked logical channel, the spare forked logical channel connects RLC710X-1 and MAC730X-1 established on MeNB for RB2, and transmits the data between the two. Also, in the case where only one backup bifurcated logical channel is established as shown in fig. 7(c), the backup bifurcated logical channel is used to transmit data, and when two or more backup bifurcated logical channels are established for RB2, the MeNB selects at least one of the backup bifurcated logical channels to transmit data.

Step 604: the MeNB sends a SeNB delete Request (SeNB Release Request) to the S-SeNB.

Step 605: the MeNB sends an RRC connection reconfiguration (RRC connection reconfiguration) to the UE for informing the UE to change the split bearer of RB2 on the S-SeNB to the T-SeNB.

Step 606: the UE feeds back RRC connection reconfiguration Complete (RRC connection reconfiguration Complete) to the MeNB.

Step 607: the MeNB sends a SeNB reconfiguration complete (SeNB reconfiguration complete) to the T-SeNB.

Step 608: if a random access operation needs to be performed on the T-SeNB, the UE performs random access on the T-SeNB. This step is an optional step.

Step 609: the MeNB and/or the UE stop transmitting data using the backup forked bearer.

In this step, after the UE successfully accesses the T-SeNB, the SeNB changes successfully, and the MeNB and/or the UE stop using the standby forked bearer to transmit data, which may specifically be: after the UE is successfully accessed to the T-SeNB, the MeNB is informed, the UE stops using the standby forked bearer to transmit data, and after the MeNB receives the notification, the MeNB stops using the standby forked bearer to transmit data; or the UE stops using the standby forked bearer to transmit data after successfully accessing the T-SeNB, the T-SeNB notifies the MeNB that the UE is successfully accessed, and the MeNB stops using the standby forked bearer to transmit data after receiving the notification; or, the MeNB sends the RRC connection reconfiguration message to the UE for a preset duration T, and then stops using the standby forked bearer to transmit data, and the UE stops using the standby forked bearer to transmit data after receiving the RRC connection reconfiguration message sent by the MeNB for the preset duration T.

Step 610: the MeNB sends a delete UE context to the S-SeNB.

Fig. 11 is a flowchart illustrating a second embodiment of implementing data transmission according to the present invention, where in the second embodiment, a backup split bearer is established for a split bearer when an SeNB changes, as shown in fig. 11, the method includes:

step 1101: a bifurcated bearer is established.

To establish a bifurcated bearer on the MeNB and the S-SeNB, fig. 12(a) is a schematic diagram of a radio protocol architecture of a downlink bifurcated bearer before the SeNB changes the bearer in the second embodiment of the present invention, and as shown in fig. 12(a), the MeNB and the UE establish two RBs: RB1 and RB2, wherein RB1 is MCG bearer and RB2 is split bearer.

Step 1102 to step 1103: the specific implementation is completely the same as step 601 to step 602 in the first embodiment, and is not described here again.

Step 1104: the specific implementation is completely the same as step 604 in the first embodiment, and is not described here again.

Step 1105: the MeNB sends an RRC connection reconfiguration to the UE, which in a second embodiment is used to inform the UE to change the split bearer of RB2 on the S-SeNB to the T-SeNB on the one hand, and to establish a backup split bearer of the split bearer on the MCG on the other hand.

Fig. 12(b) is a schematic diagram of a radio protocol architecture of a downlink split bearer in a SeNB change process in the second embodiment of the present invention, and as shown in fig. 12(b), in this step, the MeNB and the UE establish a backup split bearer for the RB2 on the MeNB side, that is, a backup RLC1220 established on the MeNB shown in fig. 12(b) and a backup DTCH between the RLC1220 and the MAC1240 not shown in fig. 12(b), and the backup split bearer uses the security configuration of the MCG on the MeNB. Fig. 12(b) is a protocol architecture diagram taken as an example of a base station side, the protocol architecture diagram on the UE side is identical to that on the base station side, except that the MeNB and the S-SeNB on the base station side are located on different physical devices, the MeNB and the S-SeNB are connected through an X2 interface, and the protocol architecture corresponding to the MeNB side and the protocol architecture corresponding to the S-SeNB side on the UE side are located on the same physical device and connected through an internal hardware interface, a software interface, or a software code.

It should be noted that, during the SeNB changing process, for example, in this step, according to the UE capability, the signal quality of the radio link between the UE and the S-SeNB, and the policy of the base station, the MeNB may notify the UE to directly delete the split bearer on the S-SeNB, that is, delete the RLC1230 and the DTCH between the RLC1230 and the MAC1250, and may also continue to retain the split bearer on the S-SeNB. Such as: when the UE capability does not support simultaneous communication with the MeNB, the S-SeNB and the T-SeNB, or when the signal quality of a wireless link between the UE and the S-SeNB is not good enough, or when a base station strategy needs to be deleted, directly deleting the split bearer on the S-SeNB; the following steps are repeated: when the UE capability supports simultaneous communication with the MeNB, the S-SeNB and the T-SeNB, the signal quality of a wireless link between the UE and the S-SeNB is good enough, and the base station policy requires, the split bearer on the S-SeNB can be continuously reserved. For the reserved case, in addition to using the backup bearer to transmit data during the SeNB change, data transmission on the split bearer of the S-SeNB may also continue. The first embodiment also applies to such processing.

As explained above with the backup data transmission path as the backup split bearer, when the backup data transmission path is the backup split logical channel, the backup split logical channel established for split RB2 on the MCG is connected to the RLC entity and the MAC entity already established for split RB2 on the MCG in step 1101.

Step 1106: data is transmitted using the alternate forked bearer. For downlink transmission, the MeNB transmits data using the standby forked bearer, the transmitted data including at least data that the MeNB has distributed to the RLC entity of the S-SeNB, such as RLC1230 in fig. 12(b), but has not completed transmission at the S-SeNB before the SeNB change. For uplink transmission, the UE transmits data using the backup forked bearer, the transmitted data including at least data that the PDCP entity of the MCG has distributed to the RLC entity of the SCG before the SeNB change but has not completed transmission at the SCG.

The specific implementation description of this step is the same as step 603 in the first embodiment, and is not described here again.

Step 1107 to step 1111: the specific implementation is the same as steps 606 to 610 in the first embodiment, and details are not described here.

In the second embodiment, after the UE successfully accesses the T-SeNB, the SeNB is successfully changed, and after the SeNB is successfully changed, the protocol architecture thereof is as shown in fig. 12(c), the standby forked bearer is deleted, and the split bearer of RB2 can be enabled on the T-SeNB. The specific deletion of the standby forked bearer may be: after the UE is successfully accessed to the T-SeNB, the MeNB is informed, the UE deletes the local standby forked bearer, and after the MeNB receives the notice, the local standby forked bearer is deleted; or the UE deletes the local standby forked bearer after successfully accessing the T-SeNB, the T-SeNB notifies the MeNB that the UE is successfully accessed, and the MeNB deletes the local standby forked bearer after receiving the notification; or, the MeNB sends the RRC connection reconfiguration message to the UE for a preset duration T, and then deletes the local standby bearer.

In the third and fourth embodiments, assuming that the capacity of the X2 interface between the MeNB and the SeNB is not large enough, if all data transmitted on the SeNB needs to be sent from the MeNB to the SeNB over the X2 interface, such a huge amount of data cannot be carried on the X2 interface, and thus a bifurcated bearer cannot be established between the MeNB and the SeNB, and there are independent S1-U interfaces between the MeNB and the SeNB and the core network. But the capacity between MeNB and SeNB is sufficient to carry downlink data that the source SeNB sent to the MeNB by the source SeNB during the SeNB change has received from the core network but has not completed transmission at the source SeNB. The spare data transmission path in the third and fourth embodiments is a spare forked bearer.

Fig. 13 is a flowchart illustrating a third embodiment of implementing data transmission according to the present invention, where in the third embodiment, it is assumed that a bearer is established on an SCG and a backup forked bearer is established for the bearer on an MCG at the same time, and a concept of establishing a bearer here includes a case where the bearer is established directly on the SCG during establishment of the bearer and a case where the bearer that is originally established on the MCG independently is reestablished on the SCG. As shown in fig. 13, the specific implementation includes:

step 1301: and establishing a bearer on the SCG, and simultaneously establishing a standby forked bearer for the bearer on the MCG.

Taking a downlink bearer as an example, fig. 14(a) is a radio protocol architecture diagram of a downlink forked bearer established by a base station side and a spare forked bearer thereof in the third embodiment of the present invention, and as shown in fig. 14(a), it is assumed that an RB3 is established for a UE on an S-SeNB, that is, a PDCP entity, an RLC entity, and DTCH between RLC and MAC of the RB3 are established on the S-SeNB. Meanwhile, when RB3 is established, a backup forked bearer is also established for RB3 on the MeNB, such as backup RLC1420 established on the MeNB and backup DTCH between RLC1420 and MeNB MAC shown in fig. 14 (a). Security configuration using SCG, such as user plane security key (K) using SCG, for standby forked bearer_UPenc) RLC1420 interfaces with RB3 PDCP1410 on SeNB. Fig. 14(b) is a radio protocol architecture diagram of an uplink split bearer established on the UE side and a spare split bearer thereof in the third embodiment of the present invention, and a protocol architecture thereof is consistent with that of the base station side shown in fig. 14(a), except that the MeNB and the S-SeNB on the base station side are located on different physical devices, the MeNB and the S-SeNB are connected by an X2 interface, and the protocol architecture corresponding to the MeNB side and the protocol architecture corresponding to the S-SeNB side on the UE side are located on the same physical device and connected by an internal hardware interface or a software code.

As described in step 600 of the first embodiment, two or more standby forked bearers may also be established for RB3, and detailed description is omitted here. The third embodiment will be described in detail by taking only the case of establishing one backup forked bearer as an example.

Step 1302 to step 1303: the specific implementation is completely the same as step 601 to step 602 in the first embodiment, and is not described here again.

Also, it should be noted that in this embodiment, the uplink uses the standby forked bearer to transmit data, that is, the UE needs to execute the transmission after receiving the notification message sent by the MeNB when the UE transmits data to the base station using the standby forked bearer, where the notification message is an RRC layer message (for example, an RRC connection reconfiguration message in subsequent step 605) or an MAC layer message.

Step 1304: the specific implementation is the same as step 1004 in the first embodiment, and is not described here again.

Step 1305: the S-SeNB sends the downlink data which is received from the core network but is not transmitted in the S-SeNB to the RLC1420 of the MeNB through the PDCP1410 processing generated PDCP PDU.

In the third embodiment, in the SeNB change procedure, the PDCP1410 of RB3 in the S-SeNB is reserved for use until step 1311, and likewise, the PDCP entity of RB3 on the UE side SCG is reserved for use until step 1311. However, the RLC entity of RB3 on the S-SCG and the DTCH between itself and the MAC determine whether to keep using, i.e., whether to continue transmitting data on the source SCG during the SeNB change process, according to the UE capability, the signal quality of the radio link between the UE and the S-SeNB, and the policy of the base station, and the specific determination method is as described in step 1105 in the second embodiment and will not be described herein again.

Step 1306: data is transmitted using the alternate forked bearer.

The MeNB sends the PDCP PDU sent by the S-SeNB to the MeNB in step 1305 to the UE using the standby forked bearer, the UE receives data using the standby forked bearer, the received data is sent to the PDCP1440 of the source SCG after being processed by the MCG standby forked bearer RLC1430, and is sent to a protocol layer above the PDCP1440, such as an application layer, after being decrypted by the security configuration of the source SCG.

Step 1307 to step 1310: the specific implementation is completely the same as step 605 to step 608 in the first embodiment, and is not described here again.

Step 1311: stopping transmitting data using the standby forked bearer.

And stopping transmitting data by using the standby forked bearer after the downlink data which is received by the S-SeNB from the core network but is not transmitted in the S-SeNB is transmitted on the standby forked bearer. Thereafter, the RLC entity of the backup forked bearer of RB3 on the MCG is connected with the PDCP entity established by RB3 on the target SCG (T-SCG), using the security configuration of T-SCG.

Step 1312: the specific implementation is completely the same as step 610 in the first embodiment, and is not described here again.

Fig. 15 is a flowchart illustrating a fourth embodiment of implementing data transmission according to the present invention, where in the fourth embodiment, it is assumed that a backup forked bearer is established for a bearer of a source SCG when an SeNB changes, and as shown in fig. 15, the specific implementation includes:

step 1501: the bearer RB3, i.e. the SCG bearer, is established on the SCG, here the SCG at the S-SeNB. In this embodiment, RB3 only uses the resources of the S-SeNB, and all protocol entities are established on the SCG, as shown in fig. 16(a), fig. 16(a) is a schematic diagram of a radio protocol architecture of a downlink SCG bearer before the SeNB changes in the fourth embodiment of the present invention.

Step 1502 to step 1504: the specific implementation is completely the same as steps 1302 to 1304, and is not described herein again.

Step 1505: and the S-SeNB sends the downlink data which is received from the core network but is not transmitted in the S-SeNB to the MeNB through the PDCP processing of the S-SeNB to generate the PDCP PDU.

In the fourth embodiment, in the SeNB change procedure, the PDCP entity of RB3 in the S-SeNB is reserved for use until step 1511, and likewise, the PDCP entity of RB3 in the SCG on the UE side is reserved for use until step 1511. However, the RLC entity of RB3 on the S-SCG and the DTCH between itself and the MAC determine whether to keep using, i.e., whether to continue transmitting data on the source SCG during the SeNB change process, according to the UE capability, the signal quality of the radio link between the UE and the S-SeNB, and the policy of the base station, and the specific determination method is as described in step 1105 in the second embodiment and is not described here again.

Step 1506: the MeNB sends an RRC connection reconfiguration to the UE, which in a fourth embodiment is used to inform the UE to change RB3 from S-SeNB to T-SeNB on the one hand and to establish a backup forked bearer of RB3 on the MCG on the other hand.

Fig. 16(b) is a schematic diagram of a radio protocol architecture of a downlink SCG bearer in a SeNB change process according to a fourth embodiment of the present invention, and as shown in fig. 16(b), in this step, the MeNB and the UE establish a backup bifurcated bearer on the MeNB side for RB3, that is, a backup RLC1620 established on the MeNB shown in fig. 16(b) and a backup DTCH between RLC1620 and MAC1630 not shown in fig. 16(b), the backup bifurcated bearer uses a security configuration of SCG on the S-SeNB, and the RLC1620 is connected to PDCP1610 of the SCG.

Step 1507: data is transmitted using the alternate forked bearer. The specific implementation is completely the same as step 1306 in the third embodiment, and is not described here again.

Step 1508 to step 1510: the specific implementation is completely the same as steps 1308 to 1310 in the third embodiment, and details are not repeated here.

Step 1511: and stopping transmitting data by using the standby forked bearer after the downlink data which is received by the S-SeNB from the core network but is not transmitted in the S-SeNB is transmitted on the standby forked bearer. Fig. 16(b) is a schematic diagram of a radio protocol architecture of a downlink SCG bearer in a SeNB change process in a fourth embodiment of the present invention, as shown in fig. 16(c), after that, the MeNB and the UE delete the standby forked bearer on the MCG, and the RB3 only uses the resources of the T-SeNB.

Step 1512: the specific implementation is completely the same as step 1312 in the third embodiment, and is not described here again.

Corresponding to the method for realizing data transmission provided by the invention, the invention also provides a device for realizing data transmission, and the device can be used as an independent entity; the present invention can also be arranged in a base station, for example, on an MeNB, or in a UE, that is, devices configured on the base station side and the UE side are functionally corresponding, where one side is a transmitting side, and the other side is a receiving side, for example, when the base station transmits downlink data, the base station receives uplink data, and accordingly, when the UE receives downlink data, the base station receives uplink data, and the UE transmits uplink data, the UE is the receiving side.

Fig. 17 is a schematic structural diagram of an apparatus for implementing data transmission according to the present invention, as shown in fig. 17, the apparatus at least includes a building module and a data transmission module; wherein:

the establishing module is used for establishing a standby data transmission path for the RB needing to use the SeNB resource on the MCG; including establishing at least one backup RLC entity and at least one backup DTCH for RBs that need to use SeNB resources.

And a data transmission module, configured to transmit data using the standby data transmission path during the SeNB change, where the transmitted data includes at least data that has been distributed to the RLC entity of the source SCG before the SeNB change but has not completed transmission at the source SCG.

Wherein, the spare data transmission path is: a backup forked bearer of RBs using SeNB resources is required, or a backup forked logical channel of RBs using SeNB resources is required.

In particular, the amount of the solvent to be used,

the establishing module is specifically configured to: when an RB needing to use SeNB resources is established, a standby data transmission path is established for the RB; or, when the SeNB is changed, a standby data transmission path is established for the established RBs which need to use the SeNB resources.

When the standby data transmission path is a standby forked bearer, the standby forked bearer established on the MCG uses the security configuration of the MCG, and the standby RLC entity is connected with a PDCP entity established on the MCG by an RB needing to use the SeNB resource;

or, the standby forked bearer on the MCG uses the security configuration of the SCG, and the standby RLC entity is connected with the PDCP entity established on the SCG by the RB that needs to use the SeNB resource.

Wherein, when the standby data transmission path is a standby fork logical channel,

When the device of the present invention is separately disposed in a network side or an MeNB, the data transmission module is specifically configured to: after a target SeNB to which the MCG belongs requests the SeNB to change to allocate resources and receives a positive reply of a response of the target SeNB, transmitting data by using a standby data transmission path; alternatively, the data is transmitted using the spare data transmission path after the MeNB receives data from the source SeNB that has been distributed to the RLC entity of the source SeNB before the SeNB change but has not completed transmission at the source SeNB.

When the apparatus of the present invention is separately installed in a user side or a UE, the data transmission module is specifically configured to: and after receiving the notification message sent by the MeNB, the UE transmits data by using the standby data transmission path.

In particular, the amount of the solvent to be used,

when the standby data transmission path is a standby forked bearer, the data transmission module specifically uses one standby RLC entity and one standby DTCH in at least one standby RLC entity and at least one standby DTCH which are established for the RB needing to use the SeNB resource to transmit data;

when the standby data transmission path is a standby fork logical channel, the data transmission module is specifically configured to: data is transmitted using one of the at least one backup DTCH and the RLC entities that have been established for the RBs that need to use the SeNB resources.

Wherein,

when the standby data transmission path is a standby forked bearer, in the SeNB change process, the data transmission module at least includes data that has been distributed to the RLC entity of the source SCG before the SeNB change but has not completed transmission at the source SCG, and specifically includes:

for the situation that the backup forked bearer established by the establishment module on the MCG uses the security configuration of the MCG, and the backup RLC entity is connected to the PDCP entity established on the MCG by the RB that needs to use the SeNB resource, the data transmitted by the data transmission module specifically includes: PDCP PDUs distributed by the PDCP entity of the MCG to the RLC entity of the source SCG but not completed in the source SCG; further, the data transmitted by the data transmission module may further include: and other PDCP PDUs issued by the PDCP entity of the MCG except the PDCP PDUs distributed to the RLC entity of the source SCG but not completely transmitted in the source SCG by the PDCP entity of the MCG. Or,

for the situation that the backup forked bearer established by the establishment module on the MCG uses the security configuration of the SCG, and the backup RLC entity is connected to the PDCP entity established on the SCG by the RB that needs to use the SeNB resource, the data transmitted by the data transmission module specifically includes: and the source SeNB receives the downlink data from the core network but does not finish transmission at the source SeNB, and the generated PDCP PDU is processed by a PDCP entity established on the source SeNB by the RB needing to use the SeNB resources.

When the standby data transmission path is a standby fork logical channel, the data transmitted by the data transmission module comprises: PDCP PDUs distributed by the PDCP entity of the MCG to the RLC entity of the source SCG but not completed in transmission at the source SCG. Further, the air conditioner is provided with a fan,

the data transmitted by the data transmission module further comprises: and other PDCP PDUs issued by the PDCP entity of the MCG except the PDCP PDUs distributed to the RLC entity of the source SCG but not completely transmitted in the source SCG by the PDCP entity of the MCG.

For the situation that the backup forked bearer established on the MCG by the establishing module uses the security configuration of the MCG, the situation that the established backup RLC entity is connected with the PDCP entity established on the MCG by the RB needing to use the SeNB resource, or the situation that the backup data transmission path is the backup forked logical channel,

when the device of the present invention is separately arranged in the user side or the UE, the data transmission module is further configured to: after the UE successfully accesses the target SeNB or the UE receives a change notification of the SeNB sent by the MeNB for a preset time period T, stopping transmitting data by using the standby data transmission path;

when the device of the present invention is separately disposed in the network side or the MeNB, the data transmission module is further configured to: and stopping transmitting data by using the standby data transmission path when the MeNB receives the notice from the UE or the UE of the target SeNB that the target SeNB is successfully accessed.

For the situation that the backup forked bearer established on the MCG by the establishment module uses the security configuration of the SCG, the established backup RLC entity is connected with the PDCP entity established on the SCG by the RB needing to use the SeNB resource,

when the device of the present invention is separately disposed in the network side or the MeNB, the data transmission module is further configured to: and stopping transmitting the data by using the standby data transmission path when the transmission of the downlink data which is received by the source SeNB from the core network but is not transmitted by the source SeNB is finished.

The invention also provides a base station comprising the apparatus of any one of the above; the invention also provides a UE comprising the device of any one of the above.

The above description is only a preferred example of the present invention, and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A method of data transmission, comprising: establishing a standby data transmission path for a radio bearer RB needing to use the secondary base station SeNB resource on a master control service cell group MCG;

2. The data transmission method of claim 1, further comprising, prior to the method: establishing the RB needing to use the SeNB resource;

the establishing of the standby data transmission path comprises:

3. The data transmission method according to claim 1 or 2, wherein the spare data transmission path is: a backup forked bearer of RBs using SeNB resources is required, or a backup forked logical channel of RBs using SeNB resources is required.

4. The data transmission method according to claim 1 or 2, wherein the backup data transmission path is a backup split bearer;

5. The data transmission method according to claim 1, wherein the backup data transmission path is a backup forked bearer;

6. The data transmission method according to claim 1 or 2, wherein the backup data transmission path is a backup branched logical channel;

the standby forked logical channel comprises: at least one backup DTCH established for RBs using SeNB resources; wherein the standby DTCH connects the RLC entity on the MCG that has been set up for the RB that needs to use SeNB resources and the MAC entity on the MCG.

7. The data transmission method according to claim 1, wherein the changing of the SeNB includes: after the MeNB to which the MCG belongs requests the target SeNB to allocate resources after the SeNB is changed and receives a positive reply of a target SeNB response;

8. The data transmission method of claim 3, wherein the transmitting data using the data transmission path comprises:

9. The data transmission method according to claim 5, wherein when the backup forked bearer uses the security configuration of the MCG and the backup RLC entity is connected to a PDCP entity established on the MCG by an RB that needs to use SeNB resources, the transmitted data includes:

10. The data transmission method of claim 9, wherein the transmitted data further comprises:

11. The data transmission method according to claim 5, wherein when the backup forked bearer uses the security configuration of the S-SCG, and the backup RLC entity is connected to the PDCP entity established on the S-SCG by the RB requiring the use of SeNB resources, the transmitted data comprises:

12. The data transmission method according to claim 6, wherein the transmitted data comprises: PDCP PDUs distributed by the PDCP entity of the MCG to the RLC entity of the source SCG but not completed in transmission at the source SCG.

13. The data transmission method of claim 12, wherein the transmitted data further comprises: and the other PDCP PDUs sent by the PDCP entity of the MCG except the PDCP PDUs which are distributed to the RLC entity of the source SCG by the PDCP entity of the MCG but are not completely transmitted in the source SCG.

14. The data transmission method of claim 1, further comprising: and stopping transmitting data by using the standby data transmission path.

15. The data transmission method according to claim 14, wherein when the backup data transmission path is a backup forked bearer and the backup forked bearer on the MCG uses the security configuration of the MCG, the backup RLC entity is connected to a PDCP entity that is established on the MCG by the RB that needs to use the SeNB resources, or the backup data transmission path is a backup forked logical channel,

16. The data transmission method according to claim 14, wherein when the backup data transmission path is a backup forked bearer and the S-SCG is configured for security, and the backup RLC entity is connected to a PDCP entity that is established on the S-SCG by an RB that needs to use SeNB resources, the stopping of transmitting data by using the backup forked bearer comprises:

17. The data transmission method of claim 16, further comprising: and the standby RLC entity is connected with a PDCP entity which is established on a target SCG T-SCG after the change of the SeNB by the RB needing to use the SeNB resources, and uses the security configuration of the T-SCG.

18. A data transmission apparatus, comprising:

19. The data transmission apparatus according to claim 18, wherein the establishing module is specifically configured to: when the RB needing to use the SeNB resource is established, a standby data transmission path is established for the RB; or when the SeNB is changed, establishing a standby data transmission path for the established RB needing to use the SeNB resource.

20. A data transmission arrangement as claimed in claim 18 or 19, wherein the spare data transmission path is: a backup forked bearer of RBs using SeNB resources is required, or a backup forked logical channel of RBs using SeNB resources is required.

21. The data transmission apparatus according to claim 18 or 19, wherein the backup data transmission path is a backup split bearer;

22. The data transmission apparatus of claim 18, wherein the backup data transmission path is a backup split bearer;

23. The data transmission method according to claim 18 or 19, wherein the backup data transmission path is a backup bifurcated logical channel;

24. The data transmission apparatus according to claim 18, wherein when the apparatus is separately disposed in a network side or an MeNB, the data transmission module is specifically configured to:

25. The data transmission apparatus according to claim 18, wherein when the apparatus is separately disposed in a user side or a UE, the data transmission module is specifically configured to: and after receiving the notification message sent by the MeNB to which the MCG belongs, the UE transmits data by using the standby data transmission path.

26. The data transmission apparatus according to claim 20, wherein when the backup data transmission path is a backup split bearer, the data transmission module is specifically configured to: transmitting data using one of at least one standby RLC entity and at least one standby DTCH established for RBs requiring use of SeNB resources;

27. The data transmission apparatus of claim 22, wherein the establishing module establishes a backup forked bearer on the MCG using security configuration of the MCG, and when the backup RLC entity is connected to a PDCP entity established on the MCG by an RB requiring the use of SeNB resources,

28. The data transmission apparatus of claim 27, wherein the data transmitted by the data transmission module further comprises: and the PDCP PDUs which are transmitted by the PDCP entity of the MCG except the PDCP PDUs which are distributed to the RLC entity of the S-SCG by the PDCP entity of the MCG but are not transmitted in the S-SCG are transmitted.

29. The data transmission apparatus of claim 22, wherein the establishing module establishes a backup forked bearer on the MCG using security configuration of the SCG, and when the backup RLC entity is connected to a PDCP entity established on the SCG by an RB requiring the use of SeNB resources,

30. The data transmission apparatus according to claim 23, wherein the data transmitted by the data transmission module comprises: PDCP PDUs distributed by the PDCP entity of the MCG to the RLC entity of the source SCG but not completed in transmission at the source SCG.

31. The data transmission method of claim 30, wherein the data transmitted by the data transmission module further comprises: and the other PDCP PDUs sent by the PDCP entity of the MCG except the PDCP PDUs which are distributed to the RLC entity of the source SCG by the PDCP entity of the MCG but are not completely transmitted in the source SCG.

32. The data transmission apparatus of claim 20, wherein the setup module uses a security configuration of the MCG for the backup forked bearer established on the MCG, and when the established backup RLC entity is connected to a PDCP entity established on the MCG for an RB requiring the use of SeNB resources or when the backup data transmission path is a backup forked logical channel,

33. The data transmission apparatus of claim 22, wherein the establishment module establishes a backup forked bearer on the MCG using security configuration of the SCG, and when the backup RLC entity is connected to a PDCP entity established on the SCG by an RB requiring the use of SeNB resources,

34. A base station comprising the apparatus as claimed in any one of claims 18 to 33.

35. A UE comprising the apparatus as claimed in any of claims 18 to 33.

36. A computer-readable storage medium storing computer-executable instructions for performing the data transmission method of any one of claims 1 to 17.