Satellite Earth Stations and Systems (SES); Return Link Encapsulation (RLE) protocol

RTS/SES-00458

General Information

Status
Not Published
Current Stage
12 - Completion
Due Date
26-Jun-2023
Completion Date
14-Jun-2023
Ref Project
Standard
ETSI TS 103 179 V1.2.1 (2023-06) - Satellite Earth Stations and Systems (SES); Return Link Encapsulation (RLE) protocol
English language
45 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


TECHNICAL SPECIFICATION
Satellite Earth Stations and Systems (SES);
Return Link Encapsulation (RLE) protocol

2 ETSI TS 103 179 V1.2.1 (2023-06)

Reference
RTS/SES-00458
Keywords
MSS, protocol, satellite
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
https://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2023.
All rights reserved.
ETSI
3 ETSI TS 103 179 V1.2.1 (2023-06)
Contents
Intellectual Property Rights . 6
Foreword . 6
Modal verbs terminology . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 8
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 9
4 System Aspects . 9
4.0 General . 9
4.1 Protocol Stack . 10
4.2 Protocol Tailoring and Configuration. 12
4.3 Physical Layer Requirements . 12
5 RLE Data Format . 12
5.0 General . 12
5.1 Higher Layer SDU. 13
5.2 The Addressed Link PDU (ALPDU). 13
5.2.0 General . 13
5.2.1 Addressed Link PDU Format and Syntax . 14
5.2.1.0 General . 14
5.2.1.1 compressed_protocol_type Field (optional). 14
5.2.1.2 protocol_type Field (optional) . 15
5.2.1.3 alpdu_label_byte Field (optional) . 15
5.2.1.4 sdu_byte Field . 15
5.2.1.5 fragmenting_aldpdu . 15
5.2.1.6 sequence_number Field (optional) . 15
5.2.1.7 alpdu_crc Field (optional) . 16
5.2.2 The ALPDU Label . 16
5.2.3 Mapping the ALPDU to Available Payload . 16
5.2.3.0 General . 16
5.2.3.1 Forwarding the ALPDU in One Payload-adapted PDU . 16
5.2.3.2 Forwarding the ALPDU Using Several Payload-adapted PDUs . 17
5.2.3.3 Integrity Protection of a Fragmented ALPDU . 17
5.2.3.4 Multiplexing Payload-adapted PDUs used for Different ALPDUs . 17
5.3 The Payload-adapted PDU (PPDU) . 17
5.3.0 General . 17
5.3.1 The Payload-adapted PDU Format and Syntax . 18
5.3.1.0 General . 18
5.3.1.1 start_indicator and end_indicator Fields . 19
5.3.1.2 ppdu_length Field . 19
5.3.1.3 fragment_id Field . 19
5.3.1.4 alpdu_label_type Field . 20
5.3.1.5 protocol_type_suppressed Field . 20
5.3.1.6 ppdu_label_byte Field (optional) . 20
5.3.1.7 large_alpdus Field . 20
5.3.1.8 use_alpdu_crc Field (optional) . 20
5.3.1.9 total_length Field . 20
5.3.1.10 alpdu_byte Field. 21
5.3.2 The PPDU Label . 21
ETSI
4 ETSI TS 103 179 V1.2.1 (2023-06)
5.4 The Frame PDU (FPDU) . 21
5.4.0 General . 21
5.4.1 The FPDU Format and Syntax . 21
5.4.1.0 General . 21
5.4.1.1 use_explicit_payload_header_map Field. 22
5.4.1.2 payload_label_length Field (optional) . 22
5.4.1.3 ppdu_label_length Field (optional) . 22
5.4.1.4 payload_label_byte Field (optional) . 22
5.4.1.5 ppdu_byte (optional) . 23
5.4.1.6 padding_byte (optional) . 23
5.4.1.7 use_frame_protection field . 23
5.4.1.8 protection_byte (optional) . 23
5.4.1.9 padding_bit (optional) . 23
5.4.2 The FPDU Payload Label . 23
5.4.3 FPDU error protection . 23
6 RLE Configuration and Tailoring . 23
6.0 General . 23
6.1 System Specification and Signalling . 24
6.2 Higher layer SDU . 24
6.2.1 Maximum SDU size. 24
6.3 Addressed Link PDU (ALPDU) . 25
6.3.1 Protocol type table . 25
6.3.2 Label type table . 25
6.3.3 Extension headers . 25
6.3.4 Maximum ALPDU Length . 26
6.3.5 Integrity Protection . 26
6.4 Payload-adapted PDU (PPDU). 26
6.4.0 General . 26
6.4.1 PPDU Label . 26
6.4.2 ALPDU Fragmentation . 26
6.5 Frame PDU (FPDU) . 27
6.5.1 Payload Header Map . 27
6.5.2 Payload Label . 27
6.5.3 Frame Protection . 27
7 RLE Reassembly Error Check . 27
7.0 General . 27
7.1 Principles . 27
7.2 Reassembly error check algorithm with sequence number . 28
7.3 Reassembly error checking algorithm with CRC-32 . 29
Annex A (normative): ALPDU CRC-32 Calculation . 30
Annex B (informative): RLE Configuration . 31
B.0 General . 31
B.1 Protocol type table . 31
B.2 Label Type Table . 31
Annex C (informative): Reassembly Error Check Examples . 33
C.0 General . 33
C.1 Error check with sequence number . 33
C.2 Error check with CRC-32 . 34
Annex D (informative): Generic Label Type Selection Algorithm . 35
Annex E (normative): RLE Example Scenarios . 37
E.0 General . 37
ETSI
5 ETSI TS 103 179 V1.2.1 (2023-06)
E.1 DVB-RCS2 . 37
E.1.0 General . 37
E.1.1 DVB-RCS2 Common Configuration. 37
E.1.1.0 General . 37
E.1.1.1 Maximum SDU Size . 37
E.1.1.2 Protocol Type Table. 37
E.1.1.3 Label Type Table . 37
E.1.1.4 Maximum ALPDU Length . 38
E.1.1.5 Extension Headers . 38
E.1.1.6 Integrity Protection . 38
E.1.1.7 PPDU Label . 38
E.1.1.8 ALPDU Fragmentation . 38
E.1.1.9 Payload Header Map . 38
E.1.1.10 Frame protection . 38
E.1.2 DVB-RCS2 Transparent Star Configuration . 38
E.1.2.0 General . 38
E.1.2.1 Addressing requirements . 38
E.1.2.2 Payload Label . 39
E.1.3 DVB-RCS2 Transparent and Regenerative Mesh . 39
E.1.3.0 General . 39
E.1.3.1 Addressing requirements . 39
E.1.3.2 ALPDU label . 39
E.1.3.3 Payload Label . 39
E.2 S-MIM . 40
E.2.0 General . 40
E.2.1 Common Configuration . 40
E.2.1.0 General . 40
E.2.1.1 Maximum SDU Size . 40
E.2.1.2 Protocol Type Table. 40
E.2.1.3 Label Type Table . 41
E.2.1.4 Maximum ALPDU Length . 41
E.2.1.5 Extension Headers . 41
E.2.1.6 Integrity Protection . 41
E.2.1.7 ALPDU Fragmentation . 41
E.2.1.8 Payload Header Map . 42
E.2.1.9 PPDU Label . 42
E.2.2 RLE Configuration for SSA . 42
E.2.3 QS-CDMA Configuration . 43
E.2.3.0 General . 43
E.2.3.1 QS-CDMA Configuration for DCH Transport Channel . 43
E.2.3.2 QS-CDMA Configuration for RACH Transport Channel . 43
E.3 Other Regenerative Satellite Systems . 44
History . 45

