Content for TS 24.250 Word version: 17.0.0

1… 5…

3.1 Definitions 3.2 Abbreviations 4.1 General 4.2 Reference Model 4.3 Description of RDS protocol
...

1 Scope p. 7

The present document specifies a Reliable Data Service (RDS) protocol.

The present document defines the frame structure, format of fields and procedures for operation of the RDS protocol. RDS is mainly intended to be used for acknowledged data transfer, but it also supports unacknowledged data transfer.

The present document is applicable to the UE, the SCEF and to the P-GW in the Evolved Packet System (EPS) and to the UE, the SMF, NEF and to the UPF in the 5G System (5GS).

2 References p. 7

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1]

TR 21.905: "Vocabulary for 3GPP Specifications".

[2]

TS 23.682: "Architecture enhancements to facilitate communications with packet data networks and applications".

[3]

RFC 4122: "A Universally Unique IDentifier (UUID) URN Namespace".

[4]

TS 23.501: "System Architecture for the 5G System; Stage 2".

[5]

W3C Recommendation: "Extensible Markup Language (XML) 1.0 (Fifth Edition)", 26 November 2008

[6]

RFC 8529: "The JavaScript Object Notation (JSON) Data Interchange Format".

[7]

RFC 7049: "Concise Binary Object Representation (CBOR)", October 2013.

3 Definitions and abbreviations p. 7

3.1 Definitions p. 7

For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.

For the purposes of the present document, the following terms and definitions given in TS 23.682 apply:

SCEF

For the purposes of the present document, the following terms and definitions given in TS 23.501 apply:

SMF

NEF

UPF

3.2 Abbreviations p. 8

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.

RDS

Reliable Data Service

4 Overview p. 8

4.1 General p. 8

The Reliable Data Service (RDS) protocol supports the following requirements:

RDS supports peer-to-peer data transfers and shall provide reliable data delivery between the UE and the network. In EPS the data is transferred via a PDN connection between the UE and SCEF or P-GW. In 5GS the data is transferred between the UE and NEF or UPF via a PDU session between the UE and SMF.
A UE can connect to multiple network entities. In EPS a UE can connect to multiple SCS/AS via the SCEF or P-GW. In 5GS a UE can connect to multiple AF via the NEF or UPF.
RDS shall support multiple applications on the UE to simultaneously conduct data transfers with their peer entities on the network using a single PDN connection or a PDU session between the UE and the network.
RDS shall support both acknowledged and unacknowledged data transfers.
RDS shall support variable-length frames and shall allow detection and elimination of duplicate frames at the receiving endpoint.

4.2 Reference Model p. 8

Copy of original 3GPP image for 3GPP TS 24.250, Fig. 4.2-1: Protocol layering for reliable data transfer between UE and SCEF in EPS

Figure 4.2-1: Protocol layering for reliable data transfer between UE and SCEF in EPS
(⇒ copy of original 3GPP image)

The reference model showing the protocol layering for reliable data transfer between UE and SCEF in EPS is illustrated in Figure 4.2-1.

Copy of original 3GPP image for 3GPP TS 24.250, Fig. 4.2-2: Protocol layering for reliable data transfer between UE and NEF in 5GS

Figure 4.2-2: Protocol layering for reliable data transfer between UE and NEF in 5GS
(⇒ copy of original 3GPP image)

The reference model showing the protocol layering for reliable data transfer between UE and NEF in 5GS is illustrated in Figure 4.2-2.

4.3 Description of RDS protocol p. 9

4.3.1 Protocol functions p. 9

RDS establishes a peer-to-peer logical link between the UE and the network. The logical link is identified by,

a pair of port numbers and EPS bearer ID in EPS; or
a pair of port numbers, PDU session identity and the QoS Flow Identifier in 5GS.

Each port number is used to identify an application on the UE side or at the network side and is carried in the address field of each frame. The source port number identifies the application on the originator and the destination port number identifies the application on the receiver. When a single application on the originator conducts data transfer with a single application on the receiver, the source port number and destination port number need not be used. Each RDS frame shall consist of a header and an information field of variable length. The header shall contain information about port numbers and the frame number that is used to identify the frame and provide reliable transmission. The information field contains the payload to be transferred between the UE and the network.

In EPS,

the UE establishes a PDN connection with the SCEF or P-GW either during Attach or through UE requested PDN connectivity. The UE shall use the EPS bearer ID to select the bearer to transfer RDS PDUs to the SCEF or P-GW. The EPS bearer ID identifies the destination (at the UE or at the SCEF or P-GW) and is not carried in the frame as it is already included in the NAS ESM message header.

In 5GS,

the UE establishes a PDU session with the SMF through UE requested PDU session establishment procedure. The UE shall use the PDU session identity and the QoS Flow Identifier to select the flow to transfer RDS PDUs to the NEF or UPF. The PDU session identity identifies the destination (at the UE or at the NEF or UPF) and is not carried in the frame as it is already included in the NAS 5GSM message header.

Once the UE and network successfully negotiate to use RDS for a particular PDN connection or a PDU session, the PDN connection or PDU session shall transfer data only using RDS protocol.

RDS shall support both single and multiple applications within the UE. RDS enables applications to reserve source and destination port numbers for their use and also subsequently release the reserved port numbers. When reserving ports applications can indicate the serialization format that they will be using. RDS also enables applications to query their peer entities to determine which port numbers are reserved and which are available for use at any given time. Applications can also additionally query their peer entities to determine the serialization format that will be used. RDS shall provide fuctionality for flow control and sequence control to maintain the sequential order of frames across the logical link. The UE and the network may support reservation of the source and the destination port numbers for their use and subsequent release of the reserved port numbers.

4.3.2 Acknowledged operation p. 10

In acknowledged operation the information is transmitted in order in numbered Information (I) frames. The I frames are acknowledged at the RDS layer. Error recovery and reordering mechanisms based on retransmission of acknowledged I frames are specified. Several I frames can be acknowledged at the same time. Flow control is implemented via a sliding window mechanism.

The procedure for establishment of acknowledged transfer is described in clause 6.

4.3.3 Unacknowledged operation p. 10

In unacknowledged operation the information is transmitted in numbered Unconfirmed Information (UI) frames. The UI frames are not acknowledged at the RDS layer. Error recovery and reordering mechanisms are not defined. Duplicate UI frames are discarded. Flow control procedures are not defined.