Patent Description:
After deployment of 4th generation mobile communication networks, researches about 5th generation mobile communication are carried out to address the issue of data traffic increase. In a 5th mobile communication deployment scenario, access to a 5th mobile communication network based on a 4th mobile communication network may be supported. For example, an electronic device may be simultaneously connected to a plurality of cells, which may be associated with different RATs.

In a 5th mobile communication system, an electronic device may communicate with a base station based on a specified protocol stack. For example, the specified protocol stack may include service data adaptation protocol (SDAP), packet data convergence protocol (PDCP), radio link control (RLC), medium access control (MAC), and physical (PHY) layers. At least one data radio bearer (DRB) or signaling radio bearer (SRB) may be established to transfer user plane packets between the electronic device and the base station.

Main functions of the SDAP may include at least one of a function of transfer of user plane data, a function of mapping between a quality of service (QoS) flow and a DRB for both downlink (DL) and uplink (UL), a function of marking QoS flow ID in both DL and UL packets, and/or a function of reflective QoS flow to DRB mapping for UL SDAP PDUs. For example, with regard to the SDAP layer device, the electronic device may be configured by an RRC message with respect to whether to use a header of the SDAP layer device or use a function of the SDAP layer device for each PDCP layer device, each bearer, or each logical channel. When the SDAP header is configured, the SDAP layer device may instruct the electronic device to update or reconfigure mapping information about a QoS flow and data bearer of uplink and downlink, using a NAS reflective QoS configuration <NUM>-bit indicator and AS reflective QoS configuration <NUM>-bit indicator. The SDAP header may include QoS flow ID information indicating QoS. The QoS information may be used in data processing priority for supporting a smooth service and/or scheduling information.

Main functions of a PDCP device may include at least one of a function of header compression and decompression (e.g., robust header compression (ROHC) only), a function of transfer of user data, a function of in-sequence delivery of upper layer protocol data units (PDUs), a function of out-of-sequence delivery of upper layer PDUs, a function of PDCP PDU reordering for reception, a function of duplicate detection of lower layer service data units (SDUs), a function of retransmission of PDCP SDUs, a function of ciphering and deciphering, and/or a function of timer-based SDU discard in uplink. The reordering function of the PDCP device may be referred to as a function of reordering PDCP PDUs received in a lower layer based on a PDCP sequence number (SN). The reordering function may include a function of delivering data to an upper layer in reordered sequence, a function of delivering data to an upper layer without considering an order, a function of recording missing PDCP PDUs by reordering a sequence, a function of sending a state report about missing PDCP PDUs to a transmission side, and/or a function of requesting retransmission of missing PDCP PDUs.

Main functions of an RLC device may include a function of transfer of data of upper layer PDUs, a function of in-sequence delivery of upper layer PDUs, a function of out-of-sequence delivery of upper layer PDUs, a function of error correction through automatic repeat request (ARQ), a function of concatenation, segmentation, and reassembly of RLC SDUs, a function of re-segmentation of RLC data PDUs, a function of reordering of RLC data PDUs, a function of duplicate detection, a function of protocol error detection, a function of RLC SDU discard, and/or a function of RLC re-establishment. The function of in-sequence delivery of the RLC device may be referred to as a function of delivering RLC SDUs received from a lower layer to an upper layer in sequence. The function of in-sequence delivery may include a function of reassembling and delivering multiple RLC SDUs if a single RLC SDU is received after being segmented into the multiple RLC SDUs, a function of reordering received RLC PDUs based on an RLC sequence number (SN) or PDCP SN, a function of recording missing RLC PDUs by reordering a sequence, a function of sending a state report about missing RLC PDUs to a transmission side, a function of requesting retransmission of missing RLC PDUs, a function of delivering, to an upper layer, only RCL SDUs prior to missing RLC SDUs in sequence if there are missing RCL SDUs, a function of delivering, if a prescribed timer expires, all RLC SDUs received before the timer expires to an upper layer in sequence even if there are missing RLC SDUs, and/or a function of delivering, if a prescribed timer expires, all RLC SDUs received up to the present time to an upper layer in sequence even if there are missing RLC SDUs. Furthermore, the RLC device may process RLC PDUs in the order in which the RLC PDUs are received (e.g., in the order of arrival regardless of an order of sequence numbers) and deliver the RLC PDUs to a PDCP device out of sequence. If received data is segmented data, the RLC layer may receive segments stored in a buffer or to be received later and may reconstruct the segments as a single complete RLC PDU, and, thereafter, may process and deliver the RLC PDU to a PDCP device. The RLC device may not include a concatenation function. The concatenation function may be performed in a MAC layer or may be replaced with a multiplexing function of a MAC layer. The function of out-of-sequence delivery of the RLC device may be referred to as a function of out of sequence delivering RLC SDUs received from a lower layer to an upper layer. The function of out-of-sequence delivery may include a function of reassembling and delivering multiple RLC SDUs if a single RLC SDU is received after being segmented into the multiple RLC SDUs and/or a function of recording missing RLC PDUs by storing and ordering RLC SN or PDCP SN of received RLC PDUs.

A MAC device may be connected to multiple RLC layer devices configured in one terminal. For example, main functions of the MAC may include at least one of a function of mapping between logical channels and transport channels, a function of multiplexing/demultiplexing of MAC SDUs, a function of scheduling information reporting, a function of error correction through hybrid ARQ (HARQ), a function of priority handling between logical channels of one user equipment, a function of priority handling between UEs by means of dynamic scheduling, a function of multimedia broadcast/multicast service (MBMS) service identification, a function of transport format selection, and/or a function of padding.

A PHY layer may channel code and modulate data of an upper layer and render the data into an orthogonal frequency division multiplexing (OFDM) symbol to transmit the OFDM symbol by wireless channel, or may demodulate and channel decode an OFDM symbol received through a wireless channel and deliver the OFDM symbol to an upper layer. Document (<CIT>) discloses a conventional packet retransmission method in a wireless communication system and document (<CIT>) discloses prioritizing packet transmission method for TCP packets.

In the case of handing over an electronic device to another cell supporting the same RAT as a currently connected cell, this handover may be referred to as an intra-RAT handover. In the case of handing over an electronic device to another cell supporting an RAT different from that of a currently connected cell, this handover may be referred to as an inter-RAT handover.

When the electronic device performs the intra-RAT handover, information of ROHC or security key used in a PDCP layer may be changed. In this case, data transmitted by the electronic device using the security key or ROHC information of a source cell before the handover may not be successfully received in a target cell after the handover. Therefore, some PDCP SDUs may be discarded without being transmitted to the target cell after the handover.

When the electronic device performs the inter-RAT handover, the electronic device may transmit from a first PDCP service data unit (SDU) that was not transmitted to the source cell before the handover to the target cell after the handover. For example, when the electronic device operates in an unacknowledged mode (UM), the electronic device may not be aware of whether data transmitted to the source cell before the handover has been successfully received by the source cell. For another example, when the electronic device operates in an acknowledged mode (AM), although the electronic device has transmitted the data in a PDCP layer, the electronic device may fail to receive an acknowledgement of the data in a lower layer (e.g., RLC layer or MAC layer).

In 5th generation mobile communication that supports multi-RAT simultaneous connection, a change may occur in PDCP due to a handover of an electronic device. Therefore, if appropriate data transmission is not performed according to a change in PDCP, data throughput may deteriorate due to data loss.

Various embodiments of the present disclosure may provide an electronic device supporting a data transmission method based on a change in PDCP.

The scope of invention is defined by the appended claims.

An electronic device according to an embodiment of the present disclosure include: at least one wireless communication circuit configured to provide a first radio access technology (RAT) and a second RAT, a processor operatively connected to the at least one wireless communication circuit, and a memory operatively connected to the processor. Said memory stores instructions that, when executed, cause the processor to: transmit at least a portion of a plurality of first data packets based on a first packet data convergence protocol, PDCP, detect a PDCP change from the first PDCP to a second PDCP by detecting a change in a PDCP version or in a PDCP key by detecting a change between new radio, NR, PDCP and evolved universal mobile communication system terrestrial radio access, E-UTRA, PDCP, identify, in response to the detected PDCP change, at least one first data packet that is delivered from a PDCP layer to lower layer and not transmitted to a physical layer, and when a transmission protocol of the at least one first data packet is a user datagram protocol, UDP, determine reprocess the at least one first data packet by: storing the at least one first data packet in a buffer, changing at least portion of the first data packet to at least one second data packet related to the second PDCP by removing at least one first packet header from the at least one first data packet and adding at least one second packet header to the at least one first data packet from which the at least one first packet header has been removed, and transmitting the at least one second data packet.

