L2 processing for bearer type change

Abstract

The present disclosure relates to L2 handling for bearer type change. A method is provided, comprising: at a base station, transmitting, to a user equipment (UE), a radio resource control (RRC) reconfiguration message including an information element (IE) for split bearer configuration, wherein the base station is to allocate a previously unused logical channel identifier (LC-ID) for a data radio bearer (DRB) associated with packet data convergence protocol (PDCP) re-establishment, and a medium access control (MAC) entity is to discard MAC protocol data units (PDUs) with unknown LC-IDs to release a previous logical channel associated with the DRB including a previously unused LC-ID of the DRB without involving a secondary cell group (SCG) or master cell group (MCG) MAC reset, enabling to prevent data from the previous logical channel to reach a PDCP entity of the DRB without involving the SCG or MCG MAC reset; and transmitting data to the UE via a MCG bearer, a SCG bearer, or a split bearer.

Description

[0001] Case Separation Statement

[0002] This application is a divisional application of the invention patent application with PCT international application number PCT / US2018 / 037522, international application date June 14, 2018, Chinese national phase application number 201880053157.7, and invention title "L2 processing for bearer type change".

[0003] Cross-references to related applications

[0004] This patent application claims the benefit of U.S. Provisional Patent Application 62 / 520,867 (P119905Z), filed June 16, 2017, and U.S. Provisional Patent Application 62 / 525,001 (P120116Z), filed June 26, 2017. Both patent applications 62 / 520,867 and 62 / 525,001 are hereby incorporated herein by reference in their entirety. Technical Field

[0005] This disclosure relates to the field of wireless communication technology, and more particularly to L2 processing for bearer type change. Background Technology

[0006] Currently, there are many different bearer types for 5G New Radio (5NR) systems, including primary cell group (MCG) bearers, secondary cell group (SCG) bearers, MCG split bearers, and SCG split bearers. Attempts have been made to merge MCG split bearers and SCG split bearers. Even so, there are many different types of bearer type changes to define and the behavior for each. Furthermore, under the current model, it is difficult to extend split bearers to more than two cell groups.

[0007] For Long Term Evolution (LTE) and New Radio (LTE-NR) Dual Connectivity (DC), the following should be considered for Layer 2 (L2 processing): First, changes to the LTE Packet Data Convergence Protocol (PDCP) entity to / from the NR PDCP entity should be considered. Second, in cases where the unified bearer of SCG split bearers and MCG split bearers should be treated as split bearers, the User Equipment (UE) may not be able to identify whether PDCP and / or RLC re-establishment is required. Third, changes to the Secondary Node (SN) with UE mobility may not result in PDCP changes, thus no security configuration changes. Fourth, in addition to SCG Media Access Control (MAC) resets, MCG MAC resets should also be provided for SCG split bearers with SN changes with UE mobility, as well as for bearer type changes between MCG split bearers and SCG split bearers. Summary of the Invention

[0008] Some embodiments of this disclosure provide a method comprising: at a base station, sending a Radio Resource Control (RRC) reconfiguration message to a User Equipment (UE) including an Information Element (IE) for Split Bearer Configuration, wherein the base station is configured to assign a previously unused Logical Channel Identifier (LC-ID) to a Data Radio Bearer (DRB) associated with a Packet Data Convergence Protocol (PDCP) Re-establishment, and a Media Access Control (MAC) entity is configured to discard MAC Protocol Data Units (PDUs) having unknown LC-IDs to release a previously unused logical channel associated with the DRB, including the previously unused LC-ID of the DRB, without involving a Secondary Cell Group (SCG) or Primary Cell Group (MCG) MAC reset, such that data from the previously logical channel can be prevented from reaching the DRB's PDCP entity without involving an SCG or MCG MAC reset; and transmitting data to the UE via an MCG bearer, an SCG bearer, or a split bearer.

[0009] Some embodiments of this disclosure provide a processor for a base station configured to perform operations including: sending a Radio Resource Control (RRC) reconfiguration message to a User Equipment (UE) including an Information Element (IE) for Split Bearer Configuration, wherein the base station is configured to assign a previously unused Logical Channel Identifier (LC-ID) to a Data Radio Bearer (DRB) associated with a Packet Data Convergence Protocol (PDCP) re-establishment, and a Media Access Control (MAC) entity is configured to discard MAC Protocol Data Units (PDUs) with unknown LC-IDs to release a previously unused logical channel associated with the DRB, including the previously unused LC-ID of the DRB, without involving a Secondary Cell Group (SCG) or Primary Cell Group (MCG) MAC reset, enabling the PDCP entity to prevent data from the previously logical channel from reaching the DRB without involving an SCG or MCG MAC reset; and sending data to the UE via an MCG bearer, an SCG bearer, or a split bearer. Attached Figure Description

[0010] The subject matter for which protection is sought is specifically pointed out and clearly requested in the concluding section of this specification. However, in conjunction with the appendix... Figure 1 When reading this text, one can understand this subject matter by referring to the following specific implementation methods, in which:

[0011] Figure 1 It is a schematic diagram of a Layer 2 (L2) radio network architecture according to one or more implementation schemes, which includes a primary cell group (MCG) bearer, a secondary cell group (SCG) bearer, and a split bearer arrangement;

[0012] Figure 2A and Figure 2B This is a schematic diagram of a LTE-NR split bearer deployment via a primary cell group (MCG) according to one or more implementation schemes;

[0013] Figure 3A and Figure 3B This is a schematic diagram of a LTE-NR split bearer deployment via secondary cell groups (SCGs) according to one or more implementation schemes;

[0014] Figure 4 This is a schematic diagram of the Radio Resource Control (RRC) connection reconfiguration process according to one or more implementation schemes;

[0015] Figure 5 It is a schematic diagram illustrating the changes from a single-connection bearer to a multi-connection bearer by configuring or releasing one or more logical channels according to one or more implementation schemes;

[0016] Figure 6 and Figure 7 This is a schematic diagram of a Radio Resource Control (RRC) reconfiguration process according to one or more implementation schemes, which shows the reconfiguration completion process and the RRC connection re-establishment process, respectively.

[0017] Figure 8 The system architecture of the network according to some implementation schemes is shown;

[0018] Figure 9 Example components of a device according to some embodiments are shown; and

[0019] Figure 10 An example interface of a baseband circuit according to some implementation schemes is shown.

[0020] It should be understood that, for the sake of brevity and / or clarity, the elements shown in the figures are not necessarily drawn to scale. For example, the dimensions of some elements may be enlarged relative to others for clarity. Furthermore, reference numerals are repeated between figures where appropriate to indicate corresponding and / or similar elements. Detailed Implementation

[0021] In the following detailed description, numerous specific details are set forth to provide a comprehensive understanding of the claimed subject matter. However, those skilled in the art will understand that the claimed subject matter can be implemented without these specific details. In other instances, well-known methods, processes, components, and / or circuits are not described in detail.

[0022] See now Figure 1This paper will discuss a schematic diagram of a Layer 2 (L2) radio network architecture according to one or more implementation schemes, which includes a primary cell group (MCG) bearer, a secondary cell group (SCG) bearer, and a split bearer arrangement. Figure 1 The Layer 2 (L2) processing of Long Term Evolution (LTE) Dual Connectivity (DC) (referred to as LTE-LTE DC) between the lead eNB (MeNB) and the secondary eNB (SeNB) is illustrated. In network 100, the Evolved Packet Core (EPC) 110 controls MeNB 112 and SeNB 114 via the SI interface.

[0023] MeNB 112 and SeNB 114 may include one or more of the following Layer 2 entities: Packet Data Convergence Protocol (PDCP) 116, Radio Link Control (RLC), and Media Access Control (MAC) 120. In a dual-connectivity arrangement, MeNB 112 or SeNB 114, or both, may deliver data to User Equipment 122 via one or more bearer types. Bearer types may include Primary Cell Group (MCG) bearer type 124, which includes Signaling Radio Bearer (SRB1) 126, Signaling Radio Bearer (SRB2) 128, and bearer 130. Bearer types may also include Secondary Cell Group (SCG) bearer type 132, which includes bearer 134. Bearer types may also include split bearer type 136, for example, where bearer 128 in MeNB 112 is split into split bearer 140 and split bearer 142 between MeNB 112 and SeNB 114. Split bearer 142 is provided from MeNB 112 to SeNB 114 via the X2 interface, such that split bearer 140 is provided from MeNB 112 to UE 122, and split bearer 142 is provided from SeNB to UE 122.

[0024] In LTE DC, SCG changes can be performed on bearer type changes, as described below. An SCG change is a synchronous SCG reconfiguration process involving random access (RA) to the primary and secondary cells (PSCell) and includes resetting / re-establishing Layer 2, and, if the SCG Data Radio Bearer (DRB) is configured, also includes a security refresh. This process is used in many different scenarios, such as SCG establishment, PSCell changes, key refreshes, and / or DRB type changes. UE 122 performs SCG change-related actions upon receiving an RRCConnectionReconfiguration message including the mobilityControlInfoSCG, as described, for example, in section 5.3.10.10 of the 3GPP Technical Specification (TS) 36.331.

[0025] Details of the L2 processing (PDCP and RLC and MAC entity processing) for bearer type addition and modification are provided in 3GPP TS36.331, Sections 5.3.10.3al (MCG and SCG L2 processing on PDCP and RLC) and 5.3.10.10 (SCG modification process), which are copied below.

[0026] 5.3.10.3al DC-specific DRB addition or reconfiguration

[0027] For the drb-Identity value used to initiate this procedure, the UE should:

[0028] 1> If drb-ToAddModListSCG is received and includes the drb-Identity value; and

[0029] The drb-Identity value is not part of the current UE configuration (i.e., a DC-specific DRB is established);

[0030] 2> If drb-ToAddModList is received and includes the drb-Identity value (i.e., add a split DRB);

[0031] 3> Create a PDCP entity and configure it with the current MCG security configuration and according to the pdcp-Conflg included in drb-ToAddModList;

[0032] 3> Establish the MCG RLC entity and MCG DTCH logical channel based on the logicalChannelConfig, rlc-Conflg, and logicalChanneldentity included in drb-ToAddModList;

[0033] 3> Establish the SCG RLC entity and SCG DTCH logical channel based on logicalChannelConfigSCG, logicalChanneldentitySCG and rlc-ConflgSCG included in drb-ToAddModListSCG;

[0034] 2> Otherwise (i.e., add SCG DRB):

[0035] 3> Create a PDCP entity and configure it with the current SCG security configuration and according to the pdcp-Conflg included in drb-ToAddModListSCG;

[0036] 3> Establish the SCG RLC entity and SCG DTCH logical channel based on logicalChannelConfigSCG, logicalChanneldentitySCG and rlc-ConflgSCG included in drb-ToAddModListSCG;

[0037] 2> Instruct the upper layer to establish the DRB and the EPS of the established DRB-

[0038] Bearer identity;

[0039] Otherwise (i.e., DC-specific DRB modifications; drb-ToAddModList and / or drb-

[0040] ToAddModListSCG is received):

[0041] 2> If the DRB indicated by drb-Identity is a split DRB:

[0042] 3> If drb-ToAddModList is received and includes the drb-Identity value, and for that entry, drb-TypeChange is included and set to toMCG.

[0043] (i.e., splitting into MCG):

[0044] 4> Release the SCG RLC entity and the SCG DTCH logical channel;

[0045] 4> Configure the PDCP entity according to pdcp-Config, if it is included in drb-ToAddModList;

[0046] 4> Reconfigure MCG based on rlc-Conflg and logicalChannelConflg

[0047] RLC entities and / or MCG DTCH logical channels, if included in drb-ToAddModList:

[0048] 3> Otherwise (i.e., reconfigure the split):

[0049] 4> Reconfigure the PDCP entity according to pdcp-Conflg, if it is included in drb-ToAddModList;

[0050] 4> Reconfigure the MCGRLC entity and / or MCG DTCH logical channel according to rlc-Conflg and logicalChannelConflg, if included in drb-ToAddModList;

[0051] 4> Reconfigure the SCG RLC entity and / or SCG DTCH logical channel according to rlc-ConflgSCG and logicalChannelConfigSCG, if included in drb-ToAddModListSCG;

[0052] 2> If the DRB indicated by drb-Identity is an SCG DRB:

[0053] 3> If drb-ToAddModList is received and includes the drb-Identity value, and for that entry, drb-TypeChange is included and set to toMCG.

[0054] (i.e., from SCG to MCG):

[0055] 4> Reconfigure the PDCP entity with the current MCG security configuration and according to pdcp-Conflg, if it is included in drb-ToAddModList;

[0056] 4> Reconfigure the SCG RLC entity and SCG DTCH logical channel as the MCG RLC entity and MCG DTCH logical channel;

[0057] 4> Reconfigure the MCG RLC entity and / or MCG DTCH logical channel according to rlc-Conflg, logicalChannelConflg, and logicalChannelConflg, if included in drb-ToAddModList;

[0058] 3> Otherwise (i.e., drb-ToAddModListSCG is received and includes drb-

[0059] Identity value (i.e., reconfiguring SCG):

[0060] 4> Reconfigure the PDCP entity according to pdcp-Conflg, if it is included in drb-ToAddModListSCG;

[0061] 4> Reconfigure the SCG RLC entity and / or SCG DTCH logical channel according to rlc-ConflgSCG and logicalChannelConfigSCG, if included in drb-ToAddModListSCG;

[0062] 2> If the DRB indicated by drb-Identity is an MCG DRB:

[0063] 3> If drb-ToAddModListSCG is received and includes the drb-Identity value, and for that entry, drb-Type is included and set to split (i.e., MCG to split):

[0064] 4> Reconfigure the PDCP entity according to pdcp-Conflg, if it is included in drb-ToAddModList;

[0065] 4> Reconfigure MCG based on rlc-Conflg and logicalChannelConflg

[0066] RLC entities and / or MCG DTCH logical channels, if included in drb-ToAddModList;

[0067] 4> Establish the SCG RLC entity and SCG DTCH logical channel based on logicalChannelConfigSCG, logicalChanneldentitySCG and rlc-ConflgSCG included in drb-ToAddModListSCG;

[0068] 3> Otherwise (i.e., drb-Type is included and set to scg, i.e., MCG to SCG);

[0069] 4> Reconfigure the PDCP entity with the current SCG security configuration and according to pdcp-Config, if it is included in drb-ToAddModListSCG;

[0070] 4> Reconfigure the MCG RLC entity and MCG DTCH logical channel as the SCG RLC entity and SCG DTCH logical channel;

[0071] 4> Reconfigure SCG RLC entities and / or their corresponding logicalChannelConfigSCG entities based on rlc-ConfigSCG, logicalChanneldentitySCG, and logicalChannelConfigSCG.

[0072] Or the SCG DTCH logical channel, if included in drb-ToAddModListSCG;

[0073] 5.3.10.10SCG Reconfiguration

[0074] UE should:

[0075] 1> If makeBeforeBreakSCG is configured:

[0076] 2> Stop timer T313 if it is running;

[0077] 2> Start timer T307 and set the timer value to t307, as included in mobilityControlInfoSCG;

[0078] 2> Start syncing the DL to the target PSCell, if necessary;

[0079] 2> Perform the remainder of the procedure, including and following the MAC reset after the UE has stopped uplink transmission / downlink reception with the source SCG cell;

[0080] Note 0a: When to stop uplink transmission / downlink reception with the source SCG cell to start

[0081] The retuning of the connection to the target cell

[16] depends on the specific implementation of the UE, if makeBeforeBreakSCG is configured.

[0082] 1> If the received scg-Configuration is set to release or includes mobilityControlInfoSCG (i.e., SCG release / change):

[0083] 2> If mobilityControlInfo is not received (i.e., SCG is released / modified without HO):

[0084] 3> Reset the SCG MAC, if configured;

[0085] 3> For each drb-Identity value that is part of the current UE configuration:

[0086] 4> If the DRB indicated by drb-Identity is an SCG DRB:

[0087] 5> Re-establish the PDCP entity and SCG RLC entity;

[0088] 4> If the DRB indicated by drb-Identity is a split DRB:

[0089] 5> Perform PDCP data recovery and re-establish the SCG RLC entity;

[0090] 4> If the DRB indicated by drb-Identity is an MCG DRB; and

[0091] 4> The drb-ToAddModListSCG is received and includes the drb-Identity value, while for that entry, the drb-Type is included and set to scg.

[0092] (That is, from MCG to SCG):

[0093] 5> Re-establish the PDCP entity and MCG RLC entity;

[0094] 3> Configure lower layers to account for SCG SCells (except PSCells) being in a deactivated state;

[0095] 1> If the received scg-Configuration is set to release:

[0096] 2> Release the entire SCG configuration, except for the DRB configuration (i.e., such as drb-

[0097] (Configured by ToAddModListSCG);

[0098] 2> If the current UE configuration includes one or more split or SCG DRBs and the received RRCConnectionReconfiguration message includes drb-

[0099] radioResourceConflgDedicated of ToAddModList:

[0100] 3> Reconfigure the SCG or split the DRB using the drb-ToAddModList specified in 5.3.10.12;

[0101] 2> Stop timer T313 if it is running;

[0102] 2. Stop timer T307 if it is running;

[0103] 1> Otherwise:

[0104] 2> If the received scg-ConfigPartMCG includes scg-Counter.

[0105] 3> Update the S-KeNB key based on the KeNB key and using the received scg-Counter value, as specified in TS33.401

[32] ;

[0106] 3> Derive the KuPenc key associated with the cipheringAlgorithmSCG included in the mobilityControlInfoSCG within the received scg-ConfigPartSCG, as specified in TS 33.401

[32] ;

[0107] 3> Configure lower layers to apply encryption algorithms and K UPenc Key;

[0108] 2> If the received scg-ConfigPartSCG includes radioResourceConfigDedicatedSCG

[0109] 3> Reconfigure the dedicated radio resource configuration of the SCG as specified in 5.3.10.11;

[0110] 2> If the current UE configuration includes one or more split or SCG DRBs and the received RRCConnectionReconfiguration message includes radioResourceConfigDedicated with drb-ToAddModList:

[0111] 3> Reconfigure the SCG or split the DRB using the drb-ToAddModList specified in 5.3.10.12;

[0112] 2> If the received scg-ConfigPartSCG includes sCellToReleaseListSCG:

[0113] 3> Perform SCell release for SCG, as specified in 5.3.10.3a;

[0114] 2> If the received scg-ConfigPartSCG includes pSCellToAddMod:

[0115] 3> Perform PSCell additions or modifications, as specified in 5.3.10.3c;

[0116] Note 0: This process is also used to release PSCells, such as PSCell changes and PSCell SI changes.

[0117] 2> If the received scg-ConfigPartSCG includes sCellToAddModListSCG:

[0118] 3> Perform SCell additions or modifications as specified in 5.3.10.3b;

[0119] 2> Configure lower layers based on mobility ControlInfoSCG (if received);

[0120] 2> If rach-SkipSCG is configured:

[0121] 3> Configure a lower layer to apply a rach-SkipSCG to the target SCG, as specified in TS 36.213

[23] and TS 36.321[6];

[0122] 2> If the received scg-ConfigPartSCG includes mobilityControlInfoSCG (i.e., an SCG change):

[0123] 3> Restore all SCG DRBs and resume SCG transmissions used for splitting DRBs (if they have been paused);

[0124] 3. Stop timer T313 if it is running;

[0125] 3> Start timer T307 and set the timer value to t307, as included in mobilityControlInfoSCG, if makeBeforeBreakSCG is not configured;

[0126] 3> Start syncing the DL to the target PSCell;

[0127] 3> Initiate a random access procedure on the PSCell as specified in TS 36.321[6] if the rach-SkipSCG is not configured;

[0128] Note 1: The UE does not need to determine the SFN of the target PSCell by obtaining system information from the cell before performing RACH access in the target PSCell.

[0129] 3> This process ends, but the difference is that when the MAC successfully completes the random access procedure on the PSCell or when the MAC indicates that a PDCCH transmission for C-RNTI has been successfully received, and if rach-skipSCG is configured, the following actions are performed:

[0130] 4> Stop timer T307;

[0131] 4> Release ul-Conflglnfo, if configured;

[0132] 4> The application does not require the UE to know any part of the target PSCell's SFN CQI report configuration, scheduling request configuration, and probe RS configuration, if any;

[0133] 4> When acquiring the SFN of the target PSCell, the application needs the UE to know parts of the measurement and radio resource configuration of the SFN of the target PSCell (e.g., periodic CQI reports, scheduling request configuration, probe RS configuration), if available;

[0134] Note 2: Whenever the UE needs to set or reconfigure the settings according to the received fields, it should apply the new settings.

[0135] Configuration, except for the cases described above.

[0136] The L2 processing for the bearer type change in LTE-LTE DC is summarized in Table 1 below.

[0137]

[0138] Table 1: L2 processing of LTE-LTE DC

[0139] Now for reference Figures 2A to 2B as well as Figure 3A and Figure 3B The diagrams will be discussed illustrating the LTE-NR split bearer deployments via the primary cell group (MCG) and the secondary cell group (SCG), respectively. Figure 2A The diagram shows the split bearer arrangement between the LTE MeNB 112 and the NR secondary 5G NodeB (SgNB) 214, while Figure 2B The diagram illustrates a split bearer arrangement between the NR primary 5G NodeB (MgNB) 212 and the LTE SeNB 114, where the split is via the MCG. Similarly, Figure 3A The split bearer arrangement between the LTE MeNB112 and the NR SgNB 214 is shown, while Figure 3B The split-bearing arrangement between MgNB 212 and SeNB 114 is shown, wherein the split is via SCG.

[0140] For LTE-NR DC (also known as EUTRAN-NR DC (EN-DC)), there are many different bearer types, including MCG bearer, SCG bearer, MCG split bearer, and SCG split bearer. It has been proposed to merge MCG split bearers and SCG split bearers into a single unified split bearer, where UE 122 only sees the split bearer type. In one or more implementations, network 100 may conform to the fifth-generation (5G) New Radio (NR) standard, enabling support for LTE-NR DC. To support LTE-NR DC, the following factors can be considered for L2 processing:

[0141] 1. Changes from / to the LTE PDCP entity to the NR PDCP entity

[0142] 2. When SCG split bearers and MCG split bearers are treated as unified bearers of split bearers, UE 122 may not be able to identify whether a re-establishment needs to be performed.

[0143] 3. Changes to the secondary node (SN) for UE mobility may not result in changes to PDCP, therefore there are no security configuration changes.

[0144] 4. In addition to SCG MAC reset, MCG MAC reset may also be required for SCG split bearers with SN changes due to UE mobility, as well as for bearer type changes between MCG split bearers and SCG split bearers.

[0145] For (1), this will affect the bearer type change of MCG to / from SCG and SCG split bearers. If the LTE PDCP entity is different from the NR PDCP entity, then LTE / NR PDCP needs to be established during the bearer type change of MCG to / from SCG and SCG split bearers, rather than reconfigured. However, such establishment will mean that the PDCP sequence number will be reset, so some data may be lost during the transition. In some implementations, the NR PDCP entity can be used for all bearers in Evolved Universal Terrestrial Radio Access (E-UTRA) New Radio Interface (NR) Dual Connectivity (DC), referred to as the (EN-DC) case. If this is the case, then reconfiguration can still be used. However, this will mean that the LTE side will have to implement NR PDCP for EN-DC, and there may be the same problem of switching from LTE PDCP to NR PDCP and vice versa when EN-DC is configured / deconfigured. Alternatively, UE 122 will always use the LTE PDCP entity, and network 100 may comply with the limitations of LTE PDCP. For example, the SN length of DC is 15 or 18, while the size of PDCP Service Data Unit (SDU) is 8088 bytes instead of 9K bytes.

[0146] For (2), in the case of unified split bearer, UE 122 only sees the split bearer type. UE 122 does not know if there are any changes to PDCP, and therefore does not know whether PDCP needs to be re-established due to MCG split bearer to / from SCG split bearer or / and MCG / SCG split bearer to MCG / SCG split bearer (and whether LTE RLC needs to be re-established).

[0147] For (3), UE 122 may not know whether the change of SN will involve the re-establishment of PDCP.

[0148] For (4), an SCG MAC reset can be performed for SN changes due to UE 122 mobility. Bearer type changes use the SN change procedure to simplify the PDCP and RLC re-establishment process. In addition to the SCG MAC reset for SN changes, an SCG MAC reset must also be performed for bearer type changes between MCG split bearers and SCG split bearers, where the PDCP position is changed. The reason for the reset is to clear MAC Protocol Data Units (PDUs) configured using the old security key.

[0149] In one or more implementations, to avoid data loss, lossless reconfiguration can be performed from LTE PDCP to NR PDCP and vice versa. UE 122 can receive indications from network 100, such as from EPC 110, regarding whether to perform PDCP re-establishment or recovery and whether a key change is required. Furthermore, MAC reset can be avoided as long as the PDCP PDU encoded with the old security key is discarded before reaching the reconfigured PDCP entity. Alternatively, an indication of whether the PDCP payload is encoded with the old or new key can be provided in the PDCP header, allowing the PDCP entity to discard the PDCP PDU (if it is encoded with the old key) or decrypt the PDCP PDU using the old key.

[0150] PDCP reconfiguration between NR PDCP and LTE PDCP or between NR PDCPs, where MCG PDCP is also NR. PDCP

[0151] In one or more implementations, a reconfiguration between LTE PDCP and NR PDCP can be performed to avoid data loss. Such PDCP reconfiguration would mean that the network must ensure the use of a consistent SN length. If the PDCP SN has been increased to 18 bits, then network 100 will have to continue using the 18-bit PDCP SN length, even on LTE DC.

[0152] Split Data Radio Bearers (DRBs) can be either MCG-split DRBs or SCG-split DRBs on the network side. Changes in bearer type from an MCG bearer to an MCG-split bearer can be performed without key changes or PDCP re-establishment, while changes from an MCG bearer to an SCG-split bearer will involve key changes and PDCP re-establishment. Therefore, all the different possibilities can be supported. Changes between LTE PDCP and NR PDCP can support the following lossless reconfiguration.

[0153] 1.p For MCG to SCG split bearer and vice versa, there is re-establishment and key change functionality.

[0154] 2. For MCG split bearer to MCG bearer, data recovery is possible without key change.

[0155] 3. For MCG-to-MCG split bearer, there is no key change or data recovery.

[0156] Since UE 122 does not know what kind of lossless reconfiguration can be used, the type of lossless reconfiguration can be indicated in the configuration when such reconfiguration is performed.

[0157] MAC reset of MCG and SCG to avoid

[0158] Both MCG and SCG MAC resets affect not only the bearer of interest but also other bearers and signaling radio bearers (SRBs). The reason for the reset is to clear the soft buffers and Hybrid Automatic Repeat Request (HARQ) buffers of MAC PDUs using older security keys. To avoid the SCG / MCG MAC reset clearing buffers, the following methods can be implemented in one or more implementations.

[0159] 1. Assigning a new logical channel identifier (LC-ID or LCID) to a DRB associated with PDCP re-establishment or bearer type change requires an SCG or MCG MAC reset. The MAC will discard MAC PDUs with unknown LC-IDs.

[0160] 2. The PDCP header of the PDCP PDU includes a one-bit switching bit to indicate whether the PDCP PDU is encrypted or protected with a previous or new key, and the PDCP entity discards the PDCP PDU with the previous key indication or decrypts the PDCP PDU with the old or new key accordingly.

[0161] a. Instead of a one-bit switching bit, the PDCP header of the PDCP PDU includes an index indicating the key used. Upon receiving the PDCP PDU, the PDCP entity will either decrypt the PDCP payload based on the key indexed in the PDCP header or simply discard it.

[0162] 3. Allow MAC PDUs with PDCP-level integrity protection using old security keys to be sent to PDCP, leaving them for PDCP to discard if integrity protection fails.

[0163] Method 1 can be used if the RLC entity associated with the DRB is reset / re-established. When the RLC is reset / re-established, all state variables can be reset and the RLC SN can be initialized. The MAC PDU associated with the previous RLC SN can be discarded. If the RLC entity associated with the DRB is not reset / re-established, Method 2 can be used. Since the RLC entity is not re-established, the existing state variables and SN will continue. Sending a MAC PDU containing the existing RLC SDU will then be no problem for the RLC entity. Another method for the MCG branch is to use the end marker in the PDCP header. In the MCG branch, the RLC entity associated with the DRB is the LTE RLC, i.e., the MCG branch, and the RLC PDUs can be delivered to the PDCP entity in sequence. If the RLC entity is not reset / re-established, the PDCP entity can receive the PDCP PDUs in sequence. Upon receiving the end marker in the PDCP header of the PDCP PDU, the PDCP entity can stop using the old key and perform decryption with the new key.

[0164] See now Figure 4 This section will discuss a schematic diagram of the Radio Resource Control (RRC) connection reconfiguration process according to one or more implementation schemes. As mentioned above, lossless reconfiguration can be performed from LTE PDCP to NR PDCP or vice versa. UE 122 can receive instructions from network 100, such as from Evolved Universal Terrestrial Radio Access Network (EUTRAN) 410, regarding whether to perform PDCP re-establishment or restoration and whether a key change is required. Such instructions can be provided to UE 122 by EUTRAN 410 as... Figure 4The illustrated Radio Resource Control (RRC) connection reconfiguration procedure 400 is part of, for example, an RRCConnectionReconfiguration message 412 sent by EUTRAN 412 to UE 122. UE 122 can respond accordingly, for example, with an RRCConnectionReconfigurationComplete message 414. It should be noted that the RRC connection reconfiguration procedure 400 is merely one example of an indication of whether to perform PDCP re-establishment or recovery and whether a key change is required for UE 122, where various other procedures such as the RRC connection establishment procedure or in the PDCP header can be utilized, and in this respect, the scope of the subject matter for which protection is requested is not limited.

[0165] In one or more implementations, the Layer 2 processing for bearer type changes is available in Appendix A of 3GPP TS37.340 V15.1.0 (2018-03), as shown in Table 2 below. Appendix A provides information on the overview of L2 processing for bearer type changes in EN-DC, with and without security key changes (from KeNB to S-KgNB and from S-KgNB to KeNB), i.e., with and without end-point changes. It should be noted that MAC behavior depends on the scheme chosen by the network, such as MAC reset, LCID change, etc.

[0166]

[0167]

[0168] Table 2: L2 processing of bearer type changes with and without security key changes

[0169] It should be noted that in Table 2 above, the MAC behavior depends on the scheme selected by the network, such as MAC reset, LCID change, etc. For MAC reset, the signaling is based on the change of LCID via releasing and adding DRBs. Phase 2 text is indicated in Appendix A of TS37.340, as shown in Table 2 above. LCID values ​​0 to 2 correspond to SRB ID values ​​0 to 2, and LCID values ​​3 to 10 correspond to DRB ID values ​​1 to 8.

[0170] See now Figure 5This paper will discuss schematic diagrams illustrating changes from single-connectivity to multi-connectivity bearers by configuring or releasing one or more logical channels, according to one or more implementation schemes. Currently, there are many different bearer types for 5G NR: MCG bearers, SCG bearers, MCG split bearers, and SCG split bearers. In one or more implementation schemes, MCG split bearers and SCG split bearers can be combined. Even so, there are many different types of bearer type changes to define and the behavior for each.

[0171] Instead of modeling the bearer type, bearer configuration 500 can be considered as a Data Radio Bearer (DRB) 510, having a Packet Data Convergence Protocol (PDCP) or higher protocol layer as the primary "bearer or DRB" with one or more logical channels of RLC or higher, such as logical channel 512 (RLC or lower) in cell group 1, logical channel 514 (RLC or lower) in cell group 2, logical channel 516 (RLC or lower) in cell group 3, etc. Figure 5 As shown.

[0172] DRB section 510 (PDCP and above) does not need to be associated with any specific node such as a primary node, secondary node, etc. A logical channel is part of a cell group. Changes can be made simply by configuring or releasing the logical channel associated with the DRB, rather than changing from one “bearer type” to another. For example, logical channel 516 can be configured or released as shown in configuration 518. Furthermore, protocol layer behavior, such as whether it is reset or re-established, can be explicitly notified by signaling, rather than being associated with a bearer type change. A logical channel may also be suspended for any reason, such as the cell being inactive or the cell being released, while communication can continue through other logical channels. A suspended logical channel configuration 518 can subsequently be “revived” or cleared or transferred to another cell group.

[0173] The DRB 510 with a PDCP portion can be reconfigured and re-established when there are node changes on the network, such as when changing from an MCG-based bearer (MCG or split) to an SCG-based bearer, or when there is a SN node change. Alternatively, for such changes, the DRB 510 with the PDCP configuration can be released and added. The release / addition process may or may not retain the PDCP sequence number (SN), depending on whether lossless delivery is involved. It should be noted that changes from / to legacy networks will involve changes from / to LTE PDCP and LTE bearer types, which can be performed during handover (HO).

[0174] One consequence of unifying the split bearer type is that, from the perspective of the RAN2 (UE) specification, and from both the control plane and user plane perspectives, only one split bearer type exists. This arrangement simplifies the UE 122 specification because only one bearer type is considered, and it reduces the number of bearer type changes that need to be supported. This result is achieved when the bearer type is unified from both the control plane and user plane perspectives.

[0175] From a network perspective, both bearer types still exist because PDCP for split bearers can reside in either the primary node (MN) or the secondary node (SN), and network specifications support both options. The PDCP configuration for split bearers can be carried in a separate container. In such an arrangement, the MN Radio Resource Control (RRC) message will have two containers: one for the secondary node (SN) configuration excluding the PDCP configuration used for any split bearer, and the other carrying the PDCP configuration for the split bearer, regardless of whether the PDCP is located in the primary node (MN) or the secondary node (SN) on the network side.

[0176] From the perspective of UE 122, PDCP can be modeled as an independent entity not belonging to the MN stack or SN stack. The received PDCP configuration can configure the PDCP layer, which can be executed within UE 122 by an MCG RRC entity or an SCG RRC entity as a separate container. Such RRC modeling, where the PDCP configuration is not directly associated with MN RRC messages or SN RRC messages, conforms to the user plane modeling of a "neutral" PDCP entity.

[0177] From a network perspective, the PDCP configuration carried in a separate container can come from a node that has a PDCP entity. If there is an MCG split bearer, the PDCP configuration container can be provided by the MN, while if there is an SCG split bearer, the PDCP configuration can be provided by the SN. In this approach, the PDCP configuration of the SN remains transparent to the MN.

[0178] In one or more implementations, the security key for a unified split bearer cannot be automatically associated with the MN key or SN key based on the bearer type. Instead, the security key can be configured separately as part of the PDCP configuration. For example, the security key can be a key specifically assigned to each split bearer, independent of the MN key or SN key.

[0179] For certain bearer type changes (except for MCG-to-MCG splits), the bearer type change may be accompanied by an SCG change. UE122 also performs the following actions for SCG changes: For PDCP entities, if the bearer type change is between MCG and SCG, PDCP is re-established. In the case of an MCG-to-MCG split, PDCP recovery can be performed, involving PDCP retransmission. For RLC entities, an MCG RLC entity can be re-established for MCG-to-SCG, and an SCG RLC entity can be re-established for both SCG-to-MCG and MCG-to-MCG splits. An SCG MAC reset can be applied.

[0180] The above SCG change procedure can also be performed for auxiliary node (SN) changes due to UE mobility. The above procedure is summarized in Table 3 below.

[0181]

[0182]

[0183] Table 3: Bearer Type Change Process

[0184] As shown in Table 3 above, for a bearer type change from an SCG split bearer to an SCG bearer or a SN change for an SCG split bearer, the change also affects the LTE (MCG) RLC entity associated with the SCG split bearer. In this case, during an SCG split bearer to SCG bearer change or when the PDCP entity is re-established, such as during a secondary node (SN) change for an SCG split bearer, during a bearer type change between an MCG and an SCG bearer, etc., the LTE (MCG) RLC entity must be re-established to deliver the buffered RLC Service Data Units (SDUs) to the PDCP before the LTE (MCG) RLC entity is released.

[0185] The following factors may also be considered for changes in bearer type and SN in Evolved Universal Terrestrial Radio Access (E-UTRA) New Radio (NR) Dual Connectivity (DC) (EN-DC).

[0186] Changes from / to LTE RLC entities to / from NR RLC entities can occur due to bearer type changes between MCG and SCG bearers. LTE RLC has a reordering function, thus buffering out-of-order RLC SDUs, while NR RLC immediately delivers all RLC SDUs to the PDCP without reordering or buffering. Therefore, if the change is from an LTE RLC entity to an NR RLC entity, such as from MCG to SCG, a re-establishment needs to be performed on the LTE RLC entity to ensure that any RLC SDUs stored in the reordering queue can be pushed to the PDCP layer. The LTE RLC can then be released and the NR RLC entity established. If the change is from an NR RLC entity to an LTE RLC entity, the NR RLC entity can be released without a re-establishment, and the LTE RLC entity can be established. Reconfiguration of the LTE RLC entity to / from the NR RLC entity is not required. Instead, the RLC entity can be released and established between MCG and SCG bearer type changes.

[0187] In NR, there is no RLC reordering, therefore RLC re-establishment is not required when an NR RLC entity is to be released. This applies to SCG and SCG / MCG splits into MCG bearer type changes. In these bearer type changes, SCG RLC entity re-establishment is not required before RLC release because buffering or no reordering functionality exists in NR RLC. Based on the above, for bearer type changes that do not involve mobility processes, such as SN changes, SCG RLC entities do not need to be re-established.

[0188] MAC processing during bearer type change

[0189] In LTE, an SCG MAC reset is performed for sequence number (SN) changes due to UE mobility. Bearer type changes use the SN change procedure to simplify the PDCP and RLC re-establishment process. In addition to the SCG MAC reset for SN changes, an SCG MAC reset can also be performed for bearer type changes between MCG split bearers and SCG split bearers, where the PDCP position is changed. The reason for the reset is to clear MAC PDUs configured using the old security key.

[0190] Furthermore, in NR, if PDCP is re-established with a security key change, for example due to a change in the SN due to UE mobility and a change in the bearer type between the MCG split bearer and the SCG split bearer, then the MCG MAC also needs to be reset for the SCG split bearer. Resetting both the MCG and SCG MACs affects not only the bearer of interest with key changes (e.g., due to SN changes), but also other bearers and SRBs unaffected by the key changes.

[0191] If the soft buffer and HARQ buffer of the MAC PDU using the old security key are not cleared, the MAC will attempt to deliver to the new RLC and PDCP entities. To avoid the SCG / MCG MAC resetting and clearing the buffers, the following methods can be implemented.

[0192] 1. Assign a new LC-ID to the DRB associated with the PDCP re-establishment. The MAC will discard MAC PDUs with the old (now unknown) LC-ID.

[0193] 2. The PDCP header of the PDCP PDU includes an index indicating whether the PDCP PDU was encrypted or protected with a previous or new key, or for integrity purposes. The PDCP entity discards the PDCP PDU with the previous key indication or decrypts it accordingly with the old or new key, based on this indication. A 1-bit switch bit can be used to indicate a key change instead of the index. Upon receiving a PDCP PDU, the PDCP entity will decrypt the PDCP payload according to the key indicated in the PDCP header, or simply discard it.

[0194] 3. Allow MAC PDUs with PDCP-level integrity protection using old security keys to be sent to PDCP, leaving them for PDCP to discard if integrity protection fails.

[0195] Method 1 above can be used if the RLC entity associated with the DRB is reset / re-established, and it can also be used if the associated RLC entity is not re-established. When the RLC is reset / re-established, all state variables will be reset and the RLC SN will be initialized. MAC PDUs associated with RLC PDUs that have a previous RLC SN can be discarded. One issue may be that there are not enough LCIDs for the UL / DL logical channel on the LTE side. Currently, there are eight LC-IDs associated with the DRB. This will allow for a maximum of four split bearers, which is sufficient.

[0196] If the RLC entity associated with the DRB is not reset / re-established, method 2 above can be used. Since the RLC entity is not re-established, existing state variables and SNs will continue. Then sending a MAC PDU containing the existing RLC SDU will not be a problem for the RLC entity.

[0197] Method 3 above is possible for NR PDCP. If LTE PDCP is used for split bearers, DRB integrity protection is not supported. Furthermore, discarding a PDCP PDU using an integrity check failure may mean deviating from normal integrity check failures and triggering the recovery process.

[0198] Comparing Method 1 and Method 2, Method 1 can be used regardless of whether the RLC entity is re-established. Therefore, a new LC-ID can be assigned during a DRB bearer type change or SN change associated with PDCP re-establishment. The MAC will discard the MAC PDU with the old (unknown) LC-ID.

[0199] It should be noted that the following still applies to Evolved Universal Terrestrial Radio Access (E-UTRA) New Radio Interface (NR) Dual Connectivity (DC) (EN-DC). Whenever the PDCP location changes, such as from MCG (split) to SCG (split) and the SN changes along with the PDCP location, the PDCP should be re-established. When a split path is released, for example, when the SCG branch of an MCG split bearer is released or the MCG branch of an SCG split bearer is released, the PDCP entity performs PDCP recovery.

[0200] In one or more implementations, the following L2 processing may be applied to EN-DC. Whenever the PDCP location changes, such as from MCG (split) to SCG (split) and the SN changes along with the PDCP location, the PDCP should be re-established. When a split path is released, for example, when the SCG branch carried by the MCG split is released or the MCG branch carried by the SCG split is released, the PDCP entity performs PDCP recovery.

[0201] Further considerations for EN-DC

[0202] For changes in bearer type and SN in EN DC, the following factors may be considered.

[0203] 1. Changes from / to the LTE PDCP entity to the NR PDCP entity

[0204] 2. For unified bearers (SCG (split) bearers and MCG split bearers are considered split bearers), UE 122 may not be able to identify whether a re-establishment needs to be performed, such as for MCG to split, whether it is MCG to MCG split or MCG to SCG split, etc.

[0205] 3. Changes to the SN for UE mobility may not lead to changes in PDCP, therefore no security configuration changes are required.

[0206] Factor 1 mentioned above can occur in multiple scenarios.

[0207] a) HO between traditional LTE and EN-DC / NR: Lossless HO is expected for HO within the EPC. This also involves key changes and can be supported by a combination of PDCP reconfiguration between LTE and NR PDCP and re-establishment with SN continuity.

[0208] b) Change of DRB bearer type from MCG bearer to split or SCG bearer: This can be achieved through...