ETSI
6 ETSI TS 103 179 V1.2.1 (2023-06)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Satellite Earth Stations and
Systems (SES).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
7 ETSI TS 103 179 V1.2.1 (2023-06)
1 Scope
The present document specifies the Return Link Encapsulation (RLE) Protocol, which is used to encapsulate and if
necessary fragment network layer packets such as for example IP datagrams to allow their transmission over the return
link of an interactive satellite network.
RLE has been derived from the Generic Stream Encapsulation (GSE) protocol [1], used in the forward links of
interactive and broadcasting satellite networks, which are normally characterized by continuous transmission, limited
variability in the size of network layer packets, and large physical layer frames typically capable of carrying more than
one network layer packet. RLE was designed to maximize the system efficiency on the return channel, which is in turn
characterized by bursty traffic, highly variable size of network layer packets, smaller physical layer bursts, and multiple
access constraints.
The RLE protocol is designed to provide three main functionalities which are fully specified in the present document,
namely:
• encapsulation;
• fragmentation;
• frame packing.
RLE is today used in DVB-RCS2 [2] as well as in the S-MIM [3] standards.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 102 606: "Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE)
Protocol".
[2] ETSI EN 301 545-2: "Digital Video Broadcasting (DVB); Second Generation DVB Interactive
Satellite System (DVB-RCS2); Part 2: Lower Layers for Satellite standard".
[3] ETSI TS 102 721-5: "Satellite Earth Stations and Systems (SES); Air Interface for S-band Mobile
Interactive Multimedia (S-MIM); Part 5: Protocol Specifications, Link Layer".
[4] IETF RFC 4326: "Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP
Datagrams over an MPEG-2 Transport Stream (TS)".
TM
[5] IEEE 802.3-2012 : "IEEE Standard for Ethernet".
[6] IETF RFC 4944: "Transmission of IPv6 Packets over IEEE 802.15.4 Networks".
ETSI
8 ETSI TS 103 179 V1.2.1 (2023-06)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] IETF RFC 5163: "Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the
Generic Stream Encapsulation (GSE)".
[i.2] ETSI EN 301 790: "Digital Video Broadcasting (DVB); Interaction channel for satellite
distribution systems".
[i.3] DVB Document A155-2: "Digital Video Broadcasting (DVB); Second Generation DVB
Interactive Satellite System (DVB-RCS2); Part 2: Lower Layers for Satellite standard",
January 2013.
[i.4] ETSI TS 102 721-3: "Satellite Earth Stations and Systems (SES); Air Interface for S-band Mobile
Interactive Multimedia (S-MIM); Part 3: Physical Layer Specification, Return Link Asynchronous
Access".
[i.5] ETSI TS 102 721-4: "Satellite Earth Stations and Systems (SES); Air Interface for S-band Mobile
Interactive Multimedia (S-MIM); Part 4: Physical Layer Specification, Return Link Synchronous
Access".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
Protocol Data Unit (PDU): unit of data produced by a layer of the network stack and given to the next lower layer for
transport to the remote peer layer instance
NOTE 1: It contains control information from the current layer and may contain user data from the layer above.
NOTE 2: The SDU of a given layer is the PDU of the layer above.
RLE receiver: entity processing received physical layer frame or burst payloads to reconstruct original network layer
packets.
RLE transmitter: entity processing network layer packets to produce physical layer frame or burst payloads to be
transmitted through the corresponding physical layer
Service Data Unit (SDU): unit of data that is passed from one layer of the network stack to the next lower layer which
has not yet been encapsulated into a PDU by that lower layer
NOTE: It is the set of data given by the user of a layer service to that layer to be transmitted semantically
unchanged to the peer service user. The SDU of a given layer is the PDU of the layer above.
3.2 Symbols
Void.
ETSI
9 ETSI TS 103 179 V1.2.1 (2023-06)
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACM Adaptive Coding and Modulation
ALPDU Addressed Link PDU
ARQ Automatic Repeat reQuest
bslbf bit string, left bit first
CDMA Code Division Multiple Access
CoS Class of Service
CRC Cyclic Redundancy Check
CRDSA Contention Resolution Diversity Slotted ALOHA
DAMA Demand Assignment Multiple Access
DCH Dedicated CHannel
DVB-RCS Digital Video Broadcasting - Return Channel via Satellite
FEC Forward Error Correction
FPDU Frame PDU
GSE Generic Stream Encapsulation
IP Internet Protocol
LLC Logical Link Control
MAC Medium Access Control
NCC Network Control Center
PDU Protocol Data Unit
PPDU Payload-adapted PDU
QEF Quasi Error Free
QoS Quality of Service
QS-CDMA Quasi Synchronous - Code Division Multiple Access
RACH Random Access CHannel
RLE Return Link Encapsulation
ROHC RObust Header Compression
rpchof remainder polynomial coefficients, highest order first
SDU Service Data Unit
S-MIM S-Band Mobile Interactive Multimedia
SNAP Subnetwork Access Protocol
SNDU SubNetwork Data Unit
SSA Spread Spectrum ALOHA
SVN Switched Virtual Network
TCP Transmission Control Protocol
uimsbf unsigned integer, most significant bit first
VoIP Voice over Internet Protocol
4 System Aspects
4.0 General
The main use of the RLE protocol is the transport of data on the return link of transparent or regenerative interactive
satellite networks and on the direct links between terminals in fully meshed systems (see Figure 4.1).
ETSI
10 ETSI TS 103 179 V1.2.1 (2023-06)