A data transmission method of an electronic device according to an embodiment of the present disclosure may include: transmitting at least a portion of a plurality of first data packets based on a first packet data convergence protocol, PDCP, detecting a PDCP change from the first PDCP to a second PDCP by detecting a change between new radio, NR, PDCP and evolved universal mobile communication system terrestrial radio access, E-UTRA, PDCP, in response to the detected PDCP change, at least one first data packet that is delivered from a PDCP layer to a lower layer and not transmitted to a physical layer, when a transmission protocol of the at least one first data packet is a user datagram protocol, UDP, determining to reprocess the at least one first data packet, and reprocessing the at least one first data packet. The reprocessing comprises storing the at least one first data packet in a buffer, removing at least one first packet header from the at least one first data packet, creating at least one second data packet related to the second PDCP by adding at least one second packet header to the at least one first data packet from which the at least one first packet header has been removed, and transmitting the at least one second data packet.

According to various embodiments of the present disclosure, deterioration of service performance may be prevented through re-processing or retransmission of an unprocessed packet due to a change of PDCP.

According to various embodiments of the present disclosure, overall data throughput of a communication network may be increased by preventing dropping of a data packet.

Besides, various effects may be provided that are directly or indirectly identified through the present disclosure.

With regard to descriptions of the drawings, the same or similar reference numerals may be used for the same or similar components.

Hereinafter, various embodiments of the present disclosure will be described with reference to the accompanying drawings.

The electronic device described in relation with <FIG> is not according to the invention and are present for illustration purposes only.

As used herein, each of such phrases as "A or B", "at least one of A and B", "at least one of A or B", "A, B, or C", "at least one of A, B, and C", and "at least one of A, B, or C" may include any one of, or all possible combinations of the items enumerated together in a corresponding one of the phrases. As used herein, such terms as "1st" and "2nd", or "first" and "second" may be used to simply distinguish a corresponding component from another, and does not limit the components in other aspect (e.g., importance or order). It is to be understood that if an element (e.g., a first element) is referred to, with or without the term "operatively" or "communicatively", as "coupled with", "coupled to", "connected with", or "connected to" another element (e.g., a second element), it means that the element may be coupled with the other element directly (e.g., wiredly), wirelessly, or via a third element.

<FIG> illustrates wireless communication systems that provide networks of legacy communication and/or <NUM> communication. The wireless communication systems described in relation with <FIG> are not according to the invention and are present for illustration purposes only.

Referring to <FIG>, network environments 100A, 100B, and 100C may include at least one of a legacy network or a <NUM> network. The legacy network may include, for example, a <NUM> or LTE base station <NUM> (e.g., eNodeB (eNB)) of a 3rd Generation Partnership Project (3GPP) standard supporting a wireless connection with an electronic device <NUM> and an evolved packet core (EPC) <NUM> for managing <NUM> communication. The <NUM> network may include, for example, a new radio (NR) base station <NUM> (e.g., gNodeB (gNB)) supporting a wireless connection with the electronic device <NUM> and a 5th generation core (5GC) <NUM> for managing <NUM> communication of the electronic device <NUM>.

Tthe electronic device <NUM> may transmit/receive a control message and user data through legacy communication and/or <NUM> communication. The control message may include, for example, a message related to at least one of security control, bearer setup, authentication, registration, or mobility management of the electronic device <NUM>. The user data may represent, for example, user data except for the control message transmitted/received between the electronic device <NUM> and a core network <NUM> (e.g., EPC <NUM>).

Referring to reference number 200A, the electronic device <NUM> transmit/receive at least one of a control message or user data to/from at least a portion (e.g., NR base station <NUM>, 5GC <NUM>) of a <NUM> network using at least a portion (e.g., LTE base station <NUM>, EPC <NUM>) of a legacy network.

The network environment 100A may include a network environment, in which multi-radio access technology (RAT) dual connectivity (MR-DC) to the LTE base station <NUM> and the NR base station <NUM> is provided, and a control message is transmitted/received to or from the electronic device <NUM> through the core network <NUM> of one of the EPC <NUM> and the 5GC <NUM>.

In an MR-DC environment, one of the LTE base station <NUM> and the NR base station <NUM> may operate as a master node (MN) <NUM>, and the other may operate as a secondary node (SN) <NUM>. The MN <NUM> may be connected to the core network <NUM> so as to transmit/receive a control message. The MN <NUM> and the SN <NUM> may be connected through a network interface so as to transmit/receive a message related to a radio resource (e.g., communication channel) to/from each other.

The MN <NUM> may be configured as the LTE base station <NUM>, the SN <NUM> may be configured as the NR base station <NUM>, and the core network <NUM> may be configured as the EPC <NUM>. For example, a control message may be transmitted/received through the LTE base station <NUM> and the EPC <NUM>, and user data may be transmitted/received through the LTE base station <NUM> and the NR base station <NUM>.

Referring to reference number 200B, a <NUM> network may transmit/receive a control message and user data independently of the electronic device <NUM>.

Referring to reference number 200C, a legacy network and <NUM> network may provide data transmission/reception independently of each other. For example, the electronic device <NUM> and the EPC <NUM> may transmit/receive a control message and user data through the LTE base station <NUM>. For another example, the electronic device <NUM> and the 5GC <NUM> may transmit/receive a control message and user data through the NR base station <NUM>.

The electronic device <NUM> may be registered in at least one of the EPC <NUM> or the 5GC <NUM> so as to transmit/receive a control message.

The EPC <NUM> or the 5GC <NUM> may manage communication of the electronic device <NUM> via an interworking. For example, movement information of the electronic device <NUM> may be transmitted/received through an interface between the EPC <NUM> and the 5GC <NUM>.

<FIG> illustrates protocol stack structures of a network and electronic device. The protocol stack structures described in relation with <FIG> are not according to the invention and are present for illustration purposes only.

In a mobile communication system, a base station may communicate with a terminal (e.g., the electronic device <NUM> of <FIG>) by selectively using an evolved universal mobile telecommunication system (UMTS) terrestrial radio access (E-UTRA) communication protocol (or LTE communication protocol) and a new radio (NR) communication protocol. For example, the base station and the terminal may communicate using the E-UTRA communication protocol or the NR communication protocol. The base station and the terminal may communicate in an MR-DC network environment (e.g., the network environment 100A of <FIG>). In this case, for example, the base station and the terminal may interchangeably use at least a portion of the E-UTRA communication protocol and at least a portion of the NR communication protocol. For example, the terminal may use different communication protocols for each layer.

In the embodiments described below, an E-UTRA protocol stack may be referred to as a first communication protocol stack or a first protocol stack. The first protocol or first communication protocol may be referred to as an E-UTRA protocol (or LTE protocol). In the embodiments described below, an NR protocol stack may be referred to as a second communication protocol stack or a second protocol stack. The second protocol or second communication protocol may be referred to as an NR protocol. For example, the electronic device <NUM> may execute the first communication protocol stack and the second communication protocol stack using at least one communication processor (e.g., the wireless communication module <NUM> of <FIG>) included in the electronic device <NUM>.

The first communication protocol stack and the second communication protocol stack may include a control plane protocol for transmitting/receiving a control message and a user plane protocol for transmitting/receiving user data. The control message may include, for example, a message related to at least one of security control, bearer setup, authentication, registration, or mobility management. The user data may include, for example, data except for the control message.

The control plane protocol and the user plane protocol may include physical (PHY), medium access control (MAC), radio link control (RLC), or packet data convergence protocol (PDCP) layers. The PHY layer, for example, may channel code and modulate data received from an upper layer (e.g., MAC layer) to transmit the data by a wireless channel, and may demodulate and decode data received through a wireless channel to deliver the data to an upper layer. The PHY layer included in the second communication protocol stack may further perform an operation related to beam forming. The MAC layer, for example, may logically/physically map to a wireless channel through which data is to be transmitted/received, and may perform hybrid automatic repeat request (HARQ) for error correction. The RLC layer, for example, may concatenate, segment, or reassemble data, and may check an order of data, reorder data, or check duplication of data. The PDCP layer, for example, may further perform an operation related to data integrity and ciphering of a control message and user data. The second communication protocol stack may further include a service data adaptation protocol (SDAP). The SDAP, for example, may manage radio bearer allocation based on quality of service (Qos) of user data.

The control plane protocol may include a radio resource control (RRC) layer and a non-access stratum (NAS) layer. The RRC layer, for example, may process a control message related to radio bearer setup, paging, or mobility management. The NAS, for example, may process a control message related to authentication, registration, and/or mobility management.

