KR20230040223A - Data processing method and apparatus - Google Patents

Abstract

According to the present specification, a data processing method and a device thereof are provided. The method performs integrity protection and/or cyphering processing for concatenated data units (PDCP SDUs) according to specific criteria, timing and/or order for concatenation processing in a packet data convergence protocol (PDCP) object provided to a concatenation function so as to transmit or receive data by effectively concatenating corresponding service data units (SDUs) In the PDCP object. Therefore, the present invention can reduce L2 header overhead and process user data at high speed through a mobile communication network.

Description

Data processing method and apparatus {DATA PROCESSING METHOD AND APPARATUS}

The present invention relates to a data processing method and apparatus in a mobile communication network, and in particular, provides a method for transmitting and receiving data by effectively concatenating corresponding service data units (SDUs) in a layer 2 entity (e.g. PDCP).

NR L2 data flow

Layer 2 of NR consists of the following sublayers.

Medium Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP) and Service Data Adaptation Protocol (SDAP).

1 shows an example of NR layer 2 data flow processing.

In FIG. 1, one transport block is generated by concatenating/multiplexing two RLC PDUs from radio bearer x (RBx) and one RLC PDU from radio bearer y (RBy) by MAC. Each of the two RLC PDUs from RBx corresponds to one IP packet (n and n+1), and the RLC PDU from RBy is a segment of IP packet (m).

NR removed the RLC concatenation function used in LTE. Accordingly, data can be transmitted by multiplexing RLC PDUs in the MAC layer. However, as data usage increases due to applications requiring higher bandwidth, a technology capable of supporting high-speed security processing (e.g. ciphering, integrity protection function) for all user data on the air interface (Uu) between the terminal and the base station is needed. need. For example, in the conventional NR technology, since one IP packet becomes one PDCP SDU for user data, integrity protection/ciphering processing for user data must be performed for each packet. Accordingly, the processing load increases as the number of IP packets to be processed increases. As a way to solve this problem, a method of performing integrity protection/ciphering processing by concatenating user plane data can be considered, but no specific method has been provided.

In the NR technology, since integrity protection processing must be performed for each IP packet for user plane data, processing time/load may increase as the amount of user data increases.

The present invention, devised to solve the above problems, proposes a method and apparatus for reducing security processing load by concatenating user data in an upper L2 entity.

In order to achieve the above object, the present specification provides a data processing method and apparatus.

As described above, the present invention has an effect of reducing L2 header overhead and processing user data at high speed through a mobile communication network.

1 shows an example of NR layer 2 data flow processing.
2 shows an example of a PDCP PDU according to the present invention.
3 shows an example of a PDCP header.
4 shows another example of a PDCP header.
5 shows an example of a PDCP PDU according to the present invention.
6 shows an example of a PDCP entity function processing sequence.
7 shows an example of intra-AMF/UPF handover.
8 shows a configuration block diagram of a processor in which the disclosure of this specification is implemented.
9 shows a wireless communication device according to an embodiment of the present specification.
10 illustrates a block configuration diagram of a network node according to an embodiment of the present specification.
11 illustrates a block configuration diagram of a communication device according to an embodiment of the present specification.

Hereinafter, a data processing method based on 5G NR radio access technology will be described. However, this is for convenience of explanation, and the present invention can be applied to data processing based on any radio access technology (e.g. LTE, 6G). The embodiments described in the present invention include contents of information elements and operations specified in any NR standard (e.g. TS 38.322, NR RLC standard, TS 38.323, NR PDCP standard, TS 38.331, NR RRC standard, etc.). Even if terminal operation contents related to the definition of corresponding information elements are not included in this specification, corresponding contents specified in standard specifications, which are known technologies, may be included in the present invention. The embodiments provided below may be implemented individually or in any combination/combination of each specific embodiment.

In the prior art, PDCP main function operations (header compression/integrity protection/ciphering) were processed in association with each PDCP SDU. Accordingly, even for small IP packets such as TCP ACK, processing for header compression/integrity protection/ciphering was required in PDCP for each packet. If one or more user data units (e.g. IP packet/SDAP SDU, SDAP PDU/PDCP SDU) are concatenated and processed, the processing load for header compression/integrity protection/ciphering can be reduced. Also, the total amount of L2 headers (e.g. PDCP header, RLC header, MAC header) used to transmit and receive each user data unit can be reduced. For example, through the present invention, one of the PDCP function operation or detailed operation (e.g. header compression / integrity protection / ciphering / PDCP dismiss / PDCP status reporting / PDCP status report format / PDCP retransmission / PDCP header format / SN status transmission) The above can be processed in association with each PDCP PDU.

A sublayer that provides concatenation function

For example, an SDAP PDU including one or more IP packets/SDAP SDUs may be generated in SDAP. For example, when receiving one SDAP SDU from a higher layer for one QoS flow, the transmitting SDAP entity maps the corresponding SDAP SDU to the corresponding DRB according to the stored QoS flow and DRB mapping rules. An SDAP PDU may be generated by concatenating one or more SDAP SDU(s) associated with the corresponding QoS flow. The corresponding SDAP PDU may have a different SDAP header/header field/format different from the conventional SDAP header (e.g. SDAP header having RDI, RQI, QFI or D/C, R, QFI fields). For example, to distinguish each SDAP SDU, a length field for indicating the length of the corresponding SDAP SDU and an extension field for indicating whether (additional) data follows may be included. The corresponding additional field can be added outside the conventional SDAP header. (Including the corresponding additional field header before the SDAP header in the first SDAP SDU included in the concatenated SDAP PDU) The corresponding additional field may be configured to be byte-aligned. However, this method has a problem in that header compression may be difficult for concatenated IP packets. To solve this problem, header compression can be performed by dividing IP packets through information for distinguishing the boundaries of concatenated IP packets (the above-mentioned length information). You may need to use the SDAP header included in the /PDCP SDU. For example, for one or more SDAP SDUs included in one PDCP SDU, header compression may be performed in units of each SDAP SDU to regenerate the PDCP SDU.

As another example, PDCP may provide a PDCP concatenation including one or more PDCP SDU(s). One PDCP PDU including a plurality of PDCP SDU(s) may be generated. The corresponding PDCP PDU may have another PDCP header/header field/format/additional header that is distinguished from the conventional PDCP header (e.g. PCDP header having D/C, R, PDCP SN fields). For example, to distinguish each PDCP SDU, a length field for indicating the length of the corresponding PDCP SDU and an extension field for indicating whether (additional) data follows may be included. The corresponding additional field may be attached to the outer shell of the conventional PDCP header (eg, including the corresponding additional field header in front of the PDCP header corresponding to the first PDCP SDU included in the corresponding concatenated PDCP PDU). Corresponding additional fields may be configured to be byte-aligned. The corresponding additional field may include a field (e.g. Length/Length/Length Indicator) for distinguishing each PDCP SDU within a plurality of concatenated PDCP SDUs. The corresponding field may indicate the length (bytes) of a corresponding data field element present in a PDCP data PDU transmitted/received by the PDCP entity.

