Improvements in and relating to coverage in a telecommunication network

Abstract

Coverage within a Radio Access Network (RAN) is affected by the size of control messages transmitted between user equipment (UE) and base station (gNB): the smaller the control message, the larger the

Description

The present invention relates to issues connected to coverage in a telecommunication network. There are many factors which can impact coverage. One addressed herein concerns messaging. In particular, it concerns control messages including Radio Resource Control (RRC) messages and Medium Access Control layer Control Elements (MAC CEs) exchanged between a User Equipment (UE) and a base station (gNB) of the network. Embodiments of the present invention find particular utility in Fifth Generation or New Radio systems but may find application in other telecommunication networks. In a Radio Access Network (RAN) i.e. the part of a telecommunication network which interfaces directly with UEs, one of the main determinants of coverage is the size of the bitstream transmitted from the UE to the network. The gNB includes Central Unit and Distributed Unit (CU-DU) split architecture where gNB Central Unit (gNB-CU) is a logical node hosting RRC, SDAP (Service Data Adaptation Protocol) and PDCP protocols of the gNB or RRC and PDCP protocols of the gNB that controls the operation of one or more gNB-DUs, and gNB Distributed Unit (gNB-DU) is a logical node hosting RLC, MAC and PHY (Physical) layers of the gNB, and its operation is partly controlled by gNB-CU. The gNB-CU terminates the F1 interface connected with the gNB-DU. One gNB-DU supports one or multiple cells. One cell is supported by only one gNB-DU. The gNB-DU terminates the F1 interface connected with the gNB-CU. For DC operation, the Master gNB-DU designates the gNB-DU of an gNB or a gNB acting as master node, and the Secondary gNB-DU designates the gNB-DU of an gNB or a gNB acting as secondary node. Signalling Radio Bearers are known in the art and are used for control plane data transmission and reception in MCG (Master Cell Group) and SCG (Secondary Cell Group). There are a plurality of SRBs in use, including: SRBO, which is used for CCCH (Common Control Channel), i.e. when to set up RRC connection with the network; SRB1, which is used for most RRC messages after RRC connection; SRB2, which is used to transport low priority Non-Access Stratum (NAS) messages; and SRB3, which is used to transport SCG RRC message between SCG and UE. Note that Packet Data Convergence Protocol (PDCP) header and Radio Link Control (RLC) headers are not attached to data via SRBO, but they are attached to data via other SRBs. Transparent Mode (TM) RLC is one RLC entity, and Acknowledged Mode (AM) RLC is another RLC entity. TM mode does not require any RLC entity processing, including RLC header generation. As mentioned above, PDCP header and RLC header are attached to data via SRB1, SRB2, and SRB3. A Medium Access Control (MAC) header is attached to data via all SRBs by adding Logical Channel ID (LCID) corresponding to the logical channel of each SRB. MAC CE is a control message, which can be transmitted and received from / to MAC layers of UE or gNB, and processed in MAC layer. In general, It does not go through RLC, PDCP, and RRC layers. Figure 2 summarises this and illustrates the configuration of SRBO to SRB3. A feature of coverage in a Radio Access Network (RAN) is that the size of the bitstream is of importance when determining coverage. The first RRC message between the UE and the network is one of RRCSetupRequest and RRCResumeRequest. RRCSetupRequest is transmitted from the UE when the UE transits from RRC IDLE mode to RRC CONNECTED mode. RRCResumeRequest is transmitted from the UE when the UE transits from RRC INACTIVE to RRC CONNECTED mode. The smaller the size of the control message, the larger the coverage. It is therefore desirable to minimise as far as possible the size of the control message. Any reduction in the size of the control message translates into increased coverage. It is an aim of embodiments of the present invention to reduce the size of control messages in such situations. In this invention, the term “control message” indicates RRC message or MAC CE. As the size of RRC message is much larger than the size of MAC CE, how to reduce the size of RRC message is firstly dealt with, and then the replacement of a large RRC message with a small MAC CE is also dealt with for the certain cases. However, the size of RRCSetupRequest and RRCResumeRequest is limited, in the prior art, to a certain size (e.g. 48bits or 56bits) in the applicable standard because it has an impact on coverage. Further, it is difficult to optimize the size of RRCSetupRequest and RRCResumeRequest because Message 3 (RRCSetupRequest or RRCResumeRequest) is the first RRC message from the UE side before RRC Connection and this already has a limited size due to the aforementioned coverage issue. Message 3 is transmitted via SRBO and only a MAC header is attached to the RRC messages. Problems or issues with coverage can be experienced due to one or more of: • the case that UE is initially setting up the RRC connection with network; • the case that UE performs handover (i.e. PCell change for MCG(Master Cell Group) or PSCell change for SCG(Secondary Cell Group)) to another cell (i.e. PCell change), e.g. intra-gNB handover (Handover to another cell of the same gNB or base-station) or intra-DU handover (Handover to another cell belonging to the same DU) or Inter-gNB handover (Handover to a cell of different gNB or base-station) or inter-DU handover (Handover to a cell belonging to the different DU), which can be applied to MCG or SCG; • the case that UE performs Secondary Cell Group (SCG) addition or change (i.e. PSCell change), e.g. SCG addition (PSCell addition) or intra-SCG change (Change to another cell of the same SCG) or inter-SCG change (Change to a cell of the different SCG); • the case that UE performs RRC Re-establishment according to one of many causes including the following: o upon detecting radio link failure of the MCG and t316 is not configured; or o upon detecting radio link failure of the MCG while SCG transmission is suspended;or o upon detecting radio link failure of the MCG while PSCell change or PSCell addition is ongoing; or o upon detecting radio link failure of the MCG while the SCG is deactivated; or o upon re-configuration with sync failure of the MCG; or o upon mobility from NR failure; or o upon integrity check failure indication from lower layers concerning SRB1 or SRB2, except if the integrity check failure is detected on the RRCReestablishment message; or o upon an RRC connection reconfiguration failure; or o upon detecting radio link failure for the SCG while MCG transmission is suspended in NR-DC or in NE-DC; or o upon reconfiguration with sync failure of the SCG while MCG transmission is suspended;or o upon SCG change failure while MCG transmission is suspended; or o upon SCG configuration failure while MCG transmission is suspended in NR-DC or in NE-DC; or o upon integrity check failure indication from SCG lower layers concerning SRB3 while MCG is suspended; or o upon T316 expiry. According to the present invention there is provided an apparatus and method as set forth in the appended claims. Other features of the invention will be apparent from the dependent claims, and the description which follows. According to a first aspect of the present invention, there is provided a method of performing a PCell change by a transmitting device, configured with at least one target cell configuration in a wireless communication system, the method comprising: receiving a MAC Control Element (CE) indicating the at least one target cell configuration; performing a PCell change execution to the target cell by applying the at least one target cell configuration and sending RRCReconfigurationComplete to the at least one target cell. In an embodiment, the transmitting device is a User Equipment, UE. In an embodiment, control messages are transmitted via Signalling Radio Bearer 1, SRB1. In an embodiment, the network provides a plurality of SRB configurations for the transmitting device, said plurality of configurations comprising one or more of: - SRB with RLC-AM(Acknowledged Mode) entity configuration; - SRB with RLC-TM(Transparent Mode) entity configuration for RRC message transmission with reduced overhead; - SRB with RLC-UM(Unacknowledged Mode) entity configuration for RRC message transmission with reduced latency; - SRB with two RLC-AM entities, one RLC-AM entity for one cell and the other RLC-AM entity for the other cell (i.e. split SRB for carrier aggregation (CA), which can be used for packet duplication to enhance the reliability); - SRB with two RLC-AM entities, one RLC-AM entity for one cell group (e.g. MCG) and the other RLC-AM entity for the other cell group (e.g. SCG) (i.e. split SRB for dual connectivity (DC), which can be used for packet duplication to enhance the reliability); - SRB with two RLC entities, one RLC-AM entity for reliable transmission and the RLC-UM entity for RRC message transmission with reduced latency; and - SRB with two RLC entities, one RLC-AM entity for reliable transmission and the RLC-TM entity for RRC message transmission with reduced overhead (i.e. split SRB for coverage enhancement with overhead reduction). In an embodiment, a source cell checks if a transmitting device has capability relating to a Fourth MAC PDU by means of UE Information Request and UE Information Response. In an embodiment, the source cell checks if the target cell has capability relating to the Fourth MAC PDU via Xn message. According to a second aspect of the present invention, there is provided apparatus arranged to perform the method of any preceding claim. Although a few preferred embodiments ofthe present invention have been shown and described, it will be appreciated by those skilled in the art that various changes and modifications might be made without departing from the scope ofthe invention, as defined in the appended claims. For a better understanding ofthe invention, and to show how embodiments ofthe same may be carried into effect, reference will now be made, by way of example only, to the accompanying diagrammatic drawings in which: Figure 1 shows a representation ofthe Control Plane and User Plane stack, referenced in this application; Figure 2 shows a representation of Signalling Radio Bearer (SRB) configuration; Figure 3 shows a message exchange according to an embodiment ofthe present invention; Figure 4 shows a configuration of SRB1 according to an embodiment ofthe present invention; Figure 5 shows an RRC message configuration according to an embodiment of the present invention; Figure 6 shows an RRC message configuration according to an embodiment of the present invention; Figure 7 shows a configuration of SRB according to an embodiment ofthe present invention; Figure 8 shows an RRC message configuration according to an embodiment of the present invention; Figure 9 shows a configuration of SRB according to an embodiment ofthe present invention; Figure 10 shows an RRC message configuration according to an embodiment of the present invention; Figure 11 shows a configuration of SRB according to an embodiment of the present invention and an associated message configuration; Figure 12 shows a MAC PDU structure according to an embodiment of the invention; and Figure 13 shows a MAC PDU structure according to an embodiment of the invention. Multiple cases are considered in the following and each has one or more RRC messages and a MAC CE associated therewith: Case 0: When UE is initially setting up the RRC connection with network; RRCSetupRequest, RRCResumeRequest, Case 1-1: When UE performs handover to another cell (i.e. PCell change), e.g. intra-gNB handover (Handover to another cell of the same gNB or base-station) or intra-DU handover (Handover to another cell belonging to the same DU) or Inter-gNB handover (Handover to a cell of different gNB or base-station) or inter-DU handover (Handover to a cell belonging to the different DU), which can be applied to MCG or SCG; RRCReconfiguration, RRCReconfigurationComplete, Case 1-2: When UE performs handover to another cell (i.e. PCell change), e.g. intra-gNB handover (Handover to another cell of the same gNB or base-station) or intra-DU handover (Handover to another cell belonging to the same DU) or Inter-gNB handover (Handover to a cell of different gNB or base-station) or inter-DU handover (Handover to a cell belonging to the different DU), which can be applied to MCG or SCG; A MAC CE with an identity indicating a target cell (or a target cell configuration), instead of RRCReconfiguration, RRCReconfigurationComplete, Case 2: When UE performs SCG addition or change (i.e. PSCell change), e.g. SCG addition (PSCell addition) or intra-SCG change (Change to another cell of the same SCG) or inter-SCG change (Change to a cell of the different SCG); RRCReconfiguration, RRCReconfigurationComplete, Case 3: When UE performs RRC Re-establishment according to one of many RRC Reestablishment cause; RRCReestablishmentRequest, RRCReestablishment, RRCReestablishmentComplete. Case 4: When UE performs Conditional handover; RRCReconfiguration, RRCReconfigurationComplete to the source cell; RRCReconfigurationComplete to the target cell Further, newly defined RRC messages may be created for any of the cases above (i.e. Case 0, 1,2, 3, and 4). As mentioned above, the smaller the size of the control message (e.g. RRC message or MAC CE), the greater the coverage. If the RRC message can be reduced, then coverage can be correspondingly increased. If the size of RRC messages can be reduced, the network coverage can be enhanced. For Case 1-1, in particular, it is difficult to optimise the size of RRC message. However, in embodiments of the invention, the configuration restriction is lifted and new parameters, rules and procedures are introduced, thereby allowing RRC messages to be reduced in size for Cases 1,2,3 and 4 all described previously. The following relates to Case 1-1, PCell change or Handover. The message exchange between the UE 10, the Source gNB 20 and Target gNB 30 is shown in Figure 3. The target gNB 30 can be interpreted as a target cell, i.e. for intra-gNB handover or intra-DU handover, the target gNB 30 indicates the target cell belonging to the same gNB (or DU) as the source gNB is the target gNB. The handover is triggered by the network. Based on the UE’s measurement report (S1), the source gNB 20 looks for a suitable cell and then sends a handover request message (S2) to target gNB 30 for approval. When the target gNB 30 approves the request, it generates Handover request ACK message (S3) including a RRCReconfiguration message and sends it to the source gNB 20. The source gNB 20 (or cell) sends the RRCReconfiguration message (S4) to UE 10 as a handover command, which includes reconfigurationWithsync indicator indicating PCell change (i.e. handover). When UE receives the RRCReconfiguration message, UE starts T304 timer and initiates a handover to the target cell. T304 stops when the random access procedure toward the target cell is successfully completed. The handover is considered as failed upon the expiry ofT304 timer. The source gNB transfers Sequence Number (SN) status to the target gNB, which allows the target gNB to reorder the received data in order and check the missing data, based on sequence number (e.g. PDCP sequence number or COUNT value) (S5). The source gNB can forward the data to the target gNB, which has not been transmitted to UE (S6). The UE 10 performs handover by initiating a random access procedure (S7) and sending RRCReconfigurationComplete (S9 to the target gNB (or cell) 30. When UE successfully completes the random access procedure (i.e. the target gNB receives the RRCReconfigurationComplete message), UE and the target gNB considers the handover as successfully completed and indicates the source gNB to release UE context (S10). After handover (i.e. PCell change for MCG or PSCell change for SCG), UE transmits and receives data to / from the target gNB (S12). The target gNB can re-configure RRC configuration to UE, if needed (S11). Figure 3 shows that various RRC messages are transferred as a part of the handover process. These RRC messages are all transmitted via SRB1. The size of the RRCReconfiguration message can be defined as X bytes while the size of RRCReconfigurationComplete is about 2 bytes. Based on the RRC configuration for the target cell 30, the size of the RRCReconfiguration message could be hundreds of bytes, which is variable. The RRCReconfigurationComplete message is also of a variable size, but is generally around 2 bytes. When RRCReconfiguration is sent (S4) to UE 10 via the first SRB1, the first SRB1 can be configured, according to the specific configuration in place, as one of: SRB1, split SRB1 (based on Carrier Aggregation), or split SRB1 (based on Dual Connectivity).These configurations are shown in Figure 4. According to an embodiment of the present invention, the first MAC Protocol Data Unit, (PDU), to be transmitted via SRB 1 includes the RRC message (e.g. RRCReconfiguration), PDCP header, MAC-I, RLC header, and MAC header as shown in Figure 5. As an example, the size of the headers and MAC-I are shown. Note that MAC-I is the Message Authentication Code for Integrity, which is generated and processed in the PDCP entity. If the RRC message to be transmitted is RRCReconfiguration and the transmitted data has the format and structure of the first MAC PDU, its size would be 10+X bytes (2+2+2+X+4 bytes). However, if the RRC message to be transmitted is RRCReconfigurationComplete and the transmitted data has the format and structure of the first MAC PDU, its size would be 12 bytes (2+2+2+2+4 bytes) as shown in Figure 6. In this case, the total message includes quite a large overhead, relative to the actual data, which is only 2 bytes. According to an embodiment of the invention, for a SRB (SRB1 or SRB2 or SRB3 or SRBx), gNB provides one or more of the following SRB configuration(s) to the UE via dedicated RRC signalling: - SRB with RLC-AM(Acknowledged Mode) entity configuration; - SRB with RLC-TM(Transparent Mode) entity configuration for RRC message transmission with reduced overhead; - SRB with RLC-UM(Unacknowleddged Mode) entity configuration for RRC message transmission with reduced latency; - SRB with two RLC-AM entities, one RLC-AM entity for one cell and the other RLC-AM entity for the other cell (i.e. split SRB for carrier aggregation (CA), which can be used for packet duplication to enhance the reliability); - SRB with two RLC-AM entities, one RLC-AM entity for one cell group (e.g. MCG) and the other RLC-AM entity for the other cell group (e.g. SCG) (i.e. split SRB for dual connectivity (DC), which can be used for packet duplication to enhance the reliability); - SRB with two RLC entities, one RLC-AM entity for reliable transmission and the RLC-UM entity for RRC message transmission with reduced latency. - SRB with two RLC entities, one RLC-AM entity for reliable transmission and the RLC-TM entity for RRC message transmission with reduced overhead (i.e. split SRB for coverage enhancement with overhead reduction). One RLC-AM entity can be configured for the source cell and the other RLC-TM entity can configured be for the target cell. Or one RLC-TM entity can be configured for the source cell and the other RLC-AM entity can be configured for the target cell. Or the RLC-AM entity and the other RLC-TM entity can be configured for the target cell. Or the RLC-AM entity and the other RLC-TM entity can be configured for the source cell. The network can configure the second SRB with two RLC entities, one RLC-AM entity for reliable transmission and the RLC-TM entity for RRC message transmission with reduced overhead or the second SRB with RLC-TM entity configuration for RRC message transmission with reduced overhead, which can be configured by RRCReconfiguration message before RRCReconfiguration with reconfigurationWithSync indicating handover (in this case, the overhead can be reduced for both RRCReconfiguration and RRCReconfigurationComplete message) or by RRCReconfiguration message with reconfigurationWithSync indicating handover (in this case, the overhead can be reduced only for RRCReconfigurationComplete message as UE will send it the target cell. The coverage towards the target cell will be enhanced). The second MAC PDU to be transmitted via SRB1 includes the RRC message (e.g. RRCReconfiguration or RRCReconfigurationComplete), PDCP header, MAC-I, and MAC header, and the second SRB1 can be configured with a PDCP entity associated with an AM RLC entity and a TM RLC entity or a separate SRBx with TM RLC as shown in Figure 7. The second MAC PDU can be transmitted and received (i.e. processed) via the TM RLC leg of the second SRB1 when the second SRB1 is configured. The TM RLC entity does not process the received data, i.e. it does not generate RLC header. If the RRC message to be transmitted is RRCReconfiguration and the transmitted data has the format and structure of the second MAC PDU, its size would be 8+X bytes (2+2+X+4 bytes), i.e. the size is reduced by 2 bytes compared to the previous example. This is illustrated in Figure 8. As the size decreases, the coverage increases. However, if the RRC message to be transmitted is RRCReconfigurationComplete and the transmitted data has the format and structure of the second MAC PDU, its size would be 10 bytes (2+2+2+4 bytes) as shown in the following figure, i.e. the size is reduced by 2 bytes compared to the previous example. This is also illustrated in Figure 8. As the size decreases, the coverage increases. In a further embodiment of the present invention, the network can configure the third SRB with one RLC-TM entity for RRC message transmission with reduced overhead, which can be configured by RRCReconfiguration message before RRCReconfiguration with reconfigurationWithSync indicating handover (in this case, the overhead can be reduced for both RRCReconfiguration and RRCReconfigurationComplete message) or by RRCReconfiguration message with reconfigurationWithSync indicating handover (in this case, the overhead can be reduced only for RRCReconfigurationComplete message as UE will send it the target cell. The coverage towards the target cell will be enhanced). The third MAC PDU to be transmitted via the SRB1 includes the RRC message (e.g. RRCReconfiguration or RRCReconfigurationComplete), MAC header and a new field (e.g. MAC-I in MAC entity or Digital Signature) and the third SRB1 can be configured with a TM RLC entity as a supplementary SRB1 or a new SRBx as shown in Figure 9, i.e. the MAC entity performs integrity protection and integrity verification for the third MAC PDU with a new field, as shown. The indicator in the MAC header may indicate whether it is integrity protected (or ciphered) or not (e.g. special LCID). The third MAC PDU can be transmitted and received (i.e. processed) via the third SRB1 when the third SRB1 is configured. As an example, the size of the headers and MAC-I can be assumed as shown in Figure 10. If the RRC message to be transmitted is RRCReconfiguration and the transmitted data has the format and structure of the third MAC PDU, its size would be 6+X bytes (2+X+4 bytes), i.e. the size is reduced by 4 bytes. However, if the RRC message to be transmitted is RRCReconfigurationComplete and the transmitted data has the format and structure of the third MAC PDU, its size would be 8 bytes (2+2+4 bytes) as shown in Figure 10, i.e. the size is reduced by 4 bytes. In a further embodiment of the present invention, the fourth MAC PDU to be transmitted for PCell change can be defined as a MAC CE(Control Element). The fourth MAC PDU can include the first MAC CE triggering (or indicating) PCell change with an Identity (or index) for the target cell or the second MAC CE acknowledging the PCell change (the second MAC CE can be replaced by the HARQ ACK of the first MAC CE). The fourth MAC PDU (i.e. the first MAC CE indicating PCell change) can replace RRCReconfiguration or RRCReconfigurationComplete in order to reduce the overhead and enhance the coverage as the size of RRC message is much larger than the size of MAC CE. In an embodiment of the present invention, the network can send a UE the first MAC CE with an indicator indicating the target cell (or the target cell configuration) for PCell change, instead of transmitting RRCReconfiguration message with reconfigurationiWithSync indicating PCell change. The target cell identity or target cell configuration indicated by the first MAC CE can be (pre-) configured (e.g. by RRCReconfiguration message) via a SRB1 before the transmission of the first MAC CE. When UE receives the first MAC CE with an indicator indicating the target cell (or the target cell configuration), UE applies the indicated target cell configuration and performs PCell change (i.e cell switch procedure). UE can also indicate the MAC layer’s reception of the first MAC CE (or the execution of PCell change) to the RRC layer so the RRC layer can apply the target cell configuration or generate RRCReconfigurationComplete message. The cell switch procedure includes the random access procedure towards the target cell triggered by the UE. If a time alignment timer is not running for the target cell or a timing advance value (TA value) for the target cell is not valid or the timing advance value for the target cell is not indicated in the first MAC CE, UE can perform a random access procedure towards the target cell to get a valid TA value. During the random access procedure, UE can transmit RRCReconfigurationComplete message to the target cell. If a time alignment timer is running for the target cell or a timing advance value (TA value) for the target cell is valid or the timing advance value for the target cell is indicated in the first MAC CE, UE does not trigger a random access procedure (i.e. skip the random access procedure) and UE can transmit RRCReconfigurationComplete message by using available radio resources (e.g. configured grant or PDCCH-indicated resources from the target cell). In this way, the network can transmit the first MAC CE to UE to trigger a PCell change with reduced overhead (i.e. for coverage enhancement and fast control message processing (as the MAC CE is very small)) and UE can complete the PCell change by sending RRCReconfigurationComplete message to the target cell. In a further embodiment of the present invention, the fourth MAC PDU can be protected by integrity protection (or ciphering) and integrity verification (or deciphering) performed by MAC entity with a new field. The indicators in MAC header may indicate whether it is integrity protected (or ciphered) or not (e.g. special LCID) or whether to include the new field. The new field can be attached to the end of MAC PDU or located after MAC header or right after MAC CE. The fourth MAC PDU can be a security-protected MAC CE with the new field or a normal (non-security protected) MAC CE without the new field as shown in Figure 11. The new field can be defined as a new MAC-I in the MAC entity, which can be generated in the MAC entity (the transmitting MAC entity) and can be checked in the MAC entity (the receiving MAC entity). In another embodiment, the new field can re-use MAC-I of PDCP entity, i.e. the PDCP entity can generate MAC-I for MAC. If the PCell change is triggered by the fourth MAC PDU, its size would be around 3 bytes, i.e. the size is significantly reduced but its reconfiguration is very limited. However, if the fourth MAC PDU replaces RRCReconfigurationComplete, its size would be around 3 bytes, i.e. the size is significantly reduced. The new field can be defined as a new MAC-I in the MAC entity, which can be generated in the MAC entity (the transmitting MAC entity) and can be checked in the MAC entity (the receiving MAC entity). In another embodiment, the new field can re-use MAC-I of PDCP entity, i.e. the transmitting PDCP entity can generate MAC-I for MAC CE by performing the integrity protection for PDCP header or MAC CE while the receiving PDCP entity can perform integrity verification for MAC-I for MAC CE or PDCP header, i.e. calculate X-MAC and match it to MAC-I and then check the integrity verification failure. This approach can reuse the legacy mechanism and minimize the implementation impact because the size of MAC CE is very small and thus the processing delay would be marginal. When the integrity protection and verification mechanism in PDCP is reused (i.e. MAC-I is used as the new field), the first process can be as shown in Figure 12. A special SRB (or DRB or radio bearer) can be configured for MAC CE integrity protection and verification. (The ciphering or deciphering can be applied in the same manner, if configured). The MAC entity generates the MAC CE and delivers it to the PDCP of the special DRB. The COUNT, DRB ID, Security Key etc for integrity protection can be applied as per a normal DRB. The PDCP entity applies the integrity protection for it and then submits it to the lower layer as normal data, i.e. MAC CE can be considered as a normal data. The PDCP header is generated, and the integrity protection is applied to PDCP header or MAC CE. After that, MAC-I is generated and attached to the end of MAC CE as shown in Figure 12. In the RLC entity, the RLC header is generated and attached to the front of RLC SDU. The RLC entity can be configured with AM mode for reliable transmission (by ARQ). UM mode can be configurable for the RLC entity. The MAC entity generates the MAC header and attaches it to MAC SDU, then submits it. The receiving MAC / RLC / PDCP entity can handle this as a normal data. However, when the integrity protection and verification mechanism in PDCP is reused (i.e. MAC-I is used as the new field), the second process can be as shown in Figure 13. A special SRB (or DRB or radio bearer) can be configured for MAC CE integrity protection and verification. The ciphering or deciphering can be applied in the same manner, if configured. The MAC entity generates the MAC CE and delivers it to the PDCP of the special DRB. The COUNT, DRB ID, Security Key etc for integrity protection can be applied as per a normal DRB. The PDCP entity applies the integrity protection for it and then submits it to the lower layer as normal data, i.e. MAC CE can be considered as a normal data. The PDCP header is generated, and the integrity protection is applied to PDCP header or MAC CE. After that, MAC-I is generated and attached to the end of MAC CE as shown in Figure 13. For the RLC entity, it can be configured with TM mode to reduce overhead or RLC entity itself is not configured. The MAC entity generates the MAC header and attaches it to MAC SDU, then submits it. The receiving MAC / PDCP entity can handle this as a normal data. In another embodiment, the PDCP header can be omitted to reduce the overhead further. Solution 1 The source gNB 20 can check whether UE 10 has the capability about the second SRB1 (or the second MAC PDU) or the third SRB1 (or the third MAC PDU) by UE Information Request and UE Information Response for UE Capability. The source gNB 20 can pre-configure the second SRB1 (or the third SRB1) to UE 10 by RRCReconfiguration (e.g. via SRB1) before sending handover command (e.g. RRCReconfiguration). When the source gNB 20 decides a handover is required, the source gNB 20 (or Cell) can ask the target gNB 30 (or Cell) about whether it has the capability about the second SRB1 (or the second MAC PDU) or the third SRB1 (or the third MAC PDU) via Xn message. The target gNB 30 can respond to this with a indication via Xn message. The Xn message is an inter-node message between gNBs. After that, the source gNB 20 can send the handover command with the second MAC PDU (or the third MAC PDU) including RRCReconfiguration to the UE 10 via the second SRB1. When the UE 10 receives the handover command, the UE 10 can check whether the configuration about the second SRB1 (or the third SRB1) or the second MAC PDU (or the third MAC PDU) for the target gNB 30 (or Cell) is configured in RRCReconfiguration. If configured, UE 10 configures the second SRB1 (or the third SRB1) for the target cell 30. In another embodiment, UE 10 can check the availability of the second SRB1 (or the third SRB1) or the second MAC PDU (or the third MAC PDU) for the target gNB 30 (or Cell) in system information (broadcasted as indicator), and then the UE 10 can configure it for the target cell 30. To complete handover, UE 10 can send the second MAC PDU (or the third MAC PDU) including RRCReconfiguationComplete to the target gNB 30 via the second SRB1 (or the third SRB1), if configured. Otherwise, UE 10 can send the first MAC PDU including RRCReconfiguationComplete to the target gNB 30 via the first SRB1. This transmission can be done as a part of the random access procedure (e.g Message 3 transmission or HARQ ACK). Solution 2 The source gNB 20 can check whether UE 10 has the capability about the second SRB1 (or the second MAC PDU) or the third SRB1 (or the third MAC PDU) by UE Information Request and UE Information Response for UE Capability. When the source gNB 20 decides a handover is required, the source gNB 20 (or Cell) can ask the target gNB 30 (or Cell) about whether it has the capability about the second SRB1 (or the second MAC PDU) or the third SRB1 (or the third MAC PDU) via Xn message. The target gNB 30 can respond to this with an indication via Xn message, e.g. Yes or No (ACK or NACK). After that, the source gNB 30 can send the handover command with the first MAC PDU including RRCReconfiguration to UE 10 via the first SRB1. When the UE 10 receives the handover command, UE 10 can check whether the configuration about the second SRB1 (or the third SRB1) or the second MAC PDU (or the third MAC PDU) for the target gNB 30 (or Cell) is configured in RRCReconfiguration. If configured, UE 10 configures the second SRB1 (or the third SRB1) for the target cell 30. In another embodiment, UE 10 can check the availability of the second SRB1 (or the third SRB1) or the second MAC PDU (or the third MAC PDU) for the target gNB 30 (or Cell) in system information (broadcasted as indicator), and then UE 10 can configure it for the target cell 30. To complete handover, UE 10 can send the second MAC PDU (or the third MAC PDU) including RRCReconfiguationComplete to the target gNB 30 via the second SRB1 (or the third SRB1), if configured. Otherwise, UE 10 can send the first MAC PDU including RRCReconfiguationComplete to the target gNB 30 via the first SRB1. This transmission can be done as a part of the random access procedure (e.g Message 3 transmission or HARQ ACK). Solution 3 The source gNB 20 can check whether UE 10 has the capability about the fourth MAC PDU by UE Information Request and UE Information Response for UE Capability. When the source gNB 20 decides a handover is required, the source gNB 20 (or Cell) can ask the target gNB 30 (or Cell) about whether it has the capability about the fourth MAC PDU via Xn message. The target gNB 30 can respond to this with a indication via Xn message, e.g. Yes or No (ACK or NACK). After that, the source gNB 20 can send the handover command with the fourth MAC PDU to UE 10. When the UE 10 receives the handover command, the UE can reply to the source cell 20 by sending HARQ ACK or the fourth MAC PDU to the source cell 20, in order to let the source cell 20 know about the successful reception. In another embodiment, UE 10 can reply to the target gNB 30 (or cell) by sending the fourth MAC PDU to the target cell 30, in order to let the target cell 30 know about the successful handover and complete the handover. In another embodiment, UE 10 can check the availability of the fourth MAC PDU for the target gNB 30 (or Cell) in system information (broadcasted as indicator), and then UE 10 can use it for the target cell 30. To complete handover, the UE 10 can send the fourth MAC PDU (or the third MAC PDU) indicating handover completion to the target gNB 30 (or cell), if configured. In another embodiment, the UE 10 can perform a random access procedure to the target cell 30, in order to let the target cell 30 know about the successful handover and complete the handover, with the fourth MAC PDU (or the third MAC PDU). This transmission can be done as a part of the random access procedure (e.g Message 3 transmission or HARQ ACK). In another embodiment, the networks send the fourth MAC PDU indicating Pcell change with the new field (i.e. security-protected MAC CE) to the UE 10 while the UE can respond to it by sending the fourth MAC PDU acknowledging it without the new field (normal MAC CE) (to the source cell 20 or the target cell 30) in order to reduce the size of transmitted MAC PDU. Solution 4 The source gNB 20 can check whether UE 10 has the capability about the fourth MAC PDU (i.e. MAC CE based PCell change functionality) by UE Information Request and UE Information Response for UE Capability. When the source gNB 20 decides a handover is required, the source gNB 20 (or Cell) can ask the target gNB 30 (or Cell) about whether it has the capability about the fourth MAC PDU (i.e. MAC CE based PCell change functionality) via Xn message. The target gNB 30 can respond to this with an indication via Xn message, e.g. Yes or No (ACK or NACK). After that, the source gNB 20 can send the first MAC CE as the handover command (i.e. the fourth MAC PDU) to UE 10. When the UE 10 receives the first MAC CE (i.e. the handover command), the UE can reply to the source cell 20 by sending HARQ ACK in order to let the source cell 20 know about the successful reception. Specifically, the source gNB 20 can send a UE the first MAC CE with an indicator indicating the target cell (or the target cell configuration) for PCell change, instead of transmitting RRCReconfiguration message with reconfigurationiWithSync indicating PCell change. The target cell identity or target cell configuration indicated by the first MAC CE can be (pre-) configured (e.g. by RRCReconfiguration message) via SRB1 before the transmission of the first MAC CE. When UE receives the first MAC CE with an indicator indicating the target cell (or the target cell configuration), UE applies the indicated target cell configuration and performs PCell change (i.e cell switch procedure). UE can also indicate the MAC layer’s reception of the first MAC CE (or the execution of PCell change) to the RRC layer so the RRC layer can apply the target cell configuration or generate RRCReconfigurationComplete message. The PCell switch procedure includes the random access procedure towards the target cell triggered by the UE. If a time alignment timer is not running for the target cell (i.e. time alignment between UE’s uplink and the network (i.e. the target cell)) or a timing advance value (TA value) for the target cell is not valid or the timing advance value for the target cell is not indicated in the first MAC CE, UE can perform a random access procedure towards the target cell to get a valid TA value. During the random access procedure, UE can transmit RRCReconfigurationComplete message to the target cell. If a time alignment timer is running for the target cell or a timing advance value (TA value) for the target cell is valid or the timing advance value for the target cell is indicated in the first MAC CE, UE does not trigger a random access procedure (i.e. skip the random access procedure) and UE can transmit RRCReconfigurationComplete message by using available radio resources (e.g. configured grants or PDCCH-indicated resources from the target cell). In this way, the network can transmit the first MAC CE to UE to trigger a PCell change with reduced overhead (i.e. for coverage enhancement and fast control message processing (as the MAC CE is very small)) and UE can complete the PCell change by sending RRCReconfigurationComplete message to the target cell. In the legacy procedure, the network (the source gNB) transmits RRCReconfiguration with reconfigurationWithSync indicator to trigger a PCell change and UE completes the PCell change by sending the RRCReconfigurationComplete messasge to the target cell, which incurs more overhead and ends up reducing the coverage. As the size of RRC message is much larger than the size of MAC CE, the replacement of a large RRC message with a small MAC CE can be applied to the certain cases described in this invention. In another embodiment, UE 10 can reply to the target gNB 30 (or cell) by sending the fourth MAC PDU (e.g. RRCReconfigurationComplete messasge ) to the target cell 30, in order to let the target cell 30 know about the successful handover and complete the handover. In another embodiment, UE 10 can check the availability of the fourth MAC PDU (e.g. the first MAC CE or MAC CE based PCell change functionality) for the target gNB 30 (or Cell) in system information (broadcasted as indicator), and then UE 10 can use it for the target cell 30. To complete handover, the UE 10 can send the fourth MAC PDU (or the third MAC PDU) indicating handover completion (e.g. RRCReconfigurationComplete message or a newly defined MAC CE) to the target gNB 30 (or cell), if configured. In another embodiment, the UE 10 can perform a random access procedure to the target cell 30, in order to let the target cell 30 know about the successful handover and complete the handover, with the fourth MAC PDU (or the third MAC PDU). This transmission can be done as a part of the random access procedure (e.g Message 3 transmission or HARQ ACK). In another embodiment, the networks send the fourth MAC PDU indicating Pcell change with the new field (i.e. security-protected MAC CE) to the UE 10 while the UE can respond to it by sending the fourth MAC PDU acknowledging it without the new field (normal MAC CE) (to the source cell 20 or the target cell 30) in order to reduce the size of transmitted MAC PDU. Further technical enhancements When the second MAC PDU (or the second SRB1) or the third MAC PDU (or the third SRB1) or the fourth MAC PDU are applied to each of the aforementioned cases in orderto reduce the size of actual transmitted MAC PDU, then: • the number of HARQ retransmission for the MAC PDU can be configured with a large number (or infinity) to guarantee its successful delivery because TM RLC entity and MAC entity has no such functionality as ARQ, while ARQ mechanism of AM RLC entity can guarantee the successful delivery. In another embodiment, UE 10 or the network can keep HARQ retransmission for the MAC PDU until the HARQ ACK for the MAC PDU is received; • if the HARQ retransmission fails (or the number of HARQ retransmission reaches the configured threshold or beyond it, or the HARQ NACK is received and HARQ ACK has not received for the MAC PDU) or the network (or UE or MAC entity) concludes that the successful delivery of the MAC PDU fails, the MAC entity can indicate this to the RRC layer so that the RRC layer sends the first MAC PDU via the first SRB1. In another embodiment, a timer can be introduced to determine the successful delivery of the MAC PDU (the timer starts at the transmission of the second MAC PDU(or the third MAC PDU), stops upon the confirmation of successful delivery, and the RRC layer sends the first MAC PDU via the first SRB1 at the expiry of the timer); • the network or the UE 10 should guarantee the successful delivery of the second MAC PDU (or the third MAC PDU or the fourth MAC PDU). To enable the above, one or more of: a separate HARQ process; a HARQ Identity; or HARQ parameters can be introduced. Continued, Further technical enhancements for Solutions When the fourth MAC PDU is applied to each of the aforementioned cases in order to reduce the size of actual transmitted MAC PDU, the Integrity verification failure can be detected or can happen from the new field if the fourth MAC PDU is security protected and includes the new field (Digital Signature or MAC-I). Therefore, embodiments also deal with how to handle integrity verification failure in MAC entity. If integrity verification fails or the new field is not successfully decoded or an error for the new field is detected in the MAC entity or PDCP entity, then several options are available: Option 1: The MAC entity detects and indicates it to an upper layer (e.g. RRC layer). Based on this indication, the RRC layer can perform RRC Re-establishment procedure, (e.g. UE can do this) Option 2: The MAC entity generates a new MAC CE (or HARQ NACK) indicating the integrity verification failure and sends it to the source cell 20 to let the source cell know about the failure (or the error). Based on this, the source cell 20 can perform retransmission of the fourth MAC PDU or generate a new fourth MAC PDU indicating a new Pcell change and send it to UE 10 or fallback to the normal handover (i.e. send the first MAC PDU via the first SRB1 for a new handover command). Option 3: When the integrity protection and verification mechanism in PDCP is reused (i.e. MAC-I is used as the new field) and the first or second process is performed, the PDCP entity detects and indicates it to an upper layer (e.g. RRC layer). Based on this indication, the RRC layer can perform RRC Re-establishment procedure, (e.g. UE can do this). The aforementioned SRBs, MAC PDUs, Solutions, and technical enhancements can be extended (or applied) to the other cases and the corresponding RRC messages with revision accordingly as set out here: Case 3: When the UE 10 performs SCG addition or change (i.e. PSCell change), e.g. SCG addition (PSCell addition) or intra-SCG change (Change to another cell of the same SCG) or inter-SCG change (Change to a cell of the different SCG); RRCReconfiguration, RRCReconfigurationComplete to the target cell, Case 4: When UE performs RRC Re-establishment according to one of many RRC Reestablishment cause; RRCReestablishmentRequest to the previous cell (or new cell), RRCReestablishment, RRCReestablishmentComplete. Alternatively, newly defined RRC messages can be configured for Cases 1,2, 3, and 4 The proposed structure for SRB1 can be extended to other SRBs (SRB2 or SRB3 or SRB4) or can be defined as a new SRB (e.g. SRBx) As can be seen from the foregoing, embodiments of the invention provide improved techniques to reduce the size of RRC messaging and hence improve the coverage. At least some of the example embodiments described herein may be constructed, partially or wholly, using dedicated special-purpose hardware. Terms such as ‘component’, ‘module’ or ‘unit’ used herein may include, but are not limited to, a hardware device, such as circuitry in the form of discrete or integrated components, a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC), which performs certain tasks or provides the associated functionality. In some embodiments, the described elements may be configured to reside on a tangible, persistent, addressable storage medium and may be configured to execute on one or more processors. These functional elements may in some embodiments include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Although the example embodiments have been described with reference to the components, modules and units discussed herein, such functional elements may be combined into fewer elements or separated into additional elements. Various combinations of optional features have been described herein, and it will be appreciated that described features may be combined in any suitable combination. In particular, the features of any one example embodiment may be combined with features of any other embodiment, as appropriate, except where such combinations are mutually exclusive. Throughout this specification, the term “comprising” or “comprises” means including the component(s) specified but not to the exclusion of the presence of others. Attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. 5 Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features. 10 The invention is not restricted to the details of the foregoing embodiment(s). The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed. 15 24 03 25