Referring to <FIG>, the protocol stack of the electronic device <NUM> may include at least one of an E-UTRA/NR PDCP <NUM>, NR PDCP <NUM>, NR PDCP <NUM>, E-UTRA RLC <NUM>, E-UTRA RLC <NUM>, NR RLC <NUM>, NR RLC <NUM>, E-UTRA MAC <NUM>, and/or NR MAC <NUM>. For example, a master node (MN) <NUM> (e.g., the master node <NUM> of <FIG>) may include at least one of an E-UTRA/NR PDCP <NUM>, NR PDCP <NUM>, NR PDCP <NUM>, E-UTRA RLC <NUM>, E-UTRA RLC <NUM>, E-UTRA RLC <NUM>, E-UTRA RLC <NUM>, and/or E-UTRA MAC <NUM>. For example, a secondary node (SN) <NUM> (e.g., the secondary node <NUM> of <FIG>) may include an NR PDCP <NUM>, NR PDCP <NUM>, NR PDCP <NUM>, NR RLC <NUM>, NR RLC <NUM>, NR RLC <NUM>, NR RLC <NUM>, and NR MAC <NUM>.

For example, the electronic device <NUM> may communicate with the MN <NUM> using a master cell group (MCG) bearer, and may communicate with the SN <NUM> using a secondary cell group (SCG) bearer. In this case, a protocol stack of the electronic device <NUM> associated with the MCG bearer may include an E-UTRA protocol stack (e.g., E-UITRA/NR PDCP <NUM>, E-UTRA RLC <NUM>, and E-UTRA MAC <NUM>). A protocol stack of the electronic device <NUM> associated with the SCG bearer may include an NR protocol stack (e.g., NR PDCP <NUM>, NR RLC <NUM>, and NR MAC <NUM>).

For another example, the electronic device <NUM> may communicate with the MN <NUM> and the SN <NUM> using a split bearer (e.g., MCG split bearer or SCG split bearer). In this case, a protocol stack of the electronic device <NUM> associated with the split bearer may include the NR PDCP <NUM>, E-UTRA RLC <NUM>, NR RLC <NUM>, E-UTRA MAC <NUM>, and NR MAC <NUM>. In the case of the split bearer, the electronic device <NUM> may use an NR protocol stack (e.g., NR PDCP <NUM>) in a PDCP layer, but may use an E-UTRA protocol stack (e.g., E-UTRA RLC <NUM>) in a lower layer (e.g., RLC/MAC/PHY). In this case, the NR PDCP <NUM> may separate and/or aggregate data received through the split bearer and deliver the data to the E-UTRA RLC <NUM> or NR RLC <NUM>.

For another example, the electronic device <NUM> may communicate with the SN <NUM> using a secondary node (SN) terminated MCG bearer. In this case, the electronic device <NUM> may use an NR protocol stack (e.g., E-UTRA/NR PDCP <NUM>) in a PDCP layer, but may use an E-UTRA protocol stack (e.g., E-UTRA RLC <NUM> and E-UTRA MAC <NUM>) in RLC and MAC layers.

For another example, the electronic device <NUM> may communicate with the MN <NUM> using a master node (MN) terminated SCG bearer. In this case, the electronic device <NUM> may include an NR protocol stack (e.g., NR PDCP <NUM>, NR RLC <NUM>, and NR MAC <NUM>) in PDCP, RLC, and MAC layers.

As described in the above-mentioned examples, various types of bearers (e.g., MCG bearer, SCG bearer, MCG split bearer, SCG split bearer, MN terminated SCG bearer, and/or SN terminated MCG bearer) may be used in communication between the electronic device <NUM> and each node (e.g., MN <NUM> and/or SN <NUM>). In this communication environment, the type of a bearer used in communication of the electronic device <NUM> may be changed. For example, the electronic device <NUM> may move from a first cell that supports EN-DC to a second cell that does not support EN-DC. In this case, the electronic device <NUM>, according to a change of a cell type, may change a bearer type to a bearer that differs in type from a bearer configured based on an EN-DC environment. For another example, the electronic device <NUM> may use a bearer based on the NR PDCP <NUM> supporting EN-DC. In this case, the type of a bearer associated with the electronic device <NUM> may be changed according to determination of a network. The type of a bearer associated with the electronic device <NUM> may be changed from a bearer based on the NR PDCP <NUM> to a bearer based on the E-UTRA PDCP <NUM>.

<FIG> illustrates a data processing flow between network protocol stacks according to an embodiment.

The type of a bearer may be changed since a base station with which an electronic device (e.g., the electronic device <NUM> of <FIG>) communicates is changed due to movement of the electronic device <NUM>.

According to an embodiment, the electronic device <NUM> may perform Internet communication associated with an external electronic device (e.g., the server <NUM> of <FIG>) using an Internet protocol (e.g., TCP, UDP, IP). For example, the electronic device <NUM> may process data according to an Internet protocol in a main processor (e.g., the main processor <NUM> of <FIG>) included in the electronic device <NUM>. For example, the electronic device <NUM> may process transmission data according to an Internet protocol. The electronic device <NUM> may process the transmission data (e.g., IP packet) processed according to an Internet protocol, according to the type of a bearer associated with the electronic device <NUM>.

For example, a PDCP associated with a bearer is changed according to a change of the type of the bearer associated with the electronic device <NUM>. When the electronic device <NUM>, during MR-DC operation, moves to an LTE base station eNB not supporting MR-DC or moves to a cell controlled by MME not supporting MR-DC, a PDCP version (e.g., E-UTRA PDCP <NUM> (e.g., E-UTRA/NR PDCP <NUM>)) used in the bearer associated with the electronic device <NUM> is changed. When the electronic device <NUM> connected only to an LTE cell moves to a cell supporting MR-DC, the type of the bearer may be changed to a split bearer or SCG bearer. Therefore, in network deployment in which multiple RATs are present, a change of PDCP may occur since the type of a bearer associated with the electronic device <NUM> is changed due to movement of the electronic device <NUM>. Since the types of various bearers are changed, a protocol stack for the electronic device <NUM> to process data associated with a bearer is also changed. As a protocol stack is changed, there may be a packet that is lost without being processed in layer <NUM> (e.g., physical layer) and/or layer <NUM> (e.g., PDCP layer <NUM>, RLC layer <NUM>, and/or MAC layer <NUM>).

For example, the electronic device <NUM> may communicate with an MN (e.g., the MN <NUM> of <FIG>) using an MCG bearer. In this case, the electronic device <NUM> may process pieces of transmission data according to an E-UTRA protocol using the E-UTRA PDCP <NUM> in the PDCP layer <NUM>. For example, the electronic device <NUM> may use a plurality of IP packets of the transmission data as PDCP SDUs. The electronic device <NUM>, in the PDCP layer <NUM>, may generate a PDCP PDU by adding an E-UTRA PDCP header to a PDCP SDU, and may deliver the generated PDCP PDU to the RLC layer <NUM>. The electronic device <NUM>, in the RLC layer <NUM>, may concatenate a plurality of PDCP PDUs based on an amount of uplink resources allocated using the E-UTRA RLC <NUM> and may add an E-UTRA RLC header to thereby generate an RLC PDU, and may deliver the generated RLC PDU to the MAC layer <NUM>. The electronic device <NUM>, in the MAC layer <NUM>, may generate a MAC PDU by adding a MAC header to an RLC PDU using the E-UTRA MAC <NUM>, and may deliver the generated MAC PDU to a lower layer (e.g., PHY layer (not shown)).

For example, the electronic device <NUM> may communicate with an SN (e.g., the SN <NUM> of <FIG>) using an SCG bearer. In this case, the electronic device <NUM> may process pieces of transmission data according to an NR protocol using the NR PDCP <NUM> in the PDCP layer <NUM>. For example, the electronic device <NUM> may use a plurality of IP packets of the transmission data as PDCP SDUs. The electronic device <NUM>, in the PDCP layer <NUM>, may generate a PDCP PDU by adding an NR PDCP header to a PDCP SDU, and may deliver the generated PDCP PDU to the RLC layer <NUM>. The electronic device <NUM>, in the RLC layer <NUM>, may generate RLC PDUs by adding an RLC header to each of a plurality of RLC SDUs using the NR RLC <NUM>, and may deliver the generated RLC PDUs to the MAC layer <NUM>. The electronic device <NUM>, in the MAC layer <NUM>, may generate a MAC PDU by concatenating RLC PDUs based on uplink resources allocated using the E-UTRA MAC <NUM> and then adding a MAC header, and may deliver the generated MAC PDU to a lower layer (e.g., PHY layer (not shown)).

In the data processing flow according to a bearer type according to various embodiments, the type of a bearer associated with the electronic device <NUM> is changed. In the example of <FIG>, for example, the bearer type may be changed to an SCG bearer. In this case, at least a portion of data has been processed in association with the MCG bearer, but pieces of the data that were not transmitted may be lost. According to various embodiments of the present disclosure, the electronic device <NUM> may prevent data loss due to a change of a bearer type. For example, in the example of <FIG>, the bearer associated with the electronic device <NUM> may be changed from the MCG bearer to the SCG bearer. For example, when there is a PDCP SDU of data that may be lost, the electronic device <NUM> may process the PDCP SDU using the NR PDCP <NUM>. For another example, when data corresponding to data that may be lost is present in a lower layer (e.g., RLC layer <NUM>, MAC layer <NUM>, PHY layer (not shown)) of the PDCP layer <NUM>, the electronic device <NUM> may obtain a PDCP SDU from data of the lower layer, and may process the PDCP SDU using the NR PDCP <NUM>. For another example, when a PDCP SDU of data that may be lost is not present, and is not present also in the lower layer of the PDCP layer <NUM>, the electronic device <NUM> may retransmit transmission data according to a network protocol corresponding to the SCG bearer.

