Patent Description:
Mobile telecommunications systems, such as those based on the 3GPP defined UMTS and Long Term Evolution (LTE) and Long Term Evolution Advance (LTE-A) architectures, are applicable to communications between networked user devices such as mobile telephones, and more widely also to applications such as the Internet of Things. The networked devices are supported by a telecommunications network comprising base stations of various configurations offering connection coverage over particular areas, known as cells, and the base stations are in turn supported by a core network. Transmission of data and other signalling between these various entities is achieved by the use of radio bearers which transport the required messages, for example as a signalling radio bearer which carries operational information for the entities, or a data radio bearer which carries data. In some instances a bearer is direct between two entities (a base station and a user device), one sending the message and the other receiving it. In other cases, a split bearer may be used, allowing a received message to be divided between the radio handling resources of two receiving entities. Hence, a split bearer is divided between two base stations, each of which passes its part of the split bearer to a user device. The user device is appropriately configured with resources to handle data received from each base station so that it can manage the split bearer. This arrangement shares resources and enhances speed and efficiency.

The splitting of bearers in this way requires consideration of the operation of the resources in both of the entities between which the bearer is split, and the resources in the user device corresponding to each entity. Resources for each side of the split bearer should be maintained in an operational state for successful handling of the message. The patent application published as <CIT> shows a method for operating a base station in which there is a MeNB and a secondary cell group.

<FIG> shows a schematic diagram illustrating some basic functionality of a mobile (cellular, wireless) telecommunications network/system, in this example operating generally in accordance with LTE principles, and which may be adapted to implement embodiments of the disclosure as described further below. Various embodiments of <FIG> and their respective modes of operation are well-known and defined in the relevant standards administered by the 3GPP (RTM) body, and also described in many books on the subject, for example Holma and Toskala [<NUM>]. It will be appreciated that operational aspects of the telecommunications network which are not specifically described below may be implemented in accordance with any known techniques, for example according to the relevant standards and known variations thereof. Furthermore, it will be appreciated that whilst some specific examples described herein may refer to implementations based around particular 3GPP implementations, the same principles can be applied regardless of the underlying operating principles of the network. That is to say, the same principles can be applied for wireless telecommunications networks operating in accordance with other standards, whether past, current or yet to be specified.

The network <NUM> in <FIG> includes a plurality of base stations <NUM> connected to a core network <NUM>. Each base station provides a coverage area or cell <NUM> within which data can be communicated to and from terminal devices or user equipment <NUM> within the respective coverage areas <NUM> via a radio downlink DL. Data is transmitted from user equipment <NUM> to the base stations <NUM> via a radio uplink UL. The uplink and downlink communications are made using radio resources that may be used by the operator of the network. The core network <NUM> routes data to and from each user equipment <NUM> via the respective base stations <NUM> and provides functions such as authentication, mobility management, charging and so on. Regarding terminology, terminal devices may also be referred to as mobile stations, user equipment (UE), user terminal, terminal, mobile radio, mobile terminal, mobile device, or simply device, and so forth. Base stations may also be referred to transceiver stations, nodeBs, e-nodeBs, eNBs and so forth.

<FIG> shows a schematic representation of an example of a user equipment <NUM>. The user equipment <NUM> comprises a transceiver unit 104A for transmission and reception of wireless signals and a processor unit 104B configured to control the user equipment. The processor unit 104B may comprise various sub-units for providing functionality in accordance with embodiments of the present disclosure as explained further herein. These sub-units may be implemented as discrete hardware elements or as appropriately configured functions of the processor unit. Thus the processor unit 104B may comprise a processor unit which is suitably configured /programmed to provide the desired functionality described herein using conventional programming / configuration techniques for equipment in wireless telecommunications systems. The transceiver unit 104A and the processor unit 104B are schematically shown on <FIG> as separate elements for ease of representation. However, it will be appreciated that the functionality of these units can be provided in various different ways, for example using a single suitably programmed general purpose computer, or suitably configured application-specific integrated circuit(s) / circuitry. It will be appreciated that the user equipment will in general comprise various other elements associated with its operating functionality, for example a power source, user interface, and so forth, but these are not shown in <FIG> in the interests of simplicity.

<FIG> shows a schematic representation of an example of a base station <NUM>. In a network such as that in <FIG>, each base station <NUM> may be functionally identical but each serves one or more different geographical area (cells <NUM>). In some examples, base stations may be configured for operation in different related, or interworking, architectures, in an arrangement known as dual connectivity. In general, though, each base station <NUM> comprises a transceiver unit 101A for transmission and reception of communications between the base station and any user equipment <NUM> in its cell, and the core network <NUM>. A base station <NUM> further comprises a processor unit 101B configured to control the base station <NUM> to operate in accordance with embodiments of the present disclosure as described herein. The processor unit 101B may again comprise various sub-units for providing functionality in accordance with embodiments of the present disclosure as explained herein. Theses sub-units may be implemented as discrete hardware elements or as appropriately configured functions of the processor unit. Thus, the processor unit 101B may comprise a processor unit which is suitably configured / programmed to provide the desired functionality described herein using conventional programming / configuration techniques for equipment in wireless telecommunications systems. The transceiver unit 101A and processor unit 101B are schematically shown in <FIG> as separate elements for ease of representation. However, it will be appreciated that the functionality of these units can be provided in various different ways, for example using a single suitably programmed general purpose computer, or suitably configured application-specific integrated circuits(s) / circuitry. It will appreciated that the base station <NUM> will in general comprise various other elements, for example a power supply, associated with its operating functionality.

