Protocol++® (Protocolpp®)  v5.6.2
jlte Class Reference

#include "include/jlte.h"

Detailed Description

Long Term Evolution (LTE)

LTE Protocol Stack at the Data-Link Layer [1]

See PDCP_LTE_v14_1_0 specification on www.3gpp.org

If not otherwise mentioned in the definition of each field then the bits in the parameters shall be interpreted as follows: the left most bit string is the first and most significant and the right most bit is the last and least significant bit

Unless otherwise mentioned, integers are encoded in standard binary encoding for unsigned integers. In all cases the bits appear ordered from MSB to LSB when read in the PDU

PDCP SN

Length: 5, 7, 12, 15, 16, or 18 bits as indicated in the following table except for NB-IoT which uses 7 bit PDCP SN for DRB.

$ PDCP SN Length$
LengthDescription
5 SRBs
7 DRBs, if configured by upper layers (pdcp-SN-Size)
12 DRBs, if configured by upper layers (pdcp-SN-Size)
15 DRBs, if configured by upper layers (pdcp-SN-Size)
16 SLRBs
18 DRBs, if configured by upper layers (pdcp-SN-Size)

Data

Length: Variable

The Data field may include either one of the following:

  • Uncompressed PDCP SDU (user plane data, or control plane data); or
  • Compressed PDCP SDU (user plane data only)

MAC-I

Length: 32 bits

The MAC-I field carries a message authentication code calculated as specified in subclause 5.7 For control plane data that are not integrity protected, the MAC-I field is still present and should be padded with padding bits set to 0

COUNT

Length: 32 bits

For ciphering and integrity a COUNT value is maintained. The COUNT value is composed of a HFN and the PDCP SN. The length of the PDCP SN is configured by upper layers

Format of COUNT
HFNPDCP SN

The size of the HFN part in bits is equal to 32 minus the length of the PDCP SN.

NOTE: When performing comparison of values related to COUNT, the UE takes into account that COUNT is a 32-bit value, which may wrap around (e.g., COUNT value of 232 - 1 is less than COUNT value of 0).

R

Length: 1 bit

Reserved. In this version of the specification reserved bits shall be set to 0. Reserved bits shall be ignored by the receiver

D/C

Length: 1 bit

$ D/C field$
BitDescription
0Control PDU
1Data PDU

PDU type

Length: 3 bits

$ PDU type$
BitDescription
000PDCP status report
001Interspersed ROHC feedback packet
010LWA status report
011-111Reserved

FMS

Length: 12 bits when a 12 bit SN length is used, 15 bits when a 15 bit SN length is used, and 18 bits when an 18 bit SN length is used

PDCP SN of the first missing PDCP SDU

Bitmap

Length: Variable

The length of the bitmap field can be 0

The MSB of the first octet of the type "Bitmap" indicates whether or not the PDCP SDU with the SN (FMS + 1) modulo (Maximum_PDCP_SN + 1) has been received and, optionally decompressed correctly. The LSB of the first octet of the type "Bitmap" indicates whether or not the PDCP SDU with the SN (FMS + 8) modulo (Maximum_PDCP_SN + 1) has been received and, optionally decompressed correctly

$ Bitmap$
BitDescription
0PDCP SDU with PDCP SN = (FMS + bit position) modulo (Maximum_PDCP_SN+1) is missing in the receiver. The bit position of Nth bit in the Bitmap is N, i.e., the bit position of the first bit in the Bitmap is 1
1PDCP SDU with PDCP SN = (FMS + bit position) modulo (Maximum_PDCP_SN+1) does not need to be retransmitted. The bit position of Nth bit in the Bitmap is N, i.e., the bit position of the first bit in the Bitmap is 1

The UE fills the bitmap indicating which SDUs are missing (unset bit - ’0’), i.e. whether an SDU has not been received or optionally has been received but has not been decompressed correctly, and which SDUs do not need retransmission (set bit - ’1’), i.e. whether an SDU has been received correctly and may or may not have been decompressed correctly

Interspersed ROHC feedback packet

Length: Variable

Contains one ROHC packet with only feedback, i.e. a ROHC packet that is not associated with a PDCP SDU as defined in subclause 5.5.4.

PGK Index

Length: 5 bits

5 LSBs of PGK Identity as specified in [13]

PTK Identity

Length: 16 bits

PTK Identity as specified in [13].

SDU Type

Length: 3 bits

PDCP SDU type, i.e. Layer-3 Protocol Data Unit type as specified in [14]. PDCP entity may handle the SDU differently per SDU Type, e.g. header compression is applicable to IP SDU but not ARP SDU and Non-IP SDU

$ SDU Type$
BitDescription
000IP
001ARP
010PC5 Signaling
011Non-IP
100-111Reserved

KD-sess ID

Length: 16 bits

KD-sess Identity as specified in [13].

NMP