2 shows an example of a PDCP PDU according to the present invention.

For example, in FIG. 2, the PDCP Header may indicate FIG. 3 when it has a 12-bit PDCP SN and FIG. 4 when it has an 18-bit PDCP SN. As another example, the PDCP header for the first PDCP SDU included in the concatenated PDCP PDU uses FIGS. 3 and 4, but the PDCP header for the second and subsequent PDCP SDUs uses the conventional PDCP SN It can consist of a 1-byte (1 octet) header that does not contain any fields. Alternatively, PDCP PDUs may be generated without including a PDCP header for the second and subsequent PDCP SDUs. Since the SN of the second and subsequent PDCP SDUs can be calculated by adding 1 to the first PDCP SN (or sequence-1, e.g., the second PDCP SN+1, the third PDCP SN+2) , It does not include a field for indicating the corresponding information (PDCP SN), and it can be inferred (according to the order). For another example, in FIG. 2 , the PDCP SDU may indicate an uncompressed PDCP SDU (Data field) or a compressed PDCP SDU (Data field).

5 shows another example of a PDCP PDU according to the present invention. For example, in FIG. 5, Updated Header indicates an updated PDCP header that is distinguished from FIGS. 3 and 4, and indicates the length of the corresponding PDCP SDU to distinguish the D / C field, PDCP SN field, and each PDCP SDU It may include one or more of a length field to indicate whether or not (additional) data follows.

For convenience of description, a method of performing concatenation in PDCP will be described below. This is for convenience of explanation, and it is obvious that a method of performing concatenation in SDAP by changing PDCP to SDAP is also included in the scope of the present invention.

Criterion/time point/order of conketnation processing

For example, when the transmission total size for the corresponding radio bearer is indicated by the lower layer (e.g. MAC layer) in a specific transmission opportunity (e.g. uplink grant) notified by the lower layer (e.g. physical layer / MAC layer), concatenation Nation can be performed. For example, the transmitting PDCP entity concatenates the PDCP SDUs so that the PDCP PDU(s) fit within the total size of the PDCP PDU(s) indicated by the lower layer at a specific transmission opportunity notified by the lower layer. can do. (When a transmitting PDCP entity forms PDCP PDU(s) from PDCP SDUs, it shall concatenate the PDCP SDUs so that the PDCP PDU(s) fit within the total size of PDCP PDU(s) indicated by lower layer at the particular transmission opportunity notified by lower layer). RLC may indicate the transmission total size for a corresponding radio bearer to PDCP by a lower layer (e.g. MAC layer) at a specific transmission opportunity (e.g. uplink grant) notified by a lower layer (e.g. physical layer/MAC layer). . Alternatively, for a specific transmission opportunity (e.g. uplink grant) notified by the lower layer (e.g. physical layer/MAC layer), the total transmission size for the corresponding radio bearer may be indicated to PDCP by the lower layer (e.g. MAC layer).

As another example, in order to support conketnation suitable for a wireless environment, the base station may transmit help information for supporting conketnation to the terminal. For quick adaptation, corresponding information may be included in PDCCH/DCI and transmitted. Alternatively, it may be transmitted through a MAC CE including corresponding information. Alternatively, it may be transmitted through an RLC control PDU or a PDCP control PDU. Alternatively, it may be indicated through an RRC reconfiguration message. If transmitted through a lower layer, the lower layer may indicate this as PDCP. Corresponding information may be any information/parameters included in the above-mentioned embodiment or the following embodiment. Corresponding information may include at least one of an effective time, start time/slot, and start offset of the corresponding information.

As another example, for fast processing of user data, concatenation may be performed according to specific criteria in PDCP at a specific time point/time unit/size unit/number of PDCP SDUs. Related parameters, such as a corresponding criterion, time point, time unit, size unit, and number, may be configured as indicated by the base station or may be pre-configured in the terminal/base station.

6 shows an example of a PDCP entity function processing sequence. Referring to FIG. 6 , a transmitting PDCP entity may receive one PDCP SDU from an upper layer and perform an operation for assigning a sequence number (SN). For example, when a PDCP entity receives one PDCP SDU from an upper layer, it can start a discard timer associated with this PDCP SDU. The PDCP entity associates a COUNT value with TX_NEXT corresponding to this PDCP SDU. Here, TX_NEXT represents a state variable indicating the COUNT value of the next PDCP SDU to be transmitted. Then, the sending PDCP entity may perform header compression. For example, perform header compression for that PDCP SDU using ROHC and/or using EHC. Then, the PDCP entity can concatenate the corresponding PDCP SDU. Then, integrity protection and ciphering are performed. For example, integrity protection and ciphering are performed using TX_NEXT. Afterwards, the PDCP header is added. For example, set the PDCP SN to TX_NEXT modulo 2 ^{[ pdcp-SN-SizeUL ]} in the PDCP PDU.

For example, when receiving user data from a higher layer, the PDCP entity determines if concatenation has been configured and/or the size for concatenation (eg, maximum for concatenated PDCP SDU(s)). /total size/sum size, max/total size/size sum for concatenated header compressed PDCP SDU(s), max/total size/size for concatenated header uncompressed PDCP SDU(s) If the sum, the maximum size of a PDCP PDU excluding Add Header in FIG. 2 and the maximum size of a PDCP PDU excluding Add Header and all PDCP Headers in FIG. 2 are indicated, PDCP SDUs can be concatenated to fit the corresponding size.

For another example, the PDCP entity, when receiving user data from higher layers, determines if concatenation has been configured and/or the number of PDCP SDUs for concatenation (e.g., the concatenated PDCP SDU(s)). maximum/total number of concatenated header uncompressed PDCP SDU(s), maximum/total number of concatenated header-compressed PDCP SDU(s)) if indicated. PDCP SDUs can be concatenated to suit