According to various embodiments, the electronic device <NUM> may ensure transmission of data according to a change of a PDCP version. For example, the change of the PDCP version includes a security key change, ROHC information change, and/or a change between NR PDCP and E-UTRA PDCP. Hereinafter, the PDCP version change is referred to as a PDCP change. According to an embodiment, the electronic device <NUM> estimates a data loss (e.g., identify or estimate a change of PDCP), and performs reprocessing and/or transmission of data to be lost.

According to an embodiment, the electronic device <NUM> identifies a PDCP change. For example, the electronic device <NUM> may identify the PDCP change by identifying an inter-RAT handover. For another example, the electronic device <NUM> may identify the PDCP change by estimating a handover. For example, the electronic device <NUM> may identify the PDCP change by estimating a handover based on a communication state (e.g., signal to interference plus noise ratio (SINR), received signal strength indicator (RSSI)).

According to various embodiments, the electronic device <NUM> identifies a data packet to be lost in response to identification of the PDCP change. For example, the electronic device <NUM> may identify, as data packets to be lost, data packets corresponding to a PDCP SDU that was delivered to a lower layer of the PDCP layer <NUM> but was not transmitted in a physical layer. The electronic device <NUM> identifies, as data packets that are likely to be lost, data packets corresponding to a PDCP SDU that was delivered to a lower layer but was not transmitted in a physical layer, when a PDCP SDU is deleted after being delivered to the lower layer (e.g., in the case of RLC unacknowledged mode (UM)).

For example, a security key and/or ROHC information may be changed according to a handover within the same RAT. In an RRC connection re-establishment procedure according to an intra-RAT handover, the electronic device <NUM>, in the PDCP layer <NUM>, may process data based on an RLC mode (e.g., RLC acknowledged mode (AM) or RCL UM) and a radio bearer type. For example, in the case of a data radio bearer (DRB) of RLC AM, the electronic device <NUM> may store a PDCP SDU in a memory (e.g., the memory <NUM> of <FIG>) at least temporarily until an acknowledgement of the PDCP SDU is received. In the case of an intra-RAT handover, the electronic device <NUM> may re-process PDCP SDUs, for which an acknowledgement has not been received from a lower layer, or PDCP SDUs not processed yet by using changed ROHC information and/or security key, and may transmit or retransmit the re-processed PDCP SDUs through a DRB. For another example, in the case of a DRB and signaling radio bearer (SRB) of RLC UM, the electronic device <NUM> may delete a PDCP SDU after delivering the PDCP SDU to a lower layer.

According to an embodiment, the electronic device <NUM> may store at least a portion of data (e.g., data packet predicted to be lost) that satisfies a specified condition in a memory (e.g., the volatile memory <NUM> of <FIG>) at least temporarily. The electronic device <NUM> identifies, as the data satisfying the specified condition, data that was delivered from the PDCP layer <NUM> to a lower layer but was not transmitted, data that was delivered from the PDCP layer <NUM> to a lower layer but an RLC ACK was not received, or data that was delivered from the PDCP layer to a lower layer in the RLC UM but was not transmitted in a physical layer. According to an embodiment, if the specified condition is satisfied, the electronic device <NUM> stores a PDCP SDU in the memory <NUM> at least temporarily during at least a partial time period. For example, the electronic device <NUM> may identify whether the specified condition is satisfied based on a channel state (e.g., reception channel state) of the electronic device <NUM> or a channel state history. For example, the electronic device <NUM> may estimate an event (e.g., handover) in which loss of a PDCP SDU is predicted, based on a channel connection state. If data loss is estimated, the electronic device <NUM> may store a PDCP SDU in the memory <NUM> at least temporarily. For another example, the electronic device <NUM> may identify whether the specified condition is satisfied, based on QoS. In order to ensure service quality of a PDCP PDCP SDU based on QoS, it may be determined to store a PDCP SDU for fast retransmission of the PDCP SDU. According to various embodiments, it may be determined whether to store (e.g., buffer) a data packet based on PDCP SDU information (e.g., IP packet information) of data (e.g., data packet predicted to be lost) satisfying the specified condition. For example, after storing a data packet predicted to be lost based on the determination on whether to store, the electronic device <NUM> may re-process and/or transmit the stored data packet after PDCP is changed.

Referring to <FIG>, in lower layers of the PDCP layer <NUM>, the first communication protocol stack and the second communication protocol stack may differ in concatenation structure.

According to an embodiment, the electronic device <NUM> may generate a PDCP SDU through reverse conversion of a data packet predicted to be lost. For example, a MAC PDU of the first communication protocol stack may be identified as data predicted to be lost (hereinafter referred to as loss-predicted data), and a PDCP SDU corresponding to the MAC PDU may be in a deleted state. In this case, when handing over the electronic device <NUM> to a cell corresponding to the second communication protocol stack, the electronic device <NUM> may generate a plurality of PDCP SDUs from the MAC PDU through reverse conversion for the MAC PDU generated by the E-UTRA MAC <NUM>. For example, the electronic device <NUM> may store the PDCP SDUs generated through reverse conversion in a memory of the electronic device <NUM> at least temporarily.

According to an embodiment, the electronic device <NUM> store a data packet predicted to be lost in a volatile memory (e.g., PDCP buffer) at least temporarily. For example, the electronic device <NUM> may estimate that an inter-RAT handover will occur based on a channel state, and may store, in a PDCP buffer, a PDCP SDU of a certain time after the estimation. The electronic device <NUM> stores, in a memory at least temporarily, a data packet predicted to be lost in a form of a PDCP PDU including a PDCP header and PDCP SDU.

According to an embodiment, after a handover, the electronic device <NUM> process a plurality of stored PDCP SDUs according to the second communication protocol stack and then may transmit the PDCP SDUs. For example, the electronic device <NUM> may generate a PDCP PDU by adding, to the plurality of stored PDCP SDUs, a PDCP header corresponding to the second communication protocol stack and may transmit the PDCP PDU. In the case where a data packet is stored in a form of PDCP PDU in the volatile memory <NUM>, the electronic device <NUM> removes an existing PDCP header and add a PDCP header corresponding to the second communication protocol stack to generate and transmit a PDCP.

<FIG> illustrates a structure of a PDCP management module <NUM> according to various embodiments.

The structure described in relation with <FIG> is not according to the invention and are present for illustration purposes only. According to various embodiments, the PDCP management module <NUM> may control data processing and transmission according to a change of PDCP. For example, the PDCP management module <NUM> may be operated by an application processor (AP) (e.g., the processor <NUM> of <FIG>) and/or a communication processor (CP) (e.g., the communication module <NUM> of <FIG>). The PDCP management module <NUM> may be a logical module (or software module) operated by the AP and/or CP on a memory <NUM>. For example, the PDCP management module <NUM> may be implemented on the memory <NUM> when instructions stored in a nonvolatile memory (e.g., the nonvolatile memory <NUM> of <FIG>) of an electronic device (e.g., the electronic device <NUM> of <FIG>) are executed by the AP and/or CP. The components of the PDCP management module <NUM> illustrated in <FIG> are divided according to logic and/or function, and embodiments of the present disclosure are not limited to the components illustrated in <FIG>. For example, at least a portion of the components of the PDCP management module <NUM> illustrated in <FIG> may be omitted. For another example, the PDCP management module <NUM> may further include a component not illustrated in <FIG>.

According to various embodiments, the memory <NUM> may be a volatile memory (e.g., the volatile memory <NUM> of <FIG>). For example, the memory <NUM> may include an AP region <NUM> accessed and controlled by the AP, a common region <NUM> accessed and controlled by the AP and CP, and a CP region <NUM> accessed and controlled by the CP. For example, the AP region <NUM>, the common region <NUM>, and the CP region <NUM> may be divided by an address of the memory <NUM>.

According to an embodiment, at least a portion of the PDCP management module <NUM> may be located in the AP region <NUM>. According to an embodiment, at least a portion of the PDCP management module <NUM> may be located in the CP region <NUM>. The location of the PDCP management module <NUM> on the memory <NUM> illustrated in <FIG> is an example, and embodiments of the present disclosure are not limited thereto.