Length: 12 bits when a 12 bit SN length is used, 15 bits when a 15 bit SN length is used, and 18 bits when an 18 bit SN length is used. Number of missing PDCP SDU(s) with associated COUNT value below the associated COUNT value corresponding to HRW, starting from and including the associated COUNT value corresponding to FMS

HRW

Length: 12 bits when a 12 bit SN length is used, 15 bits when a 15 bit SN length is used and 18 bits when an 18 bit SN length is used

PDCP SN of the PDCP SDU received on WLAN with highest associated PDCP COUNT value

P

Length: 1 bit

Polling indication. Set to 1 when eNB triggers a PDCP status report or LWA status report for LWA

Encryption

LTE Encryption Block Diagram [2]

LTE uses the Snow3g and ZUC encryption algorithms for the user plan and AES-CTR mode for the control plane. The key is 128-bit for all three algorithms. As shown above, all algorithms are stream ciphers with inputs of key, 32-bit COUNT, 5-bit BEARER, DIRECTION (UPLINK or DOWNLINK), LENGTH in bits to generate the KEYSTREAM block of (length+31)/32 words. The keystream is XOR'd with the keystream to create the ciphertext block. Encryption is applied to the payload of the packet

Authentication

LTE Authentication MAC Generation Diagram [3]

LTE uses the Snow3g and ZUC authentication algorithms (also known as F9 mode), for the user plane and AES-CMAC mode for the control plan. The key is 128-bit for all three algorithms. As shown above, using the key, 32-bit COUNT, 5-bit BEARER (or sometimes called FRESH), DIRECTION (UPLINK or DOWNLINK), to generate a 4-byte MAC. Authentication is applied over both the header and the payload (the encrypted payload if encryption is enabled) with the MAC appended to the end of the packet

LTE Control Plane Packet formats [4]

LTE User Plane Packet formats [5]

  1. www.nxp.com/Long Term Evolution Protocol Overview p12
  2. 3GPP TS 36.323 V14.1.0 (2016-12)
  3. 3GPP TS 36.323 V14.1.0 (2016-12)
  4. 3GPP TS 36.323 V14.1.0 (2016-12)
  5. 3GPP TS 36.323 V14.1.0 (2016-12)

For API Documentation:

See also
ProtocolPP::jprotocol
ProtocolPP::jlte
ProtocolPP::jltesa
ProtocolPP::jsnow3g
ProtocolPP::jsnowv
ProtocolPP::jzuc
ProtocolPP::jmodes

For Additonal Documentation:

See also
jprotocol
jlte
jltesa
jsnow3g
jsnowv
jzuc
jmodes
Protocol++® (ProtocolPP®) written by : John Peter Greninger • © John Peter Greninger 2015-2024 • All Rights Reserved
All copyrights and trademarks are the property of their respective owners

The source code contained or described herein and all documents related to the source code (herein called "Material") are owned by John Peter Greninger and Sheila Rocha Greninger. Title to the Material remains with John Peter Greninger and Sheila Rocha Greninger. The Material contains trade secrets and proprietary and confidential information of John Peter Greninger and Sheila Rocha Greninger. The Material is protected by worldwide copyright and trade secret laws and treaty provisions. No part of the Material may be used, copied, reproduced, modified, published, uploaded, posted, transmitted, distributed, or disclosed in any way without prior express written consent of John Peter Greninger and Sheila Rocha Greninger (both are required)

No license under any patent, copyright, trade secret, or other intellectual property right is granted to or conferred upon you by disclosure or delivery of the Materials, either expressly, by implication, inducement, estoppel, or otherwise. Any license under such intellectual property rights must be express and approved by John Peter Greninger and Sheila Rocha Greninger in writing

Licensing information can be found at www.protocolpp.com/license with use of the binary forms permitted provided that the following conditions are met:

  • Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution
  • Any and all modifications must be returned to John Peter Greninger at GitHub.com https://github.com/jpgreninger/protocolpp for evaluation. Inclusion of modifications in the source code shall be determined solely by John Peter Greninger. Failure to provide modifications shall render this license NULL and VOID and revoke any rights to use of Protocol++®
  • Commercial use (incidental or not) requires a fee-based license obtainable at www.protocolpp.com/shop
  • Academic or research use requires prior written and notarized permission from John Peter and Sheila Rocha Greninger

Use of the source code requires purchase of the source code. Source code can be purchased at www.protocolpp.com/shop

  • US Copyrights at https://www.copyright.gov/
    • TXu002059872 (Version 1.0.0)
    • TXu002066632 (Version 1.2.7)
    • TXu002082674 (Version 1.4.0)
    • TXu002097880 (Version 2.0.0)
    • TXu002169236 (Version 3.0.1)
    • TXu002182417 (Version 4.0.0)
    • TXu002219402 (Version 5.0.0)
    • TXu002272076 (Version 5.2.1)
    • TXu002383571 (Version 5.4.3)

The name of its contributor may not be used to endorse or promote products derived from this software without specific prior written permission and licensing

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER AND CONTRIBUTOR "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE

The documentation for this class was generated from the following file: