Outline Xw User Plane Protocol Packet Data Convergence

  • Slides: 55
Download presentation

Outline • Xw User Plane Protocol • Packet Data Convergence Protocol – Ciphering and

Outline • Xw User Plane Protocol • Packet Data Convergence Protocol – Ciphering and integrity protection functions – Header compression – Robust header compression – PDCP PDU packet formats – LTE security aspects • Summary Reference: Harri Holma, Antti Toskala, Jussi Reunanen, LTE Small Cell Optimization 3 GPP Evolution to Release 13, John Wiley & Sons, Ltd, 2016 2

Xw User Plane Protocol • Using services of the transport network layer in order

Xw User Plane Protocol • Using services of the transport network layer in order to allow flow control of user data packets transferred over the Xw interface • Provision of Xw UP specific sequence number information for user data transferred from the e. NB to the WT for a specific E-RAB configured with the LWA bearer option • Information of successful transmission towards or in sequence delivery to the UE of LWAAP PDUs from WT for user data associated with a specific E-RAB configured with the LWA bearer option • Information of LWA PDUs that were not transferred towards or not delivered to the UE • Information of the currently desired buffer size at the WT for transmitting to the UE user data associated with a specific ERAB configured with the LWA bearer option • Information of the currently minimum desired buffer size at the WT for transmitting to the UE user data associated with all E-RABs configured with the LWA bearer option

Transfer of Downlink User Data • Services Expected from the Xw Transport Network Layer

Transfer of Downlink User Data • Services Expected from the Xw Transport Network Layer • Provide Xw-U specific sequence number information at the transfer of user data carrying a DL LWA PDU from the e. NB to the WT via the Xw-U interface • The e. NB shall assign consecutive Xw-U sequence numbers to each transferred Xw-U packet

Xw-U Interface • The Transfer of Downlink User Data procedure needs to be sent

Xw-U Interface • The Transfer of Downlink User Data procedure needs to be sent across the Xw-U interface • The WT shall detect – Whether an Xw-U packet was lost – And memorise the respective sequence number after it has declared the respective Xw-U packet as being “lost” • The WT shall – Transfer the remaining LWA PDUs towards the UE – Memorise the highest Xw-U sequence number of the PDCP PDU that was successfully transferred towards or delivered to the UE

Downlink Data Delivery Status • Provide feedback from the WT to the e. NB

Downlink Data Delivery Status • Provide feedback from the WT to the e. NB to allow the e. NB to control the downlink user data flow via the WT for the respective E-RAB

The Feedback for Downlink Data Delivery • The highest Xw-U sequence number successfully transferred

The Feedback for Downlink Data Delivery • The highest Xw-U sequence number successfully transferred towards or delivered to the UE – Among those PDUs received from the e. NB • The desired buffer size in bytes for – The concerned E-RAB • The minimum desired buffer size in bytes for the UE • The Xw-U packets – Declared as being “lost” by the WT – Not yet been reported to the e. NB within the DL DATA DELIVERY STATUS frame

Downlink Data Delivery Indication • Whether the frame is the last DL status report

Downlink Data Delivery Indication • Whether the frame is the last DL status report received in the course of releasing a bearer from the WT • The e. NB considers that no more UL data is to be expected from the WT • When the e. NB received the DL DATA DELIVERY STATUS frame – Regard the desired buffer size – Remove the buffered PDCP according to the feedback of successfully delivered PDCP – Decides upon the actions necessary to take for PDCP or LWIP PDUs reported other than successfully delivered

Elements for the Xw User Plane Protocol 7 6 5 4 3 Field 1

Elements for the Xw User Plane Protocol 7 6 5 4 3 Field 1 Field 3 2 1 Field 2 Field 4 continue 0 Number of Octets Bits 1 2 Spare Field 6 continue Spare extension Octet 1 Octet 2 Octet 3 2 Octet 4 Octet 5 Padding 0 -m

Frame Format for the Xw User Plane Protocol • DL USER DATA – PDU

Frame Format for the Xw User Plane Protocol • DL USER DATA – PDU Type 0 – Allow the WT to detect lost Xw-U packets – Associated with the transfer of a Downlink LWA PDU over the Xw-U interface • DL DATA DELIVERY STATUS – PDU Type 1 – Transfer feedback to allow the receiving e. NB to control the downlink user data flow via the WT