Figure 4.1: Interactive Satellite Network
The terminal transmitter contains the transmit side of the RLE protocol (RLE transmitter) which processes network
layer packets and produces physical layer frame or burst payloads. The gateway receiver or the terminal receiver (in the
meshed case) contain the receiving side of the RLE protocol (RLE receiver) which reconstructs network layer packets
from the received burst or frame payloads. In regenerative satellite systems the RLE receiver may also partly or
completely be located in the satellite.
4.1 Protocol Stack
The RLE protocol resides in the Data Link Layer of the communication system (see Figure 4.2). The RLE transmitter
gets network layer packets from the network layer (for example IP datagrams) and produces burst or frame payloads
that are delivered to the physical layer for transmission. On the receiver side burst or frame payloads are processed to
extract the network layer packets and deliver them to the network layer.
ETSI
11 ETSI TS 103 179 V1.2.1 (2023-06)

Figure 4.2: Network Protocol Stack
RLE has three distinct functions:
1) The Encapsulation function which is partly related to the Logical Link Control Layer takes higher layer
packets and associated protocol type and label information and packs these into Addressed Link PDUs
(ALPDUs). On the receiver side the ALPDUs are unpacked and dispatched to the network layer instance
handling the given protocol type. The Encapsulation function realizes the protocol multiplexing function of the
Logical Link Control Layer.
2) The Fragmentation function fragments ALPDUs into smaller units producing Payload-adapted PDUs
(PPDUs), which are then multiplexed into a single stream. The fragmentation takes into account size
information about the physical layer payload fields and may take into account priority information and other
system-specific constraints. This sublayer normally includes a scheduler selecting packets to be processed
based on this information. On the receiving side PPDUs are reassembled into ALPDUs, checked for errors
and, in the success case, delivered upstreams. The fragmentation process is controlled by the current payload
sizes required by the physical layer and the current ALPDU sizes. The physical layer payload sizes may
change on a frame by frame or burst by burst basis (for example in systems using ACM) and the ALPDU sizes
will adapt to the variable size of the higher layer protocols (TCP/IP, for example).
3) The Frame Packing function takes the stream of PPDUs and packs one or more of these into a Frame PDU
(FPDU). It may optionally add signaling information, a label and provide additional error detection capabilities
if the physical layer does not provide those. On the receiver side the Frame Packing function optionally checks
for transmission errors, extracts all PPDUs from each FPDU and dispatches them to the right instance in the
Fragmentation layer for reassembly of ALPDUs. Both the Fragmentation and the Frame Packing function are
related to the Medium Access Control sublayer.
The protocol can be employed not only in single hop (direct transmitter to receiver) configurations, but also in
multi-hop scenarios using switching. The switching can occur between any of the sub-layers of the protocol in which
case the intermediate node implements only the sub-layers below the switching point. Examples are provided in
Annex E.
ETSI
12 ETSI TS 103 179 V1.2.1 (2023-06)
4.2 Protocol Tailoring and Configuration
The RLE protocol can be tailored and configured to fit the transmission system requirements as good as possible. This
involves two steps:
1) Selection of the capabilities and options to be implemented in the transmission system. This is done based on
the system requirements and on the characteristics of the surrounding layers (physical layer and network
layer). Features than are not needed and options that can be set to fixed values reduce the implementation and
testing effort. The remaining options shall be provided with either configuration or signaling (or both) support
in the system.
2) Configure the system operation. The limits of this configurability are defined by the previous step.
Complete information on protocol tailoring and configuration is provided in clause 6.
4.3 Physical Layer Requirements
RLE can operate over physical layers with fixed burst or frame sizes as well as over physical layers with burst or frame
sizes varying from burst to burst or frame to frame as they occur in systems like DVB-RCS2 when using adaptive
coding and modulation (ETSI EN 301 545-2 [2]). The RLE transmitter dynamically adapts the fragmentation to the
available burst or frame size.
The following conditions shall be met by the physical layer:
1) The physical layer burst or frame payload shall have a certain minimum size. This size depends on the
configuration of the FPDU (see clause 5.4) and the PPDU (see clause 5.3). The burst or frame payload size
shall be large enough for the FPDU to be able to carry at least one PPDU. The space for the PPDU shall be
large enough so that a PPDU with the start_indicator set to "1" and the end_indicator set to "0"
fits into that space.
2) The physical layer shall either never reorder physical layer bursts or frames or it shall do so only in
exceptional cases. In the later case the use_alpdu_crc option shall be used for reassembly error checking.
If reordering occurs than all the higher layer PDUs data of which is carried in the reordered frames or bursts
are lost.
3) The physical layer shall either operate quasi-error-free or the use_frame_protection option of the
FPDU shall be used with a protection scheme that reduces the residual errors to quasi-error-free operation.
5 RLE Data Format
5.0 General
The RLE transmitter transforms the network layer PDU into an Addressed Link PDU (ALPDU), sections the ALPDU
into one or more Payload-adapted PDUs (PPDUs) as required, and assembles PPDUs into FPDUs that fit into burst
payload.
On the receiving side the FPDUs from the physical layer are unpacked, the resulting PPDUs are reassembled into
ALPDUs. These in turn are decapsulated and the contained network layer PDUs are sent to the next upper layer (see
Figure 5.1).
ETSI
13 ETSI TS 103 179 V1.2.1 (2023-06)