For another example, when receiving user data from a higher layer, the PDCP entity may concatenate PDCP SDUs in units of time if concatenation is configured and/or if a time unit for concatenation is indicated. . (It can be concatenated in units of time within the above size. The unit of time can be a slot/minislot/subframe/random transmission opportunity/unit or a multiple of the unit. When receiving user data, when receiving the first PDCP SDU to be concatenated, starts the corresponding timer PDCP entity associates the COUNT value with TX_NEXT corresponding to this PDCP SDU PDCP entity performs header compression The PDCP entity MAY concatenate PDCP SDUs to fit the indicated/configured size If the PDCP SDUs are concatenated to the maximum size before the timer expires, MAY restart the timer if the timer expires Performs the following PDCP functional operations (e.g. integrity protection and ciphering) on concatenated PDCP SDUs.

For another example, when the PDCP entity receives user data from a higher layer, when receiving the first PDCP SDU concatenated in the above-mentioned time unit, the PDCP entity associates a COUNT value with TX_NEXT corresponding to this PDCP SDU can make it Alternatively, the PDCP entity may associate a COUNT value with TX_NEXT corresponding to the concatenated PDCP PDU containing this PDCP SDU. The PDCP entity performs header compression. A PDCP entity MAY concatenate PDCP SDUs to fit the indicated/configured size. For example, when user data is received from an upper layer within a corresponding time unit and a second PDCP SDU concatenated in the corresponding time unit is received, the PDCP entity performs header compression on this PDCP SDU. (The PDCP SN/COUNT value may be linked to PDCP SDUs. Alternatively, the PDCP SN/COUNT values may be linked to PDCP PDUs (Concatenated PDCP SDUs). This will be described later.). The PDCP entity performs header compression on PDCP SDU(s) received (within the maximum size/number) within the corresponding time unit. If PDCP SDUs are concatenated according to the maximum size/number in that time unit, upon receipt of the next PDCP SDU following the concatenated PDCP SDUs, the PDCP entity will concatenate the COUNT value to TX_NEXT corresponding to this PDCP SDU. can Alternatively, the PDCP entity may associate a COUNT value with TX_NEXT corresponding to the concatenated PDCP PDU containing this PDCP SDU. The PDCP entity performs header compression. A PDCP entity MAY concatenate PDCP SDUs to fit the indicated/configured size. A PDCP entity may perform integrity protection and ciphering on concatenated header uncompressed PDCP SDUs. A PDCP entity may perform integrity protection and ciphering on concatenated header compressed PDCP SDUs.

For another example, the PDCP entity receives one PDCP SDU from an upper layer, performs header compression, integrity protection, and ciphering before attaching a sequence number to the PDCP SDU, attaching a sequence number, and performing header compression. Concatenation may be performed at one of the following points: before performing integrity protection and ciphering, and before adding a PDCP header.

For another example, the PDCP entity receives one PDCP SDU from an upper layer, performs header compression on the corresponding PDCP SDU, and performs integrity protection and ciphering before performing header compression and integrity protection and ciphering. and before adding the PDCP header.

For another example, the PDCP entity receives one PDCP SDU from a higher layer, performs header compression on the corresponding PDCP SDU, and performs header compression on the corresponding PDCP SDU, and the corresponding PDCP SDU/concatenated PDCP SDUs/PDCP SDUs are concatenated. Before attaching a sequence number to the nested PDCP PDU, before performing integrity protection and ciphering on the PDCP PDU to which the corresponding PDCP SDU/concatenated PDCP SDUs/PDCP SDUs are concatenated, integrity protection and ciphering are performed, Concatenation can be performed either before adding the PDCP header.

Any of the embodiments described above may be arbitrarily combined/combined (and/or) to perform concatenation. For example, if the size and number are specified, concatenation can be made according to which of the size and number satisfies the condition first. (e.g. size 9000 bytes, when 10 numbers are indicated at the same time, if only 1500 byte PDCP SDUs are received in the transmit buffer, 6*1500 bytes=9000 bytes, so 6 PDCP SDUs can be concatenated into one PDCP PDU)

Integrity protection/ciphering handling for concatenated data units (PDCP SDUs)

One or more concatenated PDCP SDUs included in one PDCP PDU may be considered and processed as one PDCP SDU. For convenience of description, this is denoted as a Concatenated Data Unit (CDU). This is for convenience of description and may be replaced with any other name. The CDU may indicate a part except for the Add header in FIG. 2 (PDCP Header|PDCP SDU |PDCP Header|PDCP SDU |PDCP Header|PDCP SDU). The CDU may indicate a part (PDCP SDU|PDCP SDU|PDCP SDU) except for the Add header and each PDCP header in FIG. 2 . The CDU may represent a part (PDCP SDU|PDCP SDU|PDCP SDU) except for the Updated header in FIG. 5 .

For example, when a PDCP entity receives one PDCP SDU from an upper layer, it may start a discard timer associated with the PDCP SDU. The PDCP entity may associate a COUNT value with TX_NEXT corresponding to this PDCP SDU. A PDCP entity may perform header compression. One ROHC compressed packet is associated with the same PDCP SN and COUNT value for that PDCP SDU.

For another example, when receiving PDCP SDU(s) from a higher layer, the PDCP entity may determine/perform concatenation according to the above-described embodiment. Alternatively, the concatenation can be determined/performed in any way. A discard timer associated with the concatenated PDCP SDU(s)/CDU/PDCP PDU may be started. The dismiss timer may be started (if concatenated) upon receipt of the first PDCP SDU contained in the concatenated PDCP SDU(s)/CDU/PDCP PDU. Alternatively, the discard timer may be started when receiving the last PDCP SDU included in the concatenated PDCP SDU(s)/CDU/PDCP PDU. Alternatively, the discard timer can be started when concatenating the PDCP SN/COUNT by creating concatenated PDCP SDU(s)/CDU/PDCP PDU. Alternatively, the discard timer may be started when all PDCP SDUs included in the concatenated PDCP SDU(s)/CDU/PDCP PDU are received. Alternatively, the discard timer can be started when concatenating the PDCP SN/COUNT by creating concatenated PDCP SDU(s)/CDU/PDCP PDU. Alternatively, the discard timer may be started before/after performing header compression on all PDCP SDUs included in the concatenated PDCP SDU(s)/CDU/PDCP PDU. Alternatively, the discard timer can be started before ciphering/integrity protection begins by creating a concatenated PDCP SDU(s)/CDU/PDCP PDU.

For another example, the PDCP entity may associate each COUNT value with TX_NEXT corresponding to each PDCP SDU. A PDCP entity may perform header compression. One ROHC compressed packet can be associated with the same PDCP SN and COUNT value for that PDCP SDU. Each ROHC compressed packet included in the concatenated PDCP SDU(s)/CDU/PDCP PDU may be associated with a different PDCP SN and COUNT value.

For another example, the PDCP entity may associate a COUNT value with TX_NEXT corresponding to the first PDCP SDU. Each PDCP SDU may have the same TX_NEXT. Each PDCP SDU may be associated with the same corresponding COUNT value. A PDCP entity may perform header compression. Each ROHC compressed packet included in the concatenated PDCP SDU(s)/CDU/PDCP PDU may be associated with the same PDCP SN and COUNT value.

For another example, the PDCP entity may associate a COUNT value with TX_NEXT corresponding to the last PDCP SDU. Each PDCP SDU may have the same TX_NEXT. Each PDCP SDU may be associated with the same corresponding COUNT value. A PDCP entity may perform header compression. Each ROHC compressed packet included in the concatenated PDCP SDU(s)/CDU/PDCP PDU may be associated with the same PDCP SN and COUNT value. In another example, a PDCP entity corresponds to each PDCP SDU. Each COUNT value can be linked with TX_NEXT. The PDCP entity may perform header compression on one PDCP SDU using/in association with the corresponding COUNT value. After header compression is performed on the first PDCP SDU included in the concatenated PDCP SDU(s)/CDU, TX_NEXT is increased by 1. The PDCP entity may perform header compression on a second PDCP SDU included in the concatenated PDCP SDU(s)/CDU/PDCP PDU using/in conjunction with the corresponding COUNT value. After header compression is performed on the second PDCP SDU included in the concatenated PDCP SDU(s)/CDU/PDCP PDU, TX_NEXT is incremented by 1. You can keep doing this until you reach the max size/max number. Alternatively, TX_NEXT may be increased by 1 whenever header compression is performed on the concatenated PDCP SDU.

For another example, the PDCP entity may perform integrity protection/ciphering using TX_NEXT to be allocated/allocated/corresponding to the concatenated PDCP SDU(s)/CDU/PDCP PDU. The PDCP entity may perform integrity protection/ciphering using one and the same TX_NEXT linked to the concatenated PDCP SDU(s)/CDU/PDCP PDU. Alternatively, the PDCP entity may perform integrity protection/ciphering using TX_NEXT corresponding to the first PDCP SDU in the concatenated PDCP SDU(s)/CDU/PDCP PDU. Alternatively, the PDCP entity may perform integrity protection/ciphering using TX_NEXT corresponding to the last PDCP SDU in the concatenated PDCP SDU(s)/CDU/PDCP PDU.

The ciphered data unit consists of the MAC-I and the data portion of the PDCP Data PDU (except for the SDAP Header and SDAP Control PDU if the PDCP SDU contains them). Parameters required by PDCP for downlink and uplink ciphering/desiphering are inputs to the ciphering algorithm. Inputs required for the ciphering function include a COUNT value and DIRECTION (direction of the transmission: set as specified in TS 33.501). Parameters required by PDCP provided by RRC include BEARER (using RB identity-1 as a radio bearer identifier) and KEY (the ciphering keys for the control plane and for the user plane are K_RRCenc and K_UPenc, respectively) .

The integrity protected data unit is the PDU header and the data part of the PDU before ciphering. Parameters required by PDCP for downlink and uplink integrity protection and verification are inputs to the integrity protection algorithm. Inputs required for the integrity protection function include a COUNT value and DIRECTION (direction of the transmission: set as specified in TS 33.501). Parameters required by PDCP provided by RRC include BEARER (using RB identity-1 as a radio bearer identifier) and KEY (the ciphering keys for the control plane and for the user plane are K_RRCenc and K_UPenc, respectively) . When transmitting, the UE calculates the MAC-I field value. And when receiving, it calculates the X-MAC based on the input parameters. If the calculated X-MAC corresponds to the MAC-I, integrity protection is successfully verified. (At transmission, the UE computes the value of the MAC-I field and at reception it verifies the integrity of the PDCP Data PDU by calculating the X-MAC based on the input parameters as specified above. If the calculated X-MAC corresponds to the received MAC-I, integrity protection is verified successfully.)

COUNT value used as input for ciphering/integrity protection is assigned/assigned/corresponding to concatenated PDCP SDU(s)/CDU TX_NEXT is assigned to concatenated PDCP SDU(s)/CDU can One TX_NEXT may be used in conjunction with one concatenated PDCP SDU(s)/CDU/PDCP PDU. Alternatively, TX_NEXT may be used in conjunction with the number of PDCP SDU(s) concatenated to one concatenated PDCP SDU(s)/CDU/PDCP PDU.

For another example, the PDCP entity may perform integrity protection/ciphering using one TX_NEXT to be allocated/assigned/corresponding to the concatenated PDCP SDU(s)/CDU. The PDCP entity sets the PDCP SN to TX_NEXT modulo 2 ^{[ pdcp-SN-SizeUL ]} in its PDCP PDU. Increase TX_NEXT by 1. Submit the resulting PDCP Data PDU to the lower layer (RLC entity).

For another example, the PDCP entity may perform integrity protection/ciphering using the first order/shortest TX_NEXT among corresponding values in the concatenated PDCP SDU(s)/CDU/PDCP PDU. The PDCP entity sets the PDCP SN to TX_NEXT modulo 2 ^{[ pdcp-SN-SizeUL ]} in its PDCP PDU. Increase TX_NEXT by the number of concatenated PDCP SDUs. Submit the resulting PDCP Data PDU to the lower layer (RLC entity).

For another example, the PDCP entity may perform integrity protection/ciphering by using the last order/largest TX_NEXT among corresponding values in the concatenated PDCP SDU(s)/CDU/PDCP PDU. The PDCP entity sets the PDCP SN in that PDCP PDU to TX_NEXT modulo 2 ^{[ pdcp-SN-SizeUL ]} or (TX_NEXT-number of concatenated PDCP SDUs) modulo 2 ^{[ pdcp-SN-SizeUL ]} . Increase TX_NEXT by the number of concatenated PDCP SDUs. Submit the resulting PDCP Data PDU to the lower layer (RLC entity).

For another example, the PDCP entity may perform header compression. One ROHC compressed packet can be associated with the same PDCP SN and COUNT value for that PDCP SDU. The PDCP entity may associate each COUNT value with TX_NEXT corresponding to each concatenated PDCP SDU(s)/CDU/PDCP PDU. Here, TX_NEXT may indicate a state variable indicating a COUNT value of the next concatenated PDCP SDU(s)/CDU/PDCP PDU to be transmitted.

For another example, the PDCP entity may perform header compression. One ROHC compressed packet can be associated with the same PDCP SN and COUNT value for that PDCP SDU. The PDCP entity may associate each COUNT value with TX_NEXT corresponding to each concatenated PDCP SDU(s)/CDU/PDCP PDU. Here, TX_NEXT may indicate a state variable indicating a COUNT value of the next concatenated PDCP SDU(s)/CDU/PDCP PDU to be transmitted including the corresponding PDCP SDU if the corresponding PDCP SDU is concatenated.

For another example, the PDCP entity may perform header compression. One ROHC compressed packet can be associated with the same PDCP SN and COUNT value for that PDCP SDU. The PDCP entity may associate each COUNT value with TX_NEXT corresponding to each concatenated PDCP SDU(s)/CDU/PDCP PDU. Where TX_NEXT is the next concatenated PDCP SDU(s)/CDU/ to be transmitted for the concatenated PDCP SDU(s)/CDU/PDCP PDU containing the PDCP SDU, if the corresponding PDCP SDU is concatenated. It may indicate a state variable indicating the COUNT value of the PDCP PDU.

Receive operation

When receiving a PDCP Data PDU from a lower layer, the receiving PDCP entity must be able to determine the COUNT value of the received PDCP Data PDU. The COUNT value (RCVD_COUNT) of the received PDCP Data PDU indicates the received HFN and the received sequence number (RCVD_SN). (RCVD_COUNT: the COUNT of the received PDCP Data PDU = [RCVD_HFN, RCVD_SN]). The received HFN is calculated by the PDCP entity as the HFN of the received PDCP Data PDU. The received sequence number represents the PDCP SN of the received PDCP Data PDU included in the PDU header.

After the receiving PDCP entity determines the COUNT value of the received PDCP Data PDU, the receiving PDCP entity performs deciphering and integrity verification of the PDCP Data PDU using COUNT = RCVD_COUNT.

If the COUNT value (RCVD_COUNT) of the received PDCP Data PDU was not delivered to the upper layers, the COUNT value of the first PDCP SDU (RX_DELIV: This state variable indicates the COUNT value of the first PDCP SDU not delivered to the upper layers, but still waited for) or if the corresponding PDCP Data PDU was previously received, discard the PDCP Data PDU. (

- if RCVD_COUNT < RX_DELIV; or

- if the PDCP Data PDU with COUNT = RCVD_COUNT has been received before:

- discard the PDCP Data PDU; )

In one example, if not discarded, the receiving PDCP entity stores the resulting PDCP SDU in a receive buffer. If the COUNT value of the received PDCP Data PDU (RCVD_COUNT) is greater than or equal to the COUNT value of the next PDCP SDU expected to be received (RX_NEXT: This state variable indicates the COUNT value of the next PDCP SDU expected to be received), RX_NEXT can be updated by RCVD_COUNT + 1.

For another example, if not discarded, the receiving PDCP entity stores the resulting PDCP SDU in a receive buffer. If the COUNT value of the received PDCP Data PDU (RCVD_COUNT) is greater than or equal to the COUNT value of the next PDCP SDU expected to be received (RX_NEXT: This state variable indicates the COUNT value of the next PDCP SDU expected to be received), RX_NEXT RCVD_COUNT + corresponding concatenated PDCP SDU(s)/CDU by the number of concatenated PDCP SDU(s).

For another example, if not discarded, the receiving PDCP entity stores the resulting PDCP SDUs in a receive buffer. If the COUNT value of the received PDCP Data PDU (RCVD_COUNT) is the COUNT value of the next concatenated PDCP SDU(s)/CDU/PDCP PDU expected to be received (RX_NEXT: This state variable indicates the COUNT value of the next concatenated If greater than or equal to PDCP SDU(s)/CDU/PDCP PDU expected to be received), RX_NEXT may be updated by RCVD_COUNT + 1. For another example, if the COUNT value (RCVD_COUNT) of the received PDCP Data PDU is the same as the COUNT value (RX_DELIV) of the first PDCP SDU waiting for delivery to the upper layer, header decompression is performed (if it was not previously decompressed), If not), it is passed to the upper layer in ascending order of the associated COUNT value. RX_DELIV is updated with the COUNT value of the first PDCP SDU not delivered to the upper layer. (

If the received PDCP Data PDU with COUNT value = RCVD_COUNT is not discarded above, the receiving PDCP entity shall:

- store the resulting PDCP SDU in the reception buffer;

- if RCVD_COUNT >= RX_NEXT:

- update RX_NEXT to RCVD_COUNT + 1.

- if outOfOrderDelivery is configured:

- deliver the resulting PDCP SDU to upper layers after performing header decompression using EHC.

- if RCVD_COUNT = RX_DELIV:

- deliver to upper layers in ascending order of the associated COUNT value after performing header decompression, if not decompressed before;

- all stored PDCP SDU(s) with consecutively associated COUNT value(s) starting from COUNT = RX_DELIV;

- update RX_DELIV to the COUNT value of the first PDCP SDU which has not been delivered to upper layers, with COUNT value > RX_DELIV; )