DL USER DATA (PDU Type 0) Format 7 6 5 PDU Type (=0) 4

DL USER DATA (PDU Type 0) Format 7 6 5 PDU Type (=0) 4 3 2 1 spare 0 Number of Octets Bits 1 Xw-U Sequence Number 3 Spare extension 0 -4

DL DATA DELIVERY STATUS (PDU Type 1) Format 6 5 4 3 PDU Type

DL DATA DELIVERY STATUS (PDU Type 1) Format 6 5 4 3 PDU Type (=1) 2 Spare 1 0 Final Frame Lost Packet Ind. Report Number of Octets Bits 7 1 Highest successfully delivered Xw-U Sequence Number 3 Desired buffer size for the E-RAB or UE 4 Minimum desired buffer size for the UE 4 Number of lost Xw-U Sequence Number ranges reported 1 Start of lost Xw-U Sequence Number range 6* (Number of reported lost Xw-u SN ranges) End of lost Xw-U Sequence Number range Spare extension 0 -4

Outline • Xw User Plane Protocol • Packet Data Convergence Protocol – Ciphering and

Outline • Xw User Plane Protocol • Packet Data Convergence Protocol – Ciphering and integrity protection functions – Header compression – Robust header compression – PDCP PDU packet formats – LTE security aspects • Summary Reference: Harri Holma, Antti Toskala, Jussi Reunanen, LTE Small Cell Optimization 3 GPP Evolution to Release 13, John Wiley & Sons, Ltd, 2016 13

Introduction • The packet data convergence protocol (PDCP) sublayer is part of the LTE

Introduction • The packet data convergence protocol (PDCP) sublayer is part of the LTE layer 2 protocols – Responsible for the IP header compression of user-plane data packets in order to reduce the number of information bits transmitted over the air-interface • The header compression mechanism is based on the Internet Engineering Task Force (IETF) standard robust header compression (ROHC) • Ciphering and integrity protection of control-plane RRC messages • In-sequence delivery and duplicate removal • At the receiver side, the PDCP performs the corresponding deciphering and decompression operations • There is one PDCP entity per radio bearer (RB) configured for a terminal 14

PDCP on the User-plane • Header compression and decompression using ROHC protocol • transfer

PDCP on the User-plane • Header compression and decompression using ROHC protocol • transfer of user data; in-sequence delivery of upperlayer • PDUs at PDCP reestablishment procedure for RLC acknowledged mode (AM) • Duplicate detection of lower-layer service data units (SDUs) at PDCP reestablishment procedure for RLC AM • Retransmission of PDCP SDUs during handover for RLC AM • Ciphering and deciphering • Timer-based SDU discarding in the uplink 15

PDCP on the Control-plane • Ciphering and integrity protection • Transfer of control-plane data

PDCP on the Control-plane • Ciphering and integrity protection • Transfer of control-plane data 16

PDCP Sublayer in LTE Protocol Stack 17

PDCP Sublayer in LTE Protocol Stack 17

Radio Bearers • The LTE radio-access network provides one or more radio bearers to

Radio Bearers • The LTE radio-access network provides one or more radio bearers to which IP packets are mapped according to their Qo. S requirements • Two types of radio bearers – Data radio bearers (DRBs) carrying user-plane data – Signaling radio bearers (SRBs) carrying control-plane information • Each radio bearer is associated with one PDCP entity • Each PDCP entity is associated with one or two (one for each direction) RLC entities depending on – The radio bearer characteristic (i. e. , unidirectional or bidirectional) – The RLC mode • The PDCP entities are located in the PDCP sublayer and are configured by upper layers • A control service access point (SAP) provides the PDCP interface with the RRC sublayer 18

PDCP Sublayer and Structure of PDCP PDU 19

PDCP Sublayer and Structure of PDCP PDU 19

PDCP Sublayer and Structure of PDCP PDU (Cont. ) • The PDCP entities are

PDCP Sublayer and Structure of PDCP PDU (Cont. ) • The PDCP entities are located in the PDCP sublayer • Several PDCP entities may be defined for a UE • Each PDCP entity carries user-plane data and may be configured to use header compression • Each PDCP entity transports the data of one radio bearer • The LTE standard supports ROHC protocol for header compression as specified by IETF standards • Each PDCP entity uses one ROHC instance • A PDCP entity is associated with either the control -plane or the user-plane – Depending on which radio bearer is carrying the data