In particular, the processor units of user equipment and base stations include resources for handling radio bearers. The resources may include a protocol stack comprising layers including a PDCP (packet data convergence protocol), a RLC (radio link control) and a MAC (medium access control), where the layers may be dedicated to particular types of radio bearer, or may be shared. Under particular events in the network operation, one or more parts of the resources may need to be reset or re-established for continued operation, which herein is referred to generally as reconfiguration, or alternatively as alteration, indicating some change in in the resources, including resetting, re-establishment, clearing, removing from use and other like procedures that alter the way in which the resources are able to handle one or more radio bearer types. The procedures for resetting and re-establishing are well-understood, and specified in the 3GPP standards. For example, the MAC reset procedure is specified in section <NUM> of 3GPP specification TS <NUM>, the RLC re-establishment procedure is specified in section <NUM> of 3GPP specification TS <NUM>, and the PDCP re-establishment is specified in section <NUM> of 3GPP specification TS <NUM>. On a high level, a layer is reset during reset or re-establishment, but different terminology is used in the different specifications for the various protocol layers.

As is well understood, in wireless telecommunications networks such as an LTE type network, there are different Radio Resource Control (RRC) modes for terminal devices, including governing the connection state between the terminal device and a base station. These include an idle mode and a connected mode. Generally speaking, in RRC connected mode a terminal device is connected to a base station in the sense of being able to receive user plane data from the base station, whereas in RRC idle mode the terminal device is unconnected to a base station in the sense of not being able to receive user plane data from the base station. However, in idle mode the terminal device may still receive some communications from base stations, for example, reference signalling for cell reselection purposes and other broadcast signalling.

While the <FIG> example network shows all base stations (eNBs) as being the same, and each supporting one cell, in some networks and systems other arrangements may be used. For example, in Release <NUM> of the 3GPP standard governing the LTE architectures, the concept of dual connectivity (DC) was introduced. In dual connectivity, base stations are specified as being either a master base station or a secondary base station, and user equipment can connect with both.

<FIG> shows a schematic representation of the control plane architecture specified for dual connectivity. A master base station <NUM> (designated MeNB) and a secondary base station <NUM> (designated SeNB) communicate via a control plane using X2-C layer protocol. However, unlike the description above in which any base station is involved in handling RRC communications, in dual connectivity only the MeNB <NUM> is designated for RRC handling. Consequently, the RRC entity resides in the MeNB <NUM>, and communication with the core network in the form of a mobility management entity <NUM> (MME) via an S1-MME protocol layer terminates in the MeNB <NUM>.

Also, it is possible for a base station, being a master or a secondary eNB, to support more than one cell. <FIG> shows a schematic representation of part of a network having a MeNB <NUM> supporting three cells 105A, 105B and 105C, and a SeNB <NUM> supporting three cells 106A, 106B and 106C. A user equipment UE <NUM> has access to cells from both eNBs, indicated as the group <NUM>. Within the group <NUM>, one cell can be a primary cell, from the MeNB cells. Within the group <NUM> relating to the UE <NUM>, the MeNB cells 105A and 105B are designated as a master cell group MCG, and the SeNB cells 106A and 106B are designated as a secondary cell group SCG. The UE <NUM> has access to the cells of MCG and the two cells of the SCG, indicated by the overlapping cell areas in <FIG>.

A purpose of the dual connectivity arrangement is to enable sharing and combining of resources belonging to different base stations. This sharing is expressed in the concept of split bearers.

<FIG> show a schematic representation of an example user plane protocol stack for a dual connectivity arrangement. Typically, an incoming message arrives via a bearer and is handled by the various protocol layers defined within the LTE architecture. Once master and secondary eNBs are defined and grouped in dual connectivity, one can further designate a bearer intended for the MeNB <NUM> as a master cell group bearer, MCG bearer <NUM>, and a bearer intended for the SeNB <NUM> as a secondary cell group bearer, SCG bearer <NUM>. A bearer arrives via the S1 protocol layer, is handled by the eNB's resources in turn by a packet data convergence protocol (PDCP), then a radio link control (RLC) protocol, and then the medium access control (MAC) layer. As shown in <FIG>, each eNB <NUM>, <NUM> has these resource layers to handle received bearers.

In addition to the MCG bearer and the SCG bearer, dual connectivity defines a third, split bearer, for the purpose of sharing resources in the MeNB and the SeNB on the network side of the telecommunications system. A split bearer <NUM> is delivered to a PDCP in the MeNB <NUM>, and the MeNB <NUM>, at the PDCP, then controls a split or division of the split bearer's data between the MeNB <NUM> and the SeNB <NUM>. Data for the MeNB <NUM> is passed to the MeNB's RLC and then its MAC, and data for the SeNB <NUM> is passed from the MeNB <NUM>, using the X2 protocol layer, to an RLC in the SeNB and then to the MAC of the SeNB.

In order to be able to handle a message carried by a split bearer once it is passed on from the two eNBs, a UE is provided with two MAC entities, a master cell group MAC (MCG MAC) and a secondary cell group MAC (SCG MAC), plus corresponding RLC and PDCP. These are included in the resources of the UE for split bearer handling.