[0209] DRBs were initially not set to NR PDCP DRBs in the cell to avoid this.

[0210] c) SRB1 can always be set to LTE PDCP during connection establishment because the UE's capabilities are only known to the network after SRB1 is established. Subsequent reconfiguration to a split SRB using NR PDCP may involve a change from LTE PDCP to NR PDCP. This is not necessary if LTE PDCP is used for the split SRB. If required, such a change can be addressed using an intra-cell HO if it is needed in the cell with which UE 122 established the connection.

[0211] Regarding Factor 2 above, in the case of a unified bearer, UE 122 only sees the split bearer type. UE 122 is unaware of any changes from MCG splitting to SCG splitting, and therefore, if there is a PDCP change, it does not know whether PDCP needs to be re-established. Explicit indications can be provided to indicate whether PDCP re-establishment should be performed. Such indications can also be provided for Factor 3 above for SN changes accompanying UE mobility.

[0212] For unified bearers, UE 122 is unaware of any PDCP changes on the network side, or whether PDCP re-establishment should be performed, such as for MCG splitting to SCG splitting, or SN changes following PDCP changes. Furthermore, for unified bearers, UE 122 only performs PDCP re-establishment when explicitly instructed, especially for reconfigurations from split bearer to split bearer or for SN changes following PDCP location changes.