Functional Decomposition of PDCP Entities

Functional Decomposition of PDCP Entities

Illustration of PDCP Functions on the Control-Plane and User-Plane

Illustration of PDCP Functions on the Control-Plane and User-Plane

PDCP and Lower Protocol Layer • The maximum size of a PDCP SDU is

PDCP and Lower Protocol Layer • The maximum size of a PDCP SDU is 8188 octets • The PDCP uses the services provided by the RLC sublayer • The lower protocol layers provide the following services to the PDCP sublayer – Acknowledged data transfer service including indication of successful delivery of PDCP PDUs – Unacknowledged data transfer service – In-sequence delivery, except at reestablishment of lower layers – Duplicate discarding, except at reestablishment of lower layers • The PDCP is used for transmission of SRBs (signaling radio bearers carrying control-plane data) and DRBs (data radio bearers carrying user-plane data) – Mapped to dedicated control channel (DCCH) and dedicated traffic channel (DTCH) logical channels • The PDCP is not used for other types of logical channels

ROHC Protocol • The IETF ROHC protocol is utilized for header compression in LTE

ROHC Protocol • The IETF ROHC protocol is utilized for header compression in LTE • There are multiple header compression algorithms, called profiles – Defined for the ROHC protocol • Each profile is specific to the particular network layer, transport layer, or upper layer protocol combination – Transmission control protocol/IP (TCP/IP) – Real-time transport protocol/user datagram protocol/IP (RTP/UDP/IP) • The followings are not specified in 3 GPP LTE specifications – The implementation of ROHC functionality – The supported header compression profiles

Supported Header Compression Protocols and Profiles

Supported Header Compression Protocols and Profiles

ROHC Channel • PDCP entities associated with DRBs can be configured by upper layers

ROHC Channel • PDCP entities associated with DRBs can be configured by upper layers to use header compression • The RObust Header Compression (ROHC) Framework provides configuration parameters – – Mandatory and must be configured by upper layers Between compressor and decompressor entities At the transmitter and receiver sides Define the ROHC channel • The ROHC channel is a unidirectional channel – i. e. , there is one channel for the downlink and one for the uplink – Both channels belonging to the same PDCP entity • There is one set of parameters for each channel • The same values are used

Ciphering and Integrity Protection Functions • The ciphering function includes both ciphering and deciphering

Ciphering and Integrity Protection Functions • The ciphering function includes both ciphering and deciphering and is performed in the PDCP sublayer • For the control-plane – PDCP PDU and the message authentication code for integrity (MAC-I) are ciphered – i. e. , a 32 -bit field that carries the message authentication code • For the user-plane – The data part of the PDCP PDU is ciphered • Ciphering is not applicable to the PDCP control PDUs • The ciphering algorithm and key to be used by the PDCP entity are configured by upper layers • The ciphering method is applied according to the security architecture of 3 GPP system architecture evolution • The ciphering function is activated by upper layers • After security activation, the ciphering function is applied to all PDCP PDUs – Idicated by upper layers for the downlink and the uplink transmissions 27

PDCP Required Ciphering Parameters • The required inputs to the ciphering function include –

PDCP Required Ciphering Parameters • The required inputs to the ciphering function include – COUNT (a combination of SN and HFN which is 32 bits) – DIRECTION (one-bit direction of the transmission) • The parameters required by the PDCP which are provided by upper layers – BEARER (defined as the RB identifier which is 5 bits) – KEY (the 128 -bit ciphering keys for the controlplane and for the user-plane)

Illustration of the Ciphering and Deciphering Procedures 29

Illustration of the Ciphering and Deciphering Procedures 29

Integrity Protection and Verification Procedures 30

Integrity Protection and Verification Procedures 30

Integrity Protection • The data unit that is integrity protected – The PDU header

Integrity Protection • The data unit that is integrity protected – The PDU header – The data part of the PDU prior to ciphering • The integrity protection algorithm and key to be used by the PDCP entity – Configured by upper layers – The integrity protection method is applied according to the security architecture of 3 GPP system architecture evolution – The integrity protection function is activated by upper layers • The RRC message which activates the integrity protection function – Integrity protected with the configuration included in that RRC message – The message must be decoded by the RRC sublayer – Before the integrity protection verification can be performed for the PDU 31