As mentioned above, only the MeNB has a RRC entity, so signalling radio bearers for RRC are transported over the MCG only, i.e. by MCG bearer. The SCG is not involved in the transporting of RRC messages. For UEs configured for dual connectivity and split bearer transport, user traffic from the core network can be received at the MeNB as a split bearer, and then divided between the MeNB and the SeNB for handling and passing to the UE. Any traffic on a SCG bearer is received from the core network at the SeNB and transported using resources of the SeNB to the UE.

In the context of LTE, further details regarding dual connectivity can be found in the <NUM> specification at sections <NUM> and <NUM>, and also in 3GPP TR <NUM>.

As can be seen from <FIG>, a bearer arrives at the PDCP protocol layer. The PDCP is involved in security of the data traffic, including ciphering using a key. Each PDCP in each network entity (eNBs and UEs, for example) will use its own key; these are regularly updated. The MeNB may use a key designated as KeNB, while the SeNB may use a key designated as SKeNB. Other parameters are utilised by the PDCP together with the key to effect security; these include a numerical counter to generate successive numbers in a sequence of count values. Hence there is a set of parameters, used in a security algorithm to perform the ciphering. Each set of parameters, one for each successive number from the count value, is used only once for ciphering, to maintain security. The count value has a maximum number that can be generated, so for a given key, once this number is reached, there are no new parameter sets available for ciphering. Re-use of parameters is undesirable, so it is preferred to acquire a new key for the PDCP and start the count value sequence again at its beginning (at zero, for example), to work through all successive values in the count value sequence with the new key. The expiration of the numbers available from the counter can be referred to as "rollover", and hereinafter the disclosure may mention "PDCP rollover", "PDCP counter rollover", "PDCP count rollover or "count rollover". The process following rollover, including acquisition of a new key, has a high processing overhead associated with it, and requires a resetting of the MAC layer for handling of ciphering with the new key.

An example of a possible network configuration for future telecommunications is an arrangement comprising an LTE architecture providing wide (macro) coverage in conjunction with a so-called new radio (NR), referring to current and future telecommunications methods allowing increased data throughput, such as 4th and 5th generations (<NUM> and <NUM>) and further. The type of radio access technology (RAT) used in the LTE network and the new radio network may be different, but an LTE network and a NR network could interwork, where a benefit of having connectivity to both LTE and NR is reduced signalling towards the core network from mobility towards the core network being anchored at the LTE macro entity, combined with higher throughput made possible be utilising resources in both LTE and NR. A UE will be configured to operate under both RATs. In this context, dual connectivity is relevant, such that MeNBs may be designated from LTE and SeNBs from NR, or vice versa.

Split bearers are therefore also relevant, and a new split bearer configuration is considered, namely a secondary cell group split bearer, or SCG split bearer.

<FIG> shows a schematic representation of an example user plane protocol stack utilising a SCG split bearer. As in <FIG>, a master node <NUM> (in this example in the LTE side) and a secondary node <NUM> each receive their designated bearers, MCG bearer <NUM> and SCG bearer <NUM> respectively, and these are handled by a PCDP, a RLC and a MAC layer, as before. No conventional split bearer is included, however; instead there is a SCG split bearer <NUM> which is delivered to the SeNB <NUM> (labelled Secondary gNB in <FIG> to indicate a difference from the eNB of <FIG> owing to the addition of the NR network). A PDCP in the SeNB <NUM> receives the SCG split bearer <NUM> and divides the data. Some is retained in the SeNB, being passed to the RLC and MAC layers. Other data is passed from the SeNB <NUM> to the MeNB <NUM> via an X protocol layer (labelled Xnew to indicate possible change from the X layers within LTE, such as the X1 layer in <FIG>), and the MeNB <NUM> handles it with its own RLC and MAC resources.

The SCG split bearer is proposed in the context of the higher data rates that can be handled in an NR architecture. Note this is merely an example, however, and secondary cell group split bearers are relevant in other contexts also.

<FIG> shows SCG split and SCG bearers together, and they may be simultaneously used or supported. SCG bearer can be considered as a special case of SCG split bearer, in which <NUM>% of the data traffic is over the SCG and <NUM>% over the MCG. Either or both of the SCG bearer and the SCG split bearer may coexist alongside the MCG bearer. However, coexistence of the MCG split bearer (as in the <FIG> example) and the SCG split bearer is unlikely owing to different transport requirements and hence a need for a high bandwidth in the user plane anchor. However, any coexistence of bearer types is not relevant to the present disclosure, and embodiments and examples addressing the SCG split bearer can be implemented regardless of other secondary node bearers.

However, the coexistence of the MCG bearer and the SCG split bearer implies that there will be at least one PDCP entity in the MCG, to handle the MCG bearer, and at least one PDCP entity in the SCG, to handle the SCG split bearer. Consequently, ciphering will be carried out using two keys, the KeNB in the MCG PDCP and the SKeNB in the SCG PDCP. The MeNB MAC receives data ciphered with both keys.

