|
4G/LTE - Protocol Stack |
||||||||||||||
|
PDCP
I would say PDCP is a kind of interface between inside world and outside world. By "Inside World", I roughly mean "Network Access Network(mainly eNodeB) and Controller for eNodeB", "Network Emulator Hardware and internal firmware", and "Mobile Device (UE)". PDCP is a layer sitting at the top most part of the radio stack. In terms of basic operation, what PDCP does seems very simple. Just "adding the PDCP header to the incoming data and forward to RLC in downlink", or "removing the PDCP header from the incoming packet and forward it to IP layer in case of uplink" is all that it does. However, this layer can be pretty busy stack if you enables various additional features like Integrity, Ciphering and Header Compression. Recently (from Rel 12) as Dual Connectivity (Split Bearer) is supported, this layer has become much busier.
Overview / Overall Functionality
The data coming into the box (eNB or UE) first go through PDCP and then gets into RLC (Downlink Path). Data waiting in RLC trying to go out to the outside world has to go through PDCP to reach outside world(Uplink Path).
In the case when everything goes OK, you don't see any problems in protocol stack and just check protocol log you may think the function of PDCP looks simple and all it does is just to add/remove a small header to each packet and send/recieve it from/to RLC. But if you list up all the detailed functions of PDCP, you would get pretty long list as shown below.
As in other layers, let's start looking into the diagram from 3GPP specification (TS 36.323). The first diagram is as follows.
What are we supposed to do ? Yes, Verbalize it (describe it). i.e, explain the diagram in your own words.
In the following diagram, you see that PDCP is directly connected to RLC Layer (RLC UM and RLC AM). Do you find anything strange or missing ? Yes, PDCP has no connection to RLC TM mode, meaning RLC TM mode data does not go through PDCP.
< 36.323 - Figure 4.2.1.1 - PDCP layer, structure view >
Following Diagram would give you more detailed information about PDCP Operation. Of course, all of the these functionality is listed in the 3GPP specification, but it would not become yours unless you combine these diagrams and the written descriptions in your own words.
Now let's follow through the diagram from left side.
The other side (right side, receiving side) is simply reverse process of transmission process. So I will leave this to the readers to interpret the diagram.
< 36.323 - Figure 4.2.2.1 - PDCP layer, functional view >
RRC Parameters for PDCP Configuration
As you might have noticed at the descriptions in previous section, the PDCP operation can be very simple or pretty complex depending configuration. Then you may ask 'how we can configure PDCP operation ?'. These are configured by Higher Layer Signaling message (i.e, RRC or NAS message). Ciphering and Integrity functionality of PDCP is configured by Security Mode Command message and other PDCP functionality is configured by RRC Connection Reconfiguration or RRC Connection Setup message as shown in the following examples. From very basic PDCP configuration based on Release 8 and pretty complicated configurations based on Release 13, you would notice how PDCP has evolved from old specification to more recent specification. Of course, you don't need to enable all of those features shown in Release 13 example, but it would be obvious that the set of possible options has been expanded greatly as it evolves to recent standard.
< EMM : Security Mode Command >
Security mode command ::= DIVISION +-Security header type ::= V | +-Security header type ::= CHOICE [Plain NAS message, not security protected] +-EPS mobility management protocol discriminator ::= V +-Security mode command message identity ::= V +-Selected NAS security algorithms ::= V | +-Octet1 ::= DIVISION | +-spare ::= FIX [0] | +-Type of ciphering algorithm ::= EPS encryption algorithm EEA0 (null ciphering algorithm) | +-spare ::= FIX [0] | +-Type of integrity protection algorithm ::= EPS integrity algorithm 128-EIA2 +-Spare half octet ::= V +-NAS key set identifier ::= V | +-TSC ::= CHOICE [native security context (for KSI ASME)] | +-NAS key set identifier ::= CHOICE [possible values for the NAS key set identifier 0] +-Replayed UE security capabilities ::= LV +-IMEISV request ::= TV OPTIONAL:Omit +-Replayed nonce UE ::= TV OPTIONAL:Omit +-Nonce MME ::= TV OPTIONAL:Omit
< RRC : Security Mode Command >
+-securityModeCommand-r8 ::= SEQUENCE [0] +-securityConfigSMC ::= SEQUENCE | +-securityAlgorithmConfig ::= SEQUENCE | | +-cipheringAlgorithm ::= ENUMERATED [eea0] | | +-integrityProtAlgorithm ::= ENUMERATED [eia2] | +-EXTENSION ::= SEQUENCE +-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
< RRC Connection Reconfiguration / RRC Connection Setup - Basic Configuration / Release 8 >
+-rrcConnectionReconfiguration-r8 ::= SEQUENCE [001100] +-measConfig ::= SEQUENCE OPTIONAL:Omit +-mobilityControlInfo ::= SEQUENCE OPTIONAL:Omit +-dedicatedInfoNASList ::= SEQUENCE OF SIZE(1..maxDRB[11]) [1] OPTIONAL:Exist +-radioResourceConfigDedicated ::= SEQUENCE [110101] OPTIONAL:Exist | +-srb-ToAddModList ::= SEQUENCE OF SIZE(1..2) [1] OPTIONAL:Exist | +-drb-ToAddModList ::= SEQUENCE OF SIZE(1..maxDRB[11]) [1] OPTIONAL:Exist | | +-DRB-ToAddMod ::= SEQUENCE [11111] | | +-eps-BearerIdentity ::= INTEGER (0..15) [5] OPTIONAL:Exist | | +-drb-Identity ::= INTEGER (1..32) [1] | | +-pdcp-Config ::= SEQUENCE [110] OPTIONAL:Exist | | | +-discardTimer ::= ENUMERATED [infinity] OPTIONAL:Exist | | | +-rlc-AM ::= SEQUENCE OPTIONAL:Exist | | | | +-statusReportRequired ::= BOOLEAN [TRUE] | | | +-rlc-UM ::= SEQUENCE OPTIONAL:Omit | | | +-headerCompression ::= CHOICE [notUsed] | | | | +-notUsed ::= NULL | | +-rlc-Config ::= CHOICE [am] OPTIONAL:Exist | | +-logicalChannelIdentity ::= INTEGER (3..10) [3] OPTIONAL:Exist | | +-logicalChannelConfig ::= SEQUENCE [1] OPTIONAL:Exist | +-drb-ToReleaseList ::= SEQUENCE OF OPTIONAL:Omit | +-mac-MainConfig ::= CHOICE [explicitValue] OPTIONAL:Exist | +-sps-Config ::= SEQUENCE OPTIONAL:Omit | +-physicalConfigDedicated ::= SEQUENCE [0000111010] OPTIONAL:Exist +-securityConfigHO ::= SEQUENCE OPTIONAL:Omit +-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
< RRC Connection Reconfiguration / RRC Connection Setup - Full Configuration / Release 13 >
+-rrcConnectionReconfiguration-r8 ::= SEQUENCE [001100] +-measConfig ::= SEQUENCE OPTIONAL:Omit +-mobilityControlInfo ::= SEQUENCE OPTIONAL:Omit +-dedicatedInfoNASList ::= SEQUENCE OF SIZE(1..maxDRB[11]) [1] OPTIONAL:Exist +-radioResourceConfigDedicated ::= SEQUENCE [110101] OPTIONAL:Exist | +-srb-ToAddModList ::= SEQUENCE OF SIZE(1..2) [1] OPTIONAL:Exist | +-drb-ToAddModList ::= SEQUENCE OF SIZE(1..maxDRB[11]) [1] OPTIONAL:Exist | | +-DRB-ToAddMod ::= SEQUENCE [11111] | | +-eps-BearerIdentity ::= INTEGER (0..15) [5] OPTIONAL:Exist | | +-drb-Identity ::= INTEGER (1..32) [1] | | +-pdcp-Config ::= SEQUENCE [111] OPTIONAL:Exist | | | +-discardTimer ::= ENUMERATED [infinity] OPTIONAL:Exist | | | +-rlc-AM ::= SEQUENCE OPTIONAL:Exist | | | | +-statusReportRequired ::= BOOLEAN [TRUE] | | | +-rlc-UM ::= SEQUENCE OPTIONAL:Exist | | | | +-pdcp-SN-Size ::= ENUMERATED [len7bits] | | | +-headerCompression ::= CHOICE [rohc] | | | | +-rohc ::= SEQUENCE [1] | | | | +-maxCID ::= INTEGER (1..16383) [1] OPTIONAL:Exist | | | | +-profiles ::= SEQUENCE | | | | | +-profile0x0001 ::= BOOLEAN [TRUE] | | | | | +-profile0x0002 ::= BOOLEAN [TRUE] | | | | | +-profile0x0003 ::= BOOLEAN [FALSE] | | | | | +-profile0x0004 ::= BOOLEAN [FALSE] | | | | | +-profile0x0006 ::= BOOLEAN [FALSE] | | | | | +-profile0x0101 ::= BOOLEAN [FALSE] | | | | | +-profile0x0102 ::= BOOLEAN [FALSE] | | | | | +-profile0x0103 ::= BOOLEAN [FALSE] | | | | | +-profile0x0104 ::= BOOLEAN [FALSE] | | | | +-EXTENSION ::= SEQUENCE | | | +-EXTENSION ::= SEQUENCE [1111] | | | +-VERSION-BRACKETS1 ::= SEQUENCE [1] OPTIONAL:Exist | | | | +-rn-IntegrityProtection-r10 ::= ENUMERATED [enabled] OPTIONAL:Exist | | | +-VERSION-BRACKETS2 ::= SEQUENCE [1] OPTIONAL:Exist | | | | +-pdcp-SN-Size-v1130 ::= ENUMERATED [len15bits] OPTIONAL:Exist | | | +-VERSION-BRACKETS3 ::= SEQUENCE [11] OPTIONAL:Exist | | | | +-ul-DataSplitDRB-ViaSCG-r12 ::= BOOLEAN [TRUE] OPTIONAL:Exist | | | | +-t-Reordering-r12 ::= ENUMERATED [ms0] OPTIONAL:Exist | | | +-VERSION-BRACKETS4 ::= SEQUENCE [111] OPTIONAL:Exist | | | +-ul-DataSplitThreshold-r13 ::= CHOICE [setup] OPTIONAL:Exist | | | | +-setup ::= ENUMERATED [b0] | | | +-pdcp-SN-Size-v1310 ::= ENUMERATED [len18bits] OPTIONAL:Exist | | | +-statusFeedback-r13 ::= CHOICE [setup] OPTIONAL:Exist | | | +-setup ::= SEQUENCE [1111] | | | +-statusPDU-TypeForPolling-r13 ::= ENUMERATED [type1] OPTIONAL:Exist | | | +-statusPDU-Periodicity-Type1-r13 ::= ENUMERATED [ms5] OPTIONAL:Exist | | | +-statusPDU-Periodicity-Type2-r13 ::= ENUMERATED [ms5] OPTIONAL:Exist | | | +-statusPDU-Periodicity-Offset-r13 ::= ENUMERATED [ms1] OPTIONAL:Exist | | +-rlc-Config ::= CHOICE [am] OPTIONAL:Exist | | +-logicalChannelIdentity ::= INTEGER (3..10) [3] OPTIONAL:Exist | | +-logicalChannelConfig ::= SEQUENCE [1] OPTIONAL:Exist | | +-EXTENSION ::= SEQUENCE [00] | +-drb-ToReleaseList ::= SEQUENCE OF OPTIONAL:Omit | +-mac-MainConfig ::= CHOICE [explicitValue] OPTIONAL:Exist | +-sps-Config ::= SEQUENCE OPTIONAL:Omit | +-physicalConfigDedicated ::= SEQUENCE [0000111010] OPTIONAL:Exist +-securityConfigHO ::= SEQUENCE OPTIONAL:Omit +-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
According to 36.323 4.3.1 Services provided to upper layers, the maximum size of a PDCP SDU is defined as follows.
According to this table, you would notice that a regular IP packet (smaller than 1500 Bytes) can be easily packed into a single PDCP SDU regardless of LTE standards. In case of Jumbo frame, it wouldn't be packed into a single SDU in case of LTE-NB if the IP packet size goes over 1600 bytes. However, even such a jumbo packets can be packed into a single PDCP SDU in legacy LTE unless the IP packet size does not go over 8188 bytes. Then, how about the jumbo frame with the size of greater than 8188 bytes ?
As in MAC PDU, RLC PDU.. PDCP also has it's own data structure and again you would never understand this structure in detail unless you get some real data and anlayze the data manually. But putting all together the following diagram (from 3GPP 36.323) would guide you to decode PDCP Data.
The only key question when you try to decode real PDCP data would be "Which diagram I have to use to decode this data ?". Only practice would give you the quick answer.
First Let's briefly look at the data structure. Following is the data structure for SRB. It means all the C plane data (RRC/NAS message) use this data structure. As you see, the first three bits are reserved. and next comes 5 bits PDCP SN(Sequence Number) and at the end of the block 4 bytes of MAC-I data is attached.
< 36.323 Figure 6.2.2.1 : PDCP Data PDU Format for SRBs >
Following two diagram shows the PDCP structure for DRB. It means U-Plane data, DTCH data is using this kind of data structure. The only differences between these two data type is the size of SN (Sequence Number). One is using 7 bit and the other is 12 bits. Comparing to SRB PDCP structure, you would find two differences. D/C bit at the first bit of the structure. This tells you whether the PDCP data is for user data or PDCP control data (This control data does not mean C-Plane data. It is control data being used in PDCP layer). And the other difference is that you do not have the MAC-I at the end of the data. MAC-I is the special information for Integrity protection. Do you remember Integrity Protection applies only to C-Plane data, not to U-Plane data ?
< 36.323 Figure 6.2.4.1 : PDCP Data PDU Format for DRBs using a 7 bit SN >
< 36.323 Figure 6.2.3.1 : PDCP Data PDU Format for DRBs using a 12 bit SN >
< 36.323 Figure 6.2.9.1: PDCP Data PDU format for DRBs using a 15 bit SN >
< 36.323 Figure 6.2.11.1: PDCP Data PDU format for DRBs using an 18 bit SN >
Following two data structure is a kind of PDCP layer control packet. Most of the LTE PDCP PDU you woud see would be the Data PDU. However, you may see the PDCP packet with D/C field = 0 (i.e, Control PDU) when PDCP PDU(s) get lost during the communication or you will often see these packets when ROHC is in action. In the case of missing PDCP packets, you would see Figure 6.2.6.1 structure and in ROHC case you would see Figure 6.2.5.1 structure as shown below.
< 36.323 Figure 6.2.5.1: PDCP Control PDU format for interspersed ROHC feedback packet >
< 36.323 Figure 6.2.6.1: PDCP Control PDU format for PDCP status report using a 12 bit SN >
NOTE : FMS stands for First missing PDCP SN
< 36.323 Figure 6.2.6.2: PDCP Control PDU format for PDCP status report using a 15 bit SN >
< 36.323 Figure 6.2.6.2: PDCP Control PDU format for PDCP status report using a 15 bit SN >
All of the following tables shows the meaning of each data field shown in the diagrams we saw above. You will refer to this table a lot when you try to decode PDCP data yourself. Otherwise, you would read now and forget as your click to another page.
< 36.323 Table 6.3.2.1: PDCP SN length >
< 36.323 Table 6.3.7.1: D/C field >
< 36.323 Table 6.3.8.1: PDU type >
< 36.323 Table 6.3.10.1 Bitmap >
My perception of any process is "a black box that convert a set of inputs into a set of output". So for any process, I usually try to define what is the inputs and out is the final outputs.. and then try to find the all of the steps one by one to convert the input into the outputs.
If I define LTE Integrity Protection Procedure with this logic, it would be "a process that convert 'K' value from USIM into PDCP MAC-I and NAS MAC(Message Authentication Code)". Describing this process with illustration would be as follows. Just try to go through this illustration whenever you have chance and try to have your own idea first. The process described here apply only to C-Plane data. Actually this is a huge topic and hard to be described here in detail (Refer to NAS Integrity page for further detail).
Examples of PDCP Data Structure
In this section, I will show you some of the examples of PDCP data structure.
< Example : PDCP <-- DL DCCH : RRC Connection Reconfiguration >
This example PDCP PDU has following structure. The SDU/PDU is from eNB PDCP.
DL DCCH RRC : 20 06 03 59 3D 11 4D E1 B8 18 3A 10 17 00 30 00 07 88 80 00 08 01 B2 91 26 08 08 48 68 23 4B 73 2B A0 23 13 2B 63 60 13 1B 08 28 0E 05 40 08 09 38 DC 04 01 08 80 18 00 00 84 08 36 05 40 08 14 18 36 05 40 08 10 00 68 26 05 40 08 12 80 5F B0 07 88 84 00 08 00 00 00 00 08 98 07 88 80 00 09 18 2F A0 00 00 00 08 BF 02 CF 03 20 08 1F 93 53 E0 FA 81 BC 0F A8 E0 60 78 26 3E 9D 52 D2 E8 00 FB 50 65 03 FF 04 07 E8 10
PDCP PDU : 06 20 06 03 59 3D 11 4D E1 B8 18 3A 10 17 00 30 00 07 88 80 00 08 01 B2 91 26 08 08 48 68 23 4B 73 2B A0 23 13 2B 63 60 13 1B 08 28 0E 05 40 08 09 38 DC 04 01 08 80 18 00 00 84 08 36 05 40 08 14 18 36 05 40 08 10 00 68 26 05 40 08 12 80 5F B0 07 88 84 00 08 00 00 00 00 08 98 07 88 80 00 09 18 2F A0 00 00 00 08 BF 02 CF 03 20 08 1F 93 53 E0 FA 81 BC 0F A8 E0 60 78 26 3E 9D 52 D2 E8 00 FB 50 65 03 FF 04 07 E8 10 0C F3 6E 17
Header : 06 (Hex), 00000110 (Bin) R - 0 R - 0 R - 0 SN - 00110 (Bin), 6 (Dec) MAC-I : 0C F3 6E 17 // This is added by eNB PDCP Layer. UE is comparing this with the one it calculated internally.
< Example : UL DCCH --> PDCP : RRC Connection Reconfiguration Complete >
This example PDCP PDU has following structure. The SDU/PDU is from eNB PDCP.
UL DCCH RLC : A0 07 07 10 00 C4 8E 9A A7 PDCP PDU : 07 10 00 C4 8E 9A A7
Header : 07 (Hex), 00000111 (Bin) R - 0 R - 0 R - 0 SN - 00111 (Bin), 7 (Dec) MAC-I : C4 8E 9A A7 // This is added by UEPDCP Layer. eNB is comparing this with the one it calculated internally.
< Example : DL DTCH -> PDCP : IP Data >
This example PDCP PDU has following structure. The SDU/PDU is from eNB PDCP.
DL DTCH (from IP Interface) : 45 00 00 C8 04 12 40 00 80 11 72 BF C0 A8 01 02 C0 A8 01 01 EA 60 4A 12 00 B4 AE 8B 80 08 32 60 69 14 46 F2 18 69 D6 05 D5 57 57 D7 D3 55 57 5C 41 45 5E D6 DC D4 53 5E 5F 53 D6 D0 D2 DE D8 D0 55 56 D6 DE D0 D1 57 D4 54 54 57 5D 58 5C D5 D0 D2 55 D5 D6 54 51 55 D5 55 D4 D2 D3 D1 D5 51 5C D4 D9 D2 D5 51 5D 58 5E 56 DB DB 55 54 57 52 53 52 D7 D0 D0 D2 D6 55 D5 D1 D1 D3 D3 D7 D5 D4 53 53 50 55 D7 D5 55 57 57 52 54 56 56 50 56 54 D5 54 56 55 D1 D2 D1 DD D3 D3 DD D5 D3 D7 5E 5D 51 D6 DC D6 51 5D 58 5C D2 D2 D0 51 50 D4 52 54 D6 57 51 54 55 D4 D4 D6 50 D7 DF D7 D7 54 D2 DD D3 50 5B 5D 55 D7 D1 D7 D3
PDCP PDU : 80 48 45 00 00 C8 04 12 40 00 80 11 72 BF C0 A8 01 02 C0 A8 01 01 EA 60 4A 12 00 B4 AE 8B 80 08 32 60 69 14 46 F2 18 69 D6 05 D5 57 57 D7 D3 55 57 5C 41 45 5E D6 DC D4 53 5E 5F 53 D6 D0 D2 DE D8 D0 55 56 D6 DE D0 D1 57 D4 54 54 57 5D 58 5C D5 D0 D2 55 D5 D6 54 51 55 D5 55 D4 D2 D3 D1 D5 51 5C D4 D9 D2 D5 51 5D 58 5E 56 DB DB 55 54 57 52 53 52 D7 D0 D0 D2 D6 55 D5 D1 D1 D3 D3 D7 D5 D4 53 53 50 55 D7 D5 55 57 57 52 54 56 56 50 56 54 D5 54 56 55 D1 D2 D1 DD D3 D3 DD D5 D3 D7 5E 5D 51 D6 DC D6 51 5D 58 5C D2 D2 D0 51 50 D4 52 54 D6 57 51 54 55 D4 D4 D6 50 D7 DF D7 D7 54 D2 DD D3 50 5B 5D 55 D7 D1 D7 D3
Header : 80 48 (Hex) , 10000000 01001000 (Bin) D/C - 1 // indicate that this is Data PDU R - 0 R - 0 R - 0 SN - 0000 01001000 (Bin), 72 (Dec)
Following is the decoded IP Packet for your reference : (Blue and Pink part in the above PDU indicate Source and Destination IP address)
Internet Protocol Version 4, Src: 192.168.1.2, Dst: 192.168.1.1 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) 0000 00.. = Differentiated Services Codepoint: Default (0) .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0) Total Length: 200 Identification: 0x0412 (1042) Flags: 0x02 (Don't Fragment) 0... .... = Reserved bit: Not set .1.. .... = Don't fragment: Set ..0. .... = More fragments: Not set Fragment offset: 0 Time to live: 128 Protocol: UDP (17) Header checksum: 0x72bf [validation disabled] [Good: False] [Bad: False] Source: 192.168.1.2 Destination: 192.168.1.1 [Source GeoIP: Unknown] [Destination GeoIP: Unknown] User Datagram Protocol, Src Port: 60000 (60000), Dst Port: 18962 (18962) Source Port: 60000 Destination Port: 18962 Length: 180 Checksum: 0xae8b [validation disabled] [Good Checksum: False] [Bad Checksum: False] [Stream index: 0] Data (172 bytes)
To decode the PDU in this example, 3GPP specification is not enough because this PDCP PDU contains ROHC feedback defined in RFC 4495 as shown below. (If you are interested only in PDCP header, 3GPP is enough .. but if you want to decode it a little bit further into the palyload of the PDU, you need to look into RFC 4495 in this case)
Code: 0 indicates that a Size octet is present. 1-7 indicates the size of the feedback data field, in octets.
Size: Indicates the size of the feedback data field, in octets.
FEEDBACK data: FEEDBACK-1 or FEEDBACK-2 (see below).
CID information in a feedback element indicates the context for which feedback is sent. The LARGE_CIDS parameter that controls whether a large CID is present is taken from the channel state of the receiving compressor's channel, not from the state of the channel carrying the feedback.
Following is an example of PDCP Control PDU captured during ROHC Operation.
PDCP PDU : 10 F6 20 00 41 16 11 39 (HEX) PDCP PDU : 00010000 11110110 00100000 00000000 01000001 00010110 00010001 00111001 (Bin)
Header : 10 F6 (Hex) , 00010000 11110110(Bin) D/C - 0 // indicate that this is Control PDU PDU Type - 001 // Indicate that this is Interspersed ROHC Feedback R - 0 R - 0 R - 0 R - 0 Interspersed ROHC Feedback - 11110110 (Bin) // If you further decode this based on RFC, it goes as follows 11110 - Fixed in RFC4995 110 - Size of the feedback Data Field in Octets
|
||||||||||||||
