t handover) and remove the flush timer. As a result, when the UE receives a PDCP SDU in LTE, it delivers it to a higher layer together with all PDCP SDUs with lower sequence numbers (SNs), regardless of possible gaps and in ascending order of the SNs. Further simplifications were considered, but with Release 8 coming to an end, no further modifications were agreed upon, and the principles of the LTE PDCP reordering window were left untouched since. 5G opened the door for further simplifications: instead of employing reordering in both RLC and PDCP, it was decided to perform reordering only in PDCP. Without hav- ing to reorder packets in RLC, PDCP can now decipher packets on the fly: a gap in the SN sequence of acknowledged packets in RLC no longer stalls delivery toward PDCP, and deciphering operations no longer have to deal with large bursts of data. Further- more, unlike in LTE, it is also possible to configure PDCP not to reorder packets. This is aimed at applications that tolerate out-of-sequence delivery. Another simplification agreed upon in 5G was to rely on the COUNT variable to spec- ify UE behavior (instead of relying on the SN, as in LTE) and to assume that it never wraps around. COUNT is still determined based on the received SN and the state vari- ables as in LTE, but the simplification makes the descriptions lighter and much easier to understand (one can compare Section 5.1.2.1.2 from 3GPP TS 36.323 for LTE with 7.4 PDCP Section 5.2.2.1 from 3GPP TS 38.323 for 5G). With 32 bits for COUNT, approximately 4.3 billion packets can be exchanged before a wraparound occurs. This corresponds to 6442 Gb of data, or 994 days of continuous phone calls (respectively assuming 1500 bytes payload and one packet every 20 ms). There are therefore no practical limitations asso- ciated with the assumption that COUNT does not wrap around. Note that if it did wrap around, the gNB could then simply move the QoS flow to a new radio bearer. 7.4.3 Security Security is guaranteed in the RAN via ciphering and integrity protect