Recall the above discussion that mentioned PDCP count rollover. Under 3GPP Release <NUM> for dual connectivity, a "SCG change" procedure is defined for situations including a rollover of the SeNB PDCP receiving the SCG bearer. This is defined in section <NUM>. <NUM> of the <NUM> standard, and includes the requirement that "During SCG change, MAC configured for SCG is reset and RLC configured for SCG is re-established regardless of the bearer type(s) established on SCG. For SCG bearer, PDCP configured for SCG is re-established. In case of reconfiguration from split to MCG bearer, RLC configured for SCG is released. During SCG change, S-KeNB key is refreshed.

The SCG change procedure is applicable in a range of scenarios. <FIG> shows a depiction of the procedure, from standard <NUM> section <NUM>.

This scope of SCG change procedure is restricted to cells under control of the SeNB, and therefore in the SCG. However, a SCG split bearer will use a RLC instance in the MCG (see <FIG>), and share the MCG MAC with other MCG bearers including SRBs (signalling radio bearers, for RRC signalling). Also, note that in any change between MCG bearer and (conventional) split bearer there will be no need to reset any of the MCG resources because ciphering for both bearers is done in MCG PDCP (see <FIG>), and MCG RLC and MCG MAC can continue without any reset. This is not possible for the SCG split bearer, however, because the SCG PDCP in the SeNB will cipher the SCG split bearer, before passing it to resources in the MCG (RLC and MAC in the MeNB).

Hence, a difficulty can arise for SCG split bearers when a PDCP count rollover occurs in the SeNB. Recall from above that a count rollover initiates the SCG change procedure, which includes refreshing of the SKeNB key. Resources in the MeNB may then be unable to handle their allocated part of the SCG split bearer.

Standard <NUM>, section <NUM> specifies PDCP count in dual connectivity as: SCG bearers in DC share a common pool of radio bearer identities (DRB IDs) together with the MCG bearers and when no new DRB ID can be allocated for an SCG bearer without guaranteeing COUNT reuse avoidance, the MeNB shall derive a new S-KeNB. SeNB indicates to MeNB when uplink or downlink PDCP COUNTs are about to wrap around and MeNB shall update the S-KeNB. To update the S-KeNB, the MeNB increases the SCG Counter and uses it to derive a new S-KeNB from the currently active KeNB in the MeNB. The MeNB sends the newly derived S-KeNB to the SeNB. The newly derived S-KeNB is then used by the SeNB in computing a new encryption key KUPenc which is used with all DRBs in the SeNB for this UE. Furthermore, when the SCG Counter approaches its maximum value, the MeNB refreshes the currently active KeNB, before any further S-KeNB is derived.

From this we can appreciate that in the event of PDCP rollover for a SCG split bearer, it is required that the SCG change procedure should be initiated for the resources under the SeNB, i.e. SCG RLC and PDCP should be re-established and the SCG MAC is reset. In the scenario of LTR-NR interworking described above, it is likely that PDCP count rollover will happen in the NR PDCP (in other words, the SeNB, as in <FIG>), because the majority of the data traffic will be pushed using NR (rather than LTE) to take advantage of the higher throughput. Accordingly, following a similar logic, and because SCG split bearer data packets will be ciphered by the SCG PDCP, rollover of the SCG PDCP suggest a requirement for a change procedure in which the MCG RLC should be re-established, and the MCG MAC should also be reset.

Consequently, a proposal to address the issue of PDCP rollover in the SeNB when SCG split bearers are used is to ensure that appropriate handling of the MCG resources is undertaken, which is some examples includes resetting / re-establishing of the MCG RLC and the MCG MAC.

<FIG> shows a ladder diagram indicating steps in a first proposal of a method to achieve this. A network and its entities are configured for SCG split bearer use. For example, the entities comprise a UE <NUM>, a MeNB <NUM> in a LTE architecture and a SeNB <NUM> in a NR architecture. In a first step S1, PDCP count rollover is recognised in the SeNB <NUM>. In step S2, the SeNB <NUM> indicates to the MeNB <NUM> that PDCP rollover has occurred so that SeNB resource modification (reconfiguration) is required. In response, the MeNB <NUM> creates a new security key for the SeNB <NUM>, and sends it to the SeNB <NUM> in step S3. Note that steps S1, S2 and S3 are the same as in the known SCG change procedure. Under the proposal, however, a next step S4 requires the SeNB <NUM> to additionally indicate to the MeNB <NUM> that handling (modification, reconfiguration) of the MCG resources relevant to the SCG split bearer is required, so that the MCG RLC and the MCG MAC are to be reset; the MeNB <NUM> performs this. Finally, in Step S5, the MeNB <NUM> carries out RRC reconfiguration of the UE <NUM>. This also occurs in the SCG change procedure, in that the UE's SCG MAC is reset and its SCG RLC is re-established, but additionally here the UE's MCG MAC is reset and its MCG RLC is re-established (recall that the UE is provided with resources for both the MCG and the SCG for operation under dual connectivity, so it has two MAC entities, for example). The UE's SCG PDCP for the split SCG bearer is also re-established.

However, this solution presents issues in that resetting the MCG MAC will impact the SRBs and DRBs (signalling and data radio bearers) arriving at the MCG. There will be no issue regarding the RLC in the MeNB as there is a single instance of RLC per RB, but the MAC layer is configured for a whole cell group (MCG or SCG). Consequently, it would be preferable to avoid resetting the MAC. It is equivalent to moving the UE to RRC idle state, which is clearly problematic.