Integrity Protection Verification • • The UE computes the value of the MAC-I field

Integrity Protection Verification • • The UE computes the value of the MAC-I field during transmission The UE verifies the integrity of the PDCP PDU by calculating the X-MAC at reception – i. e. , computed MAC-I, based on the input parameters • Integrity protection is verified successfully – If the calculated X-MAC is the same as the received MAC-I • The PDCP entity discards the received PDU – When a PDCP entity receives a PDCP PDU that contains reserved or invalid values • The PDCP data PDU – Used to transport the PDCP SDU SN and user-plane data containing an uncompressed PDCP SDU – User-plane data containing a compressed PDCP SDU – Control-plane data – MAC-I field for SRBs • The PDCP control PDU – Following PDCP reestablishment and header compression control information – Convey the PDCP status report identifying missing PDCP SDUs – e. g. , ROHC feedback 32

Header Compression • The data payload of the IP packet is almost the same

Header Compression • The data payload of the IP packet is almost the same size or even smaller than the header itself – In some services and applications such as voice over IP (Vo. IP), interactive gaming, multimedia messaging, etc • Over the end-to-end connection comprising multiple hops – These protocol headers are extremely important • Over a single point-to-point link – These headers serve no useful purpose • It is possible to compress these headers – Save the bandwidth and use expensive radio resources more efficiently • The header compression provides other important benefits – Such as reduction in packet loss – Improved interactive response time • Payload header compression – The process of suppressing the repetitive portion of payload headers at the sender – Restoring them at the receiver side of a low-bandwidth/capacity-limited link 33

The Use of Header Compression • The use of header compression has a well

The Use of Header Compression • The use of header compression has a well -established history in transport of IPbased payloads over capacity-limited wireless links – More bandwidth efficient transport methods are required • The IETF has developed several header compression protocols – Widely used in telecommunication systems 34

Examples Of the Compression Ratios • IP version 4 protocol header – Consists of

Examples Of the Compression Ratios • IP version 4 protocol header – Consists of 20 bytes – Combined with the UDP header of 8 bytes and RTP header of 12 bytes results in an IPv 4/UDP/RTP header size of 40 bytes – A header compression scheme typically compresses such headers to 24 bytes in the steady-state • IP version 6 protocol header – Increased header size of 40 bytes due to increased IP address space 35

IPv 6, UDP, and RTP Header Formats 36

IPv 6, UDP, and RTP Header Formats 36

The Flow Context of Header Compression • Collection of information about field values and

The Flow Context of Header Compression • Collection of information about field values and change patterns of field values in the packet header • The first few packets of a newly identified flow are used to build the context on both sides – These packets are sent without compression – Link characteristics like bit error rate and round trip time • Once the context is established on both sides, the compressor compresses the payload headers as much as possible • Account the link conditions and feedback from the decompressor – The compressed packet header sizes may vary • At certain intervals and in the case of error recovery – Uncompressed packet headers are sent to reconstruct the context and revert back to normal operational mode 37

The Performance Of A Header Compression Scheme • The header compression is a hop-to-hop

The Performance Of A Header Compression Scheme • The header compression is a hop-to-hop process and is not applied in an end-to-end connection – The header compression does not introduce any changes in the data payload when it compresses and decompresses the header in end-toend connection – Perform operations in hop-to-hop such as routing, Qo. S negotiation, and parameter adjustment, etc • Header compression is best suited for specific links in the network characterized by – Relatively low bandwidth – High bit error rates – Long round trip times • The performance of a header compression scheme – Compression efficiency • Determined by how much the header sizes are reduced by the compression scheme – Robustness – Compression transparency • Ensures that the decompressed headers are semantically identical to the original 38 headers

Robust Header Compression • The ROHC scheme reduces the size of the transmitted IP/UDP/RTP

Robust Header Compression • The ROHC scheme reduces the size of the transmitted IP/UDP/RTP header by removing redundancies – Classifying header fields into different classes according to their variation pattern • The fields that are classified as inferred are not sent • The static fields are sent initially and then are not sent again • The fields with varying information are always sent • The ROHC mechanism is based on a context – Maintained by both ends, i. e. , the compressor and the decompressor • The context encompasses the entire header and ROHC information • Each context has a context identifier – Identifies the flows 39