According to various embodiments, the CP region <NUM> may include a PDCP buffer <NUM>. The PDCP buffer <NUM>, which is a storage space for buffering PDCP data (e.g., PDCP SDU or PDCP PDU), may be a memory region within a specified address range. For example, the PDCP buffer <NUM> may include a region of an address range accessible by all of PDCP layers having different versions.

According to various embodiments, the PDCP management module <NUM> may include an AP monitor <NUM>, a PDCP SDU analyzer <NUM>, a PDCP SDU capturer <NUM>, a PDCP SDU loss detector <NUM>, a PDCP SDU manager, an inter-communication protocol stack PDCP SDU deliverer <NUM>, a reverse operator <NUM>, and/or a CP monitor <NUM>.

According to an embodiment, the AP monitor <NUM> may monitor a situation of the AP, and may deliver the monitored situation of the AP to the PDCP SDU manager <NUM>. For example, the situation of the AP may include a CPU load factor and/or a situation of a transmission path (e.g., peripheral component interconnect express (PCIE)) between AP-CP. For example, the PDCP SDU manager <NUM> may determine, by using the CPU load factor, a possibility of processing of data corresponding to a PDCP SDU required to be retransmitted in the AP. For another example, the PDCP SDU manager <NUM> may determine an available capacity for data delivery from the AP to the CP based on the situation of the transmission path between AP-CP. The CPU load factor and the situation of the transmission path between AP-CP are examples, and the AP monitor <NUM> may monitor and report various situations of the AP.

According to an embodiment, the PDCP SDU analyzer <NUM> may identify a characteristic of a PDCP SDU by analyzing the PDCP SDU (e.g., IP data packet) delivered from the AP or an upper layer. For example, the PDCP SDU analyzer <NUM> may identify the characteristic of the PDCP SDU based on information (e.g., transmission protocol) of an IP data packet included in the PDCP SDU. According to an embodiment, the PDCP SDU analyzer <NUM> may determine whether to store the PDCP SDU based on the characteristic of the PDCP SDU. When determining whether to store the PDCP SDU, the electronic device <NUM> may use a result of identifying or estimating a data loss (e.g., PDCP change). If it is determined to store the PDCP SDU, the PDCP SDU analyzer <NUM> may cause the PDCP SDU capturer <NUM> to store the identified PDCP SDU or corresponding PDCP PDU in the common region <NUM> or the PDCP buffer <NUM>. For example, the PDCP SDU analyzer <NUM> may identify the information of an IP packet using an IP header of the IP packet included in the PDCP SDU. According to an embodiment, the PDCP SDU analyzer <NUM> may identify, based on the identified IP packet information, whether the PDCP SDU is a PDCP SDU re-transmittable in an upper layer (e.g., upper layer of a PDCP layer). For example, if the characteristic of the PDCP SDU is a transmission control protocol (TCP), the electronic device <NUM> may retransmit the PDCP SDU from an upper layer of a PDCP layer based on whether ACK/NACK is received. For another example, if the characteristic of the PDCP SDU is a user datagram protocol (UDP), the electronic device <NUM> may not retransmit the PDCP SDU from the upper layer of the PDCP layer regardless of whether ACK/NACK is received. Since a retransmission protocol is not ensured in an upper layer if the PDCP SDU is a UDP packet, the PDCP SDU analyzer <NUM> determines to store the PDCP SDU or corresponding PDCP PDU in the common region <NUM> or the PDCP buffer <NUM>. For example, the electronic device <NUM> may store the PDCP SDU or PDCP PDU in the common region <NUM> or the PDCP buffer <NUM> until a specified condition is satisfied during a specified time.

According to an embodiment, the PDCP SDU analyzer <NUM> may determine to store the PDCP SDU re-transmittable in an upper layer. For example, the PDCP SDU analyzer <NUM> may determine to store the PDCP SDU corresponding to a TCP packet based on QoS of a terminal. For example, in order to ensure service quality of the terminal based on QoS, the PDCP SDU <NUM> may determine to store the PDCP SDU for fast retransmission of the PDCP SDU. For example, the PDCP SDU analyzer <NUM> may determine to store the PDCP SDU based on a current channel state of the electronic device <NUM> or a channel state history. For example, the PDCP <NUM> may estimate an event (e.g., handover) in which loss of a PDCP SDU is predicted, based on the channel state or the channel state history, and may determine to store a PDCP SDU of at least a portion of PDCP or a corresponding PDCP PDU in response to prediction of the loss. If a PDCP SDU is deleted from a memory region corresponding to a PDCP layer, the common region <NUM>, and/or the PDCP buffer <NUM> when it is determined to store the PDCP SDU, the PDCP SDU analyzer <NUM> may restore the PDCP SDU from a PDCP PDU and packets in a lower layer using the reverse operator <NUM>.

According to an embodiment, the PDCP SDU capturer <NUM> may capture and store PDCP SDUs for retransmission or reprocessing based on a determination of the PDCP SDU analyzer <NUM>. For example, the PDCP SDU capturer <NUM> may store a PDCP SDU or corresponding PDCP PDU captured in the PDCP buffer <NUM>. For example, in the RLC AM, the PDCP SDU capturer <NUM> may store the PDCP SDU or corresponding PDCP PDU until an acknowledgement response of an RLC layer, corresponding to the stored PDCP SDU or corresponding PDCP PUD, is received. For another example, with regard to data (e.g., data transmitted in the RLC UM or UDP data packet) for which an acknowledgement response is not required, the PDCP SDU capturer <NUM> may store the PDCP SDU or corresponding PDCP PDU during a specified time. The PDCP SDU or corresponding PDCP PDU stored by the PDCP SDU capturer <NUM> may be in a ciphered state or deciphered state. In the case of the ciphered state, when the PDCP SDU stored by the PDCP SDU manager <NUM> is processed, deciphering of the PDCP SDU may be additionally performed. According to an embodiment, the PDCP SDU capturer <NUM> may include a first communication protocol stack PDCP SDU capturer <NUM> for the first communication protocol stack and a second communication protocol stack PDCP SDU capturer <NUM> for the second communication protocol stack.

According to an embodiment, the PDCP SDU loss detector <NUM> may detect a PDCP SDU predicted to be lost due to a change of PDCP. In order to detect a PDCP SDU predicted to be lost, the PDCP SDU loss detector <NUM> may identify a cause of deletion of a PDCP SDU when the PDCP SDU is deleted from a PDCP layer. According to an embodiment, the PDCP SDU loss detector <NUM> may distinguish whether the PDCP SDU is deleted since the PDCP SDU has been transmitted normally through a physical layer or since the PDCP SDU is not processed due to a change of PDCP. For example, the PDCP SDU loss detector <NUM> may identify the cause of deletion of the PDCP SDU by identifying whether data corresponding to the PDCP SDU has been transmitted normally in a physical layer. For another example, in the RLC AM, the PDCP SDU loss detector <NUM> may identify the cause of deletion of the PDCP SDU based on a result of ACK/NACK in an RLC layer. According to an embodiment, the PDCP SDU loss detector <NUM> may be present for each wireless interface (e.g., radio access technology) corresponding to an independent PDCP version. For example, the PDCP SDU loss detector <NUM> may include a first communication protocol stack PDCP SDU loss detector <NUM> and a second communication protocol stack PDCP SDU loss detector <NUM>.

According to various embodiments, with regard to a PDCP SDU predicted to be lost, the PDCP SDU manager <NUM> may determine whether to process the PDCP SDU through CP internal processing or whether to discard the PDCP SDU and then receive and process the PDCP SDU retransmitted from the AP. For example, the PDCP SDU manager <NUM> may determine a processing method of the PDCP SDU based on the AP situation, the CP situation, and/or the PDCP SDU characteristic identified by the PDCP SDU analyzer <NUM>. According to an embodiment, when it is determined to process the PDCP SDU through the CP internal processing, the PDCP SDU manager <NUM> may use the inter-communication protocol stack PDCP SDU deliverer <NUM> to deliver the PDCP SDU between communication protocol stacks using different types of PDCP versions.

According to various embodiments, the inter-communication protocol stack PDCP SDU deliverer <NUM> may deliver the PDCP SDU predicted to be lost to a communication protocol stack using a different type of PDCP version. The PDCP SDU predicted to be lost may be already stored in the PDCP buffer <NUM> of the CP region <NUM>. Alternatively, the PDCP SDU may be already stored in the PDCP buffer <NUM> in a form of PDCP PDU including a PDCP header. The inter-communication protocol stack PDCP SDU deliverer <NUM> may perform delivery of the PDCP SDU to a communication protocol stack using a different type of PDCP version by processing the PDCP SDU stored in the PDCP buffer <NUM> within the PDCP buffer <NUM>.