For another example, if the COUNT value (RCVD_COUNT) of the received PDCP Data PDU is equal to the COUNT value (RX_DELIV) of the first PDCP SDU waiting for delivery to the upper layer, header decompression is performed for each PDCP SDU ( If it has not been previously decompressed), it is passed to the upper layer in ascending order of the associated COUNT value. Or, it is delivered to the upper layer according to the received order. RX_DELIV is updated with the COUNT value of the first PDCP SDU not delivered to the upper layer.

For another example, if the COUNT value (RCVD_COUNT) of the received PDCP Data PDU is the same as the COUNT value (RX_DELIV) of the first concatenated PDCP SDU(s)/CDU/PDCP PDU that is waiting but not delivered to the upper layer, the corresponding Performs header decompression on each PDCP SDU included in the concatenated PDCP SDU(s)/CDU/PDCP PDU (if not previously decompressed) and delivers them to upper layers in ascending order of the associated COUNT value. . Or, it is delivered to the upper layer according to the received order. RX_DELIV is updated with the COUNT value of the first concatenated PDCP SDU(s)/CDU/PDCP PDU not delivered to the upper layer.

PDCP header format

To provide PDCP concatenation, the transmitting/receiving PDCP entity must be able to distinguish each PDCP SDU from multiple PDCP SDUs included/concatenated in one CDU. The transmitting PDCP entity must be able to create a PDCP PDU in which a PDCP header for distinguishing it is created/set, and submit it to a lower layer. The receiving PDCP entity must be able to distinguish each PDCP SDU and deliver it to a higher layer.