On the other hand, if the MCG MAC is not reset, one consequence is that there may be data packets (herein also "packets") in the MCG MAC HARQ buffer for the SCG split bearer which will halt a HARQ process or make it unusable. HARQ, or hybrid automatic repeat request, combines high-rate forward error correcting coding and ARQ error control, and is a process undertaken in the MAC, taking packets stored in the HARQ buffer. Resetting the MAC clears the buffer, and hence addresses any halt or unusability of a HARQ process. As a consequence, it is important to consider carefully the prospect of resetting or not resetting the MCG MAC to address an SCG PDCP count rollover.

A second proposal, alternative to that in <FIG> is to not reset the MCG MAC, and limit the handling of the MCG resources to a re-establishment of the MCG's RLC for SCG split bearer only. DRB release for conventional bearers does not involve a MAC reset, so omitting this procedure is feasible. Note however that it is assumed that there will be no packets queued in the HARQ for a bearer about to be released so that all processes continue as usual for the remaining DRBs.

A benefit of not resetting the MCG MAC for a SCG split bearer is that there will be no interruption of traffic on the MCG side of the link. However, there may be packets in the MCG MAC related to the SCG split bearer. An option to manage these is to continue with the transmission / reception until the HARQ processes have cleared, for example by setting a timer for the HARQ operation so that it is assumed to have cleared when the timer expires. Then, the MCG MAC discards any remaining packets related to the SCG split bearer after the MCG RLC has been re-established and the timer has expired (or the HARQ queue is otherwise empty or deemed empty).

For downlink traffic, one may arrange that the SCG PDCP stops sending packets to the MCG RLC well in advance of the MCG RLC re-establishment, so that the HARQ queue is empty before the RLC re-establishment is performed, or will be insufficiently full so as to certainly or near-certainly be able to empty during operation of the timer. Then there is no need to reset the MCG MAC. Under this regime, the UE may be notified well in advance that there is no requirement for its MCG MAC to be reset. For example, this information may be transmitted in a RRC/MAC/PHY layer message.

For the uplink, the network may reconfigure the UE with a split ratio for the SCG split bearer of zero percent for the MCG side of its resources (so that all split bearer traffic is diverted to the SCG side, thus avoiding the MCG side until regular operation after the count rollover has resumed). Alternatively, and similarly, the UE may be configured so that no uplink is granted on the MCG, again avoiding the MCG MAC during the critical time around count rollover.

<FIG> shows a ladder sequence of messages in an example procedure to implement the second proposal. The network is as in the <FIG> example, with a UE <NUM>, a MeNB <NUM> and a SeNB <NUM> configured for SCG split bearer operation. Steps S1 and S2 are as in <FIG>, but in this example, after the SeNB <NUM> notifies the MeNB <NUM> that modification is needed following a PDCP count rollover in step S2, in step S3a the SeNB <NUM> stops traffic to the MeNB <NUM>, and also the MeNB <NUM> stops the UE's uplink on MCG resources (by no uplink grant or by an explicit indication, for example). Then, in step S3b, there is a status report to the SeNB regarding the data in the MAC HARQ buffer, for example that the timer described above has expired or that the buffer is empty (no packets in the MCG side MAC). Then the procedure moves to step S3 which is the same as before, namely the provision of a new security key to the SeNB. Step S4 is modified compared to <FIG>, in that the SeNB <NUM> indicates a reset of the MCG RLC to the MeNB <NUM> but not an reset of the MCG MAC (this may be a definite instruction not to reset the MAC, or the absence of an instruction to do a reset). Finally, step S5 is similarly modified, in that the MeNB <NUM> performs an RRC reconfiguration of the UE <NUM>, which includes re-establishment of the UE's MCG RLC, but does not include resetting of the UE's MCG MAC.

So, the SeNB may stop downlink traffic towards the MCG, in step S3a, and rely on flow control feedback to ensure there are no packets left in the MAC buffer, as in step S3b.

Regarding the uplink from the UE, in order to ensure there are no uplink packets in the MCG MAC of the UE which is designated for SCG split bearer, one may implement the following:.

Each of these options can be used as a reliable indicator from the UE to the SeNB that buffers in the UE MCG MAC are clear. One or other can be used in conjunction with stopping the uplink traffic as in paragraph <NUM> above.

Finally, after the new key is delivered to the SeNB in step S3, the UE is informed about the handling of resources, as described above with reference to <FIG>.

A third proposal of a procedure to manage the SeNB PDCP rollover is that when the count rollover happens, the SeNB notifies this fact to the MeNB, and the MeNB moves the UE into a idle state, that is, the UE is moved to RRC idle. Alternatively, the SCG split bearer is released. In either case, traffic is no longer directed to the UE using the SCG split bearer, so inconsistencies between the SCG MAC and the MCG MAC are not liable to cause any problems.

In the event that in a given new radio (NR) architecture there is no RRC idle state, a fourth proposal is that the UE may instead be moved to a connected inactive state. This will have the same effect as a move to an idle state.

In a fifth proposal, in response to count rollover occurring or being about to occur in the SCG PDCP, the MeNB can perform an intra cell handover of the UE. The same RRC reconfiguration message might be used to effect the handover and to establish SCG split bearer. Mobility control information used for handover already includes resetting of MCG and SCG MAC, and associated RLC and PDCP handling and SCG configuration.