[0213] See now Figure 6 and Figure 7 This paper will discuss schematic diagrams of the Radio Resource Control (RRC) reconfiguration process according to one or more implementation schemes, illustrating the reconfiguration completion process and the RRC connection re-establishment process, respectively. The RRC reconfiguration success process 600 is described in... Figure 6 As shown, the network or EUTRAN 410 sends an RRCReconfiguration message 612 to UE 122, and if successful, UE 122 sends an RRCReconfiguration message 614 to EUTRAN 410. The RRC reconfiguration failure procedure 700 is in... Figure 7As shown, the network or EUTRAN 410 sends an RRCReconfiguration message 712 to UE 122. In the event of RRC reconfiguration failure, UE 122 and EUTRAN participate in the RRC connection re-establishment process 714. Figure 6 and Figure 7 The purpose of the procedures shown is to modify RRC connections, such as to establish, modify, or release RBs, to perform synchronized reconfigurations, to set, modify, or release measurements, and / or to add, modify, or release SCells and cell groups. As part of these procedures, NAS-specific information can be transmitted from the network or EUTRAN 410 to UE122. In EN-DC, Signaling Radio Bearer 3 (SRB3) can be used to configure measurements, MAC, RLC, PDCP, physical layer, and RLF timers and constants.

[0214] In one or more implementations, RRCReconflguration message 612 and / or RRCReconflguration message 712 may include an Information Element (IE) RadioBearerConfig. The IERadioBearerConfig is used to add, modify, and release signaling and / or data radio bearers. Specifically, this IERadioBearerConfig carries parameters for the Packet Data Convergence Protocol (PDCP) entity used for the radio bearer, and, if applicable, parameters for the Service Data Adaptation Protocol (SDAP) entity.

[0215] The behavior of UE 122 when receiving the RRCReconflguration message can be as follows, as described in section 5.3.5.4 of 3GPP TS 38.331.

[0216] 5.3.5.3 UE reception of RRCReconflguration

[0217] The UE should perform the following actions when receiving RRCReconflguration:

[0218] If RRCReconflguration includes secondaryCellGroup:

[0219] 2> Configure the cell group for SCG according to section 5.3.5.5;

[0220] If the RRCReconfiguration message contains radioBearerConfig:

[0221] 2> Perform wireless bearer configuration according to 5.3.5.6;

[0222] If the RRCReconfiguration message includes measConfig:

[0223] 2> Execute the measurement configuration procedure specified in 5.5.2;

[0224] 1> If the UE is configured with E-UTRAnr-SecondaryCellGroupConflg (MCG is E-UTRA):

[0225] 2> If RRCReconflguration is received via SRB1:

[0226] 3> Construct the RRCReconfigurationComplete message and transmit it via the embedded E-

[0227] UTRA RRC message RRCConnectionReconfigurationComplete

[0228] The EUTRA MCG shall submit it as specified in TS 36.331

[10] ;

[0229] 3> If reconfigurationWithSync is included in SCG's spCellConfig:

[0230] 4> Initiate a random access procedure on SpCell as specified in TS 38.321[3];

[0231] 2> Otherwise (RRCReconflguration is received via SRB3):

[0232] 3> Submit the RRCReconfigurationComplete message to a lower layer via SRB3 for transmission with the new configuration;

[0233] Note: For SRB1, random access is triggered by the RRC layer itself, as there is not necessarily any other UL transmission. In the case of SRB3, random access is triggered by the MAC layer due to the arrival of RRCReconfigurationComplete.

[0234] The behavior of UE 122 when receiving RadioBearerConfig IE based on the received data can be as described in 3GPP TS38.331.

[0235] 5.3.5.6 Wireless Bearer Configuration

[0236] 5.3.5.6.1 Overview

[0237] The UE should perform the following actions based on the received RadioBearerConfig IE:

[0238] If RadioBearerConfig includes srb3-ToRelease and is set to true:

[0239] 2> Perform the SRB release specified in 5.3.5.6.2;

[0240] If RadioBearerConfig includes srb-ToAddModList:

[0241] 2> Perform the SRB addition or reconfiguration specified in 5.3.5.6.3;

[0242] If RadioBearerConfig includes drb-ToReleaseList:

[0243] 2> Perform the DRB release specified in 5.3.5.6.4;

[0244] If RadioBearerConfig includes drb-ToAddModList:

[0245] 2> Perform the DRB addition or reconfiguration specified in 5.3.5.6.5.

[0246] 5.3.5.6.5DRB Additions / Modifications

[0247] UE should:

[0248] For each drb-Identity value included in drb-ToAddModList that is not part of the current UE configuration (DRB establishment includes this when the full configuration option is used):

[0249] 2> Establish a PDCP entity and configure it according to the received pdcp-Config;

[0250] 2> Configure the PDCP entity according to the security algorithm in securityConfig and apply the K indicated in keyToUse. eNB / SK gNB Associated key (K) UPenc );

[0251] 2> If the DRB was configured with the same eps-BearerIdentity by NR or E-UTRA before receiving this reconfiguration:

[0252] 3> Associate the established DRB with the corresponding eps-Bearerldentity;

[0253] 2> Otherwise:

[0254] 3> Instruct the upper layer to establish the DRB and the EPS of the established DRB-

[0255] Bearer identity;

[0256] 1> For each drb-Identity value included in drb-ToAddModList as part of the current UE configuration:

[0257] 2> If reestablishPDCP is set:

[0258] 3> Configure the PDCP entity of this RadioBearerConfig to apply the encryption algorithm and the K key associated with KeNB / S-KgNB as indicated in keyToUse. UPenc The key, i.e., the encryption configuration, should be applied to all subsequent PDCP PDUs received and transmitted by the UE;

[0259] 3> Re-establish the PDCP entity of this DRB, as in section 38.323[5].

[0260] As indicated in 5.1.2;

[0261] 2> Otherwise, if recoverPDCP is set:

[0262] 3> Trigger the PDCP entity of this DRB to perform the data recovery specified in 38.323;

[0263] 2> If pdcp-Conflg is included:

[0264] 3> Reconfigure the PDCP entity based on the received pdcp-Conflg.

[0265] Note 1: Removing and adding the same drb-Identity within a single radioResourceConfig is not supported.

[0266] Add. If drb-Identity is removed and added due to reconfiguration for synchronization or re-establishment with a full configuration option, the network can use the same value of drb-Identity.

[0267] Identity.

[0268] Note 2: When determining whether the drb-Identity value is part of the current UE configuration, the UE does not distinguish...

[0269] The DRB is initially configured in which RadioBearerConfig and DRB-

[0270] In ToAddModList. To re-associate the DRB with another key (KeNB to S-KeNB or vice versa), the network provides the drb-Identity value in the (target) drb-ToAddModList and sets the reestablishPDCP flag. The network is not in the (source)

[0271] The drb-ToReleaseList lists drb-Identity.

[0272] Note 3: When the reestablishPDCP flag is set for the radio bearer, the network ensures RLC reception.

[0273] The device entity does not deliver old PDCP PDUs to the re-established PDCP entity. This is done, for example, by triggering a synchronized reconfiguration of the cell group hosting the old RLC entity, or...

[0274] This is achieved by releasing the old RLC entity.

[0275] Note 4: In this specification, unless otherwise specified, UE configuration refers to configuration by the NR RRC.

[0276] The parameters are set.

[0277] 5.3.5.7 Security Key Update

[0278] When receiving the sk-Counter specified in TS 36.331

[10] , the UE should:

[0279] 1> Based on K eNB The key is then used to update the SK using the received sk-Counter value. gNB The key, as specified in TS 33.501

[11] ;

[0280] l>Derivation of K RRCenc and K UPenc The key, as specified in TS 33.501

[11] ;

[0281] l>Derivation of K RRCint and K UPint The key is specified as in TS 33.501

[11] .

[0282] Explicit signaling for PDCP re-establishment and recovery can be performed as highlighted below in the Radio Resource Control (RRC) Signaling NR PDCP Configuration section of 3GPP TS 38.331 under RadioBearerConfig. The explicit signaling regarding the key to be used is also highlighted below.

[0283] -RadioBearerConfig

[0284] The RadioBearerConfig (IE) is used to add, modify, and release signaling and / or data radio bearers. Specifically, the IE carries parameters for PDCP and, where applicable, SDAP entities for the radio bearers.

[0285] RadioBearerConfig information element

[0286]

[0287]

[0288]

[0289] Figure 8 The architecture of a network system 800 according to some embodiments is shown. System 800 is shown to include user equipment (UE) 801 and UE 802. UE 801 and 802 are shown as smartphones (e.g., handheld touchscreen mobile computing devices that can connect to one or more cellular networks), but it may also include any mobile or non-mobile computing device, such as a personal data assistant (PDA), pager, laptop computer, desktop computer, wireless handheld terminal, or any computing device that includes a wireless communication interface.

[0290] In some implementations, either UE 801 or 802 may include an Internet of Things (IoT) UE, which may include a network access layer designed to utilize low-power IoT applications with short-lived UE connectivity. The IoT UE may exchange data with an MTC server or device via technologies such as machine-to-machine (M2M) or machine-type communication (MTC), through a Public Land Mobile Network (PLMN), Proximity-Based Service (ProSe) or Device-to-Device (D2D) communication, sensor networks, or an IoT network. M2M or MTC data exchange may be machine-initiated. The IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-lived connectivity. The IoT UE may execute background applications (e.g., keeping track of activity messages, status updates, etc.) to facilitate connectivity within the IoT network.

[0291] UEs 801 and 802 can be configured to connect to a radio access network (RAN) 810, for example, in a communicative manner—RAN 810 can be, for example, an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), a Next Generation RAN (NG RAN), or some other type of RAN. UEs 801 and 802 utilize connections 803 and 804, respectively, each connection including a physical communication interface or layer (discussed in further detail below); in this example, connections 803 and 804 are shown as air interfaces for communicative coupling and can conform to cellular communication protocols such as the Global System for Mobile Communications (GSM) protocol, Code Division Multiple Access (CDMA) network protocol, Push-to-Talk (PTT) protocol, Cellular PTT (POC) protocol, Universal Mobile Telecommunications System (UMTS) protocol, 3GPP Long Term Evolution (LTE) protocol, 5G protocol, New Radio (NR) protocol, etc.

[0292] In this implementation, UEs 801 and 802 can also exchange communication data directly via the ProSe interface 805. The ProSe interface 805 may alternatively be referred to as a sidelink interface including one or more logical channels, including but not limited to the Physical Sidelink Control Channel (PSCCH), Physical Sidelink Shared Channel (PSSCH), Physical Sidelink Discovery Channel (PSDCH), and Physical Sidelink Broadcast Channel (PSBCH).

[0293] The diagram shows UE 802 configured to access access point (AP) 806 via connection 807. Connection 807 may include local wireless connectivity, such as a connection compliant with any IEEE 802.11 protocol, where AP 806 will include Wireless Fidelity. Router. In this example, AP 806 is shown connected to the Internet but not to the core network of the wireless system (described in further detail below).

[0294] RAN 810 may include one or more access nodes that enable connectivity between 803 and 804. These access nodes (ANs) may be referred to as base stations (BS), node Bs, evolved Node Bs (eNBs), next-generation Node Bs (gNBs), RAN nodes, etc., and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). RAN 810 may include one or more RAN nodes for providing macrocells, such as macro RAN node 811, and one or more RAN nodes for providing femtocells or picocells (e.g., cells with smaller coverage, smaller user capacity, or higher bandwidth compared to macrocells), such as low-power (LP) RAN node 812.

[0295] Either RAN node 811 or RAN node 812 can terminate the air interface protocol and can be the first point of contact for UE 801 and UE 802. In some implementations, either RAN node 811 or 812 can fulfill various logical functions of RAN 810, including but not limited to Radio Network Controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management, data packet scheduling, and mobility management.

[0296] According to some implementations, UEs 801 and 802 can be configured to communicate with each other or with either RAN nodes 811 and 812 on a multi-carrier communication channel using orthogonal frequency division multiplexing (OFDM) communication signals, based on various communication technologies, such as, but not limited to, orthogonal frequency division multiple access (OFDMA) communication technology (e.g., for downlink communication) or single-carrier frequency division multiple access (SC-FDMA) communication technology (e.g., for uplink and ProSe or sidelink communication), but the scope of the implementation is not limited in this respect. OFDM signals may include multiple orthogonal subcarriers.

[0297] In some implementations, the downlink resource grid can be used for downlink transmissions from either RAN nodes 811 and 812 to UEs 801 and 802, while uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid, referred to as a resource grid or time-frequency resource grid, which represents the physical resources in the downlink within each time slot. This time-frequency plane representation is common practice for OFDM systems, making radio resource allocation intuitive. Each column and row of the resource grid corresponds to an OFDM symbol and an OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to a time slot in a radio frame. The smallest time-frequency unit in the resource grid is represented as a resource element. Each resource grid comprises multiple resource blocks that describe the mapping of certain physical channels to resource elements. Each resource block comprises a set of resource elements. In the frequency domain, this can represent the minimum amount of resources currently available for allocation. Such resource blocks are used to transmit several different physical downlink channels.

[0298] The Physical Downlink Shared Channel (PDSCH) carries user data and higher-layer signaling to UEs 801 and 802. The Physical Downlink Control Channel (PDCCH) carries information about the transmission format and resource allocation related to the PDSCH channel. It can also inform UEs 801 and 802 about the transmission format, resource allocation, and H-ARQ (Hybrid Automatic Repeat Request) information related to the uplink shared channel. Typically, downlink scheduling (allocating control and shared channel resource blocks to UE 102 within the cell) can be performed on either RAN nodes 811 or 812 based on channel quality information fed back from either UE 801 or 802. Downlink resource allocation information can be transmitted on the PDCCH used (e.g., allocated to) each of UEs 801 and 802.

[0299] PDCCH can use Control Channel Elements (CCEs) to transmit control information. Before being mapped to resource elements, the complex-valued symbols of the PDCCH can first be organized into quadruplets, which can then be arranged using a sub-block interleaver for rate matching. One or more of these CCEs can be used to transmit each PDCCH, where each CCE can correspond to a set of four physical resource elements (REGs) of nine. Four Quadrature Phase Shift Keying (QPSK) symbols can be mapped to each REG. Depending on the size of the Downlink Control Information (DCI) and channel conditions, one or more CCEs can be used to transmit the PDCCH. In LTE, four or more different PDCCH formats with different numbers of CCEs (e.g., aggregation levels, L = 1, 2, 4, or 8) can exist.

[0300] Some implementations can use the concept of resource allocation for control channel information, which is an extension of the above concept. For example, some implementations can utilize an enhanced physical downlink control channel (EPDCCH) that uses PDSCH resources for control information transmission. EPDCCH can be transmitted using one or more enhanced control channel elements (ECCEs). Similarly, each ECCE can correspond to a set of nine physical resource elements, called an enhanced resource element group (EREG). In some cases, an ECCE can have a different number of EREGs.

[0301] RAN 810 is shown communicatively coupled to core network (CN) 820 via SI interface 813. In various embodiments, CN 820 may be an evolved packet core (EPC) network, a next-generation packet core (NPC) network, or some other type of CN. In this embodiment, SI interface 813 is divided into two parts: S1-U interface 814, which carries traffic data between RAN nodes 811 and 812 and serving gateway (S-GW) 822; and SI-Mobility Management Entity (MME) interface 815, which is the signaling interface between RAN nodes 811 and 812 and MME 821.