For example, the corresponding PDCP header may include a field for distinguishing a conventional PDCP header and a PDCP header supporting PDCP concatenation. The corresponding field may be provided by modifying/changing one R field of FIGS. 3 to 4. By setting the corresponding field, it can be distinguished whether it is a PDCP header for PDCP concatenation. However, this method may be necessary when designating PDCP connectivity as a mandatory UE capability. Through this, a conventional PDCP operation that does not provide concatenation and a PDCP operation that provides concatenation can be provided through one header format.

For another example, PDCP connection can be defined as a selective UE capability, and configuration information for this can be configured by instructing the terminal through RRC signaling (RRC reconfiguration message or system information). The radio capability information of the terminal is transmitted from the terminal to the base station at the request of the base station (when the corresponding base station does not receive the corresponding terminal capability to the core network, for example, first access), and is stored in the base station and the core network entity. Thereafter, whenever the terminal in the idle state transitions to the connected state, the base station can receive it through the core network. For a terminal supporting PDCP concatenation, the base station may transmit including indication information for PDCP concatenation configuration for a specific data radio bearer through an RRC reconfiguration message. The terminal receiving the corresponding information can transmit and receive the corresponding user data through PDCP concatenation using the corresponding information.

For another example, when a corresponding base station broadcasts that the base station supports PDCP connectivity through system information, the terminal may transmit the corresponding terminal capability information to the base station.

For another example, the corresponding PDCP header may be configured to have a fixed size. For high-speed processing of user data, it may be desirable for a PDCP header to have a fixed size in order to effectively process any PDCP function (ciphering, integrity protection, etc.) with a high processing load. When the PDCP header has a fixed size, pre-processing of the PDCP function may be facilitated before receiving an instruction (eg, scheduling grant) from the lower layer from the base station or before submitting data to the lower layer.

For example, the maximum size/number of PDCP SDUs concatenated into one PDCP PDU may be limited/controlled/instructed. The base station may configure the information by instructing the terminal through an RRC message. Alternatively, the corresponding information may be fixedly pre-configured in the terminal and the base station. For example, 9000 bytes corresponding to the maximum supported size of one PDCP SDU can be used as the value (one of the values).

For another example, the corresponding PDCP header may include a field for indicating the number of PDCP SDUs concatenated in one PDCP PDU. If the corresponding number is 4, the number of concatenated PDCP SDUs can be distinguished using 2 bits. If the corresponding number is 8, the number of concatenated PDCP SDUs can be identified using 3 bits. If an extension field is used to indicate whether (additional) data follows when concatenating 4/8 PDCP SDUs, there is an advantage in that the number of bits can be reduced compared to the need for 4/8 bits. The corresponding value may be configured by being instructed by the base station to the terminal. Alternatively, the value may be (pre) configured as a fixed value in the base station and the terminal.

For another example, the length field may have a 14-bit value. The maximum supported size of one PDCP SDU in NR is 9000 bytes. If you can use it as is. Alternatively, when PDCP concatenation is supported, the maximum supported size for one PDCP SDU may be configured by the base station. Through 14 bits, it is possible to distinguish up to 16,384 bits of the 14th power of 2. Therefore, values within 9000 bytes can be distinguished. For another example, the length field may have an 11-bit value. Realistically, since the packet size often has a level of 1500 bytes, up to 2048 bits of 2's 11th power can be distinguished through 11 bits. If the transmitting terminal includes a value greater than or equal to 9000 bytes/1500 bytes, the receiving terminal may ignore it. Alternatively, you can consider this as the maximum supported size or 1500 bytes.

The corresponding value may be configured by being instructed by the base station to the terminal. Alternatively, the value may be (pre) configured as a fixed value in the base station and the terminal.

For another example, specific/some/all PDCP SDUs may have a (fixed/configured) length indicator/index value/table grouped according to IP packet/packet size type. For example, 1 as a length indicator/index to indicate PDCP SDUs of small bytes (e.g. 1 byte, 1 byte or less) such as TCP ACK, and 2 ( Alternatively, n, where n is an arbitrary natural number) may be assigned to include a corresponding length indicator/index number. Alternatively, a specific value may be indicated as a length indicator/index for indicating PDCP SDUs in a specific byte range. The corresponding value may be configured by being instructed by the base station to the terminal. Alternatively, the value may be (pre) configured as a fixed value in the base station and the terminal. A length field may be included for non-grouped PDCP SDUs. The number of PDCP SDUs not grouped in the header may be included.

Hereinafter, another embodiment of the present invention will be described.

For AM DRBs configured to send PDCP status reports on the uplink at higher layers, the receiving PDCP entity SHOULD trigger the PDCP status reporting when:

- When a higher layer requests a PDCP entity reset;

- When a higher layer requests PDCP data recovery;

- When a higher layer requests uplink data switching;

- when the upper layer reconfigures the PDCP entity to release the DAPS when the corresponding information is configured;

Status reporting can be provided as follows considering the PDCP concatenated PDCP PDU.

If a PDCP status report is triggered, the receiving PDCP entity compiles the PDCP status report as indicated below.

- Set the FMC (First Missing COUNT) field. For example, it may be set as a COUNT value (e.g. RX_DELIV) of the first PDCP SDU not delivered to the upper layer but waiting/not received. Another example is if the (first) PDCP SDU not delivered to the upper layer but queued/not received is concatenated, the PDCP PDU containing the first PDCP SDU not delivered but queued/not received to the upper layer. It can be set as a COUNT value for . Another example is if a (first) PDCP SDU not delivered to the upper layer but queued/received (first) PDCP SDU not delivered to the upper layer but queued/not received (including the corresponding PDCP SDUs) is concatenated. It can be set to the COUNT value of the first PDCP SDU included in the first PDCP PDU. Another example is if a (first) PDCP SDU not delivered to the upper layer but queued/received (first) PDCP SDU not delivered to the upper layer but queued/not received (including the corresponding PDCP SDUs) is concatenated. It can be set to the COUNT value of the last PDCP SDU included in the first PDCP PDU. For another example, it can be set to the COUNT value (e.g. RX_DELIV) of the first concatenated PDCP SDU(s)/CDU/PDCP PDU that has not been delivered to the upper layer but is on standby/not received.

- if the value set by FMC (e.g. RX_DELIV) is less than the COUNT value (e.g. RX_NEXT) of the next PDCP SDU expected to be received; or if the value set by FMC (e.g. RX_DELIV) is less than the COUNT value (e.g. RX_NEXT) of the next concatenated PDCP SDU(s)/CDU/PDCP PDU expected to be received;

-- For example, allocating a Bitmap field with a bit length equal to the number of COUNTs, not including the first lost PDCP SDU and including the last out of sequence PDCP SDUs up to here. of length in bits equal to the number of COUNTs from and not including the first missing PDCP SDU up to and including the last out-of-sequence PDCP SDUs, rounded up to the next multiple of 8, or up to and including a PDCP SDU for which the resulting PDCP Control PDU size is equal to 9000 bytes, whichever comes first). For another example, a bitmap field having a bit length equal to the number of COUNTs is allocated, not including the first lost PDCP PDU and including the last out-of-sequence PDCP PDUs up to here. For another example, a bitmap field having a bit length equal to the number of COUNTs is allocated, not including the first lost PDCP SDU and including the last out of sequence PDCP SDUs/PDUs up to here. As another example, subtract 1 from the number of concatenated PDCP SDUs for each PDCP PDU to the number of COUNTs, not including the first lost PDCP SDU and including the last out of sequence PDCP SDUs from this to here. Allocates a bitmap field with a bit length equal to the sum of all values. For example, if 3 PDCP PDUs are lost consecutively including FMC/1st lost PDCP PDU, and if 3 lost PDCP PDUs each contain 5 PDCP SDUs, a total of 15 PDCP SDUs are lost. can indicate If the status reporting is configured as a bitmap in units of PDCP SDUs, 14 bitmaps are required since the first lost PDCP SDU is not included. If COUNT is set in units of PDCP PDU/CDU/PDCP SDUs for concatenated PDCP SDUs, or if batch processing is performed in consideration of units of PDCP PDU/CDU/PDCP SDUs, the first COUNT number in the number of COUNTs (3) is considered. The value obtained by subtracting (1) plus the value obtained by subtracting 1 from the number of PDCP SDUs included in each PDCP PDU (12=3*(5-1)) (14=3-1+3*(5 -1)) can be. As another example, including the last out of sequence concatenated PDCP SDU(s)/CDU/PDCP PDU from which the first lost concatenated PDCP SDU(s)/CDU/PDCP PDU is not included, here , allocates a bitmap field with a bit length equal to the number of COUNTs.