Referring to reference number 1300A of <FIG>, for example, a PDCP SDU (e.g., a first PDCP SDU <NUM>) may be stored in the PDCP buffer <NUM> in a form of PDCP PDU (e.g., a first PDCP PDU <NUM>). According to an embodiment, the PDCP PDU deliverer <NUM> may remove a PDCP header (e.g., a first PDCP header <NUM>) from the first PDCP PDU <NUM> and add a PDCP header (e.g., a second PDCP header <NUM>) corresponding to the first PDCP header <NUM> and a different type of PDCP version so as to deliver a PDCP PDU (e.g., a second PDCP PDU <NUM>) of a different type of version to a protocol stack of a different type of version. In this case, the first PDCP PDU <NUM> and the second PDCP PDU <NUM> may correspond to PDCP PDUs of different PDCP versions.

Referring to reference number 1300B of <FIG>, for example, a PDCP SDU (e.g., a second PDCP SDU <NUM>) may be stored in the PDCP buffer <NUM> in a form of PDCP SDU. According to an embodiment, the PDCP PDU deliverer <NUM> may add a PDCP header (e.g., a third PDCP header <NUM>) corresponding to a different type of PDCP version so as to deliver a PDCP PDU (e.g., a third PDCP PDU <NUM>) of a different type of version to a protocol stack of a different type of version.

Referring to reference number 1300C of <FIG>, for example, a PDCP SDU (e.g., a third PDCP SDU <NUM>) may be stored in the CP region <NUM> other than the PDCP buffer <NUM> in the memory <NUM>. For example, the third PDCP SDU <NUM> may be stored in a form of PDCP SDU. In this case, a fourth PDCP header <NUM> may be omitted. For another example, a PDCP SDU may be stored in a form of PDCP PDU (e.g., a fourth PDCP PDU <NUM>). The PDCP SDU deliverer <NUM> may deliver a PDCP SDU or corresponding PDCP PDU between communication protocol stacks of different types by delivering information (e.g., address information of the third PDCP SDU <NUM> in the memory <NUM>) of the PDCP SDU.

Referring to <FIG>, according to an embodiment, when it is determined to process a PDCP SDU through retransmission from the AP, the PDCP SDU manager <NUM> may delete the PDCP SDU or corresponding PDCP PDU from the PDCP buffer <NUM> and then may request the AP to retransmit an IP data packet corresponding to the deleted PDCP SDU.

According to an embodiment, the inter-communication protocol stack PDCP SDU deliverer <NUM> may deliver a PDCP SDU or corresponding PDCP PDU between communication protocol stacks of different types. For example, the inter-communication protocol stack PDCP SDU deliverer <NUM> may deliver a PDCP SDU or corresponding PDCP PDU based on a determination of the PDCP SDU manager <NUM>.

According to an embodiment, the reverse operator <NUM> may restore a PDCP SDU from a data packet of a lower layer. When a PDCP SDU is deleted after being delivered from a PDCP layer to a lower layer, although a packet that has failed to be transmitted in an RLC/MAC/PHY layer has not been transmitted to a receiving end, the PDCP SDU may not be present. In this case, the reverse operator <NUM> may regenerate at least one PDCP SDU from a packet of a lower layer in a reverse order of transmission process. For example, in order to store a regenerated PDCP SDU, the reverse operator <NUM> may deliver the regenerated PDCP SDU to the PDCP SDU capturer <NUM> or may store the regenerated PDCP SDU in the PDCP buffer <NUM>.

According to an embodiment, the CP monitor <NUM> may monitor the situation of the CP, and may report situation information of the CP to the PDCP SDU manager <NUM>. For example, the situation information of the CP may include an amount of unprocessed PDCP SDUs (e.g., amount of identified PDCP SDUs to be lost), a logical channel identifier (LCID) of unprocessed PDCP SDUs, and/or a sequence number (SN) of unprocessed PDCP SDUs when PDCP is changed. For example, the PDCP SDU manager <NUM> may determine an amount of load of the CP for retransmitting or reprocessing a PDCP SDU, based on the CP situation information. The above-mentioned monitoring information of the CP monitor <NUM> is an example, and the CP monitor <NUM> may monitor CP operations associated with processing of non-transmitted and/or unprocessed PDCP SDUs according to a change of PDCP.

<FIG> illustrates a signal flow diagram in a bearer change situation. The bearer change situation described in relation with <FIG> is not according to the invention and are present for illustration purposes only.

The electronic device <NUM> may transmit/receive data based on an NR PDCP in an MR-DC environment that is based on 5th generation mobile communication NSA. For example, in operation <NUM>, the electronic device <NUM> may establish a first bearer based on an NR PDCP with a secondary node (SN) <NUM>. In operation <NUM>, the electronic device <NUM> may transmit/receive data to/from the SN <NUM> through the established first bearer. In this case, the electronic device <NUM> may transmit/receive data to/from the SN <NUM> using a split bearer or SCG bearer. The electronic device <NUM> may transmit data to the SN <NUM> through a bearer based on an NR PDCP (e.g., the NR PDCP <NUM> of <FIG>). For example, the electronic device <NUM> (e.g., the PDCP SDU analyzer <NUM> of <FIG>) may identify a characteristic of a PDCP SDU when an IP packet generated by an application is delivered to a PDCP layer. Furthermore, the PDCP SDU analyzer <NUM> may deliver the identified characteristic to a PDCP SDU manager (e.g., the PDCP SDU manager <NUM> of <FIG>). For example, the electronic device <NUM> (e.g., the PDCP SDU manager <NUM>) may determine whether to store the PDCP SDU in a PDCP buffer (e.g., the PDCP buffer <NUM> of <FIG>) based on a received PDCP SDU characteristic. Furthermore, the electronic device <NUM> (e.g., the PDCP SDU manager <NUM>) may determine whether to store the PDCP SDU based on an AP and/or CP situation.

In operation <NUM>, the electronic device <NUM> may deviate from coverage of the SN <NUM>. In this case, in operation <NUM>, the electronic device <NUM> may declare a radio link failure (RLF). The SN <NUM> may be released in response to the RLF. In this case, the electronic device <NUM> (e.g., the PDCP SDU manager <NUM>) may identify a PDCP change based on CP information. For example, the PDCP SDU manager <NUM> may identify a PDCP SDU that is likely to be lost using the PDCP SDU loss detector <NUM>. The electronic device <NUM> (e.g., the PDCP SDU manager <NUM>) may determine a processing method of a PDCP SDU based on the AP and/or CP information and the identified PDCP SDU. For example, with regard to a PDCP SDU predicted to be lost, the PDCP SDU manager <NUM> may determine whether to process the PDCP SDU through CP internal processing or whether to receive and process the PDCP SDU retransmitted from the AP.

In operation <NUM>, the electronic device <NUM> may establish a second bearer with a master node (MN) <NUM>. In operation <NUM>, the electronic device <NUM> may transmit/receive data to/from the MN <NUM> through the second bearer. For example, the second bearer may be a bearer (e.g., MCG bearer) based on LTE PDCP.

In the example of <FIG>, the type of a bearer may be changed based on an RLF. The electronic device <NUM> may process a PDCP SDU predicted to be lost based on a determination (e.g., processing by using AP or CP) of the PDCP SDU manager <NUM>. For example, when the electronic device <NUM> determines to process the PDCP SDU predicted to be lost by using the CP, the electronic device <NUM> may buffer the PDCP SDU predicted to be lost in a PDCP buffer (e.g., the PDCP buffer <NUM> of <FIG>) until the second bearer is established. The buffering operation performed by the electronic device <NUM> may include storing, by the electronic device <NUM>, the PDCP SDU predicted to be lost in the PDCP buffer (e.g., the PDCP buffer <NUM> of <FIG>). In this process, the electronic device <NUM> may use the PDCP SDU stored in the PDCP buffer <NUM> to transmit the PDCP SDU through the second bearer. For example, after establishing the second bearer, the electronic device <NUM> may deliver the stored PDCP SDU to a communication protocol stack having a different type of version under control by the inter-communication protocol stack PDCP SDU deliverer <NUM> so as to transmit the PDCP SDU to the MN <NUM> through the second bearer. For example, the electronic device <NUM> may generate a PDCP PDU by adding, to the PDCP SDU stored in the PDCP buffer <NUM>, a header related to a version of changed PDCP (e.g., the E-UTRA PDCP <NUM> of <FIG>), and may transmit the PDCP PDU to the MN <NUM> through lower layers of the changed PDCP. For another example, when the electronic device <NUM> determines to process data PDCP SDU predicted to be lost by using the AP, the electronic device <NUM> may delete the PDCP SDU predicted to be lost and may retransmit an IP data packet corresponding to the PDCP SDU from the AP to a PDCP layer (e.g., the PDCP layer <NUM> of <FIG>).

Although not illustrated, the electronic device <NUM> may store the PDCP SDU predicted to be lost in the PDCP buffer <NUM> before deviating (operation <NUM>) from the SN coverage. For example, during data transmission/reception through the first bearer (operation <NUM>), if the electronic device <NUM> estimates that an event (e.g., handover) in which data loss may occur will occur based on a channel state, the electronic device <NUM> may store the PDCP SDU predicted to be lost in the PDCP buffer <NUM> from a point of time of the estimation.

<FIG> illustrates a signal flow diagram <NUM> related to PDCP version change identification according to various embodiments. The signal flow described in relation with <FIG> is not according to the invention and are present for illustration purposes only.

In operation <NUM>, a PDCP SDU (e.g., IP data packet) may be delivered from an AP <NUM> to a CP <NUM>. During delivery of the PDCP SDU, the PDCP SDU analyzer <NUM> may identify a characteristic of the PDCP SDU, and may deliver the identified characteristic to the PDCP SDU manager <NUM>. For example, the PDCP SDU may be processed based on the second communication protocol stack <NUM>. For example, operation <NUM> may correspond to the data transmission/reception through the first bearer (e.g., operation <NUM>) of <FIG>.

According to an embodiment, the AP monitor <NUM> may monitor an AP state in operation <NUM>, and may report the AP state to the PDCP SDU manager <NUM> in operation <NUM>.

According to an embodiment, the PDCP SDU analyzer <NUM> may identify the characteristic of the PDCP SDU in operation <NUM>, and may report the identified characteristic to the PDCP SDU manager <NUM> in operation <NUM>.

According to an embodiment, the CP monitor <NUM> may monitor a CP state in operation <NUM>, and may report the CP state to the PDCP SDU manager <NUM> in operation <NUM>.

Operation <NUM> to operation <NUM> may be performed during the PDCP SDU delivery of operation <NUM>, and may be performed substantially simultaneously. An order in which operation <NUM> to operation <NUM> are performed is not limited by reference numbers related to the operations.

According to various embodiments, the CP monitor <NUM> may detect or estimate a PDCP version change in operation <NUM>. For example, the CP monitor <NUM> may detect a PDCP version change by sensing an addition or release of a secondary node (SN). For another example, the CP monitor <NUM> may estimate a PDCP version change based on a communication state (e.g., RSSI and/or SINR). For another example, the CP monitor <NUM> may estimate a PDCP version change based on an RLC ARQ state or HARQ state. The CP monitor <NUM> may detect a PDCP version change based on deviation (e.g., operation <NUM> of <FIG>) of the electronic device <NUM> from the SN coverage or an RLF (e.g., operation <NUM> of <FIG>).

According to various embodiments, in response to detection or estimation of a PDCP version change, the CP monitor <NUM> may notify the version change to the PDCP SDU loss detector <NUM>. In operation <NUM>, the PDCP SDU loss detector <NUM> may identify a PDCP SDU predicted to be lost based on the PDCP version change. When a PDCP SDU predicted to be lost is present, the PDCP SDU loss detector <NUM> may report the detection of loss to the PDCP SDU manager <NUM>.

<FIG> illustrates a signal flow diagram <NUM> related to a PDCP SDU transmission method according to various embodiments. The signal flow described in relation with <FIG> is not according to the invention and are present for illustration purposes only.

According to an embodiment, the PDCP SDU manager <NUM> may determine to process a PDCP SDU predicted to be lost in the CP <NUM>, based on at least one of the reports described above with reference to <FIG>.

According to various embodiments, in operation <NUM>, the PDCP SDU manager <NUM> may determine to capture a PDCP SDU. For example, the PDCP SDU manager <NUM> may determine to capture a PDCP SDU in response to detection or estimation (e.g., operation <NUM> of <FIG>) of a PDCP version change. For another example, the PDCP SDU manager <NUM> may determine to capture a PDCP SDU based on a PDCP SDU characteristic report (e.g., operation <NUM> of <FIG>).

According to various embodiments, in operation <NUM>, the PDCP SDU manager <NUM> may deliver a PDCP SDU capture notification to the PDCP SDU capturer <NUM>. In operation <NUM>, the PDCP SDU capturer <NUM> may capture a PDCP SDU. For example, the PDCP SDU capturer <NUM> may store a PDCP SDU in a PDCP buffer (e.g., the PDCP buffer <NUM> of <FIG>). According to an embodiment, capturing of a PDCP SDU may include reverse conversion of a packet that is present in a lower layer of a PDCP layer into a PDCP SDU.

According to various embodiments, in operation <NUM>, the CP monitor <NUM> may detect or estimate an end of PDCP version change. For example, the end of PDCP version change may correspond to completion of establishment of the second bearer (e.g., operation <NUM> of <FIG>). In operation <NUM>, the CP monitor <NUM> may notify the end of PDCP version change to the PDCP SDU manager <NUM>.

According to various embodiments, in operation <NUM>, the PDCP SDU manager <NUM> may request the PDCP SDU capturer <NUM> to deliver a captured PDCP SDU. In operation <NUM>, the PDCP SDU capturer <NUM> may deliver, to a protocol stack corresponding to the second bearer, a captured PDCP SDU through PDCP SDU delivery between communication network protocol stacks under control by the inter-communication protocol stack PDCP SDU deliverer <NUM>. For example, the inter-communication protocol stack PDCP SDU deliverer <NUM> may deliver the PDCP SDU to the protocol stack corresponding to the second bearer by processing the PDCP SDU (e.g., adding a PDCP header corresponding to the second bearer) stored in the PDCP buffer <NUM> by the PDCP SDU capturer <NUM>. For example, the inter-communication protocol stack PDCP SDU deliverer <NUM> may deliver the PDCP SDU to the protocol stack corresponding to the second bearer by deleting a PDCP header of the PDCP PDU corresponding to the first bearer, stored in the PDCP buffer <NUM>, and adding the PDCP header corresponding to the second bearer. For another example, the inter-communication protocol stack PDCP SDU deliverer <NUM> may deliver information (e.g., address information) of a PDCP SDU stored in a memory region other than the PDCP buffer <NUM> to the protocol stack corresponding to the second bearer. The electronic device <NUM> may transmit data through the second bearer based on the delivered PDCP SDU (e.g., operation <NUM> of <FIG>).

<FIG> illustrates a signal flow diagram related to a PDCP SDU retransmission. The signal flow diagram described in relation with <FIG> is not according to the invention and are present for illustration purposes only.

In operation <NUM>, the PDCP SDU manager <NUM> may determine to retransmit a PDCP SDU from the AP <NUM>, based on at least one of the reports described above with reference to <FIG>. For example, when a PDCP SDU to be lost is a TCP-based data packet based on a loss detection report (e.g., operation <NUM> of <FIG>) and PDCP SDU characteristic report (e.g., operation <NUM> of <FIG>), the PDCP SDU manager <NUM> may determine to retransmit the PDCP SDU from the AP <NUM>.

In operation <NUM>, the PDCP SDU manager <NUM> may notify deletion of the stored PDCP SDU to the PDCP SDU capturer <NUM>.

In operation <NUM>, the CP monitor <NUM> may detect or estimate an end of PDCP version change. For example, the end of PDCP version change may correspond to completion of establishment of the second bearer (e.g., operation <NUM> of <FIG>). In operation <NUM>, the CP monitor <NUM> may notify the end of PDCP version change to the PDCP SDU manager <NUM>.

In operation <NUM>, the PDCP SDU manager <NUM> may request the AP <NUM> to retransmit a PDCP SDU estimated to be lost. In operation <NUM>, the AP <NUM> may retransmit the requested PDCP SDU by retransmitting a requested IP data packet. In this case, the CP <NUM> may process a received IP data packet according to a network protocol stack corresponding to a changed PDCP version.

Described above with reference to <FIG> are methods of processing a PDCP SDU estimated to be lost when the electronic device <NUM> is handed over from the SN <NUM> corresponding to an NR cell to the MN <NUM> corresponding to an E-UTRA cell. However, embodiments of the present disclosure are not limited thereto.

According to an embodiment, the electronic device <NUM> may be handed over from an E-UTRA cell to an NR cell supporting MR-DC. In this case, since an MC bearer associated with an E-UTRA PDCP is changed to a SCG bearer or split bearer of NR, there may be a residual PDCP SDU. In this case, the same embodiments as described above with reference to <FIG> may be applied, except for a communication network protocol stack.

A bearer of the electronic device <NUM> may be changed, according to a configuration update based on network preference, from an MCG bearer based on E-UTRA PDCP to an MCG bearer based on NR PDCP in an E-UTRA cell supporting MR-DC. In this case, the PDCP SDU loss detector <NUM> may identify a PDCP SDU to be lost due to a PDCP version change. The PDCP SDU manager <NUM> may deliver the PDCP SDU to be lost to an NR protocol stack. Therefore, E-UTRA PDCP SDUs may be retransmitted through an NR PDCP SDU.

According to an embodiment, the electronic device <NUM> may determine to re-process or retransmit a PDCP SDU even when a bearer or a security key of PDCP is changed without changing RAT. For example, when successful reception by a receiving end is impossible due to a change of the PDCP security key, the PDCP SDU manager <NUM> may generate a changed PDCP SDU by using a changed security key from a PDCP SDU stored in the PDCP buffer <NUM>. The electronic device <NUM> may retransmit the PDCP SDU corresponding to the changed key through a corresponding protocol stack. For another example, in response to a change of a bearer, the PDCP SDU manager <NUM> may generate a PDCP PDU corresponding to the changed bearer from a PDCP SDU stored in the PDCP buffer <NUM>, and may retransmit the generated PDCP PDU through a corresponding protocol stack. Likewise, when packet retransmission is performed in the same bearer according to a bearer reconfiguration procedure on the same RAT, the PDCP SDU manager <NUM> may identify a PDCP SDU to be lost according to a procedure similar to that described above, and may re-process or retransmit the identified PDCP SDU.

<FIG> is a flowchart <NUM> illustrating a PDCP SDU transmission method according to various embodiments.

According to various embodiments, at least one processor (e.g., the processor <NUM> and/or communication module <NUM> of <FIG>) of the electronic device <NUM> monitors an AP and CP in operation <NUM>. For example, the operation of the AP monitor <NUM> and CP monitor <NUM> of <FIG> may be referenced for operation <NUM>.

In operation <NUM>, the at least one processor determines whether a PDCP version or key (e.g., security key of PDCP layer) change event is detected based on a result of monitoring the AP and/or CP. If the PDCP version change or key change event is not detected, the at least one processor continues to monitor the AP and CP.

In operation <NUM>, if the PDCP version change or key change event is detected, the at least one processor determines whether transmission data is lost in response to a detected event. For example, the at least one processor determines that data to be lost is present if there is transmission data that was delivered from a PDCP layer to a lower layer but was not transmitted or acknowledgement thereof was not received.

When data to be lost is present, the at least one processor determines whether to retransmit transmission data in operation <NUM>. For example, the at least one processor determines whether to retransmit based on a characteristic of the data to be lost. For example, if a transmission protocol of the data to be lost is TCP, the at least one processor determines to retransmit the transmission data. For another example, if a transmission protocol of the data to be lost is UDP, the at least one processor determines to re-process the transmission data.

If it is determined to retransmit the transmission data, the at least one processor requests the AP to retransmit the lost transmission data in operation <NUM>. If it is determined to re-process the transmission data, the at least one processor re-processes and transmits a PDCP SDU using a changed PDCP version or key in operation <NUM>.

<FIG> is a flowchart illustrating a method for transmitting a data packet of changed PDCP according to various embodiments.

According to various embodiments, an electronic device (e.g., the electronic device <NUM> of <FIG>) includes: at least one wireless communication circuit (e.g., the communication module <NUM> of <FIG>) configured to provide a first radio access technology (RAT) and a second RAT; at least one processor (e.g., the communication module <NUM> and/or processor <NUM> of <FIG>) operatively connected to the at least one wireless communication circuit and configured to provide a first packet data convergence protocol (PDCP) related to the first RAT and a second PDCP related to the second RAT; a volatile memory (e.g., the volatile memory <NUM> of <FIG>) operatively connected to the at least one processor and including, in at least a partial region thereof, a first buffer; and a nonvolatile memory (e.g., the nonvolatile memory <NUM> of <FIG>) operatively connected to the at least one processor or coupled to the processor.

For example, the nonvolatile memory stores instructions that, when executed, cause the at least one processor to perform the operations described below.

In operation <NUM>, the at least one processor stores, during wireless communication based on the first RAT, at least one first data packet related to the first PDCP in the first buffer (e.g., the PDCP buffer <NUM>) at least temporarily. For example, the at least one first data packet includes at least one first packet header including an identifier related to the first PDCP and at least one service data unit (SDU). For example, the at least one first data packet is a user datagram protocol (UDP) packet.

In operation <NUM>, the at least one processor, when the wireless communication is changed to wireless communication based on the second RAT, change at least a portion of the stored at least one first data packet to at least one second data packet related to the second PDCP.

In operation <NUM>, the at least one processor transmits the at least one second data packet using the second PDCP during the wireless communication based on the second RAT. The at least one second data packet includes at least one second packet header including an identifier related to the second PDCP and the at least one SDU of the at least one first data packet.

The at least one processor changes at least a portion of the stored at least one first data packet to at least one second data packet related to the second PDCP by removing the at least one first packet header from the at least one first data packet and adding the at least one second packet header to the at least one first data packet from which the at least one first packet header has been removed.

<FIG> is a flowchart <NUM> illustrating a method for transmitting a data packet in a PDCP change situation according to various embodiments.

In operation <NUM>, the at least one processor stores, during wireless communication based on the first RAT, a plurality of first data packets related to the first PDCP in the first buffer at least temporarily.

In operation <NUM>, the at least one processor transmits at least a portion of the plurality of first data packets using the first PDCP. For example, the at least one first data packet may include at least one first packet header including an identifier related to the first PDCP and at least one service data unit (SDU). For example, the at least one first data packet is a user datagram protocol (UDP) packet.

In operation <NUM>, the at least one processor, when the wireless communication is changed to wireless communication based on the second RAT, identifies at least one first data packet not transmitted among the plurality of first data packets.

In operation <NUM>, the at least one processor changes the identified at least one first data packet to at least one second data packet related to the second PDCP. For example, the at least one second data packet includes at least one second packet header including an identifier related to the second PDCP and the at least one SDU of the at least one first data packet. According to an embodiment, the at least one processor changes at least a portion of the stored at least one first data packet to at least one second data packet related to the second PDCP by removing the at least one first packet header from the at least one first data packet and adding the at least one second packet header to the at least one first data packet from which the at least one first packet header has been removed.

In operation <NUM>, the at least one processor transmits the at least one second data packet using the second PDCP during the wireless communication based on the second RAT.

According to various embodiments, an electronic device (e.g., the electronic device <NUM> of <FIG>) include: at least one wireless communication circuit (e.g., the communication module <NUM> of <FIG>) configured to provide a first radio access technology (RAT) (e.g., E-UTRA or NR) and a second RAT (e.g., RAT different from the first RAT); at least one processor (e.g., the wireless communication module <NUM> of <FIG>) (e.g., communication processor) operatively connected to the at least one wireless communication circuit and configured to provide a first packet data convergence protocol (PDCP) related to the first RAT and a second PDCP related to the second RAT; a volatile memory (e.g., the volatile memory <NUM> of <FIG>) operatively connected to the at least one processor and including, in at least a partial region thereof, a first buffer; and a nonvolatile memory (e.g., the nonvolatile memory <NUM> of <FIG>) operatively connected to the at least one processor or coupled to the processor. According to an embodiment, the nonvolatile memory may store one or more instructions that, when executed, cause the at least one processor to perform the operations of the electronic device described below.

According to an embodiment, the electronic device may store, during wireless communication based on the first RAT, at least one first data packet related to the first PDCP in the first buffer (e.g., the common region <NUM> or PDCP buffer <NUM> of <FIG>) at least temporarily, may change at least a portion of the stored at least one first data packet to at least one second data packet related to the second PDCP when the wireless communication is changed to wireless communication based on the second RAT, and may transmit the at least one second data packet using the second PDCP during the wireless communication based on the second RAT. For example, the at least one first data packet may include at least one first packet header including an identifier related to the first PDCP and at least one service data unit (SDU). For example, the at least one second data packet may include at least one second packet header including an identifier related to the second PDCP and the at least one SDU. For example, the at least one first data packet may be a user datagram protocol (UDP) packet.

Claim 1:
An electronic device comprising:
at least one wireless communication circuit configured to provide communication by using a a first radio access technology, RAT, and a second RAT;
a processor operatively connected to the at least one wireless communication circuit; and
a memory operatively connected to the processor,
wherein the memory stores instructions that, when executed, cause the processor to:
transmit at least a portion of a plurality of first data packets based on a first packet data convergence protocol, PDCP,
detect a PDCP change from the first PDCP to a second PDCP by detecting a change between new radio, NR, PDCP and evolved universal mobile communication system terrestrial radio access, E-UTRA, PDCP,
identify, in response to the detected PDCP change, at least one first data packet that is delivered from a PDCP layer to a lower layer and not transmitted to a physical layer, and
when a transmission protocol of the at least one first data packet is a user datagram protocol, UDP, determine to reprocess the at least one first data packet by:
storing the at least one first data packet in a buffer,
changing at least portion of the first data packet to at least one second data packet related to the second PDCP by removing at least one first packet header from the at least one first data packet and adding at least one second packet header, comprising an identifier related to the second PDCP, to the at least one first data packet from which the at least one first packet header has been removed, and
transmitting the at least one second data packet.