A second PDCP entity, three frames old, and a completely different header. Seq Num: 0 again -- but nothing about this zero relates to the signaling bearer's. This is a new entity with its own TX_NEXT, created by the RRCReconfiguration of frame 38, and the header it produces is a different shape:

First octet -- SRB 1: 4 reserved bits. DRB 1: a D/C bit plus 5 reserved bits.
Sequence number -- SRB 1: 12-bit. DRB 1: 18-bit.
MAC-I -- SRB 1: present, 4 bytes. DRB 1: not present.
Header size -- SRB 1: 2 bytes. DRB 1: 3 bytes.

1... .... = PDU Type: Data PDU is the D/C bit, and it appears here for the first time in the capture. It exists only on the user plane, because only DRBs can carry a PDCP Control PDU -- a status report or ROHC feedback. Set to 1 it means "the rest of this is user data". MAC-I Present: False is the direct consequence of integrityProtection is NOT present in frame 38's pdcp-Config: this bearer is ciphered but not integrity protected, which is the normal configuration for user data.

One more field, and it is the subtle one. SDAP header: Present, QFI: 2. TS 38.323 §5.8 excludes the SDAP header from ciphering even though it sits inside the PDCP SDU, and the trace bears that out -- Wireshark's Deciphered Data for this frame starts 6000..., the IPv6 version nibble, with the SDAP byte outside it. The QoS Flow Identifier has to stay readable so the receiver can route the packet without deciphering it.

Message Details