-- For example, 0 may be set in the bitmap field for all PDCP SDUs that are not received and, optionally, PDCP SDUs for which header compression has failed. For another example, if COUNT is set in units of PDCP PDU/CDU/PDCP SDUs for concatenated PDCP SDUs, or if batch processing is performed considering units of PDCP PDU/CDU/PDCP SDUs, the bit for all unreceived PDCP PDUs You can set 0 in the map field.

-- For all received PDCP SDUs, 1 may be set in the bitmap field. For another example, if COUNT is set in units of PDCP PDU/CDU/PDCP SDUs for concatenated PDCP SDUs, or if batch processing is performed considering units of PDCP PDU/CDU/PDCP SDUs, for all received PDCP PDUs, bit You can set 1 in the map field.

A PDCP status report may be submitted to lower layers when sending the first PDCP PDU.

For another example, a PDCP status report considering PDCP connectivity may be provided separately from a conventional PDCP status report. Instruction information for this may be configured in the terminal through an RRC message. Alternatively, when any information for instructing/configuring PDCP connection is configured, a corresponding PDCP status report may be provided. Corresponding information can distinguish the PDU TYPE by using a value different from the conventional value (000). For example, it can be distinguished by using one of the values 011-111 remaining as reserved values.

If the corresponding information is configured, the terminal can transmit the PDCP status reporting using the corresponding PDCP status report format.

When an RRC connected state terminal moves, a handover procedure may be performed. Referring to FIG. 7 , handover can be divided into a handover preparation step, a handover execution step, and a handover completion step.

In the handover execution step, the source base station may trigger handover by transmitting an RRC reconfiguration message including information necessary for accessing the target cell.

<Devices to which this specification may be applied> General>

Hereinafter, "devices" to which "this" specification can be "applied" will be described.

8 shows a configuration block diagram of a processor in which the disclosure of this specification is implemented.

As is known with reference to Figure 8, the processor 1020 in which the disclosure of this specification is implemented includes (circuits) the implementation of the "proposed" function, "procedure" and/or "method" described in this specification. can do. For example, the “processor 1020” may “include” the “first” circuit 1020-1, the “second” circuit 1020-2, and the “third” circuit 1020-3.

Also, although not shown, the processor 1020 may include "more" circuits. Each "circuit" may include "a plurality of" transistors.

The processor 1020 may be referred to as an application-specific integrated circuit (ASIC) or an application processor (AP), and includes at least one of a digital signal processor (DSP), a central processing unit (CPU), and a graphics processing unit (GPU). can do.

9 shows a wireless communication device according to an embodiment of the present specification.

Referring to Figure 9, the 'wireless' communication system may include a 'first' device 100a and a 'second' device 100b.

The first device 100a is a base station, a network node, a transmitting terminal, a receiving terminal, a wireless device, a wireless communication device, a vehicle, a vehicle equipped with an autonomous driving function, an aerial vehicle, an aerial (unmanned connected car), and a drone. UAV), AI (Artificial Intelligence) 　 Module, 　 Robot, AR (Augmented Reality) 　 Device, VR (Virtual Reality) 　 Device, MR (Mixed Reality) 　 Device, Hologram 　 Device, 　 Public 　 Safety Device, MTC 　 Device, IoT 　 Device, 　 Medical Device, 　 PIN There may be “devices” related to “tech” devices (or “financial” devices), “security” devices, “climate/environment” devices, 5G “services” or “devices” related to “the 4th” industrial “revolution” field other than that.

The second device 100b is a base station, a network node, a transmitting terminal, a receiving terminal, a wireless device, a wireless communication device, a vehicle, a vehicle equipped with an autonomous driving function, an aerial vehicle, an aerial (unmanned connected car), and a drone. UAV), AI (Artificial Intelligence) 　 Module, 　 Robot, AR (Augmented Reality) 　 Device, VR (Virtual Reality) 　 Device, MR (Mixed Reality) 　 Device, Hologram 　 Device, 　 Public 　 Safety Device, MTC 　 Device, IoT 　 Device, 　 Medical Device, 　 PIN There may be “devices” related to “tech” devices (or “financial” devices), “security” devices, “climate/environment” devices, 5G “services” or “devices” related to “the 4th” industrial “revolution” field other than that.

The first apparatus 100a may include at least one processor, such as a processor 1020a, at least one more than one memory, such as the memory 1010a, and at least one or more transceiver, such as the transceiver 1031a. The processor 1020a may perform the aforementioned functions, procedures, and/or methods. The processor 1020a may perform "one" or more "protocol". For example, the processor 1020a may perform "one" or more "layers" of a "wireless" interface "protocol." The “memory 1010a” is connected to the “processor 1020a” and can store “information” and/or “commands” in “various” forms. The “transceiver 1031a” may be “connected” to the “processor 1020a” and controlled to “transmit” and “receive” a “wireless” signal.

The second device 100b includes at least one processor, such as the processor 1020b, at least one memory device, such as the memory 1010b, and at least one transceiver, such as the transceiver 1031b. The processor 1020b may perform the aforementioned functions, procedures, and/or methods. The processor 1020b may implement "one" or more "protocols". For example, the processor 1020b may implement "one" or more "layers" of a "wireless" interface "protocol." The “memory 1010b” is connected to the “processor 1020b” and can store “information” and/or “commands” in “various” forms. The “transceiver 1031b” may be “connected” to the “processor 1020b” and controlled to “transmit” and “receive” a “wireless” signal.

The memory 1010a and/or the memory 1010b may be connected to each inside or outside of the processor 1020a and/or/or the processor 1020b, or other processors through various technologies such as wired or wireless connection. It may be connected to.

The "first" device 100a and/or the "second" device 100b may have "one" or more "antennas". For example, "antenna 1036a" and/or "antenna 1036b" may be configured to "transmit" and "receive" "wireless" signals.

10 illustrates a block configuration diagram of a network node according to an embodiment of the present specification.

In particular, in Figure 10, when the base station is divided into a central unit (CU) and a distributed unit (DU), it is a diagram that illustrates in more detail the node of the network in the previous figure W.

Referring to Figure 10, the base stations W20 and W30 may be connected to the core network W10, and the base station W30 may be connected to the neighboring base station W20. For example, the interface between the base station (W20, W30) and the core network (W10) can be referred to as NG, and the interface between the base station (W30) and the neighboring base station (W20) can be referred to as Xn.

The base station W30 may be "divided" into "CU (W32)" and "DU (W34, W36)". In other words, the base station W30 can be hierarchically separated and operated. The CU (W32) may be connected to one or more DUs (W34, W36), and, for example, the interface between the CU (W32) and the DUs (W34, W36) may be referred to as F1.

The CU (W32) can perform the function of the “upper layers” of the base station, and the DUs (W34, W36) can “perform” the function of the “lower layers” of the base station. For example, the CU (W32) is a “logical” node that hosts “radio resource control (RRC), service data adaptation protocol (SDAP)” and “packet data convergence protocol (PDCP)” layers of a base station (eg, “gNB”). There can be “number”, and DUs (W34, W36) can be “logical” nodes that “host” the “radio link control (RLC), media access control (MAC)” and “physical (PHY)” layers of the “base station.” Alternatively, the CU W32 may be a “logical” node hosting the “RRC” and “PDCP” layers of a base station (eg, “en-gNB”).