[0302] In this implementation, CN 820 includes an MME 821, an S-GW 822, a Packet Data Network (PDN) Gateway (P-GW) 823, and a Home Subscriber Server (HSS) 824. The MME 821 can functionally resemble the control plane of a legacy General Packet Radio Service (GPRS) Support Node (SGSN). The MME 821 can manage mobility aspects of access, such as gateway selection and tracking area list management. The HSS 824 may include a database for network users, including subscription-related information to support network entities in handling communication sessions. Depending on the number of mobile subscribers, equipment capacity, network organization, etc., CN820 may include one or more HSS 824s. For example, the HSS 824 can provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependencies, etc.

[0303] The S-GW 822 can terminate the SI interface 813 toward RAN 810 and route data packets between RAN 810 and CN 820. Additionally, the S-GW 822 can serve as a local mobility anchor for inter-RAN node handover and can also provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful interception, billing, and enforcement of certain policies.

[0304] P-GW 823 can terminate the SGi interface toward the PDN. P-GW 823 can route data packets between EPC network 823 and external networks, such as networks including application server 830 (alternatively referred to as Application Function (AF)), via Internet Protocol (IP) interface 825. Generally, application server 830 can be an element providing IP-bearing resources for use with the core network (e.g., UMTS Packet Service (PS) domain, LTE PS data service, etc.). In this embodiment, P-GW 823 is shown communicatively coupled to application server 830 via IP communication interface 825. Application server 830 can also be configured to support one or more communication services (e.g., Voice over Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for UEs 801 and 802 via CN 820.

[0305] The P-GW 823 can also be a node for policy enforcement and charging data collection. The Policy and Charging Enforcement Function (PCRF) 826 is the policy and charging control element of the CN 820. In non-roaming scenarios, a single PCRF may exist in the domestic public land mobile network (HPLMN) associated with the UE's Internet Protocol Connectivity Access Network (IP-CAN) session. In roaming scenarios with local traffic breaches, two PCRFs may exist associated with the UE's IP-CAN session: a domestic PCRF (H-PCRF) in the HPLMN and a visited PCRF (V-PCRF) in the visited public land mobile network (VPLMN). The PCRF 826 can be communicatively coupled to the application server 830 via the P-GW 823. The application server 830 can signal the PCRF 826 to indicate new service flows and select appropriate Quality of Service (QoS) and charging parameters. PCRF 826 can provide this rule to the Policy and Charging Enforcement Function (PCEF) (not shown), as specified by the application server 830, using an appropriate Service Flow Template (TFT) and QoS Class (QCI) identifier, to initiate QoS and charging.

[0306] Figure 9Example components of a device 900 according to some embodiments are shown. In some embodiments, device 900 may include application circuitry 902, baseband circuitry 904, radio frequency (RF) circuitry 906, front-end module (FEM) circuitry 908, one or more antennas 910, and power management circuitry (PMC) 912 (at least coupled together as shown). Components of the illustrated device 900 may be included in a UE or RAN node. In some embodiments, device 900 may include fewer elements (e.g., the RAN node may not utilize application circuitry 902, but instead include a processor / controller to process IP data received from the EPC). In some embodiments, device 900 may include additional elements, such as memory / storage devices, displays, cameras, sensors, or input / output (I / O) interfaces. In other embodiments, the components described below may be included in more than one device (e.g., the circuitry may be individually included in more than one device for a cloud-RAN (C-RAN) specific implementation).

[0307] Application circuitry 902 may include one or more application processors. For example, application circuitry 902 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, etc.). The processor may be coupled to or may include a memory / storage device and may be configured to execute instructions stored in the memory / storage device to enable various applications or operating systems to run on device 900. In some embodiments, the processor of application circuitry 902 may process IP data packets received from the EPC.

[0308] Baseband circuitry 904 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. Baseband circuitry 904 may include one or more baseband processors or control logic components to process baseband signals received from the receive signal path of RF circuitry 906 and to generate baseband signals for the transmit signal path of RF circuitry 906. Baseband circuitry 904 may interact with application circuitry 902 to generate and process baseband signals and control the operation of RF circuitry 906. For example, in some embodiments, baseband circuitry 904 may include a third-generation (3G) baseband processor (BB), namely 3G BB 904A, a fourth-generation (4G) BB, namely 4GBB 904B, a fifth-generation (5G) BB, namely 5G BB 904C, or other existing, under development, or future generations (e.g., second-generation (2G), sixth-generation (6G), etc.) BB 904D. Baseband circuitry 904 (e.g., one or more of the baseband processors designated 904A-D) can handle various radio control functions that enable communication with one or more radio networks via RF circuitry 906. In other embodiments, some or all of the functions of the baseband processors designated 904A-D may be included in modules stored in memory 904G and executed via central processing unit (CPU) 904E. Radio control functions may include, but are not limited to, signal modulation / demodulation, encoding / decoding, RF shifting, etc. In some embodiments, the modulation / demodulation circuitry of baseband circuitry 904 may include Fast Fourier Transform (FFT), precoding, or constellation mapping / demapping functions. In some embodiments, the encoding / decoding circuitry of baseband circuitry 904 may include convolution, tail-biting convolution, turbo, Viterbi, or low-density parity-check (LDPC) encoder / decoder functions. Implementations of modulation / demodulation and encoder / decoder functions are not limited to these examples, and other suitable functions may be included in other embodiments.

[0309] In some embodiments, the baseband circuitry 904 may include one or more audio digital signal processors (DSPs) 904F. The audio DSP 904F may include elements for compression / decompression and echo cancellation, and in other embodiments may include other suitable processing elements. In some embodiments, components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on the same circuit board. In some embodiments, some or all components of the baseband circuitry 904 and the application circuitry 902 may be implemented together, such as (e.g.) on a system-on-a-chip (SoC).

[0310] In some implementations, baseband circuit 904 can provide communication compatible with one or more radio technologies. For example, in some implementations, baseband circuit 904 can support communication with the Evolved Universal Terrestrial Radio Access Network (EUTRAN) or other Wireless Metropolitan Area Networks (WMAN), Wireless Local Area Networks (WLAN), or Wireless Personal Area Networks (WPAN). Implementations in which baseband circuit 904 is configured to support radio communication using more than one radio protocol can be referred to as multi-mode baseband circuits.

[0311] RF circuit 906 enables communication with a wireless network via a non-solid medium using modulated electromagnetic radiation. In various embodiments, RF circuit 906 may include switches, filters, amplifiers, etc., to facilitate communication with the wireless network. RF circuit 906 may include a receive signal path, which may include circuitry for down-converting the RF signal received from FEM circuit 908 and providing a baseband signal to baseband circuit 904. RF circuit 906 may also include a transmit signal path, which may include circuitry for up-converting the baseband signal provided by baseband circuit 904 and providing an RF output signal for transmission to FEM circuit 908.

[0312] In some embodiments, the receive signal path of RF circuit 906 may include mixer circuit 906A, amplifier circuit 906B, and filter circuit 906C. In some embodiments, the transmit signal path of RF circuit 906 may include filter circuit 906C and mixer circuit 906A. RF circuit 906 may also include synthesizer circuit 906D for synthesizing the frequency used by mixer circuit 906A in both the receive and transmit signal paths. In some embodiments, mixer circuit 906A in the receive signal path may be configured to down-convert the RF signal received from FEM circuit 908 based on the synthesized frequency provided by synthesizer circuit 906D. Amplifier circuit 906B may be configured to amplify the down-converted signal, and filter circuit 906C may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signal to generate an output baseband signal. The output baseband signal may be provided to baseband circuit 904 for further processing. In some implementations, although not required, the output baseband signal may be a zero-frequency baseband signal. In some implementations, the mixer circuit 906A in the receiving signal path may include a passive mixer, but the scope of the implementations is not limited in this respect.

[0313] In some implementations, the mixer circuit 906A of the transmission signal path can be configured to up-convert the input baseband signal based on the synthesized frequency provided by the synthesizer circuit 906D to generate an RF output signal for the FEM circuit 908. The baseband signal can be provided by the baseband circuit 904 and can be filtered by the filter circuit 906C.

[0314] In some embodiments, the mixer circuit 906A for the receive signal path and the mixer circuit 906A for the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuit 906A for the receive signal path and the mixer circuit 906A for the transmit signal path may include two or more mixers and may be arranged for image suppression (e.g., Hartley image suppression). In some embodiments, the mixer circuit 906A for the receive signal path and the mixer circuit 906A for the transmit signal path may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuit 906A for the receive signal path and the mixer circuit 906A for the transmit signal path may be configured for superheterodyne operation.

[0315] In some embodiments, the output baseband signal and the input baseband signal may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternative embodiments, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative embodiments, RF circuitry 906 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry, and baseband circuitry 904 may include a digital baseband interface for communicating with RF circuitry 906. In some dual-mode embodiments, separate radio IC circuitry may be provided to process the signal for each spectrum, but the scope of the embodiments is not limited in this respect.

[0316] In some implementations, the synthesizer circuit 906D may be a fractional N synthesizer or a fractional N / N+1 synthesizer, but the scope of implementations is not limited in this respect, as other types of frequency synthesizers may also be suitable. For example, the synthesizer circuit 906D may be a Δ-Σ synthesizer, a frequency multiplier, or a synthesizer that includes a phase-locked loop with a frequency divider.

[0317] Synthesizer circuit 906D can be configured to synthesize an output frequency based on the frequency input and the divider control input for use by mixer circuit 906A of RF circuit 906. In some implementations, synthesizer circuit 906D may be a fractional N / N+1 synthesizer.

[0318] In some implementations, the frequency input may be provided by a voltage-controlled oscillator (VCO), but this is not mandatory. The divider control input may be provided by the baseband circuitry 904 or the application circuitry 902 according to the desired output frequency. In some implementations, the divider control input (e.g., N) may be determined from a lookup table based on the channel indicated by the application circuitry 902.

[0319] The synthesizer circuit 906D of the RF circuit 906 may include a frequency divider, a delay-locked loop (DLL), a multiplexer, and a phase accumulator. In some embodiments, the frequency divider may be a dual-mode divider (DMD), and the phase accumulator may be a digital phase accumulator (DP A). In some embodiments, the DMD may be configured to divide the input signal by N or N+1 (e.g., based on carry) to provide a fractional division ratio. In some example embodiments, the DLL may include cascaded, tunable delay elements, a phase detector, a charge pump, and a set of D-type flip-flops. In these embodiments, the delay elements may be configured to divide the VCO cycle into Nd equal phase groups, where Nd is the number of delay elements in the delay line. Thus, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

[0320] In some embodiments, the synthesizer circuit 906D may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and frequency divider circuitry to generate multiple signals having multiple different phases relative to each other at the carrier frequency. In some embodiments, the output frequency may be the LO frequency (fLO). In some embodiments, the RF circuit 906 may include an IQ / polarity converter.

[0321] FEM circuit 908 may include a receive signal path, which may include circuitry configured to operate on RF signals received from one or more antennas 910, amplify the received signals, and provide an amplified version of the received signals to RF circuit 906 for further processing. FEM circuit 908 may also include a transmit signal path, which may include circuitry configured to amplify signals provided by RF circuit 906 for transmission by one or more of the one or more antennas 910. In various embodiments, amplification via the transmit or receive signal path may be performed only in RF circuit 906, only in FEM circuit 908, or in both RF circuit 906 and FEM circuit 908.

[0322] In some embodiments, FEM circuit 908 may include a TX / RX switch to switch between transmit and receive mode operation. The FEM circuit may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuit may include an LNA to amplify the received RF signal and provide the amplified received RF signal as an output (e.g., provided to RF circuit 906). The transmit signal path of FEM circuit 908 may include a power amplifier (PA) for amplifying the input RF signal (e.g., provided by RF circuit 906); and one or more filters for generating RF signals for subsequent transmission (e.g., through one or more of the one or more antennas 910).