A sixth proposal is for the MeNB or the SeNB to change bearer type from SCG split bearer to SCG bearer before performing the SCG change on PDCP count rollover. Following the dual connectivity model, changing the bearer type also involves resetting of MCG MAC.

A seventh proposal is to not reset any resources, on either the MCG or the SCG. Instead, via RRC the UE is informed about the new key obtained for the SCG PDCP. Then the UE uses two keys (the old key and the new key) for some time before discarding the old key for decryption of received packets (so, when operating in downlink) when it is apparent that nothing is ciphered with the old key any longer. Other security input parameters could also be reset for the new key. The same behaviour might be employed in a new radio base station for uplink.

This proposal can be enhanced by use of a sequence number from the PDCP count which is designated as an activation sequence number. The network estimates a future sequence number that will be at a suitable time for the keys to be changed, and communicates it to the UE. Then, when this number is reached in the ciphering, both the network and the UE can synchronise the changeover from the old key to the new key. Alternatively, an activation sequence number may be designated from the sequence of numbers from a count in the RLC layer. The PDCP sequence number may become unreliable as it approaches rollover, so use of the RLC count avoids such problems; it is unlikely that both count values will rollover at the same time.

As an eighth proposal, one can add an additional parameter as an input to the security algorithm implemented by the SeNB SCG split bearer to perform ciphering. The additional parameter is added in when the count rolls over, as a way of effectively extending the count by allowing repeated sequence numbers to be recycled as "new" numbers by the inclusion of the additional parameter. A different additional parameter might be added at each count rollover, or the additional parameter might be replaced by a different additional parameter at each count rollover. Following this option, no resource on the MCG side or the SCG side needs to be reset.

An example new parameter is a new counter which is taken in account while generating encryption and integrity keys. Currently, integrity protection is enabled on SRBs, and it is unlikely that a SRB count would roll over. RRC message PDUs (protocol data unit, the output of a protocol layer to another) are not as frequent as data transmission PDUs in PDCP.

Another example is to add a new bit to the packet header when rollover occurs, thus making the combination unique and allowing all existing numbers from the counter to be used again, each with the new bit.

A further example is to send in the packet header a bitmap related to both the old key or keys and the new key or keys.

Some of the alternative proposals presented above rely on various assumptions about the network and its operation and architecture. For example, it is assumed that the S1-MME protocol layer (see <FIG>) will still be terminated in the MeNB for LTE-NR interworking. Also, that security keys for SeNB will be derived from KeNB in the MeNB using existing dual connectivity procedures (see supply of the new key to the SeNB in <FIG> and <FIG>). However, security keys may be provided to the NR PDCP directly from S1-MME for the SCG split bearer. If so, the core network would need to be involved in provision of the new key.

It has been assumed that the procedures described herein are triggered by the SeNB. However, the various proposal and techniques for resource handling are also applicable in the case of initiation by the MeNB.

We have assumed also that SCG resources related to the SCG split bearer will be reset or re-established. However, if the MCG side can survive without reset then the SCG side of resources can be saved from reset also.

In an LTE-NR interworking scenario, the various proposals are equally valid if the NR is the master instead of the LTE, except if the RLC entity is not agreed as part of the NR protocol stack, in which case the MCG RLC becomes irrelevant.

The proposals consider a single RRC entity in the LTE MeNB. However, each proposal is applicable regardless of the number of RRC entities or state machines, or the way RRC messages may be transported over NR (using L2 protocol stacks from MCG or SCG).

While the invention has been presented in terms of PDCP count rollover, the proposals may also be applied in situations where the rollover or expiry of any parameter will risk or prevent the uniqueness of security algorithm input parameters being maintained. For example, ciphering may rely on a key which is time-sensitive, so that expiry of the key is the trigger for the various procedures.

Note that SCG may operate in licensed or unlicensed bands.

Thus far, we have considered issues arising from PDCP rollover and the subsequent key change from the SCG change procedure in the context of SCG split bearers used in a dual connectivity arrangement such as LTE-NR interworking. Within the same framework, we can also consider a further change procedure which can have similar implications regarding resource reconfiguration. This is a PSCell change procedure.

Recall the network comprising a master cell group MCG and a secondary cell group SCG, respectively under control of a master eNB, MeNB, and a secondary eNB, SeNB. Within each group, we can designate a primary cell. So, the MCG has a primary cell PCell, and the SCG has a primary cell, the PSCell for primary secondary cell. The PSCell handles or controls uplink signalling within the cells of the SCG and the PCell handles or controls uplink signalling within the cells of the MCG. Any additional cells in the MCG are called secondary cells, Scells, while any additional cells in the SCG are called secondary secondary cells, SSCells.

<FIG> shows a schematic representation of such a network. The core network MME <NUM> supports a MeNB <NUM> which provides a PCell 205A. In this example the LTE provides the master. New radio NR provides the secondary, so that a secondary SeNB provides a PSCell 206A. SCells and SS Cells are not shown for clarity. A user equipment <NUM> communicates with both the MeNB <NUM> and the SeNB <NUM>. A SCG split bearer <NUM> is used to deliver data to the SeNB, where the split bearer <NUM> is divided between the resources of the SeNB and the MeNB before being transported by each base station to the user equipment <NUM>, as before.