Example ROHC Compression/decompression Of IP/UDP/RTP Headers For Communication Over A Radio Link 40

Example ROHC Compression/decompression Of IP/UDP/RTP Headers For Communication Over A Radio Link 40

The Operational Modes Of The ROHC Scheme • Unidirectional mode (U) – Packets are

The Operational Modes Of The ROHC Scheme • Unidirectional mode (U) – Packets are only sent from compressor to decompressor – Makes ROHC usable over links where a return path from decompressor to compressor is unavailable or undesirable • Optimistic mode (O) – The bi-directional optimistic mode is similar to the unidirectional mode – Feedback channel is used to send error recovery requests and (optionally) acknowledgments of significant context updates from decompressor to compressor – The O-mode aims to maximize compression efficiency and sparse usage of the feedback channel • Reliable mode (R) – More intensive usage of the feedback channel – Stricter logic at both compressor and decompressor – Prevents loss of context synchronization between compressor and decompressor except for very high residual bit error rates 41

The Usage Of The ROHC Scheme • The U-mode is used when the link

The Usage Of The ROHC Scheme • The U-mode is used when the link is unidirectional or when feedback is not possible • For bi-directional links – The O-mode uses positive feedback packets (acknowledgment (ACK)) – R-mode uses positive and negative feedback packets (ACK and negative acknowledgment (NACK)) • ROHC always starts header compression using the U-mode – Even if it is used in a bi-directional link • ROHC does not make retransmission when an error occurs and the erroneous packet is dropped • The ROHC feedback is used only to indicate to the compressor side that there was an error and probably the context was damaged • After receiving a negative feedback, the compressor always reduces its compression level 42

The Compression States Of The ROHC Compressor • Each compression state uses a different

The Compression States Of The ROHC Compressor • Each compression state uses a different header format in order to send the header information • Initialization and refresh (IR) – The compressor has been created or reset – Full packet headers are sent – The IR compression state establishes the context • Contains static and dynamic header information • First order (FO) – The compressor has detected and stored the static fields such as IP addresses and port numbers on both sides of the connection – The FO compression state provides the change pattern of dynamic fields • Second order (SO) – The compressor is suppressing all dynamic fields such as RTP SNs – Sending only a logical SN and partial checksum to cause the other side to • Generate the headers based on prediction • Verify the headers of the next expected packet – The SO compression state sends encoded values of SN and time stamp 43 (TS), forming the minimal size packets

ROHC State Machines 44

ROHC State Machines 44

The Context Established At The Decompressor Side • • In the U-mode, the feedback

The Context Established At The Decompressor Side • • In the U-mode, the feedback channel is not used Since the compressor does not know whether the context is lost – Uses two timers, to be able to return to the FO and IR compression states • • The decompressor works at the receiving end of the link and decompresses the headers based on the header fields’ information of the context Both compressor and decompressor use a context to store all the information about the header fields To ensure correct decompression, the context should be always synchronized The decompressor has three states as follows – No context (NC) where there is no context synchronization – Static context (SC) where the dynamic information of the context has been lost – Full context (FC) when the decompressor has all the information about header fields • • In the FC state, the decompressor transitions to the initial states as soon as it detects corruption of the context The decompressor uses the “k out of n” rule by looking at the last n packets with cyclic redundancy check (CRC) failures – If k CRC failures have occurred, it assumes the context has been corrupted and transitions to an initial state (SC or NC) • The decompressor also sends feedback according to the operation mode 45

PDCP PDU Packet Formats • The PDCP PDU packets are used to transport userplane

PDCP PDU Packet Formats • The PDCP PDU packets are used to transport userplane data or control-plane information corresponding to the RRC sublayer or NAS • Depending on the type of information, a PDCP PDU packet may include – A PDCP SDU SN and user-plane data containing an uncompressed PDCP SDU – User-plane data containing a compressed PDCP SDU – Control-plane data and a MAC-I field for SRBs • The PDCP control PDU conveys a PDCP status report – Indicating which PDCP SDUs are missing following PDCP reestablishment or header compression control information, e. g. , interspersed ROHC feedback 46

PDCP PDU Packet Formats 47

PDCP PDU Packet Formats 47

LTE Security Aspects • The keys used for NAS and AS protection are dependent

LTE Security Aspects • The keys used for NAS and AS protection are dependent on the algorithm • The e. NB keys are cryptographically separated from the EPC keys that are used for NAS protection – Making it impossible to use the e. NB key to drive an EPC key • The AS and NAS keys are derived in the EPC/UE from key material – Generated by a NAS (EPC/UE) level authentication and key agreement (AKA) procedure (KASME) – Identified with a key identifier (KSIASME) • The e. NB key (Ke. NB) is sent from the EPC to the e. NB when the UE is entering the ECM-CONNECTED state – i. e. , during RRC connection or S 1 context setup • Separate AS and NAS level security mode procedures are used. – The AS level security mode procedure configures AS security (i. e. , the RRC and user-plane) – NAS level security mode procedure configures NAS security • Both integrity protection and ciphering for the RRC are activated within the same AS security mode command procedure – But not necessarily within the same message 48

Data Ciphering • The user-plane ciphering is activated at the same time as the

Data Ciphering • The user-plane ciphering is activated at the same time as the RRC ciphering • The keys that are stored in the e. NBs never leave a secure environment • User-plane data ciphering/deciphering is conducted within the secure environment • The information related to the e. NB keys is sent between the e. NBs during ECM-CONNECTED state in intra-E-UTRAN mobility • An SN denoted as COUNT is used as input to the ciphering and integrity protection • A given SN must only be used once for a given e. NB key – Except for identical retransmission on the same radio bearer in the same direction • The same SN can be used for both ciphering and integrity protection 49

Data Ciphering (Cont. ) • An HFN is used in the e. NB and

Data Ciphering (Cont. ) • An HFN is used in the e. NB and UE – In order to limit the actual number of SN bits that are needed to be sent over the radio air-interface – i. e. , an overflow counter mechanism • The HFN is synchronized between the UE and e. NB – If corruption of keys is detected, the UE has to restart the radio level attach procedure – e. g. , similar radio level procedure to the RRC_IDLE to RRC_CONNECTED mode transition or initial attach • Since subscriber identity module (SIM) access is not supported in E-UTRAN – An idle-mode UE not equipped with USIM cannot attempt to reselect the E-UTRAN • To prevent handover to the E-UTRAN – The UE which is not equipped with USIM indicates E-UTRA support in UE capability signaling in other radio access technologies (RATs) 50

Key Derivation Procedure in LTE 51

Key Derivation Procedure in LTE 51

Security Termination Points in LTE 52

Security Termination Points in LTE 52

User Plane Protection • Integrity protection for user-plane is not required – Not supported

User Plane Protection • Integrity protection for user-plane is not required – Not supported between the UE and serving gateway – The transport of user-plane data between the e. NB and the serving gateway on the S 1 interface (i. e. , the interface between e. NB and MME) • Upon RRC_IDLE to RRC_CONNECTED state transition – RRC protection and user-plane protection keys are generated – While keys for NAS protection as well as higher layer keys are assumed to be already available in the MME – These higher layer keys may have been established in the MME as a result of an AKA run – Or transferred from another MME during handover or idle mode mobility • Upon RRC_CONNECTED to RRC_IDLE state transition – The e. NB deletes the keys that it stores such that the context for idle-mode UE only resides in the MME – The state and current keys of the UE are assumed to have been 53 deleted at the e. NB upon such transition

User Plane Protection (Cont. ) • The RRC and user-plane keys are derived based

User Plane Protection (Cont. ) • The RRC and user-plane keys are derived based on the algorithm identifiers • Ke. NB results in new RRC and user-plane keys in each handover • Source e. NB and UE independently create Ke. NB* • The Ke. NB* is provided to target e. NB during the handover preparation time • Both target e. NB and UE consider the new Ke. NB to be equal to the received Ke. NB* • If AS keys (KUPenc, KRRCint, and KRRCenc) need to be changed in RRC_CONNECTED state – An intra-cell handover is used • Inter-RAT handover from UTRAN to E-UTRAN is only supported after activation of integrity protection in 54 UTRAN

Summary 55

Summary 55