The operation of the DUs (W34, W36) can be partially controlled by the CU (W32). One "DU (W34, W36)" can support "one" or more "cells". One "cell" can be "supported" only by "one" DU (W34, W36). One DU (W34, W36) may be connected to one CU (W32), and with suitable implementation, one DU (W34, W36) may be connected to multiple CUs.

Figure 11 illustrates a "block" configuration diagram of a "communication" device according to "one" embodiment of the present specification.

In particular, in Figure 11, it is a drawing that exemplifies in more detail the terminal of Figure 10 earlier.

The terminal includes a memory 1010, a processor 1020, a transceiver 1031, a power management module 1091, a battery 1092, a display 1041, an input unit 1053, a speaker 1042, and a microphone 1052, It includes a SIM (subscriber identification module) “card” and “one” or more “antennas”.

The processor 1020 may be configured to implement "proposed" functions, "procedures" and/or "methods" described herein. Layers of the radio interface protocol may be implemented in the processor 1020 . The processor 1020 may include "application-specific integrated circuits (ASICs)", "other" chipsets, "logic" circuits, and/or "data" processing devices. The processor 1020 may be an application processor (AP). The processor 1020 may include at least one of a digital signal processor (DSP), a central processing unit (CPU), a graphics processing unit (GPU), and a modulator and demodulator (Modem). Examples of the processor 1020 include the SNAPDRAGONTM series processor prepared by QualComm®, the Exynostm series processor prepared by Samsung, A series processor prepared by Apple®, and Heliotm Series Processor prepared by Mediaatek®, Intel®, Intel® The "ATOMTM" series of "processors" manufactured by or "the corresponding" next-generation "processors" may be.

The power management module 1091 manages power for the processor 1020 and/or the transceiver 1031. The battery 1092 supplies "power" to the "power" management module 1091 . The display 1041 outputs the "processed" result by the "processor 1020". The input unit 1053 receives input to be used by the processor 1020 . The input unit 1053 can be displayed on the display 1041. A SIM card is an integrated circuit used to "securely" store "international mobile subscriber identity (IMSI)" and its associated "keys" that are used to identify and authenticate "subscribers" in mobile "phone" devices such as "mobile phones" and computers. You can also store your “contacts” information on many “SIM” cards.

The memory 1010 is operatively coupled with the processor 1020 and stores various “information” for operating the processor 610. Memory 1010 may include read-only memory (ROM), random access memory (RAM), flash memory, memory card, storage medium, and/or other storage devices. If the embodiment is implemented as “software,” the technologies described in “this specification” may be “implemented” as a “module” (eg, “procedure”, “function”, etc.) that performs “functions” described in “this” specification. A module may be stored in memory 1010 and executed by processor 1020 . The memory 1010 may be implemented in the processor 1020. Alternatively, the memory 1010 may be implemented outside the processor 1020, and may be “communicatively” connected to the processor 1020 through various means known in the field of technology.

The speaker 1042 outputs the "sound" processed by the processor 1020 and the related "result". The microphone 1052 receives input related to sound to be used by the processor 1020 .

The user “for example” presses (or “touches”) the “button” of the “input unit 1053” or “by voice activation using the microphone 1052” to input “command” information such as “phone” number “etc.”

The processor 1020 receives this “command” information and processes it to perform “appropriate” functions, such as making a “call” to a “phone” number. Operational data can be "extracted" from the "sim card" or "memory 1010".

In addition, the processor 1020 may display “command” information or “drive” information on the display 1041 for the user to recognize and also for convenience.

<Explanation of terms>

All state variables are non-negative integers, and take values from 0 to [2 ³² - 1].

PDCP Data PDUs are numbered integer sequence numbers (SN) cycling through the field: 0 to [2 ^{[ pdcp-SN-SizeUL ]} - 1] or 0 to [2 ^{[ pdcp-SN-SizeDL ]} - 1] or 0 to [2 ^{[ sl-PDCP-SN-Size ]} - 1].

The transmitting PDCP entity shall maintain the following state variables:

a) TX_NEXT

This state variable indicates the COUNT value of the next PDCP SDU to be transmitted. The initial value is 0, except for SRBs configured with state variables continuation. For target SRB configured with state variables continuation, the initial value is the value stored in PDCP entity for the corresponding source SRB. For source SRB configured with state variables continuation, the initial value is the value stored in PDCP entity for the corresponding target SRB.

The receiving PDCP entity shall maintain the following state variables:

a) RX_NEXT

This state variable indicates the COUNT value of the next PDCP SDU expected to be received. The initial value is 0, except for sidelink broadcast and groupcast, and for SRBs configured with state variables continuation. For NR sidelink communication for broadcast and groupcast, the initial value of the SN part of RX_NEXT is (x +1) modulo (2 ^{[ sl-PDCP-SN-Size ]} ), where x is the SN of the first received PDCP Data PDU . For target SRB configured with state variables continuation, the initial value is the value stored in PDCP entity for the corresponding source SRB. For source SRB configured with state variables continuation, the initial value is the value stored in PDCP entity for the corresponding target SRB.

NOTE: For NR sidelink communication for broadcast and groupcast, it is up to UE implementation to select the HFN part for RX_NEXT such that initial value of RX_DELIV should be a positive value.

b) RX_DELIV

This state variable indicates the COUNT value of the first PDCP SDU not delivered to the upper layers, but still waited for. The initial value is 0, except for sidelink broadcast and groupcast, and for SRBs configured with state variables continuation. For NR sidelink communication for broadcast and groupcast, the initial value of the SN part of RX_DELIV is (x - 0.5 × 2 ^{[ sl-PDCP-SN-Size -1]} ) modulo (2 ^{[ sl-PDCP-SN-Size ]} ) , where x is the SN of the first received PDCP Data PDU. For target SRB configured with state variables continuation, the initial value is the value stored in PDCP entity for the corresponding source SRB. For source SRB configured with state variables continuation, the initial value is the value stored in PDCP entity for the corresponding target SRB.

c) RX_REORD

This state variable indicates the COUNT value following the COUNT value associated with the PDCP Data PDU which triggered t-Reordering . For target SRB configured with state variables continuation, the initial value is the value stored in PDCP entity for the corresponding source SRB. For source SRB configured with state variables continuation, the initial value is the value stored in PDCP entity for the corresponding target SRB.

Claims (1)

In the Packet Data Convergence Protocol (PDCP) object provided to the concatenation function,
Depending on the specific criteria, timing and/or sequence for cascading;
By performing integrity protection and/or cyphering processing for concatenated data units (PDCP SDUs),
A method of transmitting or receiving data by effectively concatenating corresponding Service Data Units (SDUs) in the PDCP object.

Images