Figure 5.1: PDUs within RLE stack
5.1 Higher Layer SDU
The SDU is constructed from extension headers and higher layer PDUs, for example IP packets according to the rules in
IETF RFC 4326 [4]. Each of the two parts, but not both at the same time, is optional. Associated to the SDU is a 16-bit
protocol type value which is either the type value of the outermost extension header or the actual protocol type of the
higher layer PDU if there are no extension headers. Also associated to the SDU may be a label of up to 15 bytes
carrying address or other information.
5.2 The Addressed Link PDU (ALPDU)
5.2.0 General
The RLE transmitter shall build ALPDUs that, in addition to the SDU, may include an explicit protocol type indication
and an explicit address tag in a similar structure as for GSE (ETSI TS 102 606 [1]). When both fields are included the
label field is appended after the protocol type field and before the SDU. Both fields are optional. The ALPDU may have
a non-zero size protection field (called PRO in the figure). This is illustrated in Figure 5.2.
Protocol_Type (opt) ALPDU_Label (opt) SDU PRO
0B/1B/2B 0-15B 1-4094/1-8190 0B/1B/4B

Figure 5.2: Addressed Link PDU Format
The ALPDU provides limited explicit integrity protection and thus relies on the integrity protection provided by the
lower protocol layers. If the ALPDU fits into a single PPDU it is not provided with a protection (PRO) parameter field.
When fragmented into multiple PPDUs, the ALPDU contains an integrity protection parameter field of either 1 byte or
4 bytes.
ETSI
14 ETSI TS 103 179 V1.2.1 (2023-06)
5.2.1 Addressed Link PDU Format and Syntax
5.2.1.0 General
The ALPDU format and syntax are defined in Table 5.1.
Table 5.1: Addressed Link PDU Format and Syntax
No. of bits
Syntax Mnemonic
Reserved Information
addressed_link_pdu() {
if (implied_protocol_type[alpdu_label_type] <>
protocol_type) {
if (protocol_type_compressed[alpdu_label_type] = 1){
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...