6 Protocol procedures
24.2503GPPProtocol for Reliable Data ServiceRelease 17Stage 3TS
6.1 Overview
This clause describes the RDS protocol procedures between the UE and network for acknowledged data service.
6.2 Procedures
6.2.1 Types of RDS procedures
The following RDS protocol procedures are defined:
– Establishment of acknowledged transfer;
– Acknowledged information transfer;
– Termination of acknowledged transfer;
– Unacknowledged information transfer;
– Reserve port numbers;
– Release port numbers;
– Query port numbers; and
– Notify port numbers.
6.2.2 Establishment of acknowledged transfer procedure
6.2.2.1 General
The purpose of the establishment of acknowledged transfer procedure is for the originator to establish acknowledged transmission of information with the receiver. All frames other than U and UI frames received during the establishment of acknowledged transfer procedure shall be ignored.
6.2.2.2 Establishment of acknowledged transfer procedure initiation
The originator shall initiate the establishment of acknowledged transfer procedure when upper layers indicate information is to be transmitted using acknowledged operation. The originator and the receiver identify the source and destination port numbers before initiating establishment of acknowledged transfer procedure.
The originator initiates the establishment of acknowledged transfer procedure by transmitting a SET_ACK_MODE command to receiver. When a single application on the originator conducts data transfer with a single application on the receiver, the Source Port and Destination Port numbers need not be used; otherwise the originator shall set the Source Port to the port number of the source application on the originator and the Destination Port to the port number of the destination application on the receiver. The originator shall clear all exception conditions, discard all queued I frames, reset the retransmission counter and timer T200 shall be set.
If a logical link between the UE and network identified without port numbers exists and the originator needs to initiate establishment of an additional acknowledged transfer procedure, the additional logical link between the UE and network shall be identified with port numbers while the first logical link can remain without port numbers.
Figure 6.2.2.2-1: Establishment of acknowledged transfer procedure
6.2.2.3 Establishment of acknowledged transfer procedure accepted by receiver
Upon receiving a SET_ACK_MODE command, the receiver checks if the Destination Port number contained in the SET_ACK_MODE command corresponds to an application on the receiver.
If the check is successful and if the application accepts to enter acknowledged transfer mode, the receiver shall send an ACCEPT response to the originator. When a single application on the originator conducts data transfer with a single application on the receiver, the Source Port and Destination Port numbers need not be used; otherwise the receiver shall set the Source Port to the port number of the application on the receiver and the Destination Port to the port number of the application on the originator. The receiver shall reset timer T200 if active, clear all exception conditions and set V(S), V(R) and V(A) to 0.
6.2.2.4 Establishment of acknowledged transfer procedure completed by originator
Upon receipt of the ACCEPT response and if the Destination Port number corresponds to the application which initiated the establishment of acknowledged transfer procedure, the originator enters acknowledged mode transfer. The originator shall reset timer T200 if active, clear all exception conditions and set V(S), V(R) and V(A) to 0 and the establishment of acknowledged transfer procedure is successfully completed.
6.2.2.5 Establishment of acknowledged transfer procedure not accepted by receiver
Upon receiving a SET_ACK_MODE command if the Destination Port number contained in the SET_ACK_MODE command,
– is not supported by the receiver; or
– corresponds to an application that is not able to perform acknowledged transfer mode,
then the receiver shall send an ERROR response to the originator.
6.2.3 Acknowledged information transfer procedure
6.2.3.1 General
The purpose of the acknowledged information transfer procedure is for the originator to transfer I frames to receiver and receive acknowledgements for these frames from receiver.
The originator shall store the history of the transmitted I frames, and shall remember the I‑frame transmission sequence. The history is used to decide which I frames to retransmit. Due to retransmission, the history is not necessarily an in-order sequence.
A frame within the receive window is either:
– received: the frame has been correctly received; or
– not received: the frame has not been correctly received.
A frame within the transmit window is either:
– not yet transmitted: the frame has not yet been transmitted;
– transmitted: the frame has been (re‑) transmitted, but the originator does not know if the frame has been received by the receiver;
– acknowledged: the frame has been acknowledged by the receiver; or
– marked for retransmission: the originator has decided to retransmit this I frame.
I frames shall be transmitted in ascending N(S) order. When I frames are retransmitted, the frame with the lowest N(S) shall be retransmitted first. This is used by the receiver to detect lost frames.
6.2.3.2 Transmitting I frames and requesting acknowledgements
If the originator has received information to be transmitted from upper layers, the information is inserted in an I frame. The control field parameters N(S) and N(R) shall be assigned the values V(S) and V(R), respectively. V(S) shall be incremented by 1 at the end of the transmission of the I frame.
The originator shall request an acknowledgement from the receiver by transmitting an I or S frame with the A bit set to 1. The originator may request an acknowledgement at any time. An acknowledgement shall be requested when:
– the last I frame in a sequence of one or more I frames is transmitted; or
– V(S) = V(A) + k as a result of the transmission of the I frame.
The originator shall transmit a frame in the following order of priority:
– If there are any I frames marked for retransmission then the originator shall increment by 1 the retransmission count variable for the I frame with the lowest send sequence number N(S). If the retransmission count variable exceeds the value of N200, then the originator shall initiate the Establishment of acknowledged operation procedure as described in subclause 6.2.2. If the retransmission count variable does not exceed the value of N200, then the originator shall retransmit the I frame.
– If the originator has a new I frame to transmit, if V(S) V(A) + k (where k is the maximum number of outstanding I frames) then the new I frame shall be transmitted.
– If the originator has an acknowledgement to transmit then the originator shall transmit an S frame.
When requesting an acknowledgement, the originator shall set timer T201 and associate the timer with the I frame currently being transmitted, or, if the A bit is transmitted in an S frame, with the I frame last transmitted.
Figure 6.2.3.2-1: Acknowledged information transfer procedure
6.2.3.3 Receiving I frames and sending acknowledgements
When the receiver receives a valid I frame whose N(S) is equal to the current V(R), the receiver shall:
– pass the contents of the Information field to the appropriate upper layer entity;
– increment its V(R) by 1; and
– respond with a I or S frame containing the SACK bitmap, if the A bit of the received I frame was set to 1.
When the receiver receives a valid I frame whose N(S) is not in the range V(R) N(S) V(R) + k, the receiver shall discard the frame as a duplicate.
When the receiver receives a valid I frame where V(R) N(S) V(R) + k, then the receiver shall store the I frame until all frames from V(R) to N(S) ‑ 1 inclusive are correctly received. Once all the frames are correctly received the receiver shall then:
– pass the contents of the Information field to the appropriate upper layer entity; and
– set its V(R) = N(S) + 1.
Whenever the receiver detects an error in the sequence of received I frames, it shall transmit an I or S frame.
If the receiver receives an I frame with a higher N(S) than the N(S) of the previously received I frame, and if there are I frames missing between these two N(S) values, then the receiver shall assume that the missing I frames have been lost. If the receiver receives an I frame with a lower N(S) than the N(S) of the previously received I frame, it can assume that its peer originator has (re‑) started retransmission due to the reception of an acknowledgement.
6.2.3.4 Receiving acknowledgements
On receipt of a valid I or S frame , the originator shall, if N(R) is valid, treat the N(R) contained in this frame as an acknowledgement for all the I frames it has transmitted with an N(S) up to and including the received N(R) ‑ 1. A valid N(R) value is one that is in the range V(A) N(R) V(S). If N(R) is not valid, then the received SACK bitmap shall be disregarded.
V(A) shall then be set to N(R).
On receipt of a valid I or S frame containing the SACK bitmap, the originator shall consider all I frames with the corresponding bit set to 1 in the SACK bitmap as acknowledged.
If timer T201 is active and associated with an acknowledged I frame, then timer T201 shall be reset.
The originator shall determine which I frames to retransmit by analysing it’s I frame transmission sequence history and the acknowledgements received. An unacknowledged I frame that was transmitted prior to an acknowledged I frame shall be considered lost and shall be marked for retransmission. Acknowledged I frames shall be removed from the I frame transmission sequence history.
6.2.4 Termination of acknowledged transfer procedure
6.2.4.1 General
The purpose of the termination of acknowledged transfer procedure is to terminate the acknowledged transmission of information between the UE side and the network side. All frames other than U and UI frames received during the termination of acknowledged transfer procedure shall be ignored and all queued I frames shall be discarded.
6.2.4.2 Termination of acknowledged transfer procedure initiation
The originator or receiver shall initiate the termination of acknowledged transfer procedure when upper layers indicate termination of acknowledged operation.
The originator initiates the termination of acknowledged transfer procedure by transmitting a DISCONNECT command. When a single application on the originator conducts data transfer with a single application on the receiver, the Source Port and Destination Port numbers need not be used; otherwise the originator shall set the Source Port to the port number of the source application on the originator and the Destination Port to the port number of the destination application on the receiver. The originator shall reset the retransmission counter and timer T200 shall be set.
Figure 6.2.4.2-1: Termination of acknowledged transfer procedure
6.2.4.3 Termination of acknowledged transfer procedure accepted by receiver
Upon receiving a DISCONNECT command, the receiver checks if the Destination Port number contained in the DISCONNECT command corresponds to an application on the receiver.
If the check is successful the receiver shall send an ACCEPT response to the originator. When a single application on the originator conducts data transfer with a single application on the receiver, the Source Port and Destination Port numbers need not be used; otherwise the receiver shall set the Source Port to the port number of the application on the receiver and the Destination Port to the port number of the application on the originator.
6.2.4.4 Termination of acknowledged transfer procedure completed by originator
Upon receipt of the ACCEPT response and if the Destination Port number corresponds to the application which initiated the termination of acknowledged transfer procedure, the originator terminates acknowledged transfer mode. The originator shall reset timer T200 if active, and the termination of acknowledged transfer procedure is successfully completed.
6.2.4.5 Termination of acknowledged transfer procedure not accepted by receiver
Upon receiving a DISCONNECT command if the Destination Port number contained in the DISCONNECT command
– is not supported by the receiver; or
– corresponds to an application that is not in acknowledged transfer mode,
then the receiver shall send an ERROR response to the originator.
6.2.5 Unacknowledged information transfer procedure
6.2.5.1 General
The purpose of the unacknowledged information transfer procedure is for the originator to perform unacknowledged transmission of information to the receiver. No error recovery mechanisms are defined for unacknowledged operation
6.2.5.2 Unacknowledged information transfer procedure initiation
The originator shall initiate the unacknowledged information transfer procedure when information from upper layers is to be transmitted using unacknowledged operation. The originator and the receiver negotiate the use of source and destination port numbers before initiating unacknowledged information transfer.
The originator initiates the unacknowledged information transfer procedure by transmitting a UI frame to receiver. When a single application on the originator conducts data transfer with a single application on the receiver, the Source Port and Destination Port numbers need not be used; otherwise the originator shall set the Source Port to the port number of the source application on the originator and the Destination Port to the port number of the destination application on the receiver. The originator shall set the unconfirmed sequence number N(U) in UI frame to the value of unconfirmed send state variable V(U).
Figure 6.2.5.2-1: Unacknowledged information transfer procedure
6.2.5.3 Unacknowledged information transfer procedure accepted by receiver
Upon receiving a UI frame the receiver passes the contents of the Information field to the appropriate upper layer corresponding to the Destination Port. The receiver shall set the unconfirmed receive state variable V(UR) to N(U) + 1.
6.2.5.4 Unacknowledged information transfer procedure completed by originator
Upon transmission of the UI frame the unacknowledged information transfer procedure is completed by the originator.
6.2.5.5 Unacknowledged information transfer procedure not accepted by receiver
Upon receiving a UI frame,
– if the Destination Port number is not in use by the receiver; or
– if N(U) of the received UI frame is in the range ( V(UR) – k’ ) N(U) V(UR) and if a UI frame with the same N(U) has already been received,
then the UI frame is discarded by the receiver without any further action. The value of k’ may be in the range 1 < k’ < MAX SEQUENCE NUMBER/2.
6.2.6 Reserve port numbers procedure
6.2.6.1 General
The originator and the receiver use the reserve port number procedure if they support the handling as specified in subclause 5.4.2.6. The purpose of the reserve port numbers procedure is for the originator to reserve a combination of source and destination port numbers for use with a specific application. All frames other than U and UI frames received during the reserve port numbers procedure shall be ignored. It is optional for the receiver to support the reserve port number functionality.
6.2.6.2 Reserve port numbers procedure initiation
The originator shall initiate the reserve port numbers procedure when upper layers indicate information is to be transferred using a specific application. The upper layers may identify the source and destination port numbers to be reserved based on the available port numbers at originator and receiver before initiating the reserve port numbers procedure.
The originator initiates the reserve port numbers procedure by transmitting a MANAGE_PORT command to the receiver. The originator shall set the Source Port to the port number to be reserved on the originator, the Destination Port to the port number to be reserved on the receiver, and the Application ID field to the identifier of the application to be associated with the combination of the Source Port and Destination Port numbers specified in the MANAGE_PORT command. If the originator wants to reserve a combination of source and destination port numbers for an application but does not want to negotiate the serialization format used by the application, the originator shall set the Action field to "Reserve port". If the originator wants to reserve a combination of source and destination port numbers for an application and also negotiate the serialization format used by the application, the originator shall set the Action field to "Reserve port and serialization format" and shall also set all the serialization formats supported by the originator in the Serialization Format field. The originator shall clear all exception conditions, discard all queued I frames, reset the retransmission counter and timer T200 shall be set.
6.2.6.3 Reserve port numbers procedure accepted by receiver
If the receiver supports the reserve port number functionality then upon receiving a MANAGE_PORT command with the Action field set to "Reserve port" or "Reserve port and serialization format", the receiver checks if the Destination Port number contained in the MANAGE_PORT command is associated with any application on the receiver.
If the check is successful the receiver shall reserve the Destination Port for use with the application identifier included in the MANAGE_PORT command. The receiver shall send a MANAGE_PORT response to the originator by setting the Action field in response frame to the same value of Action field received in the MANAGE_PORT command frame and the Status field in MANAGE_PORT response frame to "Success". The receiver shall reset timer T200 if active and clear all exceptions.
If the originator has indicated the serialization format supported by the application in the Serialization Format field of the MANAGE_PORT command frame, the receiver checks if it can support the serialization format indicated by the originator. If the originator has indicated multiple serialization formats the receiver selects the best serialization format among those indicated that it can support. The receiver sets the Serialization Format field in the MANAGE_PORT response frame to the selected serialization format.
6.2.6.4 Reserve port numbers procedure completed by originator
Upon receipt of the MANAGE_PORT response with the Action field set to "Reserve port" or "Reserve port and serialization format", and if the Status field is set to "Success", the originator shall reserve the Source Port for use with the application identifier included in the MANAGE_PORT command and select the serialization format indicated in the Serialization Format field in the MANAGE_PORT response frame, for use with the application.. The originator shall reset timer T200 if active, clear all exception conditions and the reserve port numbers procedure is successfully completed.
6.2.6.5 Reserve port numbers procedure not accepted by receiver
If the receiver supports the reserve port number functionality then upon receiving a MANAGE_PORT command with the Action field set to "Reserve port" or "Reserve port and serialization format", if the Destination Port number contained in the MANAGE_PORT command is already reserved for use with another application on the receiver then the receiver shall send a MANAGE_PORT response to the originator by setting the Action field in response frame to "Reserve port" and the Status field in MANAGE_PORT response frame to "Port not free".
If the receiver was successful in reserving the destination port for use with the application identifier included in the MANAGE_PORT command frame and the originator has indicated the serialization format supported by the application in the Serialization Format field of the MANAGE_PORT command frame and the receiver cannot support any of the serialization formats indicated by the originator, the receiver shall set the Serialization Format field in the MANAGE_PORT response frame to the serialization formats that the receiver can support and shall set the Status field in the MANAGE_PORT response frame to "Serialization format not supported". The receiver shall not reserve the destination port for use with the application identifier included in the MANAGE_PORT command frame.
6.2.7 Release port numbers procedure
6.2.7.1 General
The originator and the receiver use the release port number procedure if they support the handling as specified in subclause 5.4.2.6. The purpose of the release port numbers procedure is for the originator to release a combination of source and destination port numbers that have been reserved for use with a specific application. All frames other than U and UI frames received during the release port numbers procedure shall be ignored. It is optional for the receiver to support the release port number functionality.
6.2.7.2 Release port numbers procedure initiation
The originator shall initiate the release port numbers procedure when upper layers indicate that information transfer using a specific application is over and that it is permissible to release the combination of ports used by this application.
The originator initiates the release port numbers procedure by transmitting a MANAGE_PORT command to the receiver. The originator shall set the Source Port to the port number to be released on the originator, the Destination Port to the port number to be released on the receiver, the Action field to "Release port" and the Application ID field to the identifier of the application that is associated with the combination of the Source Port and Destination Port numbers specified in the MANAGE_PORT command. The originator shall clear all exception conditions, discard all queued I frames, reset the retransmission counter and timer T200 shall be set.
6.2.7.3 Release port numbers procedure accepted by receiver
If the receiver supports the release port number functionality then upon receiving a MANAGE_PORT command with the Action field set to "Release port", the receiver checks if the Destination Port number contained in the MANAGE_PORT command is reserved on the receiver for use with the application specified by the Application ID field in the MANAGE_PORT command.
If the check is successful the receiver shall release the Destination Port from use with the application identifier included in the MANAGE_PORT command. The receiver shall send a MANAGE_PORT response to the originator by setting the Action field in response frame to "Reserve port" and the Status field in MANAGE_PORT response frame to "Success". The receiver shall reset timer T200 if active and clear all exceptions.
6.2.7.4 Release port numbers procedure completed by originator
Upon receipt of the MANAGE_PORT response with the Action field set to "Release port", and if the Status field is set to "Success", the originator shall release the Source Port from use with the application identifier included in the MANAGE_PORT command. The originator shall reset timer T200 if active, clear all exception conditions and the release port numbers procedure is successfully completed.
6.2.7.5 Release port numbers procedure not accepted by receiver
If the receiver supports the release port number functionality then upon receiving a MANAGE_PORT command with the Action field set to "Release port", if the Destination Port number contained in the MANAGE_PORT command is not reserved on the receiver for use with specified application identifier in the MANAGE_PORT command then the receiver shall send a MANAGE_PORT response to the originator by setting the Action field in response frame to "Release port" and the Status field in MANAGE_PORT response frame to "Port not associated with specified application".
6.2.8 Query port numbers procedure
6.2.8.1 General
The originator and the receiver use the query port number procedure if they support the handling as specified in subclause 5.4.2.6. The purpose of the query port numbers procedure is for the originator to query the list of port numbers that are reserved for use with a specific application and the associated serialization format. All frames other than U and UI frames received during the query port numbers procedure shall be ignored. It is optional for the receiver to support the query port number functionality.
6.2.8.2 Query port numbers procedure initiation
The originator shall initiate the query port numbers procedure when upper layers indicate the need to determine any port numbers on receiver that are available for use with an application or query the serialization format associated with an application.
The originator initiates the query port numbers procedure by transmitting a MANAGE_PORT command to the receiver and setting Requested port numbers to the destination port numbers that it intends to query. If the originator intends to query all the port numbers, then it shall not include the Requested port numbers. If the originator only wants to query the destination port numbers that are reserved but does not want to query the serialization format used by the application, the originator shall set the Action field to "Query port", otherwise if the originator also wants to query the serialization format used by the application, the originator shall set the Action field to "Query port and serialization format". The originator shall clear all exception conditions, discard all queued I frames, reset the retransmission counter and timer T200 shall be set.
6.2.8.3 Query port numbers procedure accepted by receiver
If the receiver supports the query port number functionality then upon receiving a MANAGE_PORT command with the Action field set to "Query port" or "Query port and serialization format", the receiver shall send a MANAGE_PORT response to the originator by setting the Action field in response frame to the same value received in the Action field of the MANAGE_PORT command. For each Destination Port that is reserved on the receiver for use by an application, the receiver shall include an entry in the MANAGE_PORT response. The receiver shall set the Num Entries field in the MANAGE_PORT response to the number of entries that are included in the MANAGE_PORT response. For each Destination Port that is reserved on the receiver, the receiver shall include the Source Port number that the Destination Port is paired with and the Application ID of the application to be used with the reserved Destination Port. If the receiver does not have any reserved Source Port number for the associated Application ID, the Source Port number shall be set to 0. If the receiver received a MANAGE_PORT command with Action field set to "Query port and serialization format", then for each destination port entry the receiver shall include the Serialization Format associated with the Application ID.
If the entries for all the source port numbers do not fit in the MANAGE_PORT response, the receiver shall include as many entries on source port numbers as possible. For all the source port numbers that are reserved on the receiver and for which information cannot be included in the MANAGE_PORT response, the receiver shall set the corresponding entry in the Port numbers not available bitmap. If the entries for all the destination port numbers requested by the originator fit in the MANAGE_PORT response, the receiver shall not include the optional Port numbers not available bitmap. The receiver shall reset timer T200 if active and clear all exceptions.
6.2.8.4 Query port numbers procedure completed by originator
Upon receipt of the MANAGE_PORT response with the Action field set to "Query port" or "Query port and serialization format", the originator shall make a note of all Destination Ports that are reserved for use with an application along with associated serialization format and may pass this information to upper layers. If the Port numbers not available bitmap is not set to zero, the originator can subsequently query information on these source port numbers by sending another MANAGE_PORT command by setting the Action field to "Query port" or "Query port and serialization format" and setting Requested port numbers to Port numbers not available in the received MANAGE_PORT response. The originator shall reset timer T200 if active, clear all exception conditions and the query port numbers procedure is successfully completed.
6.2.9 Notify port numbers procedure
6.2.9.1 General
The originator and the receiver use the notify port number procedure if they support the handling as specified in subclause 5.4.2.6. The purpose of the notify port numbers procedure is for the originator to notify the receiver of the list of port numbers that are reserved for use with a specific application and the associated serialization format. All frames other than U and UI frames received during the notify port numbers procedure shall be ignored. It is optional for the receiver to support the notify port number functionality.
6.2.9.2 Notify port numbers procedure initiation
The originator shall initiate the notify port numbers procedure when a Source Port on the originator may be reserved for use with an application.
The originator initiates the notify port numbers procedure by transmitting a MANAGE_PORT command to the receiver. If the originator wants to notify the receiver of only the source port numbers that are reserved at the originator but does not want to notify the serialization format used by the application, the originator sets the Action field to "Notify port", otherwise if the originator also wants to notify the receiver of the serialization format used by the application, the originator shall set the Action field to "Notify port and serialization format". For each Source Port that is reserved on the originator for use by an application, the receiver shall include an entry in the MANAGE_PORT command. The originator shall set the Num Entries field in the MANAGE_PORT command to the number of entries that are included in the MANAGE_PORT response. For each Source Port that is reserved on the originator, the originator shall include the Destination Port number that the Source Port is paired with and the Application ID of the application to be used with the reserved Source Port. If the originator does not have any reserved Destination Port number for the associated Application ID, the Destination Port number shall be set to 0. If the originator wants to notify the receiver about the serialization format used by the application, then for each destination port entry the originator shall also include the Serialization Format associated with the Application ID.
If the entries for all the source port numbers do not fit in the MANAGE_PORT command, the originator shall include as many entries on source port numbers as possible. For all the source port numbers that are reserved on the originator and for which information cannot be included in the MANAGE_PORT command, the originator shall set the corresponding entry in the Port numbers not available bitmap. If the entries for all the source port numbers fit in the MANAGE_PORT command, the originator shall not include the Port numbers not available bitmap. The originator shall clear all exception conditions, discard all queued I frames and reset the retransmission counter.
6.2.9.3 Notify port numbers procedure accepted by receiver
If the receiver supports the notify port number functionality then upon receipt of the MANAGE_PORT command with the Action field set to "Notify port" or "Notify port and serialization format", the receiver shall make a note of all Source Ports that are reserved for use with an application on the originator along with the associated serialization format and may pass this information to upper layers. The receiver shall clear all exception conditions and the notify port numbers procedure is successfully completed.
If the Port numbers not available bitmap is included in the MANAGE_PORT command, the receiver can subsequently query information on these source port numbers by sending a MANAGE_PORT command by setting the Action field to "Query port" or "Query port and serialization format" and setting Requested port numbers to Port numbers not available in the received MANAGE_PORT command as described in subclause 6.2.8.
6.3 Abnormal cases
6.3.1 Expiry of timer T200
Timer T200 is set when a U frame with any of the following commands is transmitted.
– SET_ACK_MODE;
– DISCONNECT;
– SET_PARAMETERS; and
– MANAGE_PORT.
If timer T200 expires before a response to the sent command is received then the originator shall retransmit the command, and shall reset and start timer T200 and increment the retransmission counter. After retransmission of the command N200 times, the originator shall abort the operation and notify the upper layers.
6.3.2 Expiry of timer T201
On expiry of timer T201, the originator shall increment by 1 the retransmission count variable for the I frame associated with timer T201. If the value of the retransmission count variable does not exceed N200, the originator shall reset and start timer T201, and retransmit the I frame with the A bit set to 1. If the value of the retransmission count variable exceeds N200, the originator shall send the ERROR command to the receiver and initiate the establishment of acknowledged transfer procedure to re-establish the acknowledged transfer mode with the receiver.
6.3.3 Collision during reserving the same port number between originator and receiver
If the originator is trying to reserve a combination of source port number on the originator and a destination port number on the receiver by sending a MANAGE_PORT command to the receiver and if it receives another MANAGE_PORT command from the receiver trying to reserve the same port number on the originator then,
a) if both the originator and the receiver are trying to reserve the same combination of port numbers with the same application identifier, then the originator shall accept the MANAGE_PORT command from the receiver, reserve the Destination Port for use with the application identifier included in the MANAGE_PORT command and send a MANAGE_PORT response to the receiver by setting the Action field in response frame to "Reserve port" and the Status field in MANAGE_PORT response frame to "Success"; or
b) otherwise the originator shall not accept the MANAGE_PORT command from the receiver and shall send a MANAGE_PORT response to the receiver by setting the Action field in response frame to "Reserve port" and the Status field in MANAGE_PORT response frame to "Port not free".
6.4 List of RDS Parameters
6.4.1 General
The following parameters are applicable for Reliable Data Service (RDS).
6.4.2 RDS version number (Version)
The RDS version number (Version) is an RDS layer parameter. The default version number is 0.
6.4.3 Retransmission timers (T200 and T201)
The default value of timers T200 and T201 is 250 seconds.
6.4.4 Maximum number of retransmissions (N200)
The default value of N200 is 3.
6.4.5 Maximum number of outstanding I frames (k)
k is the maximum number of sequentially-numbered I frames that may be outstanding (i.e. unacknowledged) at any given time. k is also denoted as window size. The default value of k is 3. The value of MAX SEQUENCE NUMBER is 8.
6.4.6 Maximum length of Information Field (N201)
The default value of N201 is 1520 octets.
Annex A (informative):
Change history
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2017-04 |
CT1 #103 |
C1-171464 |
– |
– |
– |
TS skeleton generated for submission at CT1 #103 |
0.0.0 |
|
2017-04 |
CT1 #103 |
– |
– |
– |
– |
Incorporated agreed P-CRs for TS 24.250 from CT1 #103 – C1-171467, C1-171618, C1-171619, C1-171621, C1-171930, C1-171932, C1-171933, C1-171935. C1-171936 and editorial clean-up by the rapporteur. |
0.1.0 |
|
2017-05 |
CT1 #104 |
– |
– |
– |
– |
Incorporated agreed P-CRs for TS 24.250 from CT1 #104 – C1-172240, C1-172404, C1-172406, C1-172621, C1-172622, C1-172623, C1-172624, C1-172625. C1-172626 and editorial clean-up by the rapporteur. |
0.2.0 |
|
2017-06 |
CT-76 |
CP-171107 |
Version 1.0.0 created for presentation to TSG CT for information and approval |
1.0.0 |
|||
|
2017-06 |
CT-76 |
Version 14.0.0 created after approval at CT76 |
14.0.0 |
||||
|
2017-12 |
CT-78 |
CP-173060 |
0002 |
F |
RDS handling when retransmission count exceeds N200 |
14.1.0 |
|
|
2017-12 |
CT-78 |
CP-173060 |
0003 |
1 |
F |
Max Length of RDS information Field |
14.1.0 |
|
2017-12 |
CT-78 |
CP-173060 |
0004 |
1 |
F |
Clarification on SACK bitmap usage |
14.1.0 |
|
2017-12 |
CT-78 |
CP-173060 |
0006 |
1 |
F |
Clarification on identification of RDS connections for multiple applications |
14.1.0 |
|
2017-12 |
CT-78 |
CP-173079 |
0005 |
1 |
C |
Support for Reliable Data Service with PtP SGi Tunneling |
15.0.0 |
|
2018-12 |
CT-82 |
CP-183075 |
0008 |
A |
Define variables and parameters for unacknowledged operation |
15.1.0 |
|
|
2019-03 |
CT-83 |
CP-190108 |
0011 |
3 |
B |
Enhancing RDS for dynamic port management |
16.0.0 |
|
2019-06 |
CT-84 |
CP-191128 |
0012 |
1 |
B |
Updates to Scope for support of RDS in 5GS |
16.1.0 |
|
2019-06 |
CT-84 |
CP-191128 |
0013 |
4 |
B |
Updates to Overview for support of RDS in 5GS |
16.1.0 |
|
2019-06 |
CT-84 |
CP-191128 |
0014 |
B |
Updates to field format and procedures for support of RDS in 5GS |
16.1.0 |
|
|
2019-06 |
CT-84 |
CP-191147 |
0015 |
3 |
B |
Procedures for port number management |
16.1.0 |
|
2019-06 |
CT-84 |
CP-191128 |
0016 |
B |
Change Title of TS 24.250 |
16.1.0 |
|
|
2019-12 |
CT-86 |
CP-193116 |
0021 |
2 |
F |
Abnormal cases for port number management |
16.2.0 |
|
2020-09 |
CT-89e |
CP-202166 |
0023 |
1 |
F |
Reference model for RDS in 5GS |
16.3.0 |
|
2020-09 |
CT-89e |
CP-202166 |
0025 |
2 |
F |
Updates to Manage Port Command for long Application Identifiers |
16.3.0 |
|
2020-12 |
CT-90e |
CP-203213 |
0026 |
F |
Correcting hanging text and other errors |
16.4.0 |
|
|
2020-12 |
CT-90e |
CP-203208 |
0024 |
2 |
B |
Support for Indicating Serialization Format in RDS |
17.0.0 |