The PSCell is able to be changed, so that a different cell in the SCG becomes the primary, i.e. a SSCell becomes the new PSCell and the original PSCell becomes a SSCell. In dual connectivity, this change also triggers the SCG change procedure discussed above (and depicted in <FIG>). Cells in a NR SCG have a small size, owing to operation at higher radio frequencies for NR compared to LTE, so mobility of entities will lead to frequent PSCell changes. Note that PCell change is also possible.

Various factors have relevance when considering how to manage a PSCell change. In this scenario, the physical uplink control channel PUCCH on the SCG is configured on the PSCell. Physical channel reconfiguration is required when a new cell takes the role of a PSCell, so that PUCCH resources are configured on the new PSCell, if previously not configured. PUCCH resources are not configured for all SCells in LTE. NR may follow the same principle, or may allow a PUCCH-like control channel on all configured SCells. Both the possibilities are within the current scope.

In dual connectivity, there is no linkage between the SKeNB key and the SCG counter, and the PSCell identity (ID). So, PSCell change is independent of SCG security. Conversely, the PCell Cell ID is used for KeNB calculation and NAS (non-access stratum) information is taken from the PCell (standard <NUM> section <NUM> ). Hence, PSCell change and PCell change procedures can differ from security point of view; there is no requirement for the procedures to be the same.

During SCG change, the SKeNB key is refreshed as described above. For NR, it is possible that handover and security procedures may be separated, so in the future, PSCell change (for handover or caused by mobility) may be performed without a SKeNB change.

The random access (RA) procedure, by which a UE accesses the network, is run on the PSCell. RA procedure requires new time alignment, so there has been a requirement to reset resources during the dual connectivity PSCell change procedure. However, a RACH (random access channel)-less handover procedure where source and target cells are synchronized has recently been proposed, so that in the future the RA procedure may not always be required, or if required have no associated resource reset.

Radio Link Monitoring is performed on the PSCell. A change in RLM configuration is required at PSCell change.

Uplink thresholds for traffic separation between the MCG and the SCG are configured in PDCP and these thresholds are provided by the LTE eNB.

In the context of NR, one may assume, in some cases, a radio access network (RAN) in which multiple data or distribution units (DU) are connected to a single control unit (CU) to provide the secondary cell group. Change of the PSCell is effected by allocating a different DU to provide the PSCell. Therefore, one can consider how to perform a PSCell change for non-standalone for a SCG split bearer, with multiple DUs connected to a CU on the NR, secondary, side.

PSCell change in dual connectivity is handled by the SCG change procedure, described above.

<FIG> shows a schematic representation of the protocol instances for LTE-NR tight internetworking in an example case where a UE is connected to a LTE macro and to a SeNB DU. LTE is the master and NR is SeNB. In this example, protocol stacks for two bearers are shown, the MCG bearer <NUM> and SCG split bearer <NUM>. The MCG bearer <NUM> has associated PDCP and RLC entities. The SCG split bearer <NUM> has resources in the CU of SCG PDCP, SCG RLC and SCG MAC. Owing to the split, it also has RLC resources in the MCG side. The MCG MAC is common for both the bearers, and handles the MCG bearer and the part of the SCG split bearer which is passed to the MCG by the SCG PDCP, as before.

In the earlier scenario, the SCG change procedure was triggered by the SCG PDCP counter rolling over, requiring a new key for the SCC PDCP and hence incompatibility between resources for the SCG split bearer on the SCG side and resources for the other part of the SCG split bearer on the MCG side.

In the current scenario, the SCG change procedure is triggered by a PSCell change. This gives a new SCG PDCP (with a different key and other ciphering algorithm parameters) on the SCG side, again giving incompatibilities between resources for the SCG split bearer on the SCG and the MCG side.

Owing to similarities in the two situations, one can apply various of the proposals outlined above for PDCP count rollover to the PSCell change situation. In particular, each of the first, second, third, fourth and fifth proposals is readily applicable to dealing with PSCell change. Hence, rather than the SCG split bearer PDCP count rollover in the SeNB being the trigger for the various methods of resource handling and management, the PSCell change is the trigger (arising, for example, from entity mobility requiring a different cell in the SCG being designated as the PSCell).

Other methods are also proposed to address the PSCell change situation. A dual connectivity SCG change procedure results in PDCP re-establishment, with the associated implication that the MCG RLC and MCG MAC need to be re-established and reset, leading to SRB disruption (as discussed above). However, considering LTE-WLAN aggregation whereby security and mobility procedures are separated, and a future C-RAN architecture of NR such as in <FIG>, PDCP re-establishment may not be necessary for PSCell change.

The <FIG> example is one possibility for a future architecture of centralised deployment, in which the SCG split bearer is divided after handling by the receiving PDCP. Other options are outlined in the 3GPP standard specification TR <NUM> covering non-centralised deployment (like the LTE architecture) and co-sited deployment (with LTE). <FIG> shows a diagrammatic representation of possible options for the splitting of bearers to be shared between resources. For both uplink and downlink, the split (for RRC and data) could be arranged at any of the successive protocol layers, so that bearer handling can be shared between two sets of resources A and B. Hence, various options <NUM> to <NUM> are contemplated, respectively for splitting before PDCP (or after for the opposite link direction), between PDCP and high level RLC, between high level RLC and low level RLC, between low level RLC and high level MAC, between high level MAC and low level MAC, between low level MAC and high level PHY (physical layer), between high level PHY and low level PHY, or between low level PHY and RF.

