ols (also known as profiles), specific to the layers located above the Layer 2 of the RAN, for example, TCP/IP or RTP/UDP/IP. Header compression was motivated by, and is com- monly used for, voice services to reach comparable coverage as legacy CS services for which no RTP/UDP/IP header was present. Once configured for a DRB, RoHC produces two kinds of packets: PDCP PDU with a compressed header and RoHC feedback packets. The former kind is always associated with a PDCP SN and can be ciphered, whereas the latter is categorized as a PDCP control PDU, does not have an associated SN, and is neither ciphered nor integrity protected. 7.4.5 Duplicates and Status Reports Duplicates can be generated by the protocol layers below PDCP when the acknowledg- ments governing retransmissions fail to reach the transmitter. This typically happens at handover, when there is no time to synchronize the transmission and receive windows of RLC in acknowledged mode (AM) before resetting the RLC entities: the latest PDUs correctly received by the receiver are not known to the transmitter. To guarantee loss- less mobility, those PDUs are always retransmitted after handover, thereby generating duplicates. In order to avoid delivering such duplicates to the upper layers, PDCP discards them based on the received SN: if a PDU with the same SN has already been received, it is dis- carded. Then, to reduce the number of duplicates occurring after handover, PDCP status reports can be exchanged in the target cell after handover. It is important to understand that PDCP status reports are not needed to guarantee lossless mobility; they only help reduce the overhead generated by the duplicates over the air interface. Also, because retransmissions in the target cell can already start in one direction (e.g. downlink) before receiving and processing the PDCP status report from the reverse direction (e.g. uplink), not all duplicates might be eliminated. The overhead of a couple of duplicates over the air interface is, however, acceptable to guarantee low