Claims

1. A method of performing a PCell change by a transmitting device, configured with at least one target cell configuration by RRCReconfiguration in a wireless communication system, the method comprising:5receiving a MAC Control Element (CE) that includes an indicator, indicating the at least one target cell configuration;performing a PCell change execution to the target cell by applying the at least one target cell 10 configuration and sending RRCReconfigurationComplete to the at least one target cell.

2. The method of claim 1 wherein the transmitting device is a User Equipment, UE.

3. The method of claim 1 or 2 wherein control messages are transmitted via Signalling RadioBearer 1, SRB1.15 4. The method of any preceding claim wherein the network provides a plurality of SRBconfigurations for the transmitting device, said plurality of configurations comprising one or more of:- SRB with RLC-AM(Acknowledged Mode) entity configuration;- SRB with RLC-TM(Transparent Mode) entity configuration for RRC message transmission with 20 reduced overhead;- SRB with RLC-UM(Unacknowledged Mode) entity configuration for RRC message transmission with reduced latency;- SRB with two RLC-AM entities, one RLC-AM entity for one cell and the other RLC-AM entity for the other cell (i.e. split SRB for carrier aggregation (CA), which can be used for packet 25 duplication to enhance the reliability);- SRB with two RLC-AM entities, one RLC-AM entity for one cell group (e.g. MCG) and the other RLC-AM entity for the other cell group (e.g. SCG) (i.e. split SRB for dual connectivity (DC), which can be used for packet duplication to enhance the reliability);- SRB with two RLC entities, one RLC-AM entity for reliable transmission and the RLC-UM entity 30 for RRC message transmission with reduced latency; and- SRB with two RLC entities, one RLC-AM entity for reliable transmission and the RLC-TM entity for RRC message transmission with reduced overhead (i.e. split SRB for coverage enhancement with overhead reduction).

5. The method of any preceding claim wherein a source cell checks if a transmitting device35 has capability relating to a Fourth MAC PDU by means of UE Information Request and UE Information Response.

6. The method of claim 5 wherein the source cell checks if the target cell has capability relating to the Fourth MAC PDU via Xn message.

7. Apparatus arranged to perform the method of any preceding claim.24 03 25

Images