[0323] In some implementations, the PMC 912 can manage the power supplied to the baseband circuitry 904. Specifically, the PMC 912 can control power selection, voltage scaling, battery charging, or DC-DC conversion. The PMC 912 is typically included when the device 900 can be battery powered, for example, when the device is included in a UE. The PMC 912 can improve power conversion efficiency while providing the desired implementation size and thermal characteristics.

[0324] Although Figure 9 The PMC 912 is shown coupled only to the baseband circuit 904. However, in other embodiments, the PMC 912 may additionally or alternatively be coupled to other components (such as, but not limited to, the application circuit 902, the RF circuit 906, or the FEM circuit 908) and perform similar power management operations therefor.

[0325] In some implementations, the PMC 912 can be controlled or otherwise integrated into various power-saving mechanisms of the device 900. For example, if the device 900 is in the RRC_Connected state, where it remains connected to the RAN node because it anticipates receiving traffic soon, it can enter a state known as Discontinuous Receive Mode (DRX) after a period of inactivity. During this state, the device 900 can be powered down for short intervals, thereby saving power.

[0326] If there is no data traffic activity during the extended period, device 900 can transition to an RRC idle state, in which the device disconnects from the network and does not perform operations such as channel quality feedback or handover. Device 900 enters a very low-power state and performs paging, in which the device periodically wakes up again to listen to the network, and then powers off again. Device 900 cannot receive data in this state; to receive data, it must transition back to the RRC connected state.

[0327] An additional power-saving mode allows the device to be unavailable from the network for periods exceeding the paging interval (ranging from seconds to hours). During this time, the device is completely unconnected to the network and can be completely powered off. Any data sent during this period will incur significant latency, which is assumed to be acceptable.

[0328] The processors of application circuitry 902 and baseband circuitry 904 are elements that can be used to execute one or more instances of the protocol stack. For example, the processor of baseband circuitry 904 can be used alone or in combination to execute layer 3, layer 2, or layer 1 functions, while the processor of application circuitry 902 can utilize data received from these layers (e.g., packet data) and further execute layer 4 functions (e.g., Transport Communication Protocol (TCP) and User Datagram Protocol (UDP) layers). As mentioned herein, layer 3 may include the Radio Resource Control (RRC) layer, which will be described in further detail below. As mentioned herein, layer 2 may include the Media Access Control (MAC) layer, Radio Link Control (RLC) layer, and Packet Data Convergence Protocol (PDCP) layer, which will be described in further detail below. As mentioned herein, layer 1 may include the physical (PHY) layer of the UE / RAN node, which will be described in further detail below.

[0329] Figure 10 An example interface of the baseband circuit according to some implementation schemes is shown. As discussed above, Figure 9 The baseband circuitry 904 may include processors such as 3G BB 904A, 4G BB 904B, 5G BB 904C, other BB 904D, and CPU 904E, and memory 904G utilized by these processors. Each of the processors designated 904A-904E may include memory interfaces 1004A-1004E for sending / receiving data to / from memory 904G, respectively.

[0330] The baseband circuit 904 may further include: one or more interfaces for communicatively coupling to other circuits / devices, such as a memory interface 1012 (e.g., an interface for sending / receiving data to / from a memory external to the baseband circuit 904); and an application programming interface 1014 (e.g., for sending / receiving data to / from a memory external to the baseband circuit 904); Figure 9 Application circuit 902 (interface for sending / receiving data); Radio frequency (RF) interface 1016 (e.g., for sending / receiving data to / from...). Figure 9 The RF circuit 906 is an interface for transmitting / receiving data; the wireless hardware interface 1018 (e.g., for transmitting / receiving data to / from near field communication (NFC) components, Components (e.g.) Low Energy) Interface for sending / receiving data to / from components and other communication components; and power management interface 1020 (e.g., an interface for sending / receiving power or control signals to / from PMC 912).

[0331] The following are exemplary specific implementations of the subject matter described herein. It should be noted that any example and its variations described herein may be used in any permutation or combination of any other example or variation, but in these respects the scope of the subject matter for which protection is sought is not limited.

[0332] In Example 1, an evolved Node B (eNB) or fifth-generation (5G) Node B (gNB) apparatus includes one or more baseband processors for generating a Radio Resource Control (RRC) Connection Reconfiguration message RRCConnectionReconfiguration to include an Information Element (IE) for configuring a User Equipment (UE) to receive data from a Long Term Evolution (LTE) node and a New Radio (NR) node in a unified split bearer configuration, and encoding the data for transmission to the UE via a Primary Cell Group (MCG) bearer, a Secondary Cell Group (SCG) bearer, or a unified split bearer; and a memory for storing the configuration message. Example 2 may include the subject matter of Example 1 or any of the examples described herein, wherein the IE of the RRC Connection Reconfiguration message indicates a bearer type change between the MCG bearer and the unified split bearer, or between the SCG bearer and the unified split bearer. Example 3 may include the subject of Example 1 or any of the examples described herein, wherein one or more baseband processors are configured to perform a lossless reconfiguration of the LTE Packet Data Convergence Protocol (PDCP) entity to an NR PDCP entity, or a lossless reconfiguration of the NR PDCP entity to an LTE PDCP entity, for a change in bearer type. Example 4 may include the subject of Example 1 or any of the examples described herein, wherein the IE of the RRC connection reconfiguration message indicates whether a bearer change with Packet Data Convergence Protocol (PDCP) re-establishment and key change should be performed for an MCG bearer to an SCG split bearer or for an SCG split bearer to an MCG bearer. Example 5 may include the subject of Example 1 or any of the examples described herein, wherein the IE of the RRC connection reconfiguration message indicates whether a bearer change with Packet Data Convergence Protocol (PDCP) data recovery and no key change should be performed for an MCG split bearer to an MCG bearer. Example 6 may include the subject of Example 1 or any of the examples described herein, wherein the IE of the RRC connection reconfiguration message indicates whether a bearer change without key change or Packet Data Convergence Protocol (PDCP) data recovery should be performed for an MCG bearer to an MCG split bearer. Example 7 may include the subject of Example 1 or any of the examples described herein, wherein the IE of the RRC connection reconfiguration message indicates to the UE whether to perform a Media Access Control (MAC) reset on the SCG bearer or MCG bearer or a combination thereof.Example 8 may include the subject matter of Example 1 or any of the examples described herein, wherein the IE of the RRC connection reconfiguration message is configured to configure the one or more baseband processors to assign a previously unused Logical Channel Identifier (LC-ID) to a Data Radio Bearer (DRB) associated with a PDCP re-establishment or bearer type change, wherein the Media Access Control (MAC) entity is configured to discard a MAC Protocol Data Unit (PDU) with an unknown LC-ID without involving an SCG or MCG MAC reset, the unknown LC-ID including the previously unused LC-ID of the DRB. Example 9 may include the subject matter of Example 1 or any of the examples described herein, wherein the IE of the RRC connection reconfiguration message is configured to configure the one or more baseband processors to include a 1-bit switching bit in the PDCP header of a Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDU) to indicate whether the PDCP PDU is encrypted or protected with a previous key or a new key, wherein the PDCP entity, based on the indication, discards the PDCP PDU with the indication of the previous key or decrypts the PDCP PDU with the previous key or the new key. Example 10 may include the subject of Example 1 or any of the examples described herein, wherein instead of the 1-bit switching bit, the PDCP header of the PDCP PDU includes an index indicating the previous key or the new key, wherein the PDCP entity, upon receiving the PDCP PDU, will decrypt the PDCP payload or discard the PDCP payload based on the key indexed in the PDCP header. Example 11 may include the subject of Example 1 or any of the examples described herein, wherein the IE of the RRC connection reconfiguration message is used to configure the one or more baseband processors to allow Media Access Control (MAC) Protocol Data Units (PDUs) with Packet Data Convergence Protocol (PDCP) level integrity protection using the old security key to be sent to the PDCP entity, and to allow the PDCP entity to discard the MAC PDU due to integrity protection failure.

[0333] In Example 12, an apparatus for a fifth-generation (5G) Node B (gNB) includes one or more baseband processors for encoding a reconfiguration message RRCReconfiguration to include Packet Data Convergence Protocol (PDCP) and higher-layer configuration information elements (IEs) for configuring a Data Radio Bearer (DRB) to be coupled to one or more logical channels at or below Radio Link Control; encoding the reconfiguration message RRCReconfiguration to configure changes from a single-connectivity bearer to a multi-connectivity bearer by configuring or releasing one or more of the logical channels; and a memory for storing the configuration. Example 13 may include the subject matter of Example 12 or any of the examples described herein, wherein the reconfiguration message includes an information element (IE) RadioBearerConflg to be transmitted to a User Equipment (UE) to reset or re-establish one or more protocol layers. Example 14 may include the subject matter of Example 12 or any of the examples described herein, wherein the DRB is associated with two or more logical channels of a Radio Access Technology (RAT) implemented by the gNB. Example 15 may include the subject of Example 12 or any of the examples described herein, wherein the RAT conforms to the Long Term Evolution (LTE) standard or the New Radio (NR) standard. Example 16 may include the subject of Example 12 or any of the examples described herein, wherein one or more baseband processors are used to encode signals to be transmitted to a User Equipment (UE) to indicate one or more security keys associated with the DRB and changes to the one or more keys. Example 17 may include the subject of Example 12 or any of the examples described herein, wherein one or more baseband processors are used to configure the one or more logical channels to be associated with a Primary Cell Group (MCG), a Secondary Cell Group (SCG), or any additional group or a combination thereof. Example 18 may include the subject of Example 12 or any of the examples described herein, wherein one or more baseband processors are used to place one or more logical channels in one or more cell groups into a suspended state, while allowing communication to continue on one or more other logical channels in one or more other cell groups. Example 19 may include the subject of Example 12 or any of the examples described herein, wherein the DRB is an uplink radio bearer or a downlink radio bearer, or a combination thereof. Example 20 may include the subject of Example 12 or any of the examples described herein, wherein one or more baseband processors are used to encode signals to indicate node changes as a corresponding set of functions. Example 21 may include the subject of Example 12 or any of the examples described herein, wherein one or more baseband processors are used to encode signals to indicate auxiliary node (SN) PDCP node changes with key changes and PDCP re-establishment, as well as re-establishment or reset of one or more of the logical channels.Example 22 may include the subject of Example 12 or any of the examples described herein, wherein one or more baseband processors are configured to encode signals to indicate a secondary node (SN) logical channel by providing a new logical channel configuration for a corresponding cell group and re-establishing the new logical channel or one or more other logical channels. Example 23 may include the subject of Example 12 or any of the examples described herein, wherein one or more baseband processors are configured to cause a secondary node (SN) logical channel change by reconfiguring an old logical channel or by releasing the old logical channel and adding a new logical channel. Example 24 may include the subject of Example 12 or any of the examples described herein, wherein one or more baseband processors are configured to cause a SN logical channel change by reconfiguring one or more cell groups that have not been changed to stop the transmission of old data to the PDCP layer when the PDCP layer changes its configuration.

[0334] In Example 25, an apparatus for a user equipment (UE) includes one or more baseband processors for decoding a Radio Resource Control (RRC) Connection Reconfiguration message RRCConnectionReconfiguration from a network, wherein the RRC Connection Reconfiguration message includes an Information Element (IE) for configuring the UE to receive data from a Long Term Evolution (LTE) node and a New Radio (NR) node in a unified split bearer configuration, and for processing data received via a Primary Cell Group (MCG) bearer, a Secondary Cell Group (SCG) bearer, or a unified split bearer; and a memory for storing the configuration message. Example 26 may include the subject matter of Example 25 or any of the examples described herein, wherein the IE of the RRC Connection Reconfiguration message indicates a bearer type change between the MCG bearer and the unified split bearer, or between the SCG bearer and the unified split bearer. Example 27 may include the subject matter of Example 25 or any of the examples described herein, wherein the one or more baseband processors are configured to decode a lossless reconfiguration of an LTE Packet Data Convergence Protocol (PDCP) entity to an NR PDCP entity for a bearer type change, or to decode a lossless reconfiguration of an NR PDCP entity to an LTE PDCP entity. Example 28 may include the subject of Example 25 or any of the examples described herein, wherein the RRC connection reconfiguration message indicates whether a bearer change with Packet Data Convergence Protocol (PDCP) re-establishment and key change should be performed for an MCG bearer to an SCG split bearer or for an SCG split bearer to an MCG bearer. Example 29 may include the subject of Example 25 or any of the examples described herein, wherein the IE of the RRC connection reconfiguration message indicates whether a bearer change with Packet Data Convergence Protocol (PDCP) data recovery and no key change should be processed for an MCG split bearer to an MCG bearer.

[0335] In Example 30, one or more machine-readable media may have instructions thereon that, when executed by an evolved Node B (eNB) or fifth-generation (5G) Node B (gNB) device, cause the generation of a Radio Resource Control (RRC) Connection Reconfiguration message, RRCConnectionReconfiguration, to include an Information Element (IE) for configuring a User Equipment (UE) to receive data from a Long Term Evolution (LTE) node and a New Radio (NR) node in a unified split bearer configuration, and encoding the data for transmission to the UE via a Primary Cell Group (MCG) bearer, a Secondary Cell Group (SCG) bearer, or a unified split bearer. Example 31 may include the subject matter of Example 30 or any of the examples described herein, wherein the IE of the RRC Connection Reconfiguration message indicates a bearer type change between the MCG bearer and the unified split bearer, or between the SCG bearer and the unified split bearer. Example 32 may include the subject matter of Example 30 or any of the examples described herein, wherein the instruction, when executed, also causes a lossless reconfiguration of the LTE Packet Data Convergence Protocol (PDCP) entity to an NR PDCP entity for a bearer type change, or a lossless reconfiguration of the NR PDCP entity to an LTE PDCP entity. Example 33 may include the subject matter of Example 30 or any of the examples described herein, wherein the IE of the RRC connection reconfiguration message indicates whether a bearer change with Packet Data Convergence Protocol (PDCP) re-establishment and key change should be performed for an MCG bearer to an SCG split bearer or for an SCG split bearer to an MCG bearer. Example 34 may include the subject matter of Example 30 or any of the examples described herein, wherein the IE of the RRC connection reconfiguration message indicates whether a bearer change with Packet Data Convergence Protocol (PDCP) data recovery and no key change should be performed for an MCG split bearer to an MCG bearer.

[0336] In Example 35, one or more machine-readable media having instructions thereon, which, when executed by a device of a fifth-generation (5G) Node B (gNB), cause a reconfiguration message RRCReconfiguration to be encoded to include Packet Data Convergence Protocol (PDCP) and higher-layer configuration information elements (IEs) for configuring a data radio bearer (DRB) to be coupled to one or more logical channels at or below radio link control, and to encode the reconfiguration message RRCReconfiguration to configure changes between a single-connectivity bearer and a multi-connectivity bearer by configuring or releasing one or more of the logical channels. Example 36 may include the subject matter of Example 35 or any of the examples described herein, wherein the reconfiguration message includes an information element (IE) RadioBearerConfig to be transmitted to a user equipment (UE) to reset or re-establish one or more protocol layers. Example 37 may include the subject matter of Example 35 or any of the examples described herein, wherein the DRB is associated with two or more logical channels of a radio access technology (RAT) implemented by the gNB.

[0337] In Example 38, one or more machine-readable media having instructions that, when executed by a user equipment (UE) device, cause decoding of a Radio Resource Control (RRC) Connection Reconfiguration message from a network, wherein the RRC Connection Reconfiguration message includes an Information Element (IE) for configuring the UE to receive data from Long Term Evolution (LTE) nodes and New Radio (NR) nodes in a unified split bearer configuration, and for processing data received via a Primary Cell Group (MCG) bearer, a Secondary Cell Group (SCG) bearer, or a unified split bearer. Example 39 may include the subject matter of Example 38 or any of the examples described herein, wherein the IE of the RRC Connection Reconfiguration message indicates a bearer type change between the MCG bearer and the unified split bearer, or between the SCG bearer and the unified split bearer. Example 40 may include the subject of Example 38 or any of the examples described herein, wherein the instructions, when executed, also cause a lossless reconfiguration of the LTE Packet Data Convergence Protocol (PDCP) entity of the bearer to an NR PDCP entity for a change in bearer type, or a lossless reconfiguration of the NR PDCP entity to an LTE PDCP entity.

[0338] In Example 45, an apparatus for a user equipment (UE) includes one or more baseband processors for decoding a reconfiguration message RRCReconfiguration, which includes a Packet Data Convergence Protocol (PDCP) and a higher-level configuration information element (IE) for configuring a Data Radio Bearer (DRB) to be coupled to one or more logical channels at or below Radio Link Control; configuring a change between a single-connectivity bearer and a multi-connectivity bearer or between a single-connectivity MCG bearer and an SCG bearer by configuring or releasing one or more of the logical channels; and a memory for storing the configuration. Example 46 may include the subject of Example 45 or any of the examples described herein, wherein the one or more baseband processors are configured to decode the IE of the reconfiguration message to reset or re-establish one or more of the protocol layers. Example 47 may include the subject of Example 45 or any of the examples described herein, wherein the DRB is associated with two or more logical channels of a Radio Access Technology (RAT) implemented by the gNB. Example 48 may include the subject of Example 45 or any of the examples described herein, wherein the RAT conforms to the Long Term Evolution (LTE) standard or the New Radio (NR) standard. Example 49 relates to an apparatus comprising means for executing instructions of any of the foregoing examples. Example 50 relates to a machine-readable storage containing machine-readable instructions that, when executed, implement the apparatus of any of the foregoing claims.

[0339] In this specification and / or claims, the terms “coupled” and / or “connected” and their derivatives may be used. In certain embodiments, a connection may be used to indicate that two or more elements are in direct physical and / or electrical contact with each other. “Coupled” may mean that two or more elements are in direct physical and / or electrical contact with each other. However, coupling may also mean that two or more elements are not in direct contact with each other, but can still cooperate and / or interact with each other. For example, “coupled” may mean that two or more elements are not in contact with each other, but are indirectly joined together via another element or an intermediate element. Finally, the terms “above,” “cover,” and “over” may be used in the following description and claims. “Above,” “cover,” and “over” may be used to indicate that two or more elements are in direct physical contact with each other. However, it should be noted that “over” may also mean that two or more elements are not in direct contact with each other. For example, “over” may mean that one element is above another element but not in contact with each other, and there may be one or more other elements between the two elements. Furthermore, the term "and / or" can mean "and," it can mean "or," it can mean "exclusive," it can mean "one," it can mean "some, but not all," it can mean "none," and / or it can mean "both," although the scope of the claimed subject matter is not limited in this respect. In this specification and / or claims, the terms "comprising" and "including" and their derivatives may be used, and they are intended to be synonymous with each other.

[0340] While the claimed subject matter has been described with a degree of specificity, it should be recognized that those skilled in the art can modify its elements without departing from the substance and / or scope of the claimed subject matter. It is believed that the subject matter of L2 treatment with respect to changes in load-bearing type and its many incidental benefits will be understood from the foregoing description, and it will be apparent that various changes can be made to the form, construction, and / or arrangement of its components without departing from the scope and / or spirit of the claimed subject matter, or without sacrificing all its material advantages; the forms described above are merely illustrative embodiments, and / or further do not provide any substantial changes thereto. The purpose of the claims is to cover and / or include such changes.

Claims

1. A method for a base station, comprising: At the base station: A Radio Resource Control (RRC) reconfiguration message is sent to the User Equipment (UE) including an Information Element (IE) for split bearer configuration, wherein the base station is configured to allocate a previously unused Logical Channel Identifier (LC-ID) to the Data Radio Bearer (DRB) associated with the Packet Data Convergence Protocol (PDCP) re-establishment, and a Media Access Control (MAC) entity is configured to discard MAC Protocol Data Units (PDUs) with unknown LC-IDs to release the previously unused logical channel associated with the DRB, including the DRB's previously unused LC-ID, without involving a Secondary Cell Group (SCG) or Primary Cell Group (MCG) MAC reset, thereby preventing data from the previously used logical channel from reaching the DRB's PDCP entity without involving an SCG or MCG MAC reset; and Data is sent to the UE via MCG bearer, SCG bearer, or split bearer.

2. The method according to claim 1, wherein, The IE in the RRC reconfiguration message indicates a change in bearer type between the MCG bearer and the split bearer, or between the SCG bearer and the split bearer.

3. The method according to claim 2, wherein, The bearer type change includes reconfiguring the Long Term Evolution (LTE) PDCP entity of the bearer to a New Radio (NR) PDCP entity.

4. The method according to claim 2, wherein, The bearer type change includes reconfiguring the new air interface NR PDCP entity of the bearer to a Long Term Evolution LTE PDCP entity.

5. The method according to claim 1, wherein, The IE indication in the RRC reconfiguration message indicates whether a bearer change with PDCP re-establishment and key change should be performed for an MCG bearer to an SCG split bearer.

6. The method according to claim 1, wherein, The IE indication in the RRC reconfiguration message indicates whether a bearer change with PDCP re-establishment and key change should be performed for an SCG split bearer to an MCG bearer.

7. The method according to claim 1, wherein, The IE indication in the RRC reconfiguration message is whether to perform a bearer change with PDCP data recovery and no key change for MCG split bearer to MCG bearer.

8. The method according to claim 1, wherein, The IE indication in the RRC reconfiguration message indicates whether a bearer change without PDCP data recovery or key change should be performed for an MCG bearer to an MCG split bearer.

9. A baseband circuit for a base station, the baseband circuit comprising one or more baseband processors, The one or more baseband processors are configured to perform operations, the operations including: A Radio Resource Control (RRC) reconfiguration message is sent to the User Equipment (UE) including an Information Element (IE) for split bearer configuration, wherein the base station is configured to allocate a previously unused Logical Channel Identifier (LC-ID) to the Data Radio Bearer (DRB) associated with the Packet Data Convergence Protocol (PDCP) re-establishment, and a Media Access Control (MAC) entity is configured to discard MAC Protocol Data Units (PDUs) with unknown LC-IDs to release the previously unused logical channel associated with the DRB, including the DRB's previously unused LC-ID, without involving a Secondary Cell Group (SCG) or Primary Cell Group (MCG) MAC reset, thereby preventing data from the previously used logical channel from reaching the DRB's PDCP entity without involving an SCG or MCG MAC reset; and Data is sent to the UE via MCG bearer, SCG bearer, or split bearer.

10. The baseband circuit according to claim 9, wherein, The IE in the RRC reconfiguration message indicates a change in bearer type between the MCG bearer and the split bearer, or between the SCG bearer and the split bearer.

11. The baseband circuit according to claim 10, wherein, The bearer type change includes reconfiguring the Long Term Evolution (LTE) PDCP entity of the bearer to a New Radio (NR) PDCP entity.

12. The baseband circuit according to claim 10, wherein, The bearer type change includes reconfiguring the new air interface NRPDCP entity of the bearer into a Long Term Evolution LTE PDCP entity.

13. The baseband circuit according to claim 9, wherein, The IE indication in the RRC reconfiguration message indicates whether a bearer change with PDCP re-establishment and key change should be performed for an MCG bearer to an SCG split bearer.

14. The baseband circuit according to claim 9, wherein, The IE indication in the RRC reconfiguration message indicates whether a bearer change with PDCP re-establishment and key change should be performed for an SCG split bearer to an MCG bearer.

15. The baseband circuit according to claim 9, wherein, The IE indication in the RRC reconfiguration message is whether to perform a bearer change with PDCP data recovery and no key change for MCG split bearer to MCG bearer.

Images