Hence one can consider further the alternatives of both PDCP re-establishment and PDCP maintenance when addressing the issues of resource handling for PSCell change.

Firstly, consider that the PDCP in the SCG is to be maintained.

A proposed approach is that, assuming PDCP is not re-established for PSCell change within a CU, the PDCP stops sending the traffic to the RLC protocol layers in both the SCG and the MCG. Information exchange between the UE and the network may be necessary in order to ensure that both sides are time-synchronised.

<FIG> shows a ladder diagram of steps (message sequence) in an example of such a method. The network includes a UE, a MeNB in LTE, and CU and DU SeNBs in NR. Firstly, the RRC entity(ies) in the MeNB or SeNB decide based on measurements that a PSCell change is required. UE measurements are reported to either a) MeNB or b) SeNB directly or c) received by MeNB and forwarded to SeNB over the X2New interface. Particular values of or changes in the measurements, such as those caused by UE mobility, can indicate a requirement for a new PSCell. Then the RRC informs the PDCP and RLC/MAC about the PSCell change decision, and may ask to stop the traffic. If SeNB is the entity which makes a decision about PSCell change, then SeNB RRC informs the MeNB (MCG-RLC, MCG MAC) over X2 and the UE over RRC. The UE RRC internally informs PDCP and RLC/MAC entities about PSCell change. Next, the SCG-PDCP entity in the UE (for the uplink) and in the SeNB (for the downlink) stops traffic towards both the MCG and SCG. This is for the purpose of obtaining an empty HARQ buffer in the MAC, and can be implemented as discussed previously under the second proposal for the first scenario, by configuring uplink thresholds and informing MeNB for downlink traffic, and receiving feedback from both the MeNB and the UE when buffers are empty. Then, the SCG RLC entities in the UE and the SeNB are re-established and the SCG MAC is reset. The PDCP is informed once it is complete. Finally, the PDCP restarts the traffic and may inform RRC about the completion of the procedure. If reordering function is in the PDCP only then NR-RLC (SCG-RLC in this example) may also not need a reset.

In an alternative in which the PDCP is re-established, PSCell change is handled locally within the SeNB but an explicit indication is necessary for the UE and MeNB such that it does not result in resetting of MCG MAC. This proposal assumes that PDCP is re-established. <FIG> shows a ladder diagram of steps (message sequence) in an example of such a method. Comparison with <FIG> shows that the methods are the same except for re-establishment of the SCG PDCP. A different RRC reconfiguration message for the UE is needed, to instruct re-establish of the SCG PDCP in the UE. Stopping of traffic is still required since the MCG-MAC is not to be reset.

As a final proposal, we consider a situation in which the SCG MAC in the NR side is not reset. One difference compared to above is that the SCG MAC has always been assumed to be reset because the assumption taken is that one DU controls a single cell, and a single MAC entity exists per DU. However, multiple cells may share a single MAC entity (scheduler), and UE NR SCG-MAC is able to support multiple cells. If both source and target cell are controlled by the same MAC-DU then cell change may take place via MAC level signalling. Alternatively, HARQ processes are separated per bearer in NR MAC, so resetting the resources specific to one bearer does not impact others.

This implies no traffic stopping procedure between the UE, MeNB and SeNB, a difference from the <FIG> examples. Also, there is no need for RRC/X2 signalling related to a traffic stop/start, and reset are expected. The SeNB changes the cell internally, taking measurements or any other internal criteria (e.g. load balancing on uplink/downlink control channels) into account, and uses MAC control element or physical layer signalling or similar means (e.g. RLC or PDCP control PDU) to notify the UE. The change of cells is expected to be quick enough that no interruption is noticeable on the MCG side and all entities are kept without reset or interruption. This is an improvement compared to the schemes of <FIG>.

These examples may also be applied for mobility within a NR MCG as well.

We have assumed in these examples that LTE is the master and NR is the secondary. For a deployment where NR is master and LTE is secondary, it is assumed that NR CU-DU split may happen and LTE may or may not support C-RAN architecture. No difference is foreseen between the two cases.

There has been described a method for use in a wireless telecommunications network, the mobile telecommunications network as defined by the claims.

Claim 1:
A method for use in a wireless telecommunications network, the mobile telecommunications network comprising:
a core network;
base stations supported by the core network and each providing wireless connectivity within at least one base station cell where the cells are arranged into a master cell group under control of a master base station (<NUM>) and a secondary cell group under control of a secondary base station (<NUM>), wherein in the secondary cell group one cell is designated as a primary secondary cell, and the master cell group and the master base station are configured within a Long Term Evolution radio access network, and the secondary base station is a core unit associated with distributed units providing the cells of the secondary cell group, the core unit and the distributed units configured under a different radio access network, the master cell group and the secondary cell group interworking to provide the wireless telecommunications network; and
a terminal device (<NUM>) configured to communicate wirelessly with the base stations including by the use of a split radio bearer receivable at the secondary cell group via the primary secondary cell for splitting between the secondary base station and the master base station before delivery to the terminal device;
the method being characterized by further comprising:
in the event of a need to change the designation of the primary secondary cell from a first cell to a second cell in the secondary cell group when the first cell and the second cell are both provided by a same distributed unit so that the first cell and the second cell share a common medium access control protocol layer, the change of the primary secondary cell from the first cell to the second cell is performed using signalling in the common medium